Ba frontier model ra mắt trong vòng mười ngày của tháng 7: GPT-5.6 Luna ngày 1/7, Claude Sonnet 5 ngày 5/7, Grok 4.5 ngày 8/7. Mỗi cái thắng ở một tiêu chí khác nhau — Sonnet 5 dẫn đầu benchmark code với 82.1% SWE-Bench Pro, GPT-5.6 Terra đạt độ tin cậy agent cao nhất với 97.2% trên multi-step tool chains, Grok 4.5 nhanh nhất với ~140ms p95 TTFT và rẻ nhất với $2/$6 mỗi triệu token. Cuộc chiến model đã xong. Cuộc chiến routing mới bắt đầu.

Mình đã thấy điều này trước đây với cloud instances. Bạn không chọn một loại EC2 rồi scale tất cả vào đó. Bạn route workload đến đúng compute tier. Logic tương tự giờ áp dụng cho LLM, và team nào chưa xây routing layer đang bỏ phí 40-80% ngân sách AI.

Tại Sao Default Một Model Thất Bại Ở Scale

Khi team mới adopt LLM API, họ chọn một model — thường là cái vừa đọc benchmark thấy hay nhất — và gửi tất cả request vào đó. Ổn trong pilot. Vỡ ở production scale.

Toán học đơn giản: nếu bạn xử lý một triệu API calls mỗi tháng trên Claude Sonnet 5 với $3/triệu input token (sau khi introductory period kết thúc 31/8/2026), trung bình 2.000 token mỗi request, bạn chi khoảng $6.000/tháng chỉ riêng input. Nhưng vấn đề thật sự là: phần lớn request đó không cần Sonnet 5. Chúng là classification call đơn giản, tóm tắt text ngắn, hay status check mà model $0.25/triệu xử lý tốt y hệt.

Thực tế, 70-80% LLM calls trong production nằm trong vùng “commodity” — task mà model tier Haiku thực hiện ở mức 95%+ chất lượng so với flagship. Bạn đang trả giá flagship cho công việc commodity.

Kiến Trúc Ba Tầng

Pattern hoạt động trong production là cascade ba tầng, với routing layer phía trước:

Request → Router → [Nano | Standard | Frontier]
                        ↓          ↓          ↓
                  Haiku 4.5   Sonnet 5   GPT-5.6 Terra
                   $0.25/$1   $3/$15     $5/$20

Tầng 1 — Nano (Haiku 4.5 hoặc tương đương): Classification đơn giản, tóm tắt text ngắn, phát hiện intent, slot filling, bất cứ thứ gì dưới ~500 token với structured output. Mục tiêu: 70-80% request.

Tầng 2 — Standard (Claude Sonnet 5, Sonnet 4.6): Lý luận phức tạp, sinh code dưới 200 dòng, tổng hợp tài liệu, khớp tone tinh tế. Mục tiêu: 15-25% request.

Tầng 3 — Frontier (GPT-5.6 Terra, Claude Opus 4.8): Multi-step agentic tasks yêu cầu độ tin cậy >95%, code review phức tạp, tasks mà thất bại thì tốn kém. Mục tiêu: 5-10% request.

Phân chia 75/20/5 giữa các tầng này cắt hóa đơn $6.000 chỉ dùng Sonnet xuống còn khoảng $1.800 — giảm 70% mà user không thấy khác biệt chất lượng ở 75% còn lại.

Xây Dựng Router

Router là phần khó nhất. Bạn có ba lựa chọn, theo độ phức tạp tăng dần:

Lựa Chọn 1: Rule-Based Routing (Bắt Đầu Ở Đây)

Cách đơn giản nhất là rules engine dựa trên request metadata bạn đã có:

