文章目录小红书HELMSMAN全闪存向量检索技术解析用40台服务器替代35000核的架构革命一、引言二、背景十亿级向量检索的内存税2.1 向量检索为什么需要海量内存2.2 为什么图索引一度成为主流2.3 小红书的痛点35,000核 350TB DRAM2.4 聚类索引为什么死了三、HELMSMAN架构全景五大核心组件3.1 系统总览3.2 五大组件清单四、核心创新一聚类索引的回归——The Clustering Strikes Back4.1 为什么聚类索引可以反击4.2 聚类索引 vs 图索引存储依赖的对比4.3 聚类索引的设计五、核心创新二用户态存储栈——SPDK直访NVMe5.1 传统Linux I/O路径的问题5.2 SPDK用户态方案5.3 存储栈的关键优化六、核心创新三分层学习式搜索剪枝LLSP6.1 传统剪枝的问题6.2 LLSP的设计6.3 为什么预判式如此重要6.4 学习模型的训练七、核心创新四GPU加速与弹性分布式构建7.1 GPU加速计算7.2 GPU与NVMe的并行流水线7.3 弹性分布式构建流水线八、性能对比HELMSMAN vs 传统方案8.1 硬件成本对比8.2 吞吐量对比8.3 延迟保障8.4 生产部署九、横向对比向量检索的技术路线之争9.1 主流系统对比9.2 全闪存方案的行业趋势9.3 为什么是现在十、总结小红书HELMSMAN全闪存向量检索技术解析用40台服务器替代35000核的架构革命一、引言2026年7月在西雅图举办的OSDI 2026第20届USENIX操作系统设计与实现研讨会上小红书引擎架构团队发表了一篇引发工业界震动的论文——HELMSMAN。论文标题的第一句话就是The Clustering Strikes Back聚类反击了直接宣告了一个颠覆性的结论用约40台全闪存服务器替代了原本需要约35,000个CPU核心和约350TB内存的向量检索集群硬件成本降低超过90%同时满足搜索、推荐、广告等核心业务的毫秒级SLA要求。这不是用更便宜的硬件凑合而是通过算法与系统的联合设计co-design在NVMe SSD上重建了向量检索的整个技术栈——从聚类索引的回归、用户态存储栈的重写到学习式搜索剪枝和GPU加速流水线。区别于学术界为了发论文而造系统的做法HELMSMAN直接部署在小红书的生产环境中稳定承载十亿级向量检索的高并发实时流量。它代表了一个清晰的信号向量检索的下一阶段不再是堆内存而是怎么用最便宜的存储跑出最高的性能。本文将从HELMSMAN的聚类索引回归、SPDK用户态存储栈、分层学习式剪枝、GPU加速流水线等维度对这一系统进行深度技术解析。亲爱的朋友们创作不容易若对您有帮助的话请点赞收藏加关注哦您的关注是我持续创作的动力谢谢大家有问题请私信或联系邮箱jasonai.fngmail.com二、背景十亿级向量检索的内存税2.1 向量检索为什么需要海量内存在AI时代向量检索Approximate Nearest Neighbor Search, ANNS是搜索引擎、推荐系统、广告系统和大模型RAG的核心基础设施。它的基本任务是给定一个查询向量从数十亿个候选向量中找到距离最近的几个。目前主流的十亿级向量检索方案有两大技术路线技术路线代表系统核心原理内存需求基于图的索引HNSW, DiskANN, SPANN构建向量间的图结构从入口点沿图边逐步接近最近邻图结构需要大量内存存储边和向量基于聚类的索引IVF, k-means聚类将向量分组到聚类中心搜索时只查询相关聚类只需存储聚类中心和索引映射内存需求低2.2 为什么图索引一度成为主流在HDD和早期SSD时代I/O延迟是向量检索的主要瓶颈。图索引的优势在于优势说明I/O数量少图搜索只需要随机读取少量节点I/O次数少召回率高图的连通性保证了搜索路径的精度算法成熟HNSW等算法经过充分优化性能稳定但图索引有一个致命缺点图结构本身需要海量内存存储。对于十亿级向量每个向量几百维图索引需要的内存规模动辄数百TB。2.3 小红书的痛点35,000核 350TB DRAM在HELMSMAN之前小红书的十亿级向量检索依赖传统的内存方案资源规模成本估算CPU核心约35,000个数千台服务器DRAM约350TB每TB服务器内存约$3,000-5,000仅内存成本就超过$100万服务器数量数千台机柜、电力、运维成本叠加这是一个典型的内存税场景——为了追求向量检索的性能不得不购买远超实际计算所需的内存容量。2.4 聚类索引为什么死了聚类索引如IVF的内存需求远低于图索引但在传统存储环境下有两个致命问题问题说明I/O数量多聚类索引需要读取多个聚类列表I/O次数远超图索引随机读延迟高传统SSD的随机读延迟在微秒到毫秒级无法支撑在线检索的SLA所以在HDD/早期SSD时代聚类索引被认为不适合在线向量检索只用于离线批处理。但是现代NVMe SSD的性能已经发生了质变。三、HELMSMAN架构全景五大核心组件3.1 系统总览┌─────────────────────────────────────────────────────────────────┐ │ HELMSMAN 系统架构 │ │ │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ 查询接口层Query Interface │ │ │ │ 接收查询向量 → 返回Top-K最近邻向量 │ │ │ └────────────────────┬────────────────────────────────────┘ │ │ │ │ │ ┌────────────────────▼────────────────────────────────────┐ │ │ │ 分层学习式搜索剪枝LLSP │ │ │ │ 学习模型动态决策哪些聚类需要加载哪些可以跳过 │ │ │ └────────────────────┬────────────────────────────────────┘ │ │ │ │ │ ┌────────────────────▼────────────────────────────────────┐ │ │ │ 用户态存储栈SPDK-based ANNS Storage │ │ │ │ 绕过内核 → 直接管理NVMe队列 → 批量提交固定大小I/O请求 │ │ │ └────────────────────┬────────────────────────────────────┘ │ │ │ │ │ ┌────────────────────▼────────────────────────────────────┐ │ │ │ GPU加速计算层 │ │ │ │ 向量距离计算L2/内积与NVMe读取形成并行流水线 │ │ │ └────────────────────┬────────────────────────────────────┘ │ │ │ │ │ ┌────────────────────▼────────────────────────────────────┐ │ │ │ NVMe SSD全闪存存储层 │ │ │ │ 聚类列表按原始LBA布局分布热点数据常驻内存 │ │ │ └─────────────────────────────────────────────────────────┘ │ │ │ │ 核心原则算法与存储栈联合设计I/O与计算充分重叠 │ └─────────────────────────────────────────────────────────────────┘3.2 五大组件清单组件功能创新点聚类式索引向量分组与索引组织回归聚类索引放弃图的串行依赖用户态存储栈NVMe SSD直接访问基于SPDK绕过内核I/O路径分层学习式搜索剪枝动态决策读取范围用学习模型替代固定阈值GPU加速计算向量距离计算加速与NVMe读取形成并行流水线弹性分布式构建大规模索引构建分布式流水线处理编码、聚类、写入四、核心创新一聚类索引的回归——“The Clustering Strikes Back”4.1 为什么聚类索引可以反击HELMSMAN论文标题中的The Clustering Strikes Back直接回答了这个问题。聚类索引能够在现代硬件上复兴依赖于两个关键变化变化说明NVMe SSD并行带宽大幅提升现代NVMe SSD的并行读取带宽已经足够支撑聚类索引的多I/O需求瓶颈从I/O数量转移到了软件栈聚类索引的真正瓶颈不是I/O次数多而是软件栈没有把这些I/O高效地批量送到硬件4.2 聚类索引 vs 图索引存储依赖的对比维度图索引DiskANN/SPANN聚类索引HELMSMAN访问模式串行依赖每读一个节点决定下一个读哪里独立并行多个聚类列表可以同时读取I/O特征少量随机读大量固定大小的批量读对SSD的要求低延迟随机读高吞吐批量读软件栈需求需要缓存图结构需要高效批量提交I/O内存需求高存储图结构低只存聚类中心和映射关键洞察聚类索引的独立并行I/O模式恰恰是现代NVMe SSD最擅长的。SSD的并行性在批量读取固定大小的数据块时表现最优而聚类索引的cluster list天然就是固定大小的块。4.3 聚类索引的设计HELMSMAN的聚类索引设计设计要素实现方式向量分组k-means聚类将十亿级向量分组到固定大小的cluster固定cluster大小所有cluster大小一致简化空间分配Chunk-based分配器避免通用文件系统 overhead直接按块分配原始LBA布局cluster list直接映射到NVMe SSD的物理逻辑块地址五、核心创新二用户态存储栈——SPDK直访NVMe5.1 传统Linux I/O路径的问题传统的Linux存储栈从用户空间到NVMe SSD需要经过多层┌──────────────────────────────────────────────────┐ │ 传统Linux I/O路径 │ │ │ │ 用户空间应用 │ │ │ │ │ ▼ │ │ ┌──────────┐ │ │ │ 文件系统 │ ext4/xfs/btrfs │ │ └────┬─────┘ │ │ │ │ │ ▼ │ │ ┌──────────┐ │ │ │ VFS层 │ Virtual File System │ │ └────┬─────┘ │ │ │ │ │ ▼ │ │ ┌──────────┐ │ │ │ 块设备层 │ Block Layer │ │ └────┬─────┘ │ │ │ │ │ ▼ │ │ ┌──────────┐ │ │ │ 内核驱动 │ Kernel NVMe Driver │ │ └────┬─────┘ │ │ │ │ │ ▼ │ │ NVMe SSD │ │ │ │ 问题多层抽象带来上下文切换、锁竞争、数据拷贝 │ └──────────────────────────────────────────────────┘每一层都带来额外开销层级开销来源影响文件系统元数据管理、权限检查增加延迟VFS抽象层转发CPU浪费块设备层I/O调度、合并不适合固定大小批量I/O内核驱动中断处理、上下文切换延迟抖动5.2 SPDK用户态方案HELMSMAN使用SPDKStorage Performance Development Kit完全绕过内核路径┌──────────────────────────────────────────────────┐ │ HELMSMAN SPDK用户态路径 │ │ │ │ 用户空间应用HELMSMAN │ │ │ │ │ ▼ │ │ ┌──────────────────────┐ │ │ │ SPDK用户态NVMe驱动 │ Polled-mode, zero-copy │ │ └──────────┬───────────┘ │ │ │ │ │ ▼ │ │ NVMe SSD直接管理SQ/CQ队列 │ │ │ │ 优势无上下文切换、无锁、零拷贝、直接轮询 │ └──────────────────────────────────────────────────┘SPDK的核心特性特性说明HELMSMAN的利用方式Polled-mode I/O主动轮询完成队列而非被动等待中断消除中断延迟适合高频I/OZero-copy数据直接在用户空间和设备间传输消除内核到用户空间的内存拷贝Lockless无锁队列设计避免多线程竞争开销直接管理SQ/CQ用户空间直接操控NVMe提交队列和完成队列批量提交cluster读取请求5.3 存储栈的关键优化优化项具体做法效果Raw LBA布局cluster list直接按原始逻辑块地址分布避免文件系统元数据开销批量提交固定大小的cluster读取请求批量提交最大化NVMe并行性热点常驻内存高频访问的cluster列表常驻DRAM减少I/O降低尾部延迟六、核心创新三分层学习式搜索剪枝LLSP6.1 传统剪枝的问题聚类索引搜索时需要决定读取哪些聚类列表。传统方法使用固定阈值方法做法问题固定Top-N读取距离查询向量最近的N个聚类不同查询的最优N不同固定值要么浪费I/O要么降低召回率距离阈值只读取距离小于阈值的聚类阈值难以调优且随数据分布变化6.2 LLSP的设计HELMSMAN提出了分层学习式搜索剪枝Leveling-Learned Search Pruning, LLSP特性说明学习模型替代固定规则用训练好的模型动态预测哪些聚类需要加载预判式剪枝剪枝决策在实际读取cluster list之前完成避免中间结果依赖额外I/O分层策略多层剪枝从粗到细逐步缩小搜索范围6.3 为什么预判式如此重要LLSP的一个核心约束是剪枝必须在读取cluster list之前完成。这是因为如果剪枝依赖中间结果后果需要先读取部分cluster list增加额外I/O轮次根据中间结果再决定读更多串行化无法利用NVMe并行性尾部延迟增加无法保证在线检索的SLA所以LLSP的设计哲学是一次性预判批量读取绝不串行等待。6.4 学习模型的训练维度内容训练数据历史查询的真实最优聚类集合特征查询向量与各聚类中心的距离分布、维度统计目标预测哪些聚类包含最近邻向量推理开销极低轻量级模型纯计算无I/O七、核心创新四GPU加速与弹性分布式构建7.1 GPU加速计算HELMSMAN利用GPU加速向量距离计算计算任务GPU加速方式效果L2距离计算GPU并行计算查询向量与候选向量的欧氏距离吞吐大幅提升内积计算GPU并行矩阵乘法适合大规模批量计算Top-K选择GPU并行归约算法快速筛选最近邻7.2 GPU与NVMe的并行流水线HELMSMAN的关键设计是将GPU计算与NVMe I/O重叠┌─────────────────────────────────────────────────────┐ │ GPU-NVMe 并行流水线 │ │ │ │ 时间轴 ──────────────────────────────────────────▶ │ │ │ │ NVMe读取: [Cluster A] [Cluster B] [Cluster C] ... │ │ ╲ ╲ ╲ │ │ ╲ ╲ ╲ │ │ GPU计算: [计算A] [计算B] [计算C] ... │ │ │ │ 关键GPU在计算当前batch时NVMe已经在预读下一batch │ │ I/O与计算充分重叠没有空闲等待 │ └─────────────────────────────────────────────────────┘7.3 弹性分布式构建流水线十亿级向量的索引构建是一个巨大的工程任务。HELMSMAN的构建流水线阶段内容分布式策略向量编码将原始数据编码为向量多节点并行聚类分配k-means聚类分配每个向量到对应clusterGPU加速聚类计算SSD写入将cluster list写入NVMe SSD按LBA布局直接写入无需文件系统弹性设计意味着构建集群可以按需扩缩容——需要快的时候加机器不需要的时候释放资源。八、性能对比HELMSMAN vs 传统方案8.1 硬件成本对比维度HELMSMAN之前HELMSMAN之后改善幅度CPU核心~35,000个大幅减少40台服务器90%DRAM~350TB大幅减少仅需热点数据90%服务器数量数千台约40台90%硬件成本基准降低超过90%—8.2 吞吐量对比HELMSMAN相比现有磁盘向量检索系统的吞吐量提升对比系统吞吐量提升倍数说明DiskANN2x - 16x微软的磁盘图索引系统SPANN2x - 16x微软的高纯度ANN磁盘系统提升幅度取决于具体工作负载和查询复杂度。8.3 延迟保障指标要求HELMSMAN表现平均延迟毫秒级满足P99延迟严格SLA满足热点常驻内存降低尾部延迟吞吐量高并发在线查询满足NVMe并行GPU加速8.4 生产部署HELMSMAN已在小红书的生产环境中部署支撑以下核心业务业务场景特点HELMSMAN适配搜索高并发、低延迟毫秒级响应满足搜索SLA推荐实时性要求高在线检索支持实时更新广告大规模候选集十亿级向量检索能力AI工具集成向量相似度检索支持大模型RAG场景相似内容搜索图片/文本向量匹配高吞吐批量检索九、横向对比向量检索的技术路线之争9.1 主流系统对比系统厂商/机构索引类型存储介质特点HELMSMAN小红书聚类索引全闪存NVMe 少量DRAM成本最低90%硬件节省HNSW开源图索引全内存延迟最低但内存成本极高DiskANN微软图索引磁盘内存缓存平衡方案但I/O瓶颈SPANN微软图索引磁盘内存DiskANN改进版纯度更高FAISS-IVFMeta聚类索引内存经典方案但无法处理十亿级MilvusZilliz多种可配通用向量数据库9.2 全闪存方案的行业趋势HELMSMAN不是孤立现象。2025-2026年多个研究都在探索向量检索上闪存研究机构核心思路HELMSMAN小红书聚类索引 SPDK用户态 LLSPLSM-VEC学术界LSM树结构的磁盘向量检索Turbocharging Vector DBsIBM Research利用现代SSD特性优化向量DBSSD-Controller VDBIBM Research在SSD控制器内直接做相似度搜索这标志着向量检索正在从内存为王转向闪存优先的范式。9.3 为什么是现在条件说明时间点NVMe SSD带宽质变PCIe 4.0/5.0 SSD的并行带宽已超过图索引的I/O需求2024-2025SPDK成熟用户态NVMe驱动成为工业标准2023-2025向量规模爆炸十亿级向量检索成为大厂刚需内存成本成为不可承受之重2025-2026AI应用驱动搜索、推荐、RAG对向量检索的性能和成本都有极致要求2025-2026十、总结维度核心要点硬件成本用40台全闪存服务器替代35,000核350TB DRAM成本降低超90%聚类索引回归“The Clustering Strikes Back”——现代NVMe SSD的并行带宽让聚类索引重新成为最优选择用户态存储栈基于SPDK绕过内核I/O路径零拷贝、无锁、直接轮询最大化NVMe吞吐学习式剪枝LLSP用学习模型替代固定阈值预判式决策避免串行I/O依赖GPU加速GPU计算与NVMe读取形成并行流水线I/O与计算充分重叠生产验证已在小红书搜索、推荐、广告等核心业务上线满足毫秒级SLAHELMSMAN的真正价值不在于省了90%的钱——省只是结果。它真正的贡献是证明了在向量检索领域算法和系统的联合设计co-design可以带来数量级的性能改善。当学术界还在争论图索引好还是聚类索引好时小红书用一篇OSDI论文给出了答案没有绝对好的索引只有和硬件最匹配的索引。聚类索引在HDD时代被判了死刑但在全闪存时代迎来了重生——因为瓶颈从来不是算法本身而是软件栈有没有把硬件的能力发挥到极致。“The Clustering Strikes Back”——这不仅仅是一篇论文的标题更是一个工程哲学的宣言永远不要低估硬件进步给算法带来的新机会。参考资料The Clustering Strikes Back: HELMSMAN — arXiv 2606.13145Xiaohongshu Engine Team Publishes HELMSMAN at OSDI 2026 — PANdailyXiaohongshu HELMSMAN Moves Vector Search to Flash — Remio小红书HELMSMAN用全闪存重构百亿级向量检索 — Xinfinite小红书引擎架构团队OSDI 2026新成果 — AITNTHELMSMANOSDI 2026上的向量检索新突破 — ShowAPI小红书提出HELMSMAN向量检索系统硬件成本节省超90% — OmnitoolsSPDK: Storage Performance Development Kit — OfficialOSDI 26 Technical Sessions — USENIX小红书HELMSMAN入OSDI 2026: 40台干翻35000核 — New Universe
)
