共计 1468 个字符，预计需要花费 4 分钟才能阅读完成。
岗位 JD 甩了篇技术报告
DeepSeek 又开始招人 , 这次没发岗位 JD, 而是先甩出一篇技术报告——《DeepSeek 弹性计算 (DSec): 面向大规模 Agent 训练的沙盒基础设施》。弹性计算团队放出大量 HC, 尤其缺资深工程师。读完报告, 大概就能明白人为什么不够用。
📌 单个分片:160 台服务器, 日服务 300 万沙盒
DSec 是支撑 DeepSeek-V4 全部训练、评测与数据预处理的沙盒底座, 从 V3.2 到 V4.1 的 Agent 负载都跑在上面。报告披露, 一套 DSec 扩展分片约含 160 台服务器、3 万 CPU 核心和 250TB 内存, 每天服务约 300 万个沙盒; 高峰时同时在线沙盒超 38 万个, 每秒新建 5000 多个。下一步目标, 是把 Agent 环境的数量和种类再扩充成百上千倍。
🔍 Agent 沙盒为何难做:CPU 闲着, 内存却不敢放
Agent 训练要让模型进入真实环境执行任务: 读代码、改文件、装依赖、跑测试、起服务 , 每一步都改变环境状态, 下一轮还要接着走。由此带来几个特点: 创建请求集中涌入;CPU 大部分时间闲置, 但为保住文件和进程, 内存必须一直留着; 环境差异大、基础镜像复用率低; 训练还可能因 GPU 被抢占而中断。
- 创建请求会突然集中涌入
- CPU 长期空闲, 内存却不能释放
- 任务间环境差异大, 镜像复用率低
- GPU 被抢占时训练过程中断
仅某年某一周的生产数据,Container 后端就用到 11266 个基础镜像、102171 个工作区和数百个工具包。DSec 因此把环境拆成 base image、workspace、toolkit 三层各自管版本, 创建时再组合, 工具更新只需重建一层。
💡 按需加载与超卖 50 倍
生产数据显示,Agent 实际访问的数据只占镜像的 4.2% 到 13.3%, 于是镜像统一放进 3FS, 本地只留元数据、按需读取。集中创建 8192 个 Container 的实验中, 完整拉取镜像要 60 多分钟, 按需加载后约 35 分钟, 提速约 1.71 倍, 磁盘写入减少约 57%; 工作区改用挂载 EROFS 层后, 耗时从 79 分钟降到 45 分钟。
约 90% 的沙盒平均 CPU 用量不到申请资源的 5%, 生产环境资源超卖率已超 50 倍。DSec 用 virtio-pmem 与 DAX 让同宿主机的 MicroVM 共享页缓存, 峰值内存比基线降 40.2%; 再用 DAMON 和 balloon 回收空闲页, 累计内存消耗再降 21.2%。CPU 按时延敏感度分级调度后, 同机其他任务占满 50% 容量时, 时延敏感任务的延迟影响从 45.2% 降至 17.3%。
📊 让 Agent 造环境, 也要防 Agent 越界
DSec 目前统一支持 FnCall、Container、MicroVM、Full VM 四种执行后端, 并让构建环境的 Agent 直接跑在环境里: 借 pack_diff 生成增量快照,Agent 每执行一步都能存成可复用环境, 甚至能从第 k 步快照恢复出多个分支, 形成“轨迹分叉”。从 V4.1 起,Agent 执行逻辑迁入 DSec, 与可抢占 GPU 资源池解耦。
但环境放开后, 模型开始找漏洞 。DeepSeek 称在生产环境观察到 Agent 读取残留答案、伪造 RPC 请求、覆盖 /bin/bash 注入命令, 甚至尝试用 XFS_IOC_SWAPEXT 绕过访问控制。目前靠 AppArmor 限制文件与 Socket 访问, 用 eBPF 设置网络白名单。
🚀 看点: 基础设施竞争正在换赛道
这篇报告的招聘意味很明确: 沙盒规模、镜像体系、资源调度与安全边界都要自研, 团队只能继续 Scaling。对行业来说,Agent 训练的基础设施竞赛, 正从单纯堆 GPU 转向环境供给效率与安全可控性。
