坦白说，第一次在技术评审会上看到DSec这个项目名，我心里是打了个问号的——大模型训练不是把数据和算力堆上去就行了吗，为什么还要专门搞一套“沙箱基础设施”？直到自己真正开始跑智能体训练，我才意识到传统训练和Agent类任务之间的鸿沟有多大，也才理解“沙箱化”这三个字背后藏着的调度、隔离、弹性、恢复这一整套问题。

DSec（DeepSeek弹性计算）就是冲着这个场景来的：它把大规模智能体训练环境做成了可弹性伸缩的沙箱基础设施，每个训练任务跑在独立、可复现、可隔离的运行环境里，底层资源按水位自动扩缩容，调度层统一管理成千上万个并发实例。这篇文章不讲PPT，只做技术拆解和落地实录，内容包括设计思路、核心机制、部署步骤、排障经验。适合正在搭建AI训练基础设施的工程师、算法团队里负责大规模Agent实验的同学，以及想搞清楚这套架构“为什么这么设计”的技术负责人。

1. 项目解析：DSec到底在解决什么问题

1.1 为什么智能体训练不是普通的训练任务

我们平时说的深度学习训练，不管是CV还是NLP，再复杂也就是“喂一批样本、算梯度、更新权重”这个循环。智能体训练完全不是这个玩法。它是在一个动态环境里让模型反复决策、执行动作、观察反馈，任务可能横跨几十个工具调用，中途还会动态拉起新的子任务。

举一个最简单的例子：训练一个能自动浏览网页、填写表单、调用搜索API的Agent。它每个回合的训练信号不是静态标注好的样本，而是“动作执行之后环境的反馈结果”。这种任务要跑出规模，往往同时存在几百上千个相对独立的探索分支，每个分支有自己的临时工作目录、会话状态、工具依赖。

如果把这些东西全部丢到同一台裸机上跑，很快会遇到三个非常现实的问题：

• 依赖冲突。分支A要装playwright做浏览器自动化，分支B只需要纯CPU版的torch做策略网络推理，装来装去环境就乱了。
• 安全边界模糊。Agent会执行任意代码、连外部网络，一旦某个分支因为探索策略失控去访问内部系统，整条训练链路都会出问题。
• 状态残留。上一个任务留下的临时文件、环境变量、动态链接库，会莫名其妙影响下一个任务的实验结果，而且这种影响极其隐蔽，查都查不到。

DSec把这些问题归为同一个根因：训练环境没有边界。沙箱不是“多一层限制”，而是给每个智能体任务一个确定性的运行边界，让环境本身成为可声明、可管理、可复现的工件。

1.2 DSec的模块划分与设计取舍

大方向上看，DSec是一套面向智能体任务的调度系统，但它的架构不是把Kubernetes拿过来直接用，而是在容器基础设施之上重新做了一层任务编排框架。原因是K8s的原生控制器比较偏“无状态Web服务”模型，对智能体训练里“长时运行、动态子任务、GPU共享、状态恢复恢复”这套诉求支持得比较粗糙。

DSec整体分成五个模块：

• API Server：面向用户的统一入口，负责任务提交、配额管理、身份认证、操作审计。所有训练任务的描述都通过这里进入系统。
• Scheduler：全局调度器，实时感知每个节点的GPU类型、显存余量、网络带宽、镜像缓存状态，然后把任务调度到最合适的位置。
• Sandbox Runtime：每个训练任务占用的隔离单元。负责文件系统、网络、进程、GPU的隔离，并且支持在任务运行中调整CPU、内存配额。
• Image & Artifacts：训练镜像、工具插件都打包成不可变工件统一管理；任务生成的模型检查点、评估报告、trace数据也在这一层归档。
• Observability：汇总每个沙箱的日志、指标、调用链数据，给训练任务一个“体检报告”。

