小红书引擎架构团队的 HELMSMAN 论文入选 OSDI 2026:用约 40 台全闪存服务器替代过去约 35000 核 + 350TB 内存的向量检索负载,硬件成本节省 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 报道)。

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

向量检索基础设施演进:从 HNSW+DRAM 到 HELMSMAN 重写存储栈

一、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 阵列带宽。

但 SPANN 类老聚类方案距离生产还有几个明显短板:HELMSMAN 团队把它们一一拆掉。

第一,Linux I/O 软件栈是隐形税。论文分析发现,传统 Linux I/O 路径的软件开销最高能占到端到端路径的 58%。对于一次查询可能产生上千个固定大小 cluster 读取的场景,这些内核态切换、文件系统、块层、设备映射、NVMe 驱动的开销会被急剧放大。

HELMSMAN 用 SPDK 构建用户态存储栈,直接绕过文件系统、块层和 NVMe 驱动,管理 NVMe 提交队列和完成队列。cluster list 直接落到 raw NVMe 逻辑块里,用统一 chunk allocator 管理多块 SSD。这套 ANNS 定制化存储栈让系统不只是把数据搬进 SSD,而是为 ANNS 的访问模式重写了整条路径。

第二,nprobe 怎么定是个预测问题。nprobe 太大,产生过多 SSD 读取和距离计算;太小,又损失召回。固定阈值在不同 query 和不同 top-k 下要么过扫要么漏扫。

HELMSMAN 提出了 LLSP(Leveling-Learned Search Pruning):router 模型先根据 query 和 top-k 预测搜索范围等级,GBDT pruning 模型再在该等级内根据质心距离和相对距离比例预测真正需要读取的 nprobe。这套设计把「该扫多少」变成了一个面向 query 和 top-k 的预测问题——简单查询少扫,困难查询多扫,但所有读取仍可以一次性批量提交给 SSD。

第三,构建必须跟上更新节奏。HELMSMAN 把构建拆成三阶段异构流水线:第一阶段 GPU 加速粗粒度 k-means 快速生成初始质心;第二阶段弹性 CPU 资源池完成 cluster 切分、负载均衡和边界 padding;第三阶段多核 CPU 服务器合并 shard、构建质心图、训练 LLSP 模型、物化索引。配合 Virtual Kubelet,还能利用在线集群低峰期的混部 CPU 资源,把它变成可恢复、可扩展的构建能力。

最终,系统可以在 1 小时内完成 0.1B 规模索引构建,在数小时内完成 10B 规模索引重建(同上来源)。

HELMSMAN 系统架构:在线服务链路 + 离线构建流水线 + ANNS 定制化存储栈

四、从内存路线到「存储栈定制」的范式迁移

回头看 HELMSMAN 的数字——40 台全闪存 vs 35,000 核 + 350TB DRAM,硬件成本节省 90%;相比 DiskANN/SPANN 获得 2-16× 吞吐,达到纯内存部署 85% 的吞吐能力,同时满足毫秒级平均延迟和长尾延迟约束——真正颠覆的不是「SSD 比 DRAM 便宜」这件事,而是「愿意为 AI 工作负载重写基础设施」这件事。

这不是小红书一家的独唱。

2026-07-20,小红书和北大同步开源了 UltraEP(arXiv 2606.04101),处理 MoE 训推中的专家负载不均,在每个 microbatch 和每一层动态复制热点专家,关键路径开销压到 300µs 以内,达到理想性能 94.3%、较 SOTA 提升 1.49×。同一家公司在 3 天内连发两篇系统论文——一个解决检索侧,一个解决训推侧,全部指向同一个事实:通用基础设施装不下 AI 的工作负载。

再往前一周,2026-07-16,火山引擎存储团队发了一篇《从 Data Lake 到 State Lake:面向 Agent 时代的存储基础设施重构》,把存储范式从 Content Storage(对象存储/冷归档)升级到 State Storage(Checkpoint/KVCache/Agent Memory),明确提出「存储的角色从『数据底座』升级为『状态底座』」。

HELMSMAN、UltraEP、State Lake——三篇都在做同一件事:为 AI 的某一类具体工作负载,把基础设施拆开来重写一遍。

这才是过去半年中国基础设施圈最被低估的暗线:硬件军备竞赛还在打,但胜负点已经悄悄从「谁 GPU 多、谁内存大」转向了「谁愿意为 AI 工作负载重写底层软件」。HNSW + DRAM 的组合统治了向量检索十年,下一个十年,拼的是 SPANN、SPDK、LLSP 这些没几个人愿意碰的脏活。

当所有人都在拼模型能力的时候,真正的护城河正在这些论文里悄悄换主。

参考资料

机器之心 2026-07-23:小红书引擎架构团队 OSDI 2026 新成果:HELMSMAN 重塑大规模向量检索基础设施
论文:arXiv 2606.13145 / https://arxiv.org/abs/2606.13145
开源仓库:https://github.com/Red-EAD/helmsman
小红书技术REDtech 2026-07-20:小红书、北大开源 UltraEP
火山引擎存储 2026-07-16:从 Data Lake 到 State Lake