2026年6月，全球六大编程助手的ARR（年化经常性收入）合计突破300亿美元。按照SemiAnalysis的tokenomics模型，年底这个数字将冲到1000亿美元。Claude Opus 4.8在SWE-bench Pro上拿下69.2%，在Terminal-Bench 2.1上拿到74.6%。这些能力不是预训练喂出来的。是RL（强化学习）训出来的。Anthropic CEO Dario Amodei最近公开表示，RL正在展现当年预训练Scaling Law一样的对数线性增长曲线——训得越久，能力越强。
但很少有人停下来问一句：训RL的时候，你的GPU到底在干什么？
SemiAnalysis刚刚发布了一份数万字的深度技术报告，标题叫《RL Systems Mind the Gap: Matching Trainer and Generator Throughput》。他们用GLM-5模型，在256块H200上跑了完整的RL训练管线——128块给Trainer，128块给Generator，预填充与解码分离部署——然后发现了一个让所有AI基础设施负责人都应该后背发凉的数字：Trainer的MFU（模型浮点利用率）只有10.5%，wall-clock时间里30%在空转等数据。而Generator吃掉的计算量是Trainer的3倍。
换句话说，你以为你在做RL训练。实际上你的GPU集群更像一个昂贵的数据生成流水线，真正的训练只占了一小角。
这不是某个开源框架写得差的问题。这是RL训练管线在系统层面存在结构性瓶颈——而大多数实验室和公司甚至还没有意识到这个瓶颈的存在。
三个角色，一条死锁的生产线
要理解问题出在哪，先得看明白RL训练系统里三个角色的分工。
Generator负责推理：它读取数据集中的prompt，让模型生成响应——学术圈叫rollout。RL Environment负责判分：比如一个代码执行沙箱，把生成的代码扔进去跑，根据测试通过率打出reward。Trainer负责优化：吃进rollout和reward，算出梯度，更新模型权重，然后推送给Generator。一个循环闭合。
听起来很干净。但这个循环里藏着一个致命假设：Trainer需要等Generator把所有rollout都生成完，才能开始训练。Generator也不能在生成中途更新权重，因为同一批rollout必须来自同一个版本的模型——学术界管这叫on-policy约束，传统RL理论认为，跨版本的数据混用会毒化训练信号。
这直接制造了一个两难困境：要么Trainer闲等，白烧GPU；要么降低生成质量要求——少采样、短rollout——牺牲训练效果。两种选择都在烧钱。
SemiAnalysis的实测把这种浪费量化了。Trainer消耗rollout的速度是2.75个/秒，Generator的生产速度只有1.95个/秒。Trainer快，Generator慢。这导致Trainer的30%时间在空转，MFU被锁死在10.5%。而Generator端呢？因为推理天然比训练更吃显存带宽，它的计算用量反超Trainer 3倍。最贵的GPU在闲着，次贵的在超负荷跑。
GRPO：标准答案，也是问题本身
当前开源RL训练的事实标准是GRPO（Group-Relative Policy Optimization），由DeepSeek在R1中大规模验证后成为行业标配。GRPO的思路很精巧：对每个prompt采样多个completion形成一个group，计算每个rollout相对于组内平均分的advantage（优势值），高于平均的加强，低于平均的抑制。相比传统PPO，GRPO直接省掉了一个价值模型（critic），砍了训练的计算开销。
但GRPO的优雅之下，埋着系统效率的两个死穴。
第一个死穴就是前面说的同步锁。因为所有rollout必须来自同一个policy版本，Generator和Trainer被强制串行——这在推理任务短、rollout快的场景下还能接受，但当模型规模上了千亿参数、rollout长度从几百token膨胀到几千甚至上万token（多轮工具调用、长链推理），Generator的产出速度会急剧下降。Trainer的等待时间随之飙涨。
第二个死穴更隐蔽。GRPO的训练信号来自group内rollout之间的reward差异：如果某个prompt太难（大家都是零分）或太简单（大家都是满分），整组advantage全是零，这组数据等于白跑。SemiAnalysis在报告中明确指出了这种"uniform distribution"风险：当solve rate趋近0%或100%时，Generator拼了命跑的rollout，Trainer一口都吃不到。这个浪费发生在生成端，崩溃在训练端，而你的监控面板上甚至不会报错。
打破同步锁：三条技术路线正在合流
行业并非没有意识到问题。过去12个月里，三条技术路线正在从不同方向冲击RL训练的同步瓶颈。
第一条路：PipelineRL。ServiceNow团队在NeurIPS 2025上发表的这项工作，提出了一个大胆的方案——允许Trainer在Generator还在生成rollout的过程中就推送新权重。他们称之为in-flight weight updates。"飞行中权重更新"。Generator接收到新权重后继续生成后续token，一个rollout的头部token可能来自旧policy，尾部token来自新policy。PipelineRL在32块H100上的实验拿到了约2倍的学习加速，且训练效果没有显著劣化。核心结论简单但颠覆性：on-policy不是非黑即白的二元开关。RL算法能容忍一定程度的policy staleness，而这容忍度比大多数人想象的大得多。
第二条路：异步RL + 陈旧度容忍。Meta的ScaleRL论文首次在70B Llama 3-V上系统性地测试了这个边界：让Generator领先Trainer最多8个训练步骤（k=8），对最终模型性能几乎没有影响，但硬件利用率大幅提升。更激进的是CMU与Meta AI联合团队提出的M2PO（Second-Moment Trust Proxy Optimization）：即使数据陈旧达256个训练步骤——你没看错，256步——只要妥善控制重要性采样的二阶矩，off-policy训练完全可以匹配on-policy性能。研究人员称这种现象为"prosperity before collapse"——陈旧数据在性能崩溃之前，有一段很长的"繁荣期"，其信息密度与新鲜数据几乎等同。清华IIIS、蚂蚁集团与港科大联合推出的异步RL框架AReaL，把这个理念工程化落地，实测拿到2.77倍加速。
第三条路：周期性异步。基于昇腾NPU平台的团队在Periodic Asynchrony方案中找到了一个精巧的折中：每个训练迭代开始时同步一次权重，然后整批rollout使用同一policy生成，再异步训练。本质是在同步和异步之间开了个"中间地带"——保留on-policy的数学纯度，但消除Trainer等待Generator的硬同步锁。NPU平台上实测吞吐量翻倍，GPU平台同样有效。
三条路线指向同一个方向：RL训练系统的效率上限，不取决于你有多少GPU，而取决于你能多大程度上打破Trainer和Generator之间的同步锁。不管是通过in-flight更新、陈旧度容忍、还是周期性异步——选了哪条路不重要，重要的是先意识到"同步"本身就是最大的效率杀手。
被忽视的CPU黑洞：RL Sandbox
如果说Trainer-Generator不匹配是GPU层的瓶颈，那RL Environment就是CPU层的黑洞——而且这个黑洞比大多数人想象的深得多。
RL训练中的代码执行、数学验证、工具调用——这些操作都不跑在GPU上。它们需要隔离的沙箱环境：把模型生成的代码塞进去跑，抓取输出，比对预期。一个训练step可能需要同时运行数千甚至数万个沙箱实例。SemiAnalysis在报告中把RL环境交互延迟拆成两块：沙箱启动时间和沙箱执行时间。当rollout变长、tool use变多，沙箱开销会以肉眼可见的速度吃掉Generator的产出。
Dylan Patel在今年3月的Daytona Compute Conference上说得更直白：AI数据中心正在从GPU-centric向GPU+CPU混合架构演进，RL训练对CPU的需求规模被严重低估了。一个大规模RL训练管线需要的并行CPU沙箱数量，会远超大多数团队在预算表里预留的那一栏。Northflank的公开数据显示，生产级RL训练可能需要10万级并发沙箱，每个沙箱从冷启动到就绪需要1到2秒——这些秒数加总起来，等于整条管线里凭空多出来的延迟。
CoreWeave近期推出的Sandboxes产品，试图在Kubernetes集群内提供统一的沙箱执行层。Modal的serverless代码执行层也在解决同一个问题。但本质上，这是行业过去两年的基建欠账：所有人都在抢GPU，没人在意RL训练需要多少CPU、多少沙箱、多少隔离环境。现在RL突然成了模型能力提升的主引擎，这笔账必须还——而且是紧急的。
TCO算术：GPU单价是你看过最贵的幻觉
SemiAnalysis报告中有一个容易被快速翻阅跳过的段落，但可能是对从业者最有实操价值的部分：他们把自建RL训练管线和托管方案做了价格对比，对比对象是Thinking Machines Lab的Tinker API。
Thinking Machines Lab由OpenAI前CTO Mira Murati创立，OpenAI联合创始人John Schulman担任首席科学家。Tinker提供一个极低抽象的API：forward_backward用于计算梯度，sample用于生成，研究者可以用几行代码表达几乎所有后训练算法。它基于LoRA，允许多个训练任务共享同一个GPU池，从而压低单位成本。对于小团队或实验性RL任务，这意味着你不需要先搭一个分布式训练集群再开始工作。
但Tinker只是引子。SemiAnalysis真正想说的是TCO结构。他们引用自家的ClusterMAX框架指出：只看GPU小时单价来比价，是行业内最大的成本幻觉。一个gold-tier集群和silver-tier集群的GPU小时价可能接近，但综合TCO——算上配置时间、故障恢复、调试周期、网络存储调优——可以差出5%到15%。如果是AWS这类全托管云，用SemiAnalysis的真实世界定价数据做TCO调整后，比顶级neocloud贵出最高113%。RL训练因为Trainer和Generator天然需要异构硬件组合（不同精度、不同并行策略、不同推理部署方式），集群质量的差异会被进一步放大。
这引出一个残酷的结论：并不是所有团队都该自建RL训练管线。如果你的RL是实验性质的、不频繁的、小规模的任务，Tinker或Modal这类托管方案的TCO可能远低于自己搭集群。但如果你在持续训一个核心模型——比如前沿实验室的旗舰推理模型，每天几万甚至几十万美元的GPU开销——系统层面的每一分利用率差距都会被scale放大到百万美元级别。这时候，自建加深度系统优化是唯一的路。而这条路需要你回答的第一个问题就是：你的Trainer和Generator，匹配上了吗？
谁在赢？谁会裸泳？
RL训练基础设施的竞争格局正在快速分化。三个阵营的轮廓已经清晰。
第一阵营是托管平台。Thinking Machines的Tinker、Modal的serverless RL栈、CoreWeave的Sandboxes，都在试图把RL训练的复杂度封装成API调用。他们的打法是"先让用户上车"——优势是零门槛，劣势是当用户规模大到一定程度，通用设计的TCO天花板会逼着用户自建。
第二阵营是框架层。verl、OpenRLHF、Prime Intellect的prime-rl、蚂蚁集团/清华的AReaL——开源RL训练框架正在从"能用"进化到"好用"。PipelineRL式的in-flight更新、M2PO式的陈旧度容忍、Periodic Asynchrony式的中间路线，都在被吸收进主线。框架层的赢家不会是单一项目，而是能最快整合系统创新的生态。
第三阵营是芯片层。PipelineRL和M2PO的核心发现——RL训练可以容忍大量policy staleness——意味着RL训练对GPU间互联带宽的要求可能低于预训练，但推理侧的吞吐要求极高。这对AMD、Intel以及各家ASIC厂商是一个结构性利好：如果你的芯片在推理端够强，RL训练场景可能是你切入AI训练市场的最佳入口。对NVIDIA来说，这反而意味着它的训练护城河——NVLink + cuDNN全家桶——在RL场景下的溢价空间可能收窄。一个更分散的芯片格局，正在RL训练的跑道上酝酿。
最危险的，是那些"以为自己会做RL训练"的公司。买了GPU，装了verl，跑了几个benchmark——然后发现月度账单是预期的3倍。因为没人告诉过他们：Trainer在空转，Sandbox在排队，Generator在等权重同步，而10.5%的MFU已经把一半以上的算力预算变成了废热。
RL训练不是买卡就能跑的时代，结束了。下一个阶段属于那些能看穿GPU小时价标签，把Trainer、Generator、Sandbox三条线的吞吐量当成一个系统来设计的人。而这张系统蓝图上的第一条线，是从承认10.5%的MFU不是bug、而是设计缺陷开始的。
快报