·

Một trong những sai lầm phổ biến nhất khi triển khai AI agent vào sản phẩm là dùng đúng một model — thường là model mạnh nhất, đắt nhất — cho mọi tác vụ, từ việc phân loại email đơn giản đến việc viết code refactor phức tạp. Đây giống như việc thuê một kiến trúc sư trưởng để đi dán tem thư: công việc vẫn hoàn thành, nhưng chi phí bỏ ra hoàn toàn không tương xứng với giá trị nhận lại.

Model selection (lựa chọn model) không phải là quyết định kỹ thuật một lần rồi thôi — nó là một chiến lược tối ưu hóa chi phí (cost optimization) liên tục, cần được thiết kế như một phần kiến trúc của hệ thống, không phải như một tùy chọn cấu hình được set một lần và bỏ quên. Bài viết này sẽ đi vào chi tiết cách phân loại model theo tier, cách ánh xạ tác vụ vào tier phù hợp, cách xây dựng cơ chế cascading (thác đổ tầng) giữa các model, và cách đo lường hiệu quả của chiến lược lựa chọn model trong thực tế vận hành.

Bức Tranh Toàn Cảnh Về Các Tier Model

Khi nói về "chọn model", nhiều người chỉ nghĩ đến việc chọn giữa vài cái tên quen thuộc như GPT-4, Claude, Gemini. Nhưng để tối ưu chi phí một cách có hệ thống, ta cần nhìn các model theo tier (tầng) — nhóm các model theo mức năng lực, độ trễ (latency) và đơn giá token, thay vì theo nhà cung cấp. Cách phân tier này giúp việc ra quyết định trở nên nhất quán, dễ tái sử dụng, và dễ tự động hóa bằng router.

Về bản chất, thị trường LLM (Large Language Model) hiện nay phân bố theo ba tier rõ rệt, mỗi tier có một "hồ sơ" (profile) riêng về năng lực và giá.

Tier 1: Model Đầu Bảng (Frontier/Flagship Models)

Đây là nhóm model mạnh nhất mà một nhà cung cấp đang có tại một thời điểm — ví dụ như Claude Opus, GPT-4.1/GPT-5 flagship, Gemini Ultra/Pro bản cao cấp nhất. Đặc điểm chung của nhóm này:

  • Năng lực lý luận (reasoning) vượt trội: xử lý tốt các bài toán nhiều bước, có tính mơ hồ (ambiguous), cần suy luận đa lớp hoặc kết hợp nhiều domain kiến thức.
  • Context window lớn: thường hỗ trợ hàng trăm nghìn đến hàng triệu token, phù hợp với các tác vụ cần "nhớ" toàn bộ codebase, tài liệu dài, hoặc lịch sử hội thoại phức tạp.
  • Đơn giá cao nhất: input/output token của Tier 1 thường đắt gấp 10-30 lần so với Tier 3, và gấp 3-8 lần so với Tier 2.
  • Độ trễ cao hơn: model lớn thường sinh token chậm hơn, ảnh hưởng đến trải nghiệm real-time nếu dùng sai chỗ.

Ví dụ thực tế: một agent làm nhiệm vụ review pull request phức tạp, cần hiểu kiến trúc hệ thống, đánh giá trade-off giữa các thiết kế, và đưa ra nhận xét mang tính chiến lược — đây là bài toán xứng đáng dùng Tier 1.

Tier 2: Model Cân Bằng (Balanced/Mid-Tier Models)

Đây là nhóm model được thiết kế để cân bằng giữa năng lực, tốc độ và chi phí — ví dụ Claude Sonnet, GPT-4o mini (bản giữa), Gemini Flash bản pro. Đặc điểm:

  • Năng lực đủ tốt cho phần lớn tác vụ nghiệp vụ hàng ngày: viết code chuẩn, tóm tắt tài liệu, trả lời câu hỏi dựa trên tài liệu (RAG), sinh nội dung có cấu trúc.
  • Đơn giá hợp lý: thường bằng 1/5 đến 1/10 so với Tier 1, nhưng chất lượng đầu ra chỉ giảm nhẹ với các tác vụ không quá phức tạp.
  • Tốc độ nhanh hơn đáng kể, phù hợp cho các luồng tương tác cần phản hồi nhanh.

Trong thực tế vận hành sản phẩm, đây thường là tier "mặc định" — tier mà đa số request nên rơi vào, nếu hệ thống được thiết kế tốt.

Tier 3: Model Kinh Tế/Nhỏ (Economy/Edge Models)

