
8月20日 CUDA 与 AI 系统加速速览:rl-triton 最高 5.70×、MoNe 128K 节省约 80%、OGR 线上 +1.120%
本期整理 rl-triton、MoNe、OGR 与 FLEXRec 四项更新,给出 GPU 与推理性能数字、适用边界以及可以直接开始的小规模验证动作。
四篇预印本都在 8 月 18 日提交,覆盖 GPU kernel、长上下文推理和推荐 serving。它们有一个共同提醒:局部 kernel 倍率、模型质量提升和线上指标,必须连同对照组、硬件、负载与质量门槛一起看,才能决定是否值得在自己的系统里复现。
快速判断
| 分组 | 更新 | 已报告结果 | 适用场景 | 先验证什么 | 行动窗口 |
|---|---|---|---|---|---|
| CUDA / Triton | rl-triton:把 7 类 RL credit assignment 写成统一的 associative scan | 相对向量化 baseline 1.6×–5.70×;H100 上一个高占比配置的 PPO 端到端 1.11×–1.16× 12 | 大量环境、短 rollout、GPU 侧 RL 轨迹处理 | credit assignment 在整步更新中的占比、kernel 输入是否为 FP32、端到端而不是单 kernel 的收益 | 已有 PPO / actor-learner GPU 路径时可做小型 A/B |
| 推理优化 | MoNe:用固定大小的 neural memory 代替查询时重读长上下文 | 128K tokens 时,相对 ICL 的计算与峰值显存约降 80%,参数开销 6.4%;RULER 上 128K 仍保持较高 Sub-EM 34 | 长文档、多轮查询、显存受限或端侧个性化 | 预处理一次的成本、跨查询复用、质量在自然文档和更大模型上的变化 | 有 32K 以上上下文预算时优先离线复现 |
| 推荐模型 | OGR:直接生成有序 slate,并用流水化 SID 解码 | 工业 / 公共数据集 NDCG@5 相对提升 48.2% / 27.2%;Kuaishou 3% 流量 A/B 的 Effective Views +1.120%;相对 TIGER-Beam / OneRec-Beam 吞吐 2.43× / 2.49× 56 | 以 slate 为基本推荐单元、需要联合处理 item 交互与顺序的短视频推荐 | slate size、beam width、候选生成链路、线上流量分配和 Effective Views 与业务目标的关系 | 有生成式推荐原型时可先做离线 slate replay |
| 推荐模型 / 推理 | FLEXRec:动态融合多个 transformer layer exit,保留判别式全库排序 | 在 Qwen 3 1.7B、Llama 3.2 3B 和 3 个数据集上验证;相对 E4SRec 延迟额外开销 <1 ms,平均启用 exit 约为 Qwen 2 个、Llama 3 个 78 | 紧凑 LLM 排序、请求复杂度差异大、生成式解码延迟过高的推荐链路 | NDCG@20 / Recall@20、每个请求启用的 exit 数、稀疏 Yelp 类数据上的退化 | 已有判别式 LLM-RS 时可先替换单一输出头 |
CUDA / Triton:rl-triton 的 5.70×,只在 credit assignment 占得足够多时才会变成端到端收益
rl-triton 把 GAE、V-Trace、Retrace、TD(lambda) returns、discounted returns、eligibility traces 和 episodic prefix sums 统一成一阶线性递推,再用 associative scan(结合律扫描)把串行递推改成
O(log T) 个并行步骤。每种算法的 Triton kernel 在片上构造递推系数,减少中间结果反复写回 HBM。论文把七类算法都放进同一套算子框架,并明确处理 terminated 与 truncated episode。1作者在 NVIDIA H100 80GB HBM3 和 RTX 2000 Ada 上,用 Triton 3.0.0、PyTorch 2.4.1+cu124 做 GPU benchmark。相对向量化 baseline,七类算法的完整调用 speedup 为 1.6×–5.70×;这个范围覆盖两张 GPU、是否处理每步 truncation 两种设置。2
真正值得拿来做容量判断的是 PPO 端到端实验。作者在 H100 上用合成 PPO 更新,对比 CleanRL、RLlib 和 Sample Factory 使用的 sequential backward loop,以及向量化
torch.compile baseline。在 (128, 128) policy、16,384 个环境的配置里,GAE 占 loop baseline 更新时间的约 10%–15%,端到端 speedup 达 1.11×–1.16×;在 (1024, 1024) policy、4,096 个环境时,GAE 只占约 2.2%,相对 loop 的端到端收益约 1.02×,相对向量化 scan 约 1.00×。2这组结果把验证入口说得很清楚:先测 credit assignment 在整步更新中占多少,再看单 kernel 倍率。论文还指出,当前 kernel 要求
float32 输入;seq_len 超过 131,072 后,部分 backward 路径会退回分块的两遍实现,两个 forward scan 则没有 chunked fallback。2最小复现可以只改一层:固定环境数、rollout 长度和 policy shape,分别记录 vectorized scan、rl-triton 与整步 PPO 的时间。若 credit assignment 占比低于几个百分点,直接移植 kernel 很可能只得到局部数字;若它在高并发短 rollout 中占据明显比例,再继续看 HBM 往返和 truncation 分支是否与论文设置一致。
推理优化:MoNe 把 128K 上下文的查询阶段变成固定大小记忆
MoNe 给冻结的预训练 Transformer 接上模块化 neural memory。模型先把长上下文切成固定大小的 segment,在 test-time learning 阶段用每层局部梯度更新 fast-weight memory;回答查询时,memory 只根据 query token 生成 key/value,不再把全部上下文重新送进 backbone。这个结构把长上下文处理拆成一次性的
O(N) 预处理和近似固定成本的查询阶段。34论文用 Qwen2.5-0.5B-Instruct 做冻结 backbone,在 RULER 的 S-NIAH、MK-NIAH 和 Frequent Word Extraction 任务上比较 ICL、RAG 与 MoNe。上下文长度覆盖 4K 到 32K,也延伸到 backbone 原生窗口之外的 48K、64K、96K 和 128K。4K–32K 区间里,MoNe 的 Sub-EM 为 0.99–1.00;到 128K 时,S-NIAH、MK-NIAH 和 Frequent Word Extraction 的 Sub-EM 仍分别为 0.96、0.94 和 0.96,训练只使用了不超过 4K 的上下文。4
效率数字来自同一组受控任务。32K 时,MoNe 的峰值 GPU 显存为 1.41 GB,ICL 为 2.48 GB;总 FLOPs 为 38.10T 对 58.06T。128K 时,ICL 需要 7.07 GB 和 786.3T FLOPs,MoNe 的总量为 1.41 GB 和 149.61T FLOPs。论文将 128K 的计算与峰值显存优势概括为相对 ICL 约 80%,代价是额外 6.4% 参数。4
MoNe 适合先进入离线长上下文回放,而不是直接改线上服务。当前实验只用 0.5B backbone 和 RULER 的受控检索任务;论文把更大模型、自然的单文档 / 多文档问答和真实工作负载列为后续验证方向。4
第一步可以固定一批 4K、32K、64K、128K 请求,分别测 ICL、RAG 和 MoNe 的预处理时间、首 token 延迟、跨查询复用率、峰值显存与任务质量。若服务端请求通常只查询一次,MoNe 的一次性记忆更新成本需要单独摊销;若同一份长文档会被多次查询,固定大小 memory 才有更明确的价值。
推荐系统:OGR 把 slate 生成和排序合在一起,FLEXRec 则把小模型的层深变成可路由资源
OGR:先看 slate 级目标,再看生成速度
OGR 的 TUSID 把 item 的语义信息和局部协同信号融合成分层 Semantic IDs;随后,OGR 用 list-wise preference planner 建模整组 slate 的偏好和 item 间依赖,再进行流水化的 position-wise SID decoding,直接生成有序 slate。SPA 通过 reward-guided conservative policy optimization,把生成结果继续对齐到用户偏好。5
论文在 KuaiRec 和 Kuaishou 的工业数据集上做离线实验,交互按时间排序并采用 leave-five-out 评估。实验运行在 NVIDIA L20,最大用户历史长度为 128,slate size 为 5,SID tokenizer 使用四层、每层 1,024 大小的 codebook,推理 beam width 为 20。相对代表性 baseline,工业数据集和公共数据集的 NDCG@5 相对提升分别为 48.2% 和 27.2%。56
速度收益来自把整组 slate 的规划和各位置 SID 解码重叠起来。论文在相同的 slate 设置下测得 OGR 相对 TIGER-Beam 的吞吐提升为 2.43×,相对 OneRec-Beam 为 2.49×,并同时取得最高 NDCG@5。6
线上数字来自 Kuaishou 3% 生产流量的 A/B 测试。相对现有系统,OGR 的 Effective Views 提升 1.120%,Comments、Likes 和 Forwards 分别提升 2.954%、0.505% 和 1.255%。这些指标来自短视频推荐的具体流量分配与业务目标,不能直接换算成所有推荐系统的排序收益。6
如果你已有生成式推荐原型,第一步应复现同样的 slate size、beam width 和用户历史截断,再把候选生成、SID 解码、planner 和 rerank 的耗时拆开。离线 NDCG 提升必须和线上 Effective Views 的口径分开保留;只有当 slate 级排序目标确实是瓶颈时,OGR 的端到端生成路径才值得替换现有多阶段链路。
FLEXRec:动态 exit 让每个用户序列使用不同的层深
FLEXRec 选择判别式推荐路径:每个 Transformer layer 都接一个 prediction head,AC-Router 根据用户序列动态选择要融合的 exit 数量和身份,再用 target-k hinge loss 把激活数量限制在目标范围。这样,模型仍用一次前向传播做全库 item ranking,避免生成式推荐的自回归解码。78
FLEXRec 在 Toys、Beauty 和 Yelp 三个数据集上测试 Qwen 3 1.7B 与 Llama 3.2 3B,所有实验使用单张 NVIDIA H100 PCIe 80GB。论文报告,FLEXRec 在可比的 compact-backbone 方法中取得最高或接近最高的推荐质量;相对 E4SRec,额外推理延迟小于 1 ms。78
路由行为不是固定按序列长度切层:Qwen backbone 平均激活约 2 个 exit,Llama 平均约 3 个,同一长度分组内仍有明显方差。论文还发现,去掉 target-k 约束后,Beauty-Qwen 的最大 active exit 数会升到 16,说明稀疏约束直接关系到推理开销的稳定性。8
这条路线适合已有判别式 LLM 推荐模型的团队:先保留原有 item embedding、检索和评估脚本,只增加中间层 head 与 router。回放时同时记录 NDCG@20、Recall@20、P99 延迟和每请求的 active exits;特别要把稀疏 Yelp 类数据单独看,不能只用 Toys 或 Beauty 的结果判断路由策略是否稳定。
最小验证顺序
- 先测可占用的时间份额。 对 rl-triton 记录 credit assignment 在整步更新中的占比;对推荐模型记录生成 / 排序、候选和 rerank 各阶段的时间。
- 再固定对照组。 复现 rl-triton 的 vectorized baseline、MoNe 的 ICL / RAG、OGR 的 TIGER-Beam / OneRec-Beam,以及 FLEXRec 的 E4SRec;同时固定 GPU、batch、序列长度、slate size 和 beam width。
- 把质量门槛和性能放在同一张表。 RL 看训练稳定性与回报,长上下文看 Sub-EM / 下游任务,推荐看 NDCG、Recall 和线上业务指标;任何单一 speedup 都不能替代这些门槛。
- 最后才做线上容量压测。 先确认收益来自你的 workload 分布,再测 P99、显存、跨查询复用、流量分配和回滚路径。
本期四条更新都值得做小规模验证,但验证顺序不同:rl-triton 先问算子在整步里占多少时间,MoNe 先问同一上下文会被查询几次,OGR 先问业务是否真的优化 slate 级目标,FLEXRec 先问判别式排序能否容纳动态层路由。先把这些前提量出来,再决定是否投入完整改造。
References
- 1
- 2rl-triton HTML 全文
arxiv.org
- 3
- 4MoNe HTML 全文
arxiv.org
- 5
- 6Once Generated, Ranked HTML 全文
arxiv.org
- 7
- 8Empowering Compact LLMs HTML 全文
arxiv.org

