Суть проблемы: GPU не упирается, а сервер простаивает
Одна RTX 5090, Ryzen 7 9800X3D и локальный сервер инференса с 12 слотами под параллельные запросы. Владелец этой сборки запустил 25 агентов, чтобы занять все слоты работой, и быстро попал в неожиданный сценарий. Агенты начали застревать на этапе tool call, сервер работал на пределе и почти не двигал задачи вперёд.
Видеокарта при этом не была виновата. После оптимизаций кэша и переиспользования префиллов GPU выдавал в среднем около 700 токенов в секунду на реальной работе: с thinking, вызовами инструментов и прочими накладными расходами, а не в синтетическом тесте. Проблема нашлась в другом месте. Диспетчер задач показал, что CPU загружен на 100% по всем потокам. Автор описал этот случай в посте на r/LocalLLaMA.
Вывод формулируется коротко: в агентном кодинге с активным использованием инструментов ограничением может стать процессор, а не декодирование и не префилл. GPU справляется со своей частью, а пайплайн стоит, потому что застрял на оркестрации.
Оговорка важная: это опыт одного проекта. Речь о портировании Kenshi на движок Godot, на конкретной сборке с RTX 5090, Ryzen 7 9800X3D и 12-слотовым сервером. Переносить цифры на любую другую конфигурацию без проверки не стоит.
Как выглядела деградация: агенты зависают на tool call
При 25 агентах на 12-слотовом сервере почти все агенты начали застревать на этапе tool call. Сервер едва работал: задачи висели, прогресс почти не двигался, хотя генерация как таковая узким местом не была.
Ключевая деталь: деградация проявлялась не на декодировании и не на префилле, а именно на работе с инструментами. Это разные фазы пайплайна, и нагружают они разное железо.
Декодирование и префилл нагружают GPU и память. Tool call - это оркестрация: вызовы инструментов, запуск тестов, ожидание результатов, переключения между контекстами агентов, разбор ответов и повторный запуск цикла. Значительная часть этой работы ложится на CPU, и когда таких циклов становится 25 одновременно, процессор начинает захлёбываться.
Отсюда практический признак: если GPU загружен ниже ожидаемого или простаивает, а агенты висят на вызове инструмента, ищите проблему не в модели.
Диагностика: почему смотреть надо на CPU, а не на GPU
Автор проверил диспетчер задач и обнаружил, что упирается не GPU и не память, а CPU: 100% по каждому потоку. Видеокарта при этом работала в комфортном режиме.
Проблему легко пропустить из-за характера метрик. Высокая скорость генерации (порядка 700 токенов в секунду) выглядит как признак здоровой системы: ускоритель быстрый, VRAM в норме, модель отвечает. Но эти показатели ничего не говорят о том, успевает ли процессор обслуживать оркестрацию. Пайплайн может стоять при внешне свободном GPU.
Что держать под наблюдением при агентном кодинге:
- загрузку CPU по потокам, а не только общую загрузку системы;
- очереди задач и время ожидания на этапе tool call;
- загрузку GPU и объём занятой VRAM;
- число одновременно активных агентов и количество слотов сервера.
Общая загрузка CPU усредняется по всем ядрам и может выглядеть терпимо, когда отдельные потоки уже забиты под завязку. Смотреть по потокам полезнее: именно там видно, что процессор не успевает. О том, как читать метрики ускорителя и почему одна цифра без сценария мало что значит, мы разбирали в материале про заявления о 100% эффективности GPU.
Почему Ryzen 7 9800X3D не хватило
Автор говорит прямо: 9800X3D не хватает, чтобы обслуживать работу с инструментами в проекте с интенсивным использованием агентов, хотя сам движок способен работать быстрее.
Нагрузка при 25 агентах и 12 слотах ложится сразу на несколько вещей: планировщик задач, переключение контекста между агентами, обработку вызовов инструментов, запуск тестов и параллельные задачи. Всё это не распараллеливается идеально, и чем больше агентов, тем дороже каждое переключение.
Это не значит, что 9800X3D плохой процессор. С десятками других сценариев он справляется. Речь о конкретной комбинации: множество параллельных агентов, высокая частота вызовов инструментов, один проект с плотным циклом разработки. В такой связке даже сильный по игровым меркам CPU упирается в потолок.
Вывод основан на одной конфигурации и одном проекте. На меньшем числе агентов, при последовательной оркестрации или при другой интенсивности tool call картина может отличаться. Прежде чем планировать апгрейд, стоит измерить, где упирается ваша система.
Что реально помогло: оптимизации до и после
Две оптимизации заметно улучшили картину, хотя и не сняли ограничение полностью.
Оптимизация кэша и переиспользование префиллов
После доработки кэша и переиспользования префиллов GPU вышел на средние 700 токенов в секунду на реальной работе. В эту цифру входят thinking и вызовы инструментов, то есть перед нами не чистый синтетический декод, а показатель на живых задачах. Автор приводит эти данные в том же посте.
Оговорка по цифре: 700 токенов в секунду - средний показатель, а не гарантированный максимум. Он зависит от типа задач, длины контекста и характера нагрузки.
Даже при такой скорости сервер простаивал из-за CPU. Это и есть главный сигнал: оптимизация инференса упирается в потолок, который находится на стороне процессора, а не видеокарты.
Тюнинг фронтенда: 20k - 7k промптов и 43 - 18 минут
Вторая мера касалась организации заданий. До тюнинга фронтенда система передавала промпты объёмом около 20k, после переработки их размер снизился примерно до 7k. Время выполнения сократилось с 43 до 18 минут.
Что изменилось по сути: задания стали компактнее, а новые джобы организованы плотнее. Меньше лишних данных в промпте и более компактные формулировки задач снизили объём передаваемой информации и время прохода. Деталей реализации автор не раскрывает, поэтому конкретные приёмы стоит подбирать под свой пайплайн.
Обе оптимизации улучшили ситуацию, но не убрали ограничение по CPU. Именно поэтому вывод автора звучит как диагноз: реальный лимит сместился на процессор.
Практические выводы для агентного кодинга
Больше агентов, чем слотов
Рекомендация автора: держать агентов больше, чем слотов на сервере. Причина простая: агенты неизбежно простаивают во время использования инструментов и тестов. Пока одни ждут результат, другие могут занять освободившиеся слоты, и сервер не будет пустовать. Об этом он пишет в том же разборе.
Здесь важно не переусердствовать. Правило работает, когда слоты действительно освобождаются, а система успевает обслуживать оркестрацию. Именно на этом шаге и вылезла проблема с CPU: агентов стало больше, чем процессор смог обслужить. Контекст важен, поэтому универсального числа агентов нет.
Общий контекст против фиксированного
Автор отмечает, что общий контекст превосходил фиксированный во всех случаях, которые он пробовал за время проекта. Логика понятна: агенты, работающие с общим состоянием, видят принятые решения и не дублируют работу друг друга, а фиксированный контекст заставляет каждого заново собирать картину.
Это личный опыт без количественных данных. В других проектах результат может отличаться, особенно если агенты слабо связаны между собой или параллельно работают над независимыми частями. Как устроен расход контекста в агентных инструментах и при чём тут prompt cache, мы разбирали в отдельном материале про то, куда утекают токены в AI-агентах.
Кому подходит этот опыт и что делать дальше
Если вы запускаете агентный кодинг с активным использованием инструментов на локальном железе, из этого опыта складывается конкретный чек-лист:
- смотрите на загрузку CPU по потокам, а не только на GPU и VRAM;
- если CPU упирается в 100%, оптимизации кэша и фронтенда помогут, но могут не снять ограничение полностью;
- проверьте число параллельных агентов: возможна ситуация, когда слотов больше, чем система способна обслужить;
- если упор повторяется, рассматривайте более производительный CPU или сокращайте параллелизм.
Апгрейд процессора - не единственный путь. Иногда дешевле уменьшить число одновременных агентов, ужать промпты, перейти на последовательную оркестрацию или перераспределить задачи по времени. Выбор модели и квантизации тоже влияет на итог, потому что tool calling чувствителен к тому, насколько стабильно модель держит формат вызовов: здесь полезно посмотреть на сравнение моделей на 16-24 ГБ VRAM по tool calling, скорости и длине контекста.
Все цифры и выводы относятся к одному проекту (портирование Kenshi на Godot) и одной конфигурации (RTX 5090, Ryzen 7 9800X3D, 12-слотовый сервер). Это не универсальный бенчмарк, и на вашей сборке баланс между GPU и CPU может оказаться другим. Единственный надёжный способ - измерить своё узкое место: включить мониторинг по потокам, зафиксировать время ожидания на tool call и только потом решать, что менять.