Nhóm model nhỏ, nhanh, rẻ — ví dụ Claude Haiku, GPT-4o-mini/nano, Gemini Flash-Lite, hoặc các model mã nguồn mở tự host như Llama 3 8B, Mistral 7B, Phi-3. Đặc điểm:

  • Giá rẻ nhất, đôi khi chỉ bằng 1/20 đến 1/50 so với Tier 1.
  • Tốc độ sinh token rất nhanh, độ trễ thấp — phù hợp cho các tác vụ cần chạy real-time với volume lớn.
  • Năng lực lý luận hạn chế: dễ mắc lỗi với các tác vụ yêu cầu suy luận nhiều bước, dễ "hallucinate" (bịa thông tin) khi task vượt quá khả năng.
  • Nhiều model trong tier này còn có thể tự host (self-hosted) trên hạ tầng riêng, giúp loại bỏ hoàn toàn chi phí theo token và chuyển sang chi phí hạ tầng cố định — một lựa chọn đáng cân nhắc khi volume đủ lớn.

Mẹo

  • Đừng chỉ nhìn vào bảng giá "per-token" — hãy tính cost-per-successful-task (chi phí trên mỗi tác vụ hoàn thành đúng). Một model Tier 3 rẻ nhưng phải retry 3 lần vì lỗi có thể đắt hơn một lần gọi Tier 1 thành công ngay.
  • Lập một bảng so sánh nội bộ (internal model card) ghi lại: giá input/output, context window (kích thước ngữ cảnh tối đa model xử lý được), độ trễ trung bình, và điểm benchmark nội bộ theo từng loại tác vụ của chính team mình — benchmark công khai của nhà cung cấp không phải lúc nào cũng phản ánh đúng use case của bạn.
  • Theo dõi sát các bản cập nhật giá và model mới — thị trường LLM thay đổi giá rất nhanh, một model "mid-tier" hôm nay có thể rẻ ngang Tier 3 sau vài tháng nhờ cải tiến hạ tầng của nhà cung cấp.
  • Với các tác vụ có thể self-host, hãy tính toán điểm hòa vốn (break-even point) giữa chi phí API theo token và chi phí vận hành GPU/server — thường chỉ có lợi khi volume đủ lớn và ổn định.

Khung Ánh Xạ Tác Vụ Sang Model (Task-to-Model Mapping Framework)

Có tier rồi, câu hỏi tiếp theo là: làm sao biết tác vụ nào nên đi với tier nào? Đây là lúc cần một framework ánh xạ rõ ràng, thay vì để mỗi developer tự quyết theo cảm tính. Nguyên tắc cốt lõi: độ phức tạp của tác vụ và độ chấp nhận rủi ro (risk tolerance) của kết quả quyết định tier, không phải "muốn dùng model xịn cho chắc".

Một framework thực dụng thường đánh giá tác vụ theo 4 tiêu chí:

  1. Độ phức tạp lý luận: task chỉ cần pattern matching / phân loại đơn giản, hay cần suy luận đa bước?
  2. Độ nhạy với sai sót (error tolerance): nếu model trả lời sai, hậu quả là gì — không ai để ý, hay ảnh hưởng trực tiếp đến khách hàng/production?
  3. Yêu cầu về độ trễ: task cần phản hồi tức thì (real-time chat) hay có thể chạy batch/async?
  4. Volume: task này chạy 10 lần/ngày hay 10.000 lần/ngày? Volume cao khuếch đại tác động của việc chọn sai tier.

Nhóm Tác Vụ Tier 3 (Model Kinh Tế)

Đây là các tác vụ có độ phức tạp lý luận thấp, error tolerance cao (sai một chút cũng không nghiêm trọng, hoặc có bước kiểm tra sau), và thường có volume rất lớn. Ví dụ cụ thể trong pipeline agentic:

  • Phân loại intent (intent classification): xác định user đang hỏi về "billing", "technical support" hay "sales" để route sang luồng xử lý phù hợp.
  • Trích xuất trường dữ liệu có cấu trúc (structured extraction) từ text đã có format rõ ràng, ví dụ lấy ngày/giờ/số tiền từ email xác nhận đơn hàng.
  • Tóm tắt ngắn (short summarization) cho log, comment, hoặc changelog không đòi hỏi văn phong tinh tế.
  • Kiểm tra định dạng, validate input trước khi đưa vào bước xử lý nặng hơn — ví dụ agent kiểm tra xem một đoạn code có đúng cú pháp ngôn ngữ được khai báo không.
  • Sinh tên biến, docstring ngắn, comment code đơn giản trong các tác vụ auto-complete.

Ví dụ prompt thực tế cho Tier 3 (intent classification):

System: You are a routing classifier. Read the user message and return
ONLY one of these labels: BILLING, TECH_SUPPORT, SALES, OTHER.
Do not explain your reasoning. Output the label only.

User: "My invoice from last month shows double charge, can you help?"

Task này không cần lý luận sâu — một model nhỏ, rẻ, nhanh xử lý tốt với accuracy gần như tương đương model lớn, vì bản chất là bài toán phân loại có tập nhãn hữu hạn.

