Chiến lược lựa chọn mô hình AI nào giúp doanh nghiệp tối ưu hóa hiệu suất khi OpenRouter ghi nhận 60% lượng token sử dụng đến từ các mô hình nguồn mở và Trung Quốc?

I. Con số gây sốc và phản biện lối mòn phổ biến

Tháng 5 năm 2026, OpenRouter công bố dữ liệu mà toàn bộ ngành AI inference phải dừng lại nhìn nhận: 60% tổng lượng token được xử lý trên nền tảng này đến từ các mô hình nguồn mở và mô hình có xuất xứ Trung Quốc. Con số này không phải một thống kê thị hiếu thông thường. Đây là bằng chứng toán học rằng cán cân quyền lực trong AI inference đang dịch chuyển một cách thô bạo và không thể đảo ngược.

Để hiểu trọng lượng của con số này, cần biết OpenRouter không phải một startup nhỏ. Đây là aggregator inference lớn nhất thế giới tính đến 2026, xử lý hàng tỷ token mỗi ngày cho hàng chục nghìn developer và doanh nghiệp. Khi 60% traffic chảy về một nhóm mô hình cụ thể, nó phản ánh một thực tế kinh tế thuần túy: người dùng đang bỏ tiền thật để vote cho lựa chọn tối ưu chi phí-hiệu quả của họ.

1. Lối mòn thứ nhất: “Proprietary always wins”

Lối mòn đầu tiên cần phá vỡ là niềm tin rằng mô hình proprietary luôn vượt trội. Niềm tin này từng đúng vào năm 2023 khi GPT-4 ra mắt và bỏ xa mọi đối thủ. Nhưng năm 2026, khoảng cách chất lượng giữa GPT-4o, Claude 4, Gemini 2.5 Pro so với Llama 4 Maverick, Qwen 3, hay DeepSeek-V4 đã bị nén lại đến mức chỉ còn ý nghĩa trong một nhóm tác vụ rất hẹp như reasoning phức tạp bậc 5 hoặc multimodal edge-case.

Trên 80% tác vụ doanh nghiệp thực tế (tổng hợp tài liệu, phân loại, trích xuất dữ liệu, sinh nội dung marketing, dịch thuật, coding boilerplate), các mô hình nguồn mở đạt chất lượng tương đương với sai số chấp nhận được. Và chi phí inference trên mỗi triệu token thì chênh lệch từ 5 đến 20 lần có lợi cho phía nguồn mở.

2. Lối mòn thứ hai: “Mô hình Trung Quốc là bản sao kém chất lượng”

Lối mòn thứ hai nguy hiểm hơn vì nó mang tính định kiến phi kỹ thuật. DeepSeek-V4, Qwen 3, và GLM-5 không phải bản sao. Chúng là các mô hình được huấn luyện trên kiến trúc transformer đã được tối ưu hóa riêng cho ngữ cảnh tiếng Trung và đa ngôn ngữ, với đội ngũ researcher trình độ ngang tầm bất kỳ lab nào trên thế giới.

Dữ liệu benchmark trên MMLU, HumanEval, GSM8K và MGSM cho thấy Qwen 3-235B đạt điểm số nằm trong top 3 toàn cầu ở nhiều tác vụ. DeepSeek-V4 với kiến trúc Mixture-of-Experts (MoE) đã chứng minh rằng chi phí training và inference có thể giảm bằng cách thông minh hóa kiến trúc, không phải bằng cách hy sinh chất lượng.

Key Takeaway: 60% traffic đổ về open-source và mô hình Trung Quốc không phải phong trào nhất thời. Đó là kết quả logic của hàm chi phí-hiệu quả trong một thị trường đã trưởng thành. Doanh nghiệp nào vẫn chọn mô hình dự trên brand name thay vì dữ liệu benchmark thực tế đang đốt tiền vô ích.

---

II. Phá rã vấn đề: Phân tích First Principles

Để xây dựng chiến lược lựa chọn mô hình đúng đắn, cần phá vỡ khái niệm “lựa chọn mô hình AI” về các thực thể nguyên thủy bên dưới. Đây là cách tư duy mà Andrej Karpathy gọi là reasoning from physics, not from fashion.

