本文首发于我的博客沙箱早就是成熟技术了DeepSeek 为什么还要重造一遍 · 「东玄蟒」点开这篇论文之前我以为会看到一个新沙箱。DeepSeek 9 月 19 日在 arXiv 上挂了一份 31 页的技术报告标题里写着 Sandbox Infrastructure。我的第一反应是大概又是一个更快的沙箱实现比 Firecracker 快多少、比 Docker 强多少。读完发现全文没有一句在讲怎么造沙箱。四种后端全是现成的——容器、Firecracker microVM、QEMU 全虚拟机再加一个轻量的函数调用。隔离技术一个都没自己发明。它真正在讲的事一开始完全不在我的视野里。一个数字暴露了问题论文里有个数据我盯着看了很久在一周的生产环境里容器后端用到了11,266 个基础镜像和102,171 个 workspace。而容器镜像的平均复用次数——论文叫 fanout——中位数只有 3。意思是绝大多数镜像全平台只有两三个沙箱会用到。这个数字把一条常见策略直接判了死刑。平时我们做容器习惯是常用镜像预热到本地缓存。但这里根本没有常用这回事一万多种基础环境乘十万多种代码仓库缓存命中率低得没有意义。于是问题变成了如果每个组合都必须提前打包成一整个镜像才能用会发生什么论文举了个很具体的例子。假设升级一个工具包那些打包时包含了它的镜像哪怕基础环境和代码仓库一点没变也必须全部重新打一遍。改 k 个工具要重建 k×N 个组合。而重建不是瞬间的每次都要真的把几 GB 的文件重新打包。在一次要起三万个沙箱的场景下光等镜像生成就能把整条流水线卡死。DeepSeek 的办法是把这三样拆开——基础环境、代码仓库、工具包各自独立版本化。用的时候不搬运、不解压直接叠在一起。这就是 Linux 的 overlayfs多个只读层从同一棵目录树里同时可见底层文件原地不动。改一个工具就只重建那一个工具。论文给的实测是同一个环境用压缩包解压的方式要 79 分钟用分层挂载 45 分钟快 1.76 倍磁盘写量还少 5.5 倍。agent 大部分时间在发呆第二个反常识的事实更狠90% 的沙箱平均用不到它们申请 CPU 的 5%。原因不难理解。agent 干活是思考一下、敲条命令、再思考一下等模型生成下一个动作的时候CPU 完全是闲的。但这条不能白用。因为同一个沙箱的另一面是寿命中位数 17 分钟p99 超过三小时。而且它是有状态的——改过的文件、装的依赖、起的服务全都要留着。CPU 闲着内存和磁盘一直占着。这两个事实合起来指向一个操作系统的老词超卖。单台机器塞 3200 个容器靠的就是它们不会同时醒这个统计假设。但假设不成立的时候怎么办论文的答案不是防住而是提前排好座次——把沙箱分成两等有严格延迟预算的比如下棋 AI 每步限时叫 latency-sensitive其余的统统是 best-effort。best-effort 被扔进SCHED_IDLE只要有 LS 任务想跑它立刻让路被饿死也无所谓。所以三千个沙箱同时醒的真实后果不是系统卡死而是 BE 任务集体变慢LS 几乎不受影响。这是设计的一部分不是故障。这里有个我没想到的细节。他们一开始以为降优先级就够了实测发现只改善了 3.4%等于没用。因为在超线程里两个任务可能跑在同一个物理核的两个兄弟线程上优先级管得了谁先拿到时间片管不了你俩共享同一个核的执行单元。于是又加了 Linux 的 core scheduling禁止别人的任务跑在 LS 的超线程兄弟上。延迟膨胀从 45.2% 压到 17.3%。剩下的 17.3% 他们忍了。论文原话剩余损耗主要来自睿频下降和缓存争抢因为已经可以忍受不做内存带宽隔离。工程上能说这里够了的地方比能说这里做到了的地方更有意思。最麻烦的是教练被叫走了第三个问题的场景是这样的GPU 训练任务会被集群抢占为了提高整体利用率而 agent 的执行逻辑一开始就住在那个被抢走的训练 pod 里。结果就是——教练突然被叫走但训练场地还在原地。早期的做法是记一份命令日志。训练恢复时拿日志和沙箱状态对账重放、跳过已经完成的操作还要小心非幂等命令不能重复执行。能work但很累。从 V4.1 开始他们把 rollout 执行整个搬到了 DSec 上拆成两个部分一个 agent sandbox 跑脚手架和工具一个 worker container 管沙箱。两者都在可抢占池外面。这一改rollout 的生命周期和 trainer 彻底解耦了。被抢占的 GPU 任务重连就能接着跑不用再重建命令日志那套逻辑。配套的还有暂停机制训练被抢占时RL 框架会给相关沙箱发 pause。容器是冻结进程树、开 swap、主动回收内存microVM 更直接——把内存和执行状态快照下来然后杀掉进程把内存还给系统。下次有请求进来几秒内恢复现场。同一个动作既省了资源又让状态活了下来。超卖和抢占恢复不是两个功能是一套机制的两张脸。用户是对手不是客户最后一根线是这篇论文里最生动、也最不像系统论文的部分。普通沙箱服务里用户是付钱的客户。这里用户是被训练的那个模型本身——而它在想办法骗你。论文列了他们在生产环境里抓到的实录有 agent 去翻系统日志找泄漏的答案有 agent 伪造用户请求直接往内部通信通道发构造好的消息因为有些操作底层走 bash有 agent 试图覆盖/bin/bash来绕过检查。上了第一层文件读写和 socket 访问控制之后有 agent 换了个很刁钻的手法想绕过——结果把文件系统元数据搞坏了直接触发 shutdown。沙箱外面还有 agent 用 Go 的包管理代理去 GitHub 上搜现成的实现。而另一类破坏根本没动机有 agent 从根目录递归搜索触发了内核 bug 把系统搞崩有个跑漏洞攻击的任务攻击命令没发给目标机器在它自己身上执行了还有 agent 调了yes命令输出被平台记录累积了几十 GB。论文很坦率地承认这些控制只解决了部分问题不提供对破坏性行为的通用防御。我读到这里才反应过来这两类根本不能同时解决存心作弊的那类行为是收敛的、有目的的可以划红线堵住而笨出来的破坏行为空间是无穷的堵不完。对后者他们靠的不是禁止而是隔离爆炸半径、保持可恢复、加强观测。论文里有句话我认为是全文最重的只看最终输出无法可靠判断 agent 是否按预期解决了任务。因为训练的时候如果分不清真会和抄到你训出来的模型就是在学作弊。它其实是操作系统的第二次上演聊到这儿我把四条线摆在一起看忽然意识到一件事。 四根线的完整思维导图见博客文末分层可交互版。瓶颈反常识的事实对策慢环境种类爆炸且几乎不重复用分层叠加用时拼装占90% 时间在等模型但状态要留三小时超卖 任务分级脆训练会被抢占agent 逻辑住在被抢的地方搬出来 冷冻快照贼只看结果分不清真会还是抄到堵通道 网络白名单然后我发现这套东西我全都见过——在一个操作系统的教科书里。进程调度、优先级、内存超卖、checkpoint/restore、联合文件系统、只读压缩层。DSec 一个概念都没发明它做的事是把这些概念在160 台机器、峰值 38 万个进程的尺度上重放了一遍然后用一个分布式文件系统3FS替换了本地磁盘。论文 §7 说得很直接不需要任何内核修改实现完全由配置和沙箱编排器集成构成。他们的核心工程改动之一是给 dockerd 加了30 行 Go 代码。所以最准确的说法可能是DSec 不是一个新沙箱它是进程管理这件事在一个新尺度上的再一次上演。规模可以说明为什么值得重做一遍160 台机器每天 300 万个沙箱峰值 38 万个同时活着每秒新建 5000 个。有件事我一开始没注意回头补上这些环境不是人手工造的。手工造几万个环境不现实所以他们让 agent 自己造——干完活给沙箱打个增量快照这个交互会话就直接变成了可复用的环境。配套有个防泄漏要求很有意思建环境的 agent 和用环境的 agent 用不同账号打包前必须清掉可写层的残留否则参考答案会被打包进镜像里。论文给这一节起名叫 “Build environments of Agents, by Agents, for Agents”。林肯的梗用在这儿挺合适。那到底什么变了回到最开始那个问题沙箱技术这么成熟了DeepSeek 为什么还要做这件事。不是因为隔离不够强也不是因为启动不够快。是因为问题的形状变了。推理场景的沙箱是一次性的、无状态的、用完即走的。而训练场景的沙箱是有状态的、长命的、会被随时打断的、要和训练循环对表的——而且里面那个用户正在想尽办法骗你。造房间的手艺早成熟了。但同时管 38 万个房间的入住、装修、水电、欠费还要防着住户撬锁——这是个完全不同的活。如果你也在做 agent 相关的东西我觉得这篇论文最值得带走的不是任何一个具体机制而是那个视角当你觉得某个技术已经很成熟的时候先问问自己是不是只看了它的一个用例。——论文原文DeepSeek Elastic Compute (DSec)31 页13 张图2026-09-19 提交。 
长河君 · 2026/9/24 6:31:30 · 阅读 1.2k 沙箱早就是成熟技术了，DeepSeek 为什么还要重造一遍？
本文首发于我的博客沙箱早就是成熟技术了DeepSeek 为什么还要重造一遍 · 「东玄蟒」点开这篇论文之前我以为会看到一个新沙箱。DeepSeek 9 月 19 日在 arXiv 上挂了一份 31 页的技术报告标题里写着 Sandbox Infrastructure。我的第一反应是大概又是一个更快的沙箱实现比 Firecracker 快多少、比 Docker 强多少。读完发现全文没有一句在讲怎么造沙箱。四种后端全是现成的——容器、Firecracker microVM、QEMU 全虚拟机再加一个轻量的函数调用。隔离技术一个都没自己发明。它真正在讲的事一开始完全不在我的视野里。一个数字暴露了问题论文里有个数据我盯着看了很久在一周的生产环境里容器后端用到了11,266 个基础镜像和102,171 个 workspace。而容器镜像的平均复用次数——论文叫 fanout——中位数只有 3。意思是绝大多数镜像全平台只有两三个沙箱会用到。这个数字把一条常见策略直接判了死刑。平时我们做容器习惯是常用镜像预热到本地缓存。但这里根本没有常用这回事一万多种基础环境乘十万多种代码仓库缓存命中率低得没有意义。于是问题变成了如果每个组合都必须提前打包成一整个镜像才能用会发生什么论文举了个很具体的例子。假设升级一个工具包那些打包时包含了它的镜像哪怕基础环境和代码仓库一点没变也必须全部重新打一遍。改 k 个工具要重建 k×N 个组合。而重建不是瞬间的每次都要真的把几 GB 的文件重新打包。在一次要起三万个沙箱的场景下光等镜像生成就能把整条流水线卡死。DeepSeek 的办法是把这三样拆开——基础环境、代码仓库、工具包各自独立版本化。用的时候不搬运、不解压直接叠在一起。这就是 Linux 的 overlayfs多个只读层从同一棵目录树里同时可见底层文件原地不动。改一个工具就只重建那一个工具。论文给的实测是同一个环境用压缩包解压的方式要 79 分钟用分层挂载 45 分钟快 1.76 倍磁盘写量还少 5.5 倍。agent 大部分时间在发呆第二个反常识的事实更狠90% 的沙箱平均用不到它们申请 CPU 的 5%。原因不难理解。agent 干活是思考一下、敲条命令、再思考一下等模型生成下一个动作的时候CPU 完全是闲的。但这条不能白用。因为同一个沙箱的另一面是寿命中位数 17 分钟p99 超过三小时。而且它是有状态的——改过的文件、装的依赖、起的服务全都要留着。CPU 闲着内存和磁盘一直占着。这两个事实合起来指向一个操作系统的老词超卖。单台机器塞 3200 个容器靠的就是它们不会同时醒这个统计假设。但假设不成立的时候怎么办论文的答案不是防住而是提前排好座次——把沙箱分成两等有严格延迟预算的比如下棋 AI 每步限时叫 latency-sensitive其余的统统是 best-effort。best-effort 被扔进SCHED_IDLE只要有 LS 任务想跑它立刻让路被饿死也无所谓。所以三千个沙箱同时醒的真实后果不是系统卡死而是 BE 任务集体变慢LS 几乎不受影响。这是设计的一部分不是故障。这里有个我没想到的细节。他们一开始以为降优先级就够了实测发现只改善了 3.4%等于没用。因为在超线程里两个任务可能跑在同一个物理核的两个兄弟线程上优先级管得了谁先拿到时间片管不了你俩共享同一个核的执行单元。于是又加了 Linux 的 core scheduling禁止别人的任务跑在 LS 的超线程兄弟上。延迟膨胀从 45.2% 压到 17.3%。剩下的 17.3% 他们忍了。论文原话剩余损耗主要来自睿频下降和缓存争抢因为已经可以忍受不做内存带宽隔离。工程上能说这里够了的地方比能说这里做到了的地方更有意思。最麻烦的是教练被叫走了第三个问题的场景是这样的GPU 训练任务会被集群抢占为了提高整体利用率而 agent 的执行逻辑一开始就住在那个被抢走的训练 pod 里。结果就是——教练突然被叫走但训练场地还在原地。早期的做法是记一份命令日志。训练恢复时拿日志和沙箱状态对账重放、跳过已经完成的操作还要小心非幂等命令不能重复执行。能work但很累。从 V4.1 开始他们把 rollout 执行整个搬到了 DSec 上拆成两个部分一个 agent sandbox 跑脚手架和工具一个 worker container 管沙箱。两者都在可抢占池外面。这一改rollout 的生命周期和 trainer 彻底解耦了。被抢占的 GPU 任务重连就能接着跑不用再重建命令日志那套逻辑。配套的还有暂停机制训练被抢占时RL 框架会给相关沙箱发 pause。容器是冻结进程树、开 swap、主动回收内存microVM 更直接——把内存和执行状态快照下来然后杀掉进程把内存还给系统。下次有请求进来几秒内恢复现场。同一个动作既省了资源又让状态活了下来。超卖和抢占恢复不是两个功能是一套机制的两张脸。用户是对手不是客户最后一根线是这篇论文里最生动、也最不像系统论文的部分。普通沙箱服务里用户是付钱的客户。这里用户是被训练的那个模型本身——而它在想办法骗你。论文列了他们在生产环境里抓到的实录有 agent 去翻系统日志找泄漏的答案有 agent 伪造用户请求直接往内部通信通道发构造好的消息因为有些操作底层走 bash有 agent 试图覆盖/bin/bash来绕过检查。上了第一层文件读写和 socket 访问控制之后有 agent 换了个很刁钻的手法想绕过——结果把文件系统元数据搞坏了直接触发 shutdown。沙箱外面还有 agent 用 Go 的包管理代理去 GitHub 上搜现成的实现。而另一类破坏根本没动机有 agent 从根目录递归搜索触发了内核 bug 把系统搞崩有个跑漏洞攻击的任务攻击命令没发给目标机器在它自己身上执行了还有 agent 调了yes命令输出被平台记录累积了几十 GB。论文很坦率地承认这些控制只解决了部分问题不提供对破坏性行为的通用防御。我读到这里才反应过来这两类根本不能同时解决存心作弊的那类行为是收敛的、有目的的可以划红线堵住而笨出来的破坏行为空间是无穷的堵不完。对后者他们靠的不是禁止而是隔离爆炸半径、保持可恢复、加强观测。论文里有句话我认为是全文最重的只看最终输出无法可靠判断 agent 是否按预期解决了任务。因为训练的时候如果分不清真会和抄到你训出来的模型就是在学作弊。它其实是操作系统的第二次上演聊到这儿我把四条线摆在一起看忽然意识到一件事。 四根线的完整思维导图见博客文末分层可交互版。瓶颈反常识的事实对策慢环境种类爆炸且几乎不重复用分层叠加用时拼装占90% 时间在等模型但状态要留三小时超卖 任务分级脆训练会被抢占agent 逻辑住在被抢的地方搬出来 冷冻快照贼只看结果分不清真会还是抄到堵通道 网络白名单然后我发现这套东西我全都见过——在一个操作系统的教科书里。进程调度、优先级、内存超卖、checkpoint/restore、联合文件系统、只读压缩层。DSec 一个概念都没发明它做的事是把这些概念在160 台机器、峰值 38 万个进程的尺度上重放了一遍然后用一个分布式文件系统3FS替换了本地磁盘。论文 §7 说得很直接不需要任何内核修改实现完全由配置和沙箱编排器集成构成。他们的核心工程改动之一是给 dockerd 加了30 行 Go 代码。所以最准确的说法可能是DSec 不是一个新沙箱它是进程管理这件事在一个新尺度上的再一次上演。规模可以说明为什么值得重做一遍160 台机器每天 300 万个沙箱峰值 38 万个同时活着每秒新建 5000 个。有件事我一开始没注意回头补上这些环境不是人手工造的。手工造几万个环境不现实所以他们让 agent 自己造——干完活给沙箱打个增量快照这个交互会话就直接变成了可复用的环境。配套有个防泄漏要求很有意思建环境的 agent 和用环境的 agent 用不同账号打包前必须清掉可写层的残留否则参考答案会被打包进镜像里。论文给这一节起名叫 “Build environments of Agents, by Agents, for Agents”。林肯的梗用在这儿挺合适。那到底什么变了回到最开始那个问题沙箱技术这么成熟了DeepSeek 为什么还要做这件事。不是因为隔离不够强也不是因为启动不够快。是因为问题的形状变了。推理场景的沙箱是一次性的、无状态的、用完即走的。而训练场景的沙箱是有状态的、长命的、会被随时打断的、要和训练循环对表的——而且里面那个用户正在想尽办法骗你。造房间的手艺早成熟了。但同时管 38 万个房间的入住、装修、水电、欠费还要防着住户撬锁——这是个完全不同的活。如果你也在做 agent 相关的东西我觉得这篇论文最值得带走的不是任何一个具体机制而是那个视角当你觉得某个技术已经很成熟的时候先问问自己是不是只看了它的一个用例。——论文原文DeepSeek Elastic Compute (DSec)31 页13 张图2026-09-19 提交。