Nhóm Tác Vụ Tier 2 (Model Cân Bằng)

Đây là "vùng an toàn" cho phần lớn tác vụ nghiệp vụ: đủ phức tạp để cần khả năng ngôn ngữ và lý luận tốt, nhưng chưa đến mức cần sức mạnh đầu bảng. Ví dụ:

  • Viết code chức năng cụ thể (function-level code generation): viết một hàm xử lý logic nghiệp vụ rõ ràng, có test case sẵn để verify.
  • Tóm tắt tài liệu dài, đa chủ đề, cần giữ đúng ngữ cảnh và văn phong.
  • Trả lời câu hỏi dựa trên tài liệu nội bộ (RAG) cho các câu hỏi nghiệp vụ thông thường.
  • Sinh nội dung marketing, email, báo cáo theo template có sẵn nhưng cần văn phong tự nhiên.
  • Code review cấp độ style/convention — kiểm tra coding convention, đặt tên biến, phát hiện code smell cơ bản.

Nhóm Tác Vụ Tier 1 (Model Đầu Bảng)

Chỉ nên dùng Tier 1 khi tác vụ thực sự cần, vì đây là nơi ngân sách token "bốc hơi" nhanh nhất nếu dùng sai chỗ. Các trường hợp chính đáng:

  • Thiết kế kiến trúc hệ thống, đánh giá trade-off phức tạp — cần model hiểu được nhiều ràng buộc đồng thời và đưa ra khuyến nghị có lý luận rõ ràng.
  • Debug lỗi phức tạp, đa tầng (multi-layer) — cần truy vết logic qua nhiều file, nhiều service, nhiều lớp abstraction.
  • Lý luận pháp lý, tài chính, y tế có tính rủi ro cao, nơi sai sót có thể gây hậu quả nghiêm trọng.
  • Task cần khả năng "hiểu ý ngầm" (nuance) cao — ví dụ phân tích phản hồi khách hàng mang tính mỉa mai, hoặc soạn nội dung nhạy cảm về mặt chính sách/thương hiệu.
  • Orchestration cấp cao trong multi-agent system — model đóng vai "planner" điều phối các agent con, cần khả năng lập kế hoạch và tự sửa lỗi kế hoạch khi cần.

Mẹo

  • Viết ra một bảng ánh xạ tác vụ → tier cụ thể cho sản phẩm của bạn, review định kỳ (mỗi quý) vì độ phức tạp của tác vụ có thể thay đổi khi sản phẩm phát triển thêm tính năng.
  • Khi không chắc một tác vụ thuộc tier nào, hãy thử nghiệm A/B: chạy song song trên Tier 2 và Tier 3, so sánh accuracy trên một tập test case đại diện, trước khi quyết định.
  • Đừng quên yếu tố volume nhân với đơn giá: một tác vụ tưởng nhỏ (ví dụ tóm tắt comment) nhưng chạy hàng triệu lần/tháng có thể là chi phí lớn hơn nhiều so với một tác vụ Tier 1 chạy vài trăm lần/tháng.
  • Đối với các tác vụ biên giới (borderline) giữa hai tier, ưu tiên nghiêng về tier thấp hơn và bù lại bằng cơ chế cascading (sẽ nói ở phần sau) — vừa an toàn vừa tiết kiệm.

Mô Hình Cascading và Fallback

Một trong những kỹ thuật tối ưu chi phí hiệu quả nhất là cascading (thác đổ tầng): bắt đầu bằng model rẻ nhất có thể, và chỉ "leo tầng" lên model mạnh hơn khi cần thiết. Đây khác với việc chọn tier tĩnh cho một loại task — cascading là cơ chế động (dynamic), quyết định theo từng request cụ thể dựa trên độ khó thực tế hoặc độ tin cậy (confidence) của kết quả.

Ý tưởng cốt lõi: không phải mọi request thuộc "loại task A" đều có độ khó giống nhau. Trong 1000 câu hỏi khách hàng thuộc nhóm "tech support", có thể 800 câu đơn giản (model nhỏ trả lời tốt) và 200 câu phức tạp thực sự cần model mạnh. Nếu route tất cả 1000 câu vào Tier 1 vì "đây là tech support, cần chính xác", ta lãng phí ngân sách cho 800 câu không cần thiết.

Cascading Dựa Trên Confidence Score

Cơ chế phổ biến nhất là: gọi model rẻ trước, đánh giá confidence score (điểm tin cậy) của kết quả trả về, và chỉ escalate (đẩy lên tier cao hơn) khi confidence dưới ngưỡng cho phép.