1. Thực thể nguyên thủy thứ nhất: Hàm chi phí thực tế (True Cost Function)

Chi phí sử dụng một mô hình AI không chỉ là giá trên mỗi triệu token. Hàm chi phí thực tế bao gồm ba biến số:

Cost = (Price_per_token x Volume) + (Latency_cost x Delay_seconds) + (Switching_cost x Frequency_of_migration)

Biến thứ nhất dễ nhìn thấy nhất nhưng thường không phải biến lớn nhất. Biến thứ hai, latency cost, là chi phí ẩn khi nhân viên chờ 3 giây thay vì 1 giây cho một response, nhân lên hàng trăm lần mỗi ngày trong hàng nghìn nhân viên. Biến thứ ba, switching cost, là cái giá phải trả mỗi khi doanh nghiệp phải migrate pipeline từ model A sang model B, bao gồm re-testing, re-prompting, re-evaluation, và training lại nhân sự.

Hầu hết doanh nghiệp chỉ nhìn vào biến thứ nhất. Đây là sai lầm chiến lược cơ bản.

2. Thực thể nguyên thủy thứ hai: Phân rã tác vụ (Task Decomposition)

Một doanh nghiệp trung bình sử dụng AI cho 15-40 loại tác vụ khác nhau. Không có mô hình nào tối ưu cho tất cả. Nguyên lý vật lý ở đây rất đơn giản: mỗi mô hình là một hàm số được tối ưu hóa cho một phân phối xác suất cụ thể của dữ liệu huấn luyện.

Khi bạn dùng GPT-4o để phân loại sentiment của 10.000 review tiếng Việt mỗi ngày, bạn đang dùng một hàm số phức tạp bậc cao để giải bài toán tuyến tính. Tương đương việc dùng xe tăng để đi chợ. Hiệu quả? Có. Hiệu quả về chi phí? Không bao giờ.

Chiến lược đúng đắn là phân rã toàn bộ workload thành các micro-task, sau đó gán mỗi micro-task cho mô hình có hàm chi phí-hiệu quả tối ưu trên đúng task đó. Đây chính là khái niệm model routing ở tầng nguyên thủy nhất.

3. Thực thể nguyên thủy thứ ba: Dữ liệu và ranh giới pháp lý (Data Boundary)

Khi dữ liệu của bạn được gửi đến một API endpoint, nó đi qua một chuỗi vật lý: network -> server -> GPU memory -> inference -> response. Ở mỗi bước, dữ liệu tồn tại ở một trạng thái vật lý cụ thể và chịu sự chi phối của một bộ luật cụ thể.

Mô hình proprietary hosted ở Mỹ (OpenAI, Anthropic) chịu ràng buộc của CCPA, SOC 2, và các chính sách data retention riêng. Mô hình Trung Quốc hosted ở Trung Quốc đại lục chịu ràng buộc của Luật An ninh Dữ liệu Trung Quốc 2021, trong đó Điều 36 cho phép cơ quan nhà nước yêu cầu truy cập dữ liệu khi liên quan đến an ninh quốc gia.

Đây không phải lý thuyết. Đây là ranh giới vật lý của dữ liệu mà bất kỳ doanh nghiệp nào xử lý dữ liệu nhạy cảm (tài chính, y tế, nhân sự) phải tính toán trước khi chọn mô hình.

4. Thực thể nguyên thủy thứ tư: Khả năng kiểm soát và thoát hiểm (Control & Escape Velocity)

Mỗi lần bạn build pipeline trên một mô hình cụ thể, bạn đang tăng năng lượng cần thiết để thoát khỏi quỹ đạo của mô hình đó (escape velocity). Prompts được tuned cho GPT-4o không hoạt động tốt trên Llama 4. Evaluation framework xây dựng cho Claude không áp dụng được cho DeepSeek.

Mức độ kiểm soát (control) tỷ lệ nghịch với mức độ phụ thuộc (lock-in). Open-source cung cấp mức kiểm soát cao nhất (host trên infra của bạn, fine-tune tùy ý, modify architecture) nhưng đòi hỏi năng lực kỹ thuật cao nhất. Proprietary cung cấp mức kiểm soát thấp nhất nhưng năng lực kỹ thuật yêu cầu cũng thấp nhất.

