企业官网建设流程全解析

1. 为什么大规模智能体训练需要一套独立的沙箱基础设施

先说一个我去年反复纠结的问题：训练一个大规模智能体（Agent），到底需要什么？

很多人第一反应是“需要GPU、需要数据、需要算法”。没错，但当你真的把几十上百个智能体同时放出来、让它们去交互、去调用工具、去模拟环境里试错的时候，你会发现最棘手的问题根本不是模型本身的loss，而是训练过程本身的失控风险——某个智能体在环境里写出了无限循环，某个探索策略把共享数据写坏了，某个任务占用了全部显存导致整个训练队列雪崩。

这时候你需要的不只是“一台能跑训练的服务器”，而是一个能把每个智能体的运行环境彻底隔离、又能随时扩缩容的沙箱基础设施。这就是DSec（DeepSeek弹性计算，DeepSeek Elastic Compute）在这个项目里要解决的核心问题。

1.1 “训练”和“运行”是两件事

传统深度学习训练里，你训练的是一个静态网络，前向、反向、更新参数，整个过程封闭在训练脚本里。但智能体训练完全不同——智能体要在某个环境里持续行动：读状态、做决策、执行动作、观察回报，然后依据回报更新策略。这意味着训练过程变成了“训练程序 + 环境交互 + 外部工具调用”的组合。

环境交互天然带来不确定性。比如让智能体去操作一个模拟的浏览器，它可能触发奇怪的弹窗；让智能体去写代码解决一个编程任务，它可能生成一个fork炸弹；让智能体互相博弈，它们可能演化出意想不到的协作或对抗策略。这些行为如果在裸机或普通容器里跑，影响半径是整个训练集群。

所以DSec在设计时，第一原则就是：每个智能体的训练过程必须在独立沙箱中执行，沙箱之间、沙箱与宿主机之间必须有明确的安全边界。这不是“锦上添花”，而是大规模并行训练能持续跑下去的前提。

1.2 智能体的失控半径：沙箱为什么是刚需

我把智能体训练中可能出现的“事故”分成几类，每一类都对应一个沙箱必须提供的保障：

单独看每一类，可能都“概率不高”，但大规模训练时，低概率事件 × 成千上万个并行实例 = 一定会发生的事件。沙箱的价值不是阻止所有异常（实际上你也阻止不了），而是把异常的爆炸半径压缩到一个可回收的单元里：坏了就弃掉，重新拉一个实例继续训练。

1.3 DSec在训练链路中的位置

DSec不是一个新的深度学习框架，也不是替代Kubernetes的调度平台，它处在两者之间：往下管算力资源，往上管训练任务。具体来说，一条典型的训练链路是这样跑的：

• 训练框架（如基于PyTorch的强化学习框架）负责模型参数更新和策略优化；
• 训练工作流（如按episode采样的数据流水线）会拆出大量并行的子任务；
• 每个子任务需要独立的“环境”——这个环境里有仿真器、有工具库、有临时文件系统；
• DSec负责把“环境”实例化为一组沙箱，分发给底层的算力节点，并保证它们在执行期间被正确隔离、可观测、结束后能干净回收。

从使用者的视角看，DSec暴露的接口很简洁：“给我500个沙箱，运行这套镜像，每个沙箱跑完这段代码后返回结果。”至于这500个沙箱怎么分布、怎么扩容、怎么保证不互相干扰，是DSec内部的事。

2. DSec的总体架构：四层设计思路

DSec的架构我习惯拆成四层来看：控制面、资源池、沙箱运行时、任务编排。四层各司其职，很多设计决策都是在落地过程中被真实需求逼出来的。

2.1 控制面与数据面分离

DSec整体沿用了控制面/数据面分离的思路。控制面是一个无状态的API服务集群，负责接收训练团队的任务请求、维护沙箱状态机、下发调度决策；数据面是分布在各个物理节点上的沙箱运行时，负责真正拉起沙箱、执行用户代码、上报心跳和指标。

