小红书 HELMSMAN 将向量搜索迁移至闪存，硬件成本降低逾 90%

小红书 HELMSMAN 已将生产环境中的向量搜索迁移到约 40 台全闪存服务器上，取代了原本消耗约 35,000 个 CPU 核心和 350 TB DRAM 的工作负载。该公司表示，这一改变将相关硬件成本降低了 90% 以上。

这一成果挑战了一个常见的基础设施假设。低延迟向量检索通常依赖几乎完全存储在昂贵 DRAM 中的图索引。基于闪存的系统虽然降低了内存需求，但其速度较慢且更难预测的访问模式，往往使其无法用于要求严苛的在线服务。

HELMSMAN 采用了不同的路线。它将基于聚类的索引、对 NVMe 存储的直接访问、学习式搜索剪枝和分布式索引构建流水线结合起来。据报道，其性能接近内存系统，同时不再沿用同样高度依赖内存的架构。

该系统并非仅仅是一项实验室基准测试。根据这篇 OSDI 论文，小红书已在生产环境中运行 HELMSMAN 数月。它支持与搜索、推荐、广告、内容审核和检索增强生成相关的工作负载。

因此，真正重要的竞争并非小红书与另一个社交平台之间的较量，而是全闪存聚类架构与长期主导低延迟向量搜索的内存图架构之间的较量。

小红书 HELMSMAN 将研究成果转化为生产基础设施

核心变化体现在实际运行层面：如今，闪存存储开始处理小红书过去认为必须在内存中运行的在线向量搜索。

近似最近邻搜索（ANNS）无需扫描每个已存储向量，即可找出可能与查询最接近的向量。它为语义搜索、内容推荐、广告检索、内容审核和 RAG 系统提供支持。

小红书以极具挑战性的规模运行这些服务。其研究人员称，平台管理着数千亿个嵌入向量，每秒处理数百万次查询。

仅搜索业务就可能覆盖多达 200 亿个向量。其典型峰值流量达到每秒约 300,000 次查询，平均延迟目标约为 10 毫秒。

推荐服务则带来了不同类型的压力。单个索引包含 100 万至 1 亿个向量，而总流量可达到每秒约 250 万次查询。

广告业务涉及约 10 亿个向量，同样要求严格的毫秒级延迟。这些服务可能请求多达 3,000 个候选结果，随后由过滤和排序阶段作出最终选择。

原有基础设施采用存储在 DRAM 中的分布式 HNSW 索引。HNSW 是一种基于图的索引，通过遍历相近向量之间的连接，快速找到有希望的候选结果。

将图和向量保存在内存中可以最大限度地降低存储延迟。然而，即使计算资源仍未得到充分利用，这种方式也会让容量直接受制于 DRAM。

小红书称，其更广泛的内存向量搜索集群已扩展至约 4,000 个节点和大约 50 个集群，共使用超过 100,000 个 CPU 核心。到 2025 年，其 HNSW 索引已经消耗 PB 级 DRAM。

HELMSMAN 尚未取代这整个集群。此次生产环境对比涵盖的是此前使用约 35,000 个核心和 350 TB DRAM 的工作负载。

目前，约 40 台 HELMSMAN 机器承载了这些工作负载。根据论文，每台生产服务器配备 12 块 NVMe SSD，以及 700 GB 至 1.1 TB 的 DRAM。

这些仍然保留的内存十分重要。全闪存服务器并不意味着无内存服务器。HELMSMAN 将聚类质心、搜索路由数据和剪枝模型保存在 DRAM 中，同时将大型向量列表存储在 SSD 上。

这种转变仍然改变了硬件资源的配置比例。系统不再让 DRAM 保存每条图边和每个向量，而是将内存留给紧凑的路由结构和活跃计算任务。

研究人员表示，该部署已稳定运行数月。目前，他们正将其推广为覆盖更多服务的统一向量搜索层。

小红书还发布了一个概念验证实现。该代码为研究分析提供了起点，但并未复现内部生产环境的所有组件。

为什么内存 HNSW 成为降本目标

HELMSMAN 所解决的是一个伪装成性能要求的容量问题。

内存 HNSW 提供了小红书所需的延迟表现。然而，该基础设施的吞吐能力远超正常流量所需。

