Baseten Grid pyta, ile kosztuje ukończenie zadania programistycznego

Agent programistyczny przygotowuje zgrabną zmianę pod niedziałający test. Zmiana nie przechodzi w CI, więc programista prosi agenta o ponowną próbę. Za drugim razem zmienia się większa część repozytorium, a osoba przeglądająca kod spędza pół godziny nad poprawką, która miała zająć pięć minut. Który model był tańszy?

4 listopada Baseten udostępnił Grid w publicznej wersji testowej. Rozwiązanie łączy bramę do zatwierdzonych modeli, router oraz centralną kontrolę użycia i ograniczeń. Usługa może działać między obsługiwanymi narzędziami programistycznymi a ich modelami, by zespół stosował wspólną politykę do wszystkich żądań. Strona wczesnego dostępu kieruje zespoły na listę oczekujących.

Zadbaj o właściwy mianownik

Koszt zaakceptowanego zadania. Autorska ilustracja Telli.sh.

Cena tokena dotyczy jednostki użycia modelu. Zespół musi dostarczyć coś, co spełnia kryteria akceptacji. Żądanie może przynieść odpowiedź, uruchomienie może stworzyć diff, a zadanie wciąż może pozostać niedokończone. Rozdzielenie tych zdarzeń pozwala wyciągnąć wnioski z testu routingu.

Załóżmy, że dwie trasy otrzymują po 100 podobnych zadań. Tańsza wydaje na wszystkie próby 50 USD i kończy 50 zadań, które można zaakceptować. Druga kosztuje 90 USD i kończy 90. W tym przykładzie obie zużywają zasoby modelu za 1 USD na zaakceptowany wynik. Jeśli doliczysz czas przeglądu, opłaty za narzędzia i oczekiwanie na ponowienia, trasy mogą się różnić. Dodatkowe koszty mogą przechylić wynik na dowolną stronę.

Uwzględniaj niepowodzenia w liczniku. Trasa, która rezygnuje z trudnych żądań, może wyglądać na efektywną, jeśli porzucone próby znikną z rachunku. Nie zmieniaj też definicji sukcesu. Przy aktualizacji dokumentacji zaakceptowany diff może wystarczyć. Migracja wymaga testów na istniejących danych i sposobu wycofania zmian.

Rodzaj zadania ma znaczenie. Migracja API w całym repozytorium może wymagać kontekstu, koordynacji i wielu małych zmian. Jednolinijkowa poprawka może być trudniejsza, jeśli dotyczy subtelnego błędu współbieżności. Liczba plików i długość polecenia są użytecznymi sygnałami wtedy, gdy pozwalają przewidywać wyniki w twoim środowisku.

Eksperyment z routerem pokazuje kompromis

Eksperyment z routingiem. Autorska ilustracja Telli.sh.

W raporcie technicznym Baseten porównuje ciągłe używanie Opus 5.5 z rozdzielaniem zadań między ten model a GLM 5.3 Flash. Na zestawie zadań DeepSWE, SWE Atlas QnA i Terminal-Bench firma wskazuje punkt, w którym koszt był niższy o 72%, a odsetek zaliczeń różnił się o nie więcej niż 0,8 punktu procentowego od wyniku samego Opus. Raport zestawia router z losowym kierowaniem żądań przy podobnym koszcie. To istotne, bo przekazanie większej liczby zadań tańszemu modelowi obniżyłoby średni koszt nawet przy wyborze przez rzut monetą.

Próg routingu określa, ile warto zapłacić za przewidywaną szansę powodzenia. Podniesienie priorytetu kosztu może skierować więcej zadań na tańszą trasę. Inne ustawienie może preferować mocniejszy model tam, gdzie wynik ma większe znaczenie. Dane Baseten dotyczą wybranych modeli, zadań i założeń cenowych. Twój zespół ma inny rozkład pracy i inaczej odczuwa koszt niepowodzenia.

W komunikacie produktowym Baseten podaje osobne, zaokrąglone twierdzenie o koszcie niższym nawet o 70% we wstępnych testach. To inna informacja niż wynik 72% z eksperymentu i towarzyszące mu porównanie odsetków zaliczeń. Raport techniczny pozwala przede wszystkim zobaczyć przebieg kompromisu. Zespół może wybrać punkt zgodny ze swoimi priorytetami i sprawdzić, czy utrzymuje się przy rzeczywistej pracy.

Brama może pokazać, jak działa polityka

Komunikat o Grid opisuje zatwierdzone modele, ustawienia na poziomie zespołu i wgląd w użycie. Zespół platformowy może udostępnić programistom modele już ocenione w organizacji i zobaczyć, jak rozkłada się ich użycie. Wydatki stają się łatwiejsze do zrozumienia, jeszcze zanim zespół oddeleguje wybór trasy.

