Amazon OpenSearch Service が GPU アクセラレーションで 10 億規模のベクトルインデックスを構築する仕組み

本記事は 2026 年 8 月 11 日 に公開された「How GPU acceleration builds billion-scale vector indexes on Amazon OpenSearch Service」を翻訳したものです。

生成 AI アプリケーションが急速に増えるなか、いまの検索には高性能なベクトルインデックス作成とスケーラビリティが求められます。データセットが数十億件規模に達すると、従来の CPU ベースのインデックス作成がボトルネックになりがちで、生産性やイノベーションのスピードを鈍らせてしまいます。

GPU で高速化したベクトル (k-NN) インデックス作成が Amazon OpenSearch Service と Amazon OpenSearch Serverless で利用できるようになり、数十億件規模のベクトルにも効率よくスケールできます。この機能は、GPU アクセラレーションによるベクトル検索向けのオープンソースライブラリ NVIDIA cuVS を基盤としており、計算負荷の高いベクトルインデックスの構築を専用の GPU ワーカーにオフロードします。その間、既存の CPU インフラは検索の処理を続けられます。結果として、クエリ性能を犠牲にすることなく、大規模なベクトルインデックスをより速く、より低コストで構築できます。

以前の記事では、性能とコスト面のメリットを詳しく紹介しました。本記事では、この機能の仕組みをさらに掘り下げます。まず、その土台にある分離型アーキテクチャを見ていきます。次に、GPU で構築したインデックスが、品質を落とすことなく CPU データノードで検索可能な形式に変換される過程を説明します。さらに、10 億件の 1024 次元ベクトルを使ったベンチマークで、大規模環境でもこの方式が通用することを示します。最後に、本番環境で GPU アクセラレーションによるインデックス構築を運用する際に推奨するベストプラクティスを紹介します。

ユースケースとメリット

さまざまな業界の企業が、より豊かな顧客体験を提供するために AI やエージェント型のアプリケーションを構築しています。ベクトルインデックス作成の GPU アクセラレーションは、こうした幅広いユースケースで役立ちます。いくつか例を挙げます。

• 新しい埋め込みモデルへの移行を速める: より新しい埋め込みモデルにアップグレードすると、すべてのベクトルを生成し直してインデックスを作り直す必要があります。数億から数十億件規模になると、CPU での再構築には数日から数週間かかることもあります。GPU アクセラレーションなら再構築を数時間に短縮できるため、より高品質なモデルへ移行しつつ、再インデックスにかかる時間と可用性へのリスクを大幅に減らせます。
• 大規模な再インデックスを高速化する: 数十億件の商品リスト、カスタマーレビュー、行動シグナルを扱うグローバルな e コマースアプリケーションでは、新しい商品や埋め込みが追加されるたびに、ベクトルインデックスを素早く作り直す必要があります。GPU アクセラレーションは限られた運用時間内で再インデックスを完了し、検索の関連性を常に最新に保ちます。
• 急増する書き込みや高い持続書き込みを吸収する: ワールドカップやオリンピックといった大規模スポーツイベントを扱うメディア企業では、数百万件のリアルタイム埋め込みを同時にインデックスする必要があります。これらの埋め込みは、試合のハイライト、解説クリップ、選手のプロフィール、ファンが投稿したコンテンツにまたがり、同時に数百万人の視聴者が関連コンテンツを検索します。GPU ワーカーはこのインデックス作成の急増を吸収し、ライブ検索トラフィックを処理する CPU ノードと競合しません。そのため、大量書き込みにつきものの遅延の急増を避けられます。
• 読み書き混在のワークロードに合わせてクラスターを最適化する: 小売システムでは従来、カタログ更新時のピーク時のインデックス負荷と、同時に発生する検索トラフィックの両方に対応するため、CPU クラスターを過剰にプロビジョニングし、ピーク時の容量分を常時支払っていました。インデックス作成を GPU にオフロードすれば、CPU クラスターを検索専用に適正なサイズへ調整でき、性能を落とさずにインフラコストを削減できます。
• セマンティック検索や OpenSearch への移行を速める: テキストベースのコーパスを初めてベクトル埋め込みに変換する場合でも、既存のベクトルワークロードを別のデータベースから Amazon OpenSearch Service へ移行する場合でも、GPU アクセラレーションによるインデックス作成なら、数日かかるインデックス構築を数時間に短縮できます。GPU による上流の埋め込み生成のスピードに歩調を合わせ、切り替え時のリスクも最小限に抑えられます。

