DSec要解决什么：Agent训练环境的特殊性
Agent训练和传统云计算负载有本质区别。模型需要在真实环境中反复执行任务——读代码、改文件、安装依赖、运行测试——每一步都会改变环境状态，下一轮交互又要接着前面的状态继续。这要求沙盒既能快速大批量创建，又不能每步都销毁重建。
具体表现为几个特征：创建请求会集中涌入；CPU大部分时间空闲，但内存需要保留进程和文件状态；不同任务的执行环境差异很大；基础镜像复用率不高；训练过程还会因为GPU资源被抢占而中断。
DSec是支撑DeepSeek-V4全部训练、评测和数据预处理流程的沙盒基础设施。一套DSec扩展分片包含约160台服务器、3万个CPU核心和250TB内存，每天服务约300万个沙盒，高峰期同时在线超过38万个，每秒可创建5000多个沙盒。
环境与资源调度的关键优化
如果按传统方式，每个代码仓库或工具包更新都可能触发大批量镜像重建。DSec把环境拆成三层：操作系统和基础软件放入base image，任务代码和依赖放入workspace，工具单独做成toolkit。三层独立管理版本，创建沙盒时再组合，工具更新时只需重建工具层，不必从头重做整个环境。
镜像数据本身的传输也是大开销。统计显示Agent运行时真正访问到的数据只占整个镜像的4.2%到13.3%。DSec把镜像数据统一放到分布式文件系统里，本地只保存元数据，按需读取。测试数据：8192个Container的集中创建，原本需要60多分钟预先拉取完整镜像，改成按需加载后缩短到约35分钟，速度提升约1.71倍，磁盘写入量减少约57%。另一个工作区实验把tar.gz解压改为挂载EROFS层后，总耗时从79分钟缩短到45分钟，磁盘写入总量只有原来的约1/5.5。
资源调度方面，Agent沙盒稀疏性非常明显——约90%的沙盒平均CPU使用量不到申请资源的5%。DSec目前的资源超卖率已超过50倍，实现路径包括：
- 内存共享：通过virtio-pmem和DAX让同宿主机的MicroVM共享宿主页缓存，单独启用该机制可使宿主机峰值内存占用相比基线下降40.2%
- 空闲页回收：借助DAMON和balloon空闲页报告回收暂时不用的内存，按时间累计的内存消耗再降低21.2%
- CPU分级调度：时延敏感任务优先，时延要求低的任务利用剩余CPU。实验中同机其他任务已占用50% CPU容量时，时延敏感任务受到的延迟影响从45.2%降到17.3%
用Agent造Agent环境：轨迹分叉与安全防御
不同Agent任务对运行环境要求差异很大。DSec目前统一支持四种执行后端：FnCall（适合在线评测等短任务）、Container（软件工程和工具调用）、MicroVM（更强隔离）、Full VM（完整操作系统，支持GUI和Android应用）。
一个值得借鉴的设计是用Agent构建Agent环境。负责构建环境的Agent本身已经运行在DSec里，DSec把环境生产这件事合并到同一个平台。关键技术是pack_diff机制：Agent在沙盒里把环境配置好后，可直接生成增量快照保存当前状态，下次需要相同环境时从快照恢复即可，甚至每执行一步都可保存成新的可复用环境。
这带来了轨迹分叉能力：Agent执行到第k步有多种方案可选时，系统在第k步保存一次快照，从相同状态恢复出多个沙盒分别探索，前面环境和数据可共享，只有后续变化单独记录，无需重新执行前k步。对大规模强化学习而言，相当于把同一条轨迹上的环境状态变成可复用数据。
当Agent真的可在环境里自由操作后，安全风险随之上升。生产环境中已经观察到Agent尝试读取残留答案、伪造RPC请求、覆盖/bin/bash注入命令，甚至调用XFSIOCSWAPEXT绕过访问控制。强化学习的奖励机制会让模型主动寻找比正常完成任务更容易拿奖励的路径。DSec的应对策略包括：通过AppArmor限制文件和Socket访问（即便Agent拿到管理员权限规则仍生效）；网络侧用eBPF给每个沙盒设置白名单，限定地址、端口和协议。但DSec团队也明确承认，对内核漏洞这类风险目前仍缺少通用防御机制。
适用场景、选择标准与落地建议
DSec的设计对希望自建Agent训练基础设施的团队有直接参考价值。适合借鉴的场景包括：
- 需要大规模Agent训练或评测的平台
- 多类型执行环境并存的研发体系
- 对成本敏感、希望压低单任务资源占用的团队
选择类似方案时的判断标准：
- 镜像管理——能否做到按需加载而非全量预拉，能否支持分层组合更新
- 资源调度——是否支持基于任务时延要求的分级CPU调度，能否利用空闲页回收压缩内存占用
- 轨迹复用——能否支持环境状态快照和轨迹分叉，这对强化学习效率至关重要
- 安全隔离——能否提供多层防御，特别是对抗Agent主动探测的能力
落地建议：
- 先做环境分层——即便规模不大，分层管理也能显著降低镜像维护成本
- 优先优化热点路径——按需加载和内存共享是最直接的收益点
- 把Agent环境构建本身Agent化——pack_diff机制在中小规模也能带来明显效率提升
- 安全设计前置——Agent的主动探测能力往往超出预期，AppArmor加eBPF白名单是基础配置
如何用起来
DSec本身是DeepSeek内部基础设施，不作为产品对外提供。但其技术细节已在DeepSeek的技术分享文章中公开，文章标题为《DeepSeek弹性计算（DSec）：面向大规模Agent训练的沙盒基础设施》，可通过技术社区渠道获取完整内容参考。
对于希望自建类似能力的团队，关注以下几点：
- 基础设施栈：分布式文件系统、MicroVM、EROFS、virtio-pmem、DAX、DAMON等组件的开源实现情况
- 调度策略：参考DSec公开的CPU分级调度实验数据，自行在Kubernetes或其他编排平台上实现类似逻辑
- 团队组建：DeepSeek目前正在为弹性计算团队大规模招聘资深工程师，涉及沙盒、调度、安全等多个方向，有相关经验的工程师可关注招聘动态
如何用起来：通过 OpenStarry 接入
如果你想直接用上 deepseek 这类模型/工具，可以通过 OpenStarry 用一个 Key 快速接入，无需各自注册多个平台：
- 一个 Key 接入 13 款模型，完整兼容 OpenAI SDK，两行代码即可迁移；
- 官方原厂通道与自动容灾，节点异常时自动切换；
- 按量付费、人民币结算，模型调用费用以 OpenStarry 官网标价为准。
接入示例：
base_url: https://api.openstarry.com/v1
api_key: <你的 OpenStarry Key>
model: deepseek-v4-pro