W praktyce trzeba podjąć kilka decyzji. Który dostawca może zobaczyć zastrzeżony kod? Który model jest zatwierdzony dla konkretnego repozytorium? Który zespół finansuje ponowienia? Kto może zmienić trasę po incydencie? Brama pozwala podejmować decyzje w jednym wspólnym punkcie, jeśli administratorzy wiedzą, czym sterują poszczególne ustawienia.

Brama do modeli i środowisko wykonawcze agenta to osobne punkty kontroli. Brama może wybrać, do którego modelu trafi żądanie. Narzędzie lub środowisko wykonawcze decyduje, czy agent może odczytać poświadczenia, zapisać plik lub wysłać żądanie sieciowe. Ograniczenia tras są wartościowe w połączeniu z tymi uprawnieniami. Tańsza trasa nadal potrzebuje tych samych ograniczeń dostępu do uprzywilejowanego narzędzia.

Pozostaje kwestia dowodów. Logi routingu pomagają zrozumieć zmiany kosztów, ale ślady mogą zawierać kod, ścieżki i szczegóły incydentu u klienta. Ustal, co wolno zapisywać, kto może to zobaczyć i jak długo dane pozostaną dostępne. Politykę, której programista nie może sprawdzić, trudno diagnozować, gdy żądanie zostaje odrzucone lub niespodziewanie trafia na inną trasę.

Przetestuj routing przed zmianą ustawień domyślnych

1. Wybierz dwie lub trzy częste kategorie zadań. Uwzględnij prostą grupę, jak rutynowe aktualizacje testów, oraz trudniejszą, jak migracje wymagające zgodności wstecznej.
2. Przed rozpoczęciem określ dowody akceptacji. W zadaniu programistycznym może to być przechodzący test regresji, czysty diff, zgoda osoby przeglądającej i kontrola nieoczekiwanych zmian plików.
3. Zbierz wyniki odniesienia dla obecnego modelu domyślnego. Uwzględnij nieudane próby, ponowienia i zadania dokończone ręcznie. Zachowaj ograniczenia bezpieczeństwa i danych obowiązujące na produkcji.
4. Porównaj routing na równoważnych zadaniach. Jeśli masz dostęp, przed podłączeniem konta sprawdź w oficjalnej dokumentacji, jakie narzędzia i uprawnienia obsługuje brama.
5. Ustal warunki eskalacji. Niepowodzenie za pierwszym razem może uruchomić drugi model, ale nieograniczone ponawianie może kosztować więcej niż użycie mocniejszego modelu od początku. Ustaw limit i zapisz powód eskalacji.
6. Zachowaj możliwość zmiany trasy dla zadań, w których zły wynik miałby duże konsekwencje. Po pilotażu przejrzyj wyjątki razem z łącznymi kosztami i wynikami akceptacji.

W wewnętrznym pilotażu porównaj okres, w którym programiści wybierają modele samodzielnie, z okresem stosowania routingu przy podobnych zadaniach. Pierwsza grupa korzysta ze znajomości repozytorium. Druga może skorzystać ze spójnych zasad i lepszego wglądu w użycie. Zapisz różnice między zadaniami, żeby porównanie pokazało, gdzie pomaga automatyzacja, a gdzie liczy się ocena człowieka.

Porównaj wyniki dla tych samych zadań

Można zacząć od miesiąca zakończonych pull requestów. Oznacz pracę według pierwotnego zlecenia, na przykład jako aktualizację zależności, błąd z powtarzalnym testem, zmianę obejmującą kilka repozytoriów lub otwarte zadanie zbadania nieudanego wdrożenia. Zachowaj wersję repozytorium i kryterium akceptacji każdego zadania. Odtwórz próbkę z użyciem stabilnego punktu odniesienia i routera. W obu przebiegach użyj tych samych narzędzi, limitu czasu i środowiska testowego.

Aktualizacja zależności to przykład zadania z małą liczbą niewiadomych. Jest ukończone, gdy zmienia się wskazana zależność, testy zgodności przechodzą, a pull request nie zawiera niepowiązanych zmian. Zadanie dotyczące zasad rozliczeń wymaga dokładniejszego przeglądu. Może też wymagać interpretacji niepełnych wymagań. Rozróżnienie tych kategorii pomaga zobaczyć, skąd biorą się niższe średnie wydatki. Jeśli tania trasa dobrze obsługuje zależności, ale wymaga ponowień przy rozliczeniach, zespół może rozdzielić te przypadki.

Zapisuj czas, którego człowiek potrzebuje na decyzję o akceptacji. Załóżmy, że wariant odniesienia daje 19 zaakceptowanych wyników z 20 za 19 USD, a router daje 18 za 9 USD. W tym przykładzie koszt modelu na zaakceptowany wynik wynosi odpowiednio 1,00 USD i 0,50 USD. Jeśli przeglądający spędzą dodatkowe 20 minut na poprawieniu jednego nieudanego wyniku routingu, porównanie kosztów się zmieni. Organizacja może uwzględnić koszt tej pracy, zachowując rozróżnienie między dolarami a minutami.