def route_request(request: LLMRequest) -> ModelTier:
    # Rule cứng dựa trên loại task
    if request.task_type in ["classify", "intent", "slot_fill"]:
        return ModelTier.NANO
    
    if request.task_type in ["agent_step", "complex_code_review"]:
        return ModelTier.FRONTIER
    
    # Ước tính token budget
    estimated_tokens = estimate_tokens(request.messages)
    if estimated_tokens < 800 and request.structured_output:
        return ModelTier.NANO
    
    if estimated_tokens > 8000 or request.requires_tool_calls > 5:
        return ModelTier.FRONTIER
    
    return ModelTier.STANDARD

Cách này giúp bạn đạt 60-70% tiết kiệm chi phí ngay lập tức, không cần machine learning. Ship cái này trước.

Lựa Chọn 2: Classifier-Based Routing

Train một classifier nhỏ (Haiku fine-tuned hoặc BERT nhẹ) dự đoán model tier tối thiểu cần thiết cho request. Paper RouteLLM (ICLR 2025) chứng minh cách này giảm 85%+ chi phí trong khi giữ 95% chất lượng trên benchmark chuẩn.

class RouterClassifier:
    def __init__(self, model_path: str):
        self.classifier = load_model(model_path)
    
    def predict_tier(self, request: str) -> tuple[ModelTier, float]:
        logits = self.classifier(request)
        tier = ModelTier(logits.argmax())
        confidence = logits.softmax()[tier]
        
        # Route UP khi confidence thấp
        if confidence < 0.8:
            tier = ModelTier(min(tier.value + 1, ModelTier.FRONTIER.value))
        
        return tier, confidence

Insight quan trọng: khi classifier không chắc, luôn route lên, không phải xuống. Route sai xuống tier thấp hơn làm mất chất lượng; route sai lên tier cao hơn tốn tiền hơn nhưng giữ được correctness.

Lựa Chọn 3: Cascading với Quality Gates

Với workload high-stakes, chạy request trên model rẻ trước, đánh giá chất lượng output rồi mới trả về. Nếu output fail quality check, escalate lên tier tiếp theo.

async def cascade_request(request: LLMRequest) -> LLMResponse:
    for tier in [ModelTier.NANO, ModelTier.STANDARD, ModelTier.FRONTIER]:
        model = get_model(tier)
        response = await model.complete(request)
        
        quality_score = evaluate_quality(response, request.quality_criteria)
        
        if quality_score >= request.min_quality_threshold:
            record_routing_decision(tier, quality_score, cost=model.cost)
            return response
        
        if tier == ModelTier.FRONTIER:
            return response  # Tầng cuối, trả về kết quả tốt nhất có thể
    
    return response

Cách này thêm latency (hai model calls cho ~30% request escalate), nhưng với workload quan trọng hơn tốc độ, cascade đảm bảo bạn không bao giờ ship response kém từ model rẻ.

Ghép Workload Với Model Năm 2026

Dựa trên benchmark hiện tại, đây là mapping mình dùng cho team:

WorkloadModel Tốt NhấtLý Do
Sinh code (<200 dòng)Claude Sonnet 582.1% SWE-Bench Pro
Multi-step agentsGPT-5.6 Terra97.2% độ tin cậy tool-chain
Chat nhạy cảm về latencyGrok 4.5140ms p95 TTFT
Classification / triageHaiku 4.5Chất lượng 95%+ với giá thấp hơn 12x
Tổng hợp tài liệuClaude Sonnet 5Mạnh về structured extraction
Lý luận phức tạpClaude Opus 4.8Độ sâu tối đa, dùng tiết kiệm

“Dùng tiết kiệm” với Opus 4.8 là lời khuyên thực tế. Mình thấy team chi 40% ngân sách AI vào Opus cho những task mà Sonnet xử lý y hệt. Hãy để dành frontier tier cho task mà thất bại thực sự tốn kém.

Prompt Caching: Đòn Bẩy Thứ Hai

Routing không phải đòn bẩy duy nhất. Nếu ứng dụng của bạn gửi cùng một system prompt, document context, hay conversation history với mỗi request — và hầu hết đều vậy — thì prompt caching là tối ưu hóa có tác động cao thứ hai.

