ProsGrow が RAG の生ベクトル保存容量を 75% 削減した方法

課題：検索には異なる 2 種類のリソースコストがある

プライベート RAG システムでは、文書のエンコード、ベクトルの保存、検索結果の順位付けにコストがかかります。有用な運用設定は、どの品質変化を許容できるか、どこで能力が制限されるかによって決まります。ProsGrow は Qwen がサポートする表現と vLLM の精度別実行経路を使い、これらの判断を系統的に評価しました。

私たちは生ベクトルのバイト数を 75% 減らす 1,024 次元ベクトルを選び、別の実験では、埋め込みスループットが 69.10% 高い動的 FP8 を選びました。それぞれに独自の品質トレードオフがあります。

判断 1：保存する価値のある次元を残す

Qwen3-Embedding-8B のネイティブな 4,096 次元出力から始めました。SciFact のテストセット全体で、この FP16 ベースラインの nDCG@10 は 0.79279 でした。これは有用な文書が上位にあるほど高く評価する関連性指標です。出力を 1,024 次元に減らした場合は 0.78944、つまりベースライン nDCG@10 の 99.58%でした。

さらに強く圧縮するとランキング品質の低下が大きくなりました。このコーパスには 1,024 次元を選び、Recall@100 は 0.98000 から 0.97333 に低下しました。99.58% という維持率は、この FP16 次元数実験の nDCG@10 だけを指しています。

小さいベクトルが役立つ点と役立たない点

Qwen3-Embedding-8B は Matryoshka 表現を提供し、vLLM の埋め込みランタイムがサポートしています。この上流の機能により、有用性を保った短いベクトルを利用できます。ProsGrow の貢献は、このワークロードで生じる保存容量と品質のトレードオフを評価したことです。

1 億個の float32 ベクトルでは、計算上の生データ保存容量は 1.64 TB から 0.41 TB に減ります。データベース全体の使用容量と検索遅延は、実際のインデックスで引き続き測定する必要があります。

エンコーダはネイティブの隠れ次元幅で計算を続けており、テストした次元数間のスループット変動は最大 1.2% でした。後述する 69.10% のスループット改善は、独立した精度実験によるものです。

判断 2：FP8 による実測のエンコード能力向上

出力次元数と短い入力のワークロードを固定すると、動的 FP8 は 8 レプリカで 319,951 入力トークン/秒となり、FP16 の 189,213 を上回りました。2 回の FP8 ノード実行の低い方から、69.10% の改善率が得られます。

高速な実行経路は vLLM の動的 FP8 サポートによるものです。ProsGrow は想定した FP8 カーネルが各 GPU で実行されることを確認し、精度、同時実行数、レプリカ配置を併せて評価しました。選択した設定より同時実行数を増やしても能力はほとんど増えず、平均遅延は約 2 倍になりました。

最終比較ではプレフィックスキャッシュを無効のままとし、繰り返しのベンチマーク入力でキャッシュ再利用が Transformer の計算を代替しないようにしました。

この最適化ノードでは、100 万入力トークンあたりの GPU ボード消費エネルギーも 44.19% 減り、7.025 Wh に対して 3.921 Wh となりました。これは GPU エネルギーの実測改善で、ホストや施設の電力は指標に含みません。

FP8 の品質面の代償は別に判断する

条件を揃えた FP16 対照実験と 2 回の FP8 起動で、SciFact の品質評価全体を繰り返しました。1,024 次元で、保守的な FP8 結果は nDCG@10 が 0.786211、対応する FP16 対照は 0.789717 で、0.003506 の低下でした。Recall@100 は 0.97333 のままでした。

もう一方の FP8 起動では nDCG@10 が 0.790021 でした。受け入れ判断を保守的にするため、低いスコアを報告します。前述の 99.58% の維持率は元の次元数実験だけの結果であり、次元削減と FP8 を組み合わせた品質保証ではありません。

再ランキング：回答に影響する候補に計算資源を使う

Qwen3-Reranker-8B では、クエリごとに完全な文書 20 件を選びました。ポリシーの実験では候補数と文書の切り詰めの両方を変えたため、効果を候補数だけに帰することはできません。選択したポリシーの nDCG@10 は 0.80482 で、候補集合を小さくすることによる計算削減と検索再現率のトレードオフがあります。

その 20 文書の固定仕様では、動的 FP8 により独立実行のスループットが 2.7444 から 4.6958 検索/秒に、71.10% 向上しました。8 レプリカの保守的な結果は 21.6248 から 44.4738 検索/秒となり、top-20 検索で 77,849 から 160,106 件/時、すなわち +105.66%です。nDCG@10 は 0.804821 から 0.803368 に変化し、Recall@20 は 0.94000 のままでした。

2 回の起動でノードの結果が独立 FP8 レートの 8 倍を上回りましたが、監査後も原因は未解決です。この能力は、この特定設定に適用されます。GPU あたりの精度変更の利点を見るには、独立実行の 71.10% 比較の方が明確な指標です。

顧客にとって何が変わるか