Key Takeaway: Bốn thực thể nguyên thủy, Chi phí thực tế, Phân rã tác vụ, Ranh giới dữ liệu, và Kiểm soát-đào thoát, là bộ lọc duy nhất bạn cần để đánh giá bất kỳ mô hình nào. Mọi tiêu chí khác đều là derivative của bốn biến số này.

---

III. Xây dựng lại mô hình: Kiến trúc nội dung và Pipeline nguyên tử

Từ bốn thực thể nguyên thủy, có thể xây dựng lại một framework ra quyết định (decision framework) hoàn chỉnh. Framework này không bắt chước bất kỳ framework có sẵn nào trên internet. Nó được xây dựng lại từ các biến số vật lý.

1. Kiến trúc tổng thể: Model Routing Architecture

Kiến trúc lý tưởng cho doanh nghiệp năm 2026 không phải là “chọn một mô hình”. Đó là xây dựng một routing layer nằm giữa ứng dụng và các model endpoints.

Routing layer này nhận vào mỗi request, phân loại task type (classification, generation, extraction, reasoning, coding), đánh giá sensitivity level của data, kiểm tra latency budget, sau đó chọn model endpoint tối ưu cho đúng request đó vào đúng thời điểm đó.

Hình dung đơn giản: đây là một switch thông minh trong mạng viễn thông, không phải một dây cáp cố định nối thẳng đến một trạm duy nhất.

2. Pipeline nguyên tử: Các bước từ raw workload đến model decision

Bước 1: Task Inventory (4-8 giờ) Liệt kê toàn bộ các use case AI hiện tại và dự kiến trong 12 tháng tới. Với mỗi use case, ghi lại: loại tác vụ (classification/generation/extraction/reasoning), ngôn ngữ đầu vào/đầu ra, khối lượng token ước tính mỗi tháng, yêu cầu latency (real-time hay batch), và mức độ nhạy cảm của dữ liệu.

Bước 2: Model Benchmarking trên Data của bạn (16-40 giờ) Đây là bước bị bỏ qua nhiều nhất và cũng là bước quan trọng nhất. Không benchmark trên MMLU hay HumanEval. Benchmark trên chính dữ liệu production của bạn với 100-500 samples đại diện cho mỗi task type.

Chạy cùng bộ samples trên 5-8 model candidates. Đo lường ba metrics: quality score (đánh giá bằng human evaluation hoặc LLM-as-judge với model khác), latency (P50 và P95), và cost per 1000 requests.

Bước 3: Router Design và Policy Engine (8-16 giờ) Xây dựng một rule-based router đơn giản trước. Ví dụ:

• Task là classification tiếng Việt, data không nhạy cảm -> dùng PhoGPT-7B self-hosted hoặc Qwen 3-8B
• Task là complex reasoning, data nhạy cảm -> dùng Claude 4 Sonnet hoặc GPT-4o với enterprise API
• Task là code generation -> dùng DeepSeek-Coder-V3 hoặc Codestral

Sau khi rule-based router hoạt động ổn định 2-4 tuần, mới cân nhắc chuyển sang ML-based router nếu volume đủ lớn để justify chi phí engineering.

Bước 4: Monitoring và Continuous Evaluation (ongoing) Thiết lập automated monitoring cho ba metrics: quality degradation (khi model provider thay đổi phiên bản ngầm), latency spike, và cost overrun. Có alert mechanism khi bất kỳ metric nào vượt ngưỡng.

Bước 5: Quarterly Migration Review (mỗi quý 4 giờ) Cứ mỗi quý, chạy lại bước 2 với updated benchmark set. Thị trường model thay đổi nhanh chóng. Mô hình tối ưu hôm nay có thể không còn tối ưu sau 3 tháng.

Key Takeaway: Pipeline gồm 5 bước, Task Inventory -> Model Benchmarking -> Router Design -> Monitoring -> Quarterly Review, là atomic unit của chiến lược model selection. Bỏ bước nào cũng tạo ra lỗ hổng chiến lược.

---

IV. Chiến lược thực thi chi tiết

