Ch 20 · DSec
封面/第四部分 · 后训练/Ch 20
第四部分 · 后训练 · 20

DSec — Agentic AI 的执行底座

V4 如何用统一 SDK 管理 Function Call、Container、microVM 与 fullVM 四种执行衬底，怎样借助 3FS、EROFS 和 overlaybd 加速镜像加载，以及 trajectory log 如何支持恢复、溯源与重放。

名词速通 · 一分钟看懂"DSec"

DSec = DeepSeek 自研代码沙箱平台：四种执行衬底（Function / Container / microVM / fullVM）背后是统一 SDK libdsec；分层镜像存储（EROFS + overlaybd）架在 3FS 上；trajectory log 提供 client fast-forward + 抢占恢复 + deterministic replay

一句话：把"沙箱"工程化到与训练框架同一抽象层级。 Agentic post-training 的 trajectory 往往需要在隔离环境里执行命令、修改文件和运行测试。报告称 DSec 可支撑数十万个并发沙箱，并针对镜像加载、装箱密度和抢占恢复做了专门设计；报告没有给出现成 Docker 集群的并发失效点。

Sandbox（沙箱）
隔离的执行环境。模型生成命令，在 sandbox 中执行，再把结果返回给模型继续推理。隔离可以限制错误或恶意代码对宿主机和其他任务的影响。
Function Call 衬底（DSec 第 1 档）
通过预热池承接无状态函数调用，从而消除按请求创建执行环境的冷启动开销。它适合计算器、格式检查器等短小、环境固定的工具调用。
Container 衬底（DSec 第 2 档）
提供 Docker 兼容的容器环境，并用 EROFS 分层镜像按需加载数据。它适合需要文件系统、依赖安装和测试执行的常规代码任务。
microVM 衬底（DSec 第 3 档）
以 Firecracker 提供更强的虚拟机隔离，并使用 overlaybd 管理分层块设备。它适合需要比容器更强隔离的代码执行场景。
fullVM 衬底（DSec 第 4 档）
以 QEMU 提供完整虚拟机环境，适合需要特定操作系统或系统级能力的任务。它的通用性更高，但资源开销也更大。
libdsec（统一 SDK）
统一的 Python 接口，抽象命令执行、文件传输和 TTY 交互。调用方可通过参数选择执行衬底，而不必为四种后端分别编写一套交互逻辑。
EROFS（Enhanced Read-Only File System）
Linux 的只读文件系统。Container 衬底把 EROFS 镜像层挂载为 overlayfs 的 lowerdirs，写操作进入 upper 层，使多个 sandbox 可以复用只读基础层。
overlaybd（Overlay Block Device）
microVM 衬底使用的块设备级分层方案。只读基础层存放在 3FS，写操作进入本地 copy-on-write 层；这种设计适配虚拟机看到块设备而非宿主文件树的接口。
3FS（DeepSeek Fire-Flyer File System）
DeepSeek 的分布式文件系统。本章涉及的用途是保存沙箱镜像的只读数据层，让不同实例按需读取数据块；这里不把它与其他章节中的训练存储用途混为同一项结论。
Memory Reclamation（内存回收）
虚拟化环境中，宿主机和 guest 的缓存会增加内存压力。DSec 通过内存回收缓解重复缓存，使安全的内存超配更可行；报告没有量化其节省比例。
Spinlock 抢占（spinlock contention）
高并发启停容器时，运行时内部的自旋锁可能形成 CPU 瓶颈。DSec 针对相关竞争进行优化，以提高单机装箱密度；报告未披露具体倍数。
Trajectory Log（轨迹日志）
每个 sandbox 维护一份有序日志，记录命令调用及结果。它用于 client fast-forwarding、细粒度溯源和确定性重放；能否逐位复现仍取决于外部依赖、时间和随机源是否也受控。
一句话定位：DSec 用统一接口组织四种执行衬底，并把镜像加载、资源密度与执行日志纳入同一套沙箱平台，为大规模 agentic post-training 提供基础设施支持。

1. 为什么需要专门的沙箱平台

V4 的 post-training 包含需要实际执行工具或代码的 agentic rollout。这类 trajectory 要在隔离环境中运行命令、访问文件并收集结果。报告强调了四类工程需求：

  • 工作负载异构：短小的函数调用与完整软件工程任务需要不同的隔离强度和系统能力；
  • 镜像规模大：领域和工具环境带来大量镜像，完整预取会放大启动延迟与存储开销；
  • 高密度部署：报告称平台需要支撑数十万个并发 sandbox；
  • 生命周期与训练协同：任务被抢占或 client 重连时，需要保留或恢复已执行步骤。
论文边界

报告给出了“数十万个并发沙箱”这一总体规模，但没有披露单节点 pod 上限、sandbox 平均寿命、Docker daemon 启动吞吐或镜像带宽。因此无法用假设数字反推系统瓶颈；论文明确讨论的优化包括按需镜像加载、内存回收与锁竞争缓解。

2. 四种执行衬底，一套 SDK

DSec 通过 Python SDK libdsec 暴露一致接口，背后由四种衬底承接，按"启动延迟 → 隔离强度"排成谱系：

衬底底层典型用途启动特征隔离强度
Function Call预热执行池无状态简单调用避免按请求冷启动轻量
ContainerDocker 兼容 + EROFS常规代码任务镜像数据按需加载容器级
microVMFirecracker + overlaybd需要更强隔离的任务支持快照恢复VM 级
fullVMQEMU需要完整 OS 能力通用性优先完整 VM

