GitHub umożliwiło powszechną dostępność rozwiązania Copilot Fusion, przenosząc routing wielu modeli z problemów związanych z infrastrukturą do codziennego przepływu pracy związanego z kodowaniem. Zamiast wymagać od programisty wybrania jednego stałego modelu, Fusion może wybrać i zaaranżować jeden lub więcej modeli na żądanie.

Wersja ma znaczenie poza GitHub Copilotem. Pokazuje, jak użytkownik może przesłać jedno zadanie, podczas gdy usługa podejmuje kilka decyzji dotyczących modelu bazowego, potencjalnie generując kilka oddzielnie rozliczanych wywołań. To zmienia to, co programiści, administratorzy i systemy rozliczeniowe muszą wiedzieć o żądaniu: model pokazywany w interfejsie niekoniecznie jest już pełnym opisem sposobu wykonania pracy.

Fusion może wybierać, kaskadować lub krytykować

GitHub dokumentuje trzy wzorce wykonania dla Fusion. Żądanie może dotyczyć pojedynczego wybranego modelu, przechodzić przez kaskadę modeli lub wykorzystywać jeden model do krytyki wyników innego modelu. Użytkownicy mogą także wybrać poziom wysiłku Standardowy, Wysoki lub Maksymalny, co daje im pewną kontrolę nad ilością zastosowanej orkiestracji.

To znacząca zmiana produktu, ponieważ routing staje się częścią doświadczenia użytkownika końcowego, a nie niewidoczną optymalizacją stojącą za dostawcą API. Wielomodelowa API brama dla zespołów może przeprowadzić podobną selekcję w warstwie aplikacji, ale Fusion umieszcza decyzję w głównym środowisku programistycznym i udostępnia kontrolę nad nakładem pracy bezpośrednio programiście.

To podejście mogłoby zmniejszyć potrzebę zrozumienia przez użytkowników mocnych stron każdego dostępnego modelu. Stwarza to także nowy problem diagnostyczny. Jeśli odpowiedź jest powolna, kosztowna lub niepoprawna, zespoły muszą wiedzieć, czy wynik pochodzi z jednego modelu, kaskady, czy też krytycznej oceny obejmującej kilka modeli.

Jedno żądanie może spowodować kilka opłat

GitHub mówi, że każdy model używany przez Fusion jest rozliczany według standardowej stawki dla tego modelu. Ogłoszono także tymczasową 30% zniżkę na koszty modelu Fusion w przypadku planów płatnych, chociaż w recenzowanym ogłoszeniu nie określono, kiedy ta zniżka się zakończy.

Taki projekt rozliczeń sprawia, że śledzenie wykonania jest ważne z komercyjnego punktu widzenia. Pojedyncza akcja programisty może pochłonąć więcej zasobów niż bezpośrednie wywołanie jednego modelu, nawet jeśli orkiestracja daje lepszy wynik. Zespoły oceniające Fusion będą zatem musiały porównać koszt ukończonego zadania kodowania, a nie tylko podaną cenę symboliczną pierwszego modelu.

Ten sam problem dotyczy ujednoliconej sztucznej inteligencji API rozliczeń. Rekordy użycia powinny identyfikować każde wywołanie modelu bazowego, zachowując jednocześnie połączenie z pierwotnym żądaniem użytkownika. Bez tej relacji administratorzy mogą zobaczyć opłaty modelowe, ale mieć trudności z wyjaśnieniem, które zadanie je wygenerowało lub czy ustawienie nakładu pracy zwiększyło koszt.

Zasady korporacyjne nadal kształtują drogę

Administratorzy przedsiębiorstw i organizacji mogą ograniczyć modele, z których może korzystać Fusion, za pomocą istniejących zasad modeli GitHub. Daje to firmom możliwość wykluczenia modeli, które nie spełniają wewnętrznych wymagań, ale oznacza również, że to samo żądanie Fusion może być kierowane w różny sposób w różnych organizacjach.

W przypadku liderów inżynierii politykę modelową i politykę budżetową należy teraz rozpatrywać łącznie. Dopuszczenie drogiego modelu do katalogu może pozwolić Fusion na przywołanie go jako części sekwencji obejmującej wiele modeli, nie tylko wtedy, gdy programista wyraźnie go wybierze. Praktyczna AI API kontrola wydatków zespołów powinna zatem uwzględniać głębokość orkiestracji, poziom wysiłku i całkowity koszt wszystkich połączeń związanych z zadaniem.

Operatorzy bram podlegają powiązanym wymogom raportowania. Dzienniki powinny odróżniać model lub tryb żądany przez użytkownika od każdego modelu, który faktycznie obsłużył żądanie. To rozróżnienie ułatwia przypisywanie kosztów, badanie incydentów i powtarzalne oceny, gdy zachowanie tras zmienia się w czasie.

Routing lokalny nie eliminuje pytań dotyczących chmury

GitHub wprowadzono także eksperymentalną wersję zapoznawczą, która może przekierowywać pomiędzy kwalifikującymi się modelami lokalnymi i chmurowymi. Wnioskowanie lokalne może zapewnić inną opcję dotyczącą kosztów, opóźnień lub obsługi danych, ale słowo „lokalny” samo w sobie nie opisuje pełnej ścieżki przetwarzania. Zespoły nadal potrzebują jasności co do tego, które decyzje dotyczące routingu, monity, metadane lub wywołania modelu uzupełniającego pozostają w usługach chmurowych GitHub.

Kilka szczegółów pozostaje nierozstrzygniętych. GitHub nie określił czasu trwania 30% zniżki, a opublikowane porównania kosztów i wydajności z kodem Claude zależą od konkretnej konfiguracji testu porównawczego. Wyniki te nie powinny być traktowane jako uniwersalne szacunki dla każdego repozytorium lub obciążenia.

Trwała zmiana ma charakter architektoniczny: aranżacja modelu staje się standardową funkcją narzędzi programistycznych. W takim przypadku przejrzyste zapisy tras, wybór modelu uwzględniający zasady i raportowanie kosztów na poziomie zadania stają się niezbędnymi elementami produktu, a nie opcjonalnymi funkcjami zapewniającymi możliwość obserwacji.