The Clustering Strikes Back: Helmsman ANNS (Xiaohongshu) — 深度解读

1. 问题与动机

小红书（RedNote）的搜索/推荐/广告全靠内存 HNSW 做 ANNS，到 2025 年内存 HNSW 索引消耗 PB 级 DRAM，仅搜索就吃掉数百 TB。核心矛盾是成本-性能错配：内存部署提供 100% 吞吐，但维持延迟 SLA 只需要其中 32–43%，剩下 57–68% 的 DRAM 纯粹为容量买单；而 DRAM 8 $/GB vs Gen5 SSD 0.2 $/GB，这种浪费经济上不可持续。图索引混合方案也救不了：在 96 核 + 12 块 PCIe Gen5 SSD 上实测 DiskANN/Starling/PipeANN 都无法满足 5–10ms 平均延迟 SLA，PipeANN 因串行依赖链 I/O 把 SSD-DRAM 之间 10²–10³ 的延迟差放大，吞吐只有 HNSW 的 1/10–1/25。问题落到：能否用全闪存把 DRAM 成本砍掉、又不破 SLA。

2. 方法详解

硬件底座：全闪存服务器（12×2TB PCIe Gen5 NVMe SSD + 12×96GB DDR5 + 96 核）。
在线 serving 流水线：① Router 模型按 query 预测 nprobe（探查簇数）；② DRAM 里的 Centroid Graph 定位最近簇；③ Leveling 剪枝模型进一步过滤候选；④ 经 SPDK 直接 NVMe I/O 异步加载簇 posting list；⑤ 距离计算排出 top-k。
面向 ANNS 的用户态存储栈（§4.2）：metadata 用普通文件，簇列表作为裸逻辑块存 SSD；绕过内核做 direct device I/O，固定 12KB 簇读；批量提交 NVMe 命令、每批只敲一次 PCIe doorbell；64MB 粒度的 chunk free-list 分配器管空间。profiling 发现传统 libaio/io_uring 栈占了高达 58% 的 I/O 开销，换 SPDK 才能达到每搜索线程 120–170 KIOPS 的需求。
Leveling-Learned Search Pruning（LLSP，§4.3）：GBDT router 模型按 query+top-k 预测最大搜索范围；多级剪枝模型在不依赖中间结果反馈的前提下逐 query 精修 nprobe（从而保住批量 I/O）；特征含 query 向量、top-k、质心距离分布比；离线用大 nprobe(~4096) 的非剪枝搜索近似 ground truth 训练。之所以不学 Quake/LAET/Auncel 那种迭代式 probe-compute-decide，是因为它们会串行化簇 I/O、压低带宽利用率。
GPU 加速弹性建索引（§4.4）三阶段：① GPU 粗聚类（FAISS k-means，多 GPU，对百万级向量约 10× 加速）；② 弹性细粒度均衡（分布式 CPU worker 最多 1 万核，在低峰拆分/再平衡簇，QoS 抢占保在线流量）；③ merge & finalize（多核服务器合并分片、建质心图、训剪枝模型）。

3. 核心技术贡献

① 给在线 ANNS「复活」了聚类路线：证明现代高带宽 NVMe 阵列（Gen5 约 12GB/s）让聚类方案能在满足 SLA 的同时靠批量 I/O 扩吞吐，颠覆「只有图索引才能上线」的默认。② 定制 I/O 栈：SPDK 用户态直接 device steering，Gen4 上 85%、Gen5 上 70% 带宽利用率，远高于 SPANN 的 26–59%、图基线的 <20%。③ 无中间反馈的 query 自适应剪枝：LLSP 在保持批量 I/O 友好的同时处理可变 top-k 与 query 分布，保证 >80% 的 query 达到 90% recall 目标。④ 异构弹性建索引：GPU + 弹性 CPU 池让 0.1B 向量亚小时、10B 向量小时级建完。

4. 实验结果分析

搜索性能（SIFT100M，90% recall）：吞吐比现有 DRAM-SSD ANNS 高 2–16×，达到内存 HNSW 吞吐的 85% 且始终满足平均延迟 SLA。在 RedSrch10B 上，单节点对比 10 shard 拿到 HNSW 吞吐的 47–85%，同时 CPU 核数少 3–4×、DRAM 少约 10×；P99.9 尾延迟稳定在约 10ms，而图基线尾延迟急剧恶化。
带宽利用率（RedSrch0.5B）：Helmsman Gen4 约 85%、Gen5 约 70%，SPANN Gen4 仅 55%，图基线 <20%；升级到 Gen5 后 Helmsman 吞吐提升 55–87%，基线只涨 10–30%（说明基线吃不到新硬件红利）。
剪枝效率：LLSP 比无剪枝快 1.1–1.6×，比固定剪枝策略高 5–25%；质量上固定策略对 >40% 的 query 达不到目标 recall，LLSP 保证 >80% 达 90% 目标。
建索引：GPU 加速对 0.1B 向量约 10× 提速，从 9–12 小时降到 1 小时内；10B 向量从 >16 小时降到 4–7 小时（最多借 1 万在线集群 CPU 核）。
成本效率（Table 4–5）：RedSrch0.5B 上 Helmsman 250 QPS/$，HNSW 仅 51、SPANN 88；RedSrch10B 上靠砍 90% DRAM 拿到 8.3× 成本效率（10 QPS/$ vs HNSW 1.2）。单节点 96 核 +4 GPU 建索引成本是纯 CPU HNSW 的 1.7×，但建索引时间效率更高。

5. 局限与未来方向

作者明确列出四点：① SSD die 级热点冲突——query 突发打同一批簇会引发芯片内部冲突，用冗余簇副本缓解也只有 1.5–2× 吞吐提升；② 内存带宽瓶颈——12 块 Gen5 SSD 提供约 140GB/s 但只有约 70% 可用，因为 DDR5 有效带宽 300–350GB/s 要同时服务 SSD→DRAM、DRAM→CPU、最近质心搜索，加到 20 块 SSD 收益递减；③ 原地更新——25–30 KOPS 更新与 25–30 KQPS 搜索并发已超现有大规模动态 ANNS 系统，当前用「周期重建 + 辅助内存 HNSW + tombstone 位图」的混合设计，额外吃内存与重建成本；④ top-k 评测缺口——学界惯用 recall@10，但生产要 top-k 100–1000 且 90% recall，未来 benchmark 应反映多阶段流水线。

6. 工业实践意义

这是给自建向量检索、被 DRAM 成本压制团队的一份直接施工图。落地结论：① 生产部署约 40 台全闪存服务器（每台 0.7–1.1TB DRAM + 12 SSD），承载了原先约 35000 核 + 0.35 PB DRAM 的负载，硬件成本降 >90%，已稳定运行数月，小红书计划迁移大部分内存部署、预期年省数千万美元。② 可借鉴的设计点：用 router 模型预测 nprobe，把「按 query 花预算」做成学习问题；I/O 别走内核（libaio/io_uring 能吃掉 58% 开销），上 SPDK 用户态 + 固定 12KB 簇读 + 批量 doorbell；建索引把 GPU k-means + 低峰借在线集群 CPU 核结合，能把 10B 级建索引从天级压到小时级。③ 关键认知：大规模召回瓶颈已从「召回精度」转向「内存/成本」，且内存 HNSW 有 57–68% 的 DRAM 是为容量而非吞吐买单，这部分正是全闪存能吃下的红利。④ 注意硬件天花板：SSD 加到一定数量受 DDR5 带宽限制收益递减，热点与高频更新仍是软肋，强更新场景需谨慎。代码开源于 github.com/Red-EAD/helmsman。