ИИ-агенты большую часть времени простаивают: ждут ответа человека, результата инструмента или модели. Kubernetes для такого профиля не проектировали. Один Pod на сессию держит память ради агента, который ничего не делает, а удаление Pod между шагами даёт холодный старт в несколько секунд и теряет состояние. NVIDIA предложила Agent Substrate — открытый рантайм, который мультиплексирует множество сессий поверх небольшого пула тёплых worker-Pod. Проект передан в CNCF Sandbox.
Что именно не так с Pod на каждого агента
Классический веб-сервис — это небольшое число долгоживущих экземпляров. Агент работает иначе: проснулся, сделал один шаг (выполнил команду в оболочке, отредактировал файл, вызвал тесты или LLM), подождал — от миллисекунд до минут — и сделал следующий. Между шагами должны сохраняться файловая система, процессы и рабочий каталог.
Создание вычислительного Pod — это поход через API-сервер, admission, etcd, планировщик, kubelet, вытягивание образа и настройка сети. Секунды, приемлемые для сервиса, живущего неделями, слишком медленны для песочницы, которой нужно появиться, выполнить bash-команду на 10 мс и освободить место — сотни раз в секунду. У платформенных команд остаётся два плохих варианта: держать тёплый Pod на агента и платить за простой или создавать Pod по требованию и платить холодным стартом на каждом шаге.
Как устроен Agent Substrate
Kubernetes в этой схеме отвечает только за пул готовых Pod. Отдельная плоскость управления отображает большой набор акторов (агентов и их окружений) на меньший пул worker-ов. Когда актор простаивает, он снимается снапшотом из своей песочницы — gVisor или microVM — и worker освобождается. При следующем вызове актор восстанавливается на любом свободном worker вместе с памятью и файловой системой.
Пробуждение актора не требует нового прохода через API-сервер, планировщик и kubelet: он поднимается на уже существующем worker. Сами worker-Pod остаются обычными Pod Kubernetes, поэтому планирование, квоты и политики размещения кластера продолжают работать. Заявленная плотность — в 10 раз выше, чем у стандартных контейнеров, при безопасности на основе zero-trust.
Три сценария, под которые всё строилось
- Кодинг-ассистенты и обслуживание агентов. Агент чередует вызовы LLM с работой в своём окружении: клонирует репозиторий, правит файлы, собирает и тестирует. Пользователь ждёт, что окружение сохранится между шагами и ответит сразу, а платформа на тысячи сессий не может позволить себе отдельную тёплую песочницу каждой.
- RL post-training с агентными окружениями. Обучение с проверяемыми наградами запускает GPU-тренеры и серверы генерации рядом с парком нагруженных CPU окружений: песочниц кода, компиляторов, браузеров, симуляторов. Спрос на песочницы идёт всплесками по мере раздачи действий, а число окружений растёт с сотен в ранних экспериментах до многих сотен тысяч в продакшене. Тренер ждёт самую медленную среду, поэтому холодный старт на этом пути оставляет GPU простаивать.
- GPU-песочницы для исследований. Агенту исследователя нужен GPU не для обслуживания модели, а чтобы скомпилировать код CUDA, прогнать бенчмарк ядра или численный расчёт. Песочница запускается на общем кластере, выполняет работу и удаляется. Для организации это означает много короткоживущих изолированных GPU-песочниц, которые быстро стартуют и справедливо делят ограниченный пул GPU.
Что уже сделано в upstream
Все изменения публичны в репозитории Agent Substrate. Когда все worker-ы заняты, следующий запрос теперь ждёт, а не падает с ошибкой: раньше рантайм сразу возвращал ошибку, хотя другой актор обычно освобождал worker мгновением позже. Парковка запросов в роутере Agent Substrate (#221) держит запрос и повторяет попытку восстановления до освобождения worker, с ограниченным временем ожидания и потолком на число одновременно ждущих запросов. Дополнение (#1229) гарантирует, что запросы к уже работающим акторам не застревают в этой очереди.
Для GPU внутри песочницы делают подключаемость устройств через Kubernetes Dynamic Resource Allocation (DRA). Вендоры устройств регистрируют их через профиль, каждый контейнер песочницы запрашивает только нужные ему устройства (#752), и одна модель работает и для gVisor, и для microVM. Первыми поддерживаемыми устройствами станут GPU NVIDIA.
Лимиты CPU и памяти на контейнер для microVM-песочниц (#859) решают другую проблему: рядом с рабочим процессом агента живут вспомогательные контейнеры логирования, прокси или метрик, и часть из них может быть недоверенной. Контейнер, превысивший лимит памяти, останавливается сам, а остальная песочница продолжает работу.
Отдельная задача — сохранять GPU-песочницу между приостановкой и возобновлением, чтобы при ожидании проверки человеком она отпускала GPU, а потом возвращалась со скомпилированными артефактами и загруженными данными. Здесь есть ограничение совместимости железа: GPU-чекпоинт обычно восстанавливается только на ту же модель GPU, а иногда и только с той же версией драйвера. Предлагаемый дизайн вендорно-нейтрален и опирается на DRA: вендор описывает, как безопасно приостановить устройство и от каких его свойств зависит снапшот, Agent Substrate записывает эти свойства и восстанавливает песочницу на подходящем устройстве либо откатывается к чистому холодному старту.
Связка с NVIDIA Dynamo: где агент действует, где думает
Agent Substrate управляет тем, где агенты действуют, среда исполнения инференса — тем, где они думают. Обе стороны решают похожую задачу: тёплые простаивающие песочницы тратят CPU и память, а пересборка контекста модели при повторных вызовах тратит циклы GPU. Открытый распределённый фреймворк инференса NVIDIA Dynamo берёт на себя координацию: его роутер стоит между слоями и связывает происходящее с агентом с происходящим на GPU.
Обычная маршрутизация считает каждый вызов модели независимым запросом. У агента же запрос — шаг длинного цикла, и соседние запросы часто переиспользуют один системный промпт, определения инструментов, историю диалога и прошлые наблюдения. Dynamo видит, где лежит переиспользуемый KV-кэш, какие worker-ы заняты prefill или decode и как распределена нагрузка. Agent Substrate и обвязка агента добавляют идентичность сессии, приоритет запроса, ожидаемую длину вывода, границы вызовов инструментов и события жизненного цикла.
Вместе это позволяет держать связанные вызовы модели на worker-ах, где уже есть нужный KV-кэш, не создавая перегретых точек на GPU; отдавать приоритет интерактивным ходам перед фоновой работой агентов при перегрузке пула; сохранять системные промпты и историю через паузы между вызовами инструментов; первыми выбрасывать состояние кэша завершённых субагентов, закрытых веток рассуждения и суммаризированных контекстов; готовить вероятный контекст к завершению вызова инструмента.
Обратный поток сигналов важнее: Dynamo ближе к исполнению на GPU и видит готовность кэша, давление очереди, активные prefill и decode, ожидаемое время запроса. Он возвращает Agent Substrate прогнозируемое время до первого токена, прогнозируемое время завершения, прогресс запроса, готовность кэша и насыщение пула GPU. По этим данным рантайм решает, держать ли актор резидентным, приостановить ли его на долгом ожидании инференса или поднять к моменту, когда ответ модели близится к завершению. В масштабе парка та же обратная связь помогает настраивать ёмкость тёплых worker-ов, регулировать ветвление агентов и субагентов и не активировать CPU-песочницы, которые иначе простояли бы за насыщенной очередью GPU.
KAI Scheduler и место в стеке DSX
KAI Scheduler планирует worker-Pod Agent Substrate рядом с GPU-тренерами и серверами инференса: это обычные Pod Kubernetes, так что размещение работает уже сегодня. Согласование автомасштабирования пула worker-ов с очередями и политиками справедливого делегирования KAI могло бы распространить совместное использование ресурсов между арендаторами и на уровень окружений.
Вся связка работает на платформе NVIDIA DSX AI Factory. Dynamo, KAI Scheduler и компоненты фундамента Kubernetes входят в DSX OS, а Agent Substrate — независимый открытый проект CNCF Sandbox, который не является именованным компонентом DSX OS, хотя NVIDIA вносит в него изменения и развивает совместимость с компонентами DSX OS. Выше уровня песочниц стоят фреймворки агентов и RL — NeMo RL, NeMo Gym или собственная обвязка.
Если вы строите платформу агентов или кодинг-ассистент, помните: API Agent Substrate ещё меняются, поддержка GPU переделывается на новой основе DRA, а часть интеграции с Dynamo экспериментальна. Для пробного развёртывания есть руководство по запуску кодинг-ассистента на Dynamo и Agent Substrate: агенты Pi работают как акторы Substrate, подключаются к модели GLM-5.3-Flash через Dynamo, а Harbor организует оценки на SWE-bench Verified. Смежные подходы к обвязке агентов разобраны в материале о том, как превратить сбои ИИ-агента в тесты, а изоляция исполнения — в статье про песочницу Anthropic sandbox-runtime.
Частые вопросы
Чем Agent Substrate отличается от обычного запуска Pod в Kubernetes?
Kubernetes создаёт пул готовых worker-Pod, а отдельная плоскость управления отображает на них множество акторов. Простаивающий актор снимается снапшотом и освобождает worker, а при новом запросе восстанавливается на любом свободном worker без нового прохода через API-сервер, планировщик и kubelet.
Что происходит с состоянием агента между шагами?
Оно сохраняется: снапшот включает память и файловую систему, и при пробуждении актор восстанавливается на свободном worker с тем же состоянием. Именно этого не хватает схеме с удалением Pod между ходами.
Какие песочницы поддерживаются?
gVisor и microVM. Для microVM-песочниц появились лимиты CPU и памяти на контейнер, чтобы вышедший из-под контроля вспомогательный контейнер не убил весь агент.
Как быстро стартует агент после простоя?
Точных цифр донор не приводит, но подчёркивает: пробуждение не требует нового прохода через API-сервер, планировщик и kubelet, актор поднимается на уже существующем worker. Это и есть выигрыш по сравнению с холодным стартом Pod.
Можно ли дать агенту GPU?
Да, это одна из целей: GPU-песочницы для компиляции CUDA, бенчмарков ядер и численных расчётов. Подключаемость устройств строится на Kubernetes Dynamic Resource Allocation, каждый контейнер запрашивает только нужные устройства, первыми поддерживаются GPU NVIDIA.
Переживёт ли GPU-песочница приостановку?
Это проектируемая возможность с оговоркой: GPU-чекпоинт обычно восстанавливается только на ту же модель GPU, иногда — только с той же версией драйвера. Если подходящего устройства нет, рантайм откатывается к чистому холодному старту.
Зачем нужна связка с NVIDIA Dynamo?
Dynamo управляет инференсом на GPU и отдаёт Agent Substrate сигналы: прогноз времени до первого токена и до завершения, готовность кэша, насыщение пула GPU. По ним рантайм решает, держать актор, приостановить его на время долгого ожидания или поднять к приходу ответа модели.
Это готовый к продакшену продукт?
Нет. API проекта ещё меняются, поддержка GPU переделывается на основе DRA, часть интеграции с Dynamo экспериментальна. Проект открыт для участия, а в стеке DSX OS он остаётся внешним компонентом.
Где посмотреть, как развернуть кодинг-ассистента?
В руководстве NVIDIA по развёртыванию кодинг-ассистента на Dynamo и Agent Substrate: агенты Pi как акторы Substrate, модель GLM-5.3-Flash через Dynamo и оценки на SWE-bench Verified через Harbor.
Источник: developer.nvidia.com