40 台服务器干翻 35000 核 + 350TB 内存——小红书把向量检索塞进 SSD,砸掉了 90% 的硬件账单

40 台服务器干翻 35000 核 + 350TB 内存——小红书把向量检索塞进 SSD,砸掉了 90% 的硬件账单

2026 年 7 月,小红书引擎架构团队的论文《The Clustering Strikes Back: Building Cost-Effective and High-Performance ANNS at Scale with HELMSMAN》入选 OSDI 2026(论文地址 https://arxiv.org/abs/2606.13145)。在这篇工作里,他们用大约 40 台全闪存服务器,稳定承载了过去约 35,000 CPU Core 和约 350 TB DRAM 才能支撑的在线向量检索负载——硬件成本节省超过 90%(来源:机器之心 2026-07-23 报道)。

对一家内容平台来说,这是把向量检索这条基础设施从「按内存扩容」强行拽到了「按工作负载定制」的轨道上。

<!-- 配图 1:三阶段基础设施变迁(Mermaid 时序/流程图) -->

一、DRAM 这条路已经走到头

向量检索(ANNS,近似最近邻搜索)是搜索、推荐、广告、内容安全、RAG 这类系统的核心底座——线上服务要维护单索引数百亿规模的高维向量,同时扛住每秒百万级查询,延迟还要压到毫秒级。

过去十年这条路的标准答案只有一个:内存图索引。HNSW 一类的图结构把所有数据和边都放在 DRAM 里,贪心搜索 + 多分片并行,稳、准、快。

但这条路的成本曲线已经失控了。

小红书的数据规模近年保持接近年翻倍的增长——多模态 embedding、视频表征、用户行为向量全在往上叠。纯内存向量检索部署已经达到 PB 级 DRAM 占用,带来每年数百万美元级别的硬件支出(同上来源)。换句话说,内存扩容的速度永远追不上数据增长的速度,这条路在数学上就已经无解了。

把数据搬到 SSD 上,看起来是个直觉答案。问题在于,这件事并不简单。

二、图式 SSD-ANNS 替代不了 DRAM

过去几年已经有 DiskANN、Starling、PipeANN 这样的「图式 DRAM-SSD ANNS」系统,核心思路是把图索引的边搬出内存、需要时再从 SSD 拉回来。在内容安全、RAG 这类对吞吐和延迟容忍度较高的场景里,这套打法能压下内存占用。

但在搜索、推荐、广告这条主战场——大 top-k、强 SLA、高 QPS——这套打法替代不了纯内存部署。

根因在「图搜索天然存在的强依赖串行 I/O」。图的下一步要访问哪个邻居,依赖上一步从 SSD 读出的结果。即便 SSD 总带宽再高,这种「边读边决定」的访问模式也很难打满阵列带宽;SSD 单次访问的延迟还会被长尾放大——你能压住平均延迟,却压不住尾延迟。

更麻烦的是构建这一侧。传统 SPANN 类方案依赖单机 CPU 做聚类,数据量从千万级爬到百亿级后,单机构建时间从数小时膨胀到数天。小红书推荐和广告 embedding 按分钟到小时级频率更新,搜索也要日级重建——构建跟不上更新节奏,在线性能再好也进不了生产。

所以问题不是「SSD 够不够便宜」,而是「图式 ANNS 这种访问模式本身就吃不满 SSD 的带宽」。

三、HELMSMAN:聚类式 + 重写存储栈,才是对的组合

HELMSMAN 的判断很干脆:真正适合现代高带宽 SSD 阵列的不是图式,而是聚类式 ANNS。

聚类式的工作方式更像是「先确定一批目的地区域,再派车一次性把整批货取走」——查询时先在内存里找到一批近邻质心,再批量读取对应的 cluster list,最后做距离计算和排序。访问之间互相独立,天然就能形成批量 I/O,更容易打满 SSD 阵列带宽。

<!-- 配图 2:HELMSMAN 架构图(Mermaid 流程/架构图) -->