Sakana AI ra Fugu Max và Fugu Ultra v2, dùng nhiều model phối hợp thay vì một model khổng lồ

Ngày 11/09/2026, Sakana AI phát hành Fugu Max và Fugu Ultra v2, hai cấu hình mới của hệ thống AI mà hãng mô tả như một “model” duy nhất ở phía người dùng nhưng bên trong có thể phối hợp nhiều model mở và model chuyên biệt. Thay vì đặt toàn bộ năng lực vào một backbone khổng lồ, Fugu dùng orchestration để chọn và kết hợp năng lực phù hợp cho từng tác vụ.

Theo thông báo chính thức của Sakana AI, Fugu Max tập trung vào điểm cân bằng giữa chi phí và chất lượng, còn Fugu Ultra v2 hướng tới năng lực cao nhất cho reasoning, coding và các workflow agentic dài hơn. Đây là một hướng tiếp cận đáng chú ý vì nó biến “chọn model” từ quyết định của developer thành một phần của chính lớp inference.

Fugu Max và Fugu Ultra v2 khác nhau ở đâu?

Hai sản phẩm dùng cùng triết lý orchestration nhưng được tối ưu theo hai mục tiêu khác nhau. Fugu Max ưu tiên hiệu quả kinh tế; Fugu Ultra v2 chấp nhận chi phí cao hơn để đẩy chất lượng trên các tác vụ khó.

• Fugu Max: tối ưu cost-performance, giá công bố $2/triệu input token và $6/triệu output token; cached input $0,25/triệu token.
• Fugu Ultra v2: tối ưu peak capability, giá chuẩn $5/triệu input token và $30/triệu output token.
• Context lớn hơn 272K token với Ultra v2: Sakana niêm yết $10/triệu input và $45/triệu output; cached input tăng theo tier.

Giá có thể thay đổi, vì vậy developer nên kiểm tra bảng giá hiện hành trước khi đưa vào production.

Điểm khác biệt của Fugu nằm ở lớp orchestration, không phải một backbone cố định

Một model API truyền thống thường gắn với một backbone xác định: cùng tên model, cùng kiến trúc và cùng tập weights. Fugu được Sakana đóng gói theo cách khác. Developer gọi một endpoint như gọi một model, còn lớp orchestration phía sau có thể khai thác nhiều model khác nhau để xử lý bài toán.

Điều này khiến Fugu gần với một compound AI system hơn là cách hiểu cổ điển về một LLM đơn lẻ. Giá trị của sản phẩm không chỉ nằm ở từng model thành phần, mà ở khả năng quyết định nên dùng năng lực nào, khi nào và phối hợp kết quả ra sao.

• Fugu Max: mở rộng pool model mở và model chuyên biệt để tìm điểm cân bằng tốt hơn giữa chi phí và chất lượng.
• Fugu Ultra v2: ưu tiên cấu hình có năng lực mạnh hơn cho reasoning, coding và agentic workload.
• Một API surface: developer không phải tự viết router riêng cho từng nhà cung cấp hoặc từng model thành phần.
• Model pool có thể thay đổi: chất lượng của lớp orchestration trở thành một phần quan trọng của sản phẩm, thay vì chỉ nhìn vào một checkpoint.

Fugu Max mở rộng “Pareto frontier” giữa chất lượng và chi phí

Sakana dùng khái niệm Pareto frontier để mô tả mục tiêu của Fugu Max: với cùng mức chi phí, hệ thống cố gắng đạt chất lượng cao hơn; hoặc với cùng mức chất lượng, giảm chi phí. Đây là cách đánh giá phù hợp với orchestration vì một router tốt không nhất thiết phải luôn gọi model mạnh nhất.

Theo kết quả do Sakana công bố, Fugu Max mở rộng Pareto frontier trên 7 trong 10 benchmark mà hãng thử nghiệm. Đây là benchmark do nhà phát triển tự báo cáo, không phải đánh giá độc lập, nên nên đọc như bằng chứng về hướng tối ưu của sản phẩm hơn là kết luận rằng Fugu Max luôn tốt hơn mọi model đơn lẻ.

Sakana cũng cho biết pool của Fugu Max đã được mở rộng với thêm các model open-weight và model chuyên biệt, trong đó có NVIDIA Nemotron. Việc bổ sung model mới vào pool có thể cải thiện một số task mà không cần đổi API ở phía ứng dụng.

Fugu Ultra v2 nhắm tới reasoning và coding khó hơn

Nếu Fugu Max là lựa chọn thiên về hiệu quả, Ultra v2 là cấu hình nhắm tới chất lượng cao nhất trong hệ thống Fugu hiện tại. Sakana báo cáo Ultra v2 đạt best hoặc joint-best trên 5/8 benchmark trong bộ đánh giá của hãng và nằm top 2 ở 7/8 benchmark.

