Google Cloud и Arm предлагают смотреть на инфраструктуру для ИИ-агентов без привычного гипноза GPU. В материале от 17 июля Google заявляет, что связка GKE Agent Sandbox и Arm-процессоров Axion N4A дает до 30% лучшую price/performance, чем у «следующего гиперскейлера». Для компаний, которые уже примеряют агентный ИИ к продакшену, сигнал простой: не вся агентная нагрузка должна жить на дорогих ускорителях.
Об этом сообщает The New Stack в спонсорском материале Arm и Google. Логика у партнеров довольно приземленная: если большие модели по-прежнему крутятся на GPU и TPU, то оркестрация, вызовы API, управление состоянием агента, выбор инструментов и запуск изолированных сред для сгенерированного кода лучше отдать CPU. Именно на этой части пайплайна и строится их аргумент в пользу Axion, первого серверного Arm-процессора собственной разработки Google, который компания представила в апреле 2024 года.
Почему CPU снова в игре
Главный тезис Google и Arm звучит почти как возвращение к инженерной банальности: под каждый тип нагрузки нужен свой тип железа. Bhumik Patel, Director of Software Ecosystem Development в Arm, говорит, что агентные задачи хорошо ложатся на CPU, потому что это распределенная и конкурентная нагрузка. Проще говоря, агент большую часть времени не «думает как LLM», а координирует шаги: сходить во внешний сервис, дождаться ответа, обновить контекст, вызвать следующий инструмент, проверить промежуточный результат. Для такой работы важны не только сырые терафлопсы, а предсказуемость, стоимость и способность держать много параллельных процессов.
Это хорошо совпадает с тем, как меняется сам рынок. Первая волна генеративного ИИ продавала прежде всего inference и обучение моделей. Волна ИИ-агентов продает уже цепочки действий. В них одна тяжелая модель может соседствовать с кучей «мелкой» системной работы, и если каждую такую операцию гонять через ускорители, счет за облако быстро начинает выглядеть как плохая шутка из отдела FinOps. Отсюда и интерес к CPU-слою как к месту, где можно срезать издержки без отказа от самих AI-сценариев.
Google в этой истории продвигает не только чип, но и весь стек. По словам Mo Farhat, Group Product Manager по Axion в Google, именно GKE Agent Sandbox на инстансах Axion N4A дает до 30% лучшую ценовую эффективность по сравнению с сопоставимой нагрузкой у другого крупного облачного провайдера. Формулировка, конечно, маркетинговая: без деталей тестовой методики и списка конкурентов ее стоит читать аккуратно. Но сама постановка вопроса показательна. Конкуренция между облаками в AI-инфраструктуре смещается от гонки «у кого больше ускорителей» к гонке «кто лучше разложит агентный пайплайн по правильным вычислительным примитивам».
Безопасность как часть архитектуры, а не довесок
Отдельный акцент в материале сделан на GKE Agent Sandbox. Для корпоративного агентного ИИ это, пожалуй, даже важнее цены. Как только агент начинает не просто отвечать текстом, а генерировать и исполнять код, стандартный Kubernetes-кластер превращается в потенциальный источник проблем. Непроверенный код может полезть в соседние приложения, зацепить хостовую ноду или просто сделать что-то интересное для службы безопасности в пятницу вечером. Google продает Sandbox как изолированную среду, где такой код можно запускать безопаснее.
Технически ставка сделана на kernel-level isolation с низкой задержкой и на уже знакомые open source-механизмы. В статье упомянуты gVisor, который работает как защищенная песочница для контейнеров, default-deny network policy в Kubernetes, а также возможность подключать альтернативные sandbox-решения вроде Kata Containers. Важный нюанс: речь не о полном отказе от облачной гибкости, а о попытке совместить изоляцию с нормальной операционной скоростью. Google отдельно подчеркивает, что вертикальный стек изолирует чувствительные задачи на уровне ядра с задержкой менее секунды.
Еще один интересный элемент — GKE Pod snapshots. Для агентных систем это не косметическая функция, а способ не платить за безделье. Агенты часто работают рывками: запустились, что-то посчитали, потом ждут ответ от сервиса, человека или другого агента. Снимки состояния позволяют сохранять и восстанавливать sandbox без полной перезагрузки. Google перечисляет четыре сценария: быстрый старт из «подогретого» снапшота, пауза и возобновление долгих задач, сохранение состояния вроде истории диалога или промежуточных вычислений и воспроизводимость, когда один и тот же baseline можно клонировать для нескольких новых сред. Для инженеров это звучит как шаг к более экономной и более контролируемой эксплуатации агентных рантаймов.
Для разработчиков и платформенных команд вывод довольно практичный. Если компания строит агентные workflow поверх Kubernetes, ей уже недостаточно просто выбрать модель и подключить пару API. Нужна архитектура, в которой отдельно продуманы оркестрация, изоляция исполняемого кода, сохранение состояния и стоимость idle-периодов. Для CTO и IT-директоров это еще и вопрос закупки: возможно, инфраструктуру под агентов пора считать не как «еще немного GPU», а как смесь ускорителей, Arm-CPU и защищенных сред выполнения. Для HR и стартап-фаундеров вывод попроще: спрос смещается в сторону инженеров, которые понимают не только LLM, но и облачную платформу, Kubernetes, sandboxing и FinOps.
Главный вопрос теперь не в том, вытеснят ли CPU ускорители из AI-стека, а в том, насколько быстро облака превратят агентные рантаймы в отдельный класс инфраструктуры со своими ценами, SLA и паттернами проектирования. Если этот сценарий реализуется, рынок будет сравнивать провайдеров уже не по числу доступных GPU, а по тому, насколько дешево, безопасно и предсказуемо они умеют обслуживать агентный ИИ. Подробнее о позиции Google и Arm пишет .