Az AI kódoló asszisztensek új korszaka: mit tanulhatunk a valós felhasználási adatokból?

Az AI kódoló asszisztensek háborúja egy új fejezethez érkezett. A Claude Code, a Codex és a Gemini CLI már világszerte bizonyított a fejlesztők kezében, és az kérdés már nem az, hogy működnek-e ezek az eszközök – hanem az, hogyan lehet őket nagy léptékben működtetni anélkül, hogy a költségek az egekbe szöknének vagy a késleltetés miatt a fejlesztők a billentyűzetüket akarják majd falhoz vágni.

A University of Washington SyFI laborjának friss kutatása most kemény számokkal szolgál arról, hogyan néznek ki a valós kódoló agent munkaterhelések – és az eredmények meglepőek lehetnek. Spoiler: a meglévő LLM kiszolgáló infrastruktúrád valószínűleg nincs erre optimalizálva.

Az autonóm forradalom, amire senki sem készült fel

Van valami alapvetően fontos a kódoló agentekben, ami nyilvánvalónak tűnik, amint kimondják: ezek nem egyszerűen válaszolnak kérdésekre. Tervet hajtanak végre. Amikor egy AI kódoló asszisztensnek azt kéred, hogy implementáljon egy funkciót vagy javítson egy hibát, nem egy egyszerű kérdés-válasz tranzakciót indítasz – hanem egy autonóm munkafolyamatot indítasz el, ahol a modell gondolkodik, shell parancsokat hajt végre, fájlokat olvas és módosít, teszteket futtat, és iterál, amíg meg nem elégszik (vagy amíg meg nem szakítod).

A kutatócsapat több mint 4300 valós felhasználási sessziót rögzített, amelyek összesen nagyjából 55 milliárd tokent tartalmaztak, és az minták megdöbbentőek. Minden felhasználói kérés átlagosan 8,8 LLM-eszköz ciklust indít a befejezésig. Gondolj bele: minden kérdéshez, amit egy fejlesztő feltesz, közel kilenc kör tartozik, ahol a modell generál, majd eszköz hajt végre. A modell nem csak beszél – cselekszik. És az összes LLM inferencia kör 88%-a nem felhasználói inputra válaszul történik, hanem eszköz eredményekre.

Ennek hatalmas következményei vannak a throughput tervezés szempontjából. A hagyományos chatbótok lényegében kérés-válasz rendszerek ritka utólagos kérdésekkel. A kódoló agentek inkább hosszan futó autonóm folyamatoknak felelnek meg, gyakori kontextus-váltásokkal a generálás és végrehajtás fázisai között. Az autoscaling politikáid, a kéréssorba-állítási stratégiáid, a cache-elési megközelítésed – mindezeket újra kell gondolnod az autonóm, többlépcsős munkafolyamatok szemüvegén keresztül, nem egyszerű beszélgetésként.

Az input-output aszimmetria, ami tönkreteszi a cache-ed

Itt van egy szám, ami minden infrastruktúra mérnököt megállásra késztet: az inputok túlsúlya az outputokkal szemben 294:1. Az elemzett trace-ekben a modellek 52,56 milliárd cache-elt input tokent olvastak és 2,34 milliárd újat prefill-eltek, miközben mindössze 186,9 millió output tokent generáltak. Egy tipikus kör 32K és 256K token közötti prefix-en ül, és csak néhány száz-több ezer tokent ad hozzá, mielőtt pár százat dekódolna.

Ez egy alapvetően más teljesítményprofilt teremt, mint amire a legtöbb LLM kiszolgáló rendszer optimalizálva van. A hagyományos nyelvi modell inferencia erősen a generálási throughput-ra fókuszál – hány tokent tudunk másodpercenként előállítani. De a kódoló agenteknél a szűk keresztmetszet gyakran nem a dekódolási sebesség; a time-to-first-token (TTFT) az eszköz végrehajtás után. A csapat azt találta, hogy a Codex TTFT minden lépésnél körülbelül 3,1 másodperc, ami a kör teljes generálási idejének nagyjából 25%-át teszi ki. Amikor kilenc kört csinálsz kérésenként, ez a overhead gyorsan összeadódik.

A cache-elés története is árnyaltabb, mint elsőre tűnik. Igen, az input cache-elés (prefill caching) segít a hatalmas kontextuson, amit a kódoló agentek hordoznak. De a prefill munkaterhelés megoszlik a cache-elt tokenek és a tényleges számítást igénylő új tokenek között. A rövid, inkrementális prefill-ek az eszköz végrehajtás után más teljesítményjellemzőkkel rendelkeznek, mint a kezdeti hosszú-kontextus betöltés. A kiszolgáló rendszereknek mindkettőt hatékonyan kell kezelniük, és az optimális stratégiák eltérhetnek ezek között az esetek között.

