DeepSeek Elastic Compute (DSec) 深度解析

来源:DeepSeek V4 Technical Report,Section 5.2.5 “Sandbox Infrastructure for Agentic AI”

一、系统概览

DSec 是 DeepSeek 自研的生产级沙箱平台,专为 Agentic AI 后训练与评估(post-training & evaluation)设计。其沙箱生命周期须与 GPU 训练调度协调,包括抢占和基于 checkpoint 的恢复。

二、三大核心组件

Client
  │
  ▼
Apiserver (Rust)          ← 对外统一 RPC 入口(API gateway)
  │  自研 RPC
  ▼
Edge (Rust)               ← 本地执行代理(per-host agent),管理沙箱实例生命周期
  │
  ├─ Function Call Pool   ← 预热进程池,消除冷启动开销
  ├─ Container (Docker)   ← EROFS 镜像 + overlayfs
  ├─ microVM (Firecracker)← overlaybd 磁盘 + KVM
  └─ fullVM (QEMU)        ← 完整虚拟化,支持任意客户操作系统

Watcher (Rust)            ← 集群监控器(cluster monitor),协调沙箱与训练调度

三、设计动机(四个核心观察)

1. 执行需求多样性:Agentic 工作负载高度异构(highly heterogeneous),横跨轻量函数调用到需要多样 OS 和安全要求的完整软件工程 pipeline(full software-engineering pipelines with diverse OS and security requirements)。
2. 镜像加载是瓶颈:环境镜像数量庞大且体积大(numerous and large),必须能快速加载并支持迭代定制(load quickly and support iterative customization)。
3. 高密度部署:高密度部署要求 CPU 与内存高效利用(high-density deployment demands efficient CPU and memory utilization)。
4. 沙箱生命周期与训练调度的耦合:沙箱生命周期必须与 GPU 训练调度协调(coordinate with GPU training schedules),包括抢占和基于 checkpoint 的恢复(preemption and checkpoint-based resumption)。

四、四大核心设计

4.1 统一 API,四种执行基底

对上层暴露单一 Python SDK(libdsec),底层透明切换:

所有四种基底共享同一 API 接口——命令执行、文件传输和 TTY 访问——切换只需修改参数。

4.2 分层存储:EROFS + overlaybd + 3FS

核心思路:将镜像拆分为只读基础层(多实例共享)和可写差量层(每实例独立),存储后端统一用 3FS。

Container 路径:
  只读基础层  →  EROFS 格式,存储在 3FS,文件元数据本地磁盘就绪,
                数据块按需从 3FS 拉取(overlay lowerdirs)
  可写层      →  本地 copy-on-write(overlayfs)

microVM 路径:
  只读基础层  →  overlaybd 格式,存储在 3FS,跨实例共享
  可写层      →  本地 copy-on-write 差量

效果:

• 避免全量拉取镜像,启动时只拉取实际访问的数据块
• 数十万个沙箱共享同一份只读基础层,大幅降低每实例开销
• 快照支持链式组合(chainable),支持高效版本管理和毫秒级恢复

4.3 密度优化

以下各点来自 §5.2.5 中三个不同的原文小标题,合并整理如下。

Four Execution Substrates Behind One Unified Interface

• 预热进程池(Function Call):Function Call 将无状态调用分发到预热容器池(pre-warmed container pool),彻底消除冷启动开销(eliminating cold-start overhead)。

Fast Image Loading via Layered Storage

• 存储共享:只读基础层写入 3FS 一次,所有节点挂载时文件元数据即在本地磁盘就绪,数据块按需从 3FS 拉取(data blocks are fetched from 3FS upon request);microVM 的只读层同样驻留 3FS 供跨实例共享(cross-instance sharing)。
• 快照链(microVM):overlaybd 快照支持链式组合(chainable),便于高效版本管理,并支持毫秒级恢复(millisecond-scale resumption)。

Density Optimizations Under Massive Concurrency

为支撑单集群数十万并发沙箱,DSec 针对两个资源瓶颈:

• 缓解重复 page-cache 占用:缓解虚拟化环境中的重复页缓存占用(duplicate page-cache footprints),并通过内存回收(memory reclamation)实现安全超分(safe overcommitment)。
• 降低 CPU 开销:缓解容器运行时中的 spinlock 竞争(spinlock contention),降低每沙箱 CPU 开销,显著提升单主机打包密度(per-host packing density)。

4.4 Trajectory Log:抢占安全恢复

原文小标题:Trajectory Logging and Preemption-Safe Resumption

这是 DSec 区别于通用沙箱的最核心差异。

DSec 为每个沙箱维护一条全局有序的 trajectory log,持久记录每次命令调用及其结果(persistently recording every command invocation and its results)。该 trajectory 服务于三个目的:

1. 客户端快进(client fast-forwarding):训练任务被抢占时,沙箱资源仍被保留(sandbox resources are retained nonetheless);恢复后,DSec 重放已完成命令的缓存结果(replays cached results for previously completed commands),加速任务恢复,同时防止非幂等操作被重新执行(preventing errors from re-execution of non-idempotent operations)。
2. 细粒度溯源(fine-grained provenance):每个状态变更的来源及对应结果均可追溯(the origin and corresponding outcomes of each state change are traceable)。
3. 确定性重放(deterministic replay):任意历史会话均可从 trajectory 忠实还原(any historical session can be faithfully reproduced from its trajectory)。

五、与 E2B 的横向对比

注:E2B 信息来自外部公开资料,非 V4 Technical Report 内容。

两者都选择 Firecracker 作为 microVM 基底,验证了 Firecracker 在 AI 基础设施领域的主流地位。E2B 的实现细节可参考 基于 E2B、Consul、Nomad 与 Firecracker 的架构解构。

六、关键洞察

1. “专用 > 通用"的权衡:DSec 的许多设计(Trajectory Log、Watcher、抢占感知)对通用沙箱来说是过度设计,但对 RL 后训练来说是必需品。这说明 AI infra 正在走向垂直化。
2. 存储是核心竞争力:3FS + EROFS 的按需拉取 + 共享基础层,是 DSec 能在单集群运行数十万沙箱的关键。没有自研分布式文件系统,这个设计难以落地。(3FS 具体性能数据见 3FS 独立论文/文档,非 V4 §5.2.5 内容。)
3. Rust 的选择:三个核心组件全用 Rust,反映了对延迟(沙箱冷启动)和内存安全(多租户环境)的极致要求。
4. Trajectory Log 是真正的创新点:将"沙箱"从无状态执行单元升级为有完整历史记录的有状态实体,为 RL 训练的可观测性和可恢复性提供了基础设施保障。
5. DSec 尚未开源:截至 2026-04-28,DeepSeek 已开源 3FS、推理引擎等组件,但 DSec 本身不在开源范围内,所有技术细节仅来自 V4 Technical Report §5.2.5。

七、相关技术资料与引用来源

一手资料

底层技术资料

延伸阅读

八、执行基底实际用途推断

声明:本章内容为基于 V4 Technical Report 正文的合理推断,非 DeepSeek 官方表述。推断依据主要来自:§5.2.5 对 DSec 的描述、§4 后训练任务类型(数学/代码/工具调用/Agent)、以及附录中列举的评测基准(SWE-bench Verified、Terminal Bench 2.0、BrowseComp 等)。

8.1 推断框架:从任务类型倒推基底选择

V4 Technical Report 在 §5.2.5 中有一句关键描述:

“The execution requirements of AI agents span a wide spectrum — from simple function calls with millisecond latency requirements to complex software engineering pipelines that run for hours and require diverse OS environments and strict security isolation.”

这句话本质上就是四种执行基底的设计动机。结合 DeepSeek V4 的后训练任务域,可以建立如下映射:

8.2 Function Call 基底:RL 奖励信号的高速通道

推断核心用途:大规模 RL rollout 中的奖励函数计算。

GRPO(Group Relative Policy Optimization)是 V4 后训练的核心算法。在数学和代码等结构化任务上,奖励信号由确定性验证器(deterministic verifier)给出,例如:

• 数学答案是否等价(精确匹配或符号化比较)
• 代码输出是否通过测试用例
• JSON/工具调用响应格式是否合法

这类校验不需要完整操作系统环境,但对延迟和并发极度敏感。GRPO 每次迭代需对同一 prompt 采样多条轨迹,大规模训练时每个步骤会触发大量并发验证请求。

预热进程池正是为此设计:预热进程池常驻内存,接到请求即执行 Python/Rust 验证函数,消除冷启动开销。相比任何容器或 VM 方案,这是唯一能在不成为吞吐瓶颈的前提下支撑 GRPO 规模的基底。

支撑证据:V4 §5.2.5 明确提到"Function Call dispatches stateless invocations to a pre-warmed container pool, eliminating cold-start overhead”,且单独列为四种基底之首——在系统设计中,排列顺序通常反映使用频率。

8.3 Container 基底:工具调用与轻量代码执行的主力

推断核心用途:涉及真实文件系统但安全要求适中的 Agent 任务,以及需要完整 Python 运行时的代码执行。

具体场景推断:

1. 工具调用(Tool Use)评测:Agent 调用搜索引擎 API、计算器、数据库查询等工具,需要网络能力和持久化工作目录,但不需要内核级隔离。
2. 通用代码沙箱:执行生成代码片段(非系统级操作),需要标准 Python/Node.js 环境,包括第三方库。EROFS 基础镜像共享机制使得同时运行大量这类容器的内存开销远低于传统容器调度。
3. 网页浏览任务的轻量版本:BrowseComp 评测中,部分任务可能通过 headless Chromium + HTTP 请求在容器内完成,不需要完整 GUI 环境。

Container 基底的 namespace 隔离(Docker 兼容)对于已知安全的测试代码已经足够。

