До 300 изолированных песочниц в секунду на кластер и меньше секунды до первой инструкции — с такими цифрами разговор об агентном ИИ внезапно перестает быть только про GPU. CPU для ИИ-агентов возвращаются в центр инфраструктурной повестки: если модель не просто отвечает, а вызывает инструменты, пишет код и дергает API, без обычного процессора вся магия быстро упирается в прозаичный orchestration overhead. Для русскоязычной IT-аудитории это важный сдвиг: инвестиции в агентные системы все чаще будут измеряться не только мощностью ускорителей, но и качеством CPU-слоя, изоляции и облачной платформы.
Об этом сообщает The New Stack по итогам беседы с Мо Фархатом, который отвечает за Axion и Arm-виртуальные машины в Google Compute Engine, и Бхумиком Пателем, курирующим экосистему Arm для облака и ИИ. Их тезис звучит почти провокационно на фоне тотального культа GPU: по мере перехода от чат-ботов к агентам CPU становятся не менее, а более важными. Причина простая. Если ранний чат-бот в основном возвращал текст, то агент должен выполнить действие: сходить во внешний сервис, поднять среду, запустить сгенерированный код, подождать ответ от другого агента, собрать результат и не уронить при этом прод.
Именно здесь начинается работа, которую GPU делают плохо или вообще не делают. По словам собеседников из Google и Arm, на CPU ложатся оркестрация, вызовы API, управление памятью, конкурентное исполнение и контроль потока. Проще говоря, ускоритель нужен, чтобы быстро прогнать модель, а центральный процессор нужен, чтобы вся система вела себя как система, а не как дорогой калькулятор токенов. Фархат сравнивает роль CPU с диспетчером воздушного движения: он не летит вместо самолета, но без него все остальные участники быстро начинают мешать друг другу. Для тех, кто строит агентные пайплайны поверх Kubernetes, внутренних платформ или корпоративных API, мысль неприятная, но полезная: узким местом часто становится не инференс как таковой, а то, что происходит вокруг него.
Это не значит, что CPU внезапно заменят ускорители в больших моделях. Речь скорее о расширении их зоны ответственности. В материале The New Stack упоминается, что процессоры уже показывают приемлемую производительность на сравнительно небольших моделях порядка 8 млрд параметров. Такие модели могут выступать в роли суммаризаторов, классификаторов или точечных оценщиков внутри агентной цепочки. И это очень практичный сценарий. Не каждый шаг агентного workflow требует большого LLM-вызова на дорогом GPU-кластере; часть задач дешевле и быстрее выполнять локально на CPU, особенно если важны задержка, стоимость и предсказуемость. Для бизнеса это означает более гибкую архитектуру: дорогой ускоритель остается для тяжелого reasoning, а массу служебной работы можно разложить по CPU-ресурсам.
Вторая причина, почему CPU для ИИ-агентов становятся критичными, еще менее гламурная, но куда более жизненная: безопасность. Если агент генерирует и исполняет код от имени пользователя или компании, его нужно изолировать так, чтобы ошибка или откровенно плохой код не получили доступ к боевым системам. Патель прямо говорит о необходимости отдельного слоя изоляции. В качестве такого слоя Google продвигает gVisor — open source-проект, который работает между приложением и хостовой ОС, а в управляемом виде доступен через GKE Agent Sandbox. Идея здесь довольно прозрачная: агенту не обязательно доверять, достаточно посадить его в песочницу и ограничить последствия. Для корпоративной разработки это, пожалуй, одна из самых трезвых мыслей во всей агентной гонке. Пока одни продавцы обещают автономных цифровых коллег, платформа должна решить более скучную задачу: как дать этому коллеге возможность что-то исполнять и при этом не открыть дыру в инфраструктуре.
Google делает ставку не только на изоляцию, но и на масштаб. По словам Фархата, GKE Agent Sandbox способен запускать до 300 песочниц в секунду на кластер, а время до первой инструкции составляет меньше секунды. Это уже не демонстрация на сцене, а заявка на эксплуатационный сценарий, где агентов много, они рождают субагентов, потом простаивают в ожидании ответов, а затем снова просыпаются. Такой профиль нагрузки плохо ложится на классическую модель «подняли pod и держим, пока жив». Поэтому платформа использует snapshots подов и warm pools, чтобы не платить за простаивающие экземпляры как за постоянно занятые. Для тех, кто считает экономику agentic-нагрузок, это, возможно, важнее любого маркетинга про автономность: агент почти всегда живет рывками, и инфраструктура должна быть оптимизирована именно под такую рваную нагрузку.
Дальше начинается уже привычный облачный торг за цену и производительность. На конференции Google Cloud Next компания заявила, что клиенты, использующие Arm-процессоры Axion в GKE Agent Sandbox, могут получить на 30% лучшее соотношение цены и производительности по сравнению с ближайшим ведущим облачным провайдером. Это, разумеется, оценка самой Google, а не независимый бенчмарк, и относиться к ней стоит именно как к вендорскому заявлению. Но даже с этой оговоркой сигнал понятен: поставщики облака продают не просто compute, а специализированные профили под агентные сценарии. Google отдельно выделяет две линейки: Axion N4A — для стоимости и энергоэффективности, что полезно для песочниц, и C4A — для высокой однопоточной производительности, которая нужна в stateful-оркестрации и control-flow логике. Перевод на человеческий: CPU-выбор для агентной системы скоро будет таким же предметным, как выбор базы данных или очереди сообщений.
Для разработчиков и IT-руководителей из этого следует довольно практичный вывод. Если в дорожной карте есть ИИ-агенты, смотреть только на доступ к GPU уже недостаточно. Придется оценивать, как быстро платформа поднимает изолированные окружения, сколько стоит простой агента между вызовами, какие маленькие модели можно оставить на CPU, и насколько зрелы механизмы sandboxing. Иначе легко получить красивую демку с умным агентом и очень некрасивый счет за инфраструктуру, плюс головную боль у security-команды. На этом фоне CPU для ИИ-агентов выглядят не запасным колесом, а тем самым слоем, без которого продуктовая картинка не доедет до продакшена.
Похоже, следующий раунд конкуренции в агентном ИИ пройдет не только между моделями, но и между облачными платформами, которые лучше других научатся сочетать ускорители, CPU, изоляцию и экономику короткоживущих нагрузок. И если эта логика закрепится, то выигрывать будут не те, у кого просто больше GPU, а те, кто сумеет дешевле и безопаснее превратить ответ модели в реальное действие. Подробнее об этом кейсе пишет .