Memory Layer: Train the In-Model Cache for Recommendation Models

1. 问题与动机

这篇论文处理的不是一个单纯的模型精度问题，而是大规模推荐早排（Early-Stage Ranking, ESR）长期存在的训练—服务结构错位。Instagram Reels 的早排需要在双位数毫秒延迟内为每次请求约 \(O(1K)\) 个候选打分，因此通常先离线运行物品塔，把向量放入服务侧缓存；训练时却始终使用当前物品塔刚算出的新向量。作者把错位拆成三类：物品塔参数与缓存新鲜度不同、训练 Scribe 与候选池 Hive 表的特征来源不同、训练从不遇到缓存未命中而线上必须回退。实测这些差异使多个互动任务的训练与服务 Normalized Entropy（NE）相差 5%–12%，传统缓存总体预测覆盖率只有 96%，新发布 15 分钟内内容的命中率甚至只有 10%–20%。这正是新 UGC 冷启动的关键失败模式：模型可能知道新内容值得分发，但向量尚未进入缓存，早排直接给负分或跳过。

作者的核心判断是：缓存若只存在于服务系统，任何额外同步任务都只能缓解而不能消除错位；要解决问题，必须把缓存变成模型本身的可训练状态，让训练写入的向量就是服务读取的向量。该工作延续两塔召回、SilverTorch 内嵌缓存、TorchRec/FBGEMM 稀疏表等工业技术，但进一步把“只读服务制品”改造成训练和推理共享的单一事实源。

2. 方法详解

Memory Layer \(M\) 是以物品 ID 为键、以物品塔稠密向量为值的稀疏键值表。底层采用 Multi-Probe Zero-Collision Hashing（MPZCH）：身份张量把原始 ID 无碰撞地映射到行号，512 维向量表跨 GPU/CPU 分片存储，运行时元数据与向量共用行索引；容量有界，使用 LRU 淘汰。训练时物品塔 \(f_{\text{item}}\) 先产生目标向量 \(e_i\)，模型再从 \(M[i]\) 读出缓存向量 \(\hat e_i\)，排序损失实际使用缓存表示，因此训练看到的输入与线上一致。

作者比较了两种缓存学习方式。普通方式最小化 \(\|M[i]-\mathrm{sg}(e_i)\|_2^2\)，但需要调损失权重且渐进更新仍会短暂滞后。最终采用 Writeback：构造梯度 \(g_i^{wb}=\hat e_i-e_i\)，复用 TorchRec TBE 的 EXACT_SGD，令学习率 \(\eta=1\)，一次更新便得到 \(M[i]\leftarrow \hat e_i-(\hat e_i-e_i)=e_i\)。Writeback 梯度只更新缓存表，排名损失独立更新物品塔与其余参数，既实现精确赋值，又不需要新的 CUDA 内核或额外优化器状态；同一批次重复 ID 先去重，保证每行只执行一次精确写入。

缓存未命中由 Always-On Embeddings 兜底。大部分物品特征仍进入物品塔并被缓存；少量对新内容也有泛化能力的特征，如作者 ID、主题 ID 或内容理解特征，在线实时提取。命中时模型融合缓存向量与 always-on 向量，未命中时把缓存分支置零，只保留作者等通用信号，使所有候选都有可学习的分数，而不是固定负分。论文当前部署具体使用 always-on 作者 ID，命中后再加入媒体 ID 与 MPZCH 向量。

为覆盖没有自然互动日志的候选，Multi-Table Training 每步并行读取带标签的训练批次和无标签候选池批次，在 GPU 预处理阶段合并物品特征、只运行一次物品塔并统一 Writeback；排名损失只对训练批次计算，候选池批次只负责填充缓存。Raw Embedding Streaming（RES）则把新向量传播到预测器：每步利用 TBE 预取期间向量已在 HBM 的机会异步拷到 CPU，后台按 ID 去重、量化并合并分片，每 15 秒把向量、身份映射和元数据原子推送，P99 端到端传播约 21 秒且不阻塞 GPU 训练。

实验使用 Instagram Reels 的在线训练两塔早排，与 SilverTorch 缓存基线比较；共享表容量在中性服务算力下扩大 50%。论文明确给出在线数据源、表结构、流式间隔和服务架构，但没有披露训练批大小、优化器（排名模型部分）、学习率、GPU 型号或训练步数，这限制了外部团队对训练资源的精确复刻。MPZCH、Writeback 与 RES 的基础组件已通过 TorchRec/FBGEMM 开源，模型集成代码与内部数据未开放。

3. 核心技术贡献

第一，论文把训练—服务一致性从“同步流程治理”变成“模型结构保证”。同一 MPZCH 表在训练可写、在服务可读，消除了小时级锚点模型、Hive 回填和独立批量评估造成的表示分叉；pselect 的训练—服务 NE 差距由 12.11% 降至 1.64%，缩小 86%，reshare 差距由 5.24% 降至 3.42%，缩小 35%。