研究人员发现，在线工作负载仅使用了内存部署可用吞吐能力的约 32% 至 43%。其余容量并非只是被浪费的预配置资源。

这些资源用于存储完整索引，并在不造成延迟峰值的情况下吸收突发流量。由于基于图的搜索依赖大量细粒度内存访问，因此很难削减这些资源。

与此同时，小红书表示，其存储的向量语料库每年都会翻一番。随着用户发布内容、模型生成新的表示形式，数十亿个新向量不断涌入。

规模更大的嵌入模型进一步加剧了压力。更高维度的向量会消耗更多存储空间，而模型重新训练后，可能需要为此前已编入索引的内容生成新向量。

这种增长影响的不仅是容量，还会增加构建、分发和替换索引所需的时间与资源。

显而易见的应对方式是将向量迁移到 SSD。对于延迟要求较宽松的工作负载，包括部分内容审核和 RAG 应用，小红书已经使用了 DRAM 与 SSD 混合系统。

在线处理路径则更加棘手。DiskANN 等系统将压缩向量保存在内存中，同时把完整向量和图数据存储在 SSD 上。

图遍历会形成依赖链。系统读取图的一个部分，评估其邻居，然后确定接下来需要读取哪些存储位置。

这些串行决策使存储层无法发出足够多的独立请求，从而无法充分利用高带宽 SSD 阵列。高速硬盘未得到充分利用，而每个查询都必须等待下一个图遍历步骤。

小红书在配备 12 块 PCIe Gen5 SSD 的服务器上测试了 DiskANN、Starling 和 PipeANN。据报道，在被测试的在线工作负载中，DiskANN 和 Starling 均未达到平均延迟和尾延迟目标。

PipeANN 通过并行图探索降低了延迟。然而，在规定的延迟限制下，其吞吐量仍比内存 HNSW 低 10 至 25 倍。

这正是 HELMSMAN 没有简单地将现有图索引放到新型存储设备上的关键原因。更快的闪存无法消除图遍历固有的访问依赖关系。

聚类改变了这种访问模式。查询首先识别相关聚类，然后以独立批次读取多个聚类列表。

这种方式可以并发使用多块硬盘。它用数量更少、规模更大且可并行执行的操作，取代一连串相互依赖的小规模读取。

Microsoft 的 SPANN 研究确立了这一架构的重要实现方式。它将紧凑的质心数据保存在内存中，并将更大的倒排列表放在存储设备上。

小红书发现，随着 SSD 数量增加，SPANN 能够以更可预测的方式扩展。在一项实验中，12 块硬盘带来了接近 12 倍的吞吐量提升。

不过，在小红书的测试中，未经修改的 SPANN 吞吐量仅达到 HNSW 的约 12% 至 14%。它也只使用了可用 SSD 带宽的 26% 至 59%。

这一差距界定了真正的工程问题。闪存容量价格可负担，总带宽也相当可观，但软件栈无法将这些带宽转化为生产查询吞吐量。

HELMSMAN 如何让全闪存向量搜索具备竞争力

HELMSMAN 之所以有效，是因为存储、搜索决策和索引构建被重新设计为一个整体系统。

第一个组件是面向 ANNS 的用户态存储栈。用户态存储允许应用程序与 NVMe 设备通信，而不必让每次操作都经过常规的内核文件系统路径。

一次传统读取可能会依次经过系统调用、文件系统、块设备层、设备映射和 NVMe 驱动程序。每个阶段都会增加软件处理和协调开销。

当多个 CPU 核心发出小规模、高频读取请求时，这些开销会变得十分明显。锁竞争和上下文切换可能会在 SSD 硬件达到自身性能上限之前限制吞吐量。

HELMSMAN 使用 SPDK，这是一种专为直接、异步设备访问设计的用户态存储框架。它将聚类列表条带化分布在裸 NVMe 设备上，并在更靠近应用程序的位置管理队列。

搜索线程为选定的聚类提交异步读取命令。随后，它们轮询硬件完成队列，并在数据到达后计算向量距离。

这一设计让存储操作与聚类索引保持一致。聚类读取彼此独立，因此 HELMSMAN 可以跨多块硬盘批量执行读取，而无须等待图遍历。

论文称，在一个源自生产环境的工作负载中，基于图的竞争系统使用了不到 20% 的 SSD 带宽。SPANN 在 PCIe Gen4 硬盘上达到了约 55%。

