DeepSeek在arXiv披露了其生产级智能体训练沙箱平台DSeC，单个生产单元覆盖约160个节点、每秒创建超过5000个沙箱并在生产环境支持超过38万个并发沙箱，展示了面向大规模agent训练的调度、资源回收和镜像分发方案。论文强调将rollout执行与GPU训练解耦、统一接入多种执行后端，并提醒规模数据为团队部署结果，真实效果受硬件与任务复杂度影响。
DeepSeek团队在9月19日提交至arXiv的技术报告中，首次较完整地披露了其用于大规模智能体训练与评估的生产级沙箱基础设施——DeepSeek Elastic Compute（DSeC）。论文称，一个生产规模单元约覆盖160个节点，每天可服务约300万个沙箱；在生产环境中，系统支持超过38万个并发沙箱，创建速度超过每秒5000个。
这项披露的重点不是发布新的基础模型，而是展示支撑智能体训练的执行环境如何被大规模调度。论文原文题为《DeepSeek Elastic Compute (DSec): A Sandbox Infrastructure for Effective Agentic Training at Scale》，提交日期为2026年9月19日。TechNode在9月23日的报道中也援引了论文中的上述规模数据，并指出DeepSeek创始人梁文锋列在论文作者之中。
智能体训练需要的不只是模型和GPU
传统语言模型训练通常可以围绕数据、GPU集群和参数更新展开。但智能体训练还要求模型在接近真实软件环境的隔离空间中持续行动：读取代码仓库、调用工具、执行命令、安装依赖、启动服务，并根据执行结果调整下一步操作。
这意味着，每一个训练或评估任务都可能需要一个包含代码、依赖、服务、测试脚本和特定工具的有状态环境。模型交互期间，沙箱可能长时间保持存活；即使CPU处于空闲状态，内存、缓存和可写状态仍然会被占用。训练任务还可能突然同时请求数以万计的环境，使调度、镜像分发和生命周期管理成为瓶颈。
DSeC通过统一SDK接入函数调用、容器、微虚拟机和完整虚拟机等不同后端。论文解释，轻量、短时的任务可以采用函数或容器，要求更强系统能力或完整操作系统的任务则可以使用虚拟机。通过把这些环境放在同一套调度和生命周期管理体系中，平台可以根据任务的隔离强度、资源需求和持续时间选择不同的执行方式。
统一接入背后的调度和资源回收
论文披露，DSeC会在集群范围内负责沙箱的放置、创建、扩缩和回收，并把环境拆分为可以独立版本管理的层。系统还结合内存共享、资源回收和CPU调度，试图在高密度运行时提高节点利用率。
在生产部署中，单个节点最多可以承载约800个微虚拟机或3200个容器，但这依赖安全的资源超分和细致的生命周期管理。由于智能体在等待模型生成下一步动作时，CPU使用往往并不连续，平台可以利用这种间歇性进行更高密度的安排；另一方面，有状态任务又可能长期占用内存和写入状态，因此不能只根据瞬时CPU负载判断资源是否可以回收。
DSeC还会按需从Fire-Flyer File System（3FS）加载镜像数据。论文称，智能体训练和评估涉及大量环境镜像，且不同任务之间的复用有限，按需加载有助于降低初始化和镜像分发的压力。
把rollout执行与GPU训练解耦
DSeC与强化学习框架共同设计，把有状态的智能体rollout执行与可抢占的GPU训练过程解耦。rollout阶段，模型在沙箱中执行任务并产生轨迹；随后，系统根据退出码、标准输出、测试通过率或任务验证器计算奖励，再用于策略更新。
这种解耦可以让GPU训练资源和沙箱执行资源分别调度。论文还描述了一个与训练过程协同的生命周期机制：在保留rollout状态的同时回收闲置资源，并在任务继续时恢复相应环境。对于需要跨多个模型更新阶段持续交互的任务，这种状态连续性比简单地频繁创建新容器更重要。
论文同时讨论了智能体错误行为，包括奖励投机（reward hacking）。如果训练系统只奖励某个表面结果，智能体可能找到绕过真正任务目标的路径。因此，沙箱平台不仅是运行代码的基础设施，也是奖励计算、轨迹观察和异常行为处理的一部分。
规模数字应被视为团队披露的部署结果
论文给出的380,000多个并发沙箱、每天约300万个沙箱和每秒超过5000次创建，均来自DeepSeek对生产部署和评估结果的描述，并非独立第三方基准。不同部署环境的硬件配置、镜像复杂度、任务类型和隔离要求可能不同，因此不能据此推断所有沙箱平台都能达到相同吞吐量。
同样，DSeC是训练与评估基础设施的披露，不等同于新基础模型发布。它反映的是DeepSeek正在把智能体训练从单次实验扩展为大规模、持续运行的系统工程：模型能力之外，环境创建速度、状态保持、资源回收、镜像分发和奖励验证都可能直接影响训练效率和评估可信度。
这也解释了为什么智能体基础设施开始成为模型竞争的一部分。近期围绕开发者运行时的讨论，已经从单纯的工具调用扩展到长期任务、浏览器操作、后台执行和多智能体编排；例如，AIFlux此前报道的DeepSeek Harness候选版本已把计算机操作、浏览器后端和多工具工作流集中到开发者运行时中。另一篇关于OpenAI Agents API与托管沙箱的报道，则显示行业也在尝试把长时任务、会话恢复和沙箱环境包装成平台能力。
但规模扩大也会放大边界管理的风险。沙箱与生产系统之间的网络、凭证和数据管线如何隔离，已经成为智能体评估的重要问题；[Hugging Face对一次从评测沙箱延伸至生产系统的代理入侵事件的复盘](https://aifluxnews.com/hugging-face-%E8%AF%A6%E8%A7%A3-7-%E6%9C%88-ai-%E4%BB%A3%E7%90%86%E5%85%A5%E4%BE%B5%EF%BC%9A%E4%BB%8E%E8%AF%84%E6%B5%8B%E6%B2%99%E7%AE%B1%E5%88%B0%E7%94%9F%E4%BA%A7%E7%B3%BB%E7%BB%9F%E7%9A%84%E6%95%B0/】就说明，隔离、审计和回滚机制必须与执行速度同步建设。
目前仍不清楚DSeC是否会作为独立软件或服务对外开放，也不清楚论文中的生产规模对应哪些具体训练任务、硬件配置和长期运行成本。可以确认的是，DeepSeek已经公开展示了一套面向大规模智能体训练的弹性执行平台。随着智能体从回答问题转向持续行动，这类“模型之外”的基础设施，可能越来越决定系统能否稳定、可验证地工作。
来源：DeepSeek Elastic Compute论文（arXiv，2026年9月19日）；论文HTML全文；TechNode报道（2026年9月23日）。