GitHub a făcut Copilot Fusion disponibil în general, mutând rutarea cu mai multe modele de la o problemă de infrastructură în fluxul de lucru de codificare de zi cu zi. În loc să solicite unui dezvoltator să selecteze un model fix, Fusion poate alege și orchestra unul sau mai multe modele pentru o solicitare.
Versiunea contează dincolo de GitHub Copilot. Acesta demonstrează modul în care un utilizator poate trimite o sarcină în timp ce serviciul ia mai multe decizii de model care stau la baza, generând posibil mai multe apeluri facturate separat. Acest lucru schimbă ceea ce dezvoltatorii, administratorii și sistemele de facturare trebuie să știe despre o solicitare: modelul afișat în interfață nu mai este neapărat o descriere completă a modului în care a fost efectuată munca.
Fusion poate selecta, în cascadă sau critica
GitHub documentează trei modele de execuție pentru Fusion. O solicitare poate merge la un singur model selectat, poate trece printr-o cascadă de modele sau poate folosi un model pentru a critica rezultatul altui model. Utilizatorii pot alege, de asemenea, niveluri de efort Standard, Înalt sau Max, oferindu-le un anumit control asupra cât de multă orchestrare este aplicată.
Aceasta este o schimbare semnificativă a produsului, deoarece rutarea devine parte din experiența utilizatorului final, mai degrabă decât o optimizare invizibilă în spatele unui furnizor API. O gateway multi-model API pentru echipe poate efectua o selecție similară la nivelul aplicației, dar Fusion plasează decizia într-un mediu de dezvoltare major și expune un control al efortului direct dezvoltatorului.
Abordarea ar putea reduce nevoia utilizatorilor de a înțelege punctele forte ale fiecărui model disponibil. De asemenea, creează o nouă problemă de diagnostic. Când un răspuns este lent, costisitor sau incorect, echipele trebuie să știe dacă rezultatul a venit dintr-un model, o cascadă sau o trecere critică care implică mai multe modele.
O singură solicitare poate genera mai multe taxe
GitHub spune că fiecare model folosit de Fusion este facturat la tariful standard al modelului respectiv. De asemenea, a anunțat o reducere temporară de 30% la costurile modelului Fusion pentru planurile plătite, deși anunțul revizuit nu specifică când se va încheia această reducere.
Acest design de facturare face ca urma execuției să fie importantă din punct de vedere comercial. O singură acțiune a dezvoltatorului poate consuma mai multe resurse decât un apel direct la un model, chiar și atunci când orchestrarea produce un rezultat mai bun. Prin urmare, echipele care evaluează Fusion vor trebui să compare costul pentru sarcina de codare finalizată, nu doar prețul indicativ al primului model implicat.
Aceeași problemă se aplică pentru AI unificată API facturare. Înregistrările de utilizare ar trebui să identifice fiecare apel model subiacent, păstrând în același timp conexiunea la cererea originală a utilizatorului. Fără această relație, administratorii pot vedea taxele de model, dar se străduiesc să explice ce sarcină le-a generat sau dacă o setare de efort a crescut costul.
Politicile întreprinderii încă modelează traseul
Administratorii de întreprinderi și organizații pot restricționa modelele pe care Fusion le poate folosi prin politicile existente ale modelului GitHub. Acest lucru oferă companiilor o modalitate de a exclude modele care nu îndeplinesc cerințele interne, dar înseamnă, de asemenea, că aceeași solicitare Fusion poate fi direcționată diferit între organizații.
Pentru liderii de inginerie, politica de model și politica bugetară trebuie acum luate în considerare împreună. Permiterea unui model scump în catalog poate permite Fusion să-l invoce ca parte a unei secvențe cu mai multe modele, nu numai atunci când un dezvoltator îl alege în mod explicit. Prin urmare, controalele practice AI API ale cheltuielilor pentru echipe ar trebui să țină cont de profunzimea orchestrației, nivelul de efort și costul total al tuturor apelurilor asociate cu o sarcină.
Operatorii de gateway se confruntă cu o cerință de raportare asociată. Jurnalele ar trebui să distingă modelul sau modul solicitat de utilizator de fiecare model care a servit efectiv cererea. Această distincție sprijină atribuirea costurilor, investigarea incidentelor și evaluări reproductibile atunci când comportamentul de rutare se modifică în timp.
Rutarea locală nu elimină întrebările din cloud
GitHub a introdus, de asemenea, o previzualizare experimentală care poate fi direcționată între modelele locale și cele din cloud eligibile. Inferența locală poate oferi o altă opțiune pentru cost, latență sau manipularea datelor, dar cuvântul „local” nu descrie în sine calea completă de procesare. Echipele au nevoie în continuare de claritate cu privire la deciziile de rutare, solicitările, metadatele sau apelurile model ulterioare care rămân în serviciile cloud ale lui GitHub.
Mai multe detalii rămân nerezolvate. GitHub nu a specificat durata reducerii de 30%, iar comparațiile publicate de costuri și performanță cu Claude Cod depind de o anumită configurație de referință. Aceste rezultate nu trebuie tratate ca estimări universale pentru fiecare depozit sau volum de lucru.
Schimbarea durabilă este arhitecturală: orchestrarea modelului devine o caracteristică standard a instrumentelor pentru dezvoltatori. Pe măsură ce se întâmplă acest lucru, înregistrările transparente de rutare, selecția modelului conștient de politici și raportarea costurilor la nivel de activitate devin părți necesare ale produsului, mai degrabă decât caracteristici opționale de observabilitate.