Xiaohongshu HELMSMAN、ベクトル検索をフラッシュへ移行し、ハードウェアコストを90%以上削減

Xiaohongshu HELMSMANは、本番環境のベクトル検索を約40台のオールフラッシュサーバーへ移行し、約35,000個のCPUコアと350 TBのDRAMを消費していたワークロードを置き換えました。同社によると、この変更により関連するハードウェアコストが90%以上削減されました。

この成果は、インフラストラクチャに関する従来の前提を覆すものです。低レイテンシのベクトル検索は通常、高価なDRAMにほぼ完全に保持されたグラフインデックスに依存してきました。フラッシュベースのシステムはメモリ要件を削減しましたが、アクセスが遅く予測しにくいため、要求の厳しいオンラインサービスには適さないことが少なくありませんでした。

HELMSMANは異なるアプローチを採用しています。クラスタリングベースのインデックスに、NVMeストレージへの直接アクセス、学習型の検索枝刈り、分散インデックス構築パイプラインを組み合わせています。その結果、メモリ依存度の高い従来のアーキテクチャを維持することなく、インメモリに近い性能を実現したと報告されています。

このシステムは単なる研究室でのベンチマークではありません。OSDI論文によると、XiaohongshuはHELMSMANを数か月にわたって本番環境で運用しています。検索、レコメンデーション、広告、コンテンツモデレーション、検索拡張生成に関連するワークロードを支えています。

したがって、重要な競争軸はXiaohongshuと別のソーシャルプラットフォームとの比較ではありません。低レイテンシのベクトル検索を支配してきたインメモリ・グラフアーキテクチャに対し、オールフラッシュ・クラスタリングがどこまで対抗できるかです。

Xiaohongshu HELMSMAN、研究成果を本番インフラストラクチャへ転換

中心的な変化は運用面にあります。Xiaohongshuが以前はインメモリのワークロードと見なしていたオンラインベクトル検索を、現在はフラッシュストレージが処理しています。

近似最近傍探索（ANNS）は、保存されているすべてのベクトルを走査することなく、クエリに最も近い可能性の高いベクトルを見つけます。セマンティック検索、コンテンツレコメンデーション、広告検索、モデレーション、RAGシステムを支える技術です。

Xiaohongshuは、極めて要求の厳しい規模でこれらのサービスを運用しています。同社の研究者によると、プラットフォーム全体で数千億の埋め込みベクトルと毎秒数百万件のクエリを処理しています。

検索だけでも最大200億のベクトルを対象とします。通常のピークトラフィックは毎秒約300,000クエリに達し、平均レイテンシ目標は約10ミリ秒です。

レコメンデーションサービスでは、異なる負荷特性が生じます。個々のインデックスは100万から1億ベクトルの範囲にあり、合計トラフィックは毎秒約250万クエリに達することがあります。

広告では約10億のベクトルを扱い、同様にミリ秒単位の厳格なレイテンシ要件があります。後続のフィルタリングおよびランキング段階で最終判断を下す前に、これらのサービスは最大3,000件の候補を要求する場合があります。

従来のインフラストラクチャでは、DRAMに格納された分散HNSWインデックスを使用していました。HNSWは、近接するベクトル間の接続をたどり、有望な候補をすばやく見つけるグラフベースのインデックスです。

グラフとベクトルをメモリ内に保持することで、ストレージレイテンシを最小化できます。しかし、コンピューティングリソースが十分に活用されていない場合でも、容量がDRAMに直接依存することになります。

Xiaohongshuによると、同社の広範なインメモリ・ベクトル処理基盤は、約4,000ノード、約50クラスターにわたり、100,000個を超えるCPUコアへと拡大していました。2025年までに、HNSWインデックスはペタバイト規模のDRAMを消費するようになっていました。

HELMSMANは、まだこの処理基盤全体を置き換えてはいません。本番環境での比較対象は、以前に約35,000コアと350 TBのDRAMを使用していたワークロードです。

現在は約40台のHELMSMANマシンがこれらのワークロードを担っています。論文によると、各本番サーバーには12台のNVMe SSDと、700 GBから1.1 TBのDRAMが搭載されています。

この残されたメモリは重要です。オールフラッシュサーバーは、メモリを一切使用しないサーバーではありません。HELMSMANは、クラスターのセントロイド、検索ルーティングデータ、枝刈りモデルをDRAMに保持し、大規模なベクトルリストをSSDに格納します。

