检索模型与 GPU 系统协同设计：把收益拆成可核对的四层

Meta 在 2026 年 10 月 28 日的工程博客中介绍了新一代广告检索引擎 Andromeda，把效率提升归因于模型、系统与 GPU 硬件的协同设计（Engineering at Meta，2026-10-28）。对做检索系统的开发者来说，这篇文章的价值不在结论，而在它把一次架构改动拆成了可讨论的几块。问题在于：这些数字口径不同，不能整段照搬。

下面只做一件事——把"协同设计带来收益"这句话拆成可以分别核对的小块，标明每块的测量对象、对照基期、单位和测量边界，再指出哪些还核不了。先说明材料状态：抓取到的正文在"把索引匹配搬到 GPU"一节处被截断，涉及该部分的实现细节与结论待核实。

一、先拆层：四类收益，四种口径#

原文的叙事是一条因果链：候选池膨胀（生成式创意工具让广告主快速产出数亿条新广告）→ 旧架构在内存带宽与网络上撞墙 → 换成检索 MoE 模型 + 融合 kernel + 同卡部署 → 得到吞吐与转化收益。这条链在工程上成立，但它把四类不同性质的收益串在了一起：

• 模型层：用 MoE 门控替代稠密交互网络，在接近精排质量的前提下把推理 FLOPs 降下来。
• 系统层：把模型计算与非模型逻辑（索引匹配、打分、top-K）融进一个 kernel，中间结果留在寄存器和共享内存，不写回 HBM。
• 硬件层：整套流程收敛到单块 GH200 上，把跨主机流量压掉。
• 业务层：转化率一类的产品指标。

这四层的分母不同。模型层看 FLOPs，系统层看每请求内存流量与网络字节数，硬件层看单卡利用率，业务层看转化。任何一句"提升了 N 倍"如果不说是哪一层，就无法核对。

二、逐项核对：材料里的四个数字#

1. 吞吐：文中出现三个量级，边界不同

原文在概述处写的是生产系统每秒处理"超过 10 亿"广告，作为相较 2024 年系统的 100 倍提升；在架构一节写的是单块 GH200 上模型推理吞吐"超过每秒 100 亿"；在讲同卡部署之前，又说融合 kernel 单独测量时是"每秒数十亿"级。三个数字都不是笔误，而是测量边界不同：隔离测量的 kernel、单卡模型推理、生产端到端链路，是三个不同的东西。原文明确区分了"Measured in isolation"与生产表现，这一点值得学。

可以做一个口径自洽性检查（下面是根据文中数字做的算术对照，不是核验过的实测）：原文提到 2024 年系统是"每卡每秒数千万"广告，若取 108 为基期，1010/108 约为 100 倍，与"100x"吻合；若取 107，则约为 1000 倍。材料没有给出确切基期值，所以这个检查只能说明倍数的量级不算离谱，不能当作性能已经核实。

2. 约 300 倍 FLOPs：效率声明必须绑定质量目标

"约 300 倍"指的是推理期 FLOPs 相对 2024 年检索模型降低，前提是模型性能"接近精排级"。这两个词要一起读：脱离质量谈 FLOPs 没有意义，脱离 FLOPs 谈"接近精排"也没有意义。原文把两者画成一条新的帕累托前沿，这是正确的表述方式，但也意味着单独引用任何一个数字都会失真。

另外，FLOPs 不等于成本。原文自己指出，在每秒数十亿级的吞吐下，瓶颈是内存带宽而非算术：kernel 之间的中间张量每秒产生 TB 级 HBM 流量。所以核对成本时应该看每请求 HBM 读写字节数，而不只是 FLOPs。

3. 约 100 倍网络流量：分子分母都要说清

同卡部署的做法是：把索引匹配（执行广告主的定向规则）、打分、top-K 选择放在同一块 GPU 上，客户端只发一份紧凑负载（用户特征 + 定向查询），返回最终 top-K。对照的是旧做法——把大候选列表跨主机传输。倍数怎么算，取决于分子是"每请求字节数"还是"每秒字节数"，原文只给了倍数没给单位。把索引匹配搬上 GPU 后，定向规则的实时更新怎么保证，属于被截断的那部分，待核实。

4. +2.4% 转化：业务指标不能反推单点贡献

"自 2025 年以来 Facebook 转化提升 2.4%"是产品级累计指标，时间窗跨越了模型、系统、硬件多轮改动，也没有给出置信区间或分母。它可以支持"这套系统对业务有正向作用"，但不能支持"MoE 门控贡献了 2.4%"。把业务指标拆到技术组件，需要的是消融实验，不是时间序列。

三、在自己的系统里怎么拆：2×2 与固定延迟预算#

协同设计最容易被含糊处理的地方是：两个改动一起上，收益算谁的。最小可行的拆法是做一个 2×2 对照，把"交互项"单独算出来。

如果 D − A 明显大于 (C − A) + (B − A)，差额就是协同收益，也是"协同"这个说法唯一能被证伪的地方。实操中四项很难完全正交——新模型可能只有在融合 kernel 下才跑得进延迟预算，这时 C 这一格跑不出来，应如实记为"不可单独测量"，而不是补一个估算值填上。

还有两个约束要写进对照，否则吞吐数字会虚高：

• 延迟预算。原文强调收益是在"相同的延迟预算内"取得的。核对时应把 p99 延迟作为固定条件，而不是结果变量；否则放宽延迟换来的吞吐提升会被误记成架构收益。
• 内存与网络用字节度量。以每请求 HBM 字节数、每请求网络字节数为主指标，kernel 耗时为辅。这是针对原文"内存带宽成为新瓶颈"的推论性建议，不是原文给出的方法。

四、记录格式：把"待核实"写进字段#

下面的片段是记录格式示例，未执行，也不含任何真实测量结果，只用于说明一条性能声明至少需要哪些字段才能被别人复核。

# 声明记录模板（示例，未执行）
claim: "单卡吞吐 > 10B ads/s"
layer: system          # model | system | hardware | business
object: "单块 GH200 上的融合 kernel"
baseline: "2024 年检索模型"
unit: "ads/s/card"
boundary: isolated     # isolated | end-to-end
includes_index_match: unknown
includes_topk: unknown
latency_budget_ms: unknown
hbm_bytes_per_request: unknown
status: partially-verified
source: "https://engineering.fb.com/2026/10/28/ml-applications/meta-andromeda-next-gen-ads-retrieval-gpu-co-design/"

写法上有一个原则：字段为空就写 unknown，不要用推算值填。材料只有摘要或正文被截断时，正确表述是"本次材料未提供"，而不是"官方没有说明"。

五、适用边界#

这套拆法适用于广告、推荐、搜索这类"检索—精排"两段式系统，且候选池规模大到内存带宽成为瓶颈的场景。搬到别的场景前要先确认三点是否成立：候选池是否同样达到需要每秒数十亿次打分的量级；延迟预算是否同样在毫秒级；硬件是否同为 GH200 一类带大容量 HBM 的加速卡。原文的方法论——先找瓶颈在哪一层，再让模型结构去迁就执行模型——比任何一个具体倍数都更可迁移。至于索引匹配上 GPU 之后的规则一致性与更新机制，需等原文补全后再核对。