北京
训练一个强化学习后的大模型，GPU有超过四分之三的时间在空转——这不是硬件浪费，而是系统设计留下的缝隙。上海交通大学副教授杜冬冬在QCon上海站的演讲中，给出了一个从历史数据里"借时间"的解法。
瓶颈不在模型，在Rollout
RL已经成为大模型对齐与推理增强的标准手段。但杜冬冬团队的实测数据显示，在math和code的RLVR训练中，Rollout占训练耗时的84%–91%。随着训练响应长度从2K增长到11K+ token，这个比例还在持续走高。
更棘手的是批内长尾问题。同一批任务里，有的样本很快生成完毕，有的却拖得很长。结果是最早完成的那块GPU，约76%的时间处于空闲状态。算力买了，却在等。
传统思路是上投机解码，用一个小模型来加速生成。但这意味着额外的模型开销，而且小模型本身的能力边界会限制加速效果。杜冬冬团队换了个方向：能不能复用RL训练中已经付费生成过的历史响应？
相邻epoch之间，藏着大量可匹配的token
团队基于真实轨迹做了大量数据分析，发现了一个关键规律：相邻epoch的Rollout之间存在显著的相似性，大量token可以精确匹配上一epoch的生成结果。同时，响应长度的排序在不同epoch之间保持稳定。
这两个观察构成了RhymeRL的设计基础。既然历史数据里已经有答案，就不需要再让模型从头算一遍。
但直接复用会带来新问题：在线检索索引会重新回到关键路径上，反而增加开销。团队的设计目标是——离线建索引，在线零额外开销，不依赖额外小模型，同时保留one-step-off的算法边界，避免全异步带来的样本丢弃和范式改变。
RhymeRL的两大核心组件
系统由HistoSpec和HistoPipe两部分构成，分别解决"怎么复用"和"怎么调度"的问题。
HistoSpec负责历史推测解码：
- 为每个提示词构建一棵后缀树，实现O(m)复杂度的前缀查询
- 引入奖励感知选枝机制，优先选择高奖励路径
- 采用类AIMD的动态草稿窗口，根据验证结果自适应调整
HistoPipe负责流水线调度：
- 奇偶step长短互补调度，平衡不同step之间的负载
- 步内与跨步的尾部迁移，缓解长尾样本的失衡问题
- 两级GPU资源分配，让空闲算力得到利用
整个系统形成端到端闭环：响应、奖励、长度会回写到历史索引中，先验知识随着训练进程不断演进。训练越久，可复用的历史信息越丰富。
2.6倍吞吐提升，但边界同样清晰
实施效果方面，RhymeRL的端到端吞吐最高达到基线版本的2.6倍；其中HistoSpec单步Rollout吞吐最高提升1.86倍。
杜冬冬也指出了当前的实践边界：目前主要针对math和code场景做了比较深入的实践，更复杂、更动态的agent RL场景，可能面临不同的需求和问题。这套方案的核心价值在于不依赖传统投机解码中对小模型能力的依赖，而是充分利用空闲算力来提效。
对于关注RL Infra的工程师来说，这项工作的启示在于：优化不一定来自更强的硬件或更大的模型，有时候答案就藏在已经跑过的数据里。相邻epoch之间的相似性，是一个被忽视已久的算力富矿。
杜冬冬长期从事操作系统、智能体系统等方向研究，成果发表在SOSP、OSDI、ASPLOS、FAST等会议和期刊，获SOSP 2025最佳论文奖及FAST 2026最佳论文奖和杰出技术成果奖。其研究成果已在工业界和开源社区广泛应用，包括蓬莱可信执行环境系统、D-VSync渲染技术、Serverless低时延沙箱启动技术以及并行化GPU启动gCROP等。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
