ベクトル検索やRAG基盤の規模が大きくなるほど、インデックスの構築時間が運用上の重いボトルネックになります。数億から10億件規模のベクトルをCPUだけでインデックス化すると、完了までに数日から数週間かかることも珍しくありません。埋め込みモデルを新しいものへ移行するたびに全件を作り直す必要があることを考えると、この待ち時間はサービスの改善サイクルそのものを縛る制約になります。

この課題に対して、Amazon OpenSearch Service と Amazon OpenSearch Serverless で GPUアクセラレーションによるベクトルインデックス構築が利用できるようになりました。GPUワーカーへ構築処理をオフロードする分離型アーキテクチャによって、10億規模のインデックスを数日ではなく数時間で構築できるという内容です。本記事では、その仕組みと運用上の勘所を、AWS公式ブログの内容にもとづいて整理します。

大規模ベクトルインデックス構築がボトルネックになる理由

ベクトル検索では、近似最近傍探索のためのグラフ構造を事前に構築します。OpenSearch で広く使われる HNSW は検索性能に優れる一方、グラフの構築自体は計算量が大きく、CPUでは件数と次元数の増加に対して構築時間が急速に伸びます。10億件・1024次元といった規模になると、インデックス作成が取り込みパイプライン全体の律速になりがちです。

さらに現実の運用では、一度作って終わりではありません。埋め込みモデルの入れ替え、次元数の変更、データの再取り込みといった場面で、大規模インデックスの再構築が繰り返し発生します。構築に数日かかる前提だと、検証や切り替えのたびに長い待ち時間が積み上がり、基盤の改善速度を落としてしまいます。GPUによる高速化は、この繰り返しコストを圧縮するところに価値があります。

GPUへ処理をオフロードする分離型アーキテクチャの全体像

今回の仕組みの核心は、取り込みと検索を担うCPUデータノードから、重いグラフ構築だけを切り離して専用のGPUワーカーへ渡す分離型アーキテクチャです。両者の受け渡しには Amazon S3 が中間ストレージとして使われます。

処理の流れはおおむね次のようになります。まずベクトルフィールドを持つドキュメントを通常どおりドメインやコレクションへ取り込み、CPUデータノードのセグメントにベクトルが蓄積されます。セグメントのflushやmergeでGPU対象となるサイズのデータが生じると、データノードが元ベクトルをS3へアップロードして構築要求を送ります。マネージドのGPUワーカープールがそのジョブを受け取り、S3からベクトルを読み込んでインデックスを構築し、完成したHNSWインデックスをS3へ書き戻します。最後にデータノードがそれをダウンロードして検索に使います。

振り分けはセグメントサイズにもとづいて自動で行われます。しきい値より小さいセグメントはCPUがローカルで構築し、大きいセグメントだけがGPUワーカーへオフロードされます。仮にGPUでの構築が失敗しても、システムはCPUベースの構築へ自動的にフォールバックするため、インデックス処理そのものは止まりません。運用者が構築先を細かく指示する必要がない点が扱いやすさにつながっています。

CAGRAからHNSWへ品質を落とさず変換する仕組み

GPUワーカーでのグラフ構築には、NVIDIA cuVS が提供するGPUネイティブなアルゴリズム CAGRA が使われます。CAGRA は Faiss の cuVS GPUバックエンド経由で統合されており、初期の近傍グラフを作ったうえで冗長なリンクを枝刈りし、探索に適したグラフへ仕上げます。

ここで重要なのが、GPUで作った CAGRA のグラフをそのまま HNSW の最下層グラフとして利用できる点です。HNSW の検索はエントリーノードから最近傍リンクをたどる貪欲探索で行われますが、CAGRA が生成する最下層グラフの接続性は、CPUが HNSW で作るものと同等の検索品質を持つとされています。AWSは過去のベンチマークで、GPU構築インデックスがCPU構築のHNSWと同一の再現率を品質のトレードオフなく達成したと説明しています。

つまりGPU化は単なる速度向上ではなく、検索側の仕組みをそのままにしたまま構築部分だけを差し替える設計になっています。検索は従来どおりCPUデータノードで動くため、既存の検索クエリやアプリケーション側の実装を作り替える必要がないことも実務的な利点です。

ベンチマークが示すパフォーマンスとコストのインパクト

AWSが公開したベンチマークでは、10億件・1024次元のベクトルを対象にしています。構成はデータノードが r8g.4xlarge を24台、プライマリシャード48、レプリカ0、GPUワーカーは事前にスケールした10台という内容です。この条件でのインデックス構築時間は274分、探索の再現率は上位100件で0.93と報告されています。

スケール特性の目安として、過去の128次元・10億件のベンチマークでは約35.5分だった構築時間が、次元数を8倍の1024次元にすると274分へと、おおむね次元数に比例して増える傾向が示されています。数日から数週間かかっていた大規模インデックスの構築が数時間の水準に収まることが、運用サイクルに与えるインパクトは大きいといえます。

コスト面では、GPUが実際に構築している時間だけ課金され、アイドル時には課金が発生しないモデルが説明されています。常時GPUインフラを抱える必要がなく、再構築が発生したときにだけ計算資源を使う形です。ここで挙げた数値はいずれも特定の構成での結果であり、次元数や件数、インスタンス構成によって変わる点には注意してください。自社のデータ分布と要件で検証したうえで見積もることをおすすめします。

導入を検討するときに押さえる設計と運用のポイント

まず前提として、GPUアクセラレーションは OpenSearch 3.1 以降で利用できます。Amazon OpenSearch Service ではドメインの作成や更新時に Vector Acceleration を有効化すれば、以降はコードやAPIのフラグを変えずに使えます。OpenSearch Serverless では NextGen vector search collection を作成すると既定で有効になります。

運用でまず効くのが取り込み時のセグメント制御です。一括取り込みの間は refresh_interval を無効化して小さなセグメントが連続生成されるのを防ぎ、取り込みが終わってから元に戻すと、GPUオフロードの対象になりやすい大きめのセグメントが作られます。GPUへ回るかどうかのしきい値は index.knn.remote_index_build.size.min と max で制御でき、下限の既定値は50MBです。

検索を担うCPUデータノードには、構築済みのHNSWグラフを載せられるだけの十分なメモリが必要です。ベンチマークでも使われた r8g.4xlarge のようなメモリ最適化インスタンスが推奨されます。取り込みは並列度の高いbulkクライアントで飽和させ、進行状況は Amazon CloudWatch のメトリクスと k-NN Stats API で監視するとよいでしょう。

設計判断としては、GPU化が効くのは大規模で再構築が繰り返し発生するワークロードです。小規模なセグメントは自動的にCPUで処理されるため、すべての用途で恩恵が出るわけではありません。まずは自社のデータ規模と再構築頻度を棚卸しし、対象バージョンへの更新計画とあわせて、検証環境で構築時間と再現率を実測してから本番へ広げる進め方が堅実です。