OpenRouter Fusion, zor promptları en fazla sekiz modelden oluşan değerlendirici bir panele taşıyor

Fusion ne yapıyor

OpenRouter, gayri resmi "birkaç modele sor ve sonuçları elle uzlaştır" iş akışını bir API'ye dönüştüren bileşik bir inference yolu olan Fusion'ı yayınladı. 10 Eylül açıklamasını ele alan bir dev.to yazısına göre Fusion dört aşamada çalışıyor. Bir çağıran model önce promptu değerlendiriyor ve doğrudan yanıtlamaya mı karar veriyor yoksa deliberasyonu mu tetikleyeceğini belirliyor. Ardından bir ile sekiz modelden oluşan bir panel paralel olarak yanıt veriyor; panel üyeleri OpenRouter'ın web search ve web fetch araçlarını kullanabiliyor. Bir judge model yanıtları karşılaştırıyor; yanıtların nerede uzlaştığına, nerede çeliştiğine, her birinin kısmen neyi kapsadığına ve benzersiz içgörülere veya kör noktalara bakıyor. Son olarak çağıran model bu bulguları, uygulamanın döndürdüğü tek bir yanıta dönüştürecek şekilde sentezliyor.

dev.to yazarı otomatik yönlendirmeyle (auto-routing) net bir çizgi çekiyor. Auto-routing bir istek için tek bir model seçer; Fusion ise birkaç akıl yürütme yolunu birleştirir ve sentezden önce yapılandırılmış bir karşılaştırmaya zorlar. OpenRouter'ın belirttiğine göre, aynı frontier modelin kendisiyle eşleştirilmesi bile tek başına çalıştırmaya kıyasla deep-research puanlarını iyileştirebiliyor; bu da karşılaştırma adımının gerçekten iş yaptığını, tek etkenin "daha fazla model" olmadığını gösteriyor.

Deliberasyonun maliyeti

Bu ödünleşim açıklamada açıkça ortaya konuyor. Varsayılan üç modellik bir panel, aynı prompt üzerinde tek bir completion'a kıyasla kabaca dört ila beş kat daha pahalı ve çağrılar çoğu zaman iki ila üç kat daha uzun sürüyor. Kalite kazanımları özellikle araştırma tarzı işlerde yoğunlaşırken, chat, autocomplete ve dar etkileşimli döngüler gecikmeyi genellikle kaldıramıyor.

Nasıl çağrılır

En basit giriş noktası openrouter/fusion model slug'ı. Ek yapılandırma olmadan Fusion varsayılan bir Quality paneli kullanır ve deliberasyonun gerekli olup olmadığına modelin karar vermesine izin verir. Geliştiriciler tool_choice değerini "required" olarak ayarlayarak Fusion'ı zorunlu kılabilir, bir preset seçebilir ve judge modeli değiştirebilir. Açıklamada üç preset adı geçiyor: en güçlü genel panel için general-high, daha ucuz panel üyelerini bir frontier judge ile eşleştiren general-budget ve benzer yanıt süreleri etrafında ayarlanmış bir panel içeren general-fast. Aynı panel-judge-sentez hattı, kendi dış modeliniz zaten başka araçlar taşıyorken openrouter:fusion server aracı eklenerek de kullanılabilir.

dev.to yazısının temel önerisi, yükseltme (escalation) politikasını efsane bilgisinden çok yapılandırma olarak ele almak: preset seçimleri ve judge değişiklikleri, bir sohbet odasındaki denemede bırakılmamalı; git'te gözden geçirilen dosyalara sabitlenmelidir.

Ne zaman yükseltmeli, ne zaman yükseltmemeli

Bu rehber, sevk edilen ürünlere düzgün şekilde eşleniyor. Yanılmak pahalıysa yükseltin: araştırma özetleri, uzman eleştirisi, due-diligence karşılaştırmaları veya mühendislik haftalarını bağlayan mimari kararlar. Ayrıca bir ekip zaten aynı promptu birkaç modele yapıştırıp yanıtları bir belgede birleştiriyorsa ya da istek başına maliyettense kabul edilen sonuç başına maliyet önemliyse yükseltin; çünkü tutan tek bir Fusion çağrısı, birkaç ucuz yeniden deneme artı insanla düzeltmeden daha iyi olabilir.

Gecikme ürünün kendisiyse Fusion'ı atlayın: müşteri sohbeti, satır içi tamamlama veya yüksek hacimli etkileşimli yollar gibi. Yeniden üretilebilirlik önemliyse de atlayın, çünkü panel artı sentez hattı tasarımdan doğası gereği deterministik değil; bu da onu zamanla çıktıları karşılaştıran eval'ler, regression suite'leri ve CI kontrolleri için kötü bir tercih yapıyor. Orta seviye tek bir model görevi zaten hallediyorsa da atlayın: sınıflandırma, çıkarma, kısa yeniden yazımlar ve format dönüşümü gibi.

Yazı ayrıca, Fusion'ı müşteriye dönük akışlara bağlamadan önce bir sahiplenme kontrol listesi öneriyor: hangi görev sınıflarının onu tetikleyebileceğini tanımlayan yükseltme koşulları, yüzey başına preset politikası, kesin zaman aşımı ve fallback'lerle gecikme bütçeleri, istek ve kullanıcı başına maliyet üst sınırları, judge'ın metninin asla gözden geçirilmeden birleştirilmemesi için kabul kontrolleri ve Fusion'ın çalışıp çalışmadığının, hangi preset ile çalıştığının ve bir insanın sonucu kabul edip etmediğinin günlüğe kaydı.

Neden önemli

Fusion, birçok ekibin zaten elle yürüttüğü bir iş akışını resmileştiriyor ve ona açık maliyet ve gecikme özellikleri veriyor: yapılandırılmış çok modelli akıl yürütme karşılığında bilinçli bir dört-ila-beş-kat completion çarpanı. Ayrıca inference'ı "istek başına bir model seç" yaklaşımından, kiralık bir yetenek olarak birleştirilebilir deliberasyona doğru kaydırıyor. Üreticiler için pratik sonuç yönetişim: hangi azınlık promptların paneli hak ettiğine karar vermek ve bu kuralı depoya kodlamak, böylece agent'lar bir oturum ortasında yükseltme politikası uyduramasın.