1,024 次元の品質判定を通過するコーパスでは、ベクトルデータを 4 分の 3 減らせます。さらに FP8 の判定を通過する短い入力のインデックス作成では、実測スループットは10 億入力トークンあたり約 52 分に相当し、FP16 ベースラインの 88 分と比較できます。これらはベンチマークのレートを基に算出した処理時間の推定値です。

これにより、より頻繁にインデックスを更新できる余地が生まれます。オンライン検索には統合的な能力計画が必要です。埋め込みと再ランキングのノード全体のレートは、別々に測定されています。

ProsGrow の貢献は、ワークロード要件に合わせて運用設定を選択し、検証することです。顧客向けパイロットには、独自の関連性判定と、回答品質や p95 遅延を含む検索経路全体が必要です。ベンチマークはコンポーネント間のトレードオフを示し、本番サービスには統合検証が必要です。

独立した 2 つのコンポーネントのコスト試算

すべての稼働能力が有料利用される場合、9 月のインフラモデルでは、ノード購入費 $100,000–$150,000 に対し、埋め込みは100 万入力トークンあたり $0.00453–$0.00646、top-20 再ランキングは1,000 検索あたり $0.03258–$0.04644です。計算には、各コンポーネント固有のノード全体の実測レート、319,951 入力トークン/秒または 44.4738 検索/秒を使っています。

これらのシナリオは、3 年償却、年間保守費 5%、720 時間/月、電力料金 $0.10/kWh、電力使用量倍率 1.30、稼働時サーバー電力 6 kW を仮定します。その結果、稼働ノード 1 時間あたりのインフラ費は $5.22–$7.44 と試算されます。6 kW はソリューション群に対する共通仮定であり、上で示した GPU ボードの実測エネルギー改善とは別です。需要が低い場合、固定費を分担する販売単位数が少なくなります。

各コンポーネントは別々のテストで 8 基すべての GPU を使用したため、それぞれの最大値を同時サービス能力として合算できません。費用には保存領域、アプリケーション運用、人件費、ネットワーク、サービス予備能力、回答生成を含みません。合格する回答 1 件あたりの費用にはエンドツーエンドの検証が必要です。

測定方法と制約

• ハードウェアとモデル：RTX PRO 6000 Blackwell Server Edition GPU 8 基、各公称メモリ 96 GB、GPU ごとに 1 レプリカ。埋め込みは Qwen/Qwen3-Embedding-8B のリビジョン 1d8ad4ca9b3dd8059ad90a75d4983776a23d44af、再ランキングは Qwen/Qwen3-Reranker-8B のリビジョン 77d193c791ed757ca307ee72715aa132723da912を使用しました。
• ランタイム：vLLM 0.25.1。精度比較では float16 の活性値と動的 FP8 重みを使い、FP8 カーネル経路を検証しました。最終比較ではプレフィックスキャッシュを無効にしました。
• 埋め込み能力：64 入力をまとめたリクエストで合成の短い入力を使い、入力あたり平均 56 モデルトークン、返却次元数は 1,024 でした。ノードの各実行は 65,536 入力を処理しました。選択した FP8 の共通ウィンドウは 11.467 秒で、2 回の差は 0.47%、失敗リクエストはゼロです。実文書の品質は別に評価しました。
• 検索品質：BEIR SciFact のテストセット全体を使いました。タイトルと要旨からなる 5,183 文書、300 クエリ、公式の関連性判定を、公開元のクエリ指示と総当たりのコサイン検索で評価しました。SciFact は科学分野の 1 つのベンチマークであり、他のコーパスや近似インデックスでは異なる挙動になり得ます。
• 再ランカーの測定範囲：ノードの各実行は 2,400 検索を処理し、検索ごとに完全な文書 20 件を使いました。候補は FP16 の 1,024 次元密ベクトルベースラインから固定したため、FP8 埋め込みと再ランキングを組み合わせたパイプラインの測定ではありません。観測したスループットと品質の低い方を報告します。
• 計時とデプロイ：ウォーム状態の API ウィンドウは、最も早いレプリカ開始から最後の完了までです。起動とペイロード構築は含みません。コネクタ、チャンク分割、ベクトルデータベース操作、生成、本番でのキュー待ちには、エンドツーエンドのパイロットが必要です。1 時間や 10 億トークンの数値は算術換算であり、長時間耐久試験ではありません。
• 保存領域とエネルギー：75% 削減は保存精度を揃えた生ベクトルに対する値です。メタデータ、インデックス構造、複製、バックアップには追加の負担があります。エネルギー数値は GPU ボードのみを対象とします。結果は指定した設定のローカル比較であり、同等モデルのマネージド API に対する費用比較を主張するものではありません。

プライベート RAG 検索とセマンティック検索

プライベートな検索拡張生成（RAG）を計画するチーム向けに、この検証は埋め込みベクトルの保存容量、文書のインデックス作成能力、再ランキング品質を分けて扱います。これらの測定はセマンティック検索インフラの選択に役立ちますが、ベクトルが小さいことだけではデータベースクエリの高速化を証明できません。導入時は検索パイプライン全体で関連性、応答時間、回答品質を検証する必要があります。