近日，围绕搜索、推荐、广告等核心业务中的大规模向量检索成本与性能问题，小红书引擎架构团队在 OSDI 2026 会议上发表了论文《The Clustering Strikes Back: Building Cost-Effective and High-Performance ANNS at Scale with HELMSMAN》。

该工作提出了面向全闪存的高性能向量近似最近邻检索系统 —— HELMSMAN，通过 ANNS 定制化存储栈、分层学习式搜索剪枝，以及 GPU 加速和弹性分布式构建流水线，在严格保障毫秒级延迟约束的条件下，将原本依赖海量 DRAM 的向量检索服务迁移到 NVMe SSD 阵列之上，实现了成本、性能与构建效率的系统性突破。

在小红书搜推广业务中，HELMSMAN 使用约 40 台全闪存服务器稳定承载了过去约 35000 CPU Core 和约 350 TB DRAM 才能支撑的在线高吞吐低延迟向量检索负载，硬件成本节省超过 90%。相比现有 DRAM-SSD ANNS 系统如 DiskANN 和 SPANN 获得 2-16× 吞吐提升，最高达到纯内存部署 85% 的吞吐能力，同时满足在线服务对毫秒级别的平均延迟和长尾延迟要求；在构建侧，10B 规模索引可在数小时内完成重建，为高频模型更新和向量数据更新提供了可落地的基础设施能力。

DRAM 路线越来越贵

近似最近邻搜索（Approximate Nearest Neighbor Search，ANNS）是搜索、推荐、广告、内容安全、RAG 等系统中最核心的基础能力之一。

小红书的内容生态覆盖图文、视频、商品、用户行为等多模态数据，线上服务需要维护单索引高达数百亿规模的高维向量，并在每秒百万级查询压力下完成低延迟召回。对于直接面向用户的搜索、推荐和广告链路，向量检索通常处在粗排召回的第一阶段，既要在 5-10 ms 级别满足 SLA，又要返回数百到数千个候选结果，给索引结构、存储介质和在线执行路径都带来了极高要求。

过去，为了保证极低延迟和稳定长尾延迟，团队主要依赖大规模 in-DRAM 图索引如 HNSW，图索引的优势非常明显：数据和边都在内存中，查询可以沿图结构进行快速贪心搜索，多分片并行后再合并结果，能够长期支撑搜索、推荐、广告等高 QPS 业务。

然而，这条路线的成本曲线正在失控。随着平台内容、用户行为和多模态 embedding 的持续增长，小红书线上向量数据规模近年保持接近年翻倍的增长趋势，纯内存向量检索部署已经达到 PB 级 DRAM 占用，带来每年数百万美元级别的硬件支出。随着向量规模继续增长，单纯依靠 DRAM 扩容已经不再是经济可持续的路径。

现代 NVMe SSD 提供了一种可能。PCIe Gen5 SSD 阵列的带宽已经相当可观，单位容量成本却只有 DRAM 的一小部分。如果能把大部分向量数据下沉到 SSD，同时保持毫秒级延迟和高吞吐，向量检索基础设施的成本结构就会被改写。难点在于：这不是简单地把数据从内存搬到硬盘。

基于 SSD 的图索引不可行

已有 DiskANN、Starling、PipeANN 等图式 DRAM-SSD ANNS 系统，在内容安全和 RAG 等吞吐和延迟较宽松场景下可以降低内存占用，但在搜索、推荐、广告这类大 top-k、强 SLA、高 QPS 场景里仍然难以替代 in-DRAM 部署。根因在于图搜索天然存在强依赖的串行 I/O：下一步要访问哪个邻居，依赖上一步 SSD 读取出的结果。

即便 SSD 总带宽很高，这种「边读边决定」的搜索路径也很难把带宽打满，长尾延迟还会被 SSD 单次访问延迟放大。

HELMSMAN 的判断是：真正适合现代高带宽 SSD 阵列的，不是图式 DRAM-SSD 搜索，而是聚类式 ANNS。聚类索引查询时先在内存中找到一批近邻质心，再批量读取对应 cluster list，最后计算候选向量距离并排序。这更像先确定一批区域，再一次性派车去取货。访问之间相互独立，这种模式可以天然形成批量 I/O，更容易打满 SSD 阵列带宽。

