66.9%的等待被砍掉：智能体训练卡在最便宜的容器上

“你最贵的GPU，常常在等最便宜的容器。”这是Nebius AI训练副总裁金迪（Di Jin）给出的判断。这家总部位于阿姆斯特丹的公司做了一次实验：在一个基于Terminal-Bench的工作负载上，调整路由、沙箱执行和批次组装方式后，一个256条轨迹批次的固定权重收集时间减少了66.9%。

需要说明的是，这个数字只衡量批次收集环节，不含训练器的前向、反向和优化器计算，也不等于完整训练速度的提升。但它指向的问题很具体：在智能体训练里，钱花在GPU上，时间却耗在等待上。

智能体必须先尝试任务、产出结果，模型才能从中学习。少数跑得慢的尝试会拖住下一次训练更新，跑这些任务的系统因此成为训练速度和成本的关键变量。金迪说，从预训练或监督微调转过来的团队，容易低估这套系统的工作量。

平均吞吐会掩盖长尾

轨迹生成本身往往占据一个训练步骤的大部分实际耗时，批处理、缓存管理和调度因此直接决定模型学得多快。金迪的建议是，把推理引擎当作后训练强化学习优化器的一部分来看待。

他提醒工程师，除了吞吐，还要测“到可训练批次的时间”。平均每秒token数会掩盖长尾：在同步批次里，最后一条轨迹没跑完，这一步就结束不了。智能体轨迹长度并不一致，多数很快完成，少数拖得很久，训练GPU就在等这几个掉队的。

陈旧数据不是敌人

用旧版本模型生成的数据来学习，存在一个权衡。金迪说，一定的策略滞后可以让生成和训练重叠，从而提高GPU效率，但安全与否取决于策略变了多少、训练算法如何处理这种差异。

他给出的解释是：完全同步的强化学习中，推理GPU在训练时等待，训练GPU在生成时等待；让生成使用落后一两次更新的权重，两边就能并行跑，多数大规模系统正是靠这种重叠拿到合理利用率。当困难任务的成功很罕见时，一条已经成功的轨迹即使稍旧也值得复用。

真正有害的是生成轨迹的策略与正在训练的策略偏离太远。有用的度量是散度，而不是给数据新旧设定一个通用步数上限。金迪的原话是：“陈旧不是敌人，未被度量的陈旧才是。”

对应的手段包括：做重要性采样修正，通常做截断以限制方差；丢弃或降权超过陈旧阈值的样本；跟踪生成策略与当前策略之间的散度。

环境就是新的数据

在金迪的经验里，数据和环境占据成功强化学习后训练的大部分工作，算法设计只占最小一块，基础设施则决定迭代快慢。“基础设施决定你能迭代多快，但模型真正学到什么，由你给它的任务、环境和奖励决定。”

对智能体而言，这意味着把注意力放在生成训练经验的环境上。监督微调用的是收集好的数据集；智能体强化学习里，模型通过与环境交互生成轨迹。可复现的容器、代码库、网站和带真实状态的API，能让模型学到的能力迁移到真实使用中。还需要可靠的验证器，以及难度合适的任务；模型变强后，任务集要刷新，否则任务饱和、不再产生学习信号。金迪的说法是：“构建环境就是新的数据整理。”

问题往往出在系统交接的地方。训练器、推理引擎、沙箱和验证器各自都能正常工作，故障却在接口处冒出来：模型可能钻验证器的空子，为并未完成目标的行为拿到奖励；沙箱也可能出错，污染训练数据。

因此工程师应记录每一轮的结局属于模型成功、模型失败、基础设施失败还是未知结果。归因于基础设施的失败，应从策略梯度更新中排除；由模型自身行为导致的失败仍应记为模型失败，这样触发超时或其他错误就不会变成逃避惩罚的途径。

把等待时间变成可测指标

长周期智能体强化学习混合了轨迹、工具调用和外部延迟，造成GPU需求的突发和等待期。对GRPO类训练——同一任务的兄弟尝试互相打分——调度应围绕组完成，而不是按启动顺序。一组的所有兄弟尝试结束后进入就绪池，训练器只取符合条件的完整组。主导指标是到可训练批次的时间，每秒token数仍可用于诊断推理。路由之所以重要，是因为让对话贴近其缓存历史，可以避免重复的预填充计算。

基础设施层面的目标，是减少昂贵GPU在沙箱、浏览器、代码执行等非GPU依赖上的等待。金迪建议把CPU和沙箱容量与GPU独立扩展，并给得充裕一些，因为闲置容器相对便宜。保持沙箱就绪、用快照和分叉方法，可以把环境启动移出关键路径，但工具运行本身的时间省不掉。他建议尽可能把沙箱放在与GPU相同的网络结构上，以减少智能体数百次工具调用的累积延迟；单步超时和预算可以限制挂起的浏览器或进程带来的干扰。工程师应跟踪GPU在等待环境上花掉的卡时，与利用率和到可训练批次的时间一起看，判断加投入该加在哪里。

数值对不上，训练就会偏

强化学习后训练期间，即使起点权重相同，推理引擎和训练器也可能给同样的token分配不同的概率。量化、内核、批处理，以及混合专家模型中的专家路由，都可能造成差异，进而给训练更新引入系统性偏差。

金迪的建议是先对齐数值，再测量并修正剩余的不匹配。具体做法包括让训练器前向计算所用的量化方案和计算方式与推理引擎一致，同时为优化保留更高精度的权重。重要性采样修正可以处理残余差异，但不能假设仅靠截断就能解决所有形式的不匹配。评估应使用最终服务模型时的精度、推理引擎和版本；一旦改动量化或内核，就需要重新评估。

权重同步同样需要设计。金迪描述了三种模式：训练与推理共用GPU时在内存中重新分片权重；直接把权重传给独立的推理工作进程；发布检查点，由推理引擎通过存储热加载。哪种最好，取决于模型、硬件拓扑和对新鲜度的要求。基于存储的发布不必导致完整服务重启，异步传输和紧凑更新可以把大部分工作移出关键路径；团队应把端到端发布延迟与应用权重所需的暂停分开测量。

权重发布还要对进行中的请求和缓存状态有明确方案：视引擎而定，可以在应用更新前完成、中止或暂停请求，并按需清空或重算缓存上下文。如果一条轨迹跨越了多个策略版本，要记录其token由哪个版本生成，让训练系统有意识地处理这种混合。共享资源时，传输要与推理流量协调，并把发布延迟与策略年龄一起监控。

金迪给较小团队的建议是：从简单配置起步，等测出的瓶颈足以证明必要时，再增加异步的复杂度。

• 批次就绪：组装一个完整可用批次要多久，包括掉队的长尾？
• 策略新鲜度：每条轨迹能否追溯到生成它的策略版本，多大漂移算过旧？
• 数值对齐：训练器与推理引擎的概率差多少，剩余差距用什么修正？
• 环境可靠性：能否区分基础设施失败与模型失败，并复现受影响的轮次？
• 权重发布：更新期间进行中的请求和KV缓存会怎样，发布实际耗时多少？
• 评估：是否在用户将遇到的精度和服务栈上测试模型？