Google отдаст в облако песочницы, на которых живёт Gemini

Google 22 октября на конференции Linux Foundation AGNTCon+MCPCon в Сан-Хосе представила Agent Compute Engine. Это сервис, который выдаёт каждому ИИ-агенту собственную аппаратно изолированную microVM, лёгкую виртуальную машину со своим ядром. До сих пор на нём работали только Gemini, Antigravity и пайплайны обучения моделей самой Google. Клиентам Google Cloud превью обещают позже в этом году.

Как сообщает The New Stack, агентные нагрузки, по словам Google, стали одними из самых быстрорастущих потребителей вычислений и хранилища во всём её парке. В анонсе в блоге Google Cloud компания формулирует причину так: масштабирование Gemini показало, что безопасный запуск автономных агентов в первую очередь задача инфраструктуры.

Почему не VM и не контейнеры

Объясняют выбор Рохит Джнагал и Раманатан Венкатапатхи, оба в ранге distinguished engineer в Google. Обычные виртуальные машины дают много контроля, но медленно загружаются, приостанавливаются и возобновляются. Агенты же стартуют, засыпают и просыпаются постоянно, так что ждать машину им нельзя. Контейнеры решают часть проблемы, «но есть множество примеров, вроде агентов для программирования и ассистентов разработчика, которым нужна полная изоляция и контроль над средой агента на уровне ядра и root».

Поэтому команда начала с нуля и собрала, по их словам, «единую вычислительную платформу для агентов Google». Теперь ею смогут пользоваться и клиенты.

Компьютер, который засыпает между вызовами

По сути каждый агент получает постоянный изолированный компьютер с root-доступом. В нём он гоняет shell-скрипты, работает с headless-браузером и пишет код, а цикл агента может длиться неделями. Те же машины рассчитаны на массовые сценарии: циклы оценки, которыми передовые лаборатории проверяют свои модели, бенчмарки и обучение с подкреплением. Ещё на Agent Compute Engine работают изолированные бэкенды собственных сервисов Google.

Экономика держится на простом наблюдении инженеров: большую часть времени агент ждёт модель или пользователя. Когда агент закончил вызов инструмента и перешёл в фазу «размышления», microVM сообщает хосту, что простаивает. Хост сохраняет её состояние в снимок, и до следующего вызова машина не занимает активных ресурсов. Возобновляется она из этого снимка. Чтобы плотнее упаковать агентов на одной физической машине, сервис запускает их из одного шаблона ОС и делит память между ними в режиме copy-on-write: общие страницы копируются только тогда, когда агент их меняет.

Под капотом Cloud Hypervisor, открытый монитор виртуальных машин. У каждой microVM своё гостевое ядро и root.

Внутри нечего красть

Скорость в этой истории вторична: главное, чтобы агент не выбрался из песочницы. Джнагал и Венкатапатхи приводят пример корпоративного агента, который разбирает почту пользователя и натыкается на письмо со скрытой инструкцией: найти на машине API-ключи и отправить их на внешний адрес. Чаще всего модель такое проигнорирует, пишут они, но не всегда. Отсюда отправная точка: «Мы исходили из одного правила: считать, что внутри песочницы всем распоряжается атакующий, и добиваться, чтобы ему там нечем было воспользоваться».

На практике это выглядит так:

• каждая сессия агента живёт в однопользовательской microVM с памятью, защищённой от типичных ошибок работы с ней;
• ни в памяти, ни на диске секретов нет, а единственная идентичность машины короткоживущая, привязана к сессии и выдаётся через один локальный слушатель на VM;
• стандартного сетевого интерфейса у microVM нет, весь трафик идёт через прокси за пределами песочницы;
• когда агенту нужен, скажем, Google Drive, Agent Gateway проверяет делегирование от пользователя и идентичность песочницы и только потом подставляет настоящие учётные данные, тоже снаружи;
• трафик шифруется сквозным образом, снимки и диски зашифрованы при хранении;
• хост работает как устройство без состояния с файловой системой только для чтения, а железо и прошивка криптографически проверяются при каждой загрузке.

Всё это опирается на платформы безопасности Titan и Titanium, причём Titanium здесь выступает как IPU, отдельный процессор, на который Google выносит инфраструктурные задачи с основного железа.

Кто ещё продаёт песочницы

Идея не новая. E2B запускает каждую песочницу в Firecracker, открытой технологии микровиртуализации, которую AWS изначально сделала для Lambda, и умеет ставить её на паузу с сохранением памяти и файловой системы, а затем возобновлять примерно за секунду. Daytona начинала с контейнеров, а в июле добавила песочницы на microVM: их можно приостановить целиком или разветвить работающую машину на идентичные копии. Обе компании поддерживают любое облако.

Bedrock AgentCore от AWS тоже даёт каждой сессии агента свою microVM. Пока агент ждёт модель или инструмент, за CPU там не платят, но память тарифицируется, пока среда выполнения её не заберёт. Сессия ограничена восемью часами, а в августе AWS добавила инстансы на базе EC2, которые держат общие сессии до 14 дней. Google на этом фоне сразу говорит о циклах агента длиной в недели.

Да и у самой Google это не первая песочница. В GKE уже есть управляемая версия Agent Sandbox, открытого проекта для Kubernetes, запущенного в ноябре прошлого года, а через Gemini Enterprise Agent Platform компания продаёт песочницы для исполнения кода и управления компьютером.

Agent Substrate для своих кластеров

Тем, кто не хочет отдавать агентов в управляемый сервис Google, компания предлагает Agent Substrate, открытую среду выполнения для GKE, анонсированную в мае. Она построена поверх Agent Sandbox и добавляет лёгкую управляющую плоскость. По словам Google, та выдерживает миллионы короткоживущих вызовов инструментов, под которыми обычный Kubernetes бы захлебнулся.

Логика та же, что у Agent Compute Engine: память простаивающего агента сохраняется в снимок, а машина возвращается в пул до новой работы. Google обещает до 10 раз большую плотность по сравнению с традиционными вычислениями. В бенчмарке на 200 000 агентов Substrate, по данным компании, обрабатывал 500 активаций в секунду, а агенты засыпали и просыпались меньше чем за полсекунды.

Изолировать песочницу можно через microVM или gVisor, у каждого агента своя криптографическая идентичность, учётные данные к исходящим запросам добавляют прокси вне песочницы. Substrate работает на любом Kubernetes-кластере, и, как утверждает Google, с любой обвязкой агента, включая Claude Code, OpenClaw и Hermes от Nous Research.

«Мы сделали Hermes Enterprise, чтобы клиенты могли разворачивать его в своей существующей инфраструктуре, а мы при этом брали на себя изоляцию каждого агента и расширяемый контроль доступа, - говорит Эрве Бизира, директор по развитию бизнеса Nous Research. - Agent Substrate решает обе задачи на уровне платформы, да ещё и бережёт ценные вычислительные ресурсы».