但传统 SPANN 距离生产可用仍有明显差距。

首先是吞吐不够，大量性能损失来自传统 Linux I/O 软件栈，包括应用到内核切换、文件系统、块层、设备映射和 NVMe 驱动等开销。对于每次查询可能产生上千个固定大小 cluster 读取的场景，这些软件开销会被急剧放大。

其次是搜索策略不够自适应，无法适配真实线上请求中高度变化的 query 难度和 top-k。对于简单查询，它会扫描过多 cluster，浪费 I/O 和 CPU；对于困难查询，它又可能扫描不足，导致单查询召回波动。线上系统不能只看平均召回，还需要保证大多数请求都稳定达到目标召回，否则低召回长尾会直接影响业务效果。

最后是构建慢。传统 SPANN 构建依赖单机 CPU，从千万级数据扩展到百亿级数据后，单机构建耗时会从数小时增长到数天，百亿数据无法构建成功。小红书推荐和广告 embedding 会按分钟到小时级频率更新，搜索也需要日级重建。如果索引构建无法跟上模型和向量数据更新，在线系统即使查询性能足够，也无法真正进入生产闭环。

向量检索系统不是只要在公开数据集上取得高召回即可，真正上线需要同时满足高吞吐、低平均延迟、低长尾延迟、稳定单查询召回，以及高频索引构建。

HELMSMAN：让 SSD 真正服务于大 top-k 在线 ANNS

团队提出了面向全闪存服务器的 HELMSMAN 在线服务架构。

系统基于聚类式索引设计，使用 ANNS 定制化存储栈绕过传统 Linux I/O 软件路径，通过 SPDK 直接管理 NVMe 队列、批量提交固定大小 cluster 读取请求，并将热点在线路径压缩到「内存质心定位、学习式剪枝、SSD 批量读取、本地距离计算」这一套高吞吐流水线中，从软件栈和访问模式两侧共同提升 SSD 阵列利用率。

在线阶段，HELMSMAN 根据 query、top-k 和质心距离分布自适应预测 nprobe，避免固定裁剪在不同查询难度下造成过扫或漏扫；离线阶段，系统利用 GPU 加速粗粒度聚类，并使用弹性 CPU 资源池完成细粒度均衡、边界 padding 和最终索引合并，使推荐、广告等时效敏感场景可以达到分钟到小时级构建，大规模搜索索引也能在数小时内完成重建。

我们的目标，是在全闪存服务器上构建一套既满足在线 SLA、又显著降低硬件成本、还能支撑频繁构建的工业级 ANNS 系统。系统整体分为在线服务和离线构建两条链路。

ANNS 定制化存储栈 + 分层学习式搜索剪枝

在线链路的关键设计是 ANNS 定制化存储栈。论文分析发现，传统 Linux I/O 路径的软件开销最高可占端到端路径的 58%。对于一次查询可能读取上千个 cluster 的场景，这些开销会被急剧放大。

HELMSMAN 选择基于 SPDK 构建用户态存储栈，绕过文件系统、块层和内核 NVMe 驱动，直接管理 NVMe 提交队列和完成队列。同时，系统把吞吐关键路径上的 cluster list 直接放到 raw NVMe 逻辑块中，并通过统一 chunk allocator 管理多块 SSD。由于 cluster 被 padding 到固定大小，在线读取通常可以变成一次固定大小 I/O。

换句话说，HELMSMAN 不只是把数据放进 SSD，而是为 ANNS 的访问模式重新设计了存储路径。

第二个关键问题是 nprobe，nprobe 太大，会产生过多 SSD 读取和距离计算；nprobe 太小，又会损失召回。传统固定阈值策略很难适配真实线上请求，因为不同 query、不同 top-k 的难度差异很大。

HELMSMAN 提出了 Leveling-Learned Search Pruning（LLSP）。它的核心要求是剪枝必须在真正读取 cluster list 之前完成，不能依赖中间搜索结果，否则 I/O 又会退化成多轮依赖链，破坏聚类 ANNS 的批量读取优势。在线查询时，router 模型先根据 query 和 top-k 预测搜索范围等级；随后系统在该等级内找到近邻质心，并结合最近质心距离、相对距离比例等特征，通过 GBDT pruning 模型预测真正需要读取的 nprobe。

