SOLARIS：把"投机解码"搬进推荐 serving——异步预计算基础模型表征，让昂贵的教师在推理时也能用¶

SOLARIS = Speculative Offloading of Latent-bAsed Representation for Inference Scaling（面向推理扩展的潜表征投机卸载）。来自 Meta AI（Menlo Park, California），作者 34 人，一作 Zikun Liu，通讯方向的资深作者含 Liang Luo、Wenlin Chen、Dong Liang、Ellie Wen 等（与 Meta 此前的 ELFM / Meta Lattice / Wukong 系列作者高度重合）。arXiv 2604.12110v2，2026-04-13 首次提交，cs.LG。

一句话：推荐基础模型（Foundation Model, FM）大到无法进在线时延路径，工业界只能退而求其次做知识蒸馏——而 soft-label 蒸馏的迁移率只有 20–25%，且只发生在训练期。SOLARIS 借用 LLM 投机解码（speculative decoding） 的思想，用一个轻量 verifier（就是当前线上的垂直模型自己）预测"未来请求里会出现哪些 对"，在后台异步跑 FM 把这些对的潜表征提前算好、压缩后写进带 TTL 的分布式缓存；线上垂直模型（Vertical Model, VM）只需查表把 embedding 当普通特征吃进去，推理期也能享用 FM 的知识，却不付出任何在线时延代价。已在 Meta 广告系统全量部署，日均服务十亿级请求，取得 0.67% 全球广告营收提升（约 $100M 量级）。

研究动机与背景¶

基础模型的能力与它进不去的那扇门¶

近年推荐系统的 scaling law 研究催生了一批规模空前的基础模型（FM）。现代 FM [20, 21, 36]（即 Meta 自家的 ELFM、Meta Lattice、Wukong 谱系）擅长从海量异构数据里学习复杂的 user-item 交互，在离线评估上持续拿到收益。

问题出在部署。FM 的计算复杂度使实时 serving 不现实，于是从业者只能把知识"转移"到更小的垂直模型（Vertical Model, VM）上。而行业标准做法——知识蒸馏——论文一针见血地指出它有两个瓶颈：

1. 迁移率与泛化性受限（Limited Transfer Ratio and Generalizability）：基于 soft label 的蒸馏 [2, 11, 17, 30] 通常只能达到 20–25% 的迁移率（transfer ratio），并且蒸出来的预测标签与特定任务紧耦合——换一个任务就得重蒸一次。
2. 可用性与覆盖受限（Limited Availability and Coverage）：知识转移只发生在训练期（标签可得的时候）[7, 9, 13]，推理期完全没有知识共享的机会。

这两条合起来指向同一个 root cause：昂贵的教师计算与时延关键的服务路径被绑死在同一个请求里。既然一个请求里塞不下 FM 的前向，那 FM 的知识就只能通过训练期的标签这条极窄的带宽渗透过来。

另一条既有路线：Embedding Sharing 及其代价¶

论文在 §2.2 把已有的知识转移手段分成两类：

• 知识蒸馏（Knowledge Distillation）：教师模型给出 soft label（类别上的概率分布），让学生不仅学到正确答案，还学到类别之间的相对相似性 [2, 11, 17, 30]。但在排序系统里，soft label 这一条通道能承载的信息量本身就有限，通常低于 25% [30]。
• 嵌入共享（Embedding Sharing）：把上游模型学到的表征直接当作下游任务的特征复用 [4, 5, 15, 16, 28, 38]。有效，但会带来显著的计算与存储开销。

SOLARIS 的定位正是站在第二条路线上，用系统设计去消解它的开销：方向选 embedding sharing（信息带宽宽），代价靠"投机式异步预计算 + 缓存"来摊掉。

SOLARIS 的三条核心创新¶

1. 直接的嵌入级迁移（Direct Embedding-based Transfer）：绕开 soft-label 蒸馏，直接把 FM 的 user-item 交互嵌入搬给 VM。表征更丰富、更可泛化，迁移率显著更高。
2. 投机式嵌入预计算（Speculative Embedding Precomputation）：受 LLM 投机解码 [18]（Leviathan et al., 2023）启发，预判哪些 user-item 交互在不久的将来会发生，异步把它们的嵌入算好。这样就实现了推理期的知识蒸馏——serving 时 VM 也能用上 FM 的表征。
3. 层级化特征补全（Hierarchical Feature Enrichment）：为了在不付出线性蒸馏成本的前提下最大化覆盖率，当某个 对没有直接命中时，退而使用用户级聚合嵌入和基于相似度（近邻用户）的嵌入，继续提供知识转移收益。

论文报告的整体收益：10+ 个生产模型上最高 0.2% 的相对 log loss（RLL）改善，覆盖率提升 30%，最终 全球广告营收 +0.67%（约 $100M 量级）。

多阶段排序里 SOLARIS 站在哪一环¶

现代推荐系统采用多阶段流水线 [25, 33, 39]：

1. 召回（Retrieval）[8, 14, 19]：用广义、轻量的准则（用户兴趣、广告定向）过滤物品；
2. 粗排（Early-stage ranking）[22, 40]：用轻量深度模型结合用户与广告特征，把候选收敛到数百个；
3. 精排（Final stage ranking）[3, 10, 23]：用资源密集型模型分析上千个信号（含实时用户行为），选出进入竞价与投放的 top items。

SOLARIS 服务的是精排模型——这一点很关键，因为它直接决定了后文讨论的"覆盖率天花板"（粗排的候选量是精排的 100 倍，覆盖不过来）。

核心方法 / 系统架构¶

3.1 系统总览¶

框架建立在一个洞察上：FM 在其中间层里学到了丰富的 user-item 交互表征，这些表征凝聚了来自海量数据集、多样特征和多目标优化的整体性知识。

