大模型强化学习的算法可以写成几行公式，生产训练却是一条跨多个系统的流水线：训练器更新权重，推理引擎生成 rollout，环境执行动作并返回奖励。任何一段供给不足，昂贵的 GPU 都会等待。
“RL 是基础设施问题”来自 Modal 工程团队的实践总结。这个判断准确指出了规模化训练中的系统瓶颈，但它不是说奖励设计、数据质量或算法已经不重要，也不是所有团队都必须采用 Modal。本文把其观察放进更通用的后训练架构中讨论。
一个循环，三套系统
训练引擎
训练侧负责前向、反向、优化器状态、检查点和分布式并行。模型越大，权重、梯度、优化器状态和 KV cache 对显存与带宽的压力越高。训练框架还必须能从失败中恢复，否则一次节点故障就可能浪费整轮采样。
Rollout 引擎
策略模型需要批量生成候选轨迹。这个阶段更像高吞吐推理服务：要处理不同长度的请求、调度 KV cache，并让多个版本的策略与训练状态保持一致。生成过慢，训练器吃不到新样本；生成过快但环境处理不了，队列和内存又会堆积。
可执行环境
对代码、浏览器或工具型 Agent，动作必须在隔离环境中真实执行，测试结果和环境状态才构成反馈。环境需要并发、可复现、有限权限、可超时和可清理。冷启动、依赖安装和外部服务波动都会进入训练关键路径。
三者的核心指标不是各自峰值，而是端到端稳定吞吐。局部优化一台推理服务器，如果没有改善单位时间内可用于更新的有效轨迹，未必提高训练效率。
多节点后的关键：权重如何移动
训练器更新策略后，rollout 引擎需要获得新权重。模型跨节点部署时，权重同步可能成为主要停顿。常见缓解方向包括：
- 使用 RDMA 和高速互联提升集群内传输；
- 用 LoRA 或其他参数高效方法只同步较小的增量；
- 将训练与推理共置，减少跨网络传输，但接受资源竞争；
- 采用异步训练，容忍 rollout 使用稍旧策略，同时处理策略陈旧带来的偏差；
- 对跨集群同步使用增量或压缩传输。
Modal 博客展示了在其假设带宽和硬件下，RDMA 相比 TCP 显著缩短权重更新时间。那是特定配置的测算，不应写成任何集群都会获得固定倍数加速。真实收益取决于模型表示、拓扑、通信库、拥塞和并行策略。
三类常见工程损耗
胶水代码
节点申请、镜像、框架启动、缓存、失败重试、日志和指标经常散落在脚本与 YAML 中。胶水越多，实验配置越难复现。好的平台抽象应隐藏资源编排细节，同时暴露模型、奖励、环境和并行策略这些真正需要实验者控制的参数。
排队与失败反馈过慢
训练任务排队数小时后因配置错误立即失败，会严重拖慢迭代。解决方法包括提交前静态检查、小规模冒烟测试、镜像预构建、容量池和快速启动，而不只是购买更多 GPU。
GPU 利用率不足
环境比 rollout 慢时，GPU 会等待动作结果。常见做法是维护一组预热沙箱，按实时需求补充。但缓冲区过大浪费空闲资源，过小又暴露冷启动延迟，容量必须根据 batch、轨迹长度、动作耗时和失败率动态调整。
同步、异步与共置没有统一答案
同步 RL 易于理解策略版本与样本对应关系，却受最慢组件拖累；异步方案提高资源利用率，却要监控策略陈旧和训练稳定性；共置节省通信，却让训练与推理争抢显存和算力；解耦部署更灵活，又增加权重传输成本。
因此架构选择应从测量开始：GPU 忙碌率、rollout tokens/s、环境步骤延迟、队列深度、权重同步时间、失败恢复时间，以及每条有效轨迹的成本。没有这些指标，“GPU 没吃满”只能是一种猜测。
开源框架与平台的边界
verl、OpenRLHF、slime 等开源框架提供算法与分布式训练实现；Modal Training Gym 等项目尝试在云基础设施上封装集群、环境和可观测性。前者不必包办所有容量调度，后者也不替用户决定奖励函数和训练目标。
团队应优先采用已在相近规模验证的训练框架，再选择自建 Kubernetes/Slurm、托管算力或平台服务。供应商案例适合展示一种实现，不足以证明所有工作负载上更快或更便宜。
参考资料与延伸阅读
- Modal：Reinforcement learning is an infrastructure problem
- Modal Training Gym 官方仓库
- verl 官方仓库
- OpenRLHF 官方仓库
- slime 官方仓库
- NVIDIA NCCL 文档
- Hugging Face：大模型 RLHF 系统设计
资料核验日期：2026-08-23。文中 Modal 性能案例属于其公开测试条件；本文的系统化归纳为研究推断，不构成平台推荐。