Wojna AI kodujących – kto wygra na infrastrukturze?

Wyścig zbrojeń wśród asystentów kodowania AI wkroczył w nową fazę. Claude Code, Codex, Gemini CLI – te narzędzia przeszły już prawdziwe testy w rękach programistów na całym świecie. Pytanie nie brzmi już "czy to w ogóle działa?" Tylko: jak serwować te rozwiązania na masową skalę, nie rujnując budżetu i nie wprowadzając opóźnień, przez które developer chce wyrzucić klawiaturę przez okno.

Nowa praca badawcza z Uniwersytetu Waszyngtońskiego dostarcza twardych liczb na temat tego, jak naprawdę wyglądają obciążenia od agentów kodujących. Wyniki mogą cię zaskoczyć: twoja obecna infrastruktura do serwowania LLM prawdopodobnie nie jest pod to zoptymalizowana.

Rewolucja autonomicznych agentów, której nikt się nie spodziewał

Jest coś w koding agents, co wydaje się oczywiste, gdy ktoś to powie: te narzędzia nie tylko odpowiadają na pytania. Wykonują plany. Gdy prosisz AI o zaimplementowanie funkcji lub naprawienie buga, nie inicjujesz prostej wymiany zapytań i odpowiedzi – uruchamiasz autonomiczny workflow, w którym model będzie rozumował, wykonywał komendy shella, czytał i modyfikował pliki, uruchamiał testy i iterował, aż uzna zadanie za zakończone (albo aż go przerwiesz).

Zespół badawczy przechwycił ponad 4300 rzeczywistych sesji – łącznie około 55 miliardów tokenów. Wzorce są uderzające. Każde żądanie użytkownika wywołuje średnio 8,8 cykli LLM-narzędzia przed zakończeniem. Zastanów się nad tym: na każde pytanie developera przypada prawie dziewięć rund generowania modelu, po których następuje wykonanie narzędzia. Model nie tylko mówi – działa. Co więcej, 88% wszystkich rund inferencji LLM zachodzi nie w odpowiedzi na input użytkownika, ale w odpowiedzi na wyniki narzędzi.

To ma ogromne konsekwencje dla planowania przepustowości. Tradycyjne chatboty to w zasadzie systemy request-response z sporadycznymi follow-upami. Agenci kodujący to bardziej długotrwałe procesy autonomiczne z częstym przełączaniem kontekstu między fazami generowania a wykonania. Twoje polityki autoscalingu, kolejkowanie requestów, strategie cachowania – to wszystko wymaga przemyślenia przez pryzmat autonomicznych, wielokrokowych workflowów, a nie prostych konwersacji naprzemiennych.

Asymetria Input-Output, która psuje twój cache

Tu jest liczba, która powinna kazać każdemu inżynierowi infrastruktury zrobić podwójne spojrzenie: inputs przewyższają outputs w stosunku 294:1. W przeanalizowanych trace'ach modele przeczytały 52,56 miliarda cache'owanych tokenów inputu i prefilled 2,34 miliarda nowych, a wygenerowały zaledwie 186,9 miliona tokenów outputu. Typowa runda operuje na prefiksie od 32K do 256K tokenów i dodaje zaledwie kilkaset do kilku tysięcy tokenów, zanim zdekoduje kilkaset na wyjściu.

Tworzy to fundamentalnie inny profil wydajności niż ten, pod który większość systemów do serwowania LLM jest zoptymalizowana. Tradycyjna inferencja modeli językowych koncentruje się na throughput generowania – ile tokenów na sekundę możemy wyprodukować? Ale dla koding agents, bottleneckem często nie jest prędkość dekodowania; to time-to-first-token (TTFT) po powrocie wykonania narzędzia. Zespół ustalił, że TTFT Codex dla każdego kroku wynosi około 3,1 sekundy, co stanowi mniej więcej 25% całkowitego czasu generowania rundy. Gdy wykonujesz dziewięć rund na request, ten narzut szybko się kumuluje.

Historia cache'owania jest też bardziej nuansowana, niż się początkowo wydaje. Tak, input caching (prefill caching) pomaga przy ogromnym kontekście, jaki niosą agenci kodujący. Ale workload prefill jest podzielony między cache'owane tokeny a nowe tokeny wymagające rzeczywistej komputacji. Krótkie, inkrementalne prefille po wykonaniu narzędzia mają inne charakterystyki wydajności niż początkowe ładowanie długiego kontekstu. Systemy serwowania muszą efektywnie obsługiwać oba przypadki, a optymalne strategie mogą się różnić między nimi.

Shell commands nadal rządzą światem

