Google Cloud обновила стек для AI-агентов: Filestore на Colossus, gVisor для Ray и постоянный Cloud Run

Инфраструктура догоняет агентные сценарии

Google Cloud выпустила августовскую сводку обновлений AI-инфраструктуры и оркестрации. Центральная тема — не новая foundation model, а вычислительный слой вокруг агентов: общее файловое хранилище, изоляция выполняемого кода, постоянные serverless-инстансы, распределённый inference и управление дефицитной мощностью. Это набор самостоятельных продуктов и руководств, а не единая новая платформа.

Наиболее связная комбинация складывается из трёх изменений. Filestore получил backend на Colossus и независимое масштабирование IOPS; экспериментальная библиотека добавила gVisor sandboxes в распределённые Ray-кластеры на GKE; Cloud Run instances предложили выделенный singleton-runtime, который не выключается во время простоя. В совокупности они адресуют хранение общего состояния, безопасное исполнение задач и постоянную доступность агента.

Filestore отделяет производительность от объёма

Новый backend Filestore построен непосредственно на Colossus — распределённой системе хранения Google. Главное практическое изменение состоит в том, что IOPS теперь можно выделять независимо от ёмкости, не покупая лишнее пространство только ради производительности. Сервис глубоко интегрирован с GKE и рассчитан в том числе на группы агентов, которые одновременно читают и записывают общий набор данных.

Google называет такой сценарий agentic swarms: много процессов обращаются к общей файловой системе, а нагрузка на операции может расти быстрее самого объёма данных. Независимое provision IOPS делает конфигурацию точнее, однако краткая сводка не приводит benchmark задержки, максимальное число параллельных агентов или сравнение стоимости с объектным хранилищем и локальными дисками. Эти параметры потребуется проверять на конкретном профиле workload.

gVisor изолирует задачи внутри Ray-кластера

В партнёрстве с Anyscale Google представила экспериментальную библиотеку для запуска gVisor sandboxes в распределённых Ray-кластерах на GKE. gVisor — open-source application kernel, который создаёт более сильную границу изоляции, чем обычный контейнер, сохраняя быстрый запуск и небольшой расход памяти. Для AI-систем это особенно важно, когда агент создаёт код или передаёт вычислительную задачу распределённому worker.

Статус функции принципиален: речь идёт об экспериментальной библиотеке, а не о заявленной общей доступности управляемого сервиса. Команде нужно отдельно оценить совместимость workload, наблюдаемость, модель угроз и операционные ограничения. gVisor уменьшает поверхность прямого взаимодействия с ядром хоста, но сама августовская публикация не обещает, что sandbox делает произвольный сгенерированный код безопасным при любой конфигурации.

Cloud Run оставляет персонального агента включённым

Cloud Run instances — выделенные singleton compute runtimes, которые не завершаются, когда агент простаивает. Google позиционирует их как простой и недорогой вариант для персонального AI-агента, которому требуется постоянно сохранять рабочий процесс и быстро отвечать без холодного старта. Заявленная цена непрерывной работы конфигурации с 1 vCPU и 1 GiB памяти в течение 30 дней составляет $5,70.

Эта цифра описывает одну конкретную конфигурацию и не является полной стоимостью приложения: отдельно могут учитываться сеть, хранилище, вызовы моделей, журналы и другие сервисы. Singleton-runtime также не решает автоматически отказоустойчивость или горизонтальное масштабирование. Его ценность — в предсказуемом постоянно работающем процессе, а не в замене полноценной архитектуры для высоконагруженного multi-tenant продукта.

Практические изменения: stateless MCP и session-aware балансировка

Сводка также выделяет изменение спецификации Model Context Protocol от 28 июля 2026 года: core стал полностью stateless, из него убраны handshake initialize/initialized и логический заголовок Mcp-Session-Id. Каждый запрос теперь должен быть самодостаточным. Для инфраструктуры это упрощает распределение независимых запросов, но переносит ответственность за необходимый контекст на сам запрос и прикладной слой.

Для real-time AI Google описывает обратную проблему: аудио, транскрипты, ответы модели и синтезированная речь образуют долгоживущий двунаправленный поток, который нельзя эффективно распределять как независимые HTTP-запросы. Поэтому отдельное руководство предлагает session-aware load balancing, способное сохранять непрерывность сессии и реагировать на перебивание пользователем без разрыва соединения.

Динамическая ёмкость становится частью архитектуры

Ещё один практический блок посвящён elastic inference на GKE с разными GPU и динамическому управлению мощностью. Google перечисляет Capacity Advisor, Compute Advisor, RunAI:model streamer и GCPFuse как компоненты для подбора ресурсов и ускорения загрузки моделей. Отдельный материал сводит стратегию к трём вариантам: планировать мощность под ожидаемые периоды, держать автоматический резерв на непредвиденные сбои и использовать базовые механизмы GKE для распределения ресурсов.

Августовский набор показывает, что эксплуатация агентов постепенно оформляется в отдельную инженерную дисциплину. Модель остаётся важной частью системы, но production-качество всё чаще определяется тем, где хранится общее состояние, как изолирован чужой код, что происходит при простое, как маршрутизируется потоковая сессия и кто управляет дефицитными ускорителями. Google Cloud предлагает детали для каждого слоя, однако их эффективность и итоговая стоимость требуют испытаний на реальной нагрузке, а не вывода из продуктовой сводки.