GPU アクセラレーションはいつ有効になるのか

GPU アクセラレーションは、オプトインすれば自動的に有効になります。OpenSearch Service ドメインでは、Vector Acceleration オプションをオンにするだけで有効になり、それ以降はコードや API フラグを変更する必要はありません。OpenSearch Serverless では、NextGen ベクトル検索コレクションで GPU によるインデックス構築の高速化がデフォルトで有効です。図 1 はインデックス構築のワークフローを示しています。OpenSearch はセグメントのサイズに応じてベクトルインデックス作成の処理を GPU と CPU に自動で振り分け、性能を最適化します。問題が発生した場合は CPU にフォールバックします。

OpenSearch がセグメントをフラッシュまたはマージするとき、そのセグメントのベクトルデータサイズを、index.knn.remote_index_build.size.min と index.knn.remote_index_build.size.max で区切られた設定可能な範囲と比較します。下限のデフォルトは 50 MB です。下限を超えるセグメントはリモートの GPU ワーカーにオフロードされ、それより小さいセグメントはローカルの CPU で構築されます。セグメントのベクトルサイズは次の式で計算します。

segment_vector_size = num_vectors × dimensions × bytes_per_element

そのため、ドキュメント数が同じ 2 つのワークロードでも、セグメントサイズが異なることがあります。

どちらの例もデフォルトの下限 50 MB を超えているため、デフォルト設定では両方のセグメントが GPU ワーカーにオフロードされます。

分離型のインデックス作成アーキテクチャ

OpenSearch のインデックスは内部的にセグメントに分割され、各セグメントが独自のベクトルグラフを持ちます。このセグメント単位の構造こそが、GPU へのオフロードを実用的にしています。各セグメントのグラフは、インデックス全体で調整をとらなくても、GPU ワーカー上で独立して構築できます。これを土台にした、アーキテクチャ上の重要な着想が、ベクトルをインデックスする場所と検索する場所を分離することです。既存の CPU データノードは、取り込み、検索、ベクトル以外のワークロードの処理を続けます。セグメントがベクトルインデックスの構築段階に入ると、負荷の高いグラフ構築の作業が専用の GPU ワーカーにオフロードされ、完成したインデックスがデータノードに返されて検索に使われます。

インデックス構築のワークフロー

1. 取り込み – ベクトルフィールドを持つドキュメントは、通常どおり OpenSearch Service ドメインまたは OpenSearch Serverless コレクションに取り込まれます。ベクトルは CPU データノード上のセグメントに蓄積されていきます。
2. オフロード – セグメントがフラッシュまたはマージされ、そのベクトルデータが GPU の有効化範囲に収まると、データノードは元のベクトルを Amazon Simple Storage Service (Amazon S3) にアップロードし、構築リクエストを送信します。
3. 構築 – マネージドなウォームプールの GPU ワーカーがジョブを受け取り、ベクトルを読み込んで、NVIDIA cuVS の GPU ネイティブなグラフアルゴリズムである CAGRA (CUDA ANN Graph) を使ってインデックスを構築します。できあがった CAGRA グラフは、その後 CPU ベースの検索と互換性のある Hierarchical Navigable Small World (HNSW) グラフに変換されます。
4. 受け取り – 完成した HNSW インデックスは Amazon S3 に書き戻され、データノードがダウンロードします。データノードはそのインデックスを使って検索クエリに応答します。

フルマネージドな GPU インデックス構築

Vector Acceleration を有効にするだけで、あとは Amazon OpenSearch Service が処理します。

