小紅書引擎架構團隊OSDI 2026新成果：HELMSMAN重塑大規模向量檢索基礎設施

近日，圍繞搜索、推薦、廣告等核心業務中的大規模向量檢索成本與性能問題，小紅書引擎架構團隊在 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 規模索引可在數小時內完成重建，為高頻模型更新和向量數據更新提供了可落地的基礎設施能力。

• 論文地址：https://arxiv.org/abs/2606.13145
• 開源倉庫：https://github.com/Red-EAD/helmsman。

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 將構建拆成三階段異構流水線：

• 第一階段用 GPU 加速粗粒度 k-means，快速生成初始質心；
• 第二階段使用彈性 CPU 資源池完成 cluster 切分、負載均衡和邊界 padding；
• 第三階段由多核 CPU 服務器合并 shard、構建質心圖、訓練 LLSP 模型，并物化最終索引。

這條鏈路以 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 場景中的可行性，也為下一代低成本、高性能向量檢索系統提供了新的工程范式。