SlimPer 深度解读

1. 问题与动机

工业推荐系统正大量采用 Transformer/HSTU 一类长序列架构，但 SlimPer 指出，这些模型继承了语言模型并不适用于排序任务的计算前提。自回归语言模型需要在每个 token 位置输出预测，因此保留随序列长度增长的中间表示是合理的；精排模型最终只为一个“用户—候选物品”对输出若干个点击、点赞、评论等标量，没有逐 token 监督。照搬 Transformer 后，系统只能在两种坏选择间权衡：逐层压缩 token 会丢失原始细粒度行为，完整保留则使计算和显存随历史长度快速增长。

论文以 Instagram Reels 和 Feed 的末级排序为真实场景。生产输入通常有 10³–10⁴ 个用户侧 token，一个训练请求约含 5 个候选，而推理请求可含约 10² 个候选；若每个候选重复用户侧计算，浪费会被进一步放大。作者的核心判断是：推荐真正需要的是持续提炼“该用户与该候选为什么相关”的紧凑状态，而不是让所有用户 token 彼此反复交互。SlimPer 因此把模型容量从用户侧 token-to-token 计算转向用户—物品匹配，并要求每一层仍能直接读取完整原始证据，避免一次压缩后的不可逆信息损失。

2. 方法详解

输入由三类特征构成：高基数 ID 等稀疏特征、包含内容/行为类型/时间/上下文的用户事件序列，以及 CTR、物品质量、设备等稠密特征。各模态先被 token 化：稀疏特征用 embedding pooling；每条事件把内容 embedding、显式或隐式行为类型、位置与时间差编码、局部上下文编码相加；稠密特征归一化后经 MLP 投影。知识库由非用户侧（主要是候选物品及交叉侧）token 初始化，形状固定为 K×d。

每个 SlimPer 层执行 Select–Match–Refine 三步。第一步 Select：由当前知识库线性投影出 q 个 query。固定长度稀疏 token 使用 MLP 参数化注意力，变长事件序列使用缩放点积注意力，分别取回 q×d 的证据；稠密特征因规模较小，直接传到每层。query 来自融合后的知识库，因此一次序列检索已同时受候选物品、稀疏兴趣和其他模态影响。作者测试过额外的 key/value 投影，但没有收益，生产实现将其去掉。

第二步 Match：知识库再投影出 t 个“多面模板”，与两路取回证据做显式点积，形成 q×t 的相关性矩阵。第三步 Refine：对两路匹配矩阵做 RMSNorm，再与当前知识库投影和稠密特征拼接，经 MLP 产生残差更新。多任务场景可在每层输出任务 embedding，跨层求和后投影成各任务 logit。生产模型通常堆叠 5–10 层：低层广泛浏览历史，中层聚焦较近行为，高层把注意力收缩到最相关的约 400 条事件。

Request-Only Optimization（ROO）是工程关键。所有用户侧 token 每个请求只计算并保存一份，在同请求的全部候选间共享；候选相关状态只保留固定 K 个槽。每层计算为 O(Nq)，中间显存为 O(LK)，而完整自注意力基线为 O(LN²) 计算和 O(LN) 中间显存。典型设置 K=64、q=16、t=32、d=256；Feed 使用 5 层，Reels 使用 7 层。所有模型训练一个 epoch，采用 Shampoo 优化器、学习率 0.05。论文没有公开 batch size、GPU 型号、数据条数或训练步数，这是复现时必须自行补齐的部分。

3. 核心技术贡献

第一，论文提出推荐专用的固定槽迭代精炼范式。固定瓶颈没有切断原始输入，因为每一层都重新跨注意力访问全量 token；它限制的是中间显存，而非后续层可获得的证据。作者从信息容量角度说明，排序只需输出 τ 个标量，64×256 的知识库远高于目标熵需求。

第二，SlimPer 将计算明确分配给用户—物品交互。其每层交互容量为 O(NK)，比只让候选通过单一状态读取序列的 Transformer 式结构高 K 倍；即使把自注意力改成线性或滑窗注意力，后者仍传播 N 个中间 token，且大部分容量用于用户 token 互相混合，因此并不能获得相同的质量—显存优势。

第三，模型在统一骨干中兼容稀疏、稠密和行为序列，并把 ROO 从历史序列扩展到全部用户侧模态。这既替代原先 HSTU（序列）+ Wukong（固定特征）的后融合链路，也让大候选请求的用户计算可摊销。注意力天然连接候选与具体历史事件，还提供了可检查的预测归因路径。