Phần này là trọng tâm thực chiến, dành cho người trực tiếp ra quyết định và triển khai. Mỗi chiến lược đều được trình bày ở mức độ có thể bắt tay vào làm ngay trong tuần tới.

1. Chiến lược phân tầng mô hình theo mức độ nhạy cảm dữ liệu

Đây là chiến lược đầu tiên và quan trọng nhất vì nó quyết định toàn bộ kiến trúc. Chia dữ liệu của doanh nghiệp thành ba tầng:

Tier 1 - Public Data (dữ liệu công khai): Dữ liệu đã được publish hoặc không có bất kỳ giá trị cạnh tranh nào khi bị lộ. Ví dụ: nội dung marketing, blog posts, documentation công khai. Với tier này, ưu tiên chi phí là số một. Chạy trên bất kỳ mô hình nào rẻ nhất, bao gồm các model Trung Quốc hosted ở bất kỳ đâu.

Tier 2 - Internal Data (dữ liệu nội bộ): Dữ liệu có giá trị kinh doanh nhưng không phải bí mật thương mại. Ví dụ: báo cáo tài chính nội bộ, email nội bộ, meeting notes, customer support transcripts. Với tier này, cần cân bằng giữa chi phí và kiểm soát. Ưu tiên mô hình có thể self-host (open-source) hoặc proprietary API với cam kết data retention rõ ràng.

Tier 3 - Sensitive Data (dữ liệu nhạy cảm): Dữ liệu liên quan đến tài chính regulated, y tế, nhân sự cá nhân, bí mật thương mại, hoặc chiến lược kinh doanh. Với tier này, không được phép dùng model API bên thứ ba trừ khi có SOC 2 Type II certification và Data Processing Agreement ký kết rõ ràng. Giải pháp duy nhất là self-hosted open-source model trên private infrastructure.

Lưu ý từ chuyên gia: Tôi thấy 70% doanh nghiệp mà tôi tư vấn không có phân loại dữ liệu rõ ràng trước khi chọn mô hình. Họ gửi mọi thứ đến cùng một API endpoint. Đây là một liability pháp lý đang chờ phát nổ. Hãy phân loại trước, chọn model sau. Thứ tự không được đảo.

2. Chiến lược “Tiered Model Stack” cho từng loại tác vụ

Sau khi đã phân tầng theo dữ liệu, bước tiếp theo là xây dựng một model stack gồm nhiều lớp, mỗi lớp phục vụ một nhóm tác vụ cụ thể.

Lớp 1: Lightweight Classification và Extraction (chiếm 40-60% workload) Đây là các tác vụ đơn giản: phân loại văn bản, trích xuất thông tin có cấu trúc từ văn bản không cấu trúc, dịch thuật cơ bản. Mô hình lý tưởng: Qwen 3-8B hoặc Llama 4 Scout 17B (self-hosted), hoặc PhoGPT-7B cho tiếng Việt. Chi phí: gần bằng 0 nếu self-host trên GPU đã có sẵn.

Lớp 2: Content Generation và Summarization (chiếm 20-30% workload) Sinh nội dung marketing, tóm tắt báo cáo, draft email, viết documentation. Mô hình lý tưởng: Llama 4 Maverick 400B, Qwen 3-235B, hoặc DeepSeek-V4 (qua API từ nhà cung cấp uy tín). Chi phí: thấp hơn 5-10 lần so với proprietary.

Lớp 3: Complex Reasoning và Analysis (chiếm 10-20% workload) Phân tích chiến lược, coding phức tạp, multi-step reasoning, phân tích tài liệu dài. Mô hình lý tưởng: Claude 4 Sonnet, GPT-4o, Gemini 2.5 Pro. Chi phí: cao nhưng chỉ sử dụng cho các task thực sự cần năng lực reasoning bậc cao.

Lớp 4: Specialized Domain Tasks (chiếm 5-10% workload) Các task rất cụ thể như legal review, medical coding, financial analysis. Mô hình lý tưởng: fine-tuned open-source model trên domain-specific data, hoặc proprietary model với domain-specific prompting strategy.