SOLARIS 具体从 FM 架构的最后一个共享层（last shared layer） 抽取嵌入——论文认为这里"浓缩了关于 user-item 交互最相关的知识"。这个嵌入的计算发生在后台、异步进行；再配上层级化特征补全模块，以获得覆盖率被抬高且新鲜度有保障的嵌入。最终这些嵌入作为下游模型的输入特征增强性能。

从 Figure 1 可以读出完整数据流的四段：

Speculative Inputs → FM(Layer 0..N, 多任务共享栈)
      → SOLARIS FM Integration (Feature Extraction → Embed. Projector)
      → [Async] → 分布式缓存 (Rich User-Item Embedding)
      → Quality Control (TTL + Verifier)  /  Coverage+ (Similarity Search + Aggregation)
      → Hit / Miss 判定 → Vertical Model (Layer 0..N) + Real-time Inputs → Prediction

注意两条正交的控制轴：Quality Control 管"该不该留、还新不新鲜"（Verifier + TTL），Coverage+ 管"没命中怎么办"（相似度搜索 + 聚合）。这两条轴构成了 SOLARIS 全部的工程复杂度所在。

3.2 SOLARIS 的知识共享机制¶

传统 soft-label 蒸馏 [1, 6, 24] 只在训练期转移知识且效力有限。SOLARIS 用一套统一的、与 FM 无关（FM-agnostic）的范式实现持续的知识转移。

3.2.1 基础模型兼容性（Foundational Model Compatibility）¶

SOLARIS 适用于所有 multi-task multi-label 风格的 FM。以当前 SOTA FM 为例 [21, 34]（Meta Lattice、InterFormer），它们通过多条并行通路处理异构输入特征：

1. 稠密架构（dense architecture）：用多层感知机把连续特征变换为低维嵌入；
2. 稀疏架构（sparse architecture）：用 embedding bag collection 把类别特征转成池化后的嵌入；
3. 变长嵌入架构（variable-length embedding architecture）：从事件型特征中捕捉序列化的用户行为模式 [12, 26, 29, 32]。

三条通路的产出随后被送进一个共享的交互层栈（shared stack of interaction layers）[20, 31, 36, 37]（ELFM、DCNv2、Wukong、DHEN），产生共享网络输出（shared network output）。

为什么这个结构对 SOLARIS 至关重要：正因为多任务 FM 在分叉到各个 task head 之前有一段"共享躯干"，SOLARIS 才能在那里切一刀，拿到一个任务无关的表征。这正是它相对 soft-label 蒸馏的根本优势——soft label 是某个 task head 的产物，天然与任务绑定；共享层输出则可以喂给任意下游 VM，无论它预测的是 Facebook Feed CTR 还是 Offsite CVR。

3.2.2 SOLARIS 特征提取（Feature Extraction）¶

user-item 嵌入取自共享特征交互网络的输出，该网络处理的异构输入特征包括用户人口统计学特征、行为序列、物品属性。这个嵌入随后经一个自编码器（autoencoder）[27, 35] 压缩成一个紧凑的、固定维度的向量，以适合下游消费。该向量作为 VM 的额外输入特征。这套知识共享机制让 VM 得以利用 FM 在跨域训练中学到的丰富 user-item 交互模式。

形式化（论文以文字描述，此处按其叙述形式化以便阅读）。记 FM 的共享交互栈为 $g_{\text{shared}}(\cdot)$，用户 $u$ 与物品 $i$ 的异构输入为 $x_{u,i}$，自编码器编码端为 $\text{Enc}(\cdot)$，则 SOLARIS 缓存的表征为

$$z_{u,i} = \text{Enc}\big(g_{\text{shared}}(x_{u,i})\big) \in \mathbb{R}^{d}, \tag{1}$$

其中 $d$ 为固定的紧凑维度。VM 的预测则是

$$\hat{y}_{u,i} = f_{\text{VM}}\big(x^{\text{rt}}_{u,i},\, z_{u,i}\big), \tag{2}$$

$x^{\text{rt}}_{u,i}$ 是 VM 自己的实时输入特征（Figure 1 中的 Real-time Inputs）。式 (2) 表明 SOLARIS 对 VM 是非侵入式的：$z_{u,i}$ 只是多出来的一路特征，VM 结构无需改动。

3.2.3 推理期的知识共享（Knowledge Sharing During Inference Time）¶

FM 产出的丰富嵌入与其它输入特征存放在一起，被 VM 像普通特征一样消费——包括 serving 期。同时 FM 上会跑在线训练（online training） 以适应分布漂移。

这一段虽短，却是全文最重要的范式声明：知识转移从"训练期的一次性标签蒸馏"变成了"训练与推理期同时在线的特征供给"。soft-label 蒸馏在模型上线那一刻就断供了；SOLARIS 的通道一直开着。

3.3 异步预计算（Asynchronous Precompute）¶

为 user 池 × item 池的每一个 对生成 FM 交互表征是不可能的——基础设施的算力与存储成本高得离谱。因此 SOLARIS 提出选择性地通过异步预计算生成嵌入。

大致流程：SOLARIS 维护一个后台服务，用 FM 计算 user-item 嵌入。它接收用户级请求、评估这些请求中的候选物品、把生成的 user-item 嵌入缓存起来供未来的请求消费。异步预计算通过把嵌入生成挪到后台，放宽了时延预算；作为代价，这个做法牺牲了特征新鲜度以及 user-item 级的完整覆盖。

这句"trade-off"是整篇论文剩余部分的主线：后面所有的机制（Verifier、TTL、聚合、KNN 补全）都是在偿还这里欠下的两笔债——新鲜度债和覆盖率债。

后台教师计算（Background Teacher Computation）¶

当一个用户请求到来，多阶段排序把候选收敛到数百个。FM 维护后台任务，持续地从这些候选中挑出与该用户最相关的 top 20% 物品（由 verifier 机制决定）生成 user-item 嵌入。算好的嵌入存进分布式缓存，以 对为键。

Verifier 模型机制（Verifier Model Mechanism）¶

为进一步提升效率和缓存质量，SOLARIS 用一个轻量 verifier 模型——具体就是当前垂直模型给出的预测分数——来决定某个 对是该保留还是该丢弃。只有预测相关性足够高的对才会被选中做嵌入预计算与缓存。

这个机制扮演实时过滤器的角色，确保算力被集中在最有希望的候选上，并且——论文特意点明——与投机解码范式对齐：我们"投机（speculate）"哪些 user-item 对将会被需要，把其余的丢弃。

与 LLM 投机解码的类比要看准。在投机解码里，小的 draft model 先猜若干 token，大的 target model 并行验证。SOLARIS 里的角色分配是镜像的：轻量的 VM 扮演"猜"的角色（猜哪些对值得算），昂贵的 FM 扮演"算"的角色（异步补全表征），而"验证"发生在时间维度上——未来的真实请求是否命中缓存，就是这次投机是否成功的判决。因此这里的"投机"不是为了并行化解码步骤，而是为了在请求之间跨时间地摊薄教师成本。这一点与后文对比的 DaV-Gen / PAD-Rec 那类"在解码路径内部做投机"的工作有本质区别。

基于 TTL 的缓存失效（TTL-based Cache Invalidation）¶

异步预计算能成立，前提是用户偏好在短时间窗内是稳定的。论文给出的实证依据：在粗排阶段，用户偏好通常在几个小时内保持一致——观察到当前请求中超过 60% 的候选物品在过去六小时内被排过序。因此教师嵌入在这个窗口内仍然相关，使得 VM 在推理期无需实时教师计算即可获得增强。

训练与推理期间，VM 都会对每个 对查询缓存取回预计算嵌入。系统强制一个缓存读取 TTL（典型为数小时），在嵌入新鲜度与计算效率之间取平衡。

垂直模型 serving（Vertical Model Serving）¶

VM 把 user-item 嵌入作为额外输入特征改进预测。当某个 查询在缓存中缺失或过期时，该 user-item 对被排进 SOLARIS 模型的下一个刷新周期，同时 VM 输入侧用零张量（zero tensors）作为占位符。

零张量占位是个值得注意的工程选择：它意味着 VM 必须在训练期就见过"有嵌入"和"无嵌入"两种样本分布，才不至于在线上因大面积 miss 而分布漂移。论文没有展开这一点（例如是否做了 feature dropout 之类的训练侧对齐），是披露上的一个缺口。

3.4 层级化特征补全（Hierarchical Feature Enrichment）¶

异步预计算解决了效率，但由于 user × item 空间的巨大规模与基础设施约束，完整覆盖仍不可及。论文明确给出：原生的 user-item 嵌入覆盖率在其系统中约为 50%（§4.3 报告线上实际部署的覆盖是 40%，两处数字不一致，见"讨论与局限性"）。这个覆盖缺口在长尾物品、新用户、以及近期预计算周期未优先照顾到的新兴 user-item 交互上尤其严重。

为此 SOLARIS 实现了两条互补策略（对应 Figure 1 中的 SOLARIS Coverage+ 模块）。

策略一：聚合 user-item 嵌入（Aggregated user-item Embedding）¶

SOLARIS 引入一个聚合的 user-only 嵌入：把该用户在过去 24 小时内、跨不同物品的所有可得 user-item 嵌入做平均，并显式排除当前 user-item 对自身的嵌入。

形式化（论文以文字描述，此处形式化）：

$$\bar{z}_u = \frac{1}{|\mathcal{S}_u \setminus \{i\}|} \sum_{j \in \mathcal{S}_u \setminus \{i\}} z_{u,j}, \qquad \mathcal{S}_u = \{\, j : z_{u,j} \text{ 在过去 24h 内可得} \,\}. \tag{3}$$

其中排除当前物品 $i$ 是为了避免标签/特征泄漏式的自指——如果 $z_{u,i}$ 本来就在缓存里，那走的是 Hit 路径，用不着聚合；而在 Miss 路径上把 $z_{u,i}$ 计入是不可能的。

这个做法依赖的假设是用户偏好具有短期一致性，因而近期交互嵌入可以为当前预测提供信息。聚合 user-item 嵌入作为一路额外的输入特征，补充标准的 user-item 嵌入，把有效特征覆盖率抬到约 85–90%，确保绝大多数用户在推理时至少有某种形式的 FM 表征可用。

策略二：基于相似度的嵌入（Similarity-Based Embedding）¶

SOLARIS 维护一张预计算的用户聚类表，刻画用户相似关系。聚类过程分两个阶段：

1. 一个专用 FM 生成刻画丰富行为表征的用户级综合嵌入；
2. 用 k 近邻（KNN） 算法，基于嵌入空间的余弦相似度为每个目标用户找出相似用户。

对每一个缺少预计算嵌入的 user-item 对，SOLARIS 查询聚类表拿到目标用户的 top 相似用户；在这些相似用户中，搜索形如 的可得 user-item 嵌入。随后 SOLARIS 采用两种策略之一利用近邻嵌入：

1. 距离加权平均多个近邻嵌入——更近的用户获得成比例更高的权重；
2. 直接选取最相似的单个近邻的嵌入（基于用户特征空间中的邻近度）。