把Sandbox Runtime单独拿出来作为一层，而不是让任务直接跑在裸容器里，是我认为DSec最关键的设计取舍。智能体任务经常需要两种能力：一是运行中改变资源配置，比如一个分支刚开始单卡推理，跑着跑着需要变成双卡分布式训练；二是失败时能把“整个环境连同检查点”一起恢复，而不是简单重启一个容器。

裸容器很难做好这两件事。DSec的沙箱把所有状态放到一个可解析、可迁移的单元里，恢复操作就变成了“重建沙箱加挂载检查点”，整个过程能把训练回退到之前任何一个状态点。

1.3 与现有方案的核心差异

为了不纸上谈兵，我把传统作业调度、K8s Pod和DSec沙箱放在一张表里做了对比，选型的依据全在这张表里：

SLURM最大的问题在于它假定作业是“一次性计算”，调度完就完事，但智能体训练是不断交互的，中间产生的临时状态比最终模型参数还要重要。K8s的失败重试是面向微服务的，容器退出重启，但Agent动态子任务的状态往往已经丢了。DSec把检查点当成一等公民，恢复后相当于把时间回退到某个回合，再从这里接着往下跑。这一点对长周期智能体训练来说，价值远大于“能跑起来”本身。

2. 核心机制拆解：沙箱、弹性与调度的关键细节

2.1 沙箱隔离机制：从文件系统到GPU

沙箱内部的第一层隔离是文件系统。我落地时采用的是三层结构：基础层是一份只读镜像，包含模型权重、Python环境和预先装好的依赖；可写层用OverlayFS记录运行时修改，任务结束默认丢弃；真正需要保留的数据放在持久卷，比如数据集、检查点和API密钥。

这套设计的价值在于“环境可复现”。哪怕一个智能体训练任务跑了上千轮交互，只要可写层清掉，每个回合都能在完全一致的环境中重新启动。凡是复现不出实验结果的团队，大多数问题都可以追溯到环境漂移，DSec直接把这个变量干掉了。

第二层是网络隔离。每个沙箱有独立的网络命名空间，出网流量统一走节点上的网关组件。网关维护一个白名单域名和端口列表，训练Agent可以访问外部搜索API，但碰不到集群内部元数据服务。如果多个Agent需要在同一个任务里通信，系统会建立专门的内部DNS或共享内存队列；不同任务之间默认是不互通的。这样即使某个Agent在探索阶段执行了危险命令，它的破坏半径也被限制在单个沙箱内部。

第三层是GPU隔离。整卡模式适合大模型预训练和大Batch强化学习；MIG切分适合A100/H100这类卡上跑多个小模型推理任务；CUDA MPS适合推理和评估这类碎片化负载。这里要特别提醒一个MPS的坑：MPS本质上是一个代理服务，当多个进程同时发起显存申请时，MPS服务端很容易变成瓶颈。我的建议是不仅设置显存上限，还要按应用画像限制同一MPS上下文里的并发进程数，否则你会看到GPU利用率很高但吞吐几乎不涨的诡异现象。

2.2 弹性伸缩的策略与参数选型

弹性伸缩在DSec里分三层，每一层的触发条件和作用对象都不一样。

第一层是沙箱内垂直扩容。训练跑到一半发现某个分支CPU吃紧，可以直接在线调整CPU和内存配额。需要注意GPU显存不支持动态在线扩容，所以显存分配必须在任务启动前规划好，这也倒逼我们在提交任务时把资源需求写得更精确。

第二层是任务级水平伸缩。智能体评估这类“无状态回合”场景经常需要大量同构沙箱并行，系统根据水位自动扩展副本数量。这里有一个参数设计实例可以分享。假设单节点是8卡A100 80G，部署一个批处理型Agent评估服务，单个Agent实例大约需要4G显存、2核CPU、4G内存，理论上单卡可以跑20个实例，但实测我推荐单卡不超过12个。原因是Agent不仅有显存压力，CPU和内存波动也很大，留出余量才能避免雪崩。按这个标准，一个8卡节点的单批最大实例数是96个。

