Model nào tốt nhất?" — production đã trả lời khác

Dữ liệu routing từ hàng trăm nghìn team cho thấy: câu hỏi đúng không phải chọn model nào, mà là chọn model nào cho từng loại call.

"Model nào tốt nhất?" — production đã trả lời khác

"Bao nhiêu model là đủ cho production?" — câu hỏi này lặp đi lặp lại ở mọi architecture review mình từng ngồi. Đáp án mặc định thường là: chọn một model xịn nhất, optimize xung quanh nó, rồi chạy. Nhưng dữ liệu thật từ hơn 200 nghìn team routing qua Vercel AI Gateway — lớp proxy điều phối request đến nhiều provider cùng lúc — vừa công bố một bức tranh ngược lại hoàn toàn.

Team ở mức 10 triệu request trở lên dùng trung bình 35 model khác nhau. Không phải thử nghiệm. Là kiến trúc chuẩn.

Dữ liệu nào vừa lên bàn?

Vercel vừa publish báo cáo production index dựa trên bảy tháng traffic thật qua AI Gateway — hàng chục nghìn tỷ token, hàng trăm model. Đây không phải benchmark phòng lab hay survey tự khai. Đây là dữ liệu routing thật từ ứng dụng đang phục vụ người dùng cuối.

Vài con số đáng chú ý:

• Anthropic dẫn đầu chi phí (61% spend tháng 4/2026), nhưng Google dẫn đầu volume (38% token). Hai bảng xếp hạng, hai người thắng.
• 59% tổng token thuộc về agentic workload — tải xử lý kiểu agent, tức model gọi tool rồi quay lại nhiều vòng thay vì trả lời một lượt. Con số này tăng gấp đôi chỉ trong sáu tháng.
• 3.5% request hoàn thành nhờ fallback — chuyển sang provider khác khi provider đầu lỗi hoặc rate-limit.
• Team nhỏ (1K–10K request) dùng trung bình 3 model. Team lớn (10M+) dùng 35.

Spend đi một đường, volume đi một nẻo

Điều nhiều team đang hiểu sai: nghĩ rằng provider có nhiều request nhất là provider "chiến thắng." Thực tế, spend và volume đo hai thứ khác hẳn nhau — và chúng phân tách theo mức rủi ro của từng call.

Dịch sang ngôn ngữ vận hành: Anthropic thắng ở những call mà sai một phát là tốn tiền thật — coding agent, reasoning phức tạp, quyết định ảnh hưởng business. Google thắng ở những call sai cũng không chết ai — summarization nhanh, consumer chat, phân loại intent. Cùng một khách hàng, cùng một ứng dụng, nhưng hai tầng hoàn toàn khác nhau.

Nghĩ như một hệ thống tòa án: mỗi vụ việc được phân công đến đúng cấp xét xử phù hợp. Án dân sự nhỏ không cần lên tòa tối cao, và ngược lại — vụ trọng không thể xử ở tòa hòa giải. Routing model trong production hoạt động y hệt: request nào stakes cao thì đẩy lên model đắt, request nào nhẹ thì chạy model rẻ. Không có chuyện một "thẩm phán" xử hết mọi loại vụ.

Vercel gọi pattern này là "spend follows the cost of being wrong" — chi phí đổ về nơi mà sai lầm đắt nhất. B2B trả gấp đôi per-token so với B2C, không phải vì model khác nhau, mà vì hậu quả của câu trả lời sai khác nhau.

Khung "giá của sai" — thứ đáng mang về

Đây là framework mà builder nên áp dụng ngay, bất kể bạn dùng gateway nào hay tự build routing:

Bước 1: Phân loại call theo hậu quả sai.

Giả sử team bạn 6 người đang build một SaaS cho khách enterprise ở Việt Nam. Bạn có ít nhất ba tầng call:

• Tầng cao: Agent viết code commit thẳng vào repo, hoặc gửi email cho khách hàng. Sai = mất tiền, mất uy tín. → Model frontier, chấp nhận giá cao.
• Tầng trung: Summarize ticket, phân loại intent, suggest autocomplete. Sai = user khó chịu nhưng sửa được ngay. → Model nhanh, rẻ.
• Tầng nền: Embedding cho search, OCR screenshot, extract metadata. Sai = ảnh hưởng gián tiếp, khó nhận ra ngay. → Model chuyên dụng hoặc open-weight.

Bước 2: Thiết kế fallback như tòa phúc thẩm.

Dữ liệu Vercel cho thấy 3.5% request cần fallback, nhưng xét theo chi phí thì con số là 4.9% — vì request đắt tiền lại hay fail hơn (context dài hơn, nhiều bước hơn, dễ timeout hơn). Nếu bạn không có fallback cho tầng cao, bạn đang chấp nhận mất tiền ở chính những call quan trọng nhất.

Ví dụ thực tế: một team edtech ở Hà Nội chạy agent chấm bài tự luận. Ban đầu họ dùng một model duy nhất. Khi provider gặp sự cố 2 tiếng vào giờ cao điểm thi, toàn bộ pipeline đứng. Sau đó họ thêm fallback route sang provider thứ hai cho riêng tầng chấm bài (tầng cao) — những call summarize feedback (tầng trung) thì để fail gracefully vì học sinh có thể chờ.

Bước 3: Coi routing là unit kiến trúc, không phải afterthought.

Team 35 model không ngồi chọn thủ công từng request. Họ có routing graph — đồ thị định tuyến — với classifier rẻ ở đầu phân loại intent, rồi model frontier cho reasoning, embedding model cho retrieval, vision model cho screenshot. Mỗi node trong graph là swappable. Khi một provider tăng giá hoặc sập, traffic tự chuyển trong vài giờ thay vì vài tuần migration.

Phần nên lướt qua

"One endpoint, all your models" nghe hấp dẫn nhưng bản thân gateway không giải quyết bài toán routing cho bạn. Gateway cung cấp ống dẫn — bạn vẫn phải quyết định nước chảy đi đâu. Đừng nhầm việc có gateway với việc có chiến lược multi-model.

Leaderboard real-time — Vercel publish bảng xếp hạng model theo production data. Hay để tham khảo, nhưng đừng dùng nó như nguồn duy nhất để chọn model. Dữ liệu tổng hợp từ 200K team có workload khác team bạn. Model thắng ở aggregate chưa chắc thắng ở use case cụ thể của bạn.

"Agentic is eating everything" — đúng là 59% token thuộc agentic workload, nhưng đó là token, không phải request. Agent tốn token gấp 2.6 lần chat thường vì mỗi tool call là một round-trip tính tiền. Nếu bạn đang tính chuyển mọi thứ sang agent "cho hiện đại," hãy tính lại bill trước.

Nếu chỉ mang về một thứ

Câu hỏi "model nào tốt nhất" đã hết hạn sử dụng ở production. Câu hỏi đúng là: "Call nào của mình đắt nhất khi sai, và mình đang route nó đến đâu?"

Không cần 35 model ngay ngày đầu. Nhưng nếu bạn đang chạy mọi thứ qua một model duy nhất với cùng một mức giá — bạn đang trả giá premium cho những call không cần premium, và thiếu bảo vệ cho những call thật sự quan trọng. Bắt đầu bằng việc phân ba tầng, thêm một fallback route cho tầng cao, rồi đo lại cost. Phần còn lại tự rõ.

---

Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng