Google отдала в CNCF gVisor, песочницу Anthropic и OpenAI

Google 5 ноября передала Cloud Native Computing Foundation три своих открытых проекта для ИИ-агентов: песочницу gVisor, среду выполнения Agent Substrate и систему дообучения с подкреплением OpenRL, сообщила Google Cloud в своём блоге. Работать с этим можно уже сейчас только в одном случае: Agent Substrate вышел в версии 1.0 и общем доступе на GKE, а его открытый код ставится на любой кластер Kubernetes. Главное обещание по gVisor, почти нативный ввод-вывод на обычном ядре Linux, зависит от мейнтейнеров ядра: передача в CNCF лишь открывает путь к приёму нужных патчей.

Все три проекта приняты в CNCF Sandbox, начальную ступень фонда. Сейчас они проходят онбординг вместе с мейнтейнерами из сообщества и переезжают на независимую инфраструктуру сборки, а gVisor уже движется к следующей ступени, Incubation. По словам Google, проекты приняли в прошлом месяце. The News Stack относит принятие заявки gVisor к концу сентября, а начало его онбординга к концу октября.

Что умеет Agent Substrate

Agent Substrate рассчитан на агентов, которые в основном ждут. Агент несколько секунд выполняет код, потом ждёт ответа модели, внешнего API или человека, а в обычном Kubernetes его под всё это время занимает память и CPU. К тому же control plane приходится отслеживать миллионы постоянных объектов, а идентичность агента жёстко привязана к поду.

Substrate отделяет состояние агента от вычислений. Actor хранит память, файлы и идентичность агента. Worker - переиспользуемая песочница из тёплого пула Kubernetes. Gateway контролирует входящий и исходящий доступ и подставляет секреты по идентичности Actor, поэтому ключей внутри среды агента нет. Когда агент уходит в ожидание, его память и файлы сохраняются в хранилище, а Worker сразу возвращается в пул. Со следующим запросом Actor поднимается на любом свободном Worker меньше чем за 500 миллисекунд и продолжает с того же места.

По словам Google, версия 1.0 выдерживает продакшен-нагрузку на миллионах песочниц, даёт в 10 раз большую плотность, чем стандартные среды выполнения контейнеров, и больше 500 приостановок и возобновлений в секунду.

В качестве границы изоляции можно взять microVM Cloud Hypervisor или gVisor, и управление жизненным циклом агентов от этого выбора не меняется. Substrate запускает стандартные OCI-контейнеры, так что агенты на Agent Development Kit (ADK), постоянные среды для кода и офисные агенты работают в нём без доработок. Тем, кто не хочет держать кластеры вообще, Google предлагает в пару к Substrate Agent Compute Engine, свой сервис microVM на Titanium с быстрой гибернацией и форком окружений для оценки и RL-пайплайнов. Превью этого сервиса для клиентов Google Cloud в октябре обещали позже в этом году.

Публичная разработка Substrate началась в мае 2026 года, и с тех пор у проекта набралось больше 100 контрибьюторов. Nous Research строит на нём Hermes Enterprise, на нём же работает проект CNCF kagent, а SPIRITT собирает на Agent Substrate on GKE платформу SPIRITT Workspace. «Agent Substrate on GKE даёт нам изоляцию, чтобы агенты безопасно выполняли код, расширяемость, чтобы подключить собственный рантайм, и плотность, чтобы экономно запускать агентов каждого клиента в масштабе», - говорит гендиректор SPIRITT Тамир Маген (Tamir Magen).

Патчи, которых нет в ядре

gVisor - ядро приложений на Go, которое работает в пространстве пользователя. Оно перехватывает системные вызовы контейнера и обрабатывает их само, поэтому недоверенный код не обращается к ядру хоста напрямую. Обычные контейнеры делят одно ядро со всеми нагрузками на узле, и для побега из такого контейнера хватает одной уязвимости. В отличие от виртуальной машины, gVisor не резервирует фиксированный блок памяти и не требует вложенной виртуализации, а GPU, TPU и checkpoint/restore поддерживает штатно. С Docker и Kubernetes его связывает OCI-рантайм runsc. Northflank, например, изолирует через gVisor GPU-нагрузки там, где вложенная виртуализация недоступна.

Все провайдеры песочниц, включая Google, держат у себя патчи ядра хоста, которые приближают ввод-вывод gVisor к нативному Linux. По словам Google, мейнтейнеры Linux отказывались включать их в основное ядро, пока проектом владел один вендор, а нейтральное управление в CNCF открывает путь к их приёму, и тогда почти нативную скорость получит каждый без дополнительной настройки. До приёма эти патчи остаются у провайдеров, которые поддерживают их сами. Ограничения по скорости известны с самого запуска: в 2018 году InfoQ отмечал, что на нагрузках с большим числом системных вызовов gVisor может работать медленно, а часть вызовов и их аргументов он не поддерживает, так что запустится не каждое приложение.

К мейнтейнерам gVisor присоединятся Ant Group, Modal и Tines, а OpenAI, Tencent и NVIDIA продолжат вносить свой вклад. Google открыла код проекта в 2018 году, и сейчас под GKE Sandbox и Cloud Run он ежедневно держит миллионы песочниц. Anthropic и OpenAI изолируют в нём выполнение кода, Modal и Snowflake строят на нём свои песочницы, Ant Group и Tencent используют его в продакшене.

Как пишет The News Stack, Anthropic запускает в контейнерах gVisor код, который Claude генерирует на её веб-платформе. В отчёте по безопасности от 4 ноября OpenAI назвала песочницы вроде gVisor и Firecracker важными для того, чтобы ограничить ущерб от эксплуатации уязвимостей ядра Linux. Издание связывает анонс с растущей тревогой вокруг автономных агентов: в июле модели, проходившие кибербезопасностную оценку в OpenAI, вырвались из ограниченной среды и проникли в продакшен-инфраструктуру Hugging Face.

OpenRL: ставка на раннее участие

OpenRL - самый молодой слой стека: исследовательским превью он стал только в феврале, и в CNCF Google отдаёт его намеренно рано, пока дизайн не устоялся. Цикл дообучения пишется на обычном Python из четырёх примитивов (sample, forward_backward, optim_step, save_state) через API, совместимый с Tinker, а веса и данные остаются на вашем кластере. Готовые рецепты tinker-cookbook запускаются без изменений, поддерживаются и LoRA-адаптеры, и дообучение всех параметров.

Пул ускорителей OpenRL делит через Kubernetes Dynamic Resource Allocation (DRA). Обучение идёт на PyTorch/AutoModel, генерация роллаутов на vLLM. Из коробки проверены Gemma и Qwen, поддержка TPU пока только в планах. В связке с llm-d, проектом CNCF для распределённого инференса и RL, который недавно дошёл до 1.0, роутер отправляет многоходовые роллауты на те сэмплеры, где уже лежит подходящий префикс KV-кэша. Кроме того, одни и те же GPU по очереди обслуживают генерацию и обучение, чтобы чипы не простаивали между фазами.

Цель проекта Google формулирует как один рецепт для любой модели на любом ускорителе и признаёт, что без производителей чипов (NVIDIA, AMD, Intel и TPU), движков инференса вроде vLLM и SGLang и открытых моделей до неё не дойти. Дрю Брэдсток (Drew Bradstock), вице-президент Google по продуктам Kubernetes и оркестрации, прямо ссылается на прецедент: «Мы считаем, что эти пожертвования ускорят разработку и внедрение агентных нагрузок через эти проекты так же, как это было с Kubernetes».