第三层是节点级弹性。节点层不感知单个任务，只看整体水位和队列长度。当集群队列积压超过阈值且持续一段时间，就自动注册新节点；相反，当资源利用率低于缩容阈值且没有高危任务运行时，再逐步回收节点。

伸缩参数的设定需要非常谨慎。我常用的起点是：CPU利用率超过70%且持续5分钟开始扩容，低于30%且持续5分钟开始缩容，扩缩容冷却时间设为10分钟。冷却时间极其重要，它防止的是“任务分钟级波动导致节点反复启停”的震荡效应。上线前一定要压测，不要凭感觉设阈值。

2.3 生命周期管理与任务编排

一个训练任务从提交到销毁的完整流程，我拆成七个阶段：

1. 提交：通过API提交任务声明，包括镜像、资源、优先级、恢复策略。
2. 镜像分发：如果目标节点已有缓存镜像则跳过拉取，没有则从仓库拉取。
3. 调度绑定：调度器综合GPU类型、亲和性要求、数据位置，把任务绑定到节点。
4. 沙箱创建：网络、存储、隔离配置准备就绪。
5. 启动执行：入口脚本拉取检查点、初始化工作目录、启动训练进程。
6. 运行监控：指标、日志、看门狗持续上报。
7. 结束回收：统一释放资源，检查点上传工件仓库。

DSec的检查点机制设计得非常细，不只有模型权重。智能体训练里，还要同时保存环境状态、随机数种子、对话历史缓冲区。如果这些不保存，任务恢复后前后两个回合的动作序列就对不上，训练信号就是错的，模型很可能彻底训偏。我见过团队只保存模型权重就做恢复，结果训练曲线断崖式下跌，查了很久才意识到是agent的上下文状态丢了。

服务器负载方面，由于每个沙箱的生命周期都比较短，日志采集要避免全量落盘。我们采用“结构化日志+采样存储”，完整日志放进对象存储，查询时再拉取，这样既保住了可观测性，又不至于把日志节点跑满。

3. 从0到1落地一套DSec的实操流程

3.1 前置环境与基础组件准备

DSec对底层环境的依赖并不复杂，但版本匹配卡得很严。基础要求是Linux内核5.x以上、NVIDIA驱动、Docker或Containerd、etcd集群、私有镜像仓库。

GPU节点上的容器运行时配置是最容易出问题的环节。以Docker为例，先安装NVIDIA Container Toolkit，然后执行配置命令：

nvidia-ctk runtime configure --runtime=docker systemctl restart docker

配完后一定做一次验证：

docker run --rm --gpus all nvidia/cuda:12.4.1-base-ubuntu22.04 nvidia-smi

能正常显示GPU信息才算过。这一步如果失败，先查驱动版本和CUDA Toolkit是否匹配，再查Docker是否认到nvidia这个Runtime。很多时候“沙箱里看不到GPU”的根源就出在这里，和DSec本身一点关系都没有。

etcd建议至少三节点，存储所有任务状态和节点心跳数据。镜像仓库内网部署一套，训练镜像全部走内网分发，这也是后面离线局域网部署能跑起来的前提。

3.2 控制面初始化与节点接入

控制面初始化我习惯分三步。第一步启动API Server，指定etcd地址和JWT签名密钥，这一步解决“谁能进系统”的问题；第二步启动Scheduler，连接同一套etcd，开始接收节点心跳；第三步在每台GPU节点上安装dsec-agent，配置服务器地址和注册token，节点注册后打上标签，比如gpu-type=a100、region=cn-east。

节点注册完，用命令行确认状态正常：

dsecctl node list

看输出的状态列，Ready就说明节点已经纳管。如果一直是NotReady，优先检查40001端口网络连通性和token是否过期，这两个是最高频的原因。

