Model Router: Chọn Model AI Đúng Cho Từng Task

Karify98 & Amy 🌸·
Cover Image for Model Router: Chọn Model AI Đúng Cho Từng Task
#llm#smart-routing#ai-agent#cost-optimization#multi-model

Bài Toán Chi Phí: Task Nhỏ Dùng Model Lớn = Đốt Tiền

Một agent trung bình xử lý hàng trăm request mỗi ngày. Nhưng không phải request nào cũng phức tạp. Hỏi "hello" bằng GPT-4o giống như lái Ferrari đi mua bún đậu — đúng, nhưng lãng phí.

Smart routing giải quyết bài toán đó: phân tích từng task, chuyển đến model phù hợp nhất về cả chất lượng lẫn chi phí.

Model Router Hoạt Động Thế Nào?

Router là lớp trung gian giữa request của người dùng và các model backend. Quy trình gồm ba bước:

Phân tích request — Router đánh giá độ phức tạp của task. Request đơn giản (dịch thuật, tóm tắt, trả lời câu hỏi fact) được phân loại thấp. Request phức tạp (viết code, phân tích logic, reasoning dài) được phân loại cao.

Chọn model — Dựa trên phân loại, router chọn model phù hợp. Task đơn giản → model nhỏ, giá rẻ. Task phức tạp → model lớn, chất lượng cao.

Dispatch và fallback — Request được gửi đến model đã chọn. Nếu model đó timeout hoặc trả về lỗi, router tự động chuyển sang model backup.

Ba Phong Cách Routing

1. Rule-Based Routing

Đơn giản nhất. Developer định nghĩa rule tĩnh: request chứa từ khóa "code" → GPT-4o. Request dưới 100 token → Gemini Flash. Request từ user tier free → model nhỏ nhất.

Ưu điểm: dự đoán được, dễ debug, không tốn thêm chi phí inference. Nhược điểm: cứng nhắc, không thích ứng với context.

2. Classifier-Based Routing

Dùng một model nhỏ (hoặc classifier truyền thống) để phân loại request trước khi dispatch. Model classifier đọc input, output: task_type, complexity_score, suggested_model.

Ưu điểm: linh hoạt hơn rule-based, học được từ dữ liệu thực tế. Nhược điểm: thêm một lớp inference, tăng latency nhẹ.

3. LLM-as-Judge Routing

Dùng chính LLM lớn để quyết định task này nên gửi cho model nào. Prompt router: "Task này phức tạp mức nào? Nên dùng model nào?".

Ưu điểm: chính xác nhất, hiểu nuance. Nhược điểm: chi phí cao (vì dùng model lớn để routing), latency tăng.

OpenRouter: Unified API Cho Multi-Model

OpenRouter cung cấp một endpoint duy nhất truy cập hơn 100 model từ các provider khác nhau. Thay vì tích hợp API riêng của OpenAI, Anthropic, Google, developer chỉ cần gọi một API và chỉ định model qua tham số.

// Ví dụ gọi OpenRouter với model cụ thể
const response = await fetch("https://openrouter.ai/api/v1/chat/completions", {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${OPENROUTER_API_KEY}`,
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    model: "anthropic/claude-sonnet-4",  // hoặc "google/gemini-flash"
    messages: [{ role: "user", content: prompt }]
  })
});

Kết hợp OpenRouter với router logic cho phép developer switch model mà không đổi code phía client.

LiteLLM: Proxy Server Cho Multi-Provider

LiteLLM hoạt động như proxy server. Developer cung cấp config chứa nhiều API key từ các provider, LiteLLM unified thành một API chuẩn. Ưu điểm hơn OpenRouter: self-hosted, kiểm soát data, không phụ thuộc bên thứ ba.

Thực Tế: Route Nào Cho Task Nào?

Loại task Model gợi ý Lý do
Tóm tắt văn bản, dịch thuật Gemini Flash, GPT-4o-mini Đơn giản, cần tốc độ
Trả lời câu hỏi fact Claude Haiku, Gemini Flash Không cần reasoning sâu
Viết code đơn giản Claude Sonnet, GPT-4o Cần chính xác syntax
Viết code phức tạp, debugging Claude Opus, GPT-4o Cần reasoning logic
Phân tích dữ liệu, so sánh GPT-4o, Claude Sonnet Cần phân tích chi tiết
Reasoning toán học, logic o3-mini, Claude Opus Cần chain-of-thought

Bảng trên chỉ mang tính tham khảo. Tùy domain và dataset thực tế, kết quả có thể khác.

Chi Phí Giảm Được Bao Nhiêu?

Con số thực tế từ một số team đang dùng smart routing: chi phí inference giảm 40-70% so với luôn dùng frontier model. Lý do đơn giản: 60-70% request là task đơn giản không cần model lớn.

Với startup đang burn cash vì AI API, đây là con số đáng để nghiêm túc cân nhắc.

Bắt Đầu Đơn Giản

Không cần framework phức tạp. Bắt đầu với rule-based routing:

  1. Phân tích 100 request gần nhất của ứng dụng
  2. Phân loại: đơn giản (70%), trung bình (20%), phức tạp (10%)
  3. Viết rule: đơn giản → model nhỏ, phức tạp → model lớn
  4. Đo lại chất lượng và chi phí sau một tuần

Khi có đủ dữ liệu, nâng cấp lên classifier-based hoặc LLM-as-judge khi cần.

Bài viết này là phần 31 của series AI For Developers — hướng dẫn thực tế cho developer muốn dùng AI hiệu quả trong công việc hàng ngày.