← 返回 PaperDaily
大模型与智能体
Meta推出ROCS：推荐系统推理效率提升3倍，零质量损失
推荐系统推理常需对数百候选跑完整模型，存在大量重复计算。Meta的ROCS拆掉这种结构性冗余：延迟交互、请求侧只算一次，配合GPU内核优化，检索QPS最高提升3倍，排序阶段用省下的算力换模型质量。该方案已在Meta广告和自然内容数十个模型上真实部署，绝非纸上谈兵。
龙哥读论文
发布于 2026-09-05 00:31:10
阅读 4
查看原文
原论文信息如下：
推荐系统算力告急，Meta的ROCS如何让推理提速3倍？ 在互联网大厂的算力账单里，推荐系统一直是块“吞金兽”。用户打开App刷几下，后台就要对一个请求计算几百上千个候选的得分，每个候选都要把模型从头跑一遍，计算量惊人。
Meta AI团队最近放出的ROCS（Request-Oriented Compute Sharing，面向请求的计算共享）系统，把这个问题当成数学题来解：既然同一请求的数百个候选共享同一份用户特征，为什么要把这些重复计算一次次地跑？他们给出的答案是——提前把交互砍掉，让请求侧计算只算一遍，结果在数百个候选之间共享复用。在Meta生产环境的检索模型上，QPS最高提升了3倍且没有质量损失；排序模型上，FLOPs削减了50%，LogLoss还顺带降了0.5%，真正实现了用更少的算力换更好的效果。这种“省了钱还提了质”的买卖，谁看了不心动？👍
不过，要在动辄千亿参数、架构五花八门的推荐模型里做到这一步，远比嘴上说的复杂。ROCS真正厉害的地方，在于它不只是某个单一技巧，而是一整套从模型结构到GPU内核的协同设计。
从重复到复用：抓住请求-候选结构的计算冗余本质 要理解ROCS的价值，得先搞清楚推荐系统推理的基本结构特征。每一次推荐请求，模型输入可分为两大部分：请求侧特征（用户画像、时间、地点、行为序列等）和候选侧特征（物品类型、ID、属性等）。对一个用户请求，模型要给很多个候选物品打分排序——请求侧特征在所有候选之间完全相同，只有候选侧特征在变。也就是说，同一个模型要对一个固定的请求侧输入，配上几百个大不相同的候选输入，分别跑一次前向计算。
这种“一对多”结构天然带来了计算冗余。传统推荐模型为了让模型能捕捉到用户和候选之间细微的交叉特征，往往在非常靠前的位置就开始做请求侧和候选侧的交互。一个典型的深度推荐模型，通常包括嵌入层、特征交互层（比如各种FM变体）、序列建模层（对用户历史行为序列建模）和最终得分层。交互发生得越早，意味着其后所有层的计算都必须为每个候选从头到尾单独做一遍，用户侧信息在一开始就被候选“污染”，无法复用。图1：ROCS整体架构概览。传统模型（a）引入早期交互导致大量重复计算；ROCS（b）保持请求侧可复用通路；(c) DCA扩展共享到序列模型；(d) GLM细节
图1把ROCS的核心思想展示得很直白。图1(a)是传统模型的执行方式：模型输入端就把请求侧和候选侧的数据混合在一起，交互模块之后的所有操作全都得为每个候选重新计算，红色虚线框标出的Bc就是重复计算的代价。
图1(b)是ROCS的思路——把模型改造成一个具有“不对称依赖结构”的形态。用大白话说就是：请求侧输出的计算不依赖任何候选侧输入，而候选侧输出可以继续依赖请求侧和候选侧双方的信息。这样一来，请求侧通路上的中间结果只需要在每个请求维度上计算一次（蓝色通路部分），就能被这个请求下所有候选共享复用。候选侧计算还是照常，但基础的请求侧计算已经从“乘N”变成了“乘1”。
这个道理说起来简单，但实现起来问题就来了：怎么在不损失模型效果的前提下，把现有推荐模型改造成这种不对称结构？ROCS给出的答案是三大机制组合拳。
三大机制拆解：GLM、DCA与RRR如何协同重构模型 ROCS整套框架涉及三个核心组件，每个组件解决的问题不同，组合在一起就构成了完整的建模与推理新范式。
广义层掩码（Generalized Layer Masking，GLM）是ROCS为特征交互模型设计的核心改造工具。首要问题是：怎样判断模型某一层的输出能否被后续候选复用？
GLM给出的判定标准非常简洁：把模型的输入按组划分，形成一个有序分组（在ROCS的典型配置里就是两组，组0请求侧，组1候选侧）。对于任意一个算子f，若输入和输出都按同样的组顺序划分，且满足一个条件——**输出组i只取决于输入组0到i的数据，而不依赖任何i之后的输入组**——那么这个算子就被称为GLM合规（GLM-compliant）的，也就是完成了“ROCS化改造”（ROCSified）。
这个条件其实描述的是一个“块下三角”的依赖关系。用数学公式看更直观：对于两组输入x_R（请求）和x_C（候选），满足GLM不变性的算子f输出必须为f(x_R, x_C) = (f_R(x_R), f_C(x_R, x_C))。也就是说，请求侧输出只由请求侧输入产生，候选侧输出则可以有条件地利用双方信息。权重矩阵的形式就是块下三角矩阵：主对角线及以下为有效权重，右上块全部置零。图2：GLM模块构造。涵盖线性层、组内归一化、因子分解机以及组合闭包性质
图2展示了GLM对几类典型算子的改造方式。以线性层为例，假设输入x被分成请求组和候选组，权重矩阵W被强制改造成块下三角结构。原本4个块W_RR、W_RC、W_CR、W_CC完整参与计算，ROCS化后W_RC被置零，意思是候选侧信息不允许影响请求侧输出的计算。剩下的W_CR依然保留，让候选侧输出可以吸收请求侧信息。
类似地，归一化层（Norm）、激活函数这类无参数的逐元素算子，改成“组内局部”模式，即每一组输入独立计算归一化统计量——不允许用拼接后的全局统计量，因为全局统计会引入跨组依赖。因子分解机（FM）的交互计算也被加了块掩码，候选侧可以与请求侧做交叉交互，但请求侧内部只保留请求自身内部的交互结果。
最精妙的地方在于，GLM这种不变性满足“组合闭包”性质：两个GLM合规的算子组合在一起，整体依然GLM合规。这意味着MLP堆叠、残差连接、多层交互模块等复杂结构，只要内部由GLM合规的算子构成，整体就天然合规。图2(d)展示的正是这一性质。这下，整个特征交互模块都能被改造成“请求侧只依赖请求侧”的可复用结构，而无需为每种网络架构单独设计专用方案。
特征交互模块搞定了，序列建模模块怎么办？现代推荐模型几乎都会对用户的长序列行为数据（比如最近浏览过的几百个视频）做建模，而这里正是计算的重灾区——每个候选都要对这个长序列做一次复杂的Self-Attention推理，计算量随序列长度二次方增长，还要被候选数再放大一次。场景就是：用户过去一小时看了200个视频，现在有500个候选视频需要打分。传统方式下，每个候选都要重新跑一遍这200个视频的注意力计算，相当于同一份序列特征被从头到尾处理了500遍，纯属重复劳动。
深度交叉注意力（Deep Cross Attention，DCA）专门解决这个问题。DCA的核心思路分三步：第一步，用户序列的编码器变成纯请求侧模块，整个序列只编码一次，输出每一层的序列表示S_i，对应的K/V投影也只算一次。第二步，查询生成器被GLM化，请求侧查询和候选侧查询分开生成，候选侧查询可以聚合请求+候选的交互信息。第三步，做“分组交叉注意力”——请求侧查询和候选侧查询分别去和共享的序列表示S_i做注意力计算。请求侧注意力的结果对所有候选相同，只需算一次；候选侧注意力则保留候选特异性，为每个候选单独算。
这里有个关键细节叫“得益于深度”：DCA在每个交互层都做交叉注意力，不是只在最后一层做。这样浅层查询可以检索序列中比较基础的特征，深层查询则利用更丰富的请求-候选交互上下文，各层互补，既能充分共享序列计算，又不牺牲候选条件化的表达能力。带来的效果是：序列编码和K/V投影从每候选计算N次，降为每请求只算1次。图3：IKBO线性层实现。左为稠密实现，右为IKBO实现，将广播融合进GEMM尾算子
图1(c)展示的DCA结构很清楚地体现了这种不对称设计：Self-Attention（自注意力）完全跑在请求侧，K/V向量从用户序列表示中提取后共享给所有候选；Cross Attention（交叉注意力）在候选侧进行，查询（Q）来自候选侧信息，键（K）和值（V）则复用请求侧共享的序列编码。这样既保留了“候选条件化序列检索”的建模能力，又避免了为每个候选重复跑自注意力。
GLM和DCA保证了“能共享”，但还有一个隐患：ROCS化改造可能限制模型表达能力。传统模型里，每一层的全部输出宽度都可用于候选相关表征，而ROCS化后，有一部分宽度要专门保留给请求侧共享通路。在固定模型容量下，候选相关表达空间被压缩了，直接ROCS化可能带来质量下降。
面向请求的资源重分配（Request-oriented Resource Reallocation，RRR）就是回应这一问题的优雅解法：把ROCS省下来的计算资源，重新投资到请求侧通路上。理由非常直白——请求侧计算是所有候选共享的，多算一个请求侧特征，代价只是本来开销的约1/N；而多算一个候选侧特征，代价却是全额的N份。把一部分计算预算投到请求侧，等于用批发价买计算量，再把模型效果买回来。
具体实现上，RRR引入一个请求侧缩放比例r，控制每个ROCS模块中请求侧表征的相对宽度。r越大，请求侧通路越宽，可供复用的表征能力越强。由于请求侧通路乘以r之后，在推理时的实际成本增量只有乘以N，所以即便r等于2或4，增加的成本也只是传统模型的几分之一——但模型效果却可能因为这多出来的一大块请求侧容量而显著提升。这就是ROCS能实现“质量-效率双赢”的秘密武器。
不只省算力：IKBO的内核级优化让共享真正落地 模型结构改造完了，还差“最后一公里”——GPU上的高效执行。如果只是朴素地把ROCS模型跑起来，还是会有个拦路虎：请求侧张量需要被复制（广播）到候选批量大小才能参与矩阵乘法，这样算力是聊胜于无，可内存占用却要翻倍。要解决这个问题，就需要GPU内核级的配合。
ROCS团队给出的答案是内核内广播优化（In-Kernel Broadcast Optimization，IKBO）。IKBO的思路非常实用：与其先把请求侧张量扩展成候选批量再计算，不如在GPU内核里直接处理“请求批次”和“候选批次”的自然尺寸，把请求-候选关联关系留给消费方内核在执行时解决。具体来说，IKBO把ROCS化算子拆分成“请求批量”和“候选批量”两部分。请求批量部分在大小为B_r的批次上执行一次，产出请求侧输出以及候选侧所需的“请求派生贡献”。候选批量部分在大小为B_c的批次上正常执行。两个部分之间的关联通过一个索引映射m完成——第i个候选对应的请求是第m_i个。只要算子内核知道这个映射，就完全不需要逻辑上物化广播。
IKBO真正花心思的地方在于硬件层优化。普通GEMM算子做不了这种跨批次的融合，IKBO就自己做了一套定制化GEMM内核，用Triton实现，核心改动是把“广播+相加”操作融合进候选侧GEMM的epilogue（尾算子）阶段。矩阵乘法完成输出每个tile之后，epilogue根据候选对应的请求索引，去取对应的请求派生贡献，直接在寄存器里做加法。这样既不用把候选侧GEMM中间结果写回显存，也不用物化广播后的请求侧贡献张量，省掉了一大笔显存读写开销。
为了进一步隐藏epilogue带来的延迟，IKBO还引入了基于warp特化的持久化内核。三种warp组：一个生产者负责持续发起内存拷贝（TMA loads），两个消费者以一种“乒乓”模式操作——一个在做矩阵乘累加，另一个同时处理另一个tile的融合epilogue。显存加载、张量核计算、融合尾算子三个环节被显式地流水线化，不再依赖外部CTA带来隐式并发。本来在普通Triton内核里，大批量tile和深层流水会挤压同SM上的CTA数量，导致epilogue延迟无处隐藏——IKBO用warp特化把这个问题直接解决了。
再进一步，IKBO把请求侧和候选侧计算合并进同一个mega-kernel处理，用持久化执行调度让两侧tile共享SM资源，还用双向tile调度（请求侧tile按升序分配，候选侧tile按降序分配）来均衡负载，避免因SM间tile数量不均导致的“空转”。最后还对张量的内存对齐做了自动修复——分解后的张量连续维度字节数可能不再满足TMA路径的对齐要求，IKBO用自动变换识别受影响维度并做zero-padding（零填充），在不改变计算结果的前提下，让显存传输效率拉满。
DCA侧的注意力算子也用类似思路定制了FlashAttention-3变体——直接消费请求侧K/V张量，内核内部根据索引映射解析出每个候选对应的请求，按需加载K/V。K/V读入不会跨候选复制的浪费减少，L2缓存命中率得到提升。
从公共基准到生产部署：ROCS的真实收益全景 作为一篇实验做得比较扎实的论文，ROCS的效果评估覆盖了从公共基准到生产级工作负载的多个层级。这里把关键实验结果梳理一下。
首先是公共基准。ROCS在多个公开推荐模型骨干上做了测试，覆盖Wukong、RankFormer这类带特征交互和序列建模的主流架构。核心结论是：ROCS化后的模型相比原模型，在维持同等效果的前提下，推理时延显著更低；或者说在相同时延预算下，ROCS模型可以通过RRR把质量推得更高。也就是说，它在“质量-效率帕累托前沿”上做到了整体向外推动，而不是简单的“牺牲一点质量换速度”。表1：GLM、DCA和RRR三项技术对ROCS模型的增量消融实验对比，验证了每项技术的独立价值
然后是生产环境的大考。Meta的短视频推荐模型是一个典型的工业级排序模型：用户行为序列极长，候选池规模大，模型对时延非常敏感。ROCS部署后，在保持最终A/B测试效果甚至略优的情况下，QPS提升了50%，同时LogLoss下降了0.5%。在检索模型上，ROCS带来的收益更加可观——QPS提升了整整3倍，而且没有任何效果损失。这个数据说明，ROCS不仅能把多余的重复计算消掉，还能把省下的算力重新投资成模型质量。
从部署广度来看，ROCS已经在Meta内部横跨广告和自然内容、覆盖检索和排序等多类模型，推理复杂度跨了超过两个数量级。这不是在某个实验室环境里跑了个demo，而是经历了真实业务流量和在线A/B检验的实战系统。
需要特别指出的是，ROCS带来的这些收益并非来自简简单单的“把部分网络改成只用请求侧特征”，而是来自于ROCS化改造、GPU内核协同设计和算力再分配三者合力的结果。单独看任意一个组件，可能都会有不少折损，但组合在一起，就构成了一个完整闭环。
边界与启示：ROCS何时有效，又能走向何方？ ROCS的效果有目共睹，但龙哥更想把它的适用边界和深层启示说清楚。ROCS的本质是挖掘推荐推理结构中请求侧与候选侧的不对称性，把“一对多”的冗余计算变成“一次计算、多次复用”。理解了这一点，它的有效场景就很明确了：候选数量N越大，ROCS的收益越明显。N=1时ROCS化改造纯属多余；N=10时收益有限；N=100甚至N=1000时，请求侧计算摊销到每次候选上的成本几乎可以忽略不计，ROCS的优势就彻底释放出来了。Meta的检索和排序场景正好符合这个特征。
ROCS也不是银弹。它的GLM改造会改变模型内部的依赖结构，那些非常依赖“候选信息早期注入”才能学好的模型，可能需要更多的调参和架构适配才能追平效果。DCA的“共享序列编码+候选条件化检索”设计，本质上是从候选相关序列建模退回到“先请求侧编码、再候选侧检索”的中间地带，在一些对序列个性化要求极高的场景下，可能还需要额外的检索深度或注意力头数来弥补。论文也指出，ROCS化是在“固定模型容量”下做了结构约束，RRR算是找回表达能力的手段，但并不是所有场景都能通过简单扩大请求侧宽度来完美补偿。
不过从行业视角看，ROCS最大的启示并不只是“怎么把推荐模型跑得更快”，而是提供了一个值得深思的范式：**在追求模型效果的同时，同步考虑推理结构本身的对称性**。深度学习时代，为了涨点，业界习惯于把模型做得越来越复杂，特征交互越来越深，请求和候选的融合越来越早，却很少反向思考这种复杂度有多少是真正必需、又有多少是在为结构性冗余买单。ROCS证明了一件事：深入理解推理场景的数据结构特征，在模型设计之初就把可复用性当成一等公民，往往能收到“既省油又提速”的双重回报。这个思路，对推荐系统、广告检索，甚至对搜广推之外更广泛的“一个输入多个输出”推理场景（比如多任务学习、对比学习推理），都有借鉴价值。
龙迷三问 ROCS里的GLM和常见的注意力掩码有什么区别？
ROCS化改造后模型效果会不会变差？
ROCS能直接用到自己的推荐系统上吗？
如果你还有哪些想要了解的，欢迎在评论区留言或者讨论~
龙哥点评 论文创新性分数： ★★★★☆
ROCS把推荐推理的结构性冗余用形式化的算子级契约暴露出来，GLM、DCA和IKBO的协同设计覆盖了模型结构到GPU内核的完整链条，在工业级系统里属于很难得的体系化创新。实验合理度： ★★★★☆
公共基准与生产环境双轨验证，消融实验完整，各组件贡献拆解得比较清晰。生产A/B测试规模的QPS和LogLoss数据很有说服力。学术研究价值： ★★★★☆
为“请求-候选”结构下的计算共享提供了一个通用框架，GLM的组合闭包性质让不同算子都能被纳入同一约束体系，对后续推荐系统效率研究有较好启发。稳定性： ★★★★☆
Meta生产环境已部署在广告、自然内容等多个模型上，稳定性经过了大规模流量的检验。不过论文对极端候选分布和模型频繁更新的场景着墨不多。适应性以及泛化能力： ★★★☆☆
ROCS对“一对多”打分场景适应性很强，但偏向GPU推理场景；对于CPU部署、候选数较小的场景，ROCS的收益会打折扣。硬件需求及成本： ★★★☆☆
训练阶段和标准推荐模型差异不大，核心收益体现在推理阶段；但IKBO的定制内核依赖NVIDIA Tensor Core和TMA能力，硬件门槛偏高。复现难度： ★★★☆☆
论文宣称代码已开源，但IKBO内核涉及Triton/CUDA深度定制，复现成本不低。公共基准部分可以较快复现，生产级效果需要配套的工程环境。产品化成熟度： ★★★★☆
已在大规模生产系统中部署并产生实际收益，成熟度在推荐系统方向处于很高水平。可能的问题： 论文对“ROCS化后效果下降”的情况披露得不够细致，DCA的序列检索能力和传统候选条件化模型差距的边界也需要更多实验补充。
[1] Chen Y., Luo L., Zhang B., et al. ROCS: Request-Oriented Compute Sharing for Efficient Large-Scale Recommendation. arXiv:2607.27744v1, 2026. [2] Yi X., et al. Sampling-bias-corrected neural modeling for large corpus item recommendations. RecSys 2019. — two-tower架构综述 [3] Dao T., et al. FlashAttention: Fast and memory-efficient exact attention with IO-awareness. NeurIPS 2022. — FlashAttention基础 [4] Tillet P., et al. Triton: An intermediate language and compiler for tiled neural network computations. MAPL 2019. [5] Zhai J., et al. Actions speak louder than words: Trillion-parameter sequential transducers for generative recommendations. ICML 2024. ROCS这套组合拳，把推荐系统推理的冗余计算挖得很深。大厂算力吃紧，推荐系统又是为数不多“靠缩放定律就能涨效果”的领域——省下来的算力，就是下一轮模型升级的燃料。本文只是开胃菜，想挑战工业级推荐效率极限的朋友，强烈建议仔细读一读原论文的IKBO内核设计部分，里面藏着不少GPU优化硬功夫。
*本文仅代表个人理解及观点，不构成任何论文审核或者项目落地推荐意见，具体以相关组织评审结果为准。欢迎就论文内容交流探讨，理性发言哦～ 想了解更多原文细节的小伙伴，可以点击 "阅读原文"， 查看更多原论文细节哦！
🎯 算力省下来，模型更大更强——ROCS告诉我们：聪明的共享比盲目的堆算力更值钱！
想和龙哥一起读懂更多工业界神作，欢迎加入『龙哥读论文』粉丝群，
扫描下方二维码或者添加龙哥助手微信号加群 ：kangjinlonghelper。
一定要备注：研究方向+地点+学校/公司+昵称 （如 推荐系统+上海+Meta+龙哥），根据格式备注可更快被通过且邀请进群。
『龙哥读论文』微信群目前包含：图像处理、大模型及智能体、自动驾驶及机器人、AI医疗及AI金融5个群，还有不定期论文精读直播和求职内推信息～