それでも、この移行によってハードウェア構成のバランスは変わります。すべてのグラフエッジとベクトルをDRAMに保持するのではなく、コンパクトなルーティング構造と実行中の計算のためにメモリを確保します。

研究者によると、このデプロイメントは数か月にわたり安定して稼働しています。現在、より多くのサービスを対象とした統合ベクトル検索レイヤーとして展開を進めています。

Xiaohongshuは、概念実証実装も公開しました。このコードは検証の出発点になりますが、社内の本番環境にあるすべてのコンポーネントを再現するものではありません。

インメモリHNSWがコスト削減の対象になった理由

HELMSMANが解決しようとしているのは、性能要件に見せかけた容量問題です。

インメモリHNSWは、Xiaohongshuが必要とするレイテンシを実現していました。しかし、そのインフラストラクチャは通常のトラフィックに必要な量をはるかに上回るスループット容量を抱えていました。

研究者らの調査では、オンラインワークロードが使用していたのは、インメモリ環境で利用可能なスループットの約32%から43%にすぎませんでした。ただし、残りの容量は単なる過剰プロビジョニングではありませんでした。

これらのリソースは完全なインデックスを格納し、レイテンシの急増を引き起こすことなくトラフィックのバーストを吸収していました。グラフベースの検索は細粒度のメモリアクセスを大量に必要とするため、これらを削減することは困難でした。

一方、Xiaohongshuによると、保存されるベクトル群は毎年倍増しています。ユーザーがコンテンツを公開し、モデルが新たな表現を生成するたびに、数十億の新しいベクトルが追加されます。

より大規模な埋め込みモデルは、この負荷をさらに増大させます。高次元のベクトルはより多くのストレージを消費し、再学習されたモデルでは、すでにインデックス化されたコンテンツについても新しいベクトルの生成が必要になる場合があります。

この増加は容量だけに影響するものではありません。インデックスの構築、配布、置換に必要な時間とリソースも増加します。

当然考えられる対応策は、ベクトルをSSDへ移すことでした。Xiaohongshuはすでに、一部のモデレーションやRAGアプリケーションなど、レイテンシ要件が比較的緩いワークロード向けに、DRAMとSSDを組み合わせたハイブリッドシステムを使用していました。

オンライン経路への適用は、より困難でした。DiskANNなどのシステムは、圧縮ベクトルをメモリに保持しながら、完全なベクトルとグラフデータをSSDに格納します。

グラフ探索では依存関係の連鎖が生じます。システムはグラフの一部を読み取り、その近傍を評価してから、次に読み取るストレージ位置を決定します。

こうした逐次的な判断により、ストレージ層は高帯域幅SSDアレイを飽和させるのに十分な数の独立したリクエストを発行できません。各クエリが次のグラフ探索ステップを待つ間、高速ドライブは十分に活用されないままになります。

Xiaohongshuは、12台のPCIe Gen5 SSDを搭載したサーバーでDiskANN、Starling、PipeANNをテストしました。報告によると、DiskANNとStarlingは、テスト対象のオンラインワークロードにおいて平均レイテンシとテールレイテンシの目標を達成できませんでした。

PipeANNは並列グラフ探索によってレイテンシを削減しました。しかし、要求されたレイテンシ制限下でのスループットは、インメモリHNSWより10倍から25倍低いままでした。

これが、HELMSMANが既存のグラフインデックスを新しいストレージへ単純に配置しなかった主な理由です。フラッシュを高速化しても、グラフ探索に組み込まれたアクセス依存関係は解消できませんでした。

クラスタリングは、このアクセスパターンを変えます。クエリは最初に関連するクラスターを特定し、その後、複数のクラスターリストを独立したバッチとして読み取ります。

このアプローチでは複数のドライブを同時に使用できます。依存関係のある小規模な読み取りの連続を、より少数で幅広い並列処理へ置き換えます。

MicrosoftのSPANN研究は、このアーキテクチャの重要な形態を確立しました。コンパクトなセントロイドデータをメモリに保持し、より大規模なポスティングリストをストレージに配置します。

Xiaohongshuは、SSDを追加するにつれてSPANNのスケーラビリティがより予測しやすくなることを確認しました。ある実験では、12台のドライブによってスループットがほぼ12倍に向上しました。

それでも、変更を加えていないSPANNは、XiaohongshuのテストでHNSWのスループットの約12%から14%にしか達しませんでした。また、利用可能なSSD帯域幅の26%から59%しか使用していませんでした。