自動スケーリング – GPU ワーカーは、待機中の構築ジョブ数に応じて自動でスケールアップ・スケールダウンします。一括取り込みや再インデックスの際には、負荷に対応するために GPU ワーカーが増えます。キューが空になると、ゼロまで縮小します。

自動インスタンス選択 – サービスがセグメントサイズに基づいて、構築ジョブごとに適切な GPU インスタンスタイプを選びます。ユーザー側でキャパシティプランニングやインスタンスの選択を行う必要はありません。

アクティブな構築時のみ課金 – 課金されるのは GPU が実際にインデックスを構築している間だけで、アイドル状態のときは課金されません。ドメインやコレクションで Vector Acceleration を有効にしていても、OpenSearch Compute Unit (OCU) で計測される GPU の料金は、セグメントが有効化のしきい値に達してインデックス構築が始まったときにのみ発生します。GPU インフラを常時保有するコストはかかりません。

したがってコストは、インデックス作成の量に応じて直接増減します。急増する再インデックスのワークロードは構築が続く間だけ GPU 容量を消費し、次の構築まで GPU コストはゼロに戻ります。

図 2 は分離型の GPU ワークフローを示しています。Amazon S3 がデータノードと GPU ワーカーの仲介役となり、両者が独立して動作できるようにします。データノードは元のベクトルを Amazon S3 にアップロードし、GPU ワーカーが CAGRA グラフを構築して HNSW に変換します。完成したインデックスはデータノードに返されて検索に使われ、その間も検索は中断なく動き続けます。

CAGRA から HNSW への変換の中身

前のセクションでは、GPU ワーカーがベクトルインデックスを構築してデータノードに返す流れを説明しました。では、GPU で構築したグラフはどうやって CPU で検索可能になるのでしょうか。そして、この変換で品質は落ちるのでしょうか。結論から言うと、落ちません。

CAGRA アルゴリズム

GPU ワーカーは、Facebook AI Similarity Search (Faiss) ライブラリの cuVS GPU バックエンドを通じて統合された CAGRA アルゴリズムを使います。CAGRA は、GPU アクセラレーションを前提に一から設計されたグラフベースのインデックス作成手法です。まず、Inverted File with Product Quantization (IVF-PQ) や Nearest Neighbor Descent (NN-Descent) といった別の近似最近傍探索の手法を使って k-NN グラフを構築します。次に、近傍間の冗長な経路を取り除き、探索しやすいグラフに整えます。

出典: CAGRA: Highly Parallel Graph Construction and Approximate Nearest Neighbor Search for GPUs

GPU ワーカーによるインデックス構築の流れ

GPU ワーカーがベクトルインデックスの構築リクエストを受け取ると、そのリクエストにはセグメント固有のベクトルインデックスを構築するために必要なパラメータが含まれています。ベクトルインデックス構築コンポーネントは、まず Amazon S3 からベクトルファイルを取得して CPU メモリに読み込み、処理を開始します。読み込んだベクトルを使って、Faiss で CAGRA インデックスを構築します。GPU 上で CAGRA インデックスを構築したあと、CPU ベースの検索処理と互換性を持たせるために HNSW グラフ形式へ変換します。できあがったインデックスを Amazon S3 にアップロードして、構築リクエストが完了します。

CAGRA グラフを HNSW に変換する

一般的な HNSW インデックスは、複数の層からなる階層型グラフです。グラフの最下層 (レイヤー 0) がベクトルを保持し、上位の層はナビゲーションだけに使われる疎なサブセットです。上位の層は、検索アルゴリズムが最下層への適切な入口を見つけるのを助けます。ただし、今回の HNSW 実装では CAGRA グラフを最下層として使い、CAGRA の検索手法と同じように、グラフへのランダムな入口から探索を始めます。そのため上位の層はまったく必要ありません。

つまり、基盤となる層のグラフを構築する重い処理は GPU が担います。そのグラフを HNSW の基盤層としてそのまま再利用することで、CPU で作り直す必要がなくなり、変換の負荷を低く抑えられます。図 4 のように、CAGRA グラフがそのまま基盤層になります。クエリの実行時には、グラフ内のノードをランダムに選び、最近傍へのリンクをたどってグラフを探索します。これは貪欲探索 (greedy search) と呼ばれる方法です。

