GitHub je naredil Copilot Fusion splošno dostopen, s čimer je usmerjanje z več modeli premaknilo iz skrbi za infrastrukturo v vsakodnevni potek dela kodiranja. Namesto da bi od razvijalca zahteval, da izbere en fiksni model, lahko Fusion izbere in orkestrira enega ali več modelov za zahtevo.

Izdaja je pomembna poleg GitHub Copilot. Prikazuje, kako lahko uporabnik odda eno nalogo, medtem ko storitev sprejema več temeljnih modelnih odločitev, kar lahko povzroči več ločeno zaračunanih klicev. To spremeni tisto, kar morajo razvijalci, skrbniki in sistemi zaračunavanja vedeti o zahtevi: model, prikazan v vmesniku, ni več nujno popoln opis, kako je bilo delo opravljeno.

Fusion lahko izbira, kaskadira ali kritizira

GitHub dokumentira tri izvedbene vzorce za Fusion. Zahteva se lahko nanaša na en sam izbrani model, premika skozi kaskado modelov ali uporabi en model za kritiko izhoda drugega modela. Uporabniki lahko izberejo tudi standardno, visoko ali največjo stopnjo napora, kar jim daje nekaj nadzora nad tem, koliko uporabljene orkestracije.

To je pomemben premik v izdelku, ker usmerjanje postaja del izkušnje končnega uporabnika in ne nevidna optimizacija za ponudnikom API. Večmodelni API prehod za ekipe lahko izvede podobno izbiro na aplikacijski ravni, vendar Fusion postavi odločitev v glavno razvojno okolje in izpostavi nadzor napora neposredno razvijalcu.

Pristop bi lahko zmanjšal potrebo uporabnikov po razumevanju prednosti vsakega razpoložljivega modela. Prav tako ustvarja nov diagnostični problem. Kadar je odgovor počasen, drag ali nepravilen, morajo ekipe vedeti, ali je rezultat prišel iz enega modela, kaskade ali kritičnega prehoda, ki vključuje več modelov.

Ena zahteva lahko povzroči več stroškov

GitHub pravi, da je vsak model, ki ga uporablja Fusion, zaračunan po standardni ceni tega modela. Napovedal je tudi začasni 30-odstotni popust na stroške modela Fusion za plačljive načrte, čeprav pregledana objava ne določa, kdaj se bo ta popust končal.

Ta zasnova obračunavanja naredi sledenje izvajanja komercialno pomembno. Posamezno dejanje razvijalca lahko porabi več virov kot neposreden klic enega modela, tudi če orkestracija ustvari boljši rezultat. Ekipe, ki bodo ocenjevale Fusion, bodo zato morale primerjati ceno na opravljeno nalogo kodiranja, ne le navedene cene žetona za prvi vključeni model.

Ista težava velja za poenoteno AI API obračunavanje. Zapisi o uporabi morajo identificirati vsak osnovni klic modela, hkrati pa ohraniti povezavo z izvirno uporabniško zahtevo. Brez tega razmerja lahko skrbniki vidijo vzorčne stroške, vendar težko pojasnijo, katera naloga jih je ustvarila ali ali je nastavitev truda povečala stroške.

Politike podjetja še vedno oblikujejo pot

Skrbniki podjetij in organizacij lahko omejijo, katere modele lahko Fusion uporablja prek GitHub obstoječih pravilnikov o modelih. To podjetjem omogoča, da izključijo modele, ki ne ustrezajo notranjim zahtevam, hkrati pa pomeni, da je lahko ista zahteva Fusion različno usmerjena med organizacijami.

Za vodilne inženirje je treba politiko modela in proračunsko politiko zdaj obravnavati skupaj. Če dovolite drag model v katalogu, lahko Fusion omogočite, da ga prikliče kot del zaporedja več modelov, ne samo, če ga razvijalec izrecno izbere. Praktični AI API nadzor porabe za ekipe bi moral zato upoštevati globino orkestracije, stopnjo napora in skupne stroške vseh klicev, povezanih z nalogo.

Upravljavci prehodov se soočajo s povezano zahtevo po poročanju. Dnevniki morajo razlikovati med modelom ali načinom, ki ga zahteva uporabnik, od vseh modelov, ki so dejansko izpolnili zahtevo. To razlikovanje podpira pripisovanje stroškov, preiskavo incidentov in ponovljive ocene, ko se vedenje usmerjanja skozi čas spremeni.

Lokalno usmerjanje ne odpravi vprašanj v oblaku

GitHub je predstavil tudi poskusni predogled, ki lahko usmerja med primernimi lokalnimi modeli in modeli v oblaku. Lokalno sklepanje lahko nudi drugo možnost za stroške, zakasnitev ali obdelavo podatkov, vendar beseda "lokalno" sama po sebi ne opisuje celotne poti obdelave. Ekipe še vedno potrebujejo jasnost glede tega, katere odločitve o usmerjanju, pozivi, metapodatki ali klici nadaljnjih modelov ostanejo v storitvah v oblaku GitHub.

Več podrobnosti ostaja nedorečenih. GitHub ni določil trajanja 30-odstotnega popusta, njegove objavljene primerjave stroškov in uspešnosti s kodo Claude pa so odvisne od določene primerjalne konfiguracije. Teh rezultatov ne bi smeli obravnavati kot univerzalne ocene za vsako skladišče ali delovno obremenitev.

Trajna sprememba je arhitekturna: orkestracija modela postaja standardna funkcija orodij za razvijalce. Ko se to zgodi, postanejo pregledni usmerjevalni zapisi, izbira modela, ki upošteva pravilnike, in poročanje o stroških na ravni nalog nujni deli izdelka namesto izbirnih funkcij opazovanja.