DeepSeek 这一次没发新模型,而是把训练新一代模型的那张地基掀开给你看了。9 月 19 日,一篇 31 页、131 位作者的 arXiv 论文 2609.22978 把 DeepSeek Elastic Compute(简称 DSec)这套生产级沙盒平台从头到尾摊在桌面上。它不是论文里常被一笔带过的"基础设施",而是 DeepSeek 在 V3.2 到 V4.1 整段 RL 训练与评测里实际运行的调度底座。

把规模数字先摆出来

DSec 的生产部署规模相当硬。一组生产单元约 160 个节点,每天接住大约 300 万次沙盒启动,生产环境下持续维持 38 万以上并发沙盒,每秒能新建 5 000 多个。这种 burst 级别(亚秒内上千个沙盒起停)的工作量,远不是传统 PaaS 那套"容器一开一停"的逻辑能扛住的。DSec 把 FnCall、容器、microVM、全 VM 四种隔离后端暴露在同一套 SDK 后面,由 placement engine 在 160 节点之间用 power-of-k 选择算法做均衡,再由 edge 节点保留最终准入权,避免调度器把节点打死。

三件把"沙盒"从痛点变顺手货的活

第一件是按需镜像加载。DeepSeek 没去复刻一个 Docker registry,而是改造 dockerd,把 EROFS 镜像层动态插入 overlayfs,数据从自研 3FS 分布式文件系统按需拉取。8192 个容器突发拉取的评测里,按需 EROFS 与全本地基线都约 35 分钟跑完,eager Docker 拉取要 60 分钟,慢 1.71×,且单节点累计写盘 1600 GB,按需路径只要约 700 GB,几乎贴近本地缓存水平。

第二件是分层组合环境。开发环境、代码仓、CLI 工具被做成可挂载的只读 EROFS 层,而不是 tar.gz 解压包。tar.gz 是顺序流格式,每个沙盒必须解压复制才能开工,整套任务要 79 分钟;改 EROFS 后,镜像直接挂载、工具调用立刻开始,端到端时间被压到分钟级。

第三件是 QoS-aware CPU 调度与高密度内存复用。所有机制都基于 Linux 内置特性,不修改内核:best-effort 任务走 SCHED_IDLE、prctl(PR_SCHED_CORE) 做 core scheduling、按 QoS 等级分核;容器侧用 docker pause + memory.swap.max + memory.reclaim 主动让内存,恢复时 MADV_WILLNEED 异步预取;microVM 侧把 Firecracker 进程直接停掉、把内存与执行态落 snapshot,resume 时新建进程恢复 snapshot。

V4.1 那次改动才是真看点

论文最值得划线的,是 §6.2 描述的 agent loop 拆分。早期的训练管线把 agent loop、模型服务、RL 框架一起塞在抢占式 GPU 训练 pod 里。GPU 任务一旦被抢占,agent loop 跟着丢,sandbox 状态却还在;recover 要靠 command log 把 sandbox 执行态与 trainer 恢复的 rollout 状态对齐,代价高、副作用难去重。从 V4.1 起,DeepSeek 把 rollout 执行整体搬到 DSec 上,拆成两个组件:agent sandbox 承载 scaffold(比如 DeepSeek Harness)和工具,worker 容器负责管理 sandbox、提供 scaffold-agnostic 的控制层。两者都跑在抢占式 GPU 池之外,rollout 生命周期不再绑定 trainer 生命周期,被抢占的训练任务可以重新接上,继续推进,不再走 command-log replay。这等于把"训练与推理强耦合"这个老毛病,从系统层面切掉。

agent 越狱这事儿,系统也得兜底

论文 §6.4 直接列出了 agent 在训练里"找答案"的几种操作:伪造 RPC 打到 chronus socket、读 chronus 日志、覆写 /bin/bash 旁路检查、用 XFS_IOC_SWAPEXT 这个 ioctl 把两个文件的数据 extent 交换,逼得文件系统直接 shutdown。沙箱外,agent 还会扫端口、找 mirror、走 Go module proxy 抓 GitHub 上的现成实现。论文没有回避这些——它把这当作一类必须由系统层兜住的失败模式,而非 prompt 工程能修的毛病。配套的缓解是 AppArmor 文件与 socket 访问控制(对 root 进程也生效)+ per-sandbox eBPF 网络过滤器按任务下发 allowlist。两个机制合在一起,只挡得住"找答案"那一类,不挡 kernel panic;论文坦承"no single mechanism can prevent all"。

所以呢?

对做 RL 训练的人来说,DSec 给出了一个相当具体的工程样板:把沙盒做成弹性平台,而非单点运行时;把训练与 agent 执行的耦合,在系统层切断;把访问控制做成可按任务下发的策略面,而不是 prompt 层的对。对做系统的人来说,这篇 31 页论文里值得抄作业的东西,反而不是 RL 本身,而是 EROFS 按需挂载 + 3FS 拉取 + Linux 内置特性的那套组合——它不依赖任何私有内核模块,核心 Go 改动只有 30 行。对做产品的人,真正要紧的是,V4.1 之后 DeepSeek 的下一波旗舰模型,会在"agent 在沙盒里折腾了几百万次"这种规模下训练出来,模型行为里多出来的稳定性与攻击面理解,可能都来自这条管线。