AgentENV: When LLMs Learn to Get the Job Done, We’re Open-Sourcing the Infrastructure Behind Them | KVCache.AI
学习一下kimi和thu的工作：AgentEnv，这里面有很多有意思的技术细节，有时间需要仔细盘一下每一个功能是如何实现的。
团队认为，训练的agentic infra必须要具有以下特点：
- strong isolation
每个agent运行时不会影响主机或者其他训练任务 - scalability
支持更多样更大量的数据/环境 - high efficiency
更低成本，更高并发
传统的沙箱侧重于安全隔离，缺乏支持agent任务所需的多样化的环境配置。不同的任务需要不同的操作系统，需要不同的语言、编译器、工具链、外部服务等等。这些依赖必须通过镜像以及环境模板预先准备，而随着任务数量多增长，所需的环境会迅速演变为庞大而高度多样化的镜像集合。agentic rl需要维护数千个有状态的环境，而这些环境常常会在等待模型返回下一步动作，如果每一个环境都永久占用自己的cpu、内存、存储资源，那么环境成本就会成为扩展的瓶颈。而传统的虚拟机无法平衡难以平衡隔离性、保真度和资源效率，因此需要新一代的agent执行环境。
AgentEnv使用Firecracker构建高度隔离的微型虚拟机执行环境，关于Firecracker，可以看我另一篇文章：
AENV可以在一台拥有 128 个 CPU 核心和 512 GB 内存的服务器单节点可靠运行，基于模板的启动或恢复延迟可以低至49ms，快照创建延迟可以低至133ms。这使得“创建环境、执行任务、保存环境状态以及恢复或复制环境”的循环可以更快地完成。
AgentEnv支持镜像从远程对象存储按需加载，本次磁盘仅用于热数据的有限容量缓存。所以集群中可用的镜像和环境模板总数可用超过单个节点的磁盘容量，而无需在主机预热每个镜像。
由于AgentEnv可以在极短时间内启动，暂停，恢复环境，这就使得模型在等待推理时，可以释放cpu和可回收内存，同时在新操作到达时快速从现有状态恢复。这就使得训练系统能以更低成本维护更多活跃的，有状态的执行环境，而不需要持续地为这些环境预留全部物理资源。
增量记录内存和文件，copy on write这些应该是firecracker具备的技术，可以对比看一下。在存储方面，他们使用更底层的overlaybd，分层存储根文件系统、基础镜像、工具磁盘、依赖项和稳定快照状态这些只读层，通过内容寻址缓存进行去重。磁盘io使用ublk、io_uring和直接I/O来减少虚拟机后端和主机之间的冗余缓存。
内存方面，从同一模板恢复的执行环境共享一个只读内存快照。干净的页面会通过宿主机的页面缓存进行重用，而脏页，匿名内存等会被分配到对应执行环境的私有内存。同时agentenv还通过damon reclaim和firecracker balloon持续回收客户机内部的文件缓存，释放内存资源。
这部分大致的技术我了解，但是具体的技术细节，agentenv在已有的技术上做了哪些改进，还需要细看。
kvcache.ai给出一个insight:
对于大量有状态、间歇性活动的代理执行环境，成本不应取决于“创建了多少个环境”，而应尽可能接近“实际使用了多少资源”。