Kimi AI and kvcache – ai open sources ‘AgentENV:’ A distributed system that powers agentic Reinforcement learning (RL) training for Kimi K3

Moonshot AI Kimi’s team kvcache-ai Open-source software is available. AgentENV (AENV)AgentENV is a platform that allows you to run agent environments on a large scale. AgentENV is a platform for agentic reinforcement-learning (RL) learning. Kimi K3, Moonshot’s 2.8-trillion-parameter Mixture-of-Experts model. The code will be shipped as an MIT license.

Environment Infrastructure Holds back Agentic RL

Agentic RL is not just a sample of text. The model must be able to behave inside of a computer. Each rollout requires an isolated Linux system with a live process, filesystem and network stack.

This requirement forces a trade-off. Containers launch quickly, but also share the kernel with their hosts. That compromises code generated by models. Fully virtualized machines are isolated properly, but they boot slowly and retain memory during idle time.

AgentENV targets precisely that gap. The gap is filled by AgentENV. Firecracker The microVMs are then made cheaply to enable them to be used at the training scale.

Firecracker Architecture: Inside AgentENV

Firecracker MicroVMs are used for each Sandbox. Each microVM has its own Linux Kernel, Filesystem, and Network Namespace. The requests are sent to the Axum HTTP interface, and then forwarded on to an orchestrator who manages the life cycle of each sandbox.

Design is interesting because of the storage. Rootfs are served by a Ublk The userspace block is backed up by overlaybd Images are layered. The base layer is shared between sandboxes and the upper layer of each sandbox can be written.

A daemon is found inside every guest. Envd Handles command execution, file operation, and health reports on port 49983. The reverse proxy is used to route HTTP traffic and WebSockets from the clients into services that run inside the VM.

There are two other density mechanisms listed. Host page cache data is used to store and retrieve memory snapshots. Memory ballooning allows the guest to reclaim memory that was previously allocated. This helps maintain overcommitment as environments change over time.

Snapshot, pause, resume, fork

This project was created to provide these four key features. AgentENV takes incremental snapshots of memory and changes to the filesystem, rather than creating a complete image every time.

Here are some of the figures. Snapshot-backed environments boot or resume within under The 50-ms Pause under One hundred ms. In under a minute, incremental snapshot capture is complete. One hundred ms, even under heavy disk modification.

The most unique feature of RL is fork. Cloning is possible from a running sandbox. Sandboxes for children up to 16 sandboxes independent The source will pause briefly during capture, then resume. The source briefly pauses during capture and resumes. The source’s memory and resource configuration is passed on to each child.

Practically, expensive setup only needs to be done once. Team members can install dependencies on a repository and reach the task state. The exact same state can then be split up into multiple parallel releases. Snapshots are stored in S3 compatible object storage, or on a distributed shared file system.

It is important to note one default. The TTL of every sandbox is different, but the trigger for expiry occurs when it reaches its limit. pause, not a delete. Deletion requires passing autoPause: false Create API

Snapshot repository with on-demand load and On-demand Loading

Images are loaded as needed through the overlaybd. Local disk functions as a bound cache, which retains and eliminates data that is hot.

The fleet level story works because of this. It is not necessary for nodes to have a copy or complete image of each snapshot. The image set that can be addressed to a cluster may therefore surpass the local disk’s capacity, while still allowing for a fast startup.

Three layers are used to organize Snapshot State. Artifacts can be stored in a staging workspace for builders during a build. The source of the truth is a committed snapshot repository. Runtime configs can be stored locally in the node cache.

Supported are: posix_fs The default setting is (default). Oss. The Oss A shared S3 client is used to create the path, and so it does not require an explicit The region of the United States and Canada is a good place to start. It is not required.

A peer-to-peer option based on iroh You can promote artifacts that have been committed to other nodes. The peer nodes can be advertised to. Disabled by default. Documentation is clear that P2P doesn’t change snapshots. Documentation for shared storage asks at least one Gbps but recommends 10 Gbps.

E2B compatibility, the key to adoption

AgentENV exposes the underlying technology. E2B-compatible HTTP API. Point E2B_API_URL Your server and official E2B Python SDK or TypeScript SDK can be used without requiring any code modifications.

This was a conscious decision. The runtime can be self-hosted by teams already using E2B agents without having to rewrite their code. The native language is A. Aenv It is recommended that you use the CLI to perform AgentENV specific workflows.

Deployment paths

Linux kernel is a prerequisite. 6.8+ You can also find out more about the following: /dev/kvm Access; the installation script also requires Ubuntu 24.04. This script requires Ubuntu 24.04. Aenv CLI is compatible with Linux, macOS and x86_64/arm64. Because KVM is required, the server can only run on Linux.

Documentation of five paths is available:

• A script to install the server that will run it as a service in systemd
• Docker Image Published at ghcr.io/kvcache-ai/aenv-server
• Docker stacks that mimic a cluster of multiple nodes
• Kubernetes Manifests with Scheduler, Gateway, and Node DaemonSet
• Build-from-source using Rust’s toolchain

Multi-node deployments add a Gateway On, :8080 A scheduler On, :9090.

What you need to know

• The deployment covers Docker, Docker compose, Kubernetes, as well as the install script.
• AgentENV executes every agent environment using a Firecracker miniVM. This isn’t a container so the isolation happens at kernel-level.
• Project reports boot, resume, or pause in less than 50 milliseconds and under 100 milliseconds. These are based on snapshots.
• Running sandboxes are capable of dividing up to 16 children into independent groups on the same node.
• HTTP is E2B compatible, which means that existing E2B Python or TypeScript SDK codes will run unchanged.

Click here to find out more GitHub repository You can also find out more about the following: documentation. This research is the work of researchers on this project.