GitHub ir padarījis Copilot Fusion vispārēju pieejamu, pārceļot vairāku modeļu maršrutēšanu no infrastruktūras problēmas uz ikdienas kodēšanas darbplūsmu. Tā vietā, lai pieprasītu izstrādātājam atlasīt vienu fiksētu modeli, Fusion var izvēlēties un saskaņot pieprasījumam vienu vai vairākus modeļus.
Izlaidums ir svarīgāks par GitHub Copilot. Tas parāda, kā lietotājs var iesniegt vienu uzdevumu, kamēr pakalpojums pieņem vairākus pamatā esošos modeļa lēmumus, potenciāli ģenerējot vairākus atsevišķi apmaksātus zvanus. Tas maina to, kas izstrādātājiem, administratoriem un norēķinu sistēmām jāzina par pieprasījumu: saskarnē parādītais modelis vairs ne vienmēr ir pilnīgs apraksts par to, kā darbs tika veikts.
Fusion var atlasīt, kaskadēt vai kritizēt
GitHub dokumentē trīs Fusion izpildes modeļus. Pieprasījums var tikt nosūtīts uz vienu atlasītu modeli, pārvietoties pa modeļu kaskādi vai izmantot vienu modeli, lai kritizētu cita modeļa izvadi. Lietotāji var arī izvēlēties standarta, augstu vai maksimālo piepūles līmeni, dodot viņiem zināmu kontroli pār to, cik daudz orķestrēšanas tiek lietots.
Šī ir būtiska produkta maiņa, jo maršrutēšana kļūst par daļu no galalietotāja pieredzes, nevis par neredzamu optimizāciju, ko nodrošina pakalpojumu sniedzējs API. Vairāku modeļu API vārteja komandām var veikt līdzīgu atlasi lietojumprogrammas slānī, taču Fusion pieņem lēmumu galvenajā izstrādes vidē un pakļauj piepūles kontroli tieši izstrādātājam.
Šī pieeja varētu samazināt vajadzību lietotājiem izprast katra pieejamā modeļa stiprās puses. Tas arī rada jaunu diagnostikas problēmu. Ja atbilde ir lēna, dārga vai nepareiza, komandām ir jāzina, vai rezultāts ir iegūts no viena modeļa, kaskādes vai vairāku modeļu kritikas.
Viens pieprasījums var radīt vairākas maksas
GitHub saka, ka katrs Fusion izmantotais modelis tiek iekasēts pēc šī modeļa standarta likmes. Tā ir arī paziņojusi par pagaidu 30% atlaidi Fusion modeļa izmaksām maksas plāniem, lai gan pārskatītajā paziņojumā nav norādīts, kad šī atlaide beigsies.
Šis norēķinu dizains padara izpildes izsekojamību komerciāli svarīgu. Viena izstrādātāja darbība var patērēt vairāk resursu nekā tiešs izsaukums vienam modelim, pat ja orķestrēšana dod labāku rezultātu. Tāpēc komandām, kas novērtēs Fusion, būs jāsalīdzina maksa par paveikto kodēšanas uzdevumu, nevis tikai pirmā iesaistītā modeļa norādītā marķiera cena.
Tā pati problēma attiecas uz unified AI API billing. Lietošanas ierakstos ir jāidentificē katrs pamatā esošā modeļa izsaukums, vienlaikus saglabājot savienojumu ar sākotnējo lietotāja pieprasījumu. Bez šīm attiecībām administratori var redzēt modeļa izmaksas, taču viņiem ir grūti izskaidrot, kurš uzdevums tos ģenerēja un vai piepūles iestatījums palielināja izmaksas.
Uzņēmuma politikas joprojām veido maršrutu
Uzņēmumu un organizāciju administratori var ierobežot, kurus modeļus Fusion drīkst izmantot, izmantojot GitHub esošās modeļu politikas. Tas dod uzņēmumiem iespēju izslēgt modeļus, kas neatbilst iekšējām prasībām, taču tas arī nozīmē, ka viens un tas pats Fusion pieprasījums dažādās organizācijās var tikt novirzīts atšķirīgi.
Inženierzinātņu vadītājiem modeļa politika un budžeta politika tagad ir jāapsver kopā. Dārga modeļa atļaušana katalogā var ļaut Fusion to izsaukt kā daļu no vairāku modeļu secības, ne tikai tad, ja izstrādātājs to skaidri izvēlas. Tāpēc praktiskajās AI API tēriņu vadīklās komandām ir jāņem vērā orķestrēšanas dziļums, piepūles līmenis un visu ar uzdevumu saistīto zvanu kopējās izmaksas.
Vārtejas operatori saskaras ar saistītu ziņošanas prasību. Žurnāliem ir jānošķir lietotāja pieprasītais modelis vai režīms no visiem modeļiem, kas faktiski apkalpoja pieprasījumu. Šī atšķirība atbalsta izmaksu attiecināšanu, incidentu izmeklēšanu un atkārtojamus novērtējumus, kad maršrutēšanas uzvedība laika gaitā mainās.
Vietējā maršrutēšana nenovērš mākoņa jautājumus
GitHub ir arī ieviesis eksperimentālu priekšskatījumu, kas var maršrutēt starp piemērotiem vietējiem un mākoņa modeļiem. Vietējie secinājumi var nodrošināt citu izmaksu, latentuma vai datu apstrādes iespēju, taču vārds “lokāls” pats par sevi neapraksta visu apstrādes ceļu. Komandām joprojām ir nepieciešama skaidrība par to, kuri maršrutēšanas lēmumi, uzvednes, metadati vai papildu modeļa izsaukumi paliek GitHub mākoņpakalpojumos.
Vairākas detaļas joprojām nav noskaidrotas. GitHub nav norādījis 30% atlaides ilgumu, un tā publicētie izmaksu un veiktspējas salīdzinājumi ar kodu Claude ir atkarīgi no konkrētas etalona konfigurācijas. Šos rezultātus nevajadzētu uzskatīt par universāliem aprēķiniem katrai krātuvei vai darba slodzei.
Ilgstošās izmaiņas ir arhitektoniskas: modeļu orķestrēšana kļūst par izstrādātāju rīku standarta funkciju. Tādā gadījumā pārskatāmi maršrutēšanas ieraksti, politikām atbilstošu modeļu atlase un uzdevuma līmeņa izmaksu atskaites kļūst par vajadzīgām produkta daļām, nevis par izvēles novērošanas funkcijām.