OpenRouter Fusion API

 (openrouter.ai)
7 điểm bởi GN⁺ 6 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Khởi nguồn từ phát hiện rằng khi tổng hợp (synthesize) kết quả từ nhiều mô hình, hiệu năng có thể vượt xa việc chỉ dùng riêng từng mô hình
  • Phương pháp thảo luận đa mô hình (multi-model deliberation), trong đó nhiều mô hình chuyên gia phân tích song song một prompt, sau đó mô hình giám khảo (judge model) tổng hợp kết quả để viết câu trả lời cuối cùng
  • Các mô hình trong panel thực hiện phân tích song song với web search và web fetch được bật, còn mô hình giám khảo sắp xếp thành phân tích có cấu trúc về đồng thuận, mâu thuẫn, mức độ trùng khớp một phần, insight độc đáo, điểm mù
  • Mặc định là preset Quality; có thể chuyển sang preset Budget để dùng mô hình rẻ hơn, hoặc dùng các trường plugin fusion để định nghĩa lại hoàn toàn panel và giám khảo
  • Phù hợp cho các tình huống như nghiên cứu, phản biện chuyên gia, nơi một mô hình đơn lẻ là chưa đủ và chi phí của câu trả lời sai còn lớn hơn chi phí hoàn thiện tăng thêm
  • Vì chạy toàn bộ thành viên panel và cả lời gọi giám khảo, chi phí mỗi request được tính theo tổng các completion riêng lẻ, không phải như một mô hình đơn

Cách hoạt động

  • Biến một prompt đơn thành một quy trình thảo luận đa mô hình quy mô nhỏ
    • Panel các mô hình chuyên gia phân tích prompt song song với web search và web fetch được bật
    • Mô hình giám khảo tổng hợp phản hồi từ panel để tạo phân tích có cấu trúc theo đồng thuận (consensus), mâu thuẫn (contradictions), bao phủ một phần (partial coverage), insight độc đáo (unique insights), điểm mù (blind spots)
    • Dựa trên phân tích có cấu trúc đó, mô hình giám khảo viết câu trả lời cuối cùng

Cấu hình và thiết lập panel

  • Panel mặc định dùng preset Quality
    • Nếu muốn thành viên rẻ hơn, có thể chuyển sang preset Budget
    • Có thể ghi đè (override) hoàn toàn panel và giám khảo bằng các trường analysis_models và model của plugin fusion
  • Khuyến nghị dùng khi một mô hình đơn là chưa đủ
    • Phù hợp với nghiên cứu, phản biện chuyên gia, hoặc các lĩnh vực mà chi phí của câu trả lời sai vượt quá chi phí completion bổ sung

Giá và giới hạn

  • Vì chạy toàn bộ thành viên panel và cả lời gọi giám khảo, chi phí request được tính theo tổng các completion riêng lẻ, không dựa trên một mô hình đơn
    • Có thể kiểm tra các mô hình thực tế đã chạy trên trang Activity
  • Giới hạn context phụ thuộc vào các mô hình được chọn

Preset sử dụng 6 mô hình

  • Chất lượng cao nhất: Claude Opus, OpenAI GPT, Google Gemini Pro
  • Chi phí thấp nhất: Google Gemini Flash, DeepSeek V4 Flash, MoonshotAI Kimi

