OpenRouter ra mắt Fusion: Hệ thống kết hợp nhiều mô hình AI để tối ưu hóa độ chính xác

Fusion là mô hình tổng hợp của chúng tôi. Nó nhận một prompt và biến nó thành một cuộc tranh luận ngắn giữa nhiều mô hình. Chúng tôi gửi prompt của bạn đến một hội đồng các mô hình chuyên gia cùng lúc, và một giám khảo sẽ so sánh mọi phản hồi để mô hình gọi có thể viết ra một câu trả lời cuối cùng duy nhất.

Với Fusion, bạn đánh đổi một phần tốc độ và token để lấy chất lượng. Trang này bao gồm những gì Fusion thực hiện, chi phí, thời điểm nó vượt trội hơn một mô hình đơn lẻ và thời điểm thì không.

Tóm tắt (Tl;dr)

OpenRouter Fusion là gì?

Fusion là một hệ thống suy luận tổng hợp cho phép mô hình tiếp cận khả năng thảo luận đa mô hình. Khi mô hình gọi Fusion, nhiều mô hình sẽ trả lời prompt song song. Một giám khảo sẽ so sánh các phản hồi của chúng và tạo ra phân tích có cấu trúc, sau đó được sử dụng để tạo ra câu trả lời cuối cùng.

Điều đó làm cho Fusion khác biệt so với một lệnh gọi mô hình đơn lẻ. Một lệnh gọi đơn lẻ tuân theo con đường suy luận của một mô hình. Fusion có thể mang nhiều con đường suy luận, lựa chọn nguồn và cách diễn giải vào cùng một phản hồi.

Fusion và auto-routing phục vụ các công việc khác nhau. Auto-routing chọn một mô hình cho yêu cầu của bạn bằng cách phân loại loại tác vụ của prompt và chọn mô hình mà cộng đồng OpenRouter chi tiêu nhiều nhất cho loại tác vụ đó. Fusion kết hợp nhiều mô hình và hòa trộn các câu trả lời của chúng, và nó có thể tạo ra câu trả lời mạnh mẽ hơn bất kỳ thành viên nào trong hội đồng có thể đưa ra.

Cách thức hoạt động của OpenRouter Fusion

Fusion thêm một vòng lặp thảo luận vào bên trong một yêu cầu mô hình thông thường.

Quy trình này có bốn giai đoạn:

Công việc của giám khảo là so sánh thay vì bỏ phiếu đơn thuần. Ba mô hình lặp lại cùng một tuyên bố không có căn cứ sẽ không tự động làm cho tuyên bố đó trở nên đúng đắn. Giám khảo cũng có thể làm nổi bật một điểm hữu ích chỉ xuất hiện trong một phản hồi hoặc xác định một lỗ hổng mà mọi thành viên trong hội đồng đều bỏ lỡ.

Chất lượng tăng lên từ đâu

Fusion hưởng lợi từ sự đa dạng giữa các mô hình và sự biến thiên giữa các lần chạy riêng biệt. Các mô hình khác nhau có thể chọn các phương pháp khác nhau, chú ý đến các ràng buộc khác nhau hoặc truy xuất các nguồn khác nhau. Ngay cả hai lần chạy của cùng một mô hình cũng có thể đi theo các con đường suy luận khác nhau và thực hiện các lệnh gọi công cụ khác nhau.

Chúng tôi đã kiểm tra hiệu ứng thứ hai đó bằng cách ghép nối Claude Opus 4.8 với một lần chạy Opus 4.8 khác và sử dụng cùng một mô hình để tổng hợp. Cấu hình tổng hợp đạt 65,5% trên lần chạy benchmark DRACO của chúng tôi, so với 58,8% cho một lần chạy Opus 4.8 đơn lẻ. Mức cải thiện 6,7 điểm đó cho thấy quá trình so sánh và tổng hợp mang lại giá trị đáng kể ngay cả khi không có sự đa dạng về mô hình.

Ensembling đa mô hình là một kỹ thuật đã được thiết lập. Giá trị sản phẩm của Fusion nằm ở tính vận hành. Bạn có thể thêm một hội đồng, giám khảo, công cụ và vòng lặp tổng hợp thông qua một model slug hoặc server tool thay vì tự xây dựng và duy trì sự điều phối đó.

Fusion so với một mô hình đơn lẻ

Fusion có thể cải thiện các câu trả lời khó, nhưng nó thực hiện điều đó bằng cách làm nhiều việc hơn.

Chất lượng phụ thuộc vào tác vụ

Trên DRACO, một benchmark nghiên cứu chuyên sâu của Perplexity AI, một hội đồng Fusion tiết kiệm sử dụng Gemini 3 Flash, Kimi K2.6 và DeepSeek V4 Pro đạt khoảng 64,7% so với khoảng 65,3% của Claude Fable 5 khi chạy độc lập. Kết quả dựa trên Fable phản ánh 93 trên 100 tác vụ do các bộ lọc nội dung, vì vậy việc so sánh trực tiếp có phần hơi khập khiễng.