Confidence có thể được xác định qua nhiều cách:
- Log-probability của token đầu ra (nếu API hỗ trợ trả về logprobs).
- Model tự đánh giá (self-assessment): yêu cầu model trả về kèm điểm tự tin từ 0-1 hoặc nhãn "certain/uncertain".
- Heuristic đầu ra: câu trả lời có chứa các dấu hiệu như "I'm not sure", "it depends", độ dài bất thường, hoặc không match được với schema JSON kỳ vọng.
- Đối chiếu chéo (self-consistency): gọi model rẻ 2-3 lần, nếu kết quả không đồng nhất → confidence thấp → escalate.

Dưới đây là ví dụ pseudo-code Python cho một router cascading 3 tầng, áp dụng cho tác vụ trả lời câu hỏi hỗ trợ khách hàng:

from dataclasses import dataclass
from enum import Enum


class ModelTier(Enum):
    ECONOMY = "economy"   # e.g. Claude Haiku, GPT-4o-mini
    MID = "mid"            # e.g. Claude Sonnet, GPT-4o
    FRONTIER = "frontier"  # e.g. Claude Opus, GPT-4.1


@dataclass
class ModelResponse:
    text: str
    confidence: float       # normalized 0.0 - 1.0
    tier_used: ModelTier
    tokens_used: int


CONFIDENCE_THRESHOLDS = {
    ModelTier.ECONOMY: 0.75,  # below this, escalate to MID
    ModelTier.MID: 0.60,      # below this, escalate to FRONTIER
}

MAX_TIER = ModelTier.FRONTIER


def call_model(tier: ModelTier, prompt: str) -> ModelResponse:
    """Wraps the actual API call for a given tier.
    Real implementation would hit the provider SDK and parse logprobs
    or a self-reported confidence field from a structured output schema.
    """
    raw = provider_client.generate(model=TIER_TO_MODEL_ID[tier], prompt=prompt)
    confidence = extract_confidence(raw)  # from logprobs or self-report field
    return ModelResponse(
        text=raw.text,
        confidence=confidence,
        tier_used=tier,
        tokens_used=raw.usage.total_tokens,
    )


def cascading_route(prompt: str) -> ModelResponse:
    """Try the cheapest tier first, escalate only when confidence is low.
    Logs every hop so we can measure cascade rate later.
    """
    tier_order = [ModelTier.ECONOMY, ModelTier.MID, ModelTier.FRONTIER]
    total_tokens = 0
    last_response = None

    for tier in tier_order:
        response = call_model(tier, prompt)
        total_tokens += response.tokens_used
        last_response = response

        threshold = CONFIDENCE_THRESHOLDS.get(tier)
        if threshold is None or response.confidence >= threshold:
            # Confident enough at this tier, or this is the last tier available
            log_cascade_event(tier_used=tier, escalated=(tier != tier_order[0]),
                               total_tokens=total_tokens)
            return response

        # else: confidence too low, fall through to next tier in the loop

    # Reached FRONTIER and still returning — accept the frontier answer as final
    return last_response

Điểm quan trọng cần lưu ý trong đoạn code trên:

  • Router không gọi song song tất cả các tier — nó gọi tuần tự, dừng ngay khi đạt ngưỡng tin cậy, để tránh lãng phí token cho các tầng không cần dùng.
  • Ngưỡng confidence (CONFIDENCE_THRESHOLDS) nên được tinh chỉnh dựa trên dữ liệu thực tế (offline evaluation), không nên đặt tùy ý — đặt quá cao sẽ escalate quá nhiều làm mất lợi ích tiết kiệm, đặt quá thấp sẽ để lọt các câu trả lời sai.
  • Hàm log_cascade_event là bắt buộc về mặt vận hành — nếu không log lại tỷ lệ escalate theo từng tier, bạn sẽ không có dữ liệu để tối ưu ngưỡng sau này (xem phần đo lường hiệu quả ở cuối bài).

Hồ Sơ Chi Phí Của Cascading

Cascading không phải lúc nào cũng rẻ hơn gọi trực tiếp Tier phù hợp — cần hiểu rõ cơ chế chi phí để tránh ảo tưởng "cascading luôn tiết kiệm".

Giả sử 70% request được giải quyết ở Tier 3, 25% escalate lên Tier 2, và 5% escalate tiếp lên Tier 1, tổng chi phí sẽ là:

Total cost = 100% × cost(Tier3)
           + 25% × cost(Tier2)     [chỉ phần escalate]
           + 5%  × cost(Tier1)     [chỉ phần escalate tiếp]

Thử với số liệu cụ thể để thấy rõ mức tiết kiệm: với 1.000 request, mỗi request trung bình 2.000 token, dùng giá xấp xỉ của Claude Haiku/Sonnet/Opus (Tier 3/2/1) đã nêu ở bài Token Pricing Models:

Tier 3 (100% request): 1.000 × 2.000 token × ~$2.4/1M (avg input+output)  ≈ $4.8
Tier 2 (25% escalate):   250 × 2.000 token × ~$9/1M                       ≈ $4.5
Tier 1 (5% escalate):     50 × 2.000 token × ~$45/1M                      ≈ $4.5

Total cascading ≈ $13.8
So với all-frontier (1.000 × 2.000 token × ~$45/1M) ≈ $90

Tiết kiệm ≈ 85%

Lưu ý: 100% request đều tốn chi phí Tier 3 (vì luôn thử tier rẻ nhất trước), cộng thêm chi phí của các lần escalate. Điều này có nghĩa là cascading chỉ có lợi khi:

  1. Tỷ lệ escalate thực tế thấp (đa số task được giải quyết ở tier thấp).
  2. Chi phí của lần gọi "thử" ở tier thấp không đáng kể so với việc tiết kiệm được từ việc tránh gọi tier cao.
  3. Có tính đến chi phí độ trễ tích lũy (latency cost) — mỗi lần escalate là một round-trip API mới, cộng dồn thời gian chờ của người dùng. Với các luồng real-time, đây là chi phí "ẩn" không nằm trong hoá đơn nhưng ảnh hưởng trực tiếp đến trải nghiệm.

Với các use case cực nhạy về độ trễ, một biến thể là cascading song song có kiểm soát: gọi đồng thời Tier 3 và Tier 2, ưu tiên nhận kết quả Tier 3 nếu confidence đủ cao, nếu không thì dùng ngay kết quả Tier 2 đã có sẵn (thay vì chờ gọi tiếp) — đánh đổi một phần chi phí để giảm latency.

Mẹo

  • Luôn thu thập dữ liệu tỷ lệ escalate theo từng nguồn task (theo endpoint, theo loại khách hàng, theo ngôn ngữ...) — tỷ lệ escalate không đồng nhất, và biết được nhóm nào escalate nhiều giúp bạn tinh chỉnh threshold hoặc routing logic riêng cho nhóm đó.
  • Đặt một giới hạn số lần escalate tối đa (ví dụ tối đa 2 hop) để tránh trường hợp một request bị đẩy lặp qua nhiều tier gây tốn kém và trễ không kiểm soát.
  • Cân nhắc cache kết quả ở tầng router: nếu cùng một câu hỏi (hoặc câu hỏi tương tự về semantic) đã được escalate và trả lời đúng trước đó, có thể trả kết quả cache thay vì chạy lại toàn bộ cascade.
  • Định kỳ chạy lại offline evaluation để tinh chỉnh ngưỡng confidence — mô hình và dữ liệu người dùng thay đổi theo thời gian, threshold cố định sẽ dần lệch khỏi tối ưu.

Đánh Đổi Giữa Model Chuyên Biệt và Model Đa Năng

Ngoài việc chọn tier theo mức năng lực chung, còn một chiều tối ưu khác: chọn giữa model đa năng (general-purpose) và model chuyên biệt (specialized) cho một domain hoặc một loại tác vụ cụ thể. Đây là quyết định ảnh hưởng trực tiếp đến chi phí vận hành dài hạn.

Model Fine-Tuned

Fine-tuning (tinh chỉnh model trên dữ liệu riêng) cho phép "nén" kiến thức domain-specific vào một model nhỏ hơn, giúp model nhỏ đạt chất lượng gần bằng model lớn cho một tác vụ hẹp, cụ thể. Ví dụ: fine-tune một model Tier 3 trên hàng chục nghìn ví dụ phân loại ticket hỗ trợ của riêng công ty, giúp nó đạt accuracy tương đương Tier 1 cho đúng tác vụ đó, với chi phí vận hành thấp hơn nhiều lần.

Đánh đổi cần cân nhắc:
- Chi phí ban đầu: cần dữ liệu training chất lượng, công sức chuẩn bị dataset, chi phí chạy fine-tuning job, và công đánh giá (evaluation) trước khi đưa vào production.
- Chi phí duy trì: mỗi khi nhà cung cấp release model nền tảng mới, có thể cần fine-tune lại; dữ liệu domain cũng "drift" (thay đổi) theo thời gian, cần retrain định kỳ.
- Phạm vi hẹp: model fine-tuned thường chỉ tốt cho đúng phạm vi task đã train, không tái sử dụng tốt cho task khác — khác với model đa năng có thể áp dụng linh hoạt.
- Điểm hòa vốn: fine-tuning chỉ đáng đầu tư khi volume của tác vụ đó đủ lớn để chi phí ban đầu được khấu hao (amortize) qua chi phí vận hành tiết kiệm được mỗi request.

Model Embedding