Công bố liên quan: "Fusion vượt qua hiệu năng frontier"

  • Là công cụ tổng hợp kết quả từ nhiều mô hình để vượt qua hiệu năng của từng mô hình đơn lẻ; có thể trực tiếp chọn panel mô hình tham gia và mô hình judge để hợp nhất kết quả rồi gọi như một mô hình duy nhất
  • Trong phép đo 100 tác vụ deep research của benchmark DRACO, panel liên tục vượt trội so với từng mô hình riêng lẻ
    • Tổ hợp Fable 5 + GPT-5.5 đạt 69.0%, vượt mọi mô hình đơn lẻ gồm cả Fable 5 độc lập (65.3%)
    • Panel chi phí thấp (Gemini 3 Flash + Kimi K2.6 + DeepSeek V4 Pro) đạt mức 50% chi phí nhưng tiến sát điểm Fable 5 trong phạm vi 1%, đồng thời vượt GPT-5.5 và Opus 4.8
  • Prompt được gửi song song tới các mô hình trong panel; judge phân tích điểm đồng thuận, mâu thuẫn, insight độc đáo và điểm mù, rồi mô hình được gọi viết câu trả lời cuối cùng dựa trên đó
  • Toàn bộ pipeline chạy ở server-side, nên có thể sử dụng theo cùng cách như khi gọi từng mô hình riêng lẻ
  • Ngay cả khi hợp nhất Opus 4.8 với chính nó, điểm cũng đạt 65.5%, tăng 6.7 điểm so với chạy đơn lẻ (58.8%), cho thấy hiệu quả của chính bước synthesis
  • Phát hiện rủi ro nhiễm bẩn khi các mô hình panel tìm rubric chấm điểm trên mạng; có thể chặn bằng cách áp dụng danh sách loại trừ web search·web fetch chỉ với một dòng cấu hình
  • Có 4 cách sử dụng: Chatroom (không cần code), Model slug (thay chuỗi), Server tool (mức kiểm soát cao nhất), Plugin (chỉ định panel)
  • Không phải là lựa chọn thay thế drop-in cho Fable; các tác vụ long-horizon vốn là thế mạnh của Fable không được đưa vào, và trong coding thì được dùng như công cụ gọi chọn lọc

Bài viết liên quan

