Войната на AI код асистентите влезе в нова фаза

След като Claude Code, Codex и Gemini CLI вече са използвани от хиляди разработчици по света, въпросът не е дали тези инструменти работят, а как да ги пуснеш в мащаб без да фалираш или да въведеш толкова забавяне, че разработчиците да си хвърлят клавиатурите.

Ново изследване от UW SyFI Lab дава конкретни числа за реалните натоварвания на AI агентите за код, и резултатите вероятно ще те изненадат. Spoiler: инфраструктурата ти за serving вероятно не е оптимизирана за това.

Какво е TraceLab?

TraceLab е изследователска лаборатория, която събира и анализира реални сесии на AI код асистенти. Техният екип е обработил над 4,300 сесии с приблизително 55 милиарда токена. Целта? Да разбере как разработчиците всъщност използват тези инструменти и какво означава това за инфраструктурата.

Революцията на автономните агенти

Нещо важно, което става ясно от изследването: AI код асистентите не просто отговарят на въпроси. Те изпълняват планове. Когато помолиш AI да имплементира функционалност или да оправи бъг, не стартираш обикновена заявка. Стартираш автономен процес, в който модеът мисли, изпълнява shell команди, чете и променя файлове, пуска тестове и повтаря докато приключи.

Ето една цифра, която говори всичко: всяка заявка на потребител предизвиква средно 8.8 цикъла "модел-инструмент" преди да приключи. За всяко запитване има почти девет рунда на генериране последвано от изпълнение на инструмент. Моделът не просто говори - той действа.

И тук идва нещо интересно: 88% от всички LLM inference рундове се случват не в отговор на потребителски вход, а в отговор на резултати от инструменти. Това променя всичко за планирането на throughput.

Асиметрията, която разбива твоя cache

Ето едно число, което трябва да накара всеки инфраструктурен инженер да се замисли: входните токени надвишават изходните 294 пъти. В анализираните трасета моделите са прочели 52.56 милиарда кеширани входни токена и са добавили 2.34 милиарда нови, но са генерирали едва 186.9 милиона изходни токена.

Един типичен рунд носи 32K до 256K токена prefix и добавя само няколкостотин до няколко хиляди токена преди да декодира няколкостотин на изхода.

Това създава напълно различен профил на производителност. Традиционната LLM inference се фокусира върху generation throughput - колко токена в секунда можем да произведем. Но при код асистентите проблемът често не е скоростта на декодиране. Проблемът е time-to-first-token (TTFT) след връщане на резултата от инструмент.

Екипът установи, че TTFT на Codex за всяка стъпка е около 3.1 секунди. Това е roughly 25% от общото време за генериране на рунд. Когато правиш девет рунда на заявка, това натрупване става сериозен проблем.

Кеширането също е по-сложно отколкото изглежда. Да, input caching помага с огромния контекст, който код агентите носят. Но prefill натоварването се разделя между кеширани токени и нови токени, които изискват реално изчисление. Късите инкрементални префили след изпълнение на инструменти имат различни характеристики от първоначалното зареждане на дълъг контекст.

Shell командите владеят света

Ако си мислел, че код агентите ще правят сложни разсъждения и рефакторинг, не си бил далеч от истината - но реалността е по-различна. От 433,000 инструментни извиквания цели 76% са shell или команди. Пускане на build-ове, тестове, git операции, манипулации на файлове през CLI - негламурозната работа, която всъщност представлява ежедневния workflow на софтуерната разработка.

File edits са едва 11%, file reads и търсене - 9%, а планиране, delegating към sub-agent и уеб търсения - останалото.

Тази концентрация в shell команди има значение поради няколко причини. Първо, това са операции с тежки разпределения. Едно ls е бързо, но пускането на пълен test suite или компилиране на голям codebase може да отнеме минути. Latency разпределението обхваща четири порядъка на големина, което прави capacity planning кошмар.

Второ, речникът от инструменти варира значително между агентите. Claude Code използва 54 различни инструмента, Codex - 31, но и двамата концентрират огромната част от обема си в едни и същи основни - shell, file edits, file reads. Това подсказва, че оптимизацията за тези високочестотни инструменти може да даде огромни подобрения, дори без да се закачаш целият tool ecosystem.

Какво означава това за твоята инфраструктура

Ако строиш или оперираш AI-powered development инструменти, това изследване дава няколко конкретни насоки.

Мисли в workflow-ове, не в заявки. Инфраструктурата ти за serving трябва да отчита автономната, многостъпкова същност на код агентите. По-дълги контексти на заявки, по-сложно управление на състоянието и batch scheduling възможности, които групират свързани инструментни извиквания заедно.

Оптимизирай за idle периодите. Потребителите прекарват средно 46.7 минути между заявки, въпреки че медианата на time-to-think е само 1.4 минути. Разпределението е изключително тежко-опашато - някои разработчици итерират бързо, други пуснат заявка и се върнат часове по-късно. Умно предварително зареждане и re-prefill стратегии по време на тези idle периоди могат драстично да намалят усещаната латентност без да увеличат разходите за compute.

Раздели пътищата за prefill и decode. Съотношението 294:1 означава, че prefill изчисленията вероятно са доминиращата ти цена. Инкременталните префили след инструментно изпълнение изискват различна оптимизация от първоначалното зареждане на контекст. Обмисли отделни resource pools или scheduling политики за тези различни типове натоварвания.

Не забравяй инструментната изпълнителна инфраструктура. Когато 76% от активността на агента са shell команди, container orchestration, файлова система достъп и build tool caching стават първокласни грижи за AI agent serving. Моделната inference е само част от pipeline-а.

Бъдещето

Екипът на TraceLab е open-sourced техния trace collection и analysis pipeline. Това означава, че инфраструктурни екипи могат да генерират свои собствени трасета и да оптимизират за реални модели на използване вместо синтетични бенчмаркове. Този вид реални данни е точно това, от което AI инфраструктурното пространство се нуждае докато преминава от "да го накараме да работи" към "да го накараме да работи в мащаб".

За общността на NameOcean Vibe Hosting тези прозрения подчертават защо инвестираме в инфраструктура, която надхвърля простото GPU разпределение. Serving на AI код агенти не е просто заради raw compute - става дума за разбиране на уникалните характеристики на agentic workloads и изграждане на системи, които могат да се справят с автономната, многостъпкова, инструментно-тежка реалност на това как разработчиците всъщност използват тези инструменти.

Ерата на код агентите едва започва, и инфраструктурните решения, които вземаме днес, ще определят колко ефективно тези инструменти служат на разработчиците в продължение на години.