Jeśli myślałeś, że agenci kodujący będą zajmować się wyrafinowanym rozumowaniem i złożonym refaktoringiem, nie myliłeś się – ale rzeczywistość jest bardziej chaotyczna. spośród 433 000 wywołań narzędzi przechwyconych w trace'ach, 76% to wykonania shella lub komend. Uruchamianie buildów, testów, operacji git, manipulacji plików przez narzędzia CLI – ta niezbyt efektowna robota, która składa się na prawdziwe dzienne workflow tworzenia oprogramowania.

Edycje plików stanowiły 11%, odczyty i wyszukiwania plików 9%, a planowanie, delegacja do sub-agentów i wyszukiwania webowe zajmowały resztę. Ta koncentracja na komendach shella ma znaczenie z kilku powodów. Po pierwsze, to operacje długoogonowe: ls jest szybki, ale uruchomienie pełnego suite'u testów lub kompilacja dużego codebase'u może trwać minuty. Rozkład opóźnień rozciąga się na cztery rzędy wielkości, co czyni planowanie pojemności koszmarem.

Po drugie, słownik narzędzi różni się znacząco między agentami. Claude Code korzystał z 54 różnych narzędzi, podczas gdy Codex używał 31, ale oba koncentrowały zdecydowaną większość wolumenu w tym samym podstawowym zestawie – shell, edycje plików, odczyty plików. To sugeruje, że optymalizacja pod kątem tych wysokiej częstotliwości narzędzi mogłaby przynieść nieproporcjonalne usprawnienia, nawet bez atakowania pełnego ekosystemu narzędzi.

Co to oznacza dla twojej infrastruktury

Jeśli budujesz lub operujesz narzędziami programistycznymi wspomaganymi AI, to badanie wskazuje na kilka konkretnych wniosków.

Myśl workflowami, nie requestami. Twoja infrastruktura serwowania musi uwzględniać autonomiczny, wielokrokowy charakter koding agents. To oznacza dłużej działające konteksty requestów, bardziej wyrafinowane zarządzanie stanem i możliwości batch schedulingu, które grupują powiązane wywołania narzędzi razem.

Optymalizuj pod kątem przerw w bezczynności. Użytkownicy spędzają średnio 46,7 minuty między requestami, mimo że mediana czasu "myślenia" wynosi zaledwie 1,4 minuty. Rozkład jest ekstremalnie ciężkoogonowy – niektórzy developerzy iterują szybko, podczas gdy inni zaczynają request i wracają po godzinach. Sprytne prefetching i strategie re-prefill w tych okresach bezczynności mogłyby dramatycznie zmniejszyć odczuwalne opóźnienia bez zwiększania kosztów compute.

Oddziel swoje ścieżki prefill i decode. Stosunek input-output 294:1 oznacza, że twój prefill computation jest prawdopodobnie dominującym kosztem. Inkrementalne prefille po wykonaniu narzędzi potrzebują innej optymalizacji niż początkowe ładowanie kontekstu. Rozważ oddzielne pulę zasobów lub polityki schedulingu dla tych różnych typów workloadu.

Nie zapominaj o infrastrukturze wykonawczej narzędzi. Gdy 76% aktywności agentów to komendy shella, twoja konteneryzacja, wzorce dostępu do filesystemu i cache'owanie narzędzi buildowych stają się pierwszorzędnymi kwestiami dla serwowania AI agentów. Inferencja modelu to tylko część pipelinu.

Droga przed nami

Zespół TraceLab upublicznił swój pipeline do zbierania i analizy trace'ów, co umożliwia zespołom infrastrukturalnym generowanie własnych trace'ów i optymalizację pod kątem rzeczywistych wzorców użycia zamiast syntetycznych benchmarków. Ten rodzaj realnych danych jest dokładnie tym, czego potrzebuje przestrzeń AI infrastructure, gdy dojrzewa od fazy "niech to w ogóle działa" do "niech to działa na masową skalę".

Dla społeczności NameOcean Vibe Hosting te wnioski podkreślają, dlaczego inwestujemy w infrastrukturę wykraczającą poza prostą alokację GPU. Serwowanie AI coding agents to nie tylko surowy compute – to zrozumienie unikalnych charakterystyk agentic workloads i budowanie systemów, które mogą obsłużyć autonomię, wielokrokowość i ciężar narzędzi w rzeczywistej rzeczywistości tego, jak developerzy faktycznie używają tych narzędzi.

Era koding agents właśnie się zaczyna, a decyzje infrastrukturalne, które podejmujemy dziś, ukształtują to, jak efektywnie te narzędzia będą służyć developerom przez lata.