小红书精读：OneLA: Scaling Linear-Attention Decoding to Large Beams in Generative Recommendation

🚀大beam解码别再逐个存状态

各位算法同学们，beam width 涨到几百之后，线性注意力省下来的显存又被吃回去了——每个beam一份完整递归状态，每步解码还要整体读写一遍。OneLA 想说的是：这些状态本来就是冗余的。

📄 OneLA: Scaling Linear-Attention Decoding to Large Beams in Generative Recommendation

🔧 一个请求只保留一份 prompt prefill 后的共享状态 S_ctx，beam 之间的差异用 append-only 的 GDN Transition Records（GTR）紧凑记录，不再为每个 beam 物化完整的递归矩阵。

🧩 解码时不做状态重建，只把 GTR replay 到当前 step 真正用到的两个投影上，开销从矩阵级降到向量级，也没有 per-beam 状态写回。

⚙️ 用轻量 ancestry index 把 beam 的逻辑演化和记录的物理位置解耦：beam 选择只改引用、不改记录；再加一个 fused shared-context GPU kernel，在片上复用共享状态完成 replay。

📊 在快手工业 GR 负载上，端到端 decode 相比现有 GDN 执行路径加速 1.54–2.46×。

📈 recurrent-state 显存占用和数据搬运量同时下降，而这两项正是大 beam 场景的主要瓶颈。

✅ replay 深度被 SID 序列长度 bound 住，GR 里 prompt 长度和 beam 宽度都远大于 SID 长度，这个置换是划算的。

总结：最直接受益的是做 GR 推理、上 GDN 这类线性注意力加大 beam 解码的团队。要盯的不是吞吐峰值，而是 beam 拉宽后的端到端延迟和显存曲线，对比基线就是 vLLM 的 FullState 和 ReplaySSM 两条路。坑在于它依赖 prompt 共享、后缀短这个前提，如果 beam 之间前缀分歧出现得很早，或者你要跨请求复用状态，收益会打折。

原文：AlphaXiv