GitHub sprístupnil Copilot Fusion všeobecne a posunul viacmodelové smerovanie z oblasti infraštruktúry do každodenného pracovného toku kódovania. Namiesto toho, aby vývojár musel vybrať jeden pevný model, môže Fusion vybrať a usporiadať jeden alebo viac modelov pre požiadavku.
Na vydaní záleží okrem GitHub druhého pilota. Ukazuje, ako môže používateľ zadať jednu úlohu, zatiaľ čo služba urobí niekoľko základných modelových rozhodnutí, čo môže potenciálne generovať niekoľko samostatne účtovaných hovorov. To mení to, čo vývojári, správcovia a fakturačné systémy potrebujú vedieť o požiadavke: model zobrazený v rozhraní už nemusí nevyhnutne predstavovať úplný popis toho, ako bola práca vykonaná.
Fúzia môže vyberať, kaskádovať alebo kritizovať
GitHub dokumentuje tri vzory vykonávania pre Fusion. Požiadavka môže prejsť na jeden vybraný model, prejsť cez kaskádu modelov alebo použiť jeden model na kritiku výstupu iného modelu. Používatelia si tiež môžu vybrať štandardnú, vysokú alebo maximálnu úroveň úsilia, čo im dáva určitú kontrolu nad tým, do akej miery sa použije orchestrácia.
Ide o významný produktový posun, pretože smerovanie sa stáva súčasťou zážitku koncového používateľa a nie neviditeľnou optimalizáciou za poskytovateľom API. Brána multimodelov API pre tímy môže vykonávať podobný výber na aplikačnej vrstve, ale Fusion vkladá rozhodnutie do hlavného vývojového prostredia a poskytuje kontrolu nad úsilím priamo vývojárovi.
Tento prístup by mohol znížiť potrebu používateľov pochopiť silné stránky každého dostupného modelu. Vytvára tiež nový diagnostický problém. Keď je odpoveď pomalá, drahá alebo nesprávna, tímy potrebujú vedieť, či výsledok pochádza z jedného modelu, kaskády alebo z hodnotenia viacerých modelov.
Jedna žiadosť môže priniesť niekoľko poplatkov
GitHub hovorí, že každý model používaný spoločnosťou Fusion sa účtuje štandardnou sadzbou daného modelu. Oznámila tiež dočasnú 30 % zľavu na náklady modelu Fusion pre platené programy, aj keď recenzované oznámenie nešpecifikuje, kedy táto zľava skončí.
Vďaka tomuto návrhu fakturácie je sledovanie vykonania komerčne dôležité. Jedna akcia vývojára môže spotrebovať viac zdrojov ako priame volanie do jedného modelu, aj keď orchestrácia prináša lepší výsledok. Tímy, ktoré hodnotia Fusion, preto budú musieť porovnať cenu za dokončenú úlohu kódovania, nielen uvedenú cenu tokenu prvého zapojeného modelu.
Rovnaký problém sa týka unified AI API billing. Záznamy o používaní by mali identifikovať každé základné volanie modelu pri zachovaní spojenia s pôvodnou požiadavkou používateľa. Bez tohto vzťahu môžu správcovia vidieť modelové poplatky, ale majú problém vysvetliť, ktorá úloha ich vygenerovala alebo či vynaložené úsilie zvýšilo náklady.
Trasu stále formujú podnikové pravidlá
Správcovia podnikov a organizácií môžu obmedziť, ktoré modely môže Fusion používať, prostredníctvom existujúcich pravidiel GitHub pre modely. To umožňuje spoločnostiam vylúčiť modely, ktoré nespĺňajú interné požiadavky, no zároveň to znamená, že tá istá požiadavka Fusion môže byť v rámci organizácií smerovaná odlišne.
Pre vedúcich inžinierov je teraz potrebné zvážiť modelovú politiku a rozpočtovú politiku spoločne. Povolenie drahého modelu v katalógu môže Fusion umožniť, aby ho vyvolal ako súčasť sekvencie viacerých modelov, nielen vtedy, keď si to vývojár explicitne vyberie. Praktické AI API ovládacie prvky výdavkov pre tímy by preto mali zohľadňovať hĺbku orchestrácie, úroveň úsilia a celkové náklady na všetky hovory spojené s úlohou.
Prevádzkovatelia brán čelia súvisiacej požiadavke na hlásenie. Protokoly by mali odlíšiť model alebo režim požadovaný používateľom od každého modelu, ktorý skutočne splnil požiadavku. Toto rozlíšenie podporuje priraďovanie nákladov, vyšetrovanie incidentov a reprodukovateľné hodnotenia pri zmenách smerovania v priebehu času.
Miestne smerovanie nevylučuje cloudové otázky
GitHub tiež predstavil experimentálnu ukážku, ktorá dokáže smerovať medzi vhodnými miestnymi a cloudovými modelmi. Miestna inferencia môže poskytnúť ďalšiu možnosť pre náklady, latenciu alebo spracovanie údajov, ale slovo „lokálne“ samo osebe nepopisuje úplnú cestu spracovania. Tímy stále potrebujú mať jasno v tom, ktoré rozhodnutia o smerovaní, výzvy, metadáta alebo následné modelové hovory zostávajú v cloudových službách GitHub.
Niekoľko podrobností zostáva nevyriešených. GitHub nešpecifikovalo trvanie 30 % zľavy a jej publikované porovnania nákladov a výkonnosti s kódom Claude závisia od konkrétnej konfigurácie benchmarku. Tieto výsledky by sa nemali považovať za univerzálne odhady pre každé úložisko alebo pracovné zaťaženie.
Trvalá zmena je architektonická: orchestrácia modelov sa stáva štandardnou funkciou vývojárskych nástrojov. V tomto prípade sa transparentné záznamy smerovania, výber modelu s ohľadom na pravidlá a vykazovanie nákladov na úrovni úloh stávajú nevyhnutnou súčasťou produktu a nie voliteľnými funkciami pozorovateľnosti.