Z.ai ra mắt GLM-5.3 vào ngày 14/8 — cùng base weights với GLM-5.2, cộng thêm một tháng post-training. Con số mới đáng chú ý: Terminal-Bench 3.0 tăng từ 4.6 lên 28.3, DeepSWE v1.1 từ 46.2 lên 66.9, SWE-Marathon v1.1 từ 19.4 lên 42.5. Đây không phải là cải thiện nhỏ giọt, mà là một model đi từ “không khả thi cho task agentic coding” sang “thực sự dùng được” chỉ trong một chu kỳ training, trong khi giá chính thức của GLM-5.2 chỉ $1.40/$4.40 mỗi triệu token input/output — và các provider bên thứ ba còn phục vụ với giá rẻ hơn nhiều. Trong khi đó, giá của các model flagship Anthropic dao động $10-50 mỗi triệu token, và Financial Times tuần này đưa tin tăng trưởng doanh thu của Anthropic đang chịu áp lực chính vì doanh nghiệp đang chuyển các task đơn giản sang những lựa chọn rẻ hơn này thay vì trả giá frontier cho mọi thứ.

Tôi đã có cuộc trò chuyện này với ba engineering lead trong tháng qua, tất cả đều đi đến cùng một kết luận: nếu bạn vẫn gửi mọi request trong sản phẩm đến một model duy nhất, bạn đang hoặc trả tiền thừa đáng kể, hoặc phục vụ kém cho những task khó nhất — thường là cả hai, ở những phần khác nhau của hệ thống.

Vì sao “cứ dùng model tốt nhất ở mọi nơi” hết hiệu quả

Đó là kiến trúc đầu tiên hiển nhiên, và ổn ở lưu lượng thấp. Nó ngừng ổn khi bạn có đủ traffic để chênh lệch chi phí giữa frontier model và một mid-tier model được chọn kỹ trở thành dòng chi phí ai đó hỏi trong buổi review ngân sách. Nhưng failure mode không chỉ là chi phí — còn là chất lượng. Một frontier reasoning model áp dụng cho task thực chất chỉ là pattern-matching đơn giản (phân loại ticket này, extract field này, format response này) không chỉ lãng phí, mà còn có thể thực sự kém hơn một model nhỏ được tune cho throughput trên task hẹp, vì bạn đang trả latency của reasoning model mà không nhận lại lợi ích reasoning nào.

Routing trông như thế nào trong hệ thống thực tế

Pattern hiệu quả cho các hệ thống tôi xây năm nay không phải là một LLM call “route theo cảm tính” quyết định dùng model nào — điều đó chỉ thêm một LLM call không đáng tin cậy nữa vào critical path. Đó là một classifier tất định (deterministic) đứng trước một tập nhỏ các model tier:

from enum import Enum

class TaskTier(Enum):
    SIMPLE = "simple"       # extraction, classification, rewrite ngắn
    STANDARD = "standard"   # tóm tắt, soạn thảo, reasoning vừa phải
    COMPLEX = "complex"     # multi-step agentic work, quyết định kiến trúc

TIER_MODELS = {
    TaskTier.SIMPLE: "glm-5.3-turbo",      # rẻ, nhanh, đủ tốt
    TaskTier.STANDARD: "gemini-3.7-flash", # cân bằng chi phí/chất lượng
    TaskTier.COMPLEX: "claude-opus-5",     # frontier reasoning, trả tiền khi thực sự cần
}

def classify_task(task: Task) -> TaskTier:
    if task.requires_multi_step_planning or task.touches_production_code:
        return TaskTier.COMPLEX
    if task.output_tokens_estimate > 500 or task.needs_synthesis:
        return TaskTier.STANDARD
    return TaskTier.SIMPLE

def route(task: Task) -> str:
    tier = classify_task(task)
    return TIER_MODELS[tier]

Ba điều khiến pattern này thực sự trụ vững trong production, ngoài việc mapping đơn giản ở trên:

Classifier phải rẻ và tất định, không phải một model call khác. Rule-based hoặc một classifier local nhỏ — bất cứ thứ gì thêm một round-trip LLM đầy đủ chỉ để quyết định gọi LLM nào sẽ phản tác dụng và thêm một điểm lỗi mới. Tôi từng thấy team thử route bằng LLM call và kết quả là latency routing “ăn” hết khoản tiết kiệm từ việc chọn model downstream rẻ hơn.

Ranh giới tier cần dữ liệu thực, không phải đoán mò. “Chạm vào production code” là trigger cho complex-tier đến từ việc thực sự đo lường: các task dưới ranh giới đó có chất lượng output gần như giống hệt nhau giữa GLM-5.3 và Opus 5 trong eval của chúng tôi, các task trên ranh giới đó có khoảng cách chất lượng thật sự thể hiện trong review comment, không chỉ điểm benchmark. Hãy đặt ranh giới từ dữ liệu eval của chính bạn trên phân bố task của chính bạn — con số Terminal-Bench hay SWE-bench cho bạn biết về năng lực coding tổng quát, không phải về pattern prompt và từ vựng domain cụ thể của bạn.

Escalation phải là một đường đi hạng nhất, không phải suy nghĩ sau. Một task simple-tier trả về dạng lỗi, mơ hồ, hoặc dưới ngưỡng confidence nên tự động re-route lên tier cao hơn, không chỉ đơn giản là fail. Đây cùng bản năng với pattern fallback-chain resilience tôi từng viết riêng — routing và failover thực chất là cùng một kiến trúc giải quyết hai trigger khác nhau (chi phí vs. khả dụng), và đáng để xây chúng như một hệ thống thay vì hai.

Nơi pattern này thực sự sinh lời

Trên một hệ thống của khách hàng xử lý triage ticket support, chuyển classification simple-tier khỏi frontier model sang model tier-GLM đã cắt chi phí mỗi request khoảng 80% mà không có sụt giảm đo được về độ chính xác triage — vì triage chưa bao giờ là task cần frontier reasoning, nó cần pattern matching nhất quán, nhanh, và chúng tôi đã trả tiền cho năng lực không dùng đến. Tier complex — các thay đổi code multi-file thực sự, đề xuất kiến trúc — vẫn ở lại Opus 5, vì đó chính xác là nơi khoảng cách chất lượng giữa các tier là thật và đắt giá nếu sai.

Sai lầm theo hướng ngược lại cũng phổ biến không kém: team route mọi thứ về model rẻ nhất để tiết kiệm tiền rồi tự hỏi vì sao công cụ agentic coding của họ tạo ra những diff trông hợp lý nhưng thực chất không chạy được. Model rẻ xuất sắc ở task hẹp, được đặc tả rõ ràng và thực sự kém hơn ở công việc dài hạn, mơ hồ, nhiều bước — khoảng cách đó là thật, không chỉ là hiện tượng benchmark, và kiến trúc routing chỉ sinh lời nếu bạn thành thật về ranh giới đó nằm ở đâu với workload của chính mình.

One-model-fits-all chưa bao giờ thực sự là một chiến lược, nó chỉ là thứ bạn làm trước khi khoảng cách giá giữa các tier đủ rộng, và tooling đủ trưởng thành, để việc xây một router đáng giá chi phí kỹ thuật bỏ ra. Ngưỡng đó giờ đã rõ ràng vượt qua.