Tuần này GitHub tung Project HydraFusion vào Copilot CLI dưới dạng research preview, và cách họ mô tả trên blog khá khiêm tốn: “chất lượng frontier nhờ điều hướng đa model”. Nhưng thực chất họ đã xây một bộ lập kế hoạch theo từng tác vụ, quyết định ngay tại runtime xem yêu cầu code của bạn sẽ được xử lý bởi một model duy nhất, một chuỗi cascade hai model, hay một vòng draft-critique-revise xuyên suốt nhiều họ model — và báo cáo rằng cách làm này rẻ hơn 36-67% so với Claude Opus 5, trong khi chất lượng ngang bằng hoặc vượt trên TerminalBench 2.1, DeepSWE, và CheckpointBench.
Tôi đã tự tay xây đúng loại logic routing này cho hai nền tảng nội bộ khác nhau. Việc một vendor lớn biến nó thành sản phẩm đáng để dừng lại suy nghĩ, vì nó cho thấy điều gì đó về việc kỷ nguyên “cứ chọn model tốt nhất” của công cụ agent đang dần kết thúc.
HydraFusion thực sự làm gì
Ba pattern thực thi, được chọn tự động theo từng yêu cầu:
- Single — một model xử lý toàn bộ tác vụ từ đầu đến cuối. Đây là phương án mặc định cho những gì không có dấu hiệu cần nhiều hơn.
- Cascade — một model rẻ, nhanh draft ra lời giải; một cổng chất lượng (quality gate) đánh giá nó dựa trên tín hiệu độ tin cậy, và nếu không đạt ngưỡng, tác vụ sẽ được đẩy lên (escalate) cho một model mạnh hơn (và đắt hơn). Bạn chỉ trả giá frontier khi model rẻ thực sự gặp khó khăn.
- Critique — một model draft, một họ model khác review ở chế độ chỉ đọc, và model gốc được sửa một lượt dựa trên critique đó. Đây là pattern cho các tác vụ mà sự bất đồng giữa các model chính là một tín hiệu hữu ích — bug logic tinh vi, code nhạy cảm về bảo mật, yêu cầu mơ hồ.
Việc chọn pattern không phải một bộ luật tĩnh. GitHub mô tả nó như một bài toán tối ưu hóa trên các tín hiệu năng lực — độ sâu suy luận cần thiết, độ phức tạp sinh code, debug hay generate, tải tool-use — ánh xạ tới pattern nào đạt ngưỡng chất lượng với chi phí thấp nhất.
Vì sao đây là chuyện lớn hơn “thêm một tính năng routing”
Mọi team đang chạy agent ở quy mô lớn đều đã tự xây một phiên bản nào đó của việc này bằng tay: model rẻ cho các yêu cầu tầm autocomplete, model frontier được gate sau một heuristic độ phức tạp, có khi thêm một ý kiến thứ hai cho bất cứ gì đụng đến code auth hoặc payment. Tôi từng triển khai chính xác cấu trúc ba tầng đó. Nó hoạt động, nhưng dễ vỡ — các heuristic mục nát dần khi phân bố tác vụ thay đổi, và chẳng ai muốn nhận trách nhiệm tinh chỉnh ngưỡng escalation mỗi sprint.
Điều HydraFusion thực sự đề xuất là logic routing này không còn thuộc về tầng ứng dụng của bạn nữa — nó thuộc về runtime của agent, dựa trên tín hiệu năng lực thời gian thực thay vì một regex tự tinh chỉnh trên độ dài prompt. Nếu điều này đúng, đó là cùng một sự dịch chuyển mà chúng ta từng thấy với load balancer chuyển từ “code ứng dụng chọn server” sang “tầng hạ tầng ra quyết định đó với thông tin tốt hơn ứng dụng có được.”
Con số đáng để dừng lại là kết quả trên TerminalBench 2.1: tăng 4.9 điểm phần trăm chất lượng tác vụ đã verify, với chi phí thấp hơn 67% so với chỉ dùng Opus 5. Đây không phải kiểu “rẻ hơn nhưng kém hơn một chút” — cascade routing thắng về chất lượng chính vì pattern rẻ-trước buộc một lượt xử lý độc lập thứ hai trên bất cứ gì thực sự khó, điều mà chạy single-model không có được miễn phí.
Những chỗ tôi sẽ đặt câu hỏi
Vài điều tôi muốn được trả lời trước khi tin tưởng cách làm này trong môi trường có yêu cầu tuân thủ chặt:
- Tính không xác định (non-determinism) trở nên tệ hơn, không tốt hơn. Bạn đã chấp nhận một mức độ biến thiên giữa các lần chạy của một model đơn. Giờ chính pattern thực thi cũng có thể khác nhau giữa hai lần chạy cùng một prompt, vì tín hiệu độ tin cậy của router không đảm bảo ổn định. Với code review được gate bởi CI hoặc bất cứ gì cần khả năng tái lập, đó là một chi phí thật — nên ghim về chế độ Single và chấp nhận chênh lệch giá.
- Pattern critique giả định sự đa dạng model là tín hiệu, không phải nhiễu. Hai model từ dữ liệu huấn luyện tương quan bất đồng với nhau nói lên ít hơn những gì cách trình bày này ngụ ý. Nếu cả model draft và model critique đều được huấn luyện trên corpus web-scale trùng lặp phần lớn, “critique độc lập” có thể chỉ là các điểm mù tương quan đồng thuận với nhau đúng ở những failure mode quan trọng nhất (logic bảo mật tinh vi, API mới lạ).
- Phân bổ chi phí khó hơn cho team platform. Nếu bạn đang chargeback chi phí AI cho các đơn vị engineering, “router quyết định escalate lên model frontier cho yêu cầu cụ thể này” là một câu chuyện khó kể với VP hơn nhiều so với chi phí license cố định theo đầu người. Bạn sẽ cần log ở mức request — pattern nào được kích hoạt và vì sao — ngay từ ngày đầu, đừng đợi đến khi phòng tài chính hỏi.
Một phiên bản tối giản bạn có thể xây ngay hôm nay
Bạn không cần chờ HydraFusion GA để có được lợi ích chi phí của pattern cascade. Đây là hình dạng của thứ tôi đang chạy trước một coding agent hiện nay:
def route_request(task, cheap_model, strong_model, confidence_threshold=0.75):
draft = cheap_model.generate(task)
confidence = cheap_model.self_eval_confidence(draft) # hoặc một verifier model nhẹ
if confidence >= confidence_threshold and passes_static_checks(draft):
return draft, "single-cheap"
# Escalate: model mạnh nhận tác vụ CÙNG với bản draft của model rẻ làm context
revised = strong_model.generate(task, prior_attempt=draft)
return revised, "cascade-escalated"Khoảng cách giữa đoạn code này và HydraFusion không nằm ở pattern — nó nằm ở chất lượng của tín hiệu độ tin cậy. GitHub đang huấn luyện tín hiệu đó dựa trên các benchmark năng lực thực tế xuyên nhà cung cấp; phần lớn chúng ta phải chịu đựng với điểm tự tin tự báo cáo hoặc một cổng static-analysis dễ vỡ. Đó là phần đáng theo dõi khi tính năng này ra khỏi giai đoạn research preview: không phải bản thân pattern điều phối — thứ mà bất kỳ team nào cũng có thể sao chép ngay hôm nay — mà là liệu model độ tin cậy dùng để kích hoạt escalation có được công bố hay vẫn là lợi thế nội bộ của GitHub.
Điều rút ra cho team bạn
Nếu bạn đã tự xây một router, HydraFusion xác nhận kiến trúc này đúng — cascade thắng single-model cả về chi phí lẫn chất lượng khi cổng độ tin cậy đủ tốt. Nếu bạn chưa có, đây là một cú hích tốt để xây một cái, dù chỉ là phiên bản thô, thay vì mặc định mọi request đều dùng model đắt nhất “cho an toàn”. Những team gặp rắc rối ở đây sẽ không phải là những team dùng HydraFusion — mà là những team thấy dòng “giảm chi phí 36-67%” trong một blog post của vendor rồi mặc định nó sẽ áp dụng y hệt cho workload của mình mà không đo đạc lại trên phân bố tác vụ thực tế của họ trước.