形式化（论文以文字描述，此处形式化）。记 $\mathcal{N}_k(u)$ 为 $u$ 的 top-$k$ 近邻，$w_{u,v} \propto \cos(\mathbf{e}_u, \mathbf{e}_v)$ 为距离权重，则两种策略分别是

$$\tilde{z}^{\text{avg}}_{u,i} = \frac{\sum_{v \in \mathcal{N}_k(u),\, z_{v,i} \text{ 可得}} w_{u,v}\, z_{v,i}}{\sum_{v \in \mathcal{N}_k(u),\, z_{v,i} \text{ 可得}} w_{u,v}}, \qquad \tilde{z}^{\text{top1}}_{u,i} = z_{v^\ast,i},\quad v^\ast = \arg\max_{v \in \mathcal{N}_k(u)} \cos(\mathbf{e}_u, \mathbf{e}_v). \tag{4}$$

这条基于相似度的路径把 FM 的有效覆盖率再扩展 30%。方法本质上利用了协同过滤原理：假定行为模式相似的用户对同一条广告会表现出可比的响应，从而为此前未见的交互提供有意义的信号。

两条策略的分工：聚合嵌入换的是"同一用户、别的物品"的知识（user 维度可靠、item 维度失配）；相似度嵌入换的是"别的用户、同一物品"的知识（item 维度可靠、user 维度失配）。它们在 user-item 矩阵上是正交的两种插值方向——这是论文没有明说但结构上很清晰的设计对称性。而 §5 的讨论也正是沿这条对称性展开：现在只做了 U2U（user-to-user），未来要探索 A2A（ad-to-ad）与混合策略。

实验设置¶

部署基线与方法论（Deployment Baseline and Methodology）¶

虽然框架适用于一般 user-item 场景，论文在 Meta ads 上验证。SOLARIS 已在覆盖全球用户的多种广告模型类型上部署。

• 基线：引入 SOLARIS 之前的生产系统——其中每个 portfolio 由一个在孤立数据集上训练的独立模型服务。
• 测试方式：SOLARIS 与基线同时对线上流量预测 CTR（Click-Through Rate）/ CVR（Conversion Rate），输入形式为 (user, ad) 对；排名最高的对结合预测与其它因素呈现给用户。
• 主要离线指标：相对 BCE（binary cross-entropy）loss 下降百分比，反映模型预测质量的改善。论文另用 RLL（relative log loss） 指代同一族指标。
• 子任务定义：每个任务类别内部的不同预测目标，对应特定的 surface 或用户动作（如 Facebook Feed CTR、Instagram Link Click CTR、Offsite Conversion）。

需要说明的是：论文没有任何公开学术数据集实验，也没有具名模型间的对照表——所有数字都是 Meta 内部生产环境的相对量。这直接限制了本文结果的可复现性与可比性（详见"讨论与局限性"）。

主要实验结果¶

表 1：SOLARIS 嵌入在多类任务上改善垂直模型¶

CTR 侧收益。SOLARIS 的 user-ad 嵌入在所有被评估的 surface 上一致地改善了 CTR 预估：Facebook Feed 降低 0.09% BCE loss，Facebook Reels 0.08%，Instagram Feed 与 Instagram Link Click 各 0.05%。论文的解读是：嵌入共享让模型能更好地捕捉 user-ad 交互模式，从而给出更准的点击概率估计。值得注意的是，收益不仅出现在主任务（Feed、Reels）上，也出现在辅助任务（Instagram Link Click）上，说明这套做法具有通用性——这正是"任务无关的共享层表征"相对"任务绑定的 soft label"的直接体现。

CVR 侧收益。在转化率任务上，SOLARIS 在站内与站外事件上都带来了明确的预测损失下降与更高的转化率：Facebook Feed + Reels 组合转化任务降低 0.10%（全表最高），站外转化（Offsite Conversion，即购买、注册等发生在 Meta 平台之外的事件）降低 0.05%。论文强调这凸显了嵌入式知识转移在转化信号稀疏、用户意图更难建模的场景中的有效性。

为什么 CVR 侧收益反而最高：转化标签稀疏、归因窗口长，VM 自身能从数据里学到的东西最少，因此从一个见过全域海量数据的 FM 那里"借"来的表征边际价值最大。这与 Meta 自家后来的 DUET 工作（见下文对比章节）在动机上完全一致。

迁移率（Transfer Ratio）：本文最硬的一个数字¶

SOLARIS 在 Instagram 任务上取得 42% 的迁移率，在 Facebook 产品线上取得 44%，相对此前基于蒸馏的方法是 2 倍（2X）提升（对照 §1 与 §2.2 给出的 soft-label 蒸馏 20–25%、"通常低于 25%" [30]）。论文把这作为其独特知识共享机制有效性的核心证据。

顶线业务收益¶

• 10+ 个生产模型上最高 0.2% 的相对 log loss（RLL） 改善；
• 覆盖率提升 30%；
• 全球广告营收 +0.67%，论文括注约 $100M 量级。

消融与分析：覆盖率才是真正的杠杆¶

论文的分析部分（§4.3）几乎全部围绕一个变量展开——覆盖率（coverage）。这是本文最有信息量的一节。

表 2：特征覆盖率 vs 性能¶

实验设计。如 §3.3 所述，SOLARIS 用异步预计算在 serving 期生成 user-ad 嵌入；生产环境部署下 user-ad 嵌入的覆盖率是 40%（覆盖率在生成标签（点击、转化等）的训练数据上计算）。为研究覆盖率对下游收益的影响，论文做了离线实验：离线 user-ad 嵌入由同一个 SOLARIS 模型生成，但发生在离线训练与评估阶段，因此覆盖率能接近 100%；随后对 user-ad 嵌入做降采样得到不同覆盖率，再加进下游模型。