调用方可以通过 SDK 参数选择衬底，而命令执行、文件传输和 TTY 交互保持同一套接口。报告说明了这种可切换性，但没有描述 Function、Container 与 microVM 之间的自动 fallback 机制。

Demo · 四种衬底在 4 个维度上的权衡（点切换 task 类型看推荐衬底）
交互
当前 task：简单工具调用 需要的优先维度： 推荐衬底：Function Function Container microVM fullVM

读图法：雷达图四轴分别是启动速度（上）/ 隔离强度（右）/ 兼容性（下）/ 密度（左）。每种衬底在四轴上有自己的能力轮廓。
点不同 task 按钮看：简单工具调用优先快 → Function；不可信代码优先隔离 → microVM；需要特定 OS 优先兼容性 → fullVM。四衬底不是冗余而是覆盖了一个 2D 决策空间的四个角。

3. 分层镜像存储：复用只读基础层

为避免每个 sandbox 重复下载和保存完整镜像，DSec 使用"只读基础层 + 写时复制层"的分层设计，让不同实例复用基础数据。

  • Container 衬底：base image 与 filesystem commit 作为只读 EROFS 层挂载到 overlayfs lowerdirs；3FS 提供后端存储；元数据放本地、数据块按需 fetch；
  • microVM 衬底：使用 overlaybd 磁盘格式 —— 只读基础层在 3FS 上跨实例共享，写操作落到本地 copy-on-write 层；
  • 快照可以形成 base → middle → leaf 的链式层级；报告称这种设计支持毫秒级恢复，但没有给出创建新 sandbox 的统一启动时间。
📖 为什么 EROFS 与 overlaybd 是两件事

它们工作在不同抽象层：

  1. EROFS（文件系统层）：Container 衬底是 Linux namespace + cgroup，guest 进程直接访问 host kernel 的 file system。所以分层用文件粒度 overlay：base 层提供只读文件树，upper 层接收写。简单高效，但需要 host kernel 信任 guest；
  2. overlaybd（块设备层）：microVM 衬底是真正的 VM，guest 看到的是虚拟硬盘。host 不能直接给 file system，必须给"块设备"。所以分层在block 粒度：base 层是只读 disk image，upper 层接收 block 级 CoW。开销稍高，但隔离更彻底（guest 不能 escape 到 host fs）。

合起来看，Container 通过 EROFS、microVM 通过 overlaybd 使用 3FS 上的只读数据，并把各自的写入留在本地 CoW 层。报告没有说明沙箱镜像与 Ch19 的 teacher 状态是否部署在同一个物理 3FS 集群。

4. 高密度优化：内存与锁竞争

为提高并发密度，DSec 重点处理了两个容易被忽略的瓶颈：

  1. 缓存与内存压力：虚拟化环境中的重复缓存会降低可用内存。DSec 使用 memory reclamation，让宿主机回收 guest 不再使用的页，从而支持更稳妥的内存超配；
  2. Spinlock 竞争：大量 sandbox 并发运行时，运行时内部的锁竞争会消耗 CPU。DSec 优化相关关键路径，以提高单机装箱密度。
如何理解“装箱密度”

它不是一个固定的“每节点 sandbox 数”，而是 CPU、内存、缓存、镜像访问与任务负载共同作用的结果。报告只说明 memory reclamation 和 spinlock 优化显著提高了密度，没有给出可跨硬件复用的节点配置或倍数。

5. Trajectory Log：sandbox 级 WAL

Ch19 §3 的 token 粒度 WAL 解决rollout 推理的抢占恢复。DSec 在沙箱执行层有完全对应的设计：每个 sandbox 维护全局有序的 trajectory log，每条命令调用 + 结果都持久化。承担三件事：

  1. Client Fast-Forwarding（抢占恢复）：训练任务被 preempt 时 sandbox 资源保留；恢复时 client（agent）重新连接到 sandbox，直接 replay 已完成命令的缓存结果，避开 non-idempotent 重放错误（不会重新跑 rm -rf temp/ 一遍）；
  2. Fine-Grained Provenance（细粒度溯源）：每个状态变更都可追溯到具体 trajectory 与 step。debug 训练数据时关键 —— "为什么这个 specialist 学到了奇怪行为"，可以一路回溯到具体的 sandbox session；
  3. Deterministic Replay（确定性重放）：按日志重放已记录的交互，便于复查和调试；若执行依赖外部网络、时间或未受控随机源，仍需额外固定这些条件。
DSec 的工程价值

OPD 负责整合不同 teacher 的分布，而 DSec 负责执行带工具调用和代码运行的 trajectory。统一衬底接口、分层镜像和 trajectory log 共同降低了大规模 agentic post-training 的调度与恢复成本。论文没有提供与其他沙箱平台的横向对比，因此这里不把它表述为独有能力。

6. 一句话总结

DSec 把 agentic 工作流的执行环境纳入统一平台：四种衬底覆盖不同的性能、隔离与兼容性需求，单一 SDK 统一交互方式，3FS + EROFS + overlaybd 支持镜像分层和按需加载，trajectory log 则服务于恢复、溯源与重放。从 Ch16 的 specialist 训练到 Ch20 的沙箱执行，这五章分别解释了 V4 后训练的模型、算法与系统组成。