有些人一上来就问“DSec能跑多大集群”但真正在智能体训练这条线上摸爬过的人多半会先问另一句你的算力池到底“弹”得起来吗跑智能体任务时环境脏了、资源又被占死谁能兜底今天想聊的DeepSeek弹性计算DSec就是冲着这两个问题去的——一套面向大规模高效智能体训练的沙箱基础设施。它不解决模型结构怎么设计、奖励函数怎么收敛它解决的是你在训练过程中迟早要撞上的那些基础设施层面的硬茬子租户之间的资源争抢、训练环境互相污染、任务排队策略太蠢导致GPU空转以及出问题时连锅都端了。这个项目适合谁看如果你正在用DeepSeek系模型做智能体训练比如强化学习跑一套具身控制策略或者大规模生成式智能体做行为仿真的数据生产如果你所在的团队已经被“每个研究员各占一台GPU机器谁都不肯放”这种资源私有化问题折磨过又或者你只是想找一套能落地到内网服务器、本地化部署、并且能跟现有harness类工具链兼容的隔离训练底座——那么DSec这套思路值得你花十几分钟过一遍。下面我会按我实际搭建、调整、踩坑的顺序把整个DSec的设计思路、核心模块、部署实操、训练场景工作流以及我在本地和集群环境里遇到过的典型问题完整讲一遍。1. 内容整体设计与思路拆解1.1 为什么智能体训练需要“沙箱弹性”这对组合先说沙箱。智能体训练和普通模型训练有个非常不一样的地方训练过程面对的是一个闭环——智能体产生动作环境给反馈策略随之更新。这个环境往往不是一个干净的张量计算图而是一个完整的软件生态。比如你用Python写了一个仿真器里面要调物理引擎、渲染后端、感知模型接口甚至要启一个游戏进程。这类环境依赖庞杂最怕的就是版本冲突。我见过不止一次这种场面研究员A在共享机器上往site-packages里装了一个新版numpy第二天研究员B跑训练时IO读取速度直接变成原来的三分之一损失曲线诡异震荡。排查半天最后发现是BLAS库被顶掉了。如果是智能体训练这种环境污染更致命——因为你的动作采样本身带有随机性出了问题你根本分不清是策略不行还是环境被改坏了。再说弹性。智能体训练的资源消耗曲线极其不规则。训练早期可能要跑几千条探索轨迹simulation worker疯狂占CPU训练中期策略开始收敛评估任务又需要大量GPU做批量推理中间一旦加了reward shaping或者切换了环境配置负载又会突变。静态资源池在这种负载下要么高峰期排队排到天荒地老要么低峰期GPU利用率低到个位数电费和折旧成本白白烧掉。DSec最核心的思路就是把“沙箱”和“弹性”这两件事揉成一个整体来设计。每个训练任务的运行环境Python解释器、依赖库、系统库、缓存目录都被冻结成一个独立沙箱镜像互不可见而沙箱的宿主是动态伸缩的计算节点池——弹性调度器根据队列水位、任务优先级、节点空闲资源实时扩容和缩容。这样既保证了“你的环境炸了不连累别人”也保证了“人多的时候能加机器人少的时候能关机器”。1.2 从传统容器方案到DSec到底改了什么可能有人会问这不就是Kubernetes加容器镜像吗确实思路源头相近但你真把K8s原封不动搬到智能体训练场景里会撞上一堆别扭的点。第一个别扭是调度粒度。K8s原生调度器理解的是Pod和资源请求但智能体训练任务有自己的一套生命周期一个任务可能要动态拉起几十个worker角色的实例中途角色还会变化比如某个eval worker跑挂了需要一个新worker接管它的评估队列。DSec在调度层做了一层面向“训练任务”的抽象把任务看成是一个由若干角色实例组成的拓扑而不是一堆孤立的Pod。第二个别扭是数据集和checkpoint的共享方式。训练过程中所有worker需要读取同一份数据集模型参数也要频繁同步。传统容器方案下你得费劲地维护共享存储的挂载和权限。DSec直接把共享存储卷作为沙箱的一等公民——每个沙箱启动时挂载一个只读数据卷和一个可写的workspace卷缓存目录单独用tmpfs或本地SSD一套组合下来IO路径非常清楚不容易踩到跨节点存储锁的坑。第三个别扭是环境回收。K8s的Pod退出后会清理容器但训练任务失败时研究人员最需要的恰恰是“保留现场”——把日志、环境快照、甚至崩溃前的临时文件留下来用于事后排查。DSec在沙箱销毁前会统一执行一次“犯罪现场固定”流程把关键产物归档到指定区域再释放资源。所以你可以把DSec理解为底层还是容器技术打底但在调度器、存储挂载、生命周期回调这些层面针对智能体训练重新做了一遍深度适配。它不是一个通用的“跑任何东西”的平台而是一个“专门高效地跑智能体训练”的专门设施。2. 核心组件拆解与关键机制解析2.1 控制面与数据面的分离设计DSec在架构上有一个很清晰的切分叫“控制面与数据面分离”。控制面跑的是调度器、租户配额管理、任务生命周期管理和元数据库数据面跑的是沙箱实例、缓存服务、对象存储网关。两者之间只通过一套定义好的API通信不允许数据面的节点直接访问控制面的内部数据库。这个设计带来的直接好处是控制面可以很方便地做成高可用。我们把元数据库放在独立节点调度器至少跑两个实例主备切换时数据面沙箱不会中断。实际运维中控制面节点重启这类事几乎不需要挑时间窗口因为数据面根本不依赖控制面进程的常驻存活——沙箱一旦被拉起它的日志上报和checkpoint写入都是异步进行的控制面短暂不可用不阻塞训练继续推进。API层面DSec暴露的核心接口数量并不多但每个接口的语义都专门为训练场景打磨过submit_task提交一个训练任务描述角色的数量、资源规格、镜像、依赖的数据集和共享卷。scale_task在任务运行期动态调整某个角色的实例数量。attach_workspace把某个交互式调试会话挂到一个运行中的沙箱上用于人工介入排查。freeze_task冻结任务的全部现场日志、环境变量、临时文件然后回收资源。2.2 沙箱的含义不止是容器隔离一提到沙箱很多人第一反应就是“namespace隔离、cgroup限额”但DSec里的沙箱有更广的含义。每次训练任务分配到的那个运行环境不仅是一个隔离的容器还包含了一套完整的初始化协议和生命周期契约。初始化协议规定了三件事镜像从哪里拉取、数据卷从哪里挂载、启动后必须先执行什么动作。常见约定是沙箱启动后的第一个动作就是向控制面注册心跳并把自身角色的元信息比如worker编号、分配到的GPU设备列表写入workspace下约定的位置。这个约定非常有用——训练代码里通过读取这个位置来感知“自己是谁、该干什么”可以省掉一大堆环境变量传参的脏活。生命周期契约则是说DSec允许沙箱被“暂停”和“恢复”靠cgroup freeze和相关处理实现并不是完整的虚拟机快照。在弹性收缩时调度器会把低优先级任务的位置让给高优先级任务低优先级任务的沙箱进入暂停态等资源空出来再恢复。对智能体训练来说这个机制尤其合适——因为训练进程本身就经常要等待环境交互返回暂停造成的时延影响比普通在线服务小得多代价远低于干脆杀掉任务重新恢复checkpoint。2.3 调度器最棘手的部分容量水位与抢占策略调度器是整个DSec里我花时间最多的地方。因为它在做决策时需要平衡的目标实在太多了用户提交的优先级、队列的等待时长、节点碎片资源、任务自身的扩缩容请求还有冷/热数据的位置亲和性。调度策略里我重点说两个机制。一个是容量水位capacity watermark。DSec把每个计算节点定义出一个“安全水位”和“极限水位”。安全水位以下调度器可以自由下单超过安全水位但低于极限水位只能安排低优任务或允许“可暂停”型任务达到极限水位就停止对该节点的调度并触发一次“压缩”。压缩时优先把已暂停的沙箱换机腾出连续的空闲资源块。另一个是抢占策略。高优先级任务提交时如果等待超过一定阈值调度器会启动抢占流程。被抢占的不是随机的任务而是从“可抢占池”里挑——明确声明允许被抢占的租户任务才会进这个池子。这种做法让不同团队可以按自己的节奏决定“要不要牺牲自己的排队进度去保护别人家的任务”比一刀切的抢占策略灵活多了。实际运行下来因为抢占而导致的checkpoint回退频率很低因为每次抢占前调度器会强制沙箱做一次轻量级状态同步。2.4 存储层一个让训练读写速度直接翻倍的设计存储是沙箱基础设施最容易翻车的地方。智能体训练数据有个特点——大量小文件、重复读取、随机访问。如果你的沙箱直接从网络文件系统读取训练数据你很快就会在inode和元数据操作上耗尽性能。DSec的存储设计分了四层这是很多类似方案没有做细致的部分数据集只读层主副本放在对象存储常用数据集在各节点本地SSD上有缓存副本。沙箱读取到的是本地缓存副本首次读取时才会触发缓存填充。启动任务时可以指定数据集预取列表调度时把任务尽量调度到预取完成度高的节点上可以大大减少训练启动阶段的“空转等待”。工作区可写层每个沙箱挂一个可写的workspace卷容量按任务配额限制。训练脚本、中间产物、日志都在这里任务结束后按策略清理或归档。临时高速层沙箱内的/tmp和部分缓存目录被映射到节点本地tmpfs。有状态的环境仿真程序如果频繁写临时的渲染缓存或物理缓存这种做法的读写性能能比普通磁盘高出几个量级。日志流与checkpoint旁路层沙箱日志实时通过sidecar转发到集中日志服务checkpoint则直接写入对象存储不经过workspace卷。这样可以保证即使workspace被误删或损坏模型参数也不会丢。这套分层设计真正解决了我在训练中最头疼的问题之前跑一个需要频繁保存频率较高的仿真数据的任务网络存储时常成为瓶颈现在tmpfs吸收掉绝大部分瞬时写放大训练稳定性和可复现性都有了明显改善。3. 实操过程与核心环节实现3.1 从单机demo到小集群我的搭建路径DSec不是那种你拿个安装脚本一键跑起来就完事的软件它更像一套需要根据你的训练场景做裁剪的“半成品框架”。我实际搭建时分了三步走。第一步单机demo版。在一台开发机上用docker-compose把控制面核心组件调度器、元数据库、API网关跑起来数据面只开一个本地节点。这一步目的是验证整体链路通不通理解清楚“提交任务→调度→沙箱启动→心跳上报→日志回传”这几个核心动作的日志长什么样。这个阶段我建议你务必跑通一个最小镜像——哪怕你的训练脚本只有一句print加一个torch.cuda.is_available()把生命周期跑通比跑通复杂任务重要得多。第二步内网小集群。用三台机器搭一个最小集群一个控制节点加两个计算节点计算节点上不要跑任何其他业务专门做沙箱宿主。这一步要重点验证的是镜像分发网络内网能不能拉通、幸存的存储卷挂载权限是否正常、多沙箱并发时控制面压力是否可接受。如果你跟我一样是内网离线环境镜像仓库必须在局域网内部署一份并临时关闭或绕开TLS校验否则一堆沙箱同时启动时镜像拉取会成为明显的瓶颈。第三步接调度策略调参。这一步才是DSec真正区别于“跑步容器”的地方。你需要根据自己的任务优先级模型设置好队列权重、抢占开关、安全水位阈值。我给自己的集群设的是短任务评估类和长任务训练类分队列长任务队列允许短任务在安全水位以上共享节点但在水位达到极限且短任务等待超时后长任务才有权触发压缩。3.2 沙箱镜像制作与基础配置实例镜像制作是DSec上手时最需要仔细的环节做得不好后面全是坑。我给出一个最小可用的基础配置示例按你的训练框架往里面加依赖即可。# dsec-base.env DSEC_ROLEworker DSEC_TASK_IDtask_20250101_001 DSEC_WS_PATH/workspace DSEC_DATA_PATH/dataset DSEC_CACHE_PATH/tmp/dsec_cache DSEC_HB_INTERVAL15 DSEC_HB_ENDPOINThttp://ctrl-plane:8080/heartbeat启动脚本的关键部分如下注意每个沙箱启动后必须先注册心跳再开始干活#!/bin/bash # 等待workspace和dataset挂载完成 for i in $(seq 1 30); do if [ -d ${DSEC_WS_PATH} ] [ -d ${DSEC_DATA_PATH} ]; then break fi sleep 1 done # 向控制面注册心跳带角色信息和GPU信息 GPU_IDS$(nvidia-smi --query-gpuindex --formatcsv,noheader | tr \n , | sed s/,$//) curl -s -X POST ${DSEC_HB_ENDPOINT} \ -H Content-Type: application/json \ -d {\task_id\: \${DSEC_TASK_ID}\, \role\: \${DSEC_ROLE}\, \gpu_ids\: \${GPU_IDS}\} \ -o /dev/null # 进入训练主程序 cd ${DSEC_WS_PATH} exec python entry.py这里有个我当时踩过的坑——在沙箱里做GPU设备枚举时千万不要直接用nvidia-smi看到的物理设备号去索引CUDA设备。因为多个沙箱共用同一GPU时容器内的设备编号映射会变。DSec的做法是通过控制面下发每个沙箱可用的物理GPU设备列表环境变量注入训练代码里用CUDA_VISIBLE_DEVICES来绑定。否则你以为自己在用卡0实际跑到了卡3上还会撞到别人的任务。3.3 提交一个真正的智能体训练任务下面是一个提交强化学习训练任务的示例。假设我们用PPO训练一个机器人走路的策略仿真环境要求每回合在沙箱内独占CPU和内存评估阶段则需要GPU推理。任务定义文件task_ppo_walk.yaml如下name: ppo_walk tenant: research_a priority: high queue: training roles: - role: trainer replicas: 1 resource: cpu: 8 mem: 32G gpu: 1 image: registry.internal/agent-sim/ppo-trainer:latest - role: sim replicas: 8 resource: cpu: 4 mem: 8G image: registry.internal/agent-sim/environment:latest data: - dataset://sim_data_v3 workspace_size: 200G checkpoint_interval: 600 auto_scale: sim: min: 4 max: 12 metric: queue_depth target: 64提交命令dsec submit -f task_ppo_walk.yaml这个任务提交后调度器做的事情你脑子里要有画面先查租户research_a的配额还剩多少再查哪个节点上有sim_data_v3的缓存副本然后安排trainer角色绑定GPUsim角色尽量与trainer在同一个高速内网段。关于auto_scale的配置我要多说一句。这个机制是DSec弹性能力最直接的体现。task_ppo_walk的sim角色在训练早期可能只有4个实例就够用因为动作还没收敛到有探索价值的区域训练中段探索轨迹需求陡增queue_depth指标飙升调度器会自动扩容到8个、甚至到上限12个训练后期策略收敛再自动缩回4个。整个过程不需要你半夜起来手动加任务副本这是我认为DSec最“香”的地方。3.4 资源伸缩背后的计算逻辑既然聊到弹性就把“扩容依据”讲透一点。在task_ppo_walk里metric: queue_depth表示的是sim角色内部“待仿真轨迹队列”的长度。这个队列是怎么算出来的训练器每轮采样会生成一批参数交给sim worker仿真千八百步然后回报轨迹给训练器算loss。如果sim worker速度跟不上训练器队列迅速变长说明并发不够如果队列长期为空说明sim worker闲置留着浪费。调度器每隔一段时间默认30秒检查队列深度按下面的口算逻辑做决策当前队列深度 64 目标队列深度 64 单实例处理能力 16 (仿真步/秒) 期望实例数 当前队列深度 / 单实例处理能力 ≈ 4 如果当前实例数(8) 期望实例数(4)且持续2个周期则缩容到4 如果当前队列深度持续高于目标值超过3个周期则扩容到下一档。这里的“持续N个周期”是为了防止抖动的。智能体训练队列长度波动剧烈是常态——某几秒因为环境加载慢而暴涨不代表真需要那么多并发。我建议在实际配置时把三个周期的观察窗口定为60到90秒不要设得太短否则你会发现沙箱数量像心电图一样来回跳。GPU训练侧的弹性更微妙。训练器进程本身一般不轻易动因为你不能随便把一个正在算梯度的进程挤走。但DSec支持的是把“评估角色”做成独立角色实例评估实例可以在训练间隙弹性拉起或释放。这样你在训练收敛后做大规模评估时不需要把训练资源整个扩大而是临时拉一批评估实例测完即释放成本和效率都是最优解。4. 面向智能体训练场景的工作流与实战效果4.1 典型工作流从调参到大规模验证我拿一次完整的具身智能体训练来串一遍DSec的实际工作流这样读者能直观感受到它跟传统“手动分配服务器”的区别。任务开始阶段研究员拿到一个环境更新版本——比如把仿真器的摩擦系数模型改了。他需要先在少量沙箱里验证环境是否正常这时候提交一个debug队列的短任务只申请1个sim实例和1个trainer实例镜像用最新代码构建。DSec把这个短任务调度到缓存了相应数据集的节点上。研究员通过attach_workspace直接附着进沙箱里交互调试改参数、跑单回合仿真、看物理反馈是否合理。调试通过后研究员正式提交training队列的任务。调度器把这个大任务散布到多个计算节点上每个sim沙箱都有自己的环境但它们共享同一份只读数据集和同一个workspace卷。训练过程中研究员可以随时查看训练器的日志流和loss曲线如果发现仿真速度过慢直接调用scale_task把sim实例从8扩到12不需要重启任何进程因为每个sim实例是无状态的、从消息队列拉任务。训练结束并验证策略后进入大规模评估阶段。这个阶段需要把几十个环境并行跑若干遍统计成功率指标。研究员提交一个eval队列的短任务申请大量短生命周期沙箱。由于评估任务耗时短且可抢占调度器会优先填满在训练任务水位之上的空闲资源甚至可能抢占一部分允许被抢占的低优先任务的空间。评估一结束这些沙箱被回收资源还给长任务。这套工作流跑顺之后团队里原本“占着一台机器不放”的习惯会慢慢消失——因为默认打开网页提交任务就够了不需要自己维护环境。剩下的机器可以作为共享弹性池整体利用起来。4.2 我实测的扩缩容和资源利用率数据在介绍效果前先说明这只是我个人的小规模实测机器是4台双路服务器、每台4张GPU没有很大规模。但趋势是能说明问题的。测试场景8个sim实例并发跑仿真训练器1个GPU实例同步更新策略。任务运行2个小时每30秒记录一次队列深度和实例数量。结果如下前20分钟探索阶段队列深度一直在 100 以上sim实例保持在8个满载。20到60分钟策略逐渐收敛仿真效率提升队列深度降到 50 左右调度器把sim实例缩容到5个。60到90分钟换了一组环境参数重新探索队列深度又回升到 80sim实例自动扩到7个。最后30分钟接近收敛sim实例缩到4个剩余算力让位给另一个团队提交的评估短任务。整段运行下来GPU的平均利用率一直在80%以上CPU利用率在中段短暂下降但很快被其他短任务填上。这跟之前“每个团队固定拿一台机器高峰期排队、低峰期闲置”的体验相比提升非常明显。4.3 多租户场景下的权限与资源边界如果你所在的团队不止一个小组多租户隔离这个点就相当重要。DSec的租户隔离不是简单的“我给每个租户固定若干台机器”而是基于配额和标签的软隔离。每个租户有独立的资源配额多少CPU、多少内存、多少GPU但实际可以借用到其他租户的空闲资源只要不突破配额上限。权限控制上镜像仓库按租户做命名空间隔离数据集读写权限在提交任务时统一校验workspace卷只对任务所属租户可见。训练代码层面DSec会注入租户ID和任务ID到环境变量中日志系统会按这两个维度做索引方便事后审计。我实际最喜欢的一点是attach_workspace这个操作默认只有任务提交者和管理员能执行避免了一个团队误入另一个团队正在调试的沙箱里把现场搞乱的尴尬场面。5. 常见问题与排查技巧实录5.1 harness插件装不上、启动报错怎么处理在DSec的沙箱里跑智能体训练时很多人习惯用harness这类工具编排任务和插件。但刚上手时最容易撞上的问题之一就是harness插件装上后根本不能启动或者启动报错。我遇到的报错信息五花八门但根因通常就那么几个。第一个常见根因是Python环境版本和插件要求的版本对不上。DSec基础镜像默认自带了Python环境和一套常用依赖为了稳定版本可能相对保守。而harness类插件往往是非常新的工具对Python版本要求很敏感。处理办法是在自定义镜像阶段就明确锁定版本尽量不要在沙箱起来之后再临时pip install。如果非要临时装也一定要在workspace里建虚拟环境而不是直接改全局site-packages。第二个根因是插件缓存目录权限问题。沙箱里的/root或$HOME目录有时是只读的或没有预期权限插件安装时往home下写配置文件就会失败。我在Windows主机上遇到过SetNamedSecurityInfoW failed (win32)这类报错换成Linux沙箱环境后就没再出现。如果你的沙箱宿主是Windows环境建议插件挂载目录显式设定为workspace下的子目录并提前建好避免安装器试图创建的安全上下文跟沙箱默认策略冲突。第三个根因是插件市场访问不到。内网环境里沙箱默认没有外网访问能力插件安装源如果指向公网必然失败。应对方式有两种离线插件包方式——提前下载好插件文件放到镜像里或workspace的某个目录里安装时指定本地路径或者内网代理方式——在沙箱内设置HTTP_PROXY/HTTPS_PROXY指向内网代理服务。5.2 沙箱启动后训练进程直接退出日志显示“无可用GPU”这个问题我刚开始也困惑了一阵。后来发现原因几乎总是出在任务定义里的GPU资源请求和实际宿主的GPU分配策略不一致。DSec的GPU分配逻辑不是简单看节点上有几张卡而是看“剩余可用卡数”。如果一个节点有4张卡其中2张已经分给其他沙箱那么只有物理编号3和4可用。但你的沙箱启动后nvidia驱动返回的设备编号可能还是0到3导致训练代码默认选择0号卡实际上抢占了别人已经用着的设备。解决办法分两步。第一步在任务定义里明确指定resource.gpu不要省略。DSec在分配沙箱时默认会预留这块资源并对沙箱内的CUDA_VISIBLE_DEVICES做改写。第二步在训练代码入口处强制用CUDA_VISIBLE_DEVICES环境变量初始化显卡而不是让框架自己枚举。很多训练框架支持用环境变量限定可见设备这能从根本上避开物理号和逻辑号错位的坑。5.3 数据读取慢得像蜗牛爬智能体训练的数据读取慢大部分时候不是磁盘本身慢而是小文件随机读的元数据开销太大。如果你发现沙箱内读取训练数据的速度远低于宿主机的速度先检查缓存层有没有命中。在DSec里数据集最好是单独打包成tar或parquet这类适合顺序读的格式不要几千个小文件散着放。如果数据集必须有小文件建议在构建DSec缓存时启用“预读合并”把同一目录下的小文件合并成大块之后缓存到本地SSD。还有一个容易忽略的点是首次读取时的缓存填充过程。新节点上没有数据集缓存第一批调度到这个节点上的任务会先经历一段“拉数据”的等待看起来就像数据读取卡死了。DSec通常会在任务启动时在日志里打一条cache fill started / finished的记录遇到“慢”先翻日志确认是不是在拉缓存。如果不想等可以提前用dsec cache preload命令把数据集预拉到指定节点但要注意这也会占用节点的存储空间量力而行。5.4 多租户下网络互访被拒或超时DSec的多租户沙箱默认是隔离网络跨沙箱互访需要显式授权。如果你在训练代码里试图让两个沙箱直接通过IP通信比如数据并行训练时用nccl会发现在某些网络插件下连接超时。处理方式有三种。第一优先使用DSec提供的服务发现机制通过任务名加角色名解析到同一任务内的一组沙箱地址而不是写死IP。第二对于必须跨租户协作的组件比如一个公共的仿真服务明确把该服务部署为独立任务并给它打一个“可被特定租户访问”的标签数据面网关会放行对应流量。第三如果通信量极大比如梯度同步建议使用专用的高性能网络接口而不是走通用网关这需要在任务定义里声明一个fast_network: true的选项。我踩过最大的一个坑是训练主节点和sim节点跨租户部署后传输一个10GB的演示数据集超时。后来发现DSec默认会给跨租户流量限速主节点拉数据时触发了限速阈值。处理就是调大该租户的egress_bps配额。具体数值根据自己的内网带宽和任务规模调就行别一上来就给极大限速否则网络很容易被打满影响其他正常任务。5.5 沙箱销毁时日志丢失任务结束后再想回去看当时的训练表现发现workspace被回收日志也没了。这多半是因为日志收集配置没做对。DSec的日志流默认会发给集中日志服务但也有不少训练日志是直接写文件而不是stdout的这类日志不经过日志流。我的习惯是在训练脚本里双击拦截重要指标用logger写到stdout会被sidecar抓走同时把长时间运行的详细日志写到workspace下的logs/目录并在任务定义里声明该目录为“必须归档”。这样任务正常结束时workspace的logs/会被归档到对象存储里需要时随时取回。如果任务是被强杀的归档流程会简化成只保存系统崩溃前最后写下的日志尾部——有总比没有好至少能知道死在哪一步。6. 写在最后的一点体会兜兜转转搞了这么久的基础设施我最大的一个体会是系统设计得再好如果大家不爱用、不会用最后还是废铁。DSec这套东西真正跑顺靠的不只是我把调度器和存储层调优了多少更重要的是让团队里的研究员感觉到“在这个平台上提交任务比自己占机器更省心”——环境不用自己配镜像统一管出问题随时attach进去debug资源还能弹性伸缩不被闲置。这种使用体验上的改变才是基础设施真正的价值所在。最后再分享一个小技巧不管你是只用单机还是小集群一定要在沙箱镜像里放一个/workspace/README.md的占位文件里面写清楚这套镜像的版本、已知限制、以及常用训练命令。当你的镜像越来越多、任务越来越杂的时候这个小文件能帮你省下大量翻旧账的时间。训练基础设施说到底是一门“让复杂变得可管理”的学问。祝各位的智能体项目越跑越顺。