CUDA 与 AI 系统加速日报
面向工程与算法读者的日报频道,追踪 CUDA、GPU、性能加速、AI 编译器优化,以及推荐模型与推荐系统相关进展。
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.
Related content
- Sign in to comment.
More from this channel›
- 8月24日 CUDA 与 AI 系统加速速览:eStargz 冷启动 17 秒、边缘 RAG 能耗降 53.2%、Triton 跨函数 barrier
- 8月23日 CUDA 与 AI 系统加速速览:SGLang 启动 2.38×、KV 命中 93.2%、TP 配置省 6.9%
- 8月21日 CUDA 与 AI 系统加速速览:分片推理 1.79×、ERASE +9.51%、OneModel 延迟 -66.7%
- 8月19日 CUDA 与 AI 系统加速速览:稀疏 GPU 64.34×、边缘 MoE 2.3×与 KV-Pipe 迭代时间 -9.8%
- 8月18日 CUDA 与 AI 系统加速速览:MoE 小 batch 1.33×、VLM 共享 1.30×与端云推荐
- 8月17日 CUDA 与 AI 系统加速速览:GPU kernel 契约违规 62.1%、移植 5.1×与边缘缓存 1.65×
- 8月16日 CUDA 与 AI 系统加速速览:DARTree 9.73×、DrEM 评论 +1.388%与 FlashInfer FP8/MoE 修订