この差が、本当のエンジニアリング上の課題を明確にしました。フラッシュの容量は安価で、総帯域幅も大きい一方、ソフトウェアスタックはその帯域幅を本番クエリのスループットへ十分に変換できていませんでした。

HELMSMANがオールフラッシュ・ベクトル検索を競争力あるものにする仕組み

HELMSMANが機能するのは、ストレージ、検索判断、インデックス構築を一体のシステムとして再設計したためです。

最初のコンポーネントは、ANNS向けに設計されたユーザー空間ストレージスタックです。ユーザー空間ストレージにより、アプリケーションはすべての処理を通常のカーネルファイルシステム経路へ送ることなく、NVMeデバイスと通信できます。

従来の読み取り処理は、システムコール、ファイルシステム、ブロック層、デバイスマッピング、NVMeドライバーを経由する場合があります。各段階でソフトウェア処理と調整が追加されます。

多数のCPUコアが小規模で頻繁な読み取りを発行すると、このオーバーヘッドが顕著になります。ロック競合とコンテキストスイッチにより、SSDハードウェアが自身の上限へ達する前にスループットが制限されることがあります。

HELMSMANは、デバイスへの直接的かつ非同期なアクセス向けに設計されたユーザー空間ストレージフレームワークであるSPDKを使用します。クラスターリストをraw NVMeデバイスへストライピングし、アプリケーションにより近い位置でキューを管理します。

検索スレッドは、選択されたクラスターに対して非同期読み取りコマンドを送信します。その後、ハードウェアの完了キューをポーリングし、データの到着後にベクトル間の距離を計算します。

この設計は、ストレージ操作をクラスタリングされたインデックスに適合させます。クラスターの読み取りは独立しているため、HELMSMANはグラフ探索を待たずに、複数のドライブへ分散してバッチ処理できます。

論文によると、本番環境由来のあるワークロードでは、グラフベースの競合システムが使用したSSD帯域幅は20%未満でした。SPANNはPCIe Gen4ドライブで約55%に達しました。

HELMSMANは同世代のドライブで約85%の使用率を達成しました。Gen5 SSDでは約70%に達しましたが、より大きな利用可能帯域幅によってサーバー内の別のボトルネックが明らかになりました。

2つ目のコンポーネントは、レベリング学習型の検索枝刈りです。枝刈りは、再現率を目標値より下げることなく、どの候補クラスターを除外できるかを判断します。

固定された枝刈りルールは、多様なクエリに対してうまく機能しません。簡単なクエリでは不要なクラスターを走査する一方、難しいクエリでは早く停止しすぎて関連する結果を見逃す場合があります。

ワークロードの違いによって、この問題はさらに悪化します。検索リクエストは100件から3,000件の候補を要求する場合がありますが、RAGリクエストが要求するのはわずか10件から100件です。

HELMSMANはまず、ルーターモデルを使用して初期検索範囲を選択します。次に2つ目のモデルがクラスターを評価し、回答を改善する可能性が低い候補を除外します。

モデルは、クエリ、要求された結果数、セントロイド間の距離、局所的な分布パターンを考慮します。バケット化により、類似したケースを適切な枝刈りモデルへ振り分け、モデルのオーバーヘッドを抑えます。

この学習型アプローチは、バッチ化されたストレージアクセスとの互換性を維持します。ストレージ操作のたびに細粒度の判断を追加するのではなく、読み取り前にバッチを選択します。

平均再現率が同じ条件下で、固定ポリシーでは個々のクエリの40%以上が90%の再現率目標を達成できなかったとXiaohongshuは報告しています。HELMSMANの手法では、80%以上のクエリがその目標を上回りました。

平均再現率とクエリ単位の再現率の違いは重要です。システム全体の平均値が許容範囲にあっても、個々のユーザーには低品質な結果が数多く提示される可能性があります。

3つ目のコンポーネントは、インデックス構築に対応します。クラスタリングベースのシステムでは、ベクトルの分割、クラスターの均等化、一部の境界ベクトルの複製、ルーティング構造の構築が必要です。

CPUのみを使用するSPANNの構築では、小規模な本番インデックスでも数時間、10億ベクトル規模では数日かかる場合がありました。このような遅延は、頻繁に再学習される埋め込みモデルとは相容れません。

HELMSMANは粗いクラスタリングをGPUへ割り当てます。その後、より細かな均等化処理を伸縮可能なCPUワーカープール全体へ分散し、出力を最終的なインデックスへ統合します。

