Đừng trả tiền Opus cho mọi việc: mô hình nhỏ + leo thang theo độ tin cậy, rẻ hơn 4 lần mà gần như không mất độ chính xác
Cuối tháng, bạn mở hóa đơn API: hệ thống phân loại ticket chạy vài chục nghìn request mỗi ngày, và mọi request — kể cả ticket nhìn lướt là biết nhóm nào — đều đi qua Claude Opus 5.5.
Nếu 70–80% ca là dễ, vì sao phải trả giá frontier cho chúng? Bài này trình bày pattern cụ thể: decision model rẻ như Jev quyết định trước, chỉ leo thang những ca nó không chắc lên Opus — kèm số liệu từ hai thí nghiệm độc lập và bốn bước áp dụng.
Vì sao gọi model lớn cho mọi request là lãng phí?
Chi phí LLM tăng theo volume, không theo độ khó
Ca dễ có đáp án rõ ràng: ticket “quên mật khẩu” thuộc nhóm hỗ trợ tài khoản. Ca khó thì mơ hồ, thiếu dữ liệu, cần suy luận nhiều bước — nhưng model frontier tính phí như nhau cho cả hai loại.
Chênh lệch là rất lớn. Trên thí nghiệm của Hightouch, một quyết định tốn 3,86 USD cho mỗi 1.000 ca khi chạy hoàn toàn bằng Opus 5.5, trong khi Jev chạy một mình chỉ tốn 0,05 USD — chênh lệch khoảng 77 lần.
Latency cũng là chi phí ẩn
Opus 5.5 mất 2,2 giây mỗi identity trong thí nghiệm Hightouch, Jev chỉ mất 0,15 giây. Trên Banking77, latency p50 của Opus 5 là 2.266 ms so với 175 ms của Jev 1.13 — gấp khoảng 13 lần.
Jev là gì? Decision model khác LLM thông thường ở đâu?
Jev — decision model System One của TypeSafe
Jev, decision model đầu tiên của TypeSafe, ra mắt ngày 15/9/2026. Nó không sinh text: nhận một trạng thái cùng một câu hỏi có kiểu, trả về đáp án có kiểu kèm xác suất và confidence từ 0 đến 1.
Jev có bốn primitive: Choice chọn một trong tối đa 255 lựa chọn, Score chấm điểm theo thang định sẵn, Noul trả xác suất yes/no, Box đọc ảnh (cần Jev 1.14). Với cascade trong bài này, Choice là quan trọng nhất.
Gọi Jev qua OpenRouter Decisions API: POST https://openrouter.ai/api/alpha/decisions, model id typesafe/jev-1.13 (bản 1.14 mới nhất), chỉ cần một OpenRouter API key. Giá đã xác minh: 0,042 USD cho mỗi một triệu input token, output miễn phí.
Decision model phù hợp bài toán nào — và không phù hợp bài toán nào
Decision model phù hợp với bài toán có đáp án hữu hạn và kiểm chứng được: phân loại ticket, chấm điểm đúng/sai, review theo checklist, triage mức độ ưu tiên. Ngược lại, Jev không phù hợp với task cần reasoning dài, sinh văn bản, sáng tạo, hoặc đáp án mở.
Ai nên dùng pattern này?
Lập trình viên xây hệ thống dùng LLM ở quy mô lớn, IT manager quản hóa đơn AI, AI builder chạy agent hay LLM-as-judge với volume cao — khi volume cao, task lặp lại, đáp án có kiểu, và sai sót ở tầng rẻ được tầng frontier sửa lại.
Kiến trúc model cascade: Jev quyết định trước, Opus chỉ xử lý ca khó
Các thành phần chính của hệ thống cascade
Hai tầng, một cổng, một vòng phản hồi. Tầng một là Jev: nhận câu hỏi có kiểu, trả đáp án kèm confidence. Cổng confidence là điểm điều khiển chi phí duy nhất. Tầng hai là Claude Opus 5.5, chỉ nhận ca Jev không chắc và quyết định cuối. Vòng log ghi confidence, quyết định, chi phí và latency mỗi ca để hiệu chỉnh ngưỡng.
Ngưỡng leo thang là tham số vận hành, không phải hằng số của model. Tỉ lệ leo thang chính là cần gạt chi phí: chi phí hệ thống bằng chi phí Jev cộng với tỉ lệ leo thang nhân với chi phí Opus.
Luồng dữ liệu và luồng điều khiển
Request đi vào kèm câu hỏi có kiểu và tập đáp án. Jev trả đáp án cùng confidence: cao thì chấp nhận ngay, thấp thì leo thang lên Opus. Không có vòng lặp lại Jev sau Opus — Opus là điểm dừng cuối.
Sơ đồ kiến trúc duy nhất trong bài
flowchart TD
A["Request<br/>Câu hỏi có kiểu + tập đáp án"] --> B["Jev — decision model rẻ<br/>$0,042 / 1M input token<br/>Trả đáp án + confidence 0–1"]
B --> C{"Confidence gate<br/>Ngưỡng leo thang"}
C -->|"Confidence cao<br/>~78% ca (Hightouch test dễ)"| D["Chấp nhận ngay<br/>Trả đáp án của Jev"]
C -->|"Confidence 30–90% / thấp<br/>22% ca leo thang (Hightouch)"| E["Claude Opus 5.5<br/>Chỉ xử lý ca leo thang<br/>Quyết định cuối"]
E --> F["Kết quả cuối<br/>Đáp án + tầng đã quyết định"]
D --> F
F --> G["Log: confidence + chi phí<br/>+ latency + tỉ lệ leo thang"]
G -->|"Hiệu chỉnh ngưỡng định kỳ"| CĐa số traffic dừng ở Jev, chỉ thiểu số tốn tiền Opus; ngưỡng là điểm điều khiển chi phí duy nhất.
Phụ thuộc và giới hạn kỹ thuật
Cần OpenRouter API key; Decisions API vẫn ở giai đoạn alpha. Model id phải ghi đúng phiên bản: Jev 1.13 là bản đã được đo trên Banking77, Jev 1.14 là bản mới nhất; Hightouch không nêu phiên bản Jev nên không được áp số 1.13 cho số liệu của họ. Jev không sinh text và không reasoning dài; confidence của nó là ranking signal tốt nhưng không phải calibrated probability, theo chính OpenRouter.
Số liệu thực tế: rẻ hơn 4 lần chỉ đúng trong điều kiện nào?
Con số “rẻ hơn 4 lần” chỉ có ý nghĩa khi đi kèm tên test, task và ngưỡng — hai thí nghiệm dưới đây trình bày trong hai bảng riêng.
Thí nghiệm Hightouch — LLM judge cho identity resolution (test dễ)
Hightouch (đăng 2026-11-04, cập nhật 2026-11-06) dùng LLM làm judge để phát hiện over-merging trong identity resolution: 1.000 identity từ dữ liệu giả lập PseudoPeople, một nửa là over-merge.
| Cấu hình | Accuracy | Thời gian / ca | Chi phí / 1.000 |
|---|---|---|---|
| Opus 5.5 một mình | 99,0% | 2,2 s | $3,86 |
| Jev một mình (cutoff 60%) | 95,7% | 0,15 s | $0,05 |
| Hybrid Jev → Opus (leo thang 30–90%, 22% ca) | 98,8% | 0,63 s | $0,88 |
| Hybrid Luna → Opus (để so sánh) | 98,5% | 0,30 s | $0,33 |
Phép chia 3,86 / 0,88 cho ra 4,39 lần — nguồn gốc của con số “rẻ hơn 4 lần”. Nhưng nó chỉ đúng trên test dễ này.
Cùng thí nghiệm Hightouch trên test khó — tỉ lệ tiết kiệm co lại
Trên test khó — chỉ các ca tricky với typo và over-merge giống nhau như sinh đôi — hybrid Jev chỉ còn rẻ hơn 1,83 lần (5,39 / 2,94), nhưng accuracy nhỉnh hơn Opus một mình: 95,3% so với 95,1%. Chi tiêu tự co giãn theo độ khó của dữ liệu.
| Cấu hình | Accuracy | Thời gian / ca | Chi phí / 1.000 |
|---|---|---|---|
| Opus 5.5 một mình | 95,1% | 2,6 s | $5,39 |
| Jev một mình (cutoff 60%) | 89,1% | 0,15 s | $0,06 |
| Hybrid Jev → Opus | 95,3% | 1,56 s | $2,94 |
| Hybrid Luna → Opus | 91,6% | 0,70 s | $1,15 |
Test độc lập thứ hai — OpenRouter Banking77 (task khác, model khác)
OpenRouter chạy test ngày 22/9/2026 trên Banking77: 3.080 câu hỏi hỗ trợ khách hàng ngân hàng, phân vào 77 intent. Model ở đây là Claude Opus 5, không phải 5.5, chạy với reasoning OFF, structured output và prompt caching bật.
| Cấu hình | Accuracy | Latency p50 | Chi phí / 1.000 |
|---|---|---|---|
| Opus 5 một mình | 84,4% | 2.266 ms | $2,42 |
| Jev 1.13 một mình | 81,0% | 175 ms | $0,11 |
| Cascade ngưỡng 0,90 (75,9% ở lại Jev) | 84,0% | — | $0,69 |
| Cascade ngưỡng 0,99 | 84,3% | — | $1,13 |
Ở ngưỡng 0,90, cascade đạt 84,0% — chỉ kém Opus 0,4 điểm — với chi phí 0,69 USD, rẻ hơn 3,5 lần. Nâng ngưỡng lên 0,99 chỉ đổi thêm 0,3 điểm accuracy nhưng chi phí tăng 64% lên 1,13 USD. Lưu ý: bảng cascade là upper bound vì dùng đúng tập test đã đo accuracy.
Đọc số liệu đúng cách — calibration quan trọng hơn accuracy tuyệt đối
Đây là insight quan trọng nhất. Lỗi của Jev tập trung ở vùng confidence thấp, gần 50% — những ca nó tự nhận là không chắc — nên cổng confidence bắt được đúng những ca cần leo thang. Luna thì ngược lại: chạy một mình nó chính xác hơn Jev trên test dễ (97,3% so với 95,7%), nhưng nó quá tự tin — lỗi rơi vào bucket confidence 90–100%, nơi cổng confidence không bắt được. Khi chọn model rẻ làm tầng đầu, tiêu chí quyết định là đường cong calibration, không phải accuracy đơn lẻ.
Hướng dẫn áp dụng model cascade trong 4 bước
Bước 0 — Điều kiện tiên quyết
Cần bốn thứ: tập dữ liệu có nhãn (vài trăm mẫu trở lên); bài toán diễn đạt được thành câu hỏi có kiểu với tập đáp án hữu hạn; OpenRouter API key và ngân sách baseline chạy toàn bộ bằng Opus; cơ chế log từng ca. Không có phần mềm nào để cài đặt — đây là pattern gọi API, không phải deploy ứng dụng. Phần này mình chưa chạy thử Jev trực tiếp, chỉ đối chiếu tài liệu.
Bước 1 — Định nghĩa câu hỏi có kiểu và tập đáp án
Viết câu hỏi dạng Choice (tối đa 255 lựa chọn), Score hay Noul. Đáp án phải rời rạc, kiểm chứng được: 77 intent như Banking77, chấm đúng/sai kèm tiêu chí, triage “khẩn cấp / cao / trung bình / thấp” với định nghĩa rõ từng mức. Đáp án mơ hồ là lỗi phổ biến nhất: các lựa chọn chồng lấn nhau khiến Jev trả confidence thấp cho mọi ca, tỉ lệ leo thang tiến về 100%.
Bước 2 — Chạy Jev trên mẫu có nhãn, vẽ đường cong accuracy/cost theo ngưỡng
Gọi Decisions API (POST https://openrouter.ai/api/alpha/decisions, model typesafe/jev-1.13) trên mẫu có nhãn, ghi confidence và đúng/sai từng mẫu (pseudo-code dưới đây chỉ mô tả pattern, không phải payload API theo nghĩa đen):
for sample in labelled_samples:
result = call_decisions(model="typesafe/jev-1.13",
question=typed_question, options=answer_set, state=sample.input)
log(sample.id, result.answer, result.confidence, result.usage_cost)
for threshold in [0.60, 0.80, 0.90, 0.99]:
escalated = [s for s in logged if s.confidence < threshold]
report(threshold, escalation_rate=len(escalated) / len(logged))Output kỳ vọng: response trả về đáp án có kiểu, confidence 0–1, và usage.cost phản ánh mức giá 0,042 USD/1 triệu input token. Kiểm tra ba điểm đó trước khi đi tiếp.
Bước 3 — Chọn ngưỡng leo thang theo ngân sách và mức sai sót chấp nhận được
Chọn ngưỡng trên đường cong của chính bạn — không copy ngưỡng 0,90 của Banking77 hay khoảng 30–90% của Hightouch, vì hai con số đó đúng cho dữ liệu của họ. Ngưỡng là điểm cân bằng giữa chi phí và accuracy, và phải chọn lại mỗi khi dữ liệu thay đổi.
Bước 4 — Triển khai, log và hiệu chỉnh định kỳ
Log mọi quyết định; theo dõi tỉ lệ leo thang hàng tuần và kiểm tra accuracy định kỳ. Khi phân phối dữ liệu trôi, hiệu chuẩn lại ngưỡng. Lỗi thường gặp: copy ngưỡng mà không đo lại; đáp án mơ hồ; không log; dùng Jev cho task reasoning hay sinh text; nhầm phiên bản model. Rollback: cascade nên đứng sau một feature flag — hạ ngưỡng xuống hoặc tắt cascade, chuyển toàn bộ sang Opus cho tới khi hiệu chuẩn lại xong.
Đánh giá kỹ thuật: ưu điểm, nhược điểm và vận hành
Ưu điểm của cascade theo confidence
Tiết kiệm lớn trên ca dễ: 4,39 lần trên test dễ Hightouch, 3,5 lần trên Banking77 (ngưỡng 0,90), accuracy chỉ kém Opus 0,2–0,4 điểm. Latency giảm: hybrid 0,63 giây so với 2,2 giây của Opus một mình.
Nhược điểm và giới hạn
Cascade thêm một tầng và một cổng ngưỡng — thêm phức tạp vận hành và nghĩa vụ hiệu chuẩn. Accuracy không vượt được trần của tầng frontier nếu cổng bắt sai: ca Jev tự tin nhưng sai sẽ không bao giờ lên Opus. Decisions API vẫn ở alpha; Jev 1.13 và 1.14 có thể khác nhau về hành vi và giá.
Bảo mật và dữ liệu khi gọi Decision API
Đừng gửi PII, bí mật kinh doanh hay dữ liệu y tế/pháp lý nhạy cảm nếu chưa rà soát điều khoản lưu trữ của nhà cung cấp. Chỉ gửi đúng trường cần thiết, tách log nội dung thô khỏi log confidence/kết quả, quản lý API key như secret.
Hiệu năng và khả năng mở rộng
Jev p50 175 ms so với Opus 2.266 ms trên Banking77; hybrid 0,63 giây so với Opus 2,2 giây mỗi identity trên test dễ Hightouch. Chi phí biên mỗi ca ở tầng rẻ gần như không đáng kể; điểm nghẽn chuyển sang tầng Opus khi tỉ lệ leo thang tăng (test khó: 1,56 giây/ca). Không có benchmark throughput hay QPS tự đo.
Vận hành: giám sát gì sau khi triển khai?
Dashboard tối thiểu: tỉ lệ leo thang, accuracy mẫu kiểm tra định kỳ, chi phí/1.000 request, latency p50/p95 từng tầng, phân phối confidence theo thời gian. Cảnh báo quan trọng nhất là tỉ lệ leo thang tăng đột biến — tín hiệu dữ liệu đã đổi phân phối hoặc ngưỡng đã lệch. Theo mình, escalation rate chính là cảm biến drift miễn phí.
So sánh cascade Jev → Opus với các lựa chọn cùng phạm vi
| Phương án | Accuracy | Chi phí / 1.000 | Latency | Độ phức tạp | Khi nào phù hợp |
|---|---|---|---|---|---|
| Opus 5.5 một mình | Cao nhất test dễ (99,0%) | $3,86 | 2,2 s/ca | Thấp nhất | High-stakes |
| Jev một mình | 95,7% / 81,0% | $0,05 / $0,11 | 0,15 s | Thấp | Ca dễ chiếm đa số, sai sót rẻ |
| Hybrid Jev → Opus | 98,8% / 84,0% | $0,88 / $0,69 | 0,63 s | Trung bình | Nhiều ca dễ + có dữ liệu hiệu chuẩn |
| Hybrid Luna → Opus | 98,5% / 91,6% | $0,33 / $1,15 | 0,30 s | Trung bình | Minh họa: calibration kém thì cascade kém |
| Model tầm trung cố định | Giữa Jev và Opus | Cố định mọi ca | Cố định | Thấp | Không muốn vận hành cổng ngưỡng |
Cascade thắng khi có nhiều ca dễ và có dữ liệu hiệu chuẩn. Model tầm trung cố định thắng khi bạn không muốn vận hành cổng ngưỡng. Opus một mình thắng khi bài toán high-stakes.
Khi nào KHÔNG nên dùng model cascade?
Đừng dùng cho các ca high-stakes không chấp nhận sai sót: y tế, pháp lý, tài chính nhạy cảm — một ca Jev tự tin nhưng sai sẽ không bao giờ leo thang. Đừng dùng khi Jev chưa được hiệu chuẩn trên dữ liệu của mình, khi task cần reasoning dài, hoặc khi dữ liệu production quá khác tập hiệu chuẩn. Và đừng dùng khi volume quá nhỏ: tiền tiết kiệm được không bù nổi chi phí vận hành.
Ứng dụng thực tế của pattern cascade
Doanh nghiệp — phân loại ticket và chấm điểm LLM-as-judge
Trực tiếp nhất là phân loại ticket hỗ trợ, đúng như Banking77 với 77 intent: phần lớn ticket rõ ràng, chỉ thiểu số mơ hồ cần model lớn. Thứ hai là LLM-as-judge: dùng model chấm đầu ra của agent. Bài viết về iFixAi — kiểm toán độc lập AI agent thuộc cùng họ “dùng model để chấm model” nhưng ở góc kiểm toán, còn bài này là góc tiết kiệm chi phí.
AI workflow — review code và triage ở quy mô lớn
Chấm review code theo checklist có kiểu, triage pull request và issue, lọc ca rõ ràng trước khi đưa lên frontier review. Ca leo thang lên Opus cũng chính là ca đáng để con người xem lại trước tiên.
DevOps và IT admin — tự động hóa phân loại sự cố
Phân loại alert và log, xác định mức độ ưu tiên sự cố: ca chắc chắn tự động xử lý theo playbook, ca mơ hồ leo thang lên model lớn hoặc người trực. Bài viết về Orca — chạy nhiều AI coding agent song song đặt vấn đề quy mô khi chạy nhiều agent song song, còn cascade là một cách giữ chi phí đó trong tầm kiểm soát.
Homelab — chạy cascade với ngân sách cố định
Với tác vụ lặp lại hàng ngày như gắn tag hay phân loại nội dung, đặt trần chi phí mỗi tháng bằng ngưỡng leo thang: khi chi tiêu tiến gần trần, hạ ngưỡng chấp nhận xuống thay vì vượt ngân sách.
Bài học rút ra
- Tiết kiệm lớn nhất không đến từ model rẻ, mà từ việc không trả giá frontier cho ca dễ — cổng confidence mới tạo ra tiết kiệm.
- “Rẻ hơn 4 lần” có điều kiện: 4,39 lần chỉ đúng trên test dễ của Hightouch, test khó chỉ còn 1,83 lần, Banking77 là 3,5 lần — luôn báo cáo tiết kiệm kèm tên test, task và ngưỡng.
- Chọn tầng rẻ bằng calibration, không bằng accuracy: lỗi của Jev tập trung ở vùng confidence thấp nên cổng ngưỡng bắt được.
- Confidence không phải xác suất đã hiệu chuẩn — ngưỡng copy từ bài báo khác là ngưỡng sai; phải đo lại trên dữ liệu của mình.
- Tỉ lệ leo thang vừa là cần gạt chi phí, vừa là cảm biến phát hiện dữ liệu đã trôi trước khi accuracy tụt.
Kết luận — ai nên dùng cascade, ai không, và bước tiếp theo
Cascade phù hợp với hệ thống có volume lớn, task quyết định có kiểu lặp lại, có dữ liệu có nhãn để hiệu chuẩn, và chấp nhận sai sót nhỏ ở tầng rẻ. Nó không phù hợp với bài toán high-stakes, task reasoning hay sinh text, hoặc khi chưa có dữ liệu hiệu chuẩn.
Bước tiếp theo: lấy 300–500 mẫu có nhãn của chính mình, chạy Jev qua Decisions API, vẽ đường cong accuracy và chi phí theo ngưỡng, rồi mới quyết định ngưỡng production. Đừng triển khai chỉ dựa trên số của Hightouch hay Banking77 — ngưỡng đúng chỉ đo được trên dữ liệu của bạn.
Ghi chú phạm vi kiểm chứng
Ngày kiểm tra: 2026-11-08. Đã xác minh trực tiếp bài viết của Hightouch (đăng 2026-11-04, cập nhật 2026-11-06) và bài test Banking77 của OpenRouter (test chạy 22/9/2026). Số liệu là thí nghiệm của các bên đăng tải trên một task duy nhất mỗi bên — identity resolution với dữ liệu giả lập PseudoPeople đối với Hightouch, phân loại intent Banking77 đối với OpenRouter — và chưa được kiểm chứng độc lập trên task identity resolution. Phần này mình chưa tự chạy Jev, nên không có benchmark tự đo trong bài. Endpoint Decisions API, model id typesafe/jev-1.13 và mức giá 0,042 USD/1 triệu input token đã xác minh khớp nhau qua tài liệu OpenRouter và TypeSafe. Opus trên Banking77 chạy với reasoning OFF, structured output và prompt caching bật. Các con số chi phí theo ngưỡng là cấu hình vận hành, không phải benchmark hiệu năng tuyệt đối.
Tài liệu tham khảo
- Hightouch — LLM Judges for Identity Resolution at 4x Lower Cost: https://hightouch.com/blog/llm-judges-identity-resolution
- OpenRouter — Is Jev as Accurate as Frontier Models at Classification?: https://openrouter.ai/blog/insights/jev-vs-claude-opus-5-classification/
- OpenRouter — What Is Jev?: https://openrouter.ai/blog/insights/what-is-jev/
- OpenRouter — Jev documentation: https://openrouter.ai/docs/guides/community/jev
- Dryhurst — Jev and the OpenRouter Decisions API: https://www.dryhurst.io/articles/jev-openrouter-decisions-api/
Bình luận
Bình luận được duyệt trước khi hiển thị.Đang tải bình luận…
Để lại bình luận