• Chartography: Sakana báo cáo điểm 48,3.
• DeepSWE: Sakana báo cáo điểm 74,3.
• Các số liệu này là vendor-reported, không phải phép đo độc lập.

Một chi tiết đáng lưu ý là Fugu Ultra v2 không đơn giản “gom tất cả model mạnh nhất trên thị trường”. Sakana cho biết một số model như Claude Fable 5/5.1 và GPT-6 Astra không nằm trong pool Ultra v2. Vì vậy, kết quả của Fugu phản ánh cả chất lượng của model pool lẫn chiến lược orchestration mà Sakana xây dựng.

Fugu khác Project HydraFusion của GitHub ở điểm nào?

Bot.io.vn trước đó đã viết về Project HydraFusion của GitHub, một research preview cho phép Copilot CLI phối hợp nhiều model theo các workflow như Single, Cascade hoặc Critique. Cả HydraFusion và Fugu đều cho thấy xu hướng chuyển từ “chọn một model duy nhất” sang “điều phối nhiều model”.

Khác biệt nằm ở bề mặt sản phẩm. HydraFusion là lớp orchestration nằm bên trong trải nghiệm GitHub Copilot. Fugu được Sakana cung cấp trực tiếp như một model/API, vì vậy developer có thể tích hợp vào ứng dụng mà không cần dùng một coding assistant cụ thể.

Điểm chung quan trọng hơn là cả hai đều đặt câu hỏi mới cho hạ tầng AI: thay vì chỉ hỏi “model nào thông minh nhất?”, hệ thống phải trả lời “model nào phù hợp nhất cho bước hiện tại, với ngân sách và độ trễ đang có?”.

OpenAI-compatible API giúp Fugu dễ thử nghiệm hơn

Sakana cung cấp Fugu qua API tương thích kiểu OpenAI. Với nhiều stack hiện nay, điều này giảm đáng kể chi phí tích hợp ban đầu vì ứng dụng có thể giữ cấu trúc request/response quen thuộc và chủ yếu thay endpoint, credentials cùng tên model.

• Có thể thử Fugu trong các ứng dụng chat, RAG hoặc agent đã dùng OpenAI-compatible client.
• Có thể A/B test Fugu Max với một model đơn lẻ mà không phải viết lại toàn bộ application layer.
• Có thể dùng Ultra v2 cho các bước khó và Max cho phần lớn traffic nếu đội ngũ muốn tự thiết kế chiến lược chi phí.

Danh sách model và trạng thái hiện hành được Sakana công bố tại console của hãng. Với hệ thống orchestration, việc theo dõi model pool quan trọng hơn bình thường vì các thay đổi phía sau có thể ảnh hưởng tới chất lượng, latency hoặc hành vi của cùng một API surface.

Điều developer cần theo dõi khi dùng một model orchestration

Fugu đơn giản hóa việc chọn model ở phía ứng dụng, nhưng nó không xóa đi nhu cầu observability. Ngược lại, khi một request có thể được xử lý bằng nhiều model hoặc chiến lược khác nhau, đội ngũ production cần theo dõi kỹ chất lượng đầu ra, chi phí, latency và độ ổn định theo từng loại task.

• Tính lặp lại: cùng một prompt không nên mặc định được hiểu là luôn đi qua cùng một model thành phần.
• Chi phí: so sánh chi phí end-to-end của workflow, không chỉ đơn giá token.
• Độ trễ: orchestration có thể thêm bước quyết định hoặc phối hợp, nên latency thực tế cần được đo trên workload của chính ứng dụng.
• Đánh giá: benchmark của nhà cung cấp là điểm khởi đầu; production eval vẫn phải dùng dữ liệu và tiêu chí riêng.

Fugu Max đáng chú ý vì biến model routing thành một sản phẩm hoàn chỉnh

Sự xuất hiện của Fugu Max và Fugu Ultra v2 cho thấy một hướng cạnh tranh mới trong AI: năng lực không nhất thiết đến từ việc xây một model ngày càng lớn. Một lớp orchestration đủ tốt có thể khai thác nhiều model chuyên môn hóa để đạt mục tiêu chi phí, chất lượng hoặc độ trễ khác nhau.

Xu hướng này cũng liên quan trực tiếp tới các model agentic mới như Meta Muse Spark 1.3 hay DeepSeek-V4.1-Flash: khi agent chạy nhiều bước, gọi tool và xử lý ngữ cảnh dài, việc dùng một model cho mọi bước có thể không còn là lựa chọn kinh tế nhất.

Fugu chưa chứng minh rằng orchestration luôn thắng model đơn lẻ trên mọi workload. Nhưng release ngày 11/09 cho thấy Sakana đang cố biến multi-model routing từ một kỹ thuật hạ tầng thành một abstraction mà developer có thể mua và dùng như một model bình thường. Nếu cách tiếp cận này giữ được chất lượng khi pool thay đổi, đây có thể là một trong những hướng quan trọng của hạ tầng AI Agent trong thời gian tới.