OpenSearchCon North America 2025のキーノートのうち「Accelerated Vector Search」のパートをまとめます。
- スピーカー
- ベクトル検索の基本
- ベクトル検索のパイプラインと2つのユースケース
- CAGRA: GPU専用に設計された新しいグラフベースアルゴリズム
- CAGRAからHNSWへの変換：GPUとCPUの相互運用性
- ベクトルデータベースでの実装ケーススタディ
- パフォーマンス評価の正しい方法
- FAISSとcuVSバックエンドの統合
- OpenSearchへのGPUアクセラレーション統合
- エンドツーエンドの高速化に向けて
スピーカー
- Corey Nolet
- Principal Architect, NVIDIA
ベクトル検索の基本
ほとんどの皆さんは、今までにベクトル検索という言葉を聞いたことがあるでしょう。
簡単に紹介すると、ビデオ、オーディオ、画像、テキストなどのメディアを元にベクトルを作成し、あるアイテムを探したい場合に、それをベクトルにエンコードし、同様のベクトルを探索する手法です。これによって、セマンティック検索と呼ばれる検索を実現できます。
ベクトル検索にはいくつかのアルゴリズムがあります。
最も素朴で単純なアルゴリズムの1つは総当たりです。すべてのベクトルをリストに入れ、クエリベクトルと全て照合することで類似するものを見つけます。これはすべてのベクトル間の総当たりの距離を計算する必要があるため、スケーリングしません。ただ、CPUとGPUの両方で、小規模では近似最近傍法よりも効率的になる場合があります。
近似最近傍法は、大規模なベクトル検索でよく使用される機械学習アルゴリズムです。これらは結果を近似し、検索の品質と検索速度やリソースをトレードオフできます。これらのアルゴリズムの一般的なカテゴリは、ツリーベースとグラフベースです。この2つは相互に排他的ではなく、人々はこれらを組み合わせて使用します。HNSWは人気のあるグラフベースアルゴリズムで、今日のLuceneのベクトル検索機能を使用したことがあるなら、聞いたことがあるかもしれません。
今日、非構造化データは2018年以来7年間、文字通り指数関数的に増加しており、今日使用されている新しいデータのほとんどを占めています。
こうしたデータはembeddingとインデックス作成に時間がかかります。様々なパートナー、顧客、ユーザーとの会議で、兆規模のベクトルを扱うユースケースすら話題になるようになってきました。こうした規模に対応できるソリューションが必要なことは明白です。
Nvidia cuVSは、GPU上で高速化されたベクトル検索のためのオープンソースライブラリです。cuVSはデータベースではなく、本質的にはベクトル検索インデックスを構築できる機械学習ライブラリです。
cuVSはOSSであり、Apache 2.0ライセンスです。CUDAとRAFTを基盤とするプリミティブな仕組みの上に構築されています。
GPU上でベクトル検索インデックスをトレーニングするために、データセット全体をGPUに収める必要はありません。
ベクトル検索のパイプラインと2つのユースケース
ベクトル検索のパイプラインは、ソースとなるデータをベクトル化した上でインデックスを構築し、これを元に推論を行います。これは、主に2つの異なるユースケースで活用されます。
セマンティック検索
GPUを活用することで、インデックス構築、量子化、前処理などのスループット集約的なタスクの高速化が図れます。また、埋め込みやLLMの実行に使用したGPUを、ベクトル検索にも活用することでリソースを再利用し、コスト削減が可能になります。
そして処理が高速化することで、結果的にインフラコストを削減することもできます。
CAGRA: GPU専用に設計された新しいグラフベースアルゴリズム
HNSWはグラフベースのアルゴリズムで、CPU上では一度に1つのベクトルずつ構築されます。並列処理は可能ですが、共有状態のロックが必要となり、並列処理には限界があります。
NVIDIAは、この問題を解決するため、GPU上のすべてのコアを活用できる新しいアルゴリズム「CAGRA」を開発しました。CAGRAはGPU専用にゼロから設計されたグラフベースアルゴリズムで、グラフ構築を並列化することでビルド時間を大幅に短縮しています。このアルゴリズムは10,000個のベクトルを並列で高速に検索でき、1つのベクトルでも大規模バッチでもGPUの並列処理を最大限活用します。結果として、オンラインクエリのレイテンシーも低減されています。
ベンチマークによれば、HNSWと比較してインデックス構築時間が10倍以上高速化されています。また、検索性能においても、同等の検索品質（リコール率）を維持しながら、より高いスループットを実現しています。特に注目すべきは、ベクトルの次元数が増加するにつれてこの性能差が拡大する点で、インデックス構築速度は8.2倍から15.5倍まで向上することが確認されています。つまりCAGRAは、インデックス構築と検索の両方でHNSWを大幅に上回る性能を発揮しています。
CAGRAからHNSWへの変換：GPUとCPUの相互運用性
GPU上で構築して検索できるのは素晴らしい機能ですが、検索時にはGPUメモリに常駐させ、GPUを占有する必要があります。しかし現在のRAGなどの生成AIワークロードは、必ずしもGPUベースの検索が求められるような要件ばかりではありません。
そこでNVIDIAが提案するのが、GPU上でインデックスを構築し、検索はCPU上で行うという手法です。HNSWは階層型で各ノードの接続数が可変（スモールワールド次数分布）なのに対し、CAGRAはフラットで固定次数のグラフです。この構造の違いがありながら、CAGRAグラフはHNSWグラフに簡単に変換でき、品質とパフォーマンスを維持できます。
ベンチマークでは、HNSWインデックスの構築には数時間から数日かかることがありますが、CAGRAは20倍以上高速にインデックスを構築できます。変換後のグラフをCPU上でHNSWとして検索しても、検索品質を維持したまま高いスループットを実現します。さらに興味深いことに、高次元のデータにおいては、CAGRAで構築したフラットグラフをCPU上で検索する方が、通常のHNSWよりも高い性能を発揮することも確認されています。
ベクトルデータベースでの実装ケーススタディ
このアルゴリズムを実際のベクトルデータベースで検証するケーススタディを実施しました。OpenSearchコミュニティに敬意を表し、データベース名は伏せさせていただきますが、これはOpenSearchではありません。
80M x 1024次元のベクトル（328GB）のデータセットを使用し、データベースへの大量のベクトル取り込みとインデックス作成を順次処理で計測しました。灰色で示されるベクトル取り込み時間は、ディスクとネットワークI/Oに依存するため、CPUとGPUでほぼ同じ時間がかかります。しかし、緑色で示されるインデックス作成時間では劇的な差が現れました。
CPUでは210分かかっていたインデックス作成が、GPUでは10分で完了し、21倍の高速化を実現しました。エンドツーエンドでは約7倍の速度向上となっています。コスト面でも、CPUインスタンスの$33.88に対してGPUインスタンスは$2.72と、12.5倍のコスト削減を達成しました。これはGPUを他の用途と共有できる場合の計算です。
さらに大規模なテラバイトに規模にスケールアップした検証を行いました。1TBの生テキストから2.5TBの埋め込みを生成するベンチマークでは、CPUとGPUの両方で埋め込み生成とデータロードに約11.5時間かかります。しかし、8つのGPU（DGX 8x H100）を使用することで、インデックス構築をわずか56分で完了できました。
私たちの計算によると、同じインデックス構築をCPUで行うと6.22日かかることになります。これは、GPUが単一ノードのMilvusに対して約20倍の性能向上を実現していることを意味します。つまり、数週間かかる処理が1時間未満に短縮されるという劇的な改善です。
さらに、複数の弱いスケーリングベンチマークを実施し、GPUやCPUを追加してもほぼ線形的な速度向上が得られることを確認しました。これは、より大規模なデータセットに対してもスケーラブルなソリューションであることを示しています。
パフォーマンス評価の正しい方法
よく「HNSWのビルド時間をCPUで測定したら5秒、GPUでは30秒かかりました」といった報告を受けます。しかし、これだけでは全体像が見えません。ベクトル検索アルゴリズムは従来のデータベースインデックスとは異なり、品質と速度をトレードオフするパラメータの調整が不可欠です。調整せずに使用すると、ゴミのような結果になる可能性があります。
そこで次に尋ねるのが「どのリコール率に達しましたか？」という質問です。すると「GPU版は99%のリコール率、HNSWは80%でした」といった答えが返ってきます。これで差の一部は説明できますが、まだ不十分です。両方のアルゴリズムに最適なパラメータが設定されているか、公平な比較条件になっているかを確認する必要があります。
私たちは透明性と正直さを重視しており、弱点も含めて正確に把握したいと考えています。そのため、パレート曲線を作成して比較を行います。各アルゴリズムで可能なすべてのパラメータ組み合わせを実行し、検索品質（リコール率）と検索速度のトレードオフから最適な組み合わせを抽出します。この曲線により、例えば「90%のリコール率でどのようなスループットが得られるか」を公平に比較できます。
通常は80%以上のリコール率のウィンドウで比較を行い、最低のビルド時間だけでなく平均値を取ります。最速のビルド設定は往々にして最悪の検索性能になるためです。本番環境では数千のインデックスを構築することはなく、ハイパーパラメータ最適化などの技術を使用しますが、この方法により異なるアルゴリズムを公平に並べて比較することが可能になります。
実際のパフォーマンス評価の結果をお見せします。BiGANN-10Mデータセット（バッチサイズ10、k=100）での検証結果です。横軸はリコール率（検索品質）、縦軸はスループット（1秒あたりのクエリ処理数）を示しています。
各色のドットは異なるインデックスビルド時間（564秒から4436秒）を表しており、それぞれが異なるパラメータ設定での実行結果です。グラフを見ると、ビルド時間が長いほど（紫や水色のドット）、同じリコール率でより高いスループットを達成できる傾向が明確に現れています。
右側の枠内で示したリコール率の範囲（80-89%、90-94%、95-98%、99%以上）で比較を行うことで、実用的な品質レベルでのパフォーマンスを評価しています。特に95-98%のリコール率の範囲では、ビルド時間とスループットのバランスが最も良い設定を見つけることができます。
FAISSとcuVSバックエンドの統合
FAISSは素晴らしいライブラリです。私たちは初期のデータマイニング用機械学習ライブラリでFAISSを使用してきました。FAISSはMetaのFAIR Research組織から生まれ、ベクトル検索とGPU上でのベクトル検索を開拓しました。CPUとGPU間の相互運用性も彼らが最初に実現したもので、ここで敬意を表したいと思います。
NVIDIAとMetaは長年素晴らしい関係を築いており、2021年のコンテストでは私たちが1位を獲得しました。これは10億規模のベクトル検索を実証するもので、FAISSアルゴリズムをベースラインとして使用していました。その後、私たちは「アルゴリズムの実装を提供することもできますが、それよりも新しいアーキテクチャ、新しいCUDAバージョン、新しい命令がリリースされるたびに常に最新の状態を保つライブラリを作成しましょう」と提案しました。これが現在のFAISSのcuVSバックエンドとなり、OpenSearch統合を可能にする最初のステップとなりました。
ベンチマーク結果を見ると、CAGRAをHNSWに変換する手法の有効性が明確です。左のグラフでは、各リコール率でCAGRA（GPU構築+CPU検索）がHNSW（CPU）より5.1倍から8.2倍高速にインデックスを構築できることを示しています。右のパレート曲線では、これらの曲線がほぼ重なっており、変換によって品質が失われないことを証明しています。次元数が増加するにつれてギャップはさらに広がり、8.2倍から15.5倍の改善が見られます。
OpenSearchへのGPUアクセラレーション統合
cuVSはGPU上でベクトル検索を実現し、FAISSとの相互運用性により、GPU上で構築してCPUで検索することが可能になりました。次のステップは、これをベクトルデータベースに組み込むことでした。そこでOpenSearchチームにアプローチし、Vamshi氏、Dylan Tong氏らプロダクトマネージャーと約1年半にわたって協力してきました。
この統合にはOpenSearch側でのアーキテクチャの革新が必要でした。主要な変更点は、インデックス構築を別プロセス（Vector Index Build Component）として外部化したことです。これにより、必要に応じてサービスを起動し、スケールアウトできるようになりました。将来的にはサーバーレスインフラストラクチャの構築も可能です。
このアーキテクチャの利点は明確です。GPUは必要な時だけ使用し、必要な時間分だけ支払えばよく、簡単にスケールアウトできます。ベクトルはオブジェクトストアに保存され、OpenSearch Vector Engineとインデックス構築コンポーネント間で効率的にやり取りされます。
予想通り、インデックス構築時間は大幅に短縮され、このアプローチによりコストも大幅に削減できます。詳細については、本日午前にVamshi氏が兆規模のベクトル検索について、Navneet氏がアーキテクチャの変更について講演します。また、素晴らしいブログ記事も公開されていますので、ぜひご覧ください。(これらのセッションについても順次まとめる予定)
opensearch.org
エンドツーエンドの高速化に向けて
ディスクとネットワークの問題はまだ残っており、これが今取り組んでいる課題です。NVIDIAの新しいテクノロジー「S3 over RDMA」を活用することで、この問題に対処しています。RDMA対応のNICやインスタンス内の他のRDMA対応デバイスがある場合、S3プロトコルを介してRDMAを利用し、ベクター取り込みをさらに2〜3倍高速化できます。
実際のベンチマーク結果では、CPU TCPでの処理と比較して、Dual GPUでcuVSを使用した場合は5倍、S3 RDMAを追加した場合は8倍の高速化を達成しました。重要なのは、このRDMA技術はCPUパスでの処理でも効果があり、GPUを使わない場合でもI/O性能を改善できる点です。
グラフを見ると、オレンジ色で示される取り込み部分が全体の処理時間に占める割合が大幅に減少し、緑色で示されるインデックス構築と良いバランスになっていることが分かります。これにより、以前はボトルネックだったディスクI/Oの問題が解消され、真のエンドツーエンド高速化を実現しています。
PCI Expressを見ると、帯域幅とMIOPS（1秒あたりの数百万IOPS）が指数関数的に増加していることが分かります。約3年ごとに新しいPCI世代が登場し、性能は倍増しています。2022年のPCIe Gen 5では100 MIOPS、2025年のGen 6では200 MIOPS、2028年のGen 7では400 MIOPSに達する見込みです。
このハードウェアの進化により、私たちはもはや計算集約型タスクだけでなく、データ集約型タスクの高速化も可能になりました。NVIDIAのStorage-Nextイニシアチブは、この能力を最大限活用することを目指しています。グラフベースのアルゴリズムは、大量の細かいランダムI/Oを必要とします。グラフのトラバーサルでは、どこをトラバースするか事前に分からないため、すべてがランダムアクセスになります。
GPUの強みは、10万を超えるスレッドを持ち、それぞれが独立してランダムアクセスを実行できることです。Gen 6のGPUは200 MIOPSを生成でき、CPUの限られた並列処理では達成できない性能を実現します。これにより、ディスクベースのインデックス作成が現実的になりました。RAMを増設するよりもディスクを活用する方がコスト効率的で、すべてをシーケンシャルI/Oに変換する必要もなくなります。
ディスクベースのインデックス作成は、ベクトル検索とデータベースにおいて一般的になりつつあります。より多くのノードをスケールアウトして新しいハードウェアに投資するよりも、ディスクを活用する方がコスト効率的です。システムにディスクを追加する方がRAMを増設するよりも安価なのは明らかです。
私たちはKioxia（日本を拠点とするDGXマシン用ディスクを製造するストレージ会社）と協力しています。彼らはAiSaQという新しいライブラリを開発しました。当初はDiskANNの単純な改善として始まりましたが、8ヶ月の開発期間を経て、Storage-Nextを可能にする革新的な機能を実現しました。圧縮されたベクトルをディスクに配置することで、メモリ使用量を削減しながら、レイテンシーは2倍程度の増加に抑えています。
SCADA（Scaled Accelerated Data Access）という別のテクノロジーも開発しています。これはStorage-Nextの中核となる技術で、GPU主導のストレージアクセスを実現し、大規模な並列ランダムアクセスでディスク帯域幅を飽和させることができます。各GPUスレッドがディスクに独立してアクセスできるようになり、IOミックスからCPUを完全に排除することも可能になります。
グラフを見ると、Gen6 NVMeの数が増えるにつれてMIOPSが線形にスケールすることが分かります。ストレージベンダーは、Gen6後期からGen7初期（2025-2028年）のタイムフレームでStorage-Next対応製品を計画しています。これにより、兆規模のベクトルとペタバイト級のインデックスを現実的に扱えるようになります。
要約すると、cuVSはGPU上のベクトル検索のためのライブラリです。FAISSはcuVSを統合し、CPUとGPU間の相互運用性を可能にする素晴らしい手段となっています。そして、FAISSがOpenSearchに統合されることで、OpenSearchはインデックス構築のオフロードを可能にし、スケーラブルでサーバーレスなテクノロジーが実現します。
cuVSは完全にオープンソースであり、GPU上でのベクトル検索とクラスタリングを可能にします。3つのQRコードから、より詳細な情報、技術ドキュメント、実装例にアクセスできます。この技術により、数週間かかっていた処理が数時間に、数時間かかっていた処理が数分に短縮され、真の意味でベクトル検索の未来を切り開いています。