1億ベクトルのインデックスは、192コアのマシンでCPUのみを使用して構築した場合、約9〜12時間を要しました。4基のNvidia L20 GPUにより、そのプロセスは1時間未満に短縮されました。

100億ベクトルのデータセットでは、CPUのエラスティックスケーリングにより、エンドツーエンドの構築時間が16時間超から約4〜7時間に短縮されました。

Xiaohongshuは、トラフィックが少ない時間帯にオンラインクラスタから最大10,000個のCPUコアを一時的に借りることができます。オンラインワークロードが優先され、ワーカーが利用できなくなった場合は構築タスクを再割り当てできます。

この運用上の統合は重要です。新しい埋め込みモデルの導入によって、インデックスが数日間利用不能または古い状態になるのであれば、クエリ処理だけが高速でも役に立ちません。

真の競争はフラッシュのクラスタリング対メモリ上のグラフ

HELMSMANはHNSWを時代遅れにするものではなく、全メモリ型インデックスが経済的に正当化される状況を限定するものです。

インメモリHNSWは、純粋なレイテンシとスループットでは依然として打ち負かすのが困難です。重要なデータはプロセッサの近くに保持され、グラフ走査によって大規模なベクトル群のスキャンを回避できます。

一方、HELMSMANは、定義されたサービスレベル契約の下で十分な性能を実現することを目指しています。これは、あらゆるベンチマークで勝つこととは異なる最適化目標です。

評価対象となったワークロード全体で、Xiaohongshuによると、HELMSMANは既存のDRAMおよびSSDシステムの2〜16倍のスループットを実現しました。2つの100億ベクトルデータセットでは、本番環境のHNSWのスループットの47%〜85%に達しました。

比較では、96個のCPUコアと160 GB〜330 GBのDRAMを搭載したHELMSMANマシン1台が使用されました。HNSWのデプロイメントでは、10個のシャード、320個のコア、2.5 TBのDRAMが使用されました。

報告によると、これらのテストでHELMSMANはCPU使用量を約3〜4分の1に、DRAM消費量を約1桁削減しました。それでも目標レイテンシを満たしました。

このトレードオフは、HNSWフリートが主にインデックスを保持するためにプロビジョニングされている場合に魅力的になります。通常のトラフィックがスループットの半分未満しか消費しないのであれば、最大限のメモリ容量に費用を支払うことは利用効率の低下につながります。

HELMSMANのクラスタリング経路は、より高速なストレージから、より直接的な恩恵も受けます。Gen4からGen5 SSDへのアップグレードにより、低次元ワークロードでのスループットが約55%向上しました。

1,024次元のRAGワークロードでは、その向上率は87%に達しました。同じ世代変更において、グラフベースのSSDシステムの向上率はわずか10%〜30%でした。

これらの結果は、グラフシステムが依然として直列化されたI/Oまたはソフトウェアのオーバーヘッドによって制限されていたことを示唆しています。HELMSMANは、追加されたドライブ帯域幅のより多くを有用な検索処理へと変換しました。

ただし、この比較は普遍的なものではありません。ベクトルワークロードは、次元数、再現率目標、結果件数、フィルタ、更新頻度、レイテンシ要件によって異なります。

Xiaohongshuのオンラインシステムでは、多くの場合、数百から数千の候補を取得します。その後、下流のランキングモデルが、より豊富なコンテンツ情報とユーザーシグナルを使用して、それらの候補をフィルタリングし、再スコアリングします。

幅広いバッチ読み取りによって大規模な候補プールを生成できるため、この環境ではクラスタリングが効果的です。極めて高い再現率で非常に少数の結果を求めるワークロードには、別のインデックスの方が適している可能性があります。

他の研究でも代替案が検討されています。Huaweiと大学の研究者は、コンピューティング、メモリ、SSDストレージを3つの階層に分離するDistVSを発表しました。

DistVSは、低精度ベクトルをコンピューティングの近くに、より高精度なデータをリモートメモリに、正確なベクトルをSSDに保持します。そのPRESSアルゴリズムは、これらの階層をまたいで候補を段階的に除外します。

このアーキテクチャでは、メモリを共有され、独立してスケーリング可能なサービスとして扱います。一方、HELMSMANは、各サービス提供ノード内に高帯域幅フラッシュを集約し、ローカルデバイスを中心にアクセス方式を再設計します。

どちらのアプローチも、すべての運用者に対する唯一の答えを示すものではありません。しかし両者を合わせて見ると、ベクトルインフラストラクチャが、全面的なDRAMか低速なディスクかという二者択一を超えつつあることが分かります。

