Routing LLM — playbook cắt chi phí không cắt chất lượng

Routing LLM — playbook cắt chi phí không cắt chất lượng

Hơn nửa prompt của bạn có thể dùng model rẻ hơn. Playbook dựng routing layer trong một buổi chiều — giảm cost mà giữ nguyên output.

Bạn đang trả giá model Pro cho mọi request — kể cả câu "format lại cái JSON này giúm"?

Tuần trước mình ngồi review hóa đơn API cho một team 4 người ở Sài Gòn. Kết quả: hơn nửa số request gửi lên model lớn là những prompt đơn giản — tóm tắt email, dịch một đoạn ngắn, trích xuất vài trường dữ liệu. Toàn tác vụ mà model nhỏ hơn xử lý tốt ngang ngửa, chi phí thấp hơn cả chục lần.

Vấn đề không nằm ở model. Vấn đề là thiếu một routing layer — lớp phân luồng quyết định prompt nào đi model nào.

Bài này là playbook giúp bạn dựng lớp routing đó trong một buổi chiều. Mình dùng NadirClaw làm ví dụ thực hành, nhưng tư duy áp dụng cho bất kỳ stack nào.

Routing layer giải quyết bài toán gì?

Hiểu nôm na: routing layer là huấn luyện viên quyết định ai vào sân cho từng pha bóng. Prompt đơn giản — giao cho model nhẹ (ví dụ Gemini Flash). Prompt phức tạp — đẩy lên model nặng (Gemini Pro). Thay vì để tiền đạo ngôi sao chạy cả 90 phút mọi trận, bạn luân chuyển đội hình theo nhu cầu thực tế.

Cơ chế phía sau: một local classifier (bộ phân loại chạy cục bộ) nhận prompt đầu vào, chấm điểm complexity, rồi route sang model phù hợp. Toàn bộ việc phân loại xảy ra trên máy bạn — không tốn thêm API call nào.

Trung tâm của cơ chế này là centroid vector — vector tâm cụm. NadirClaw giữ hai centroid: một cho nhóm "simple", một cho nhóm "complex". Mỗi prompt mới được embed rồi so cosine similarity (độ tương đồng hướng) với hai centroid đó để quyết định tier.

Checklist: 4 điều kiện trước khi bắt tay

Trước khi cài bất kỳ package nào, trả lời 4 câu hỏi:

  1. Bạn có ít nhất 2 tier model rõ ràng? Ví dụ: Gemini Flash cho tier đơn giản, Gemini Pro cho tier phức tạp. Nếu team chỉ xài một model duy nhất, routing chưa có đất diễn.
  1. Bạn biết prompt nào đang ngốn chi phí nhất? Kiểm tra log. Nếu phần lớn request là tác vụ đơn giản, routing sẽ cắt được khoản đáng kể. Nếu hầu hết prompt đều phức tạp, lợi ích sẽ nhỏ.
  1. Bạn đã có baseline chất lượng chưa? Routing chỉ đáng làm khi bạn đo được: model nhỏ trả lời prompt đơn giản có chấp nhận được không? Nếu chưa đo — bước đầu tiên là benchmark, không phải cài routing.
  1. Team sẵn sàng monitor routing accuracy? Routing không phải "cài xong quên". Classifier có thể phân loại sai khi prompt pattern thay đổi theo thời gian.

Đủ 4 điều kiện → đi tiếp.

Ba bước dựng routing layer

Bước 1 — Cài và test classifier cục bộ

pip install nadirclaw sentence-transformers
nadirclaw classify "Summarize this email in 2 sentences"

Chạy lệnh trên không cần API key. NadirClaw trả về tier (simple/complex), confidence score, và model được đề xuất. Thử với 10–15 prompt thật từ production log của team — xem classifier phân loại có khớp trực giác của bạn không.

Confidence threshold (ngưỡng tin cậy) là biến quan trọng nhất ở bước này. Mặc định NadirClaw đặt threshold vừa phải. Nếu nhiều prompt bị route sai, nâng threshold lên — chấp nhận tốn thêm chút chi phí để giữ chất lượng.

Bước 2 — Map tier vào model cụ thể

Quyết định: tier simple → model nào, tier complex → model nào.

| Tier | Model ví dụ | Chi phí tương đối |
|------|-------------|---------------------|
| Simple | Gemini Flash | ~1x |
| Complex | Gemini Pro | ~10–15x |

Nếu team dùng OpenAI, logic tương tự: GPT-4o mini cho simple, GPT-4o cho complex. Routing layer không khóa vào vendor nào.

Bước 3 — Chạy proxy server và đo kết quả

nadirclaw serve --port 8000

NadirClaw chạy một proxy tương thích OpenAI API. Code hiện tại của bạn chỉ cần đổi base URL sang localhost:8000 — không sửa logic gọi API. Proxy nhận request, classify, rồi forward sang model phù hợp.

Sau 1–2 ngày chạy, export log và tính: bao nhiêu phần trăm request được route xuống tier rẻ hơn? Chất lượng output có giảm không? Giả sử team bạn gửi 1.000 request/ngày và 65% được route sang Flash — khoản tiết kiệm sẽ hiện rõ trên hóa đơn tháng tới.

Bẫy hay gặp — và cách né

Bẫy 1: Tin classifier tuyệt đối. Một team mình biết cài routing xong rồi... quên luôn. Ba tuần sau mới phát hiện classifier đang gửi prompt phân tích tài chính dài 2.000 từ xuống Flash, vì centroid vector mặc định chưa được calibrate cho domain tài chính. Cách né: chạy routing song song với model chính ít nhất 1 tuần, so sánh output trước khi chuyển hoàn toàn.

Bẫy 2: Quá ham tiết kiệm. Hạ confidence threshold xuống thấp nhất để route tối đa xuống model rẻ — rồi user bắt đầu phàn nàn. Giống đội bóng rút hết cầu thủ chính để giữ thể lực, rồi thua ngay hiệp phụ. Giữ threshold ở mức mà tỷ lệ route sai dưới 5% là vùng an toàn.

Bẫy 3: Không có fallback. Proxy server chết → request phải tự động fall về model mặc định, không phải trả lỗi 500 cho user. Đặt timeout và fallback route ngay từ đầu.

Bước tiếp — routing chỉ là entry point

Khi đã quen, mở rộng theo ba hướng:

Ngoài NadirClaw, một số giải pháp open-source khác cũng hỗ trợ routing logic tương tự — đáng xem qua nếu bạn cần tích hợp sâu hơn vào stack hiện tại.

Dịch sang tiếng người: cắt chi phí LLM không bắt đầu bằng tìm model rẻ hơn — mà bằng ngừng gửi prompt sai chỗ.

---

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

Nguồn tham khảo