同じ再現率で、より速い構築

これまでのベンチマークで、GPU で構築したインデックスが、CPU で構築した HNSW と同じ再現率を、品質を落とさずに達成することが確認されています。これは、CAGRA が生成する最下層のグラフ構造が、接続性と検索品質の点で、HNSW が CPU 上で構築するものと同等だからです。異なるのは構築の方法だけです。

GPU メモリを超える規模へのスケール

GPU メモリに収まらないデータの構築

従来の GPU インデックス作成では、データセット全体を GPU メモリに載せる必要があり、利用できるハードウェアによってインデックスサイズに明確な上限が生まれていました。CAGRA は、データセット全体を一度に GPU メモリへ載せずに k-NN グラフを構築する方式 (アウトオブコア構築) によって、この制約を取り除きます。CAGRA の初期 k-NN グラフの構築に IVF-PQ を使う場合、データはシステムメモリから GPU へバッチ単位でストリーミングされるため、データセット全体を一度に GPU メモリへ収める必要がありません。その一方で、計算負荷の高い距離計算やグラフの最適化は引き続き GPU が担います。

量子化

GPU アクセラレーションによるインデックス作成は、OpenSearch で利用できる量子化レベル (2 倍、8 倍、16 倍、32 倍の圧縮) に対応しています。量子化は、ベクトルを GPU に送る前に適用されます。これにより、GPU ワーカーへのデータ転送量と、グラフ構築時のメモリ使用量の両方を削減できます。その結果、より大きなセグメントに対してインデックスを構築でき、コスト効率が高まります。

GPU で 10 億件の 1024 次元ベクトルをインデックスする

データセットの準備

現実的な大規模ワークロードを評価するために、1024 次元のベクトルを 10 億件含むデータセットを使いました。一様なランダムベクトルは、インデックス構築と再現率のどちらでも誤解を招く結果になるため、実世界の埋め込みの構造を保ったデータが必要でした。このデータセットは、cuvs-bench に含まれる cuVS の合成データセットジェネレーターで作成しました。このジェネレーターは、Common Crawl から得た実際の埋め込みデータセットの分布を模した合成データを出力します。この方法を使えば、機微な元データを公開したり配布したりせずに、現実的なデータセットを用意できます。ジェネレーターは、10 億件のベクトルデータセット一式と 10,000 件のクエリベクトル、および対応する正解ラベルを、1 台の Amazon Elastic Compute Cloud (Amazon EC2) g6e.16xlarge インスタンス上で、約 2 時間で生成できます。

クラスター構成

ベンチマーク用のクラスターは、OpenSearch のベクトル検索のパフォーマンスチューニングのベストプラクティスに従って OpenSearch Service 上に設計し、OpenSearch Benchmark フレームワークを使ってベンチマークを実施しました。

適用した主なベストプラクティス

1. メモリ最適化インスタンス – r8g.4xlarge は、構築後の HNSW グラフを読み込むのに十分なヒープとネイティブメモリを備えています。
2. 一括取り込み中はリフレッシュを無効化 – 小さなセグメントが多数生成され、それぞれが個別の GPU 構築を発生させるのを防ぎます。
3. 多数の一括クライアント – ノード全体で取り込みを飽和させ、GPU がインデックス構築で常に稼働している状態を保ちます。

HNSW の構築と検索の設定 (m や ef_construction など) は OpenSearch のデフォルト値を使いました。ほとんどのユーザーがデフォルト値から始めるため、ベンチマークを実態に即したものに保てます。

ベンチマーク結果

構築時間はデータ量に比例してスケールする