エンジニアリングチームにとって、より広範な教訓はアーキテクチャにあります。ハードウェアの経済性が意味を持つのは、アクセスアルゴリズムとソフトウェアスタックが、より安価な媒体を活用できる場合に限られます。

したがって、検索インフラストラクチャを評価するチームは、ワークロード全体の挙動を測定する必要があります。技術文書の検索可能なコレクションも、ストレージ容量だけでなく、インデックス作成、更新、検索品質に依存します。

90%のコスト削減という主張では決着しない点

大幅な削減という見出しは、報告されたデプロイメント結果としては信頼できますが、普遍的な購入計算式ではありません。

第1の制約は、証拠の範囲です。詳細な性能およびコストの数値の大半は、Xiaohongshu自身の論文と本番環境での測定から得られています。

OSDIでの公開によって査読が加わり、手法を検証できるようになります。しかし、それはXiaohongshuの社内デプロイメントが独立して再現されたことを意味しません。

公開された概念実証は、外部の研究者が設計上の選択を検証するうえで役立ちます。しかし、非公開のデータセット、トラフィック分布、クラスタ管理、ハードウェア調達条件を再現することはできません。

第2の制約は、比較の境界です。90%という数値は、特定のインメモリデプロイメントから移行したワークロードのハードウェアコストに適用されます。

これには、エンジニアリングの人件費、移行リスク、予備容量、運用ツール、あらゆるネットワークおよびストレージ費用が必ずしも含まれているわけではありません。論文では、総所有コストよりもデバイスコストが直接的に論じられています。

HELMSMANサーバーも相当量のDRAMを保持しています。各700 GB〜1.1 TBのマシン40台は、合計で28 TB〜44 TBのメモリフットプリントを意味します。

これは以前の350 TBの割り当てを大幅に下回りますが、依然として無視できないインフラストラクチャ要件です。このシステムはメモリを排除するのではなく、比率をフラッシュ側へ移します。

第3の制約は、論文の運用上の教訓の中に現れています。フラッシュ帯域幅は、すべてのクエリパターンで均等に利用できるわけではありません。

初期のレコメンデーション試験では、バーストが同じクラスタや論理ブロックに集中することがありました。全体の帯域幅使用率が20%未満の場合でも、こうしたホットスポットによってSSDチップ内部で競合が発生しました。

Xiaohongshuは、選択したクラスタリストの冗長コピーを保存することで、この問題に対処しました。研究者によると、ストレージの増加をわずかに抑えながら、スループットが1.5〜2倍に向上しました。

レプリケーションは実用的な解決策ですが、集約帯域幅が誤解を招く理由も示しています。多数のリクエストが同じ内部リソースで衝突する場合、12基のドライブがあっても役に立ちません。

サーバーのメモリ帯域幅も別の上限を作ります。テスト構成では、12基のGen5ドライブが合計で毎秒約140 GBの外部帯域幅を提供します。

実際には、システムはその容量の約70%しか使用しませんでした。通常は毎秒300 GB〜350 GBである実効DDR5帯域幅が、先にボトルネックになりました。

メモリは、SSDからの転送を受け入れ、CPUの距離計算にデータを供給し、重心検索を支える必要があります。これらの経路が飽和した後は、ドライブを追加しても得られる効果は限られます。

第4の制約は更新に関するものです。HELMSMANはインデックス全体の再構築を高速化しますが、高頻度のインプレース変更を解決するものではありません。

典型的な1億ベクトルのレコメンデーションワークロードでは、1時間ごとの再構築と、毎秒25,000〜30,000件の検索クエリが組み合わされる場合があります。再構築を置き換えるには、同程度の頻度で挿入と削除を並行して処理する必要があります。

研究者らによると、現在の動的ANNSシステムは、そのワークロードで両方の処理頻度を維持できません。そのためHELMSMANは、ハイブリッドな鮮度維持設計を使用しています。

メインインデックスはSSD上に置かれ、定期的に再構築されます。最近の挿入データは補助的なインメモリインデックスに置かれ、削除されたベクトルはビットマップに記録されます。

クエリは両方のインデックスを検索し、候補をマージします。これにより鮮度は保たれますが、メモリ消費、マージ処理、継続的な再構築コストが追加されます。

最後の不確実性は、エンドツーエンドのプロダクト品質です。論文では、再現率、レイテンシ、スループット、帯域幅、構築時間、インフラストラクチャ効率が評価されています。

