Blog / Series AI Agents Thực Chiến

Model Routing 2026: đội ngũ mạnh không còn đặt cược vào một model duy nhất

Vấn đề gốc: vì sao “chọn một model tốt nhất” đang trở thành tư duy lỗi thời

Trong 12–18 tháng đầu của làn sóng LLM, câu hỏi phổ biến nhất là: model nào mạnh nhất? Câu hỏi này hợp lý ở giai đoạn thị trường còn chênh lệch lớn. Nhưng sang 2026, logic đó bắt đầu lỗi thời vì ba thay đổi xảy ra cùng lúc.

Thứ nhất, khoảng cách benchmark giữa nhóm frontier model ở nhiều bài test thực dụng đã thu hẹp đáng kể. Điều đó không có nghĩa mọi model giống nhau. Nó có nghĩa là việc trả tiền cao nhất không còn tự động đem lại quyết định tốt nhất cho mọi request.

Thứ hai, chênh lệch kinh tế suy luận vẫn rất lớn. Một request routing sai có thể khiến hệ thống dùng model premium cho công việc mà model rẻ hơn xử lý đủ tốt. Ở quy mô vài nghìn hoặc vài trăm nghìn request mỗi ngày, sai số kiến trúc này nhanh chóng biến thành chi phí thật.

Thứ ba, workload của hệ AI ngày nay không còn thuần “chat”. Nó bao gồm tool calling, agent loops, browser actions, long-context review, structured extraction, code execution, approval flows. Mỗi loại workload lộ ra một điểm mạnh và điểm yếu khác nhau của model. Bài Agent Reliability 2026 đã chỉ ra vì sao độ tin cậy đang là chiến trường mới; model routing chính là cách biến nhận thức đó thành kiến trúc.

Nói ngắn gọn, cuộc chơi đang dịch từ benchmark race sang workload allocation. Đội ngũ mạnh không hỏi “model số 1 là gì?” mà hỏi “request nào xứng đáng đi vào model đắt nhất, và request nào không cần?”

Model routing là gì, và nó khác “fallback đơn giản” ở đâu?

Model routing là lớp quyết định model nào sẽ xử lý một request, dựa trên loại tác vụ, mức rủi ro, độ khó, ngân sách, latency target, chính sách dữ liệu và xác suất lỗi có thể chấp nhận.

Nhiều đội ngũ tưởng mình đã có routing khi thực chất chỉ có fallback: model A lỗi thì chuyển sang model B. Cách này hữu ích, nhưng còn rất nông. Routing trưởng thành hơn phải trả lời ít nhất năm câu hỏi:

1. Phân loại workload: đây là tóm tắt, trích xuất, reasoning nhiều bước, viết code hay điều phối agent?
2. Chấm mức quan trọng: sai ở đây chỉ gây khó chịu, hay gây thiệt hại vận hành/tài chính/pháp lý?
3. Ràng buộc thực thi: cần tool-use ổn định, structured output cứng, hay context rất dài?
4. Giới hạn kinh tế: ngân sách trên mỗi request là bao nhiêu? có long-context surcharge không?
5. Hành vi sau kết quả: nếu confidence thấp thì escalate sang model mạnh hơn, hay trả về cho con người duyệt?

Nói cách khác, routing không chỉ là chọn model. Nó là chọn đường đi của một request trong toàn bộ hệ suy luận. Điều này khá giống cách workflow engine quyết định bước nào chạy tự động, bước nào chờ approval, bước nào cần memory hoặc retry.

Ba kiểu routing phổ biến trong 2026

• Static routing theo loại tác vụ: ví dụ extraction đi model rẻ, coding đi model mạnh hơn.
• Dynamic routing theo độ khó: request được một classifier hoặc router model chấm điểm trước khi quyết định đích đến.
• Cascaded routing: model rẻ xử lý vòng 1; chỉ những case confidence thấp hoặc sai schema mới được đẩy lên model premium.

Trong hệ agent, routing còn liên quan chặt tới tool calling và MCP. Có model viết hay nhưng gọi tool không ổn định. Có model reasoning tốt nhưng chậm. Có model rất rẻ nhưng dễ trượt format. Nếu không định tuyến đúng, độ mạnh của model không cứu được kiến trúc.

Use case end-to-end: trợ lý vận hành doanh nghiệp với ba tầng model

Hãy lấy một ví dụ thực tế hơn các demo benchmark. Một doanh nghiệp triển khai trợ lý AI nội bộ để xử lý ba loại việc:

1. đọc email/ticket đến và phân loại,
2. trích dữ liệu có cấu trúc để đẩy vào CRM/helpdesk,
3. xử lý case khó hơn như đối chiếu chính sách, tóm tắt hồ sơ dài hoặc chuẩn bị draft phản hồi cho nhân sự vận hành.

Nếu dùng duy nhất một model premium cho toàn bộ luồng, hệ thống có thể cho chất lượng khá ổn, nhưng chi phí sẽ đội lên nhanh chóng ở các việc lặp lại và đơn giản. Nếu dùng duy nhất một model giá rẻ, hệ thống sẽ gặp lỗi ở các case mơ hồ, nhiều ngoại lệ hoặc cần tool-use dài hơi.

Một kiến trúc routing hợp lý có thể chia thành ba tầng:

Tầng 1: model tiết kiệm cho tác vụ thể tích lớn, rủi ro thấp

Email ngắn, ticket chuẩn, extraction field quen thuộc, chuẩn hóa đầu vào. Mục tiêu ở đây là throughput cao và chi phí thấp. Nếu output có schema rõ, việc chấm lỗi cũng dễ hơn.

Tầng 2: model trung cấp cho tác vụ cần suy luận vừa phải

Case có ngữ cảnh dài hơn, cần so với tri thức nội bộ, cần tóm tắt đa nguồn, hoặc cần tạo draft theo mẫu. Router chỉ đẩy request lên tầng này khi tầng 1 không đạt confidence hoặc khi classifier nhận ra case có biến thiên.

Tầng 3: model premium cho case đắt giá hoặc agent workflow nhiều bước

Đây là nơi xử lý review hợp đồng, bug phức tạp, planning nhiều bước, điều phối tool, browser run, hoặc các case mà sai sót gây chi phí cao. Tầng này thường gắn với approval, log sâu và tiêu chuẩn audit chặt hơn.

Lúc này giá trị của routing không chỉ nằm ở việc giảm bill. Nó còn làm rõ ranh giới niềm tin trong hệ thống: phần nào được phép tự chạy, phần nào cần escalate, phần nào phải có con người kiểm tra. Đây cũng là điểm giao nhau giữa routing với bài workflow, memory, approval.

Kiến trúc hệ thống: lớp router phải biết gì, giữ state ở đâu?

Một router tốt không thể chỉ là vài câu if/else. Nó cần được thiết kế như một lớp điều hành. Tối thiểu nên có sáu phần.

1. Input normalization

Router chỉ quyết định tốt khi input sạch. Hệ thống cần chuẩn hóa metadata như loại người dùng, kênh vào, token ước tính, mức nhạy cảm dữ liệu, số tool cần dùng, SLA mong muốn.

2. Workload classifier

Có thể là rule engine, lightweight model, hoặc kết hợp cả hai. Mục tiêu không phải hiểu request ở mức hoàn hảo, mà là nhận ra nó thuộc nhóm vấn đề nào. Sai ở bước này sẽ làm toàn bộ routing lệch hướng.

3. Policy layer

Không phải request nào cũng được đi đến bất kỳ provider nào. Một số luồng có ràng buộc residency, compliance, hoặc cấm gửi dữ liệu nhạy cảm ra ngoài. Nếu policy không đứng trước router, tối ưu chi phí có thể vô tình phá yêu cầu bảo mật. Bài Agent Security 2026 đặc biệt liên quan ở điểm này.

4. Decision engine

Đây là phần kết hợp workload, policy, ngân sách, latency, confidence và lịch sử run để chọn model đích. Ở hệ tốt, quyết định này được log lại như một sự kiện có thể audit: vì sao request A đi model X thay vì Y.

5. Retry / escalate / downgrade graph

Routing trưởng thành không đi theo một đường thẳng. Nếu model đầu ra sai schema, hệ có thể retry cùng model với prompt repair. Nếu confidence thấp, có thể escalate lên model mạnh hơn. Nếu request không quan trọng và đang gặp throttling ở tier cao, có thể downgrade tạm sang model rẻ hơn. Phần này giống một state machine hơn là một lời gọi API đơn lẻ.

6. Evaluation và feedback loop

Không có router nào tối ưu ngay từ ngày đầu. Hệ thống cần đo blended cost, latency, schema error rate, escalation rate, human override rate, task success rate theo từng tuyến định tuyến. Nếu không đo theo route, đội ngũ sẽ không biết “đắt ở đâu” và “hỏng ở đâu”.

Trade-off và failure mode thường bị bỏ qua

Model routing nghe rất hấp dẫn trên slide. Nhưng nếu thiết kế hời hợt, nó chỉ biến một điểm lỗi thành nhiều điểm lỗi hơn.

1. Router sai còn nguy hiểm hơn model sai

Nếu classifier đánh giá thấp độ khó của request, hệ thống có thể gửi case quan trọng vào model rẻ, rồi trả về một câu trả lời “nghe hợp lý” nhưng sai bản chất. Lỗi này khó phát hiện hơn lỗi timeout hoặc schema fail.

2. Chi phí orchestration có thể ăn mất phần tiết kiệm

Nhiều đội chỉ nhìn vào giá token của model chính mà quên chi phí router model, retries, reformat prompts, validation passes, logging, cache misses và escalations. Nếu cascade quá nhiều tầng, tổng chi phí có thể không đẹp như dự kiến.

3. Latency bị kéo dài bởi quyết định quá thông minh

Mỗi lớp phân loại, self-check và escalation đều tăng độ trễ. Với workload người dùng chờ trực tiếp, latency budget phải là ràng buộc hạng nhất, không phải chuyện tối ưu sau cùng.

4. Drift của workload nhanh hơn drift của benchmark

Benchmark công khai thay đổi chậm hơn dữ liệu thực tế trong doanh nghiệp. Một router được tinh chỉnh tốt cho tháng trước có thể xuống cấp khi loại ticket, loại tài liệu hoặc hành vi người dùng thay đổi. Vì vậy router cũng cần được đánh giá định kỳ như model.

5. Failure mode phổ biến

• Cheap-first bias: ham tiết kiệm đến mức mọi request đều bị ép vào tier thấp.
• Premium-default bias: sợ sai nên gần như request nào cũng leo lên tier cao, khiến routing tồn tại trên giấy nhưng không tạo giá trị kinh tế.
• Hidden schema fragility: model rẻ làm đúng nội dung nhưng sai định dạng, kéo theo lỗi dây chuyền ở bước sau.
• Tool mismatch: router chọn model reasoning tốt nhưng tool-use kém ổn định cho workflow agent.
• Policy leak: route sang provider không phù hợp với ràng buộc dữ liệu vì policy không được đặt trước decision engine.
• No learning loop: hệ định tuyến sai lặp đi lặp lại nhưng không có cách hấp thụ phản hồi để sửa.

Checklist triển khai production

Nếu đội ngũ đang cân nhắc đưa model routing vào stack AI/agent, checklist sau thực dụng hơn nhiều so với việc tranh luận leaderboard.

Giai đoạn 1: xác định nơi routing thực sự tạo giá trị

• Chỉ bắt đầu khi có nhiều loại workload khác nhau hoặc volume đủ lớn để chi phí trở thành vấn đề.
• Nếu sản phẩm mới có một workflow duy nhất, một model duy nhất thường vẫn đơn giản và an toàn hơn.
• Đặt mục tiêu rõ: giảm blended cost, tăng success rate, hay tách dữ liệu nhạy cảm theo policy.

Giai đoạn 2: dựng tuyến định tuyến tối thiểu

• Bắt đầu với 2–3 tuyến rõ ràng, không cần ma trận quá phức tạp.
• Dùng rule đơn giản trước khi dùng router model cầu kỳ.
• Log toàn bộ quyết định route từ ngày đầu.

Giai đoạn 3: gắn validation sau output

• Kiểm tra schema, confidence, policy, PII và dấu hiệu hallucination trước khi chấp nhận kết quả.
• Đừng đồng nhất “model trả lời được” với “request đã xử lý xong”.
• Với agent workflow, tách rõ plan, act, verify.

Giai đoạn 4: đo theo route, không đo gộp

• Theo dõi chi phí, latency và tỷ lệ thành công cho từng tuyến.
• Đo escalation rate để biết router đang quá liều hay quá nhát.
• Đo human-review rate cho các case rủi ro cao.

Giai đoạn 5: chỉ tự động hóa mạnh khi đã hiểu failure modes

• Giữ các case rủi ro ở chế độ draft/approval trước khi cho execute tự động.
• Định kỳ review các request bị route sai để tinh chỉnh classifier và policy.
• Chuẩn bị fallback ở cấp provider, không chỉ ở cấp model name.

Insight cuối cùng: model đang bị hàng hóa hóa, còn routing mới là lợi thế hệ thống

Nếu chỉ nhìn thị trường qua các thông báo model mới, rất dễ nghĩ lợi thế bền nhất vẫn nằm ở việc “chọn đúng model chiến thắng”. Nhưng ở góc nhìn triển khai, lợi thế thật đang chuyển dần sang nơi khác: khả năng phân bổ đúng loại trí tuệ cho đúng loại công việc, đúng mức chi phí, đúng ràng buộc và đúng mức kiểm soát.

Đó là lý do model routing đang nóng lên rất nhanh trong 2026. Nó phản ánh một sự trưởng thành của thị trường: doanh nghiệp không còn mua “AI mạnh nhất” một cách trừu tượng; họ bắt đầu xây hệ thống phân phối năng lực suy luận như một lớp hạ tầng.

Với AI agents, điều này còn quan trọng hơn. Agent hiếm khi chỉ gọi model một lần. Nó đi qua planning, tool use, verification, retry, approval và memory. Khi đó, câu hỏi không phải là model nào thông minh nhất, mà là mỗi bước nên được giao cho loại model nào để toàn hệ đạt chất lượng, chi phí và độ tin cậy chấp nhận được.

Model rồi sẽ tiếp tục mạnh lên. Nhưng trong phần lớn hệ production, routing mới là nơi kiến trúc bắt đầu có IQ.