以前の OpenSearch Service でのベンチマークでは、10 億件の 128 次元ベクトル (BigANN SIFT データセット) を約 35.5 分でインデックスしました。最新のベンチマークでは、次元数を 8 倍の 1024 次元に拡大し、274 分でインデックス構築を完了しました。これはデータ量の増加におおむね比例した結果です。GPU アクセラレーションが、次元数が増えても一貫したスループット効率を保つことを示しています。構築時間は固定的な起動コストではなくデータ量に応じてスケールするため、データセットのサイズからインデックス構築時間をあらかじめ見積もれます。この規模でも検索のレイテンシーは低いままだったため、できあがったインデックスは、構築の速さを犠牲にすることなく応答性の高いクエリに対応できました。

GPU アクセラレーション向けに一括取り込みを最適化する

大量のベクトルデータを読み込むとき、インデックスの動作を一時的に調整すると、GPU の処理負荷を大幅に減らせます。この方法は、ユースケースがデータの一時的な鮮度低下を許容できる場合に有効です。インデックス全体を構築している間は、新しく取り込んだベクトルはリフレッシュを再度有効にするまで検索対象にならないため、通常は問題ありません。一括取り込み中にリフレッシュを無効にする ("index.refresh_interval": "-1") と、小さなセグメントが連続して生成されるのを防げます。そうしないと、小さなセグメントのそれぞれが個別の GPU 構築ジョブを発生させてしまいます。取り込みが完了したら、リフレッシュ間隔を有効に戻してリフレッシュを実行し、セグメントを検索可能にします。この方法により、GPU は多数の小さなセグメントに対して繰り返しインデックスを構築するのではなく、大きく密に詰まったセグメントに対して一度だけ構築するため、全体としてインデックス作成のスループットが速くなります。

GPU アクセラレーションを有効にしたあとは、Amazon CloudWatch メトリクス (クラスターレベル) と OpenSearch k-NN Stats API (ノードごと) で構築状況を監視できます。GPU での構築が失敗した場合、システムは自動的に CPU ベースのインデックス構築にフォールバックするため、データは引き続きインデックスされます。

今後の最適化

現在は、完成した HNSW インデックス (グラフ構造とベクトル) が、GPU ワーカーから Amazon S3 を経由してデータノードに転送されています。データノードは元のベクトルをすでにローカルに保持しているため、今後の最適化ではグラフ構造 (近傍リスト) だけを転送するようにします。これにより、Amazon S3 への書き戻し量とデータノードへのダウンロード時間を大幅に削減できます。

まとめ

GPU アクセラレーションによるインデックス作成を使うと、Amazon OpenSearch Service 上で 10 億規模のベクトルインデックスを、数日ではなく数時間で構築できます。しかも、OpenSearch Service ドメインと OpenSearch Serverless コレクションのどちらでも、クエリの処理方法を変える必要はありません。本記事では、OpenSearch Service が対象となるインデックス構築を GPU ワーカーにオフロードし、Faiss の NVIDIA cuVS バックエンドを通じて CAGRA グラフを構築し、それを CPU で検索可能な HNSW インデックスに変換する仕組みを紹介しました。さらに、10 億件の 1024 次元ベクトルで大規模にこの方式を実証し、一括取り込みの最適化や、構築状況と OCU 使用量の監視についてのベストプラクティスを共有しました。

使ってみる

GPU アクセラレーションによるベクトルインデックス作成を試してみませんか。対応している AWS リージョンでは、OpenSearch 3.1 以降を実行する OpenSearch Service ドメインを作成または更新する際に、GPU アクセラレーションを有効にできます。設定には、AWS マネジメントコンソール、AWS Command Line Interface (AWS CLI)、または AWS SDK を使います。OpenSearch Serverless を新しくデプロイする場合は、NextGen ベクトル検索コレクションを作成してください。このコレクションでは GPU によるインデックス構築の高速化がデフォルトで有効になっており、インデックスごとに制御できます。Classic ベクトルコレクションの場合は、コレクションレベルで GPU アクセラレーションを有効にします。

謝辞

著者一同、本記事への貢献に対し、NVIDIA の Ben Gardner、Manas Singh、Zack Meeks、Jiahong Liu、James Yi、Jinsol Park の各氏に感謝します。

著者について

この記事は Kiro が翻訳を担当し、Solutions Architect の Sotaro Hikita がレビューしました。