GitHub zpřístupnil aplikaci Copilot Fusion obecně a posunul směrování více modelů z oblasti infrastruktury do každodenního pracovního postupu kódování. Namísto požadavku na vývojáře, aby vybral jeden pevný model, může Fusion vybrat a zorganizovat jeden nebo více modelů pro požadavek.
Na vydání záleží mimo GitHub druhého pilota. Ukazuje, jak může uživatel zadat jeden úkol, zatímco služba činí několik základních modelových rozhodnutí, což může potenciálně generovat několik samostatně účtovaných hovorů. To mění to, co vývojáři, administrátoři a fakturační systémy potřebují vědět o požadavku: model zobrazený v rozhraní již nemusí nutně představovat úplný popis toho, jak byla práce provedena.
Fusion může vybírat, kaskádovat nebo kritizovat
GitHub dokumentuje tři vzory provedení pro Fusion. Požadavek může přejít na jeden vybraný model, procházet kaskádou modelů nebo použít jeden model ke kritice výstupu jiného modelu. Uživatelé si také mohou vybrat standardní, vysokou nebo maximální úroveň úsilí, což jim dává určitou kontrolu nad tím, kolik orchestrace se použije.
Jedná se o významný produktový posun, protože směrování se stává součástí zážitku koncového uživatele spíše než neviditelnou optimalizací za poskytovatelem API. Brána multimodelů API pro týmy může provádět podobný výběr na aplikační vrstvě, ale Fusion vkládá rozhodnutí do hlavního vývojového prostředí a poskytuje kontrolu nad úsilím přímo vývojáři.
Tento přístup by mohl snížit potřebu uživatelů chápat silné stránky každého dostupného modelu. To také vytváří nový diagnostický problém. Když je odpověď pomalá, drahá nebo nesprávná, týmy potřebují vědět, zda výsledek pochází z jednoho modelu, kaskády nebo kritického hodnocení zahrnujícího několik modelů.
Jeden požadavek může přinést několik poplatků
GitHub říká, že každý model používaný společností Fusion je účtován standardní sazbou daného modelu. Oznámila také dočasnou 30% slevu na náklady modelu Fusion pro placené plány, ačkoli recenzované oznámení neuvádí, kdy tato sleva skončí.
V důsledku tohoto návrhu fakturace je sledování provádění komerčně důležité. Jedna akce vývojáře může spotřebovat více prostředků než přímé volání jednoho modelu, i když orchestrace poskytuje lepší výsledek. Týmy hodnotící Fusion proto budou muset porovnat náklady na dokončený úkol kódování, nejen uvedenou cenu tokenu prvního použitého modelu.
Stejný problém se týká unified AI API billing. Záznamy o použití by měly identifikovat každé základní volání modelu a zároveň zachovat připojení k původnímu požadavku uživatele. Bez tohoto vztahu mohou administrátoři vidět modelové poplatky, ale mají problém vysvětlit, který úkol je vygeneroval, nebo zda určité úsilí zvýšilo náklady.
Trasu stále utvářejí podnikové zásady
Administrátoři podniků a organizací mohou omezit, které modely může Fusion používat, prostřednictvím stávajících zásad modelu GitHub. To společnostem umožňuje vyloučit modely, které nesplňují interní požadavky, ale také to znamená, že stejný požadavek Fusion může být v organizacích směrován odlišně.
Pro vedoucí inženýrů je nyní třeba zvažovat modelovou politiku a rozpočtovou politiku společně. Povolení drahého modelu v katalogu může Fusion umožnit jeho vyvolání jako součást sekvence více modelů, nejen když si to vývojář výslovně vybere. Praktické AI API kontroly útraty pro týmy by proto měly zohledňovat hloubku orchestrace, úroveň úsilí a celkové náklady na všechna volání spojená s úkolem.
Operátoři brány čelí souvisejícímu požadavku na hlášení. Protokoly by měly rozlišovat model nebo režim požadovaný uživatelem od každého modelu, který skutečně obsluhoval požadavek. Toto rozlišení podporuje přiřazování nákladů, vyšetřování incidentů a reprodukovatelná hodnocení, když se chování směrování v průběhu času mění.
Místní směrování nevylučuje cloudové otázky
GitHub také představil experimentální náhled, který dokáže směrovat mezi vhodnými místními a cloudovými modely. Místní odvození může poskytnout další možnost pro náklady, latenci nebo zpracování dat, ale slovo „místní“ samo o sobě nepopisuje úplnou cestu zpracování. Týmy stále potřebují mít jasno v tom, která rozhodnutí o směrování, výzvy, metadata nebo následná volání modelu zůstávají v cloudových službách GitHub.
Několik podrobností zůstává nevyřešeno. GitHub neuvedl dobu trvání 30% slevy a jeho publikovaná srovnání nákladů a výkonu s kódem Claude závisí na konkrétní konfiguraci srovnávacího testu. Tyto výsledky by neměly být považovány za univerzální odhady pro každé úložiště nebo pracovní zátěž.
Trvalá změna je architektonická: orchestrace modelů se stává standardní funkcí vývojářských nástrojů. Transparentní záznamy o směrování, výběr modelu s ohledem na zásady a vykazování nákladů na úrovni úkolů se tak stávají nezbytnou součástí produktu spíše než volitelnými funkcemi pozorovatelnosti.