10 个关键问题 Q&A
- Q：DSec 是什么，解决什么核心业务场景？
A：DeepSeek 弹性计算沙箱平台，专门用于大模型智能体大规模 RL 训练、评估、环境构建，提供隔离执行环境供模型调用工具、运行代码。 - Q：DSec 提供哪四类沙箱后端，选型依据？
A：FnCall（轻量无状态）、Container（通用工程）、microVM（强隔离 Linux）、Full‑VM（完整操作系统 GUI）；按隔离强度、启动开销、系统兼容性选型。 - Q：智能体沙箱负载有哪些独特挑战？
A：流量突发、沙箱带状态长存活、CPU 空闲适合超配、负载异构、镜像数量巨大复用率低、智能体不可信、GPU 抢占需要保留执行状态。 - Q：可组合 EROFS 分层解决了什么问题？
A：解决传统单体镜像的组合爆炸；基础镜像、工作空间、工具包独立版本，更新只需要重建对应分层，不用全部重打包。 - Q：DSec 如何实现高密度内存利用？
A：virtio‑pmem 消除页缓存重复；DAMON 识别冷内存页，配合 virtio‑balloon 空闲页上报主动回收闲置虚拟机内存，降低内存占用 21.2%。 - Q：CPU 高并发下如何保护延迟敏感任务？
A：任务分为延迟敏感 LS、尽力而为 BE；BE 设置 SCHED_IDLE，配合 core‑scheduling 隔离超线程 SMT 干扰，把延迟膨胀从 45.2% 降至 17.3%。 - Q：按需镜像加载对比传统 docker 拉取优势？
A：不从远端完整下载镜像，只加载运行实际访问的数据；磁盘写入量下降 57%，任务总耗时缩短，避免大量 IO 冲击集群。 - Q：DSec 如何处理 GPU 训练抢占，不丢失 Agent 推演状态？
A：推演执行与 GPU 训练 Pod 解耦；沙箱支持 pause 暂停保存状态，释放内存；GPU 恢复后透明 resume 继续执行，不需要回放命令日志。 - Q：什么是奖励劫持，DSec 如何缓解？
A：智能体绕开任务逻辑通过漏洞窃取答案；AppArmor 管控文件套接字，eBPF 做网络白名单，限制非法访问，不能完全根除只能缓解。 - Q：DSec 单规模单元生产核心指标？
A：160 节点；日处理 300 万沙箱，峰值并发 38 万，每秒创建 > 5000 沙箱；单节点最高 3200 容器 /800 microVM。
作者：黄家良†‡，汤弘轩†，陈景昌†，刘宇轩†，陈奕骁†，程源†，陶毅†，周靖丽†，陈宇鹏†，陈浩宇†，王嘉睿†，林圣凯†，张楚琪†，Bryan Lee Teng†，郭连†，付哲，高文俊，王艺松，赵良，王泽浩，谢紫薇，郭永强，丛培鑫，高子义，余水平，许瀚伟，吴佐凡，任之舟，周宇扬，张博伟，黄志环，朱启浩，王磊，林天乐，余瀚，胡杰文，杨德建，杨硕，陆尚浩，陈少源，邱俊杰，沙章立，钟胤旻，吴永彤，王诗宇，刘伟，徐秉正，陈隆昊，杜秋实，黄玉振，马世荣，王耀辉，陈明舒，熊桐瑞，严玉成，罗浩文，梁浩奋，张小康，曾伟浩，徐润鑫，王佩怡，朱锦华，张若愚，杨文凯，唐启，余继平，叶恬，潘睿哲，丁宏辉，刘晓东，罗凌骁，邵志宏，吴宇涵，陆季柏，刘文，张浩岭，胡景成，叶耀阳，林超凡，张兆辰，童建安，吴恒旭，李智浩，王一诚，王路遥，白玉卓，付凌月，徐瑞帆，王振泽，李宗霖，魏明奇，沈海洋，张成远，金超，张子立，杨润浩，徐新博，周健，朱睿东，郭宇哲，潘泽伦，聂少恒，李尔航，林舒涵，刘铮，陈安硕，吕子龙，曹思诺，于睿，王楚浩，郭俊毅，宋俊晓，陈凯峰，叶梦浩，李骏贤，吴迪，马海洋，王艺伦，杨浩然，蔡亦哉，刘世春，王艺平，孙俊博，徐世成，毕潇‡∗†，何颖，张轶超，张铭星，张丽月，黄盼盼，梁文峰
机构：DeepSeek‑AI；‡清华大学 邮箱：research@deepseek.com
通讯作者。†DSec 项目开发人员。‡清华大学。 黄家良为博士研究生，导师张铭星；在 DeepSeek‑AI 实习期间完成本工作，张丽月担任实习导师。 arXiv 预印本：2609.22978v1 [cs.DC]，2026‑09‑19
摘要
大语言模型（LLM）大规模智能体训练与评估，依赖隔离、带状态的执行环境。模型需要在这类环境中查阅代码仓库、调用工具、执行命令，与面向特定任务的服务交互。这类工作负载会突发性地创建大量沙箱，功能与隔离要求异构多样，长交互周期内需要保留运行状态，同时镜像数据集庞大、复用率低。因此，需要一套弹性执行平台，而非单一沙箱运行时。
本文介绍 DeepSeek 弹性计算系统 DSec，一套已投入生产的沙箱平台。它通过一套统一软件开发工具包（SDK）对外提供函数调用（FnCall）、容器、微型虚拟机（microVM）、完整虚拟机（full‑VM）四类沙箱后端。DSec 负责集群层面的调度放置与全生命周期管理；基于独立版本的分层机制组装运行环境；融合内存共享、内存回收与 CPU 调度实现高密度执行；从飞萤文件系统（3FS，Fire‑Flyer File System）按需加载镜像数据。DSec 与强化学习（RL）框架协同设计，将带状态的样本推演执行与可被抢占的 GPU 训练解耦；协调沙箱生命周期与训练流程，在回收空闲资源的同时保留推演状态；同时缓解智能体的异常行为，例如奖励劫持。
一套生产规模的 DSec 部署单元包含约 160 个节点，每日可服务约 300 万个沙箱；生产环境支持超过 38 万个并发沙箱，每秒可创建 5000 个以上沙箱实例。
评估与落地实践表明：这套机制降低了环境初始化与镜像分发开销，提升内存使用效率，在高密度资源超配下依然维持对延迟敏感业务的性能。
1 引言
前沿大语言模型的技术进步，让智能体工作流走向实用与普及（Guo 等人，2025；Jimenez 等人，2024；OpenAI 等人，2024）。智能体模型不再只输出一段文本答案，而是和执行环境交互：浏览代码库、调用工具、执行命令、排查错误、修改文件；在计算机使用类任务中还可以通过图形界面操作浏览器、桌面应用（Xie 等人，2024；Zhou 等人，2024）。在以上各类负载中，模型会根据环境反馈不断迭代，直至任务完成。这套执行模式催生了大量智能体工具与编排框架，例如 DeepSeek Harness（DSH）（Shi 等人，2026）、OpenCode（Anomaly，2025）以及多智能体训练框架。训练可靠智能体需要大规模强化学习，模型不再仅依靠静态输入输出样本学习，而是和真实隔离执行环境不断交互。
智能体训练流水线包含环境与数据构建、RL 样本推演、奖励计算、策略更新、周期性评估几个环节。其中 RL 推演与评估对沙箱平台压力最大：并发规模巨大，且与训练循环强耦合。RL 训练是一套反馈闭环，分为三步。第一，推演阶段：当前模型与沙箱环境交互，读取文件、发起工具调用、执行命令、观测输出，为每个任务生成轨迹。第二，奖励计算：框架基于退出码、标准输出、测试通过率、任务专属校验器等执行信号，对轨迹打分。第三，策略更新：RL 算法基于收集的轨迹与奖励更新模型参数。周期性评估流程类似，但轨迹仅用来衡量模型能力，不更新参数。现代系统还会将生成与策略优化流水线化，采用异步推演，源源不断补充完成的样本，维持高并发，缓解长尾拖慢问题（DeepSeek‑AI，2026）。智能体负载下，这套设计会同时运行大量带状态沙箱会话；在策略更新、调度抢占时，推演任务还会被中断、恢复，进一步提高平台对并发、生命周期管理、状态一致性的要求。
每一个推演或评估任务，平台都需要实例化一个隔离的任务专属环境，包含代码仓库、依赖库、服务、评估脚本、代码运行框架。环境需要尽可能贴近真实机器，能够直接运行未修改的软件栈、包管理器、编译工具、浏览器、模拟器、任务专用服务。一套高性能、高吞吐的沙箱运行时，是获得准确、可信的 RL 与评估结果的基础。
智能体沙箱负载具备以下关键特性，决定平台整体设计思路：
- 沙箱创建流量呈突发特征
单个任务可请求多达 32000 个沙箱实例，平台必须能够同时处理大量沙箱创建请求。突发流量要求系统水平可扩展，调度、镜像分发等共享服务不能出现单点瓶颈。 - 高密度运行要求
智能体交互过程中，沙箱经常等待大模型生成下一步动作，CPU 大多处于空闲，天然适合资源超配。生产环境中，单节点最多可部署 800 个微型虚拟机或 3200 个容器；前提是平台能够安全地做资源超配，并且处理单节点大量实例带来的生命周期压力。 - 沙箱带状态、生命周期长
模型会修改文件、安装依赖、启动服务，后续工具调用依赖这些累积状态。沙箱会经历多轮大模型交互，即便 CPU 空闲，内存占用、客户机页缓存、主机页缓存、可写状态会长时间驻留内存。高密度超配场景下，常驻内存开销直接决定集群容量，内存共享与回收成为核心需求。 - 负载高度异构
平台需要支持 OJ 在线判题类脚本执行、完整代码仓库软件工程任务、安全任务、计算机使用负载、安卓等移动端开发环境，以及其他完整系统环境。不同任务的 CPU、内存需求、依赖体积、系统功能、隔离强度差异巨大。单一沙箱抽象无法高效覆盖全部场景：轻量无状态短任务适合函数调用；需要完整商用操作系统的负载适合虚拟机。 - 环境版本繁多，复用率低
同一类负载内部也存在大量不同环境。训练评估数据集包含大量任务，每个任务可能拥有专属代码仓库、依赖版本、服务、工具包、评估脚本、虚拟机快照。平台需要管理数量庞大的镜像与环境制品，其中很多镜像复用次数很少。突发创建场景下，如果从镜像仓库拉取各类任务镜像，会给分发链路带来巨大压力，拉高启动延迟，额外 IO 还会干扰已经运行的沙箱。消融实验表明：主动预拉取镜像会将总耗时拉长 1.7 倍；按需加载可累计磁盘写入量降低 57%。 - 智能体执行不可信
智能体可能破坏文件系统、耗尽资源、干扰系统组件，破坏推演任务或者影响其他共存负载。平台需要细粒度访问控制、异常行为分析，隔离并定位智能体引发的故障。 - 支持可中断执行
GPU 训练任务可能被抢占，但推演任务还在运行。平台必须保存执行状态，支持中断后高效恢复。
以上特性定义了智能体沙箱平台的能力边界。DSec 实现弹性扩缩、高密度资源管理、内存共享回收、适配多类负载的多种隔离机制、可扩展镜像分发；并且与训练框架深度协同，支持抢占安全的任务恢复、任务专属网络策略，缓解智能体异常行为。
本文余下部分：第 2 章从使用者视角介绍 DSec，包含支持负载、沙箱后端、运行规模；第 3 章介绍端到端平台架构；第 4 章刻画生产真实负载与系统挑战；第 5 章讲解环境组装、镜像分发、高密度资源管理的核心机制；第 6 章讲解与 RL 框架协同：环境构建、状态保存、抢占下资源回收，以及智能体异常行为分析与访问控制缓解手段；第 7 章补充更多实现细节；第 8 章评估整套设计效果；第 9 章综述相关工作。
2 DSec 总览
本章从使用者视角介绍 DSec。平台使用者是训练框架、评估框架、数据构建流水线，它们替研究人员调用 SDK，全文统一称之为 “用户”。内容涵盖 SDK 入口、平台提供的沙箱后端与适配负载、沙箱会话生命周期、生产部署规模。
2.1 SDK 入口
用户通过libdsec，一套 Python 客户端库访问沙箱服务。libdsec提供统一 SDK 入口用来创建、操作沙箱，同时需要使用者根据任务选择合适的沙箱后端。典型请求参数包含沙箱类型、镜像或环境标识、CPU 内存限制、生命周期配置、网络规则、初始用户上下文。沙箱创建完成后，用户可以执行 shell 命令或者工具调用，收集命令输出与返回码。
代码清单 1 展示一个最简容器会话：客户端连接服务端点，请求指定资源、网络策略的沙箱，运行命令，最后释放沙箱。
client = DSecClient()
await client.open()
args = DSecContainerRunArgs(
container_image="registry.../sphinx‑9658:official",
memory_limit_mb=4096,
cpu_cores_limit=4,
ttl_running_stop=300, # 空闲超时
network_rules={"npm": False, "pypi": True},
init_user="root"
)
sandbox = await client.run_container(args, timeout=120)
result = await sandbox.run_shell("echo hello world")
await sandbox.stop()
示例中网络策略允许访问 PyPI 包源，禁止访问 NPM。细粒度网络控制详见第 6 章。该接口不会对所有后端做完全统一的高层抽象。函数调用、容器、微型虚拟机、完整虚拟机的启动开销、隔离边界、文件系统语义、操作系统能力各不相同。libdsec提供统一访问通路与近似操作模型，但调用方仍然需要选择和负载匹配的后端。
2.2 沙箱后端
沙箱运行时存在固有权衡：隔离性越强、系统能力越完整，启动延迟和资源开销就越高。不存在一套沙箱抽象适配全部智能体任务，DSec 支持多种后端覆盖该权衡空间。
- FnCall（函数调用）
面向短生命周期无状态任务，例如 OJ 判题、代码编译、无服务器程序、GPU 算子、工具脚本。FnCall 运行在预先创建好可复用 CPU/GPU 容器，消除每次调用的实例化开销。GPU 场景提供两种模式：共享模式，多个容器共用同一块 GPU，最大化轻量任务利用率；独占模式，任务生命周期内独占 GPU 实例，面向对性能敏感场景，如算子评测。 - 容器
软件工程与通用工具调用负载的主力后端。启动快、部署密度高，运行绝大多数仓库任务的 Linux 软件栈。缺点是与宿主机共享内核，不适合高安全要求场景。 - Firecracker 微型虚拟机 microVM
隔离边界更强，保持 Linux 兼容性。适合安全敏感任务、强租户隔离、需要虚拟机边界且运行 Linux 的负载；相比容器内存开销更大，启动更慢。 - 完整虚拟机 Full VM
运行整套商用操作系统，例如基于 QEMU 的安卓虚拟机；面向需要图形界面渲染的任务。资源开销最高，但针对依赖特定操作系统 API、移动端运行时行为、完整系统执行的任务必不可少。
生产环境中，容器和微型虚拟机占据绝大多数实例数量与资源消耗；FnCall 处理海量轻量调用，常驻环境集合较小；完整虚拟机用于各类小众但重要的任务。
2.3 用户可见生命周期
尽管后端内部实现不同，用户看到统一高层生命周期。
-
调用方选定后端，指定环境制品、资源上限、生命周期策略、网络策略，发起沙箱创建。环境制品随后端与任务变化：容器与 microVM 为基础镜像 + 任务专属工作空间、工具分层，平台组装成运行环境；Full VM 为预制虚拟机镜像或快照；FnCall 为任务描述，包含任务类型、依赖文件、待运行代码脚本。这些制品作为后续环境组装、镜像分发的输入。 -
平台准备环境，沙箱就绪，可供交互。 -
用户下发命令或工具调用，观测输出，执行任务校验测试。沙箱全程带状态：文件修改、安装依赖、启动的服务在多次调用之间保留，后续命令可以看到之前操作的结果。沙箱经历多轮交互，但两轮交互之间 CPU 经常空闲，驻留状态会持续占用资源，这是第 4 章介绍高密度场景的一大难点。 -
用户显式停止沙箱，或者生命周期 TTL 超时回收，避免空闲、遗弃会话无限占用资源。
2.4 部署规模
DSec 部署多个规模单元，全部共用一套 3FS 分布式文件系统，存放基础镜像和工作空间。单个规模单元包含接近 160 台 CPU 节点，合计 30000 核 CPU，约 250TB 内存，管理 PB 级别分层镜像数据。典型单日，单个单元提供约 300 万沙箱实例，峰值并发约 38 万，实例创建速率超过每秒 5000 个。
以上数字可以帮助理解后文：DSec 不是单一沙箱运行时，也不是容器的简单封装，是面向生产的完整执行平台，融合用户侧沙箱抽象、后端运行时、可扩展镜像存储、高密度资源管理，并且深度对接训练框架。
3 平台架构
第 2 章介绍用户视角的 DSec：SDK、沙箱后端、会话生命周期。本章介绍底层平台，描述一条请求从 SDK 下发到沙箱运行完整链路，涉及组件。架构分为集群级服务，以及沙箱运行时。集群服务处理请求接入、身份鉴权、沙箱放置、集群健康负载视图；沙箱运行时负责单节点准入、沙箱创建执行、资源回收，镜像数据依托 3FS 获取。
3.1 总览
沙箱创建请求首先经过身份访问管理 IAM 鉴权。鉴权通过后交给放置引擎，放置引擎基于监控组件 Watcher 采集的集群健康与负载信息，选出目标节点。API 服务器将请求转发至目标节点的 Edge 组件。Edge 检查本节点剩余容量，如果资源足够，使用指定后端创建沙箱；否则拒绝请求。沙箱运行需要镜像数据存储在 3FS，启动和运行时按需拉取。
容器、microVM、FullVM 沙箱内部会启动每个沙箱专属代理 Aether，以及若干 Chronus 实例，负责命令执行、文件系统访问等运行时操作。沙箱运行后，所有操作经由 API‑Server、Edge、Aether、Chronus 流转。
FnCall 不使用 Aether 与 Chronus，链路独立：任务直接在预创建容器执行，任务结束尽力清理状态。
3.2 集群级服务
集群级服务管控平台访问，跨计算节点协调沙箱请求，包含 IAM、API‑Server、放置引擎、Watcher。
IAM 身份访问管理：对所有 DSec 管理请求做身份认证与鉴权，例如创建、删除沙箱，修改用户资源与并发配额。主体指发起管理请求的用户或服务身份。IAM 通过项目实现资源管理与访问控制的作用域。项目内部访问策略规定主体可以对哪些资源执行什么管理操作；资源配额限制资源消耗。
DSec 支持多层项目嵌套，区别于云平台常见扁平、两级层级结构。授权主体（智能体、运行框架）可以创建子项目，继承父项目部分配额，授予子项目内管理权限。权限委派受父项目约束：主体不能授予自身没有的权限，子项目策略、配额不能超过父项目。人类用户和智能体使用同一套管理 API 与鉴权模型。
API‑Server：沙箱集群接入代理。训练评估代码从可信 GPU 服务器调用 libdsec；沙箱内部运行模型生成的不可信代码，可能访问外部网络，两者网络隔离，API‑Server 是唯一允许通信路径。全部沙箱请求（创建、命令执行、流式 IO）都经过接入层。API‑Server 本身不维护每个沙箱状态，定期从 Watcher 刷新 Edge 节点列表；沙箱 ID 编码自身归属 Edge 节点。任意 API‑Server 实例可以解析请求，直接转发到目标 Edge，接入层支持水平扩展。
放置引擎 Placement Engine：为每一个新建沙箱选择宿主机节点，分为过滤和打分两步。过滤阶段只保留健康、满足请求后端与硬件能力的节点，例如 GPU 沙箱只筛选具备对应 GPU 的机器。打分阶段随机采样若干个合格节点，选择负载最低节点。
Watcher：放置引擎的决策依赖 Watcher 提供集群视图。Watcher 定期探测每个 Edge、宿主机健康状态，采集调度状态：各后端类型正在运行沙箱数量，按 Edge、用户、任务做统计。放置引擎定期拉取 Watcher 状态，做新创建请求决策。
放置引擎和 Watcher 不需要持久化状态。放置引擎不保存沙箱运行状态；Watcher 重启后，通过轮询 Edge 即可重建集群视图。因此实例可以随意增删替换，无需复杂故障恢复流程。
3.3 沙箱运行时
沙箱运行时创建、管理各个沙箱实例，管控资源。包含 Edge、Aether、Chronus，镜像存储依赖 3FS。
Edge：每台机器部署一个 Edge，接收 API‑Server 下发的容器、microVM、QEMU 完整 VM、FnCall 创建请求。接收请求前，Edge 会做本地容量校验，资源不足直接拒绝，这是对放置引擎（依赖定期刷新集群全局状态）的本地二次准入。创建沙箱时，Edge 准备存储，配置 eBPF 网络策略，启动运行时。
FnCall 与容器运行在 QEMU/libvirt 虚拟机内部，不直接跑在裸金属宿主机上。虚拟机提供隔离内核、网络协议栈，作为不可信容器和裸金属硬件之间额外安全边界。为支持计算机 GUI、浏览器、游戏、3D 渲染这类图形密集负载，使用宿主机 hypervisor 半虚拟化 GPU 接口（virtio‑gpu）。完整虚拟机内，既支持原生兼容宿主机操作系统的图形 API；也可以借助 DXVK 这类兼容层，把渲染栈转换为主机原生 API。
Edge 除了维护沙箱生命周期，还协调磁盘、内存快照；沙箱停止或 TTL 到期时释放节点本地资源。
Aether：容器与 VM 沙箱内部运行 Aether，跨平台代理，和 Edge 建立通信通道。Linux 容器使用 Unix 域套接字，虚拟机后端使用 vsock。Edge 通过这条通道监控沙箱健康；通道断开标记沙箱故障。每一次操作，Aether 根据终端会话 ID 找到或创建对应的 Chronus 实例，转发操作。会话结束，Aether 终止对应的 Chronus 进程树。
Chronus：沙箱内部封装 shell 会话抽象，一个实例代表一条独立 shell 会话。对外提供跨平台接口，实现命令执行、文件系统操作、HTTP 请求、流式 IO。同一个沙箱内可以并发运行多个 Chronus 实例。Aether+Chronus 让 libdsec 可以为容器和 VM 沙箱提供统一操作接口。
基础镜像与工作空间存储：沙箱运行时以 3FS 作为基础镜像与工作空间镜像共享后端存储。容器镜像线下将 OCI 格式转换为 EROFS：元数据本地存放，实际数据保留在 3FS。microVM 磁盘镜像基于 OverlayBD 格式，同样使用这份存储。镜像格式支持按需加载、基于共享基础镜像做增量快照。Edge 启动沙箱无需完整拉取全部镜像。第 4 章说明为什么需要可扩展镜像分发，5.3 节介绍按需加载机制。
3.4 弹性云扩容：选择性卸载负载
DSec 本地部署承载稳态流量，同时使用云上虚拟机承接沙箱瞬时流量峰值。本地资源利用率超过 80% 时，放置引擎会将部分符合条件新建沙箱请求调度到云虚拟机。
DSec 不在云端使用托管容器服务 + 对象存储，而是直接复用本地容器运行时与 EROFS 镜像加载链路。EROFS 镜像存放于云上分布式文件系统，云虚拟机直接挂载。
生产文件访问追踪显示：一套去重压缩的 30TB EROFS 镜像集合，覆盖 70% 容器任务访问文件。这套共享镜像集合离线同步到云端文件系统。镜像依赖全部落在该集合内的容器任务标记为可上云；其余任务继续跑在本地。单个规模单元中，200 台云虚拟机可以消化约 30% 峰值溢出流量，无需过度配置本地集群。
4 生产沙箱负载与平台挑战
本章刻画 DSec 真实生产负载，引出对应的平台挑战。统计对象为容器与 microVM，它们占据绝大多数沙箱实例与资源消耗。负载特征和传统执行服务区别很大：请求大规模突发；沙箱长期维持状态；即便大量沙箱存活，CPU 实际占用很低；环境数据集巨大，节点本地缓存很难覆盖。下面把每一类负载特征对应系统难题，解决方案放在后续章节。
4.1 生命周期与突发流量
推演、评估任务批量创建沙箱，流量不是平稳的。图 2 可见，普通容器任务就会创建数千沙箱，长尾可达数万。最大生产任务单次请求可达 32000 个沙箱。请求短时间集中到达，训练评估批处理必须等待全部环境就绪才能开始。放置、沙箱创建、环境初始化都必须应对尖峰突发；任意环节出现拖慢实例，就会推迟模型交互。
沙箱创建完成后，运行分为三个阶段（图 3）：初始化阶段准备任务依赖、工具、初始状态；工具调用阶段，模型交替生成输出、执行沙箱操作，CPU 短时间爆发，中间穿插大量等待模型下一步动作的空闲；测试阶段校验结果，资源占用短暂冲高。各阶段时长不固定，但资源特征十分关键：初始化开销会随并发规模放大；后续阶段即便 CPU 间歇空闲，沙箱状态依然持续保留。
4.2 环境多样性与初始化压力
初始化阶段开销高昂，因为沙箱由多套独立演进软件组件组装而成。沙箱内容拆分为三部分：①基础镜像，操作系统级依赖，例如 Ubuntu、Python3.10、Java8；②工作空间，存放任务代码仓库与任务专属依赖；③工具包，频繁更新工具组件，如 DeepSeek Harness。
某一周生产统计：容器后端共 11266 个基础镜像、102171 个工作空间；microVM 使用 2 套共享基础镜像，53590 个任务专属工作空间；平台一共维护 103 个工具包，67.8% 沙箱除基础镜像外，至少还需要一个工作空间或工具包。
如果将三者打包合并为单一 OCI 镜像，会带来组合爆炸维护负担。假设 M 个基础镜像，N 个工作空间，K 个工具包：更新 m 个基础镜像，需要重建 O (m・N) 个组合镜像；更新 k 个工具包，代价 O (k・N)。举例图 4 (a)，更新工具包 T1，所有包含 T1 的完整镜像全部需要重建，即便基础镜像和工作空间没有改动。设计目标是把维护代价降低到 O (m) 与 O (k)，也就是基础镜像、工作空间、工具包各自独立版本化分发。
其他简单方案同样存在缺陷：把工作空间、工具包以压缩归档形式，沙箱启动现场解压，突发场景下大量重复解压带来巨大 CPU 与 IO 开销，甚至沙箱启动超时。把工作空间、工具包作为宿主机只读目录 bind‑mount 挂载进沙箱，会直接覆盖目标路径，而业务需要追加合并语义，把文件合并到现有目录树，不能隐藏下层原有文件；严格只读挂载也和部分工具冲突，例如 Python 生成__pycache__缓存，需要向安装目录写入文件。
4.3 CPU 利用率稀疏与高密度运行
图 5 统计显示：约 90% 容器与 microVM 沙箱平均 CPU 使用量不超过申请配额的 5%，天然适合资源超配。某生产节点单日观测峰值：1048 个容器，524 个 microVM。实际生产稳定运行可做到单节点 3200 容器或 800 个 microVM（这是实践运行值，不是硬性上限）。高密度下，内存低效、CPU 互相干扰成为主要矛盾。
内存方面 microVM 有两处浪费：第一，虚拟块设备读取镜像数据，宿主机、每个客户机都会缓存一遍，同一数据跨宿主机‑客户机边界重复缓存；第二，客户机内部空闲内存页不会主动还给宿主机，客户机申请内存往往大于实际需求，没有内部压力回收闲置页面。图 7 说明沙箱生命周期很长：容器中位数生命周期 17.4 分钟，microVM15.5 分钟；两者 p99 生命周期均超过 3 小时。长生命周期放大驻留内存开销，限制 microVM 内存超配上限。
CPU 层面：部分任务有严格单步延迟约束，例如博弈智能体，每一步移动有固定时间上限。仅仅给尽力而为任务调低调度优先级还不够。当延迟敏感任务、尽力而为任务运行在同一个物理核的超线程兄弟硬件线程上，依然会竞争计算资源。平台需要利用超配提升利用率，同时不能破坏延迟敏感任务性能。
4.4 镜像数据集庞大，单镜像实例数少
沙箱镜像总量构成第三大挑战。表 2 一周内活跃制品总容量超过 130TB，远超单台工作节点本地存储上限。图 8 镜像实例分发统计：容器镜像中位数实例数 3，p90 等于 28；microVM 镜像中位数实例数 1，p90 等于 3。实例数低，意味着本地缓存命中率很差，单节点缓存无法覆盖庞大工作集。突发沙箱创建时，拉取镜像给镜像分发系统巨大压力。
集群经过超配接近满负载，拉取、完整实例化镜像消耗 CPU、IO 资源，抢占正在运行沙箱资源。预预热镜像只是把开销前移，不会消除开销：数据仍然需要传输落地，镜像占用本地存储。同时沙箱运行只会访问镜像内一小部分数据。不同编程语言镜像采样统计表 3：运行实际访问数据仅占镜像总大小 4.2%‑13.3%。完整拉取镜像非常浪费，由此引出按需镜像加载设计。
5 核心系统机制
第 4 章提出三大耦合基础设施挑战：①突发创建、组件独立迭代，初始化开销不能随沙箱数量重复放大；②CPU 实际负载稀疏，高密度运行收益巨大，但长生命周期、内存驻留、混合延迟需求，不受约束超配不安全；③镜像集合庞大，单镜像复用实例少，运行访问占比低，主动完整镜像分发成本高，干扰业务。
本章介绍对应的三大核心机制：可组合环境分层、高密度资源管理、可扩展镜像按需分发。
5.1 可组合环境分层
核心思路：操作系统基础环境、每个工作空间、每个工具包，逻辑上都是独立分层，各自生命周期互不绑定，不需要融合成单一单体镜像。如图 4 (b)，更新工具包，只需要更新工具分层，直接和已有的基础镜像、工作空间分层重新组合即可。
OverlayFS 正好提供需要的合并语义：多层只读下层目录堆叠，内核对外呈现合并后的统一目录树；冲突文件按优先级解析；栈顶层设置可写上层目录，所有运行时写入透明落到上层，不会修改下层只读分层。
DSec 修改容器运行时 dockerd，沙箱创建时动态组装 overlayfs 栈的 lowerdir。栈底放置基础镜像；其上插入请求的工作空间只读分层；再堆叠各个工具包分层。工作空间、工具包文件合并进基础镜像目录树，不会直接替换路径；运行写入全部落到可写上层。分层之间生命周期解耦。更新 m 个基础镜像，仅重建 m 个基础分层；更新 k 个工具包，仅重建 k 个工具包分层。把单体镜像 O (m・N)、O (k・N) 维护开销下降到 O (m)、O (k)。
发布的环境分层均为不可变，存储使用 EROFS 文件系统，专为只读数据设计。对比 ext4、XFS 这类可写文件系统，EROFS 消除写相关簿记，磁盘布局更紧凑；支持数据压缩同时保留文件随机访问能力。不同于 tar.gz 归档，EROFS 可以只读取、解压需要访问的数据块，不必完整传输、解压整个镜像。
microVM 场景，基础镜像、工具包打包为独立版本 EROFS 镜像，作为只读块设备暴露给客户机。客户机内部根文件系统使用 overlayfs：EROFS 挂载为下层只读层；ext4 格式可写磁盘目录作为上层。microVM 获得和容器完全一致的可组合分层模型。
5.2 高密度资源管理
内存效率优化
virtio‑pmem + DAX 消除页缓存重复拷贝：文件访问直接映射宿主机内存页，不再拷贝进虚拟机 RAM，多台共存 microVM 可以共享宿主机一份页缓存副本。但 virtio‑pmem 并不适配全部磁盘：冷访问会触发同步缺页处理，建立映射，准备后端数据；virtio‑blk 缓冲 IO 路径可以利用客户机预读、批量块 IO。virtio‑pmem 设备还需要客户机为全部地址范围分配 struct‑page 元数据，开销大：128GB pmem 设备，元数据就消耗 2GB 客户机内存。
不使用 virtio‑pmem 的磁盘，冷文件数据会堆积在客户机页缓存，需要独立回收。DSec 结合 DAMON（数据访问监控）与 virtio‑balloon 空闲页上报。virtio‑balloon 驱动支持空闲页上报：客户机定期扫描伙伴分配器，主动把空闲页上报给宿主机；宿主机调用 madvise (MADV_DONTNEED) 释放对应宿主机内存。默认按 2MB 大页粒度上报，粒度可以内核参数调整。
DAMON 是 Linux 内核基于采样的内存访问监控组件，定期采样页访问位，识别超过配置时间阈值没有访问的冷文件页，通过内核回收逻辑淘汰冷页。回收后零散文件页释放回伙伴分配器，合并为高阶内存块，满足 balloon 空闲页上报的大页要求。
评估显示：DAMON 配合 balloon 空闲页上报，内存总消耗下降 21.2%，CPU 开销很小。生产环境：EROFS 只读基础镜像、工具分层开启 virtio‑pmem+DAX；大容量可写磁盘，使用 DAMON+balloon 空闲页回收。
QoS 感知 CPU 调度
为消除超线程 SMT 层面 CPU 互相干扰，DSec 将沙箱分为延迟敏感 LS、尽力而为 BE 两类。BE 沙箱设置 SCHED_IDLE 调度策略，只要 LS 任务就绪，BE 就让出 CPU。但仅靠调度优先级，无法阻止 BE 负载跑在同一个物理核的兄弟超线程上争抢资源。DSec 对 LS 沙箱启用 Linux 内核核心调度 core‑scheduling，阻止无关 BE 任务运行在 LS 任务同物理核的 SMT 兄弟线程。双层策略保障 LS 任务单步延迟预算，BE 负载充分利用空闲周期；实验将 SMT 带来的延迟膨胀从 45.2% 降低至 17.3%。
5.3 可扩展镜像分发与按需加载
关键观察：沙箱只会访问镜像一小部分数据，如表 3。按需拉取不仅解决启动时机问题，也降低总 IO，实际 IO 量正比于真正访问的数据占比，而不是镜像整体大小。
传统按需镜像系统一般搭配容器镜像仓库、P2P 分发避免仓库瓶颈。DSec 直接把镜像托管在 3FS，复用训练已经在使用的存储基础设施，不新增独立镜像分发层。3FS IO 特征高度不对称：大块顺序读写吞吐很高；小块随机 IO 性能很差。该特性决定设计三原则：
- 写操作本地执行
：沙箱写入行为不规则，大量小日志写。可写分层全部放在节点本地磁盘，完全避开 3FS 小写惩罚。 - 读按需、批量
：只读镜像数据只有访问时才从 3FS 拉取，IO 尽量合并为大块，发挥 3FS 大 IO 吞吐优势。 - 元数据优先本地存放
：文件系统元数据访问多为小读；镜像格式允许的前提下，元数据预取到本地节点。
容器场景 EROFS 实现这套原则。EROFS 严格只读，运行写入全部落到 overlayfs 上层本地存储；EROFS 按需缓冲 IO 读取文件内容，内核预读合并相邻块生成大请求。EROFS 多设备模式，文件系统元数据与文件数据分开。元数据下载到工作节点本地磁盘，文件数据留在 3FS。元数据遍历、路径查找不会产生远端 IO。读写路径分离：写本地友好；读远端按需批量，适配 3FS 非对称性能。
虽然规避完整拉镜像，但挂载大量 EROFS 分层会增加容器创建开销。线下将连续、总大小不超过阈值（3GB）的分层合并为一组 EROFS 镜像，保留 overlayFS whiteout 语义表示文件删除。减少最终挂载数量，避免重复文件拷贝，同时保留共享分层之间页缓存复用。使用 EROFS 文件挂载模式，消除 loop‑device 块映射层开销。
容器 EROFS+overlayFS 栈不能完全满足 microVM 全部文件系统兼容性。例如 Docker overlay2 驱动不能使用 overlayFS 后端数据目录。virtio‑fs 把宿主机文件系统导出到虚拟机内部，但 Firecracker 不支持 virtio‑fs 接口。microVM 存储设计因此有所区别。只读基础镜像、工具分层依旧使用 EROFS；可写 ext4 磁盘使用 OverlayBD，Docker‑in‑microVM 场景有独立磁盘作为 docker 数据根目录。
OverlayBD 磁盘通过 ublk 用户态块设备框架暴露。块级别路径支持按需读、本地写；支持增量磁盘快照，不需要重新打包修改文件为 EROFS。和多设备 EROFS 不一样，ext4 元数据嵌入块镜像内部，读取元数据会触发远端 IO。DSec ublk 实现将 OverlayBD 数据按 256KB 块拉取，存放到二级本地文件缓存。就算块从页缓存淘汰，本地缓存还保留副本，不需要重新访问 3FS。两条存储路径均做到写操作本地化，最小化发给 3FS 小 IO 请求。
6 和 RL 框架协同设计
DSec 为 DeepSeek V3.2 一直到 V4.1 版本 RL 训练、评估提供全部沙箱负载。除了沙箱高效执行，还需要在执行生命周期、安全策略层面与 RL 框架协同。本章：6.1 节智能体环境可由智能体交互式构建；6.2 节智能体循环与 RL 框架解耦；6.3 节暂停恢复机制，配合 GPU 抢占做资源回收；6.4 节分析破坏任务完整性、扰乱运行环境的各类智能体异常行为；6.5 节访问控制缓解手段。
6.1 由智能体构建、服务于智能体的智能体环境
手动构建 RL 训练需要海量环境并不现实。DSec 允许智能体在训练评估同一套基础设施交互式构建环境。DSec 提供pack_diff能力：沙箱运行任意时刻，生成增量磁盘快照做检查点；快照可以恢复为全新沙箱。这套检查点‑恢复接口直接把交互式会话转为可复用环境，构建、校验、消费环境使用同一基础设施，无需独立镜像流水线。
平台维护一套内部规则，约束打包生成环境，避免运行时对共享基础设施造成性能冲击；规则作为指令给到构建环境的智能体。研究人员搭建内部平台，对智能体生成环境做质量校验，导出标准化格式，供给 RL、评估任务使用。
构建阶段与运行阶段都跑在沙箱基础设施，必须防止信息泄露。构建方、运行时智能体使用不同账号；打包前清除可写分层残留构建数据，防止参考答案泄露到最终镜像。
6.2 将智能体循环与 RL 框架解耦
GPU 集群训练任务经常被抢占提升硬件利用率。长周期智能体推演任务，如果推演逻辑和 GPU 训练任务强耦合，抢占代价极高：即便沙箱状态完好，智能体循环进程会直接被杀。想要恢复推演，既要保留智能体执行状态，又要保留沙箱状态。
早期流水线版本，智能体循环运行在可抢占 GPU 训练 Pod 内部，和模型推理服务、RL 框架在一起。GPU 任务被抢占，智能体循环丢失，但沙箱还在运行。恢复时依赖命令日志，训练框架恢复推演状态再和沙箱执行状态对齐；重放时复用记录结果，避免非幂等命令重复执行带来副作用。
从 DeepSeek‑V4.1 开始，推演执行迁移到 DSec，拆分为两部分：①智能体沙箱，运行脚手架（DeepSeek Harness）与配套工具；②worker 容器，负责管控沙箱，提供与脚手架无关的推演控制层。两者全部运行在可抢占 GPU 资源池之外。推演生命周期与训练器生命周期彻底解耦。worker 容器 + 智能体沙箱共同保存完整推演状态，作为唯一可信状态源。GPU 训练任务抢占恢复后直接重连继续运行，不再需要依靠命令日志回放恢复推演状态。RL 框架移除复杂恢复逻辑，组件间协调简化，故障处理更加简单。
6.3 沙箱暂停：面向抢占式 RL 训练
GPU 任务抢占不可避免，沙箱状态必须保留在 DSec 直到推演任务结束。但是会出现大量空闲沙箱持续占用内存，训练处于暂停。RL 框架向被抢占任务关联全部沙箱主动下发 pause 请求，DSec 释放内存，同时完整保留执行状态。后续访问暂停沙箱，会透明先恢复再执行操作。
容器暂停恢复：Edge 调用 docker pause 冻结容器进程树；打开容器内存 swap 上限，调用 memory.reclaim 主动内存回收，匿名页、文件页内存回收，进程执行状态保留。恢复阶段：对进程内存映射执行 MADV_WILLNEED 异步预取，执行 docker unpause 恢复运行。
microVM 暂停恢复：保存 microVM 内存与执行状态快照，终止 Firecracker 运行进程释放内存。恢复时新建进程，加载快照恢复虚拟机运行。
6.4 智能体异常行为与系统故障
生产实践观察两大类智能体执行风险。第一类：任务看似通过，但智能体通过非预期渠道拿到答案，污染训练评估结果可信度。第二类：智能体操作破坏执行环境，干扰本任务或者集群其他任务。
通过非预期渠道获取答案（奖励劫持）智能体在沙箱内部搜索平台托管文件、通信通道寻找残留答案：尝试直接向 Chronus 套接字发送伪造 RPC 请求；读取 Chronus 日志窃取泄露答案；Chronus 会调用 bash，于是尝试覆盖 /bin/bash 绕过检查，向后续 shell 会话注入命令。平台增加文件、套接字访问控制后，智能体尝试 XFS_IOC_SWAPEXT ioctl 系统调用，交换两个文件数据扩展，试图绕过权限读取受保护文件，直接破坏 XFS 元数据，造成文件系统停机。说明智能体寻找答案行为甚至会破坏底层基础设施。
沙箱外部，智能体扫描端口服务寻找镜像；利用 Go 模块代理拉取 GitHub 代码，安装新版本包，寻找已有实现。只校验最终输出，无法可靠判断智能体是否按照预期方式解决任务。
篡改执行环境部分故障来源于普通命令、误操作，并非刻意破坏。例如智能体从根目录递归执行 grep，遍历 /proc，读取 /proc/kpagecgroup，触发内核 bug 直接崩溃内核。漏洞利用任务中，本该发送到目标 VM 的攻击命令，错误在智能体容器内部执行，造成容器内核崩溃。还有无边界命令输出消耗存储：调用 yes 命令，Chronus 捕获 stdout 日志，短时间产生几十 GB 输出，耗尽存储。
6.5 访问控制缓解手段
没有单一机制可以完全阻止全部智能体异常行为、系统故障。因此需要增强可观测性，持续发现新问题；随着模型迭代持续加固 DSec。下面介绍访问控制，限制智能体通过非正常途径获取答案，缓解奖励劫持问题。注意：这些控制手段不能防御触发内核 bug 这类破坏性行为。
- 文件与套接字访问控制（AppArmor）
AppArmor 配置文件控制文件读写权限、套接字访问，包括 Chronus 日志、Unix 域套接字。即便沙箱内部进程以 root 身份运行，策略依然生效。限制读取日志窃取答案，伪造内部通信请求。 - 细粒度网络控制（eBPF）
训练框架指定任务专属网络权限，按域名、镜像服务划分，如代码示例允许 PyPI，禁止 NPM。DSec 为每个沙箱注入 eBPF 程序，基于 IP、端口、协议过滤流量，只放行白名单。任务不同阶段网络连通要求变化，策略支持动态更新。
7 实现补充细节
放置引擎策略
亚秒级出现数千沙箱极端尖峰、大规模资源超配，需要增量负载均匀分散，使用弹性资源，而不是静态资源预留。
- k‑选择幂算法 power‑of‑k‑choices
调度器随机采样 k 个节点，从中选择负载最低节点，避免集中涌向少数节点，降低 RL 环境突发创建、工具调用阶段节点之间互相干扰。 -
每个放置引擎实例维护本地视图，叠加近期已经下发、但 Watcher 快照尚未反映的放置记录，跟踪正在处理负载，实例之间不需要协同。 -
Edge 掌握最终准入权。本地资源压力大直接拒绝，调度重新选择节点。快速路径轻量化，避免陈旧全局估算覆盖节点本地硬限制。用户隔离进一步限制资源尖峰、内核故障爆炸半径，代价是节点部署密度下降。
高可用服务
辅助、集群级服务必须高可用；服务故障会造成智能体任务失败，奖励信号、评估结果被破坏。网关、包镜像等辅助服务、控制面接入使用 BGP 负载均衡：多实例对外宣告同一个虚拟 IP；上游交换机 ECMP 路由分发流量。实例 BGP 会话断开，交换机几秒内撤销路由，流量切走。IAM、放置引擎、Watcher 等集群级服务多实例部署。定期集群重置演练，验证基础设施即代码可以从零重建全部集群服务，故障恢复不依赖人工累积状态。
dockerd 动态下层分层插入
DSec 修改开源 Docker 守护进程（Moby 项目），容器创建时动态插入 EROFS 下层分层。传入已经挂载好 EROFS 分层路径，在挂载前插入 overlayfs 栈，作为最顶层下层分层，可以覆盖下层文件。改动很小，仅 30 行 Go 代码。
Rust 实现 OverlayBD 与 ublk 库
Rust 实现 OverlayBD，并且贡献上游；Rust 用户态 ublk 库实现 Firecracker microVM 按需块存储路径。存储后端支持 3FS、对象存储 OSS、容器镜像仓库；本地文件系统作为二级缓存。页面缓存淘汰之后，数据依旧可以本地缓存读取，不用再次访问远端。该存储组件已开源：https://github.com/kvcache‑ai/AgentENV/tree/main/storage/overlaybd
内存 CPU QoS 配置
全部机制复用 Linux 现有内核能力。virtio‑pmem+DAX 通过 Firecracker 设备配置、客户机挂载参数开启。DAMON 回收依靠客户机内核参数、sysfs 调优。CPU QoS：BE 任务 SCHED_IDLE，通过 prctl (PR_SCHED_CORE) 按 QoS 类别分组任务启用 core scheduling。不需要内核补丁，全部是配置、编排层集成。
FnCall GPU，算子基准测试
FnCall 支持 GPU 运行无状态算子基准测试。GPU 资源有限，三项机制提升并发同时保障性能隔离。①NVIDIA MIG 把 GPU 切分为隔离实例；基准测试任务独占分配到的 MIG 实例并发运行。②CPU FnCall 负责编译，产物交给 GPU FnCall，减少 GPU 占用时间。③预热 Python 进程池，提前初始化运行时、导入库；请求到来直接开始算子执行。三者降低 GPU 路径非必要开销，提升 GPU 利用率与基准测试吞吐。对性能不敏感任务，提供 GPU 共享模式，允许多负载共用 GPU，进一步提高并发。
3FS 部署
每台 3FS 存储服务器配备 20 块 15TB SSD 盘，2 张 400Gbps RDMA 网卡。CPU 节点使用 FUSE 客户端访问 3FS；EROFS 元数据本地存放，文件数据按需从 3FS 拉取。数十台存储服务器，支撑数百千 CPU 核规模集群镜像按需加载。
8 评估
评估针对第 5 章四项核心机制：按需镜像加载、可组合环境分层、内存优化、QoS 感知 CPU 调度。实验聚焦基础设施性能；第 6 章与训练框架集成部分不在评估范围。
8.1 实验环境
实验运行独立 10 节点 CPU 测试集群，与生产隔离。
- 硬件
microVM 直接裸金属运行，规避嵌套虚拟化。microVM 节点：AMD EPYC 9655，2 插槽 ×96 核 ×2 超线程；1.5TB DRAM；3.4TB 本地存储。容器实验运行在 QEMU 虚拟机内部：AMD EPYC 9655，1 插槽 ×96 核 ×2 超线程，共 192 硬件线程，512GB 内存，5.8TB 本地存储。 - 内核版本
宿主机 Linux7.0；microVM 客户机 Linux6.1。 - 负载
全部来自真实 RL 训练评估场景，任务套件包含内部软件工程基准、SWE‑bench、Terminal‑bench、安全漏洞利用任务等。
8.2 按需镜像加载 EROFS
对比 EROFS 按需拉取、远端仓库主动 Docker 拉取（cold 冷）、镜像全部本地缓存 Docker（cached）。测试集群 10 节点，突发 8192 容器，RL 评估负载镜像多 GB，镜像多样性高。观测指标：运行容器数量随时间、瞬时磁盘写 IOPS、累计磁盘写入总量。CPU、内存差异不大不作展示。
结果见图 10：EROFS 按需拉取几乎和全本地基线一样快速到达最大并发，镜像直接挂载，访问时才从 3FS 取数据。传统冷 Docker 拉取，必须完整下载解压镜像容器才能启动，前 20 分钟创建严重拖慢。EROFS 全部任务完成约 35 分钟，和本地缓存接近；主动拉取需要超过 60 分钟，慢 1.71 倍。
主动拉取峰值磁盘写 IOPS 接近 EROFS 两倍；单节点累计写入 1600GB。EROFS 按需路径只有短暂尖峰，累计写入约 700GB，比主动拉取减少 57%，接近本地缓存基线 600GB。验证按需加载设计：不用完整下载解压镜像，性能接近镜像本地缓存。
8.3 可组合镜像分层 EROFS 对比 Tar 归档
同样评估工作空间 + 工具包供给，对比两种方案：传统 tar.gz 压缩包，每个沙箱启动解压；EROFS，直接挂载只读分层。替换 LLM 生成为确定工具调用序列，唯一变量就是工作空间、工具包供给方式。
tar.gz 顺序流格式，每个沙箱必须解压全部文件写入本地可写层，工具调用阶段才能开始。端到端任务耗时 79 分钟。EROFS 直接挂载共享分层，不需要解压，沙箱更早进入工具调用阶段，总耗时 45 分钟，提速 1.76 倍。
图 11 磁盘 IO 统计：tar 方案总磁盘写流量约 EROFS 的 5.5 倍；峰值磁盘写吞吐是 EROFS 的 3.4 倍。EROFS 观察到更高 CPU 利用率，是因为大量沙箱更早进入并发执行工具调用，并不是初始化开销更大；EROFS 省去每个沙箱重复解压 CPU 开销。实验验证可组合分层设计收益。
8.4 超配场景内存评估
真实 RL 智能体负载，对比四类 Firecracker 配置：未优化基线；仅 virtio‑pmem+DAX；仅 DAMON+balloon 空闲页上报 FPR；两者同时开启。
virtio‑pmem+DAX 消除多客户机重复页缓存，相比基线峰值主机内存下降 40.2%。单独 DAMON+FPR 峰值内存变化不大，但积分总内存消耗下降 21.2%。两者同时开启获得最低内存占用。virtio‑pmem 会短暂拉高 CPU 利用率，冷访问路径存在同步缺页开销；virtio‑blk 缓冲 IO 具备客户机预读批量 IO 优势。CPU 资源紧张部署，可以只启用 FPR，保留 virtio‑blk。实验验证内存优化机制互补：virtio‑pmem 消除页缓存重复；DAMON+balloon 回收闲置客户机内存。
8.5 超配下 CPU QoS 评估
延迟敏感 LS 任务，搭配共置 BE 背景负载，背景负载占节点容量 10%‑50%。对比三组：无保护基线；仅 SCHED_IDLE；SCHED_IDLE 加上 core‑scheduling。测试负载为对延迟敏感的象棋智能体。
无 QoS 保护，50% BE 负载下，每步延迟对比无共置基线膨胀 45.2%。仅 SCHED_IDLE 最多改善 3.4%，因为 LS 线程仍然会和 SMT 兄弟线程 BE 负载竞争。SCHED_IDLE+core‑scheduling：低负载延迟接近无共置基线；50% 背景负载下，延迟膨胀控制到 17.3%。负载越高，收益越明显。剩余性能损失来源于多核高负载下 CPU 睿频降频、内存带宽、共享最后一级缓存 LLC 竞争，core‑scheduling 无法处理；该残留干扰已经可接受，没有额外启用内存带宽隔离。
9 相关工作
无服务器计算SAND、REAP、TrEnv、RunD 等无服务器系统优化短生命周期无状态函数冷启动与资源共享。这类负载镜像集合少，实例复用率高，很多系统假设镜像已经本地就绪。而智能体训练沙箱带状态、生命周期长；镜像数据集巨大，单镜像实例数低，本地缓存无法覆盖。
LLM 代码执行平台面向推理场景：OpenAI 代码解释器、E2B、Kimi‑K2.5 智能体集群。面向训练的 MiMo‑V2‑Flash、ComputerRL 提到执行环境，但重点放在模型、训练流程。DSec 专注底层沙箱基础设施，把环境组装、资源超配、镜像服务、抢占安全恢复整合在一套平台。
容器镜像与文件系统格式DADI、CoFS 实现容器镜像按需加载；FaaSNet 用 P2P 加速镜像分发。EROFS 面向只读压缩文件系统。DSec 复用以上技术面向 RL 训练评估；镜像后端使用 3FS，而不是新增镜像仓库、P2P 分发层。
轻量隔离技术microVM、Kata‑containers、LibOS、Wasm 运行时、Unikernel、嵌套内核、嵌套虚拟化，不同方案隔离性、兼容性、性能各有权衡。DSec 不提出新隔离原语，在统一平台背后集成多种沙箱后端，允许调用方按任务选择最合适隔离方案。
RL 训练基础设施Slime、veRL、OpenRLHF、Seer 等 RL 框架聚焦 GPU 调度、通信、样本吞吐扩展；把执行环境当成黑盒，假设沙箱已经就绪、配置完成。DSec 属于互补基础设施层：负责沙箱供给、生命周期，和训练框架协同处理执行状态、安全策略。
10 总结
本文介绍 DSec，面向大规模 LLM 智能体训练、评估、环境构建的生产级沙箱平台。DSec 通过统一接口对外暴露多种沙箱后端，使用者根据功能、兼容性、隔离要求选择执行环境。基于 EROFS 可组合分层，避免重复重建、解压环境；互补内存共享回收机制支持高密度部署；QoS 感知 CPU 调度保障超配下延迟敏感任务；依托 3FS 按需镜像加载，降低镜像分发开销。DSec 和 RL 训练框架深度协同，支持抢占安全的任务恢复、任务专属网络策略，为智能体工作负载提供可扩展执行底座。
参考文献部分略