调度器启动后，控制台会显示集群总资源量、已分配资源、队列长度。到这里基础设施就已经能用了，但离“能训练智能体”还差最后一步——定义训练任务。

3.3 提交一个智能体训练任务

任务描述我建议一律用YAML，便于评审和版本管理。一个比较典型的配置长这样：

metadata: name: agent-exp-20250614-01 spec: image: registry.internal/dsec/agent-train:v2.3 entrypoint: ["/opt/bootstrap.sh"] isolationLevel: container gpu: mode: mps memory: 4Gi resources: cpu: 2 memory: 4Gi storages: - name: dataset mountPath: /data/eval pvc: pvc-agentdata-ro - name: workdir mountPath: /workspace size: 8Gi network: egressPolicy: whitelist allowedDomains: - "api.search.example.com" - "huggingface.co" elastic: minReplicas: 1 maxReplicas: 96 scaleMetric: cpu targetUtilization: 70 restartPolicy: checkpoint

逐项讲几个容易被忽略的设计意图：

isolationLevel: container表示用容器隔离，但如果任务涉及不可信代码执行，建议改成microvm，等于给Agent套了一台微型虚拟机，安全边际高一个量级，但启动速度和资源开销会差一些。这个选择本质上是安全性和性能的权衡，没有绝对答案。

network.egressPolicy必须显式声明网络边界。有一句话我重复过很多次：智能体训练任务默认不给外网权限，要用哪个域名开哪个。尤其要警惕Agent在探索阶段访问云厂商的元数据地址，一旦泄露访问凭证就是事故级的问题。

restartPolicy: checkpoint是一个隐含的高价值特性。任务崩溃后不是从零重跑，而是从最近的检查点恢复，恢复粒度在配置里用checkpointInterval: 300控制，表示每300秒自动打一次点。

提交命令很简单：

dsecctl apply -f agent-exp-20250614-01.yaml

提交后查看状态：

dsecctl get tasks dsecctl describe task agent-exp-20250614-01

describe会列出调度器给的调度理由，如果是Pending状态，里面通常会写清楚是资源不足还是镜像未就绪。

3.4 与日常工具链的联动

部署完基础能力，真正让它变成“生产力工具”的，是跟团队日常开发链路的整合。这里分享三个我实测有效的场景。

场景一：在沙箱里本地部署DeepSeek推理服务。用vLLM拉起推理任务，配置里显式声明监听端口。其他沙箱里的Agent可以通过内部服务名直接调用。这里有个关键细节：推理任务和训练任务如果混在同一节点，需要设置CPU亲和性和显存预留，物理核争抢会直接导致推理延迟飙升。

场景二：DSec与harness类插件的联动。沙箱启动时会读取镜像内预设的插件目录，通过PLUGIN_HOME环境变量注入到任务进程。比如提示词优化插件、数据集标注模板插件，都可以在镜像构建阶段装好，再通过dsecctl plugin install做统一管理。这样每个训练任务的Agent能力是一致的，不会出现这个沙箱有工具、那个沙箱没工具的尴尬。

场景三：离线局域网环境。只要镜像仓库和Python依赖都放在内网，DSec完全可以不依赖公网运行。注意把镜像拉取策略设为IfNotPresent，避免每次启动都去校验远程源。首次分发大镜像时建议在业务低峰期做，否则节点磁盘IO会被拉满。

还有一个经常被问到的场景是开发工具接入DeepSeek服务。本质上是外部客户端需要访问沙箱内的推理服务，DSec可以配置网关端口映射，但必须强制开启令牌鉴权和限流。开放给开发工具和开放给Agent训练是两条完全不同的链路，安全策略不能混用。

4. 排障与实战经验：文档里不会写的坑

4.1 任务长时间Pending

这是使用频率最高的问题。按我排查的经验，大概率的根因有四类，直接看describe输出就能定位：