HELMSMAN 在同代硬盘上达到了约 85% 的利用率。在 Gen5 SSD 上则达到约 70%，因为更大的可用带宽暴露了服务器其他部分的新瓶颈。

第二个组件是分级学习式搜索剪枝。剪枝用于决定可以跳过哪些候选聚类，同时确保召回率不低于目标值。

固定剪枝规则在面对不同查询时表现不佳。简单查询可能扫描不必要的聚类，而困难查询可能过早停止，遗漏相关结果。

不同工作负载进一步加剧了这个问题。搜索请求可能要求返回 100 至 3,000 个候选结果，而 RAG 请求可能只要求 10 至 100 个。

HELMSMAN 首先使用路由模型选择初始搜索范围。随后，第二个模型评估各个聚类，并移除不太可能改善答案的候选项。

这些模型会考虑查询、请求的结果数量、质心距离和局部分布模式。通过分桶，相似情况会被路由到合适的剪枝模型，从而限制模型开销。

这种学习式方法仍与批量存储访问兼容。它会在读取前选择批次，而不是在每次存储操作后增加一个细粒度决策。

在平均召回率相同的情况下，小红书称，固定策略对超过 40% 的单次查询未能达到 90% 的召回率目标。HELMSMAN 的方法则使超过 80% 的查询达到该目标以上。

平均召回率与单次查询召回率之间的区别十分重要。一个系统可能报告可接受的平均值，却在许多单个用户的查询中产生较差结果。

第三个组件解决索引构建问题。基于聚类的系统必须对向量进行分区、平衡聚类、复制部分边界向量，并构建路由结构。

仅使用 CPU 构建 SPANN 时，较小的生产索引可能需要数小时，而十亿级向量索引则可能需要数天。这种延迟无法适应频繁重新训练的嵌入模型。

HELMSMAN 将粗粒度聚类分配给 GPU。随后，它将更细粒度的均衡工作分发给弹性 CPU 工作节点池，并将输出合并为最终索引。

一个包含 1 亿向量的索引，在一台 192 核机器上仅使用 CPU 构建时，大约需要 9 到 12 小时。四块 Nvidia L20 GPU 将这一过程缩短至不到一小时。

对于包含 100 亿向量的数据集，弹性 CPU 扩缩容将端到端构建时间从超过 16 小时缩短至约 4 到 7 小时。

在低流量时段，Xiaohongshu 可临时从在线集群借用多达 10,000 个 CPU 核心。在线工作负载仍享有优先级，当工作节点不可用时，构建任务可以重新分配。

这种运维整合非常重要。如果新的嵌入模型需要等待数天才能获得可用索引，或者只能使用陈旧索引，那么仅仅实现快速查询服务并无济于事。

真正的竞争是闪存聚类对阵内存图索引

HELMSMAN 并未让 HNSW 过时；它缩小了纯内存索引在经济上合理的适用范围。

在原始延迟和吞吐量方面，内存中的 HNSW 依然难以超越。其关键数据紧邻处理器，而图遍历避免了扫描大规模向量组。

HELMSMAN 的目标则是在明确的服务等级协议下实现足够的性能。这与在每一项基准测试中取胜是不同的优化目标。

Xiaohongshu 表示，在评估的各类工作负载中，HELMSMAN 的吞吐量达到现有 DRAM 和 SSD 系统的 2 到 16 倍。在两个包含 100 亿向量的数据集上，其吞吐量达到生产环境 HNSW 的 47% 至 85%。

对比中使用了一台配备 96 个 CPU 核心和 160 GB 至 330 GB DRAM 的 HELMSMAN 机器。HNSW 部署则使用了 10 个分片、320 个核心和 2.5 TB DRAM。

据报告，在这些测试中，HELMSMAN 将 CPU 使用量降低至约三分之一到四分之一，并将 DRAM 消耗减少了近一个数量级，同时仍满足目标延迟要求。

当 HNSW 集群的资源配置主要用于容纳索引时，这种权衡会很有吸引力。如果正常流量消耗的吞吐量不到一半，那么为最大内存容量付费会导致较低的资源利用率。

HELMSMAN 的聚类路径也能更直接地受益于更快的存储。在较低维度的工作负载中，从 Gen4 SSD 升级到 Gen5 SSD 后，其吞吐量提升了约 55%。