这样做的好处有两个。第一，控制面故障不会直接杀掉正在运行的训练任务——数据面即使短暂失联，沙箱内的训练进程依然可以继续跑，恢复心跳后再补报状态。第二，控制面可以独立水平扩展，当大批训练任务同时提交时，不会因为控制面单点瓶颈而拖垮整个集群。

实际项目中我把控制面拆成了三个子服务：任务网关（接收请求、做鉴权和配额校验）、状态管理（维护沙箱生命周期）、调度器（决定沙箱放到哪个节点）。三个子服务之间通过消息队列解耦，任务高峰时可以单独扩容调度器实例数。

2.2 弹性资源池：CPU/GPU混部与突发扩缩容

训练任务对资源的需求很不均匀。有的任务要长时间占用GPU做模型推理（比如智能体策略的在线评估），有的任务只吃CPU（比如跑一个模拟环境的前几步），还有一些任务内存敏感（比如加载大型知识库做检索增强）。

DSec的资源池设计上允许CPU和GPU混部：一台物理机上既可以跑纯CPU沙箱，也可以跑需要GPU的沙箱，通过调度器做资源切分。这样做的好处是资源利用率显著提升——否则纯CPU任务和纯GPU任务分开部署，彼此的空闲资源无法共享，集群整体利用率往往只有30%-40%，混部后可以提升到60%以上。

弹性方面，DSec支持两层扩缩容：

• 节点级弹性：当资源池整体不足时，自动从云侧拉起新的物理节点加入集群；
• 沙箱级弹性：单个训练任务内部的并行度可以动态调整，比如一个采样任务发现当前吞吐不够，就请求把沙箱实例数从100扩到200。

沙箱级弹性是训练场景特有需求。强化学习里有一个经典矛盾：评估一个策略需要足够的采样量，但采样量需求在训练过程中是动态变化的——前期策略变化快，需要少采样多更新；后期策略趋于收敛，需要多采样细评估。固定资源跑会浪费不少算力，动态扩缩容能把算力花在刀刃上。

2.3 沙箱隔离：微虚机+可写镜像层

沙箱的隔离级别是整个项目里争论最多的点。一开始我倾向于用容器（containerd+Docker镜像），理由是启停快、生态成熟。但实际测试下来，容器的隔离强度对智能体训练场景偏弱：内核是共享的，某个沙箱里的智能体如果通过系统调用攻击内核漏洞，可能影响整个节点上的所有沙箱。

后面我们换成了微虚机方案（microVM）：每个沙箱运行在一个独立的轻量级虚拟机里，有独立内核，与宿主机之间通过硬件虚拟化隔离。微虚机相比传统虚拟机的优势是启动快——冷启动大约200-500ms，和容器启动时间差距已经不大，但隔离强度高了一个数量级。

于是DSec的沙箱运行时结构变成了这样：

• 底层用微虚机提供内核级隔离；
• 沙箱内跑一个极简的init进程，负责拉起用户指定的训练命令；
• 根文件系统来自只读的镜像层，每个沙箱额外挂载一个可写数据卷（用于保存训练中间结果）；
• GPU通过直通方式绑定给需要的沙箱，确保显存隔离。

2.4 任务编排：从“起一个容器”到“编排一场实验”

如果用一句话概括DSec和普通容器平台的差别，那就是：普通容器平台编排的是“进程”，DSec编排的是“一场实验的实验组和对照组”。

训练团队提交的往往不是一个沙箱请求，而是一整套实验方案。比如“跑3组不同的超参数，每组10个并行样本，中间需要对前200个episode做一次模型热更新”。DSec的任务编排层会把这些需求解析成一张任务图：哪些沙箱先启动、哪些沙箱需要共享同一份模型参数、哪些沙箱之间需要同步状态、最终结果汇总到哪里。