关键设计细节:EROFS 格式的只读基础层存储在 3FS 中,按需拉取数据块。这意味着启动时不需要下载完整镜像,首次访问延迟由 3FS 网络 IO 决定,而非全量拉取时间。对于共享同一基础镜像的大量并发容器,物理内存中的基础层页面只存在一份,这是 DSec 实现高密度并发的关键。

8.4 microVM (Firecracker) 基底:软件工程 Agent 的核心执行环境

推断核心用途:需要强安全隔离的 Agent 任务,尤其是软件工程和系统安全类评测。

这是 DSec 中使用最广泛的"中间地带"基底。两个最强证据来自 V4 的评测结果:

SWE-bench Verified(软件工程 Agent):

• 任务模式:给定真实 GitHub issue,Agent 需要 git clone 仓库、理解代码、修改文件、运行测试套件,验证 fix 是否通过
• 执行特征:多步骤、长运行(可能数十分钟)、需要完整 Linux 环境、可能运行用户提供的测试代码
• 为什么不用 Container:Agent 可能执行任意 shell 命令,包括 sudo、内核模块加载、修改系统配置——namespace 隔离不足以防止容器逃逸风险
• 为什么选 microVM:KVM 硬件隔离提供真正的内核边界,快照链机制支持毫秒级恢复

Terminal Bench 2.0(终端命令执行评测):

• 任务模式:Agent 在真实终端环境中完成系统管理、调试、安全分析等任务
• 执行特征:直接操作内核接口、文件系统、网络配置;部分任务可能包含 CTF 性质(逆向、漏洞利用)
• 安全需求极高:执行恶意代码的概率显著高于普通代码任务,必须使用 VM 级隔离

Trajectory Log 与 microVM 的深度耦合:V4 §5.2.5 明确指出 overlaybd 快照支持"millisecond-scale resumption",而 Trajectory Log 的抢占恢复正依赖这一能力。这一组合暗示 microVM 是 DSec 中持续时间最长、与 RL 调度器耦合最深的基底。

8.5 fullVM (QEMU) 基底:GPU 直通与非 Linux 环境的特殊通道

推断核心用途:两类极端场景——需要 GPU 访问的 Agent 任务,以及需要非标准 OS 或内核的评测任务。

这是使用最少但技术要求最高的基底,推断的具体场景:

GPU 直通任务:

• 需要 CUDA/ROCm 驱动访问的 Agent 任务(如在沙箱内运行 GPU 计算)需要 GPU 直通(PCIe passthrough),而这依赖 IOMMU 支持,只有完整虚拟化(QEMU/KVM)才能提供
• Firecracker 设计上刻意不支持 PCIe 直通(这是其轻量化的代价),因此有 GPU 需求的沙箱必须升级到 fullVM

非标准 OS 环境:

• Windows 兼容性测试(代码 Agent 可能需要验证跨平台行为)
• 定制 Linux 内核(安全研究、内核漏洞评测)
• BSD 或其他 Unix 变体

V4 报告的表述:§5.2.5 中 fullVM 被描述为"supports arbitrary guest operating systems",与 DeepSeek 自身作为 AI 公司的核心关切高度一致——当 Agent 任务本身需要运行 ML 工作负载时,没有 GPU 直通就无法完成任务。

fullVM 的低使用频率推断:在 RL 后训练中,绝大多数 rollout 不需要 GPU(奖励计算和代码执行均是 CPU 任务),因此 fullVM 可能只占 DSec 总沙箱实例数的极小比例(估计 <1%),主要用于特定的 benchmark 评测和产品功能验证,而非主干训练循环。

8.6 推断总结:DSec 中的资源分布(估算)

基于以上分析,推断 DSec 在大规模 RL 后训练时的基底分布大致如下(纯推断,无官方数据):

这一量级判断与 DSec 的设计权衡一致:Function Call 的预热容器池专为高频、轻量验证优化;而 fullVM 极高的资源消耗决定了它只能是特殊情况下的补充。

推断可信度评估:Function Call(高)、Container(中)、microVM(高)、fullVM(中)。microVM 推断最有把握,因为 Trajectory Log 的快照恢复设计与 Firecracker API 的直接对应、以及 SWE-bench/Terminal Bench 的安全需求,都高度指向这一结论。fullVM 的 GPU 推断依赖于 DeepSeek 自身作为 AI 公司的特殊性,若 DSec 被用于评测其他非 ML Agent 任务,实际占比可能更低。

关于 DSec 的信息局限性:目前"DeepSeek Elastic Compute (DSec)“这一名称只在 V4 Technical Report 中首次公开,arxiv、独立 GitHub 仓库或其他技术博客中均无独立文档。所有技术细节均来自 §5.2.5(约 2 页篇幅),且 DSec 本身不对外提供服务,属 DeepSeek 内部生产基础设施。

文档生成于 2026-04-28,审校于 2026-05-01,基于 DeepSeek V4 Technical Report 第 5.2.5 节(页 35-36)。