Chiến lược thực thi: Bắt đầu bằng việc phân loại 100 request gần nhất vào bốn lớp trên. Nếu phát hiện rằng 50% request đang chạy trên lớp 3 trong khi đáng lẽ chỉ cần lớp 1, bạn đã tìm ra cơ hội tiết kiệm chi phí lớn nhất.

3. Chiến lược quản lý rủi ro vendor lock-in

Rủi ro lớn nhất khi phụ thuộc vào một model provider duy nhất là sudden degradation. Đây không phải giả thuyết. Tháng 3 năm 2026, một model provider lớn đã lặng lẽ thay đổi phiên bản model trên production endpoint mà không thông báo. Kết quả: hàng nghìn pipeline bị giảm chất lượng mà developer không biết nguyên nhân.

Chiến lược phòng ngừa:

a) Model Parity Testing (kiểm thử tương đương): Luôn maintain ít nhất 2 model cho mỗi lớp tác vụ. Khi model chính gặp vấn đề, switch sang model dự phòng trong vòng dưới 30 phút. Chi phí duy trì model dự phòng gần bằng 0 nếu dùng rule-based router.

b) Prompt Abstraction Layer: Không viết prompt trực tiếp cho bất kỳ model nào. Xây dựng một abstraction layer chuyển đổi prompt template thành format phù hợp với từng model. Khi cần switch model, chỉ cần thay đổi adapter, không cần viết lại toàn bộ prompt.

c) Evaluation Dataset Freeze: Lưu trữ một frozen evaluation dataset đại diện cho mỗi task type. Khi có bất kỳ thay đổi nào từ model provider, chạy evaluation trên frozen dataset để detect regression trong vòng 1 giờ.

Lưu ý từ chuyên gia: Chi phí phòng ngừa lock-in luôn nhỏ hơn chi phí bị lock-in thực sự. Tôi đã chứng kiến một công ty fintech phải chi 3 tuần engineering effort để migrate khỏi một proprietary model khi nhà cung cấp tăng giá 300%. Nếu họ đã có abstraction layer từ đầu, migration chỉ mất 2 ngày.

4. Chiến lược tối ưu chi phí inference theo thời gian thực

Giá inference thay đổi liên tục. Cùng một model, giá có thể chênh lệch 2-3 lần giữa các provider khác nhau vào cùng thời điểm. OpenRouter tồn tại chính vì lý do này, nó là marketplace cho inference capacity.

Chiến lược thực thi:

a) Multi-provider routing: Đăng ký API keys từ ít nhất 3 provider cho mỗi model chính. Router chọn provider nào có giá thấp nhất + latency thấp nhất tại thời điểm request.

b) Batch processing cho non-real-time tasks: Các task không cần phản hồi ngay (tổng hợp báo cáo hàng đêm, indexing tài liệu, training evaluation) nên được batch lại và chạy vào giờ thấp điểm, khi giá inference thường thấp 30-50%.

c) Context window management: Rất nhiều developer lãng phí token bằng cách gửi toàn bộ conversation history vào mỗi request. Xây dựng context compression layer, chỉ giữ lại các messages thực sự cần thiết cho context của request hiện tại. Tiết kiệm 30-60% token trên mỗi request là hoàn toàn khả thi.

d) Caching layer cho repeated queries: Nếu 15-20% request của bạn là query giống nhau hoặc gần giống nhau (ví dụ: câu hỏi FAQ, classification nhãn giống nhau), xây dựng semantic cache với cosine similarity threshold 0.95. Chi phí cache lookup gần bằng 0 so với chi phí inference.

5. Chiến lược xây dựng năng lực kỹ thuật nội bộ

Không chiến lược model selection nào hoạt động nếu doanh nghiệp không có năng lực kỹ thuật tối thiểu. Nhưng “năng lực kỹ thuật” không nhất thiết phải là một team AI 20 người.

Tối thiểu cần có:

• 1-2 engineer hiểu biết về LLM inference, API integration, và prompt engineering
• 1 data engineer có khả năng xây dựng monitoring pipeline
• Quyền truy cập vào cloud GPU instances (không cần dedicated cluster, dùng on-demand hoặc spot instances)