DRACO đo lường nghiên cứu chuyên sâu, không phải lập trình thô hay trò chuyện thông thường. Quá trình tổng hợp của Fusion thường giúp ích nhiều nhất cho các prompt nghiên cứu và phân tích, nơi nhiều quan điểm thực sự làm sắc bén câu trả lời. Đừng cho rằng biên độ tương tự áp dụng cho mọi tác vụ.

Nhiều token hơn, nhưng chi phí cho mỗi tác vụ vẫn có thể tối ưu hơn

Fusion phải trả phí cho nhiều lệnh gọi mô hình cộng với giám khảo, vì vậy một yêu cầu đơn lẻ sử dụng nhiều token hơn một lệnh gọi mô hình đơn lẻ. Tuy nhiên, chi phí cho mỗi lệnh gọi không phải lúc nào cũng là con số quan trọng. Chi phí cho mỗi câu trả lời đúng thường quan trọng hơn.

Nếu một lệnh gọi Fusion trả về câu trả lời đúng trong khi một mô hình rẻ hơn cần ba lần thử, một lần chạy lại và một người kiểm tra, thì Fusion có thể rẻ hơn trên toàn bộ tác vụ. Hãy tính tổng chi phí để đạt được kết quả, không phải giá của một yêu cầu. Trang mô hình Fusion của chúng tôi có chi phí hiện tại.

Độ trễ kéo dài gấp hai đến ba lần

Các lệnh gọi Fusion thường mất thời gian gấp hai đến ba lần so với một lệnh gọi mô hình đơn lẻ tiêu chuẩn. Hội đồng chạy đồng thời, vì vậy bạn không phải đợi từng mô hình theo trình tự, nhưng bạn vẫn phải đợi thành viên chậm nhất trong hội đồng và sau đó là giám khảo. Độ trễ đó thường loại trừ các ứng dụng trò chuyện, tự động hoàn thành và các con đường thời gian thực khác.

Không mang tính tất định theo thiết kế

Một hội đồng cộng với một bước tổng hợp có thể trả về các kết quả khác nhau giữa các lần chạy. Đó là do thiết kế. Điều này ổn đối với một tác vụ nghiên cứu dùng một lần, nhưng nó trở thành vấn đề khi bạn cần đầu ra có thể lặp lại, như các bộ đánh giá, kiểm thử hồi quy hoặc bất kỳ kiểm tra nào so sánh kết quả hôm nay với hôm qua.

Khi nào nên sử dụng Fusion và khi nào nên bỏ qua

Mô hình sản xuất mạnh mẽ nhất là leo thang có chọn lọc. Hãy để một mô hình xử lý trực tiếp các công việc thường ngày và gọi Fusion cho tập hợp nhỏ các prompt xứng đáng được xem xét kỹ lưỡng hơn. Để leo thang từng bước lên một mô hình mạnh hơn, hãy xem công cụ server tool Advisor.

Sử dụng nó cho các prompt kiểu nghiên cứu, rủi ro cao, nơi việc sai sót là rất đắt đỏ

Các câu hỏi nghiên cứu, đánh giá chuyên gia, so sánh và tóm tắt thẩm định, bất cứ nơi nào độ chính xác là ưu tiên hàng đầu và việc sửa lỗi sau đó tiêu tốn thời gian hoặc tiền bạc thực tế. Trong thực tế, hãy nghĩ đến việc tóm tắt một lĩnh vực cạnh tranh từ hàng chục nguồn hiện tại trước khi bạn cam kết thực hiện một cuộc gọi chiến lược.

Sử dụng nó khi bạn phải tự mình thăm dò nhiều mô hình theo cách thủ công

Nếu quy trình làm việc hiện tại của bạn là hỏi ba mô hình cùng một câu hỏi và tự so sánh các câu trả lời, thì Fusion đang thực hiện chính xác công việc đó. Giám khảo cũng so sánh các câu trả lời nhất quán hơn so với việc đánh giá thủ công.

Bỏ qua nó đối với các con đường tương tác nhạy cảm với độ trễ hoặc có QPS cao

Khi người dùng đang chờ phản hồi, độ trễ gấp hai đến ba lần là quá lâu. Trong thực tế, điều này có nghĩa là chatbot khách hàng hoặc tự động hoàn thành mã nội dòng.

Bỏ qua nó đối với các khối lượng công việc nhạy cảm về khả năng tái lập

Các bộ đánh giá (evals), bộ kiểm thử hồi quy và bất cứ thứ gì cần kết quả ổn định qua các lần chạy. Tính không tất định làm cho các so sánh đó không đáng tin cậy. Trong thực tế, đó là một quy trình CI kiểm tra xem đầu ra của LLM có thay đổi hay không.

Bỏ qua nó đối với các tác vụ đơn giản, được xác định rõ ràng mà một mô hình tầm trung đơn lẻ đã xử lý tốt

Nếu một mô hình tầm trung trả về câu trả lời đúng ngay hôm nay, thì một hội đồng chỉ làm tăng chi phí và độ trễ mà không mang lại lợi ích thực sự. Trong thực tế, đó là phân loại, trích xuất, viết lại ngắn và chuyển đổi định dạng.