我见过很多平台把这一步做得过重，硬要用有向无环图描述所有可能，结果用户上手成本极高。DSec的取舍是：只支持三种基本关联关系——并行（一组沙箱互不依赖）、聚合（多个沙箱结果汇总到一个节点）、广播（一个模型参数同时下发到多个沙箱）。三种关系组合起来足以覆盖绝大多数智能体训练场景，但用户的心智负担小得多。

3. 智能体训练场景下的弹性计算实现细节

弹性计算听起来很美好，落地时全是细节。我挑几个最影响实际效果的实现点展开讲讲。

3.1 弹性伸缩的判断依据：谁来决定扩缩容

扩缩容不能靠人拍脑袋，得有自动化的判断依据。DSec里引入了三个核心指标：

• 任务队列深度：每个训练任务尚未分配的待执行样本数，队列持续积压说明算力不够；
• 沙箱平均利用率：CPU/GPU/内存的实时利用率，长时间低于阈值说明资源过剩；
• 采样完成时延：从“发出一个采样请求”到“拿到采样结果”的耗时，这是最有业务说服力的指标。

调度器会综合这三个指标做滚动评估，比如每30秒评估一次，当“队列深度超过阈值且平均利用率高于80%”持续3个评估周期，就触发扩容；当“队列深度接近0且利用率低于40%”持续5个评估周期，就触发缩容。

不同任务的扩缩容策略差异很大。有的任务希望激进的扩容（多占资源快速出结果），有的任务预算有限希望保守扩张。DSec允许每个任务设置自己的弹性策略档位——激进、均衡、保守——调度器根据档位调整触发的阈值。

3.2 断点续训与沙箱快照：弹性的地基

弹性伸缩的前提是沙箱可以被随时创建和销毁，而销毁不丢状态。这句话说起来简单，做起来要解决两个问题：模型状态怎么保存和环境状态怎么保存。

模型状态相对好办——训练框架本身就有checkpoint机制，周期性地把模型权重存到共享存储。DSec要做的只是保证沙箱在销毁前把最后一次checkpoint刷盘完成，并且重调度时能拿到最新的checkpoint。

环境状态就麻烦得多。很多智能体任务的环境是有状态的：模拟器跑到了第1000个step，环境内部有大量中间变量，如果沙箱销毁后重新拉一个，环境得从头开始跑，前面1000步的计算全部浪费。DSec的做法是提供沙箱快照（snapshot）：在预定检查点对沙箱的整个磁盘做增量快照，随后新沙箱可以从快照恢复，而不是从镜像冷启动。

快照的频率是调优的关键。太频繁则快照本身消耗大量磁盘IO；太稀疏则恢复时需要回放的时间太长。我目前采用的策略是自适应快照间隔——根据环境状态变化速度自动调整——状态变化快的任务自动加密快照频率，状态缓慢的任务降低频率节省开销。

3.3 任务亲和性调度：把沙箱调度到“对”的机器

分布式训练里最怕的一个问题是网络通信成为瓶颈，尤其在使用NCCL这类需要高带宽低延迟通信库的框架时。如果两个需要频繁交换梯度的沙箱被调度到不同机架甚至不同机房，训练速度会被通信延迟拖垮。

DSec的调度策略因此引入了亲和性概念：调度器会读取任务的通信模式描述——哪些沙箱之间需要高频通信（比如数据并行的rank间通信）、哪些只需要低频同步（比如周期性汇总指标）——然后据此决定放置策略。

高频通信的沙箱组尽量放到同一台物理机（通过共享内存或本地高速网络通信），退而求其次放到同一个机柜（万兆/无损网络），实在不行才跨机柜。低频同步的沙箱则不需要约束，可以充分打散以均衡资源。

这个策略在实际项目中帮了大忙。之前有一个跨机柜的分布式训练任务，训练吞吐一直上不去，排查半天发现NCCL在跨机柜通信时频繁超时重试。开启亲和性调度后，把8个通信密集的沙箱放到同一台物理机上，吞吐直接提升3倍。