Sprawdź, na czym uczył się router

W tekście technicznym Baseten wymienia DeepSWE 1.1, SWE Atlas QnA i Terminal-Bench 2.1. Badanie porównuje Claude Opus 5.5 i GLM 5.3 Flash na różnych zadaniach i ocenia router na danych odłożonych do testu. To ważne przy przenoszeniu wyników na inne zadania. Pytania o poruszanie się po repozytorium mają inną strukturę kosztu niż uruchamianie powłoki, korzystanie z zewnętrznych narzędzi czy zmiana kilku plików. Test klienta powinien reprezentować zadania, które rzeczywiście planuje wysyłać.

Tekst opisuje ustawienia Cost, Balanced i Intelligence wybierane przy żądaniu, które przesuwają próg routingu. Zespół produktowy może użyć ich do równoległego porównania testowego. Porównaj ustawienia na stałym zbiorze dozwolonych powtórzeń i zapisz wybrany model, jeśli integracja go ujawnia. Przyjrzyj się przypadkom różnych decyzji. Jeśli droższy model jest wybierany głównie przy zadaniach uznawanych przez zespół za wrażliwe lub trudne, polityka może działać sensownie. Jeśli rozbieżności skupiają się wokół typowego prostego zadania, warto skorygować klasyfikację lub zasady.

Obserwuj najwolniejsze i najdroższe przypadki

Średnie opóźnienie może ukrywać czas, w którym użytkownik czeka na trudną poprawkę przechodzącą przez kilka modeli. Zapisuj rzeczywisty czas od żądania do zaakceptowanego wyniku i oznaczaj ponowienia, eskalacje, przekroczenia czasu i przekazania sprawy. Panel pokazujący jedynie czas odpowiedzi pierwszego modelu może wykazać poprawę dla zadania, które operator musiał uruchomić od nowa. Uwzględnij czas i wydatki po przekazaniu.

Ogranicz pilotaż przed jego upowszechnieniem. Ustal budżet dla całego zadania oraz zasadę, kiedy przerwać pracę lub przejść na mocniejszy model. Nieudana próba powinna pozostawić wystarczające informacje, by można było kontynuować. Nie uruchamiaj ponownie testów i nie odczytuj tych samych plików tylko dlatego, że router wybrał inny model. Przydatną miarą jest postęp zadania.

Przy wdrażaniu zacznij od wąskiej grupy, w której akceptację można sprawdzać automatycznie, a wyjątki ocenia człowiek. Potem dodaj grupę wymagającą oceny. Osobno porównaj koszt zaakceptowanego zadania, odsetek eskalacji i czas przeglądu. Jeśli zysk się utrzyma, organizacja będzie miała lepsze podstawy do wyboru ustawień domyślnych.

Zachowaj użyteczny punkt odniesienia po zmianie modelu

Wyniki z jednego tygodnia mogą stracić aktualność po zmianie modelu, narzędzia lub repozytorium. Obok decyzji o trasie zapisz identyfikator modelu, wersję testową i zasady akceptacji. Po zmianie polityki powtórz niewielki zestaw reprezentatywnych zadań. Zachowaj w nim kilka kosztownych niepowodzeń, bo ich koszty łatwo giną w średniej.

Poproś przeglądającego o ocenę rozbieżności bez ujawniania wybranego modelu. Jeśli nie da się rozstrzygnąć, który wynik można zaakceptować, doprecyzuj kryteria przed kolejnymi przebiegami. Zasady routingu łatwiej porównać, gdy zespół wie, po czym poznać sukces.

Zasady powinny się zmieniać wraz z pracą

Routing ma wartość, gdy uwalnia zespół od ciągłego podejmowania tej samej drobnej decyzji. Szczególnie pomaga, gdy jakość i cenę można odnieść do tej samej jednostki pracy. Z czasem zmienią się modele, ceny i repozytorium. Zachowaj zadania porównawcze i aktualizuj zestaw testowy, by zasady routingu mogły nadążyć.

Na spotkanie planistyczne warto zabrać informację o tym, ile zespół zapłacił za dostarczenie zaakceptowanej pracy, wraz z jasnym opisem kompromisów. Kierownik techniczny i właściciel budżetu mogą wspólnie podjąć na tej podstawie decyzję.

Źródła

• Komunikat Baseten z 4 listopada o wersji testowej Grid
• Raport techniczny Baseten z 4 listopada o Router

---

Jeśli chcesz przechowywać rozmowy i decyzje związane z pracą w formie, którą można przeszukiwać, załóż konto Telli.sh.