结论。如表 2，覆盖率每提升 30 个百分点（20%→50%），log loss 改善 0.05%——论文称在其生产模型上这是"显著（significant）"的量级。这说明只要能把 SOLARIS 特征覆盖率推上去，就还有大量广告营收空间未被释放。

这张表的真正含义：覆盖率与收益是超线性的（20%→50% 换来 +0.05pp，60%→100% 换来 +0.17pp）。也就是说，SOLARIS 当前 40% 的线上覆盖率远在收益曲线最陡峭段的左侧，论文自己报告的 0.67% 营收提升只是这条曲线上一个很早的点。这既是本文最诚实的自我评估，也是它把"层级化补全"当作头等大事的原因。

聚合 user-ad 嵌入的效果¶

如 §3.4，聚合版本（user-only 嵌入）把覆盖率提升到 90%。生产部署中，user-only 嵌入作为一路独立特征部署，在 Instagram CTR 任务上取得额外 0.03% 的 BCE loss 改善。该 user-only 特征已部署到 10 个下游生产模型，并带来 +0.07% 的广告营收。

基于相似度的嵌入的效果¶

论文部署了一个 KNN 算子，为每个用户取 100 个相似近邻，用最相似近邻的 user-ad 嵌入填补缺失的 嵌入，把覆盖率从此前的 40% 提升到 70%。Instagram CTR 任务上的离线实验显示 BCE loss 改善 0.02%。

对照表 2 的覆盖率研究：同样是 +30pp 覆盖率，理论上应带来 0.05% 的改善，而相似度补全只拿到 0.02%，即 40% 的 headroom（0.02%/0.05%）。论文认为这符合预期，因为从近邻插补来的 user-ad 嵌入质量更低。

这是全文最有价值的一条负面结论：覆盖率不是等价的——"真嵌入的 30pp"与"插补嵌入的 30pp"价值差 2.5 倍。它把"提高覆盖率"这个目标拆成了两个不同性质的子问题：扩大真实预计算范围（贵但满值）与提升插补质量（便宜但打折）。论文在 §5 明确说当前 U2U 聚类"只带来有限的性能收益"，正是这一发现的直接延伸。

三条路径的横向汇总¶

核心贡献总结¶

1. 范式层面：把工业推荐的知识转移从"训练期 soft-label 蒸馏"推进到"训练 + 推理期的潜表征直供"，迁移率从 20–25% 翻倍到 42–44%，且因取自 FM 共享层而任务无关、可被任意 VM 复用。
2. 系统层面：用"投机 + 异步"把教师推理从请求关键路径上整体摘除——verifier（就是线上 VM 自己）挑 top 20% 候选、后台 FM 算表征、autoencoder 压缩、 键的分布式缓存 + 数小时 TTL、miss 走零张量占位并排入下一刷新周期。对 VM 零架构改动、零在线时延开销。
3. 覆盖率工程：识别出覆盖率（而非模型能力）才是这套范式的主瓶颈，并给出两条正交的插值补全路径（同用户跨物品聚合 / 跨用户同物品 KNN），把有效覆盖从 40% 推到 70–90%；同时诚实量化了插补嵌入只值真嵌入 40% 的事实。
4. 落地层面：Meta 广告系统全量部署、日均十亿级请求，10+ 生产模型最高 0.2% RLL 改善，全球广告营收 +0.67%（约 $100M 量级），其中 user-only 特征单独贡献 +0.07%。

与已归档相关工作的对比¶

AIR AIR: Atomic Intent Reasoning（香港理工大学 + 快手，2026-06-09）¶

关系：独立并发（本文未引用 AIR；AIR 晚于本文约 2 个月发表，时序上本文不可能引用，两者殊途同归）· 已加载对方精读

• 共同关注的问题：两篇论文指向同一个 root cause——一个能力远强于线上模型的大模型（SOLARIS 的推荐 FM / AIR 的 LLM）其单次前向的成本，与工业排序数十万 QPS、百毫秒级 p99 的时延预算在同一个请求内不可调和。AIR 把这条痛点写成"在线 LLM 推理在毫秒级延迟约束下代价高得不可接受；而周期性的离线用户画像更新又跟不上快速演化的用户兴趣"——后半句恰恰就是 SOLARIS 用 TTL 与 verifier 去应对的新鲜度债。
• 相近的技术骨架：两者的方法流程图可以抽象重合成同一张——离线/异步阶段用昂贵模型把语义算好并物化进一个高吞吐 KV 存储；在线阶段只做查表 + 轻量融合，绝不触发大模型前向；产物作为一路额外特征喂进既有的 CTR/CVR ranker。AIR 明确称之为"把 LLM 推理彻底从在线移到离线"，SOLARIS 称之为"decoupling the expensive knowledge transfer process from the latency-critical serving path"，是同一句话的两种说法。两者也都把最终产物接到 MMoE/DLRM 式的下游塔上，且都强调对下游不做架构改动。
• 本文的差异与推进：（1）缓存内容的形态根本不同——AIR 缓存的是离散、可解释、可组合的"原子行为-意图对"（LLM 生成的层级意图路径），SOLARIS 缓存的是连续、不可解释的 FM 共享层潜向量。离散意图对可以被自由重组，所以 AIR 天然不存在覆盖率问题；连续潜向量只能整体命中或整体丢失，覆盖率因此成了 SOLARIS 全部工程复杂度的来源。（2）缓存键的粒度不同——AIR 按"单个用户事件"建键（键空间 = 事件数），SOLARIS 按 对建键（键空间 = 用户 × 物品，组合爆炸），这正是 SOLARIS 必须引入 verifier 做投机筛选、并接受只有 40% 覆盖的直接后果。（3）SOLARIS 多出了一整套 AIR 不需要的覆盖率补全层（聚合嵌入 + KNN 近邻插补）。
• 可比的方法/实验差异：AIR 报告的是相对实时 LLM 调用约 400× 的吞吐增益与快手电商 +3.446% GMV；SOLARIS 报告的是 0.67% 全球广告营收与 42–44% 迁移率。两者都只有工业指标、都无公开数据集上的端到端对照，可比性受限。方法论上更值得对照的是新鲜度策略：AIR 用节点级"多行为计数 × 时间衰减"的偏好权重在线重算意图树，把陈旧性问题吸收进打分函数；SOLARIS 则用一刀切的数小时 TTL 加上"60% 候选在过去 6 小时内被排过序"的经验统计来兜底——后者显然更粗糙，也是 SOLARIS 可改进的明显空档。