Cache reads trên Anthropic API tốn khoảng 10% tỷ lệ input chuẩn. Với system prompt 2.000 token gửi mỗi request, đó là $0.27/triệu token tiết kiệm được trên mỗi cached call. Ở scale lớn, con số này cộng dồn nhanh.

def build_cached_request(user_message: str, system_prompt: str) -> dict:
    return {
        "model": "claude-sonnet-5",
        "system": [
            {
                "type": "text",
                "text": system_prompt,
                "cache_control": {"type": "ephemeral"}  # Cache block này
            }
        ],
        "messages": [{"role": "user", "content": user_message}]
    }

Thực tế, routing + caching cùng nhau liên tục đem lại 60-75% tiết kiệm chi phí trên production workloads. Sự kết hợp quan trọng: caching giảm chi phí mỗi token ở từng tier, và routing giảm tier bạn phải dùng.

Observability: Đo Cái Gì

Routing layer không có observability là bay mù. Các metric quan trọng:

Phân phối routing — Bao nhiêu % request đến từng tier? Nếu 50% đến Frontier, router của bạn đang cấu hình sai. Mục tiêu 70-80% trên Nano.

Tỷ lệ escalation — Với cascade routing, bao nhiêu % request escalate từ tier này sang tier tiếp theo? >40% escalation Nano→Standard cho thấy Nano tier chưa được đặc tả tốt.

Chi phí mỗi request theo tier và loại task — Loại task nào đang đắt bất ngờ? Đây là ứng viên để tối ưu prompt hoặc phân loại lại tier.

Chất lượng theo tier — Track user satisfaction, task success downstream, hay điểm eval tự động theo tier. Giảm 2% chất lượng mà tiết kiệm 60% chi phí thường xứng đáng; giảm 20% thì không.

@dataclass
class RoutingMetric:
    request_id: str
    tier_used: ModelTier
    tier_intended: ModelTier
    escalated: bool
    cost_usd: float
    quality_score: float
    task_type: str
    latency_ms: int

# Log mọi quyết định routing
metrics_collector.record(routing_metric)

Chiến Lược Rollout

Đừng bật toàn bộ cùng lúc. Thứ tự rollout mình khuyến nghị:

  1. Tuần 1-2: Shadow mode — chạy router, log quyết định routing, nhưng tiếp tục gửi tất cả request đến model hiện tại. Kiểm tra routing decisions có hợp lý không.

  2. Tuần 3-4: Route chỉ các loại task rủi ro thấp (classification, triage) xuống tầng thấp hơn. Theo dõi sát quality metrics.

  3. Tuần 5-6: Mở rộng sang task standard khối lượng cao hơn. Track tỷ lệ escalation và điểm chất lượng.

  4. Tuần 7+: Full routing với cascade fallback cho workload high-stakes. Review cost dashboard hàng tuần.

Mỗi giai đoạn phải cho thấy giảm chi phí đo được mà không có quality regression. Nếu chất lượng giảm, thắt chặt ngưỡng confidence của router trước khi tiến tiếp.

Bức Tranh Model Đã Khác

Sự thay đổi có ý nghĩa vào tháng 7/2026 không phải là một model nào đó tiến vượt bậc. Đó là frontier đã trở thành số nhiều. Bạn có ba model cạnh tranh với điểm mạnh khác biệt có ý nghĩa trong vòng một tuần. Team chọn một cái và bỏ qua những cái còn lại đang mắc sai lầm tương tự như chọn một cloud region và bỏ qua tất cả phần còn lại.

Multi-model routing không còn là tối ưu hóa “nếu có thì tốt” nữa. Ở scale mà hầu hết product team đang vận hành, đây là ranh giới giữa AI profitable và AI trở thành cost center mà leadership nghi ngờ mỗi quý.

Xây router. Bắt đầu với rule. Ship nó. Rồi làm nó thông minh hơn.

Xuất nội dung

Bình luận