検索満足度、広告コンバージョン、レコメンデーションへのエンゲージメントなどのビジネス指標は開示されていません。こうした成果は、後続のランキング段階や、より広範なプロダクトの挙動に依存します。

読者は、この結果をXiaohongshuのワークロード下における強力なシステム上の証拠として捉えるべきです。無関係なベクトルデータベースをフラッシュに移行すれば、自動的に同じ割合の削減が得られると考えるべきではありません。

HELMSMANが市場を変えるかどうかを示す3つのシグナル

HELMSMANが業界の基準となるのは、論文発表後に、より広範な移行、外部での再現、持続的なプロダクト品質が伴う場合に限られます。

第1のシグナルは、Xiaohongshu自身の展開です。同社によると、検索、レコメンデーション、広告、その他のベクトルサービス全体で、オールフラッシュサーバーがインメモリデプロイメントを徐々に置き換えています。

現在の40サーバーのデプロイメントがカバーしているのは、はるかに大規模なベクトルフリートの一部にすぎません。大半が移行されれば、このアーキテクチャがより多くのデータセット、トラフィックパターン、障害モードに耐えられることが示されます。

更新されたサーバー台数、DRAM削減量、ワークロードのカバー範囲に注目すべきです。拡大が続けば、フラッシュのクラスタリングがデフォルトのサービス提供層になり得るという主張が強まります。

展開が停滞すれば、表面化していないワークロードの違いがシステムを制限している可能性を示唆します。特定のサービスでは、レイテンシ、再現率、更新動作のために、依然としてインメモリHNSWが必要となるかもしれません。

第2のシグナルは独立した再現です。プレプリントの記録とオープンな実装により、研究者は比較のための安定した基盤を得られます。

有用な再現実験では、最新のGen5アレイ、さまざまなベクトル次元、大きな結果件数、偏りのあるトラフィック、厳格なテールレイテンシ目標をテストする必要があります。小規模な公開ベンチマークだけでは、このデプロイメントの最も厳しい条件を捉えられません。

比較には、DiskANN、SPANN、DistVS、動的インデックスの現行バージョンも含めるべきです。中心となる問いは、HELMSMANが古いベースラインを上回るかどうかではありません。

そのクラスタリングとユーザー空間I/Oの組み合わせが、異なるハードウェア、データ分布、サービス目標においても効率を維持できるかどうかです。

帯域幅利用率とクエリ単位の再現率が独立して確認されれば、Xiaohongshuの主張はさらに強まります。大きな差が見られれば、報告された結果が社内のチューニングにどの程度依存しているかが明らかになります。

第3のシグナルは、ワークロードの拡大に伴って本番環境の品質が維持されるかどうかです。ユーザーが受け取る検索結果やレコメンデーションが劣化するのであれば、インフラストラクチャの削減にほとんど価値はありません。

Xiaohongshuは、下流のモデルが最終的なフィルタリングとランキングを行うため、約90%の再現率を持つ大規模な候補セットを重視しています。この選択は、同社の多段階プロダクトアーキテクチャを反映しています。

異なるパイプラインを持つ運用者は、より少ない結果件数に対して98%以上の再現率を必要とする可能性があります。こうした目標はスキャン量を増やし、コスト上の優位性を弱める可能性があります。

テールレイテンシ、再現率が低い外れ値、ホットスポットの挙動、再構築による鮮度、下流のランキング品質を網羅する証拠に注目すべきです。これらの指標により、システムの効率性が運用上のストレス下でも維持されるかどうかが分かります。

HELMSMANの最も重要な貢献は、フラッシュがメモリを置き換えたという主張ではありません。検索経路を並列アクセス中心に再編成して初めて、最新のSSD帯域幅が有効活用できることを示した点にあります。

インフラストラクチャの責任者にとって、これは具体的な判断基準をもたらします。DRAMがトラフィック処理に使われているのか、単にインデックスを保持しているだけなのかを測定し、実際のレイテンシと再現率目標の下でクラスタ化されたフラッシュをテストすべきです。

研究者にとって、次の課題も同様に明確です。Xiaohongshuの外部で結果を再現し、動的更新を厳しく検証し、どのワークロードでインメモリグラフが依然として正当化されるかを判断することです。

Xiaohongshu HELMSMANは、すでに議論を合成ベンチマークの先へ進めました。次の問いは、他の大規模運用者が、ユーザーが実感する品質を損なうことなく、同様の削減を実現できるかどうかです。