A shell parancsok továbbra is meghatározzák a világot

Ha azt gondoltad, hogy a kódoló agentek kifinomult érveléssel és komplex refactoring-gal fognak foglalkozni, nem tévedtél – de a valóság kaotikusabb. A trace-ekben rögzített 433 000 eszközhívásból 76% shell vagy parancs végrehajtás volt. Build-ek futtatása, tesztek, git műveletek, fájlmanipuláció CLI eszközökön keresztül – az alantas munka, ami a szoftverfejlesztés mindennapi munkafolyamatát alkotja.

A fájl szerkesztések 11%-ot, a fájl olvasások és keresések 9%-ot tettek ki, a tervezés, sub-agent delegálás és webes keresések pedig a maradékot. Ez a koncentráció a shell parancsokban több okból is fontos. Először is, ezek hosszú farok eloszlású műveletek: egy egyszerű ls gyors, de egy teljes tesztcsomag futtatása vagy egy nagy kódbázis fordítása percekig is eltarthat. A késleltetés eloszlása négy nagyságrendet fed le, ami a kapacitástervezést rémálommá teszi.

Másodszor, az eszköz szókincs jelentősen eltér az agentek között. A Claude Code 54 különböző eszközt használt, míg a Codex 31-et, de mindkettő a volumen túlnyomó többségét ugyanarra a core halmazra koncentrálta – shell, fájl szerkesztések, fájl olvasások. Ez arra utal, hogy ezeknek a nagy gyakoriságú eszközöknek az optimalizálása aránytalanul nagy javulást hozhat, még az teljes eszközökészlet kezelése nélkül is.

Mit jelent ez az infrastruktúrád számára?

Ha AI-vezérelt fejlesztői eszközöket építesz vagy üzemeltetsz, ez a kutatás több konkrét következtetésre utal.

Gondolkodj munkafolyamatokban, ne kérésekben. A kiszolgáló infrastruktúrádnak figyelembe kell vennie a kódoló agentek autonóm, többlépcsős természetét. Ez hosszabb ideig futó kérés kontextusokat, kifinomultabb állapotkezelést és batch ütemezési lehetőségeket jelent, amelyek csoportosítják a kapcsolódó eszközhívásokat.

Optimalizálj az üresjárati időkre. A felhasználók átlagosan 46,7 percet töltenek a kérések között, annak ellenére, hogy a medián gondolkodási idő csak 1,4 perc. Az eloszlás rendkívül heavy-tailed – egyes fejlesztők gyorsan iterálnak, míg mások elindítanak egy kérést és órák múlva térnek vissza. Az okos prefetching és újra-prefill stratégiák ezekben az üresjárati időszakokban drámaian csökkenthetik a észlelt késleltetést anélkül, hogy növelnék a számítási költségeket.

Válaszd szét a prefill és decode útvonalakat. A 294:1 input-output arány azt jelenti, hogy a prefill számításod valószínűleg a domináns költség. Az inkrementális prefill-ek az eszköz végrehajtás után más optimalizálást igényelnek, mint a kezdeti kontextus betöltés. Érdemes külön erőforrás poolokat vagy ütemezési politikákat fontolóra venni ezekhez a különböző munkaterhelési típusokhoz.

Ne feledkezz meg az eszköz végrehajtási infrastruktúráról sem. Amikor az agent aktivitás 76%-a shell parancsok, a konténer orchestráció, a fájlrendszer hozzáférési minták és a build eszköz cache-elés elsőrangú szemponttá válnak az AI agent kiszolgálásnál. A modell inferencia csak a pipeline egy része.

Mi vár ránk

A TraceLab csapat open-source-szá tette a trace gyűjtési és elemzési pipeline-jukat, lehetővé téve az infrastruktúra csapatok számára, hogy saját trace-eket generáljanak és a valós felhasználási mintákra optimalizáljanak, szintetikus benchmarkok helyett. Ez a fajta valós adat exactly what the AI infrastructure space needs, ahogy érettebbé válik a "működik" szintről a "nagy léptékben is működik" szintre.

A NameOcean Vibe Hosting közösség számára ezek a betekintések kiemelik, miért fektetünk be olyan infrastruktúrába, amely túlmutat az egyszerű GPU allokáción. Az AI kódoló agentek kiszolgálása nem csak a nyers számítási kapacitásról szól – az agentic munkaterhelések egyedi jellemzőinek megértéséről és olyan rendszerek építéséről szól, amelyek képesek kezelni a kódoló agentek autonóm, többlépcsős, eszköz-intenzív valóságát.

A kódoló agentek korszaka csak most kezdődik, és az infrastruktúra döntések, amelyeket ma hozunk, évekre meghatározzák, mennyire hatékonyan szolgálják majd ki ezek az eszközök a fejlesztőket.