Embedding model (model chuyển văn bản thành vector số) là một dạng "chuyên biệt hóa" thường bị bỏ qua khi nói về model selection, nhưng lại là một trong những điểm tối ưu chi phí hiệu quả nhất trong pipeline agentic có sử dụng RAG (Retrieval-Augmented Generation).

Thay vì dùng một LLM đầy đủ để "hiểu" và so khớp ngữ nghĩa giữa câu hỏi và tài liệu, embedding model chuyên biệt (ví dụ text-embedding-3, Voyage, Cohere Embed) làm việc này với chi phí chỉ bằng một phần rất nhỏ so với gọi LLM cho cùng mục đích. Việc tách riêng bước "tìm kiếm ngữ nghĩa" (dùng embedding rẻ) ra khỏi bước "sinh câu trả lời" (dùng LLM phù hợp tier) là một pattern tối ưu chi phí kinh điển trong kiến trúc RAG — tránh được sai lầm dùng LLM đắt đỏ để làm công việc mà một model chuyên biệt, rẻ hơn hàng chục lần, đã làm tốt.

Model Lý Luận Chuyên Sâu (Reasoning Models như o1, o3)

Một nhóm model đặc biệt đáng nói riêng là reasoning model (model lý luận chuyên sâu) — như dòng o1, o3 của OpenAI, hay các biến thể "extended thinking" của Claude. Các model này được thiết kế để "suy nghĩ" qua nhiều bước trung gian (chain-of-thought nội tại) trước khi đưa ra câu trả lời cuối, giúp cải thiện đáng kể độ chính xác cho các bài toán logic, toán học, hoặc lập trình phức tạp.

Điểm cần lưu ý về chi phí:
- Các model này thường tính phí cho cả token suy luận ẩn (reasoning tokens) — token dùng để "suy nghĩ" nội bộ, không hiển thị trực tiếp cho người dùng nhưng vẫn được tính vào hóa đơn. Điều này có thể làm chi phí thực tế cao hơn nhiều so với số token của câu trả lời hiển thị.
- Reasoning model không phải lựa chọn phù hợp cho mọi task khó — chúng tối ưu cho các bài toán có cấu trúc logic rõ ràng (toán, thuật toán, debug logic phức tạp), nhưng không nhất thiết vượt trội hơn model Tier 1 thông thường cho các task cần "cảm nhận" ngôn ngữ, sáng tạo nội dung, hoặc hiểu ngữ cảnh xã hội.
- Độ trễ của reasoning model thường cao hơn đáng kể vì thời gian dành cho việc "suy nghĩ" nội bộ — cần cân nhắc kỹ nếu dùng trong luồng tương tác thời gian thực.
- Nên dùng reasoning model có chọn lọc: cho các bước cụ thể trong pipeline cần lý luận sâu (ví dụ bước "lập kế hoạch" trong một agent nhiều bước), rồi chuyển giao lại cho model tier thường ở các bước còn lại.

Mẹo

  • Trước khi đầu tư fine-tuning, hãy thử kỹ prompt engineering và few-shot examples trên model đa năng — nhiều trường hợp có thể đạt chất lượng tương đương mà không cần chi phí training.
  • Luôn tách riêng chi phí embedding ra khỏi chi phí LLM khi tính tổng chi phí một pipeline RAG — dễ bị bỏ quên vì đơn giá rất nhỏ, nhưng ở volume cao vẫn đáng để tối ưu (ví dụ cache embedding của tài liệu tĩnh, không tính lại mỗi lần truy vấn).
  • Với reasoning model, luôn kiểm tra dòng chi phí "reasoning tokens" trong log sử dụng — đây là chi phí ẩn dễ gây bất ngờ khi nhận hoá đơn cuối tháng.
  • Đặt reasoning model vào đúng vị trí trong pipeline (bước cần lý luận), không dùng cho toàn bộ luồng — kết hợp với model rẻ hơn ở các bước còn lại.

Kiến Trúc Routing Cho Hệ Thống Đa Model

Khi đã có nhiều tier, nhiều model chuyên biệt, và cơ chế cascading, cần một tầng routing (điều phối) tập trung để quản lý toàn bộ logic chọn model — thay vì rải rác logic if/else ở khắp các module trong codebase.

Một kiến trúc routing tốt thường có các thành phần sau:

  1. Task classifier: một bước phân loại nhanh (thường dùng model Tier 3 hoặc rule-based) để xác định loại tác vụ trước khi routing.
  2. Policy engine: nơi lưu các quy tắc ánh xạ task → tier/model, ngưỡng confidence, giới hạn escalate — nên tách thành config riêng, dễ chỉnh sửa mà không cần deploy lại code.
  3. Model adapter layer: lớp trừu tượng hóa (abstraction) giúp gọi các provider khác nhau (OpenAI, Anthropic, Google, self-hosted) qua một interface thống nhất.
  4. Observability hook: ghi log mọi quyết định routing, tier được dùng, token tiêu thụ, độ trễ, và kết quả — dữ liệu này chính là đầu vào cho phần đo lường hiệu quả ở mục tiếp theo.

