Kimi AI и kvcache-ai открыли исходный код AgentENV для агентного RL-обучения Kimi K3
Ключевые выводы
- •AgentENV запускает каждую песочницу как Firecracker microVM со своим собственным ядром Linux, файловой системой и сетевым пространством имен.
- •Проект сообщает о времени загрузки или возобновления на основе snapshot менее 50 миллисекунд и времени pause менее 100 миллисекунд.
- •Запущенная песочница может разветвляться в до 16 независимых дочерних песочниц на одном узле.
- •AgentENV предоставляет E2B-совместимый HTTP API, позволяя существующему коду E2B Python и TypeScript SDK работать без изменений.
- •Сервер требует Linux kernel 6.8 или новее и доступ к /dev/kvm, а многоузловые развертывания используют gateway и scheduler, описанные как прототип.

Команда Kimi из Moonshot AI и kvcache-ai открыли исходный код AgentENV (AENV), распределенной платформы, предназначенной для запуска агентных сред в масштабе. AgentENV используется для агентного обучения с подкреплением (RL) Kimi K3, модели Moonshot Mixture-of-Experts с 2,8 трлн параметров. Проект выпущен под лицензией MIT.
Почему инфраструктура сред является узким местом для агентного RL
Агентное RL требует большего, чем выборка текста из модели. Оно требует, чтобы модель действовала внутри реальной компьютерной среды. Для каждого роллаута нужна изолированная Linux-среда с файловой системой, сетевым стеком и запущенными процессами. В таком обучающем цикле среда является частью контура генерации данных, поэтому скорость сброса, изоляция и возможность воспроизводить или ветвить состояния задач напрямую влияют на то, сколько полезных роллаутов можно собрать.
Это требование создает сложный инфраструктурный компромисс. Контейнеры могут запускаться быстро, но они используют общее ядро хоста, что ослабляет изоляцию при выполнении кода, сгенерированного моделью. Полноценные виртуальные машины обеспечивают более сильную изоляцию, но загружаются медленнее и продолжают удерживать память в простое.
AgentENV разработан для устранения этого разрыва. Он запускает Firecracker microVM и нацелен на то, чтобы состояния простоя, перезапуски и ветвление были достаточно недорогими для нагрузок масштаба обучения.
Внутри архитектуры AgentENV на базе Firecracker
Каждая песочница AgentENV работает как Firecracker microVM со своим собственным ядром Linux, файловой системой и сетевым пространством имен. Запросы принимаются через Axum HTTP API, который передает их оркестратору, отвечающему за управление жизненным циклом песочницы.
Хранилище является центральной частью архитектуры. Корневая файловая система обслуживается через блочное устройство ublk в пользовательском пространстве, основанное на слоистых образах overlaybd. Базовые слои только для чтения совместно используются несколькими песочницами, тогда как каждая песочница записывает данные в собственный верхний слой.
Внутри каждой гостевой среды демон envd управляет выполнением команд, файловыми операциями и отчетами о состоянии на порту 49983. Обратный прокси маршрутизирует HTTP- и WebSocket-трафик от клиентов к сервисам, работающим внутри виртуальной машины.
Проект также описывает два механизма повышения плотности. Кэш страниц хоста совместно используется данными хранилища и снимков памяти. Memory ballooning возвращает хосту освобождаемую память гостевой системы, помогая поддерживать overcommit по мере того, как среды со временем расходятся.
Snapshot, pause, resume и fork
Создание snapshot, pause, resume и fork — ключевые функции AgentENV. Система создает снимки изменений памяти и файловой системы инкрементально, вместо того чтобы каждый раз записывать полный образ.
Заявленные показатели производительности указывают, что среды на основе snapshot загружаются или возобновляются менее чем за 50 ms и приостанавливаются менее чем за 100 ms. Сообщается, что инкрементальный захват snapshot завершается менее чем за 100 ms даже при интенсивных изменениях на диске.
Fork — функция, наиболее специфичная для RL-нагрузок. Запущенная песочница может клонировать себя в до 16 независимых дочерних песочниц на том же узле. Исходная среда ненадолго приостанавливается во время захвата, а затем возобновляет работу. Каждый дочерний экземпляр наследует файловую систему, память и конфигурацию ресурсов исходной среды.
Практический результат состоит в том, что затратную подготовку можно выполнить один раз. Команда может установить зависимости, клонировать репозиторий и дойти до заданного состояния задачи, а затем разветвить это точное состояние в параллельные роллауты. Это важно для агентных задач, где повторные попытки должны начинаться из одного и того же подготовленного состояния, но исследовать разные траектории действий. Snapshot могут сохраняться в S3-совместимое объектное хранилище или в общую распределенную файловую систему.
Стоит отметить одно поведение по умолчанию: у каждой песочницы есть TTL, и его истечение вызывает pause, а не удаление. Для удаления необходимо передать autoPause: false в create API.
Загрузка по требованию и репозиторий snapshot
Образы загружаются по требованию через overlaybd. Локальный диск выступает как ограниченный кэш, сохраняя часто используемые данные и вытесняя редко используемые.
Такая архитектура поддерживает работу на уровне парка узлов, поскольку узлам не нужно заранее прогревать каждый образ или хранить полную копию каждого snapshot. Набор адресуемых образов может превышать емкость локального диска, при этом запуск остается быстрым по всему кластеру.
Состояние snapshot организовано в три слоя. Промежуточная рабочая область builder хранит артефакты во время сборки. Зафиксированный репозиторий snapshot служит долговременным источником истины. Локальный runtime-кэш узла хранит производные конфигурации, используемые при запуске.
Поддерживаются два backend репозитория: posix_fs, используемый по умолчанию, и oss. Путь oss использует общий S3-совместимый клиент, поэтому требуется явно указанная region.
AgentENV также включает необязательный peer-to-peer транспорт на базе iroh, который может анонсировать зафиксированные артефакты соседним узлам. По умолчанию он отключен. Документация прямо указывает, что P2P не меняет модель зафиксированных snapshot. Для общего хранилища документация требует как минимум 1 Gbps и настоятельно рекомендует 10 Gbps или быстрее.
Совместимость с E2B как путь внедрения
AgentENV предоставляет E2B-совместимый HTTP API. Указав E2B_API_URL на сервер AgentENV, пользователи могут запускать официальный E2B Python или TypeScript SDK без изменений кода.
Эта совместимость является осознанным выбором распространения. Команды, уже запускающие агентов на E2B, могут самостоятельно разместить runtime без переписывания агентного кода. AgentENV также предоставляет собственный CLI aenv, который документация рекомендует для рабочих процессов, специфичных для AgentENV.
Варианты развертывания
AgentENV требует ядро Linux 6.8+ и доступ к /dev/kvm; скрипт установки дополнительно требует Ubuntu 24.04. CLI aenv поддерживает Linux и macOS на x86_64 и arm64. Сам сервер работает только на Linux, поскольку ему требуется KVM.
Документация описывает пять путей развертывания:
- Скрипт установки, запускающий сервер как службу systemd
- Docker-образ, опубликованный по адресу
ghcr.io/kvcache-ai/aenv-server - Стек Docker Compose, имитирующий многоузловой кластер
- Kubernetes-манифесты с gateway, scheduler и node DaemonSet
- Сборка из исходного кода с использованием инструментария Rust
Многоузловые развертывания добавляют gateway на :8080 и scheduler на :9090. Многоузловая плоскость управления описана как прототип, что делает зрелость кластерного планирования и операционные требования к общему хранилищу важными деталями для команд, оценивающих более крупные развертывания.
AgentENV запускает каждую агентную среду как Firecracker microVM, а не как контейнер, обеспечивая изоляцию на уровне ядра. Проект сообщает о времени загрузки или возобновления на основе snapshot менее 50 ms и времени pause менее 100 ms. Запущенная песочница может разветвляться в до 16 независимых дочерних экземпляров на одном узле, а E2B-совместимый HTTP API позволяет существующему коду E2B Python и TypeScript SDK работать без изменений.