Chiến lược thực thi: Bắt đầu với hosted API (không self-host) để validate use case trước. Chỉ self-host khi volume đủ lớn để justify chi phí infrastructure (thường > 50M tokens/tháng với single model). Dùng managed inference platforms như Modal, Baseten, hoặc Together AI nếu muốn self-host mà không muốn quản lý GPU cluster.

Key Takeaway: Năm chiến lược thực thi, phân tầng dữ liệu, tiered model stack, quản lý lock-in, tối ưu chi phí thời gian thực, và xây dựng năng lực nội bộ, tạo thành một hệ thống hoàn chỉnh. Triển khai tuần tự theo thứ tự ưu tiên: phân tầng dữ liệu trước, tiered stack sau, rồi mới tối ưu chi phí.

---

V. Bảng so sánh và Đánh giá hiệu quả

Bảng 1: So sánh các giải pháp Model Routing cho doanh nghiệp

Giải pháp	Mô tả	Chi phí triển khai	Thời gian triển khai	Kiểm soát	Phù hợp với
Single proprietary API	Dùng 1 model proprietary cho mọi task	Thấp	1-3 ngày	Rất thấp	Startup nhỏ, prototype
Multi-proprietary routing	Route giữa nhiều proprietary model theo task	Trung bình	1-2 tuần	Thấp	Doanh nghiệp SME, 5-50 use cases
Hybrid (Proprietary + Open-source self-host)	Self-host open-source cho task đơn giản, proprietary cho task phức tạp	Trung bình-Cao	3-6 tuần	Cao	Doanh nghiệp lớn, data nhạy cảm
Full open-source self-host	Self-host toàn bộ, không dùng proprietary API	Cao	6-12 tuần	Rất cao	Tổ chức regulated (tài chính, y tế, chính phủ)
Managed inference marketplace (OpenRouter, Together, Fireworks)	Dùng aggregator để route giữa nhiều provider	Thấp	1-3 ngày	Trung bình	Developer, doanh nghiệp muốn flexibility nhanh

Bảng 2: Scorecard đánh giá chiến lược model selection

Tiêu chí	Điểm	Ghi chú
Khả năng giảm chi phí inference	8	Tiered routing giảm 40-70% chi phí so với single proprietary, tùy mức độ triển khai
Tính khả thi triển khai	5	Yêu cầu năng lực kỹ thuật trung bình, nhiều doanh nghiệp cần thuê ngoài giai đoạn đầu
Bảo vệ dữ liệu nhạy cảm	9	Tiered data classification + self-hosted cho Tier 3 là cách tiếp cận đúng đắn nhất hiện tại
Khả năng mở rộng quy mô	7	Architecture mở, thêm model mới chỉ cần thêm adapter, nhưng monitoring complexity tăng theo
Chịu được thay đổi thị trường	8	Multi-model approach giảm dependency vào bất kỳ nhà cung cấp đơn lẻ nào
Tốc độ giá trị mang lại	6	Giá trị rõ ràng sau 2-4 tuần triển khai, không phải immediate
Khả năng duy trì dài hạn	4	Yêu cầu continuous evaluation, quarterly review, và cập nhật liên tục. Không phải set-and-forget

Đánh giá tổng điểm Scorecard:

Tổng điểm: 47/70, tương đương trung bình 6.7/10 trên mỗi tiêu chí.

Theo thang đánh giá:

• 1-4 điểm: Thấp - Chiến lược chưa đủ trưởng thành, rủi ro cao
• 5-8 điểm: Khá - Chiến lược khả thi và mang lại giá trị, cần refinement liên tục
• 9-10 điểm: Xuất sắc - Chiến lược vượt trội, tạo competitive advantage rõ rệt

Nhận xét: Tổng điểm 6.7 xếp chiến lược này vào khoảng trung bình-khá. Đây là kết quả phản ánh chính xác bản chất thực tế: chiến lược model routing là cách tiếp cận đúng đắn về mặt lý thuyết và mang lại giá trị thực tế, nhưng nó đòi hỏi investment liên tục và không phải giải pháp “một lần là xong”. Điểm thấp nhất thuộc về tiêu chí khả năng duy trì dài hạn (4/10), đây chính xác là rủi ro lớn nhất mà doanh nghiệp cần nhận thức: nếu không dedicate resource cho continuous evaluation, toàn bộ hệ thống sẽ degraded theo thời gian khi các model providers thay đổi.