Ví dụ pseudo-code Python cho một router tổng quát, kết hợp cả task classification và cascading:

from dataclasses import dataclass, field
from typing import Callable


@dataclass
class RoutingPolicy:
    task_type: str
    default_tier: ModelTier
    allow_cascade: bool = True
    max_escalations: int = 2


POLICIES: dict[str, RoutingPolicy] = {
    "intent_classification": RoutingPolicy("intent_classification", ModelTier.ECONOMY, allow_cascade=False),
    "doc_summarization":     RoutingPolicy("doc_summarization", ModelTier.MID),
    "code_review":           RoutingPolicy("code_review", ModelTier.MID, max_escalations=1),
    "architecture_design":   RoutingPolicy("architecture_design", ModelTier.FRONTIER, allow_cascade=False),
}


def classify_task(prompt: str, metadata: dict) -> str:
    """Cheap classifier (rule-based or Tier 3 model) that tags the incoming
    request with a task_type key used to look up the routing policy.
    """
    if metadata.get("endpoint") == "/api/agent/review":
        return "code_review"
    # fallback: use a lightweight model call or keyword heuristics
    return lightweight_classifier.predict(prompt)


def route_request(prompt: str, metadata: dict) -> ModelResponse:
    task_type = classify_task(prompt, metadata)
    policy = POLICIES.get(task_type, RoutingPolicy(task_type, ModelTier.MID))

    if not policy.allow_cascade:
        response = call_model(policy.default_tier, prompt)
        log_routing_decision(task_type, policy.default_tier, escalated=False,
                              tokens=response.tokens_used)
        return response

    # Cascade starting from the policy's default tier, capped by max_escalations
    response = cascading_route_from(prompt, start_tier=policy.default_tier,
                                     max_hops=policy.max_escalations)
    log_routing_decision(task_type, response.tier_used,
                          escalated=(response.tier_used != policy.default_tier),
                          tokens=response.tokens_used)
    return response

Một vài nguyên tắc thiết kế quan trọng khi xây dựng tầng routing này trong hệ thống thực tế:

  • Tách config khỏi code: POLICIES nên được load từ file YAML/JSON hoặc feature-flag service, để team vận hành có thể chỉnh threshold, tier mặc định mà không cần một lần deploy code mới.
  • Fail-safe rõ ràng: nếu provider của một tier bị lỗi/timeout, router cần có logic fallback sang provider khác hoặc tier khác, tránh làm sập toàn bộ luồng vì một điểm lỗi.
  • Rate limit và circuit breaker theo tier: tier cao thường có rate limit thấp hơn (do đắt và ít capacity hơn) — router cần biết giới hạn này để tránh escalate tràn lan gây lỗi 429.
  • Version hóa policy: khi thay đổi threshold hoặc default tier, nên gắn version để có thể so sánh hiệu quả trước/sau khi thay đổi (giống một dạng A/B test cho routing).

Mẹo

  • Xây dựng router như một service/module độc lập, không nhúng logic routing rải rác trong từng feature — giúp việc audit chi phí và điều chỉnh chính sách dễ dàng hơn nhiều.
  • Thêm cơ chế override theo request (ví dụ header x-force-tier: frontier) để debug hoặc xử lý case đặc biệt mà không cần sửa policy chung.
  • Đảm bảo router log đủ thông tin để truy vết ngược (trace back) một quyết định routing cụ thể khi cần điều tra một câu trả lời sai hoặc một khoản chi phí bất thường.
  • Với hệ thống multi-agent, đặt logic routing model selection tách biệt với logic điều phối task giữa các agent (orchestration) — hai lớp này có mối quan tâm khác nhau và dễ rối nếu trộn lẫn.

Đo Lường Hiệu Quả Của Chiến Lược Chọn Model

Model selection không phải là "làm một lần rồi xong" — nó cần được đo lường và tinh chỉnh liên tục dựa trên dữ liệu thực tế. Không có số liệu, mọi quyết định về threshold hay tier mapping đều chỉ là ước đoán.

Các chỉ số (metric) cốt lõi cần theo dõi:

  • Chi phí trên mỗi tác vụ thành công (cost per successful task): không chỉ tính chi phí token thô, mà tính cả retry, escalate, và các lần gọi thất bại phải xử lý lại.
  • Tỷ lệ escalate theo từng loại task và theo tier (escalation rate): giúp phát hiện sớm nếu một loại task đang bị đặt threshold sai (escalate quá nhiều nghĩa là tier khởi điểm chưa phù hợp).
  • Accuracy/quality theo tier: cần một tập test case đại diện (golden set) để đánh giá định kỳ chất lượng đầu ra ở từng tier, tránh tình trạng "tiết kiệm được tiền nhưng chất lượng đã âm thầm giảm".
  • Phân bổ chi phí theo tier (cost distribution): theo dõi % tổng chi phí rơi vào từng tier theo thời gian — một sự dịch chuyển bất thường (ví dụ tier Frontier tăng tỷ trọng chi phí đột ngột) là dấu hiệu cần điều tra ngay, có thể do task mới xuất hiện mà chưa được classify đúng, hoặc do lỗi logic routing.
  • Độ trễ trung bình và p95 theo tier và theo cascading path — vì tối ưu chi phí không được đánh đổi quá mức với trải nghiệm người dùng.
  • Chi phí tiết kiệm được so với baseline (nếu luôn dùng Tier 1 cho mọi request) — đây là con số thuyết phục nhất để báo cáo ROI (Return on Investment) của việc đầu tư xây dựng hệ thống routing/cascading cho stakeholder không chuyên kỹ thuật.

Về mặt vận hành, nên có một dashboard cost-per-tier cập nhật theo thời gian thực hoặc theo ngày, kèm cảnh báo (alerting) khi:
- Tỷ lệ escalate của một loại task vượt ngưỡng bất thường (ví dụ tăng gấp đôi so với trung bình 7 ngày trước).
- Chi phí tổng theo tier tăng đột biến không tương ứng với tăng volume request.
- Accuracy trên golden set giảm dưới ngưỡng chấp nhận được sau khi thay đổi threshold hoặc đổi model nền tảng.

Mẹo

  • Xây golden set đánh giá riêng cho từng loại tác vụ, không dùng một bộ test chung cho tất cả — mỗi loại task có tiêu chí "đúng/sai" khác nhau.
  • Đưa việc review dashboard cost-per-tier vào quy trình định kỳ (ví dụ retro hàng tháng của team), không chỉ xem khi có sự cố — tối ưu chi phí là việc liên tục, không phải phản ứng khi nhận hoá đơn cao bất ngờ.
  • Khi so sánh hiệu quả trước/sau thay đổi policy, luôn chuẩn hóa theo volume (per-1000-requests) để tránh so sánh sai lệch do biến động lưu lượng theo mùa/theo giờ.
  • Chia sẻ số liệu tiết kiệm chi phí (cost savings) với các bên liên quan ngoài kỹ thuật (product, tài chính) bằng ngôn ngữ business — "framework routing giúp giảm X% chi phí LLM mỗi tháng mà không đổi chất lượng đầu ra" — để duy trì sự ủng hộ cho việc đầu tư tiếp vào hạ tầng routing.

Tổng Kết

Chọn model đúng cho đúng tác vụ là một trong những đòn bẩy tối ưu chi phí mạnh nhất mà một team làm AI agent có thể áp dụng — thường mang lại mức tiết kiệm 50-80% chi phí LLM mà không đánh đổi đáng kể về chất lượng, nếu được thiết kế đúng cách.

Những điểm cốt lõi cần nhớ:

  • Phân loại model theo ba tier (Frontier, Mid-tier, Economy) dựa trên năng lực, tốc độ và giá, thay vì chọn theo cảm tính hay theo tên thương hiệu.
  • Xây dựng framework ánh xạ tác vụ → tier rõ ràng, dựa trên độ phức tạp lý luận, error tolerance, yêu cầu độ trễ và volume — review định kỳ khi sản phẩm phát triển.
  • Áp dụng cascading với confidence-based routing để tự động đẩy request lên tier cao hơn chỉ khi cần, tránh lãng phí ngân sách cho phần lớn task đơn giản.
  • Cân nhắc fine-tuning, embedding model chuyên biệt, và reasoning model như các công cụ bổ sung — mỗi loại có đánh đổi riêng về chi phí ban đầu, chi phí duy trì, và phạm vi áp dụng.
  • Xây một tầng routing tập trung, tách biệt config khỏi code, có fail-safe và observability đầy đủ, để quản lý toàn bộ logic chọn model một cách nhất quán trên toàn hệ thống.
  • Đo lường liên tục bằng các chỉ số cost-per-task, escalation rate, accuracy trên golden set, và cost distribution theo tier — không có số liệu, mọi tối ưu chỉ là phỏng đoán.

Model selection không phải là một dự án làm một lần — nó là một năng lực vận hành (operational capability) cần được đầu tư, đo lường và cải tiến liên tục, song song với sự phát triển của cả sản phẩm và thị trường model. Team nào xây dựng được năng lực này sớm sẽ có lợi thế chi phí rõ rệt khi quy mô sử dụng AI agent trong sản phẩm ngày càng tăng.

Tiếp