在一个 1,024 维的 RAG 工作负载中，提升幅度达到 87%。而基于图的 SSD 系统在同一代际升级中仅提升了 10% 至 30%。

这些结果表明，图系统仍受限于串行化 I/O 或软件开销。HELMSMAN 则将更多新增的硬盘带宽转化为有效的搜索工作。

不过，这一对比并不适用于所有场景。向量工作负载在维度、召回率目标、结果数量、过滤条件、更新频率和延迟要求方面各不相同。

Xiaohongshu 的在线系统通常会检索数百或数千个候选项。随后，下游排序模型会利用更丰富的内容和用户信号，对这些候选项进行过滤和重新评分。

聚类非常适合这种场景，因为大范围批量读取能够生成大型候选池。对于以极高召回率检索极少量结果的工作负载，其他索引可能更合适。

其他研究也在探索替代方案。Huawei 与高校研究人员提出了 DistVS，它将计算、内存和 SSD 存储分离为三个层级。

DistVS 将低精度向量放置在计算资源附近，将更高精度的数据置于远程内存中，并将精确向量存储在 SSD 上。其 PRESS 算法会逐步跨这些层级剔除候选项。

这种架构将内存视为一种可独立扩展的共享服务。HELMSMAN 则把高带宽闪存集中在每个服务节点内，并围绕本地设备重新设计访问方式。

两种路径都无法为所有运营者提供唯一答案。它们共同表明，向量基础设施正在超越全 DRAM 与慢速磁盘之间的二元选择。

对于工程团队而言，更广泛的启示在于架构。只有当访问算法和软件栈能够充分利用更便宜的介质时，硬件的经济性才有意义。

因此，评估检索基础设施的团队应衡量完整的工作负载行为。可搜索的技术文档集合还取决于索引、更新和检索质量，而不仅仅是存储容量。

90% 成本节省的说法尚未解答什么

作为已报告的部署结果，这一醒目的节省数字具有可信度，但它并非普遍适用的采购公式。

第一个局限是证据范围。大多数详细的性能和成本数据都来自 Xiaohongshu 自己的论文和生产环境测量。

在 OSDI 发表意味着经过同行评审，也使研究方法可供审查。但这并不等同于对 Xiaohongshu 内部部署的独立复现。

已发布的概念验证可以帮助外部研究人员审视设计选择，但无法复现专有数据集、流量分布、集群管理方式或硬件采购条件。

第二个局限是对比边界。90% 这一数字适用于从某个特定内存部署迁移的工作负载所产生的硬件成本。

它未必涵盖工程人力、迁移风险、备用容量、运维工具，以及所有网络与存储费用。论文对设备成本的讨论比对总体拥有成本的讨论更直接。

HELMSMAN 服务器也仍然保留了大量 DRAM。40 台机器每台配备 700 GB 至 1.1 TB 内存，意味着总内存规模介于 28 TB 到 44 TB 之间。

这远低于此前分配的 350 TB，但仍是一项不可忽视的基础设施需求。该系统只是将资源比例向闪存倾斜，而不是彻底消除内存。

第三个局限体现在论文总结的运维经验中。并非所有查询模式都能均匀利用闪存带宽。

在早期推荐试验中，突发请求有时会集中访问相同的聚类和逻辑块。即使整体带宽使用率仍低于 20%，这些热点也会在 SSD 芯片内部引发冲突。

Xiaohongshu 通过存储部分聚类列表的冗余副本解决了这一问题。据研究人员称，这种方法仅略微增加存储量，就将吞吐量提高了 1.5 到 2 倍。

复制是一种实用的解决方案，但它也说明了为什么汇总带宽可能具有误导性。当大量请求在相同的内部资源上发生冲突时，十几块硬盘也无济于事。

服务器内存带宽构成了另一重上限。在测试配置中，12 块 Gen5 硬盘可提供约每秒 140 GB 的外部汇总带宽。

但系统在实践中仅使用了约 70% 的容量。通常介于每秒 300 GB 到 350 GB 之间的有效 DDR5 带宽率先成为瓶颈。

内存必须承接来自 SSD 的数据传输、为 CPU 距离计算供给数据，并支持质心搜索。当这些路径饱和后，增加更多硬盘带来的收益十分有限。