Key Takeaway: Không có chiến lược model selection nào đạt điểm 9-10. Bất kỳ ai hứa hẹn một giải pháp “hoàn hảo” cho bài toán model routing đều đang bán hàng, không đang tư vấn. Mục tiêu thực tế là đạt mức khá (5-8 điểm) và duy trì mức đó qua mỗi quý.

---

VI. Dự báo xu hướng tương lai và Kết luận

1. Dự báo 2026-2027

Xu hướng thứ nhất: Model routing sẽ trở thành default architecture. Đến cuối 2027, tôi dự báo 80% doanh nghiệp có trên 50 nhân viên sẽ sử dụng ít nhất 3 model khác nhau trong production. Single-model architecture sẽ trở thành exception, không phải norm.

Xu hướng thứ hai: Open-source tiếp tục chiếm lĩnh phân khúc chi phí-trung bình. Với Llama 4 đã ra mắt, Qwen 3 đang được adopt rộng rãi, và Mistral Large 3 sắp tới, thị phần của open-source trong tổng inference volume sẽ vượt 70% vào cuối 2027.

Xu hướng thứ ba: Self-hosting trở nên dễ dàng hơn. Chi phí GPU đang giảm theo đường cong Moore. Một NVIDIA B200 cluster đủ để chạy Llama 4 Maverick 400B với chi phí inference tính ra thấp hơn 80% so với API proprietary equivalent. Khi chi phí hardware giảm thêm 30-40% trong 18 tháng tới, bài toán self-host sẽ trở nên compelling hơn nữa.

Xu hướng thứ tư: Geopolitical fragmentation tăng tốc. EU sẽ ban hành thêm regulation về data sovereignty. Mỹ và Trung Quốc tiếp tục cạnh tranh AI supremacy. Doanh nghiệp sẽ buộc phải maintain model stacks cho từng jurisdiction khác nhau, tăng complexity nhưng cũng tăng opportunity cho các doanh nghiệp có chiến lược đúng đắn.

2. Kết luận

Con số 60% traffic từ open-source và mô hình Trung Quốc trên OpenRouter không phải là một anomaly. Đó là equilibrium mới. Thị trường inference đã trưởng thành đủ để người dùng không còn trả premium cho brand name. Họ trả tiền cho performance trên task cụ thể, với mức giá tương ứng.

Chiến lược model selection đúng đắn cho doanh nghiệp năm 2026 không phải là “chọn GPT hay Llama”, cũng không phải “chọn Mỹ hay Trung Quốc”. Đó là xây dựng một hệ thống routing thông minh, phân loại dữ liệu theo tầng nhạy cảm, gán mỗi task cho model tối ưu, quản lý rủi ro lock-in, và tối ưu chi phí inference theo thời gian thực.

Bốn thực thể nguyên thủy, chi phí thực tế, phân rã tác vụ, ranh giới dữ liệu, kiểm soát-đào thoát, là bộ lọc duy nhất bạn cần. Mọi tiêu chí khác là noise.

Pipeline năm bước, Task Inventory, Model Benchmarking, Router Design, Monitoring, Quarterly Review, là atomic unit của execution. Bỏ bước nào cũng tạo ra lỗ hổng.

Và quan trọng nhất: không có chiến lược model selection nào là set-and-forget. Thị trường thay đổi mỗi quý. Mô hình tối ưu hôm nay có thể không còn tối ưu ba tháng sau. Continuous evaluation không phải optional. Đó là chi phí vận hành bắt buộc, giống như tiền điện cho server.

Key Takeaway cuối cùng: 60% traffic đổ về open-source và mô hình Trung Quốc là tín hiệu rõ ràng nhất rằng doanh nghiệp đang tự tối ưu hóa hàm chi phí-hiệu quả. Câu hỏi không phải là “có nên dùng mô hình nguồn mở không?” mà là “bao nhiêu phần trăm workload của bạn đáng lẽ phải chạy trên mô hình nguồn mở từ lâu rồi?”.

---