这样做带来两个好处：简单查询少扫，困难查询多扫，同时所有读取仍然可以一次性批量提交给 SSD。

这不是粗暴地压缩搜索范围，而是把「该扫多少」变成一个面向 query 和 top-k 的预测问题。

GPU 加速分布式构建流水线

向量检索不是只要查得快就够。推荐、广告的 embedding 会频繁更新，搜索也需要周期性重建。如果索引构建跟不上，在线性能再好也无法形成生产闭环。

HELMSMAN 将构建拆成三阶段异构流水线：

这条链路以 RED-Ray 和 Daft 作为执行基座。RED-Ray 负责任务调度、Actor 管理、失败恢复和跨阶段依赖；Daft 负责并行读取和数据处理。通过 Virtual Kubelet，系统还能使用在线集群低峰期的混部 CPU 资源，把不稳定的空闲算力转化为可恢复、可扩展的构建能力。

最终，HELMSMAN 可以在 1 小时内完成 0.1B 规模索引构建，在数小时级完成 10B 规模索引重建。

对高频更新的 embedding 系统来说，构建效率不只是离线优化，而是直接决定模型和向量数据能否快速进入在线效果闭环。

实验结果：85% 内存吞吐，90% 成本下降

在公开数据集和小红书真实生产负载上，HELMSMAN 都表现出稳定收益。

相比 DiskANN、Starling、PipeANN、SPANN 等 DRAM-SSD ANNS 系统，HELMSMAN 获得 2-16× 吞吐提升；在部分场景中，最高达到纯内存 HNSW 约 85% 的吞吐能力，同时满足 5-10 ms 级平均延迟和严格长尾延迟要求。HELMSMAN 显著提高了 SSD 带宽利用率。

在 RedSrch0.5B 上，图式系统 SSD 带宽利用率低于 20%，SPANN 在 PCIe Gen4 上约为 55%，HELMSMAN 在 Gen4 上可达到约 85%，在 Gen5 上约为 70%。在索引构建方面，0.1B 规模索引整体构建时间降到 1 小时以内，10B 规模数据端到端构建时间降低到约 4-7 小时，获得最高约 10× 加速。

对于推荐和广告这类高时效服务，这意味着小时级甚至分钟级更新成为可能，索引构建不再是阻碍模型迭代和向量数据更新的瓶颈。

在生产负载上，HELMSMAN 的吞吐 - 延迟优势更明显。在 RedSrch、RedRec、RedAds、RedCM、RedRAG 等数据集上，图式系统通常在较低 KQPS 下就出现百毫秒级平均延迟，难以满足直接在线链路；SPANN 受益于聚类式批量 I/O，性能好于图式系统；HELMSMAN 在此基础上通过 SPDK 存储栈和 LLSP 继续提升，最高可获得约 30× 吞吐，同时保持 5-10 ms 级平均延迟。

对于 P999 长尾，HELMSMAN 也保持了一个数量级左右的优势，说明它不仅改善平均性能，也改善线上最敏感的尾部体验。

成本收益则更直接。在小红书真实业务中，HELMSMAN 使用约 40 台全闪存服务器，稳定承载过去约 35,000 CPU Core 和约 350 TB DRAM 才能支撑的在线向量检索负载，硬件成本节省超过 90%。

总结

HELMSMAN 系统性回答了一个长期困扰工业向量检索的问题：当向量规模增长到百亿甚至更高、纯 DRAM 成本不可持续时，是否存在一条既满足在线 SLA、又能显著降低硬件成本的可落地路径。

图索引适合内存，但不一定适合 SSD；SSD 带宽很高，但需要批量、无依赖的访问模式才能释放；在线查询要快，离线构建也必须跟得上模型和数据更新。

HELMSMAN 通过聚类式索引、SPDK 用户态存储栈、LLSP 学习式剪枝，以及 GPU/CPU 异构构建流水线，给出了一条面向工业生产的全闪存 ANNS 路线。

随着 PCIe Gen5/Gen6 SSD、HBF 闪存和异构计算继续演进，向量检索基础设施会越来越走向软硬件协同加速。HELMSMAN 证明了这条路线在小红书百亿级 ToC 场景中的可行性，也为下一代低成本、高性能向量检索系统提供了新的工程范式。