DUET DUET: Dual User Embedding Transformers（Meta，2026-06-08）¶

关系：独立并发（本文未引用 DUET；DUET 晚于本文约 2 个月发表，时序上本文不可能引用；两者是同一公司同一业务线上的两条平行解法）· 已加载对方精读

• 共同关注的问题：两篇都出自 Meta 广告，都在回答"表达力强的上游模型算力开销大，直接部署到延迟敏感的 serving 路径上不现实"这同一句话。DUET 的原文表述与 SOLARIS 的开篇几乎逐字对应，且 DUET 同样把出路定位在"解耦设计：上游模型离线预训练丰富的用户嵌入，再作为静态嵌入特征异步地喂给 ranker"。两者的下游落点也一致——Meta 广告的 CTR / CVR（含 Offsite Conversion）精排模型，SOLARIS 的表 1 里那一行 Offsite Conversion 正是 DUET 的整个主战场。
• 相近的技术骨架：抽象后是同一张图——上游大模型离线/异步产出表征 → 冻结（不回传梯度）→ 量化压缩 → 写入 feature store → 下游 ranker 当额外输入特征消费，不改架构。连工程细节都成对出现：DUET 的事件触发推理（ETI）对应 SOLARIS 的后台预计算 + verifier 触发（都用"用户侧发生了某个够格的动作"来决定何时刷新，从而让高价值用户拿到更新鲜的表征）；DUET 的 SIDE 量化（相对 FP16 达 4× 压缩）对应 SOLARIS 的 autoencoder 压缩成固定维紧凑向量；DUET 的 checkpoint 校验与限流窗口，对应 SOLARIS 的 TTL 与 Quality Control 模块。
• 本文的差异与推进：最关键的差异在表征的键粒度。DUET 产出的是 user-level 嵌入（ClickAUE / ConvAUE），键空间就是用户数，因此天然 100% 覆盖，DUET 全文根本不需要讨论覆盖率；SOLARIS 押注的是 pair-level 嵌入——它承载的是交互信息而非单侧的用户画像，信息量更高（这正是 42–44% 迁移率的来源），但代价是键空间组合爆炸、覆盖率只有 40%。有趣的是，SOLARIS 的"聚合 user-only 嵌入"（式 (3)）本质上就是用 pair 嵌入的平均去逼近一个 user-level 嵌入——也就是说，SOLARIS 在 Miss 路径上会退化成 DUET 那一类表征，而它在生产上的增量只有 +0.03% BCE 与 +0.07% 营收。这个数字反过来说明：pair-level 相对 user-level 的增益是真实的，但只有在真正命中时才拿得到。另一条差异是 DUET 在上游做了统计机制驱动的架构分流（稠密点击流用堆叠自注意力、稀疏转化流用交错交叉/自注意力），而 SOLARIS 对 FM 内部结构完全不可知（FM-agnostic），只从"最后一个共享层"切一刀——更通用，但也放弃了针对下游任务定制上游的机会。
• 可比的方法/实验差异：DUET 报告相对最强 baseline 至多 0.38% 的 NE 下降与线上 +0.66% / +0.15% 的 CVR 提升；SOLARIS 报告 10+ 模型上最高 0.2% RLL 与 +0.67% 营收。两者指标族接近（都是归一化熵/log loss 相对量）但基线定义不同（DUET 对比的是单流上游预训练范式，SOLARIS 对比的是"上线前的生产系统"），不能直接相减比较。可以确定的是两条路线互补而非互斥——DUET 补的是用户侧长期画像，SOLARIS 补的是 user-item 交互，理论上可以叠加。

TransX TransX: Scaling Transformer-based Recommendation via Behavior/Serving Stream Crossing（LinkedIn，2026-07-31）¶

关系：独立并发（本文未引用 TransX；TransX 晚于本文约 3 个半月发表，时序上本文不可能引用）· 已加载对方精读