1 bình luận

 
GN⁺ 6 giờ trước
Ý kiến trên Hacker News

  • Vài tháng trước tôi đã thử tạo Fusion bằng MCP dùng OpenRouter. Ý tưởng là đưa ra một “hội đồng chuyên gia” để tìm đến khi Claude bị chặn
    Sau rất nhiều thử nghiệm và benchmark, tôi thấy việc để một mô hình đánh giá câu trả lời của mô hình khác thực ra không cho ra câu trả lời tốt hơn. Cuối cùng thì về bản chất chỉ là hỏi “câu trả lời này giống với câu trả lời mà chính bạn sẽ đưa ra đến mức nào”, còn các vòng bổ sung hay những lời giải “hiển nhiên” nảy ra thì thực tế gần giống như tăng nhiệt độ. Tôi có tìm ra cách giải, nhưng chi phí thì đắt vô lý. Nếu hướng này được chú ý hơn, có thể tôi cũng sẽ công bố bản của mình

    • Prompt rất quan trọng. Nếu muốn lấy ý kiến từ các mô hình khác thì hiển nhiên phải để chúng tạo từ đầu với cùng một prompt rồi mới tổng hợp, còn nếu muốn thì cũng có thể cho chúng xử lý trên phản hồi sẵn có
      Tôi yêu cầu chúng tìm vấn đề một cách tường minh theo từng mức độ nghiêm trọng, rồi cho các vấn đề đó đi qua một hội đồng mô hình chấm định, sau đó chỉ sửa trong phản hồi gốc những gì vượt qua ngưỡng nhất định. Điều giúp kết quả cải thiện rõ rệt là yêu cầu mô hình chấm định đánh giá riêng theo trục tính chân thực và trục “mức độ hữu ích/có cần sửa hay không”. Vì nếu ép chúng phải tìm lỗi thì rốt cuộc sẽ sinh ra kiểu bắt bẻ vụn vặt, còn trục tính chân thực cũng tốt hơn để đánh giá các mô hình phát hiện vấn đề phù hợp với mục đích của tôi. Cách này được áp dụng một phần khi tạo các phần giải thích như ở đây: https://hanzirama.com/character/%E6%9D%A5#explain — giờ trang này đã trở thành một sản phẩm phụ nhỏ từ bộ công cụ đánh giá LLM của tôi. Nếu cần chất lượng cao nhất thì rất có thể phải cố định nhà cung cấp trên OpenRouter. Chỉ :exacto thôi thì khó có được kết quả tốt và lặp lại được, đặc biệt với các mô hình open-weight
    • Tôi từng thấy rằng nếu nói với mô hình chấm định rằng câu trả lời đến từ một LLM cục bộ nhỏ và yếu, nó sẽ mổ xẻ câu trả lời cực kỳ khắt khe. Tuy vậy tôi chưa làm một cách có hệ thống, nên không biết liệu điều này có khái quát được vượt ra ngoài cảm giác cá nhân của tôi hay không
      Không biết có ai khác cũng cảm thấy rằng nếu lừa LLM vào trạng thái “cảm thấy mình vượt trội” thì nó sẽ cư xử khá tệ hay không
    • Tôi đã làm một phiên bản thô của ý tưởng này vào năm 2024[0], và thấy thú vị là ý tưởng này vẫn tiếp tục tồn tại. Khi đó có thể đặt ngưỡng chất lượng, nhưng dường như không tạo khác biệt lớn, và các mô hình tuyến đầu gần như luôn đồng ý với nhau rồi chấm điểm câu trả lời rất cao
      Bây giờ cuộc chơi đã hoàn toàn khác so với 2 năm trước, nên đáng để xem lại. [0] https://github.com/Ceroxylon/konsensis
    • Tôi nghĩ điều này phụ thuộc vào việc câu trả lời có thể kiểm chứng được hay không
      Trong ứng dụng của tôi, tôi đã thử hai mô hình chấm định. Mô hình đầu tiên là mô hình chấm định cho một mô hình tùy biến CV; nó so sánh bản CV đầu ra với CV gốc và tin tuyển dụng rồi chấm mức độ phù hợp và tính trung thực trên thang 10 điểm, và nó hoạt động tốt, hữu ích. Mô hình thứ hai là mô hình rà soát cho một nền tảng bot giao dịch bằng LLM, dùng để rà soát quyết định của mô hình chính. Ở đây thì lại có thể phản tác dụng, vì bot phải xử lý sự mơ hồ, trừ khi nó bắt được những lỗi rõ ràng như phán đoán bằng giá nến sai hoặc BUY khi lẽ ra phải là SELL. Đầu tiên là độ trễ tăng thêm, khiến với Gemma 4 31B thì 30 giây thành 60 giây, tức gấp đôi. Ngoài ra, vì mô hình rà soát chỉ chạy với quyết định BUY/SELL chứ không chạy với HOLD, nên do độ trễ và chi phí, bot có thể trở nên quá thận trọng thay vì tăng số lượng giao dịch. Vì vậy, nếu câu trả lời không dễ kiểm chứng thì tôi nghĩ tốt hơn là xử lý một lần bằng mô hình tốt hơn, thay vì thêm mô hình rà soát. Khi đó cũng khó lý giải vì sao cần mô hình chấm định, và vì sao không để cùng một agent tự rà soát chính nó. Hơn nữa, nếu đọc văn bản suy luận của các mô hình có khả năng reasoning như Gemma 4, có thể thấy chúng vốn đã tự rà soát rồi. Nói cách khác, chúng đã làm hết sức ngay từ đầu nên việc rà soát lại không bổ sung nhiều thông tin. Đây là một thử nghiệm thú vị, nhưng phải đánh giá theo từng trường hợp
    • Tôi cũng có cùng trải nghiệm. Việc tìm ra một câu trả lời tốt hơn một cách khách quan khó hơn tưởng tượng, lại còn tốn kém và chậm

  • Tôi từng có một prompt dùng theo kiểu này chỉ với Claude Code
    Hãy review một vấn đề kiến trúc. Khởi chạy 10 agent, cho mỗi agent tạo một persona riêng, sau đó review _api.go và viết review vào reviews/-review.md. Mỗi agent đọc phần tóm tắt ở đầu từng review, rồi phản hồi theo kiểu round-robin với 3 review mà nó muốn vào response/--response.md. Sau đó viết phản biện cho các phản hồi vào rebuttals/-rebuttal.md. Cuối cùng, mỗi agent lại khởi chạy một agent khác để review review, phản hồi và phản biện của chính mình, rồi tổng hợp kết quả vào findings/-findings.md. Sau cùng, một agent khác gộp các kết quả lại và viết vào review-findings.md, trong đó đưa ra một bản cô đọng. Cách này hoạt động tốt cả với các mô hình tuyến đầu lẫn mô hình tự host cục bộ. Lần cuối tôi dùng là Qwen 3.5

    • Tôi không quen với việc dùng nhiều agent trong một luồng như vậy nên có vài điều muốn hỏi
      Bạn có xem lại toàn bộ các file được tạo ra để kiểm tra xem có hallucination không, hay chỉ xem file kết quả cô đọng cuối cùng? Tôi cũng tò mò liệu dụng ý ở đây có phải là để hallucination triệt tiêu lẫn nhau qua nhiều agent, cuối cùng chỉ còn lại sự thật hay không. Tôi cũng muốn biết liệu bạn đã từng thấy nội dung sai nghiêm trọng trong phiên bản cuối chưa. Tôi có lo về chi phí, nhưng nếu dùng mô hình tự host cục bộ thì phần đó có vẻ đỡ hơn. Tuy vậy, chẳng phải các mô hình tự host cục bộ vẫn còn gặp vấn đề với việc chạy lệnh cục bộ hoặc truy cập Internet sao? Nếu vậy thì có phải cách này chỉ chạy dựa trên ngữ cảnh của file đó mà không tham chiếu đến phần còn lại của dự án không
    • Cách này có vẻ nhiều cơ chế hơn khá nhiều so với việc chạy cùng một review n lần rồi gộp kết quả. Tôi tò mò vì sao bạn lại đi đến thiết kế như vậy

  • Bối cảnh nền nằm ở đây: Surpassing Frontier Performance with Fusion
    https://news.ycombinator.com/item?id=48525392
    Nơi có UI tốt hơn một chút là https://openrouter.ai/fusion. Fusion API của OpenRouter gửi yêu cầu đến nhiều mô hình cùng lúc, rồi một mô hình chấm/phán định sẽ gộp các câu trả lời để tạo ra phản hồi cuối cùng. Họ nói là mất nhiều thời gian hơn nhưng tăng hiệu năng đáng kể. Ít nhất là như vậy trên benchmark deep research mà họ đã thử. Preset Budget gồm 3 mô hình rẻ hơn, và trên benchmark đó cho kết quả gần ngang Fable trong khi chi phí bằng một nửa. Preset Quality gồm 3 mô hình đắt hơn, vượt Fable nhưng chi phí gấp đôi Fable. Đồ thị Pareto: https://openrouter.ai/blog/images/blog/fusion-benchmark-cost.... Điều thú vị là ngay cả khi hợp nhất cùng một mô hình với chính nó thì hiệu năng vẫn tăng. 2xOpus4.8 trên benchmark cho kết quả gần ngang Fable nhưng chi phí gấp đôi Fable. Trộn các mô hình khác nhau thì có thêm một ít lợi ích nữa. Có vẻ lợi ích chính đến từ tính toán ở thời điểm kiểm thử bổ sung. Mong sẽ có thêm nhiều nghiên cứu tập trung vào các mô hình rẻ mới ra gần đây, ví dụ như DSV4 được hợp nhất với chính nó hoặc với Mimo, và cũng muốn thấy sự đánh đổi giữa hợp nhất như một dạng tính toán thời điểm kiểm thử song song với việc tăng lượng suy luận hoặc tăng số lượt

    • Việc “ngay cả khi hợp nhất cùng một mô hình với chính nó thì hiệu năng vẫn tăng” là cách làm khá phổ biến vào thời GPT-2 sang GPT-3
      Về bản chất, đó là rút thêm mẫu từ không gian đầu ra khả dĩ. Nếu mô hình có thể làm được một tác vụ với xác suất 60%, thì chỉ cần lấy 5–10 mẫu rồi áp dụng kiểu đa số phiếu. Khi độ chính xác mô hình tăng lên trên những bài toán dễ gộp kết quả thì cách này ít dùng hơn, nhưng nếu có bộ phán định phức tạp hơn, tức một LLM đủ giỏi, thì chỉ cần lấy mẫu nhiều hơn trong không gian đầu ra và chọn ra phần tốt vẫn có thể tiếp tục cải thiện hiệu năng
    • Việc panel Fable 5 + GPT 5.5 vượt khá xa hiệu năng frontier của từng mô hình đơn lẻ, nhưng khi thêm Gemini vào thì panel ba mô hình lại không tốt hơn mà còn tệ đi là điều thú vị
      Với tôi điều đó nghe như Gemini yếu hơn trên tác vụ này, nhưng lại giỏi hơn trong việc thuyết phục mô hình phán định bằng lời giải của chính nó. Và việc panel gồm hai Opus 4.8 gần như chính xác bằng một Fable 5 cũng có mùi đáng ngờ. Có cách nào biết liệu Anthropic có đang âm thầm làm kiểu này ở hậu trường không?
    • Hơi tiếc là họ gần như không bàn đến việc mất thêm bao lâu do bước tổng hợp. Với benchmark deep research thì có thể không quá quan trọng, nhưng sẽ rất thú vị nếu áp dụng vào tác vụ lập trình
    • Tôi không biết điều này còn đúng với các mô hình hiện tại không, nhưng trong nghiên cứu của Microsoft vài thế hệ trước, bắt mô hình lặp lại N lần giúp hiệu năng tăng mạnh, và điểm tối ưu là lặp 4 lần

  • Tôi đã chạy một đánh giá nhanh để xem nó khác biệt về mặt chất lượng thế nào so với việc gọi trực tiếp Opus 4.7 hoặc GPT 5.5
    Đúng như dự đoán, Fusion chậm hơn 7 lần và đắt hơn 4 lần. Đây không phải lời chê, tôi chỉ xem Fusion là thứ thuộc nhóm “chỉ dùng khi thực sự cần”. https://3fpi5avcqq.evvl.io/

    • Fusion trông thực sự rất phù hợp để làm đối tượng chưng cất
    • Cảm ơn vì đã chia sẻ. Tốc độ là mối lo lớn nhất của tôi, mà bên đó lại không nhắc đến phần này
    • Tôi tò mò không biết bên dưới đã dùng những mô hình nào. Nếu dùng mặc định Quality trong giao diện, thì cấu hình sẽ là 3 mô hình frontier và một trong số đó làm bộ phán định, nên chi phí khoảng gấp 4 là hợp lý
      Có lẽ ý tưởng cốt lõi là dùng Fusion với các mô hình đơn giản và rẻ hơn
    • Tôi thấy điều này khá trái trực giác. Có lẽ không dễ để tìm ra khuôn khổ và cấu trúc phù hợp để nó hoạt động tốt. Các mô hình thực sự không thích phối hợp với nhau
      Tôi tò mò phiên bản của họ sẽ trụ vững thế nào trong sử dụng thực tế

  • Tôi đã nghĩ khá nhiều về vấn đề này, và cách đơn giản hóa để hiểu là xem mỗi mô hình như một phân bố hình chuông nằm trên tri thức của loài người, với phân bố khác nhau giữa các mô hình
    Khi dùng nhiều mô hình, bạn có thể thay đổi phân bố của mô hình khác bằng văn bản nằm ngoài đường cong gốc của nó. Nhưng nghĩ lại thì SFP và RL có lẽ đã thay đổi phân bố văn bản gốc đủ nhiều để đặt câu hỏi liệu đầu ra kết hợp của các mô hình có thật sự đủ đa dạng để tạo ra thứ gì đó tốt hơn, hay chỉ trở thành một buồng vang. Tôi chưa có cách chứng minh, nhưng tôi tin là không phải vậy

  • Về mặt giai thoại với Fusion, tôi đã đưa cùng những truy vấn từng dùng cho Fable vào OpenRouter Fusion và kết quả tệ hơn
    Fable nắm bắt được phần nào những tầng kiến thức/trí tuệ rất sâu, không chỉ đưa ra câu trả lời nghe hợp lý mà còn đề xuất thứ tự ưu tiên cho các hạng mục cần xử lý và bảo nên bỏ một vài hạng mục, điều mà với tôi khá hợp lý. Trong khi đó, Fusion cho cảm giác giống như đang đa dạng hóa nhẹ cùng một kiểu câu trả lời mà các mô hình SOTA trước Fable từng đưa ra, và trong bài test rất hạn chế của tôi khi còn có quyền dùng Fable, nó không chạm tới được độ sâu mà Fable đạt tới

  • Cuối tuần qua, được truyền cảm hứng từ mô hình OpenRouter Fusion mới, tôi đã làm thử để xem có thể chạy thứ này trong Claude Code không, và có thể biến nó thành thứ mà người khác cũng dễ thử không
    Tôi đã tạo ra claude-fusion-launcher — chạy Claude Code trên một panel mô hình thay vì một mô hình đơn lẻ. Nó cũng hiển thị chi phí. https://github.com/smorinlabs/claude-fusion-launcher

    • Nó có đắt lên rất nhanh không? Mấy prompt đơn lẻ tôi thử trên website gần như tốn 1 đô mỗi prompt

  • Tôi tự hỏi liệu việc tái tạo lại cùng một prompt nhiều lần với cùng một mô hình ở nhiệt độ cao hơn có tương đương với việc chạy các mô hình khác nhau không
    Tôi nghi rằng phần lớn sự biến thiên cảm nhận được giữa các mô hình frontier khác nhau thực ra đến từ tính ngẫu nhiên khi nhiệt độ khác 0. Có vẻ các mô hình được huấn luyện để trả về số lượng mục tròn trịa, đẹp mắt như 5, 10, 15. Có thể là do nhiễu từ dữ liệu tài liệu marketing. Thêm nữa, khả năng hồi tưởng trong ngữ cảnh lớn vẫn còn xa mới đạt 100%. Vậy nên nếu trong code có 27 lỗi, thì dù dùng nhiều mô hình hay gọi lặp lại cùng một mô hình, mỗi lần chạy bạn vẫn có thể phát hiện ra 10 vấn đề khác nhau trong số 27 lỗi đó

  • Tôi tò mò không biết lĩnh vực này có nghiên cứu chính thức nào hay không. Tôi cũng đã thử một vài biến thể của cách tiếp cận này, nhưng khó có thể tự tin nói rằng kết quả tốt hơn.
    Tôi lo rằng nó có thể giống như hỏi riêng 2~3 tư vấn viên về chiến lược tối ưu cho doanh nghiệp. Tôi không chắc việc gộp các câu trả lời lại có thực sự tạo ra điều gì tốt hơn hay không.

  • Tôi cũng đã phát hành tính năng tương tự trong TrustedRouter của mình dưới dạng mã nguồn mở, thậm chí còn áp dụng mã hóa đầu cuối: https://trustedrouter.com/

    • Thật tốt khi có thể thấy một cam kết bảo vệ quyền riêng tư thực sự. Tôi đang tốn rất nhiều thời gian để đọc mãi những điều khoản của nhà cung cấp mang tính né tránh và mơ hồ.