第二，Writeback 用 \(\eta=1\) 的稀疏 SGD 把反向传播基础设施复用为精确赋值算子。它比额外的 \(L_2\) 对齐损失更容易运维，因为没有损失权重、动量或收敛速度需要调节，同时保留分布式 TBE 的 all-to-all 路径。

第三，Always-On Embeddings 与多表训练把“缓存命中”从质量前提降为加分项。MPZCH 自身达到 99.5% 命中，剩余 0.5% 仍由作者 ID 等信号打分，最终预测覆盖率从 96% 提升到 100%；候选池无标签物品也能在训练循环中刷新，而不再依赖独立批处理集群。

第四，RES 把训练更新、缓存发布和模型发布收敛为一条链路。向量新鲜度从约 5 分钟改善到约 20 秒，训练与发布计算成本下降 30%，循环发布吞吐提高 3 倍；经过服务端优化后端到端吞吐提高 2.42 倍，使扩大缓存容量后仍保持与基线相同的服务算力。

4. 实验结果分析

论文在 Instagram Reels 早排生产面进行长期部署，并报告所有冷启动 A/B 指标均达到统计显著。核心结果如下：

冷启动收益并非只有缓存命中率变化。系统同时获得更快流式传播、持续在线训练、扩大 50% 的缓存容量、未命中兜底，以及来自最新物品塔而非数小时前 checkpoint 的向量。论文通过上线前 A/B 消融确认收益来自 Memory Layer 而非并行模型改动，但严格逐组件线上消融因基础设施耦合难以进行；表 3 只给出早期原型的方向性结果：MPZCH+Writeback 改善转发和时长，always-on 主要改善冷启动 views/时长，RES 改善转发，多表训练扩大覆盖。Writeback 与 \(L_2\) 方案总体相当，Writeback 在 pselect NE 略优，因此选择前者。

一个值得注意的评测现象是：覆盖率从 96% 到 100% 后，实验组会额外打分原本被绕过的约 4% 新内容，处理组与对照组的内容分布不再完全相同；冷内容即时互动通常低，短周期 A/B 可能低估长期供给价值。作者因此结合相同媒体集合的受控服务评测与更长实验，而不是只看短期总体 CTR。这一处理对任何“提高新 UGC 覆盖”的实验都很重要。

5. 局限与未来方向

作者明确列出三类局限。其一，Writeback 仍是 write-behind：物品上次出现在训练步 \(t\) 时写入的是参数 \(\theta_t\) 生成的向量，服务到 \(t+k\) 时模型参数已更新，稀有物品仍会滞后；多表训练只能限制 \(k\)，不能达到逐请求运行物品塔的绝对实时。其二，训练时物品塔总能产生向量，因此缓存未命中的全零分支没有显式进入损失，模型只通过“新内容缓存信号较弱”间接学会融合；作者计划在训练中模拟未命中掩码、增加物品无关特征，并借鉴缺失模态鲁棒融合。其三，评测仅覆盖 Instagram Reels 一个内部生产面，数据、完整代码与基础设施不可公开，外部无法做精确复现或跨系统对比。

训练—服务差距也没有归零，残余来自服务端 int8 行量化、write-behind 读取和显式未命中分布与训练分布不同。作者未充分讨论的风险包括：LRU 淘汰可能进一步偏向高频内容；作者 ID 兜底会把创作者历史强势程度带入新内容冷启动，可能放大头部偏差；扩容 50% 与结构改造同时发生，使缓存容量对收益的独立贡献难以精确识别。

6. 工业实践意义

对社区搜索与推荐，最可迁移的设计是把“索引/缓存新鲜度”当作模型正确性的一部分，而不是独立数据工程 SLA。可先审计训练与线上使用的物品向量是否来自同一特征版本、同一物品塔和同一更新时间，再考虑模型扩容。若新帖子、评论或视频常在入库数分钟内错过首轮分发，可用可写稀疏表保存训练产生的内容向量，并用作者、主题、文本类别等 always-on 特征为未命中候选提供可学习兜底。

落地时不必一次复制 Meta 全套基础设施。最小试点可包含四项：共享缓存表、精确 Writeback、训练期缓存读回评测、未命中掩码与通用特征兜底；随后再加入候选池无标签灌入和秒级流式传播。验收指标除了 nDCG/CTR，还应包含缓存覆盖率、向量 Time-to-Serve、训练—服务 NE/AUC 差距、新内容首次曝光时间、5 分钟与 1 小时分桶召回、发布计算成本。论文证明这类模型—系统协同能在中性服务成本下同时提高质量、可靠性和冷启动，但内部数据不可复现，外部团队应通过逐组件灰度和相同候选集合的受控 A/B 确认因果。