• 共同关注的问题：TransX 的第二条动机——"计算重复：如果每次曝光、每个候选都重新编码完整行为前缀，训练复杂度会被服务事件数 $T$ 乘上，在线成本也随历史长度 $L$ 增长"——与 SOLARIS 的"每个请求都跑一遍 FM 不可行"是同一个结构性瓶颈的两种表达。TransX 的核心判断"长期行为表示天然可以按用户近线增量计算，而实时请求只应承担候选特定的轻量 crossing"，几乎就是 SOLARIS "把昂贵的知识转移从时延关键路径上解耦"的逐句翻译。
• 相近的技术骨架：两者都实现了"离线/近线算重的那一半 → 持久化进带版本与失效策略的缓存 → 在线只做轻量的候选相关计算 → miss 有明确回退路径"。TransX 的近线管道在新行为到达时增量更新用户编码并持久化到 per-viewer on-disk cache，缓存用 bf16 代替 float32；cache 以 model ID 与 feature-schema version 联合版本化，并配置 TTL/LRU；约 2% 无行为缓存的 cold-start 流量回退到不含 behavior encoder 的轻量模型。这三点分别对应 SOLARIS 的 autoencoder 压缩、数小时 TTL 的缓存失效、以及 miss 时的零张量占位 + 排入下一刷新周期。TransX 甚至也分了两类刷新触发器（高活跃用户用 Kafka event trigger 增量更新、其他用户用 HDFS time trigger 批量刷新），与 SOLARIS 的 verifier 触发式预计算属于同一设计家族。
• 本文的差异与推进：（1）跨模型 vs 模型内——TransX 缓存的是自己模型内部的用户侧中间表示（行为流 encoder 的输出），本质是把单个模型沿"是否依赖候选"切成两半；SOLARIS 缓存的是一个外部的、更大的教师 FM 的表征，本质是跨模型的知识迁移。这决定了 SOLARIS 多了一层 TransX 没有的问题：教师与学生异步演化（FM 在跑在线训练、VM 在独立重训），表征语义可能漂移，论文对此未作讨论。（2）缓存键——TransX 按 user 建键，因此覆盖近乎完备（仅 2% cold-start miss）；SOLARIS 按 建键，miss 率高达 60%。这再次印证前两条对比的同一结论：pair-level 是本文的高风险高收益押注。（3）TransX 的在线复杂度有严格的形式化保证（每事件 $O(md^2+mL_{\text{local}}d+mkd)$，与完整历史长度 $L$ 无关），而 SOLARIS 全文没有给出任何复杂度或成本模型——连"后台预计算消耗多少算力"这一最关键的成本项都未披露。
• 可比的方法/实验差异：TransX 报告 LinkedIn 线上 CTR +6.0%、转化 +4.4%、在线计算约降低 80%；SOLARIS 报告营收 +0.67%、且强调"no additional overheads"但未量化后台成本。两者的收益量级不可直接比较（业务、基线、指标定义均不同），但成本侧的披露差距很能说明问题：TransX 把"省了多少"作为核心卖点并给出 80% 这个数字，SOLARIS 则只说线上没有额外开销、回避了后台那笔账。

被剔除的近似候选（记录于此以防门槛放水）： - Rec-Distill Rec-Distill（ByteDance AML，2026-05-28）——问题高度同构（它把蒸馏收益分解为"教师 scaling 收益 × 可迁移性 η"，正对 SOLARIS 的 42–44% vs 20–25% 迁移率之争，且报告峰值 η > 60%），但解法仍完整地留在 logit/CE 软标签蒸馏范式内（解耦双塔学生 + 黑盒 CE 蒸馏 + 学生侧去偏 + 批流混合流水线），而 SOLARIS 的立论恰恰是跳出 soft-label 通道、改走潜表征直供 + 请求外异步物化。解法骨架不重合，剔除。时序上 Rec-Distill 亦晚于本文。 - Zero-shot CDKD Zero-shot CDKD（Google，2026-03-30）——唯一一篇比本文更早（早 14 天）却未被本文引用的近似候选，因此若同构就构成真正的独立并发。但它的问题是"无共享训练数据下把 YouTube 视频教师的知识零样本迁移给低流量 YouTube Music 学生"，解法是跨域软标签蒸馏；既没有"把教师计算移出在线路径"的动机，也没有预计算/缓存/覆盖率这条骨架。两者只在"知识迁移"这一过宽的层面相交，剔除。 - DaV-Gen DaV-Gen（Alibaba，2026-07-09）与 PAD-Rec PAD-Rec（USTC，2026-04-30）——两者都明确以 speculative decoding 为灵感，与本文字面同源、最易误判。但它们的"投机"发生在生成式检索的解码路径内部（ANN 向量起草 + 一次并行前向验证 / SID draft model 结构感知），解决的是自回归逐 token 解码的步数与时延；SOLARIS 的"投机"发生在请求之间的时间轴上——预测未来请求会需要哪些 对并提前算好。问题层与解法层均不重合，剔除。 - Mosaic Mosaic（Meta，2026-07-27）——同属"上游冻结表征供多下游 ranker 复用"的大类，但其核心问题是"如何组织一支互补的用户表征专家舰队、最大化每个新专家的边际信息"（余弦冗余损失 + 免打点评估 CoEval），没有"预测未来请求 + 投机预计算"这条主轴。同为 Meta 的候选中，DUET 的 ETI 异步 serving 与 SOLARIS 骨架同构度明显更高，故保留 DUET 而剔除 Mosaic。 - OneTrans OneTrans（ByteDance，2025-10-30）——其 cross-request KV caching 同样是"跨请求复用已算好的中间状态"，但复用的是模型自身的 KV cache，既无教师/学生分离也无投机筛选，论文主线是统一 Transformer 骨干的 scaling 效率。剔除。

讨论与局限性¶

论文自陈的局限¶

进一步提升覆盖率。当前用于提升覆盖率的聚类方法在垂直模型上只产生有限的性能收益（对应 §4.3 那个 40% headroom 的数字）。作者表示后续会把工作从本文的 U2U（user-to-user）方案扩展到 A2A（ad-to-ad）与混合策略。

早期阶段的推广受阻。SOLARIS 只在精排（final ranking stage）的垂直模型上可用且有益。原因是更早的排序阶段涉及100 倍数量的广告，覆盖率与资源约束都成为重大挑战。鉴于早期阶段模型空间巨大，作者正在努力提升嵌入覆盖率，以期解锁更大的营收潜力。

通用性局限。作者承认，虽然力求分享广泛适用的部署洞察，但部分发现本质上是公司特定的——Meta 的业务需求与合作伙伴关系塑造了 SOLARIS 所处理的问题空间，这可能限制某些结果的可推广性。

值得借鉴的设计¶