3.4 资源计费与配额：让训练团队心里有数

大规模并行训练的算力成本是实打实的，如果团队对成本没有感知，很容易出现“100个实验同时在跑、80%的结果没有复用价值”的资源浪费。DSec在资源管理里内置了配额和计费模块，每个任务在提交时声明预算上限，执行过程中实时统计资源消耗，超过预算可以配置为自动降级（比如减少并行度）或自动终止。

配额管理的颗粒度我不建议做太细，否则运维成本高。DSec目前按三层配额：账号级（团队总量）、项目级（某个方向的总预算）、任务级（单次实验的支出上限）。三层之间逻辑是:账号配额分配给项目，项目配额分配给任务，任务结束时未消耗的配额自动归还。

让我补充说明一下弹性资源的计费模型设计。由于节点一部分来自自有物理机，一部分来自云侧弹性扩出来的机器，成本模型天然不同。DSec内部计费时，对两类资源采用不同的单价，并且在调度策略里优先用性价比高的自有资源，只有排队超过一定时间才启动云侧扩容。这样一来训练团队既能享受“算力随手可得”的弹性，又不会被云侧的高单价账单吓到。

4. 沙箱安全边界的设定：可执行、可观测、可回收

安全边界的设定是整个系统里最容易走极端的部分：有些人觉得沙箱越严越好，结果训练任务动辄被误杀；有些人觉得训练环境要开放，结果出了安全事故追悔莫及。我的经验是，安全边界必须围绕“可执行、可观测、可回收”三个原则来设计，而不是一味追求隔离强度。

4.1 沙箱逃逸的典型路径与封堵手段

先说说沙箱逃逸的几条常见路径，这决定了我们必须在哪些层面设防。

第一条路径是内核漏洞利用。沙箱内的代码如果拿到了内核漏洞的exploit，可以通过系统调用直接攻击宿主机。微虚机方案天然封住了这条路——每个沙箱有独立内核，沙箱内攻击者控制的只是自己的虚拟机，很难穿透硬件虚拟化边界触达宿主机。

第二条路径是资源耗尽型逃逸。恶意的或失控的智能体可能持续分配内存、创建进程、占用文件句柄，最终拖垮宿主机上的其他沙箱。DSec在微虚机层面配置了严格的资源限制：CPU、内存、磁盘IO、进程数、线程数全部有上限，一旦超限直接冻结并回收沙箱。

第三条路径是数据越权。智能体可能在训练过程中尝试读取宿主机的敏感信息，比如挂载点、环境变量、内核模块列表。我们的策略是：沙箱内只暴露最低限度的系统信息，所有非必要的系统设备（如磁盘设备节点）一律隐藏，网络接口只保留一个虚拟网卡。

4.2 网络策略：白名单出网与内部服务访问

训练任务对网络的需求很复杂，但安全策略必须简单。DSec默认的网络策略是全拒绝：沙箱启动时没有任何对外网络权限，用户必须在任务描述里显式声明需要访问的服务列表。

声明的方式是定义目标服务的域名或IP+端口，DSec会据此生成网络白名单规则。比如一个任务需要访问内部的对象存储服务和模型服务，就在任务描述里声明这两个地址。与常见做法不同的是，DSec的网络白名单规则会在部署层面下发到宿主机防火墙，而不是在微虚机内部做，这样可以避免沙箱内的智能体篡改自身网络规则。

当然，训练中有一个特殊情况——沙箱之间需要通信（比如分布式的多个rank之间）。我们设计了“租户内互访”的白名单机制：同一个任务组里创建的所有沙箱默认可以互通，但不同任务的沙箱之间严格隔离。这样既满足了分布式训练需求，又防止跨任务的恶意探测。

4.3 可观测性：日志、指标、链路三位一体

沙箱内部发生什么，控制面必须看得见。DSec在每个沙箱内部内置了一个轻量级的观测代理，负责三件事：采集日志、上报指标、转发链路追踪数据。