4. 实验结果分析

论文在 Instagram Reels 与 Feed 末级排序的真实训练、评估数据上，以线上成熟的 HSTU+Wukong 后融合模型为基线。离线主指标是 Normalized Entropy（NE，越低越好），经验上约 0.03% 的变化已具有实际意义。

同为 2k 历史时，SlimPer 不仅质量更好，还把 QPS 提高 11%、显存降低 9.32%。扩到 6k 后，SlimPer 的 reshare NE 改善达 -0.86%，QPS 回退仍小于 20%；基线在相同扩展趋势中只改善 -0.13%，QPS 却下降 48%。FLOPs 也吻合结构分析：2k 时基线约 24 GFLOPs、SlimPer 约 3 GFLOPs，相差约 8 倍；4k 时约 74 对 5，相差约 16 倍；6k SlimPer 约 6 GFLOPs，仍只有基线 2k 成本的四分之一。

消融显示瓶颈容量和迭代深度都有效。K 从 64 降至 4 虽使 QPS 提高 23.2%、显存减少 9.53%，但 NE 恶化 1.2%；K=32 时只换来 4.25% QPS，NE 仍恶化 0.18%，说明 64 个槽是更稳妥的生产平衡。层数从 7 降至 3，QPS 提高 21% 但 NE 恶化 0.32%；增至 9 层又改善 0.12% NE，代价为 QPS -7.16%、显存 +4.92%。事件上下文带来约 -0.15% NE，其中行为类型贡献几乎全部收益，加入事件内容只再改善不足 0.02%，说明“用户做了什么动作”比局部内容共现更关键。

线上方面，Reels 5k 和 Feed 4k 模型已全流量发布，多项核心互动指标显著提升，综合 topline 影响约为典型显著发布的 10 倍；完整性、多样性、时效性等护栏无回退，训练与推理 GPU 容量大致中性。作者未披露逐项线上百分比，这限制了外部对业务收益的精确比较。

5. 局限与未来方向

作者明确列出两项局限。其一，实验只和内部最强的 HSTU+Wukong 混合基线直接比较，没有在同一条件下对比 OneTrans、HHFT、RankMixer 等近期统一架构；虽然作者称单独 HSTU 更弱，但外部仍无法验证 SlimPer 相对这些系统的优势。其二，全部数据来自 Instagram 内部，训练数据量、batch、硬件和任务标签分布未公开，精确复现不可能。

此外，论文的注意力归因说明“模型关注了什么”，并不等于因果解释；固定 K=64 是否适用于低流量、小特征或跨域场景也未验证。未来方向包括把无序的跨场景行为和上游候选证据接入知识库，将 ROO 扩展到粗排的大候选集，以及在保持 O(N) 与固定显存的前提下尝试比点积和轻量 MLP 更强的匹配、更新算子。

6. 工业实践意义

对搜推团队最直接的启示是：先检查模型的计算是否服务于最终判别目标。若线上只需少量任务分数，却在每层维护几千个用户 token 的完整状态，应优先验证“固定候选相关状态 + 每层回读原始证据”，而不是继续堆叠高效注意力变体。一个低风险试点可保留现有特征与损失，仅替换交互骨干，以 K=64、q=16、t=32 和 5–7 层为起点，并同时观察 NE/AUC、QPS、峰值显存与请求候选数。

工程部署需要把用户侧 token 化放到 request scope，确保同一请求的候选共享一份缓存；否则 SlimPer 的主要收益会被错误实现抵消。长历史应按 1k、2k、4k、6k 分档测质量—成本曲线，因为论文显示收益随长度持续扩大，但显存和 QPS拐点因场景不同。层数与 K 可作为两类预算旋钮：缩 K 更省吞吐但质量损失大，减层更适合延迟敏感流量；也可以按用户历史长度或请求价值路由不同深度。

在社区搜索/推荐中，事件 token 应显式编码点击、长停留、点赞、跳过、负反馈和时间差，而不是只编码内容 ID。论文的消融说明行为类型上下文比局部内容更有价值。上线前应保留完整性、多样性、时效性护栏，并用注意力热图检查模型是否从广泛长期兴趣逐层收敛到近期意图；若高层长期只盯最近事件，可能需要为长期兴趣设置独立槽或正则。最值得避免的是在没有 request-level 共享、没有与强生产基线同特征对比时，仅凭 O(N) 复杂度宣称成功。