1. "用学生当 verifier"是个便宜且自洽的设计。SOLARIS 没有为投机筛选另训一个模型，而是直接复用线上 VM 的预测分数。这在工程上几乎零成本，在语义上也自洽——VM 认为相关的对，正是未来最可能真的被排进 top 的对。这个"用下游的判断去调度上游的算力"的模式，可以迁移到任何"昂贵教师 + 廉价学生"的工业系统。
2. 切在共享层是范式级的选择。取 task head 之前的共享表征，一举解决了 soft-label 蒸馏"换任务就要重蒸"的痛点，让一次预计算供 10+ 个下游模型消费。这是本文迁移率翻倍的结构性原因，而不只是工程调优的结果。
3. 两条正交的插值补全路径。同用户跨物品（聚合）与跨用户同物品（KNN）在 user-item 矩阵上是两个正交方向，这个对称性给出了清晰的后续路线图（论文自己也点到了 A2A）。
4. 诚实量化插补质量折扣。"+30pp 覆盖率只拿到 40% headroom"这条负面结论比任何正面数字都有价值——它告诉后来者，覆盖率不是一个标量目标，真嵌入与插补嵌入必须分开计价。

我认为存在的问题¶

1. 成本侧完全未披露，是本文最大的缺口。全文反复强调"no additional overheads"，但那只是在线时延层面的说法。后台异步预计算要为每个用户请求的 top 20% 候选跑 FM 前向，这笔算力在总体 TCO 里绝不小；论文既没给后台 QPS、GPU 用量，也没给缓存的存储规模与成本。在一篇以"效率"为卖点的系统论文里，只报收益不报成本，结论的说服力大打折扣。相比之下 TransX 明确报告"在线计算降低约 80%"、DUET 明确报告"SIDE 相对 FP16 达 4× 压缩且对下游 NE 影响可忽略"，都比本文交代得清楚。
2. 数据前后不一致。§3.4 称"原生 user-item 嵌入覆盖率约为 50%"、聚合后"约 85–90%"；而 §4.3 称生产部署覆盖率是 40%、聚合后是 90%。这两组数字无法同时成立（除非它们分别指不同 surface 或不同时间点，但论文没有说明）。类似地，表 1 的 Instagram CTR 报 0.05%，表 2 在 40% 覆盖率附近插值出的量级也是 0.05% 上下，但表 1 的数字究竟是否已经包含了聚合与 KNN 补全的贡献，论文没有交代——而 §4.3 又说聚合是"额外 +0.03%"，读者无法拼出一张自洽的收益归因表。
3. 实验严谨度偏薄。没有任何公开学术数据集、没有具名 baseline 的对照表、没有统计显著性说明、没有 A/B 的流量规模与时长。"基线 = 上线前的生产系统"这种定义使得读者无法判断收益中有多少来自 SOLARIS 本身、多少来自同期的其它变更。表 2 的覆盖率消融是全文唯一一个像样的受控实验，但它是离线降采样得到的，与线上真实 miss 的分布（长尾物品、新用户系统性缺失）并不同分布——真实 miss 不是随机降采样，因此表 2 很可能高估了提升覆盖率的边际收益。
4. 方法披露极浅。5 页篇幅、零公式、零算法伪代码。autoencoder 的结构与训练目标、嵌入维度、缓存规模、verifier 阈值如何选、top 20% 这个比例怎么定的、零张量占位是否配合了训练侧的 feature dropout——全部缺失。本文更接近一份工程实践简报而非可复现的方法论文。
5. 解耦范式的长期上限。这是本文最本质的隐患：教师 FM 与学生 VM 之间隔着一层冻结的、滞后数小时的缓存，二者无法端到端联合优化。FM 在跑在线训练、VM 在独立重训，两侧的表征语义会持续漂移，而论文对此只字未提（既无监控方案也无对齐机制）。同时，缓存表征的维度一旦固定，就把下游能吸收的信息量锁死了——当 FM 继续 scaling 时，那个被 autoencoder 压扁的固定维向量是否还装得下增量知识，是没有答案的。这正是"先离线压缩再在线消费"这类两阶段范式的共性瓶颈。
6. 新鲜度策略过于粗糙。整套新鲜度控制就是一个全局的数小时 TTL，依据是"60% 的候选在过去 6 小时内被排过序"这一条统计。但用户兴趣的漂移速度显然是异质的——高活跃用户、突发兴趣、促销时段都会打破这个假设。对照 AIR 用节点级"计数 × 时间衰减"把陈旧性吸收进打分、TransX 按用户活跃度分两类刷新触发器，SOLARIS 的一刀切 TTL 是个明显可改进的空档。

工业落地价值¶

尽管上述保留意见，本文的工业价值仍然很高，且这个价值不依赖于 Meta 的具体实现：

• 可迁移的核心洞察：任何拥有"大到上不了线的模型"的团队都面临同一个结构性选择——是接受蒸馏的信息损耗，还是想办法把教师计算挪到请求之外。SOLARIS 给出了后者的一套完整答案，且这套答案（verifier 投机筛选 + 共享层切分 + TTL 缓存 + 层级补全）在 Meta 之外同样成立。
• 明确的实施路线：论文实际上给出了一条渐进式落地路径——先做 pair-level 真嵌入（拿最高价值但覆盖低），再叠 user-level 聚合（覆盖冲到 90%、单独就值 +0.07% 营收），最后补 KNN 插值（便宜地再拿 40% headroom）。每一步都能独立上线、独立度量。
• 收益曲线尚未走完：表 2 已经指明，40% 的覆盖率远在收益曲线的陡峭段左侧。这既是本文的局限，也是它对后来者最有用的信息——这条路线的天花板比论文报告的 0.67% 高得多。