第四个局限与更新有关。HELMSMAN 加速了完整索引重建，但无法解决高频率的原地变更。

一个典型的 1 亿向量推荐工作负载，可能同时包含每小时一次的重建和每秒 25,000 到 30,000 次搜索查询。若要取代重建，就需要支持速率相近的并发插入和删除。

研究人员表示，对于这类工作负载，当前的动态 ANNS 系统无法同时维持这两种速率。因此，HELMSMAN 采用了混合式数据新鲜度设计。

主索引驻留在 SSD 上并定期重建。最近插入的数据保存在辅助内存索引中，同时使用位图记录已删除的向量。

查询会搜索两个索引并合并候选项。这种方式能够保持数据新鲜度，但也会增加内存消耗、合并工作和持续的重建成本。

最后一个不确定因素是端到端产品质量。论文评估了召回率、延迟、吞吐量、带宽、构建时间和基础设施效率。

但它没有披露搜索满意度、广告转化率或推荐互动率等业务指标。这些结果取决于后续排序阶段和更广泛的产品行为。

读者应将这一结果视为 Xiaohongshu 工作负载下有力的系统证据，而不应假设将任意无关的向量数据库迁移到闪存就能自动节省相同比例的成本。

三个信号将表明 HELMSMAN 是否会改变市场

只有当更广泛的迁移、外部复现和持续的产品质量紧随论文成果出现时，HELMSMAN 才会成为行业参考。

第一个信号是 Xiaohongshu 自身的推广情况。该公司表示，全闪存服务器正在搜索、推荐、广告及其他向量服务中逐步取代内存部署。

目前的 40 台服务器部署只覆盖了更庞大向量集群的一部分。如果大多数工作负载完成迁移，将表明该架构能够经受更多数据集、流量模式和故障模式的考验。

应关注更新后的服务器数量、DRAM 缩减幅度和工作负载覆盖范围。持续扩展将进一步支持闪存聚类可成为默认服务层的说法。

如果推广停滞，则可能表明隐性的工作负载差异限制了该系统。某些特定服务可能仍会因为延迟、召回率或更新行为而需要内存中的 HNSW。

第二个信号是独立复现。预印本记录和开放实现为研究人员提供了稳定的比较基础。

有价值的复现应测试现代 Gen5 阵列、不同的向量维度、大量结果、倾斜流量以及严格的尾延迟目标。小型公开基准测试无法覆盖该部署最具挑战性的条件。

比较还应纳入当前版本的 DiskANN、SPANN、DistVS 和动态索引。核心问题并不是 HELMSMAN 能否击败过时的基线。

而是其聚类与用户态 I/O 的组合，能否在不同硬件、数据分布和服务目标下持续保持高效。

对带宽利用率和单次查询召回率的独立确认，将进一步巩固 Xiaohongshu 的论点。如果存在巨大差距，则会揭示报告结果在多大程度上依赖内部调优。

第三个信号是随着工作负载增长，生产质量能否保持稳定。如果用户得到的搜索或推荐质量更差，那么基础设施成本节省就没有多少价值。

Xiaohongshu 强调采用召回率约为 90% 的大型候选集，因为下游模型会执行最终过滤和排序。这一选择反映了其多阶段产品架构。

采用不同处理流程的运营者，可能要求以 98% 或更高的召回率返回更小的结果集。这些目标可能会增加扫描量并削弱成本优势。

应关注涵盖尾延迟、低召回率异常值、热点行为、重建新鲜度以及下游排序质量的证据。这些指标将表明该系统的效率能否经受运维压力。

HELMSMAN 最重要的贡献并不是宣称闪存已经取代内存。它表明，只有围绕并行访问重组搜索路径后，现代 SSD 带宽才能得到有效利用。

对于基础设施负责人而言，这带来了一个具体决策：衡量 DRAM 究竟是在服务流量，还是仅仅用于容纳索引，然后在实际的延迟和召回率目标下测试聚类闪存。

对于研究人员而言，下一项任务同样明确：在 Xiaohongshu 之外复现这一结果，对动态更新进行压力测试，并确定哪些工作负载仍值得采用内存图索引。

Xiaohongshu HELMSMAN 已经让相关讨论超越了合成基准测试。接下来的问题是，其他大型运营者能否在不牺牲用户可感知质量的情况下，实现类似的成本节省。