最高效的排查路径是：先dsecctl describe看调度器判断，再去节点上看dsec-agent日志，跳过所有猜测环节。

4.2 容器内看不到GPU

这个问题十次有八次出在NVIDIA Container Toolkit配置上，不是DSec的问题。排查命令按顺序执行：

nvidia-smi docker info | grep -i runtime dsec-agent logs --tail 50

如果docker info里的Runtimes没有nvidia，说明nvidia-ctk runtime configure那一步没有生效，重新配置并重启Docker。还有一种情况是MPS模式的沙箱看不到GPU，那是MPS控制进程没起来或者和驱动版本不兼容，单独重启MPS服务即可。

4.3 网络与文件权限问题

文件权限问题在多节点环境下特别容易踩。最常见的是在Windows上编辑好训练脚本，通过Web控制台上传到沙箱后，进程启动报权限错误。比如Windows下解压文件导致ACL异常，Linux侧映射不了，执行时就会报一些看起来莫名其妙的错误。

解决办法有两个方向：一是在文件上传阶段改用tar打包再解压，避免直接传输带ACL的文件；二是在沙箱配置里显式设置用户命名空间映射，把上传文件的UID映射到任务运行用户。说到底，沙箱内的文件权限管理不能依赖“碰巧正确”，要像对待镜像版本一样把它写进配置。

网络问题的重点在于白名单政策。新部署时常出现Agent任务访问某个域名被网关拦截，看起来像“网络坏了”，其实是白名单没配。排查时先看网关组件的域名拦截日志，比在沙箱里反复ping外部地址高效得多。

4.4 弹性伸缩抖动与资源碎片化

弹性伸缩做得不好，比不做还难受。我遇到过节点在半小时里被拉起、缩掉、再拉起的循环，资源没省到，调度器倒累得够呛。根因一般是阈值设置得太敏感，加上镜像预拉没有做好，新节点拉起后长时间处于“没镜像可用”的空转状态。

我的对策有三条：

• 设置缩容保护期。节点缩容前至少空闲10分钟以上，避免任务短暂间隙触发缩容。
• 镜像预热。任务提交时调度器先把镜像拉到目标节点，等节点就绪时镜像已经在本地，把“节点可调度时间”大幅缩短。
• 固定最小节点数。根据历史任务画像算一个保底节点数，非工作时段可以缩到这个数，但不要一直到0。从0启动一个节点的时间足够让一批短任务直接超时。

资源碎片化是另一个容易被低估的问题。大批小显存任务在MPS模式下结束后，空闲显存像芝麻一样分散，大模型任务插不进去。我目前的做法是把节点按照“小任务池”和“大任务池”打标签隔离，虽然降低了一点弹性上限，但明显减少了因碎片化调不动任务的局面。

最后交付时的三点建议

这套系统前前后后我部署了三轮，最深的体会是“能做出来”和“能稳定用”之间的距离，比想象中大得多。最后分享三个我踩过坑之后总结的建议。

第一，GPU驱动、容器运行时、NVIDIA Container Toolkit三者的版本必须锁死，形成一个固定的“基线版本组合”，升级任何一个都要走测试流程。越到底层的组件越不值得追求最新，稳才是第一位的。

第二，所有训练任务必须显式声明资源上限，哪怕你觉得写高了浪费。系统按声明分配资源，不声明就没有任何保护，一次显存溢出就能拖垮同节点的其他任务。

第三，弹性策略上线前先关掉夜间缩容，观察一周实际负载曲线再开。根据历史数据反推阈值，比拍脑袋设定靠谱得多。

最后分享一个小技巧：调度器事件和沙箱销毁事件这两个数据源一定要保留足够长时间。排查智能体训练问题的时候，能把“任务为什么被杀死”和“节点当时发生了什么”对上，往往比看训练日志更快找到根因。这套基础设施一旦稳定跑起来，团队成员会慢慢忽略它的存在——在我看来，这恰恰是它成功的最好证明。