日志采集要注意容量问题。大规模训练时，几百个沙箱同时输出日志，日志量很容易达到每秒几十MB。直接全量收集既费存储又费带宽。DSec的日志模块支持两级采样：默认只收集WARNING级别以上的日志和业务自定义的关键事件；DEBUG级别的日志仅在任务调试模式下才全量收集，且设置单沙箱日志大小上限，超限后自动滚动丢弃。

指标方面，最核心的是资源利用率、任务进度、错误率三个维度。资源利用率用于弹性伸缩判断，任务进度用于给训练团队展示“当前跑到第几个episode了、预计还要多久”，错误率用于异常告警。链路追踪则用于定位分布式训练中的通信瓶颈，我会基于全链路数据还原一次训练请求从检测环境到输出结果的完整调用链。

4.4 生命周期强制回收：防止僵尸沙箱

训练任务结束后忘记清理沙箱，是运维上最常见却又最头疼的问题。一个沙箱如果一直在跑，就会持续占用资源，而且因为训练脚本已经退出，它只是一台“空转”的虚拟机，纯浪费。

DSec在生命周期管理上采用主动回收+强制兜底双机制。主动回收是任务正常结束时，编排层调用接口销毁所有关联沙箱；强制兜底则是一个巡检服务，每5分钟扫描一遍所有沙箱的状态，发现满足以下任一条件的沙箱就强制回收：

• 超过任务声明的最大运行时长；
• 超过30分钟没有心跳上报；
• 资源利用率持续24小时低于1%（疑似闲置）。

实际落地时发现，有些训练任务确实需要长时间运行，强制回收容易误杀。所以强制回收前会先发告警，给用户一个延长时限的窗口。但如果用户在窗口内没有响应，系统依然会执行回收。毕竟，资源浪费在整个集群层面是不可接受的。

5. 一次真实的大规模训练实验：从配额申请到结果回收

前面讲的都是设计理念，这一节我完整复盘一次实战——用DSec跑一个分布式强化学习实验，训练一个智能体学会在复杂环境里完成多步任务。整个过程涵盖了配额申请、镜像定制、扩容调度、结果回收等环节。

5.1 背景与目标

这个实验的目标是验证一个多智能体协作算法：多个智能体需要共享一个环境，通过协作完成一个长期任务（比如合作搬运箱子）。算法层面需要跑大量并行环境采样，然后每隔一定的episode集中训练策略网络。

实验对资源的需求大致是：每个采样worker需要2个CPU核+4GB内存，总计需要512个采样worker；另外需要8个GPU卡用来跑策略训练；还有一个参数服务器节点负责参数聚合和下发。总体算下来需要约1024核CPU、2TB内存、8张GPU卡。

如果用一台台裸机去分配资源，光准备环境就得一整天。DSec上配置了一套容器镜像，里面预装了仿真环境、训练框架和依赖库，整个流程跑下来只花了一个小时就把所有资源就绪了。

5.2 实验准备：镜像定制与数据集挂载

第一步是定制沙箱镜像。我们基于基础镜像追加了几层：

• 仿真环境层：安装模拟器及其Python绑定；
• 训练框架层：安装强化学习训练库；
• 工具链层：安装调试工具和性能分析工具；
• 启动脚本层：封装“沙箱启动后应该执行什么命令”的逻辑。

镜像构建好之后推送到内部镜像仓库，DSec会在调度沙箱时自动从仓库拉取。要提醒的是，镜像不要做得太大——每增加1GB镜像体积，500个沙箱冷启动时就要多消耗500GB的网络传输。我们的最终镜像控制在2GB左右，包含所有必要的库，但不包含任何数据文件。

数据集和大文件不放进镜像，通过共享存储挂载到沙箱内。DSec在沙箱启动时会自动挂载用户指定的数据卷，路径在镜像内约定好（比如/data）。这样做的好处是：数据更新不需要重新构建镜像，沙箱销毁重拉时也不重复传输数据。

5.3 运行过程中的扩容与调度

实验运行到第30分钟时，采样队列开始积压。原因是环境模拟的速度比预期慢，512个采样worker的吞吐不够支撑训练节奏。策略上我配置的是“均衡”档位，调度器感知到队列深度超过阈值后，自动把worker数量从512扩容到768。

扩容过程本身对训练无感：新沙箱从镜像冷启动、挂载同一个数据卷、从最新的参数服务器拉取模型参数、加入采样任务池。整个扩容从触发到新worker产出第一个样本，大约花了40秒。

这里有一个细节值得展开：扩容时新沙箱启动需要拉取最新的模型参数，如果参数文件很大，会有一段时间新worker在“等参数”。DSec做了一个预热机制——在扩容前先把参数文件预分发到目标节点的本地缓存中，沙箱启动后直接从缓存加载，把“等参数”时间压缩到毫秒级。

实验结束时，自动缩容把worker数回收到了200，空闲算力释放给其他任务使用。最终统计下来，整个实验实际消耗的资源比过量化配置节省了约35%。

5.4 结果回收与数据清理

训练结束后，每个沙箱都会产生中间数据：采样轨迹、环境状态、奖励曲线等。DSec在任务终结时会做一个结果回收动作：

• 把沙箱数据卷中指定的输出目录（如/output）同步到持久化存储中；
• 把关键指标（训练耗时、资源消耗、吞吐曲线）汇总成一份任务报告；
• 销毁所有沙箱，释放算力和存储空间；
• 数据卷做安全擦除，避免敏感信息残留。

数据清理这一步不能省。训练数据里可能包含环境交互中的敏感内容，如果沙箱磁盘被后续任务复用时泄露，会引发很大问题。DSec的默认策略是：任务结束后数据卷立即销毁并在物理层做TRIM擦除；如果需要保留数据用于后续分析，则显式拷贝到受控的持久化存储中，并设置保留期限。

6. 我在落地DSec过程中踩过的坑

每一个看起来顺理成章的设计，背后都经历过翻车。我挑几个最典型的坑出来分享，希望能帮你绕开。

6.1 镜像仓库成为性能瓶颈

第一次大规模跑的时候就翻车了——同时拉起数百个沙箱，所有节点同时从镜像仓库拉取镜像，结果镜像仓库网络带宽被打满，部分节点拉取超时，训练任务迟迟无法启动。

后来做了两个改进。第一是镜像预拉取：调度器在决策放置沙箱时，会先检查目标节点本地是否已有该镜像的缓存层，没有则提前触发拉取；第二是镜像分发网络：在多个机房部署镜像缓存节点，节点之间使用内部高速链路同步镜像层，沙箱启动时优先从最近的缓存节点拉取。

另外一个教训是：镜像最好是分层构建，公共层单独打标签。比如基础环境层（Python、CUDA）作为公共层保持不变，训练依赖层和业务代码层作为独立层更新。这样沙箱升级时只需要增量拉取更新层，而不是整体重拉。

6.2 沙箱时钟漂移导致训练评估失真

分布式训练对时间同步敏感，但微虚机的时钟在频繁暂停/恢复后会漂移。我们遇到过一个诡异的问题：奖励曲线在某个时间点后突然剧烈抖动，怎么调参数都没用，最后发现是沙箱内时间与全局时间严重偏差，导致强化学习的回报计算窗口错乱了。

解决办法是每台宿主机统一配置时间同步服务，并要求沙箱内禁止修改系统时间。DSec在沙箱创建时设定了只读的时钟设备，沙箱内进程无法通过clock_settime系统调用改动时间，只能跟随宿主机时间。这个改动很微小，但直接解决了训练稳定性的大问题。

6.3 网络策略过于严格导致分布式训练NCCL超时

网络白名单机制最初设计得很严格，每个沙箱只能访问声明过的服务。结果分布式训练跑起来之后，NCCL初始化频繁超时，一开始我以为是网络带宽问题，查了半天才意识到：NCCL在初始化时会尝试建立多个通信端点，还会探测本机所有IP地址做绑定，有些探测连接被防火墙拦截，导致通信初始化卡住。

解决方式是，在创建任务时区分两种网络模式：训练模式和常规模式。训练模式下，同一任务组内的沙箱之间不做白名单限制，全互通；对外访问仍然走白名单。这个折中既满足了分布式通信的自由度，又保留了出网限制的安全价值。

6.4 快照机制与数据一致性的纠缠

做沙箱快照时，最初我们直接对磁盘做热快照，完全没有考虑文件系统一致性，结果恢复出来的环境经常是损坏的——模拟器把状态写到一半被打断，文件处于半写状态，恢复后模拟器直接崩溃。

后来我们调整了快照流程，加入应用层一致点概念：业务代码可以显式标记“当前环境状态是完整的，可以安全快照”，DSec只在这些一致点触发快照。如果没有显式标记，则退化为对文件系统做冻结快照（frozen snapshot），并通知业务进程先缓存住写入操作，待快照完成后再继续。

这个改进实际上是把“快照”从纯基础设施行为变成了“基础设施+业务协同”的行为，牺牲了一点透明性，但稳定性和恢复准确率大幅提升。

7. DSec后续演进方向

DSec目前已经稳定支撑了多个团队的大规模智能体训练任务，但离我理想中的形态还有不少距离。后续的演进我主要关注四个方向。

7.1 异构算力纳管

现在主要管理的是CPU和GPU资源，但随着智能体训练场景多样化，NPU、FPGA等异构算力会越来越多。异构算力有个核心难题——不同的芯片有各自的编程模型和驱动依赖，如何在沙箱层面统一封装、让训练任务无感地调度到不同算力上，是DSec下一步要解决的关键问题。

我的初步设想是引入“算力抽象层”，把不同芯片抽象成统一的“计算设备”接口，沙箱内只面对抽象接口，底层由DSec按实际硬件适配驱动。

7.2 沙箱内自动调参

训练实验的调参是个耗时耗力的过程。目前DSec已经能提供任务级别的资源扩缩容，下一步希望把“参数调优”也变成基础设施能力：多个沙箱并行跑不同超参数组合，自动收集效果指标并做贝叶斯优化，搜索到更好的参数后自动滚动更新到训练主进程中。这相当于把人工调参变成平台特性。

7.3 跨地域调度

目前的资源调度以单地域为主，所有沙箱都在同一个机房内。跨地域的诉求主要来自两类场景：一是数据合规要求数据不能出特定地域，需要把沙箱调度到数据所在地；二是某些地域的算力价格更低，希望把非敏感的低优先级任务调度到低价地域执行。

跨地域调度的挑战在于网络时延和带宽成本。我倾向于用分层调度来缓解：先做地域级调度，再在地域内部做节点级调度。跨地域通信通过专线连接，并且只有低频同步的任务才允许跨地域分布。

7.4 成本感知的弹性伸缩

现在的弹性伸缩主要看性能指标——队列深度、利用率、时延——对成本感知不足。下一步希望把“单位有效样本的算力成本”纳入伸缩决策：当成本超过阈值时，优先缩减那些边际收益最低的任务并行度；当预算有余量时，自动加大小任务并发量以加速迭代。

这一步做好的话，训练团队在DSec上的体验会从“资源够不够用”升级到“用最少的钱跑最快的实验”。

我在实际运行DSec的这段时间里，最大的感受是：基础设施的弹性最终要服务到“人”的弹性上——让研究员不再担心资源瓶颈和失控风险，让运维不再疲于救火和处理僵尸资源。DSec这个名字里的“弹性”，不只是算力的弹性，更是整个训练流程的弹性：想快就扩，想省就缩，出事能兜底，跑完能收干净。这套思路，对任何想做大规：模智能体训练的团队来说，可能都值得参考。