TurboQuant-RaBitQ論争を超えて：AIインフラコストにとってベクトル量子化が重要な理由

グーグルのTurboQuant論文（ICLR 2026）は、ほぼゼロ精度で6倍のKVキャッシュ圧縮を報告した。SKハイニックスは12%下落。サムスンは7％下落した。

この論文はすぐに批判を浴びた。RaBitQ（SIGMOD2024）の筆頭著者であるJianyang Gao氏は、TurboQuantの方法論とベクトル量子化に関する彼の先行研究との関係について疑問を呈した。(Gao博士との対談を近日公開する予定です。興味のある方はフォローしてください)。

この記事は、その議論においてどちらかの味方をするというものではない。ベクトル量子化の論文1本で900億ドルもの市場価値を動かせるという事実は、この技術がAIインフラにとっていかに重要なものになっているかを物語っている。推論エンジンにおけるKVキャッシュの圧縮であれ、ベクトル・データベースにおけるインデックスの圧縮であれ、品質を保ちながら高次元データを縮小する能力は莫大なコストに影響します。

ここでは、なぜ今ベクトル量子化が非常に重要なのか、TurboQuantとRaBitQの比較、RaBitQとは何か、どのように機能するのか、Milvusの中にRaBitQを組み込むエンジニアリング作業、そしてAIインフラストラクチャのためのより広いメモリ最適化の状況について説明します。

なぜベクトル量子化がインフラコストに関係するのか？

ベクトル量子化は新しいものではない。新しいのは、業界がそれをどれほど緊急に必要としているかということだ。過去2年間で、LLMパラメータは膨れ上がり、コンテキスト・ウィンドウは4Kから128K以上のトークンに拡張され、非構造化データ（テキスト、画像、音声、ビデオ）はAIシステムへの第一級の入力となった。こうしたトレンドの一つひとつが、保存、インデックス付け、検索が必要な高次元のベクトルを生み出す。より多くのベクトル、より多くのメモリ、より多くのコスト。

RAGパイプライン、レコメンデーション・エンジン、マルチモーダル検索など、大規模なベクトル検索を実行している場合、メモリ・コストはインフラにとって最大の頭痛の種の一つだろう。

モデルのデプロイメント中、主要なLLM推論スタックはすべてKVキャッシュに依存している。KVキャッシュは、アテンション・メカニズムが新しいトークンごとに再計算しないように、以前に計算されたキーと値のペアを保存する。これがO(n²)ではなくO(n)推論を可能にしている。vLLMから TensorRT-LLMに至るまで、すべてのフレームワークはこれに依存している。しかしKVキャッシュは、モデルの重みそのものよりも多くのGPUメモリを消費します。コンテキストが長くなり、同時ユーザーが増えれば、スパイラルが加速する。

同じプレッシャーがベクトル・データベースを襲います。何十億もの高次元ベクトルがメモリ上にあり、それぞれが1次元あたり32ビットの浮動小数点数です。ベクトル量子化は、これらのベクトルを32ビット浮動小数点数から4ビット、2ビット、あるいは1ビット表現に圧縮し、メモリを90％以上縮小する。推論エンジンのKVキャッシュであろうと、ベクトルデータベースのインデックスであろうと、基礎となる数学は同じであり、コスト削減は現実のものとなる。この分野におけるブレークスルーを報告した1本の論文が、900億ドルの株式市場価値を動かしたのはそのためだ。

TurboQuantとRaBitQの違いは？

TurboQuantもRaBitQも、量子化の前にランダムな回転（ジョンソン・リンデンストラウス変換）を入力ベクトルに適用するという、同じ基礎技術に基づいている。この回転は、不規則に分布するデータを予測可能な一様分布に変換し、誤差の少ない量子化を容易にする。

このような共通の基盤の上に、両者は異なる問題を対象とし、異なるアプローチをとっている：

	TurboQuant	RaBitQ
ターゲット	LLM推論におけるKVキャッシュ（リクエストごとのエフェメラルデータ）	データベースにおける永続的なベクトル・インデックス（保存データ）
アプローチ	2段階PolarQuant (座標ごとのLloyd-Maxスカラー量子化器) +QJL(1ビット残差補正)	シングルステージ：超立方体射影＋不偏距離推定器
ビット幅	3ビットキー、2ビット値（混合精度）	次元あたり1ビット（多ビットのバリエーションあり）
理論的主張	ほぼ最適なMSE歪み率	漸近的に最適な内積推定誤差（Alon-Klartagの下界に一致）
製作状況	コミュニティによる実装。	Milvus 2.6でリリースされ、Faiss, VSAG, Elasticsearchで採用されている。

実務家にとって重要な違いTurboQuantは推論エンジン内の一時的なKVキャッシュを最適化するのに対し、RaBitQはベクトルデータベースが数十億のベクトルに対して構築、シャード、クエリを行う永続的なインデックスをターゲットにしている。本稿では、RaBitQに焦点を当てる。RaBitQは、我々がMilvusに統合し、実稼働させているアルゴリズムである。

RaBitQとは何か？

768次元の1,000万ベクトルデータセットにおいて、RaBitQは各ベクトルを元のサイズの1/32に圧縮し、同時に94%以上の想起率を維持します。Milvusでは、これは全精度インデックスよりも3.6倍高いクエリスループットに相当する。これは理論上の予測ではなく、Milvus 2.6のベンチマーク結果である。

では、どのようにして実現したのか。

従来のバイナリ量子化はFP32ベクトルを1次元あたり1ビットに圧縮する。そのトレードオフとして、情報を捨てすぎているためリコールが低下する。RaBitQ(Gao & Long, SIGMOD 2024)は、同じ32倍圧縮を維持しながら、検索に実際に重要な情報を保持する。拡張版（Gao & Long, SIGMOD 2025）は、これが漸近的に最適であることを証明し、Alon & Klartag（FOCS 2017）によって確立された理論的下界と一致する。

なぜ高次元では座標よりも角度が重要なのか？

重要な洞察：高次元では、ベクトル間の角度は個々の座標値よりも安定で情報が多い。これは測度の集中の結果であり、ジョンソン・リンデンストラウスのランダム投影が機能するのと同じ現象です。

これが実際に何を意味するかというと、高次元ベクトルの正確な座標値を捨て、データセットに対する相対的な方向だけを残すことができる。角度関係（最近傍探索が実際に依存するもの）は圧縮に耐える。

RaBitQの仕組み

RaBitQはこの幾何学的洞察を3つのステップに変えます：

ステップ1：正規化。データセットの重心を基準に各ベクトルをセンタリングし、単位長さにスケーリングする。これにより問題は単位ベクトル間の内積推定に変換される。

ステップ2：ランダム回転＋超立方体射影。ランダムな直交行列（Johnson-Lindenstraussタイプの回転）を適用して、任意の軸への偏りを取り除きます。回転した各ベクトルを{±1/√D}^Dの超立方体の最も近い頂点に投影します。各次元は1ビットに縮退する。結果：ベクトルごとにDビットのバイナリコード。

ステップ3：不偏距離推定。クエリと元の（量子化されていない）ベクトルとの内積の推定量を構築する。この推定器は、O(1/√D)で境界付けられた誤差を持つ不偏推定であることが証明できる。768次元のベクトルに対して、これは94%以上の再現率を維持する。

2値ベクトル間の距離計算は、ビット単位のAND＋ポップカウント-現代のCPUが1サイクルで実行する演算-に削減される。これがRaBitQを単に小さいだけでなく高速にしている。

なぜRaBitQは理論だけでなく実用的なのか？

• トレーニング不要。回転を適用し、符号をチェックする。反復最適化もコードブック学習も不要。インデックス作成時間は積量子化に匹敵。
• ハードウェアに優しい。距離計算はビット単位のAND + popcount。最新のCPU（Intel IceLake+, AMD Zen 4+）はAVX512VPOPCNTDQ専用命令を持っている。シングルベクトル推定はPQルックアップテーブルより3倍速く実行されます。
• マルチビットの柔軟性。 RaBitQライブラリは1ビットを超えるバリエーションをサポートしています：4ビットは～90%の再現率、5ビットは～95%、7ビットは～99%を達成します。
• コンポーザブル。 IVFインデックスや HNSWグラフのような既存のインデックス構造にプラグインでき、バッチ距離計算のためにFastScanと連動します。

紙から製品へ：MilvusでRaBitQを出荷するために構築したもの

オリジナルのRaBitQコードはシングルマシンの研究用プロトタイプです。これをシャーディング、フェイルオーバー、リアルタイムインジェストを備えた分散クラスタで動作させるには、4つのエンジニアリング上の問題を解決する必要がありました。Milvusの中でRaBitQを産業グレードの機能にするために、エンジンの統合、ハードウェアの高速化、インデックスの最適化、実行時のチューニングなど多岐に渡りました。詳細はこちらのブログでもご覧いただけます：ベクトル圧縮を極限まで: MilvusがRaBitQで3倍以上のクエリに対応する方法

RaBitQの分散対応

私たちはRaBitQをMilvusのコア検索エンジンであるKnowhereにプラグインとしてではなく、統一されたインターフェイスを持つネイティブなインデックスタイプとして直接統合しました。Milvusの完全な分散アーキテクチャ（シャーディング、パーティショニング、ダイナミックスケーリング、コレクション管理）で動作します。

重要な課題は、量子化コードブック（回転行列、重心ベクトル、スケーリングパラメータ）をセグメント認識できるようにすることで、各シャードが独自の量子化ステートを構築し、保存できるようにすることです。インデックスの構築、コンパクション、ロードバランシングはすべて、新しいインデックスタイプをネイティブに理解する。

Popcountからあらゆるサイクルを絞り出す

RaBitQのスピードは、バイナリ・ベクトルのセット・ビットをカウントするポップカウントに由来する。このアルゴリズムは本質的に高速ですが、どの程度のスループットが得られるかは、ハードウェアをいかにうまく使うかにかかっています。私たちは、主要なサーバー・アーキテクチャの両方に対応する専用のSIMDコード・パスを構築した：

• x86（Intel IceLake+ / AMD Zen 4+）です：AVX-512のVPOPCNTDQ命令は、複数の512ビットレジスタのpopcountを並列に計算します。Knowhereの内部ループは、バイナリ距離計算をSIMD幅のチャンクにバッチ化するように再構築され、スループットを最大化します。
• ARM（Graviton、Ampere）：同じ並列ポップカウント・パターン用のSVE（Scalable Vector Extension）命令 - ARMインスタンスは、コスト最適化されたクラウド展開でますます一般的になっているため、非常に重要です。

ランタイム・オーバーヘッドの排除

RaBitQは、クエリ時に補助的な浮動小数点パラメータを必要とします。データセットの重心、ベクトルごとのノルム、および量子化された各ベクトルと元のベクトルとの内積（距離推定器で使用）です。これらをクエリごとに計算すると、待ち時間が発生します。完全な元のベクトルを保存することは、圧縮の目的を果たさない。

我々の解決策：インデックス構築時にこれらのパラメータを事前に計算して永続化し、バイナリコードと一緒にキャッシュする。メモリオーバーヘッドは小さいが（ベクトルあたり数フロート）、クエリごとの計算をなくし、高い同時実行性下でもレイテンシを安定させることができる。

IVF_RABITQ: 実際に配置するインデックス

Milvus2.6から IVF_RABITQ（Inverted File Index+ RaBitQ量子化）が導入されました。検索は2段階で行われます：

1. 粗い探索(IVF)。K-meansはベクトル空間をクラスタに分割する。クエリー時には、nprobeに最も近いクラスタのみがスキャンされる。
2. 細かいスコアリング（RaBitQ）。各クラスタ内で、1ビットコードと不偏推定量を用いて距離を推定する。Popcountが重い仕事をする。

768次元、1000万ベクトルデータセットでの結果：

メトリック	IVF_FLAT (ベースライン)	IVF_RABITQ	IVF_RABITQ + SQ8 refine
再現率	95.2%	94.7%	~95%
QPS	236	864	-
メモリフットプリント	32ビット/ディム	1ビット/ディム (元の3%)	~元の25

0.5%のリコールギャップさえ許容できないワークロードの場合、refine_typeパラメータは2つ目のスコアリングパスを追加する：SQ6、SQ8、FP16、BF16、またはFP32である。SQ8は一般的な選択であり、元のメモリのおよそ1/4でIVF_FLATレベルまでリコールを回復する。また、クエリ側（SQ1-SQ8）に対して個別にスカラー量子化を適用することもでき、ワークロードごとにレイテンシとリコールコストのトレードオフを調整するための2つのノブを提供します。

Milvusが量子化を超えてメモリを最適化する方法

RaBitQは最も劇的な圧縮手段ですが、より広範なメモリ最適化スタックの1つのレイヤーに過ぎません：

戦略	戦略	インパクト
フルスタック量子化	SQ8、PQ、RaBitQは精度とコストのトレードオフが異なる	4倍から32倍のメモリ削減
インデックス構造の最適化	HNSWグラフ圧縮、DiskANN SSDオフロード、OOMセーフインデックス構築	インデックスあたりのDRAMを削減し、ノードあたりのデータセットを拡大
メモリ マップ I/O (mmap)	ベクトルファイルをディスクにマップし、OSのページキャッシュを介してオンデマンドでページをロード	すべてをRAMにロードすることなく、TB規模のデータセットを処理
階層型ストレージ	自動スケジューリングによるホット/ウォーム/コールドのデータ分離	頻繁にアクセスされるデータに対してのみメモリ料金を支払う
クラウドネイティブ・スケーリング（Zilliz Cloud、マネージドMilvus）	弾力的なメモリ割り当て、アイドル状態のリソースの自動解放	使用した分だけの支払い

フルスタック量子化

RaBitQの1ビットの極端な圧縮は、すべてのワークロードに適しているわけではありません。Milvusは完全な量子化マトリックスを提供します：SQ8と 積量子化(PQ)は精度とコストのバランスの取れたトレードオフを必要とするワークロードに、RaBitQは超大規模データセットでの最大圧縮に、ハイブリッド構成はきめ細かな制御のために複数の方法を組み合わせています。

インデックス構造の最適化

Milvusは量子化以外にも、コアとなるインデックス構造のメモリオーバーヘッドを継続的に最適化しています。HNSWでは、隣接リストの冗長性を減らし、グラフあたりのメモリ使用量を削減した。DiskANNはベクトルデータとインデックス構造の両方をSSDにプッシュし、大規模データセットのDRAM依存性を劇的に削減した。また、インデックス構築時の中間メモリ割り当てを最適化し、ノードのメモリ限界に近づくデータセットに対してインデックスを構築する際のOOM障害を防止しました。

スマートなメモリロード

Milvusのmmap(メモリマップI/O)サポートは、ベクターデータをディスクファイルにマッピングし、OSのページキャッシュに依存してオンデマンドでロードします。起動時にすべてのデータをメモリにロードする必要はありません。突然のメモリスパイクを防ぐ遅延ロードやセグメント化されたロード戦略と組み合わせることで、TBスケールのベクトルデータセットをわずかなメモリコストでスムーズに操作することができます。

階層型ストレージ

Milvusの3階層ストレージアーキテクチャは、メモリ、SSD、オブジェクトストレージにまたがっています。ホットデータは低レイテンシのためにメモリに留まり、ウォームデータはパフォーマンスとコストのバランスのためにSSDにキャッシュされ、コールドデータはオーバーヘッドを最小化するためにオブジェクトストレージにシンクされます。システムはデータ・スケジューリングを自動的に処理するため、アプリケーション層の変更は不要です。

クラウドネイティブ・スケーリング

Milvusの分散アーキテクチャでは、データのシャーディングとロードバランシングにより、シングルノードのメモリ過負荷を防ぎます。メモリプールは断片化を減らし、利用率を向上させます。サーバレスモードでは、アイドル状態のリソースは自動的に解放され、総所有コストをさらに削減します。

これらのレイヤーの組み合わせ

これらの最適化は代替ではなく、積み重なるものです。RaBitQはベクトルを縮小する。DiskANNはSSD上にインデックスを保持する。Mmapはコールドデータのメモリへのロードを回避する。階層化ストレージはアーカイブデータをオブジェクトストレージにプッシュする。その結果、数十億のベクターに対応するデプロイメントに数十億ベクター分のRAMは必要ありません。

始める

AIデータ量が増加し続ける中、ベクター・データベースの効率とコストは、AIアプリケーションがどこまで拡張できるかを直接決定することになります。私たちは、より多くのAIアプリケーションがプロトタイプから本番へと移行できるよう、高性能で低コストのベクター・インフラストラクチャへの投資を続けていきます。

Milvusはオープンソースです。IVF_RABITQを試すには：

• IVF_RABITQの設定とチューニングのガイダンスについては、IVF_RABITQのドキュメントをご覧ください。
• ベンチマークと実装の詳細については、RaBitQ統合ブログポストをお読みください。
• MilvusのSlackコミュニティに参加して、他の開発者に質問したり学んだりしましょう。
• Milvusオフィスアワー（無料）を予約して、あなたのユースケースについて説明しましょう。

インフラストラクチャのセットアップを省きたい場合は、MilvusのフルマネージドサービスであるZilliz CloudがIVF_RABITQをサポートする無料ティアを提供しています。

RaBitQの第一作者であるCheng Long教授（NTU, VectorDB@NTU）とJianyang Gao博士（チューリッヒ工科大学）へのインタビューを予定しています。ご質問はコメント欄にお寄せください。

よくある質問

TurboQuantとRaBitQとは何ですか？

TurboQuant (Google, ICLR 2026)とRaBitQ (Gao & Long, SIGMOD 2024)は、どちらもランダム回転を使って高次元ベクトルを圧縮するベクトル量子化手法です。TurboQuantはLLM推論におけるKVキャッシュ圧縮を対象としており、RaBitQはデータベースにおける永続ベクトルインデックスを対象としている。どちらもベクトル量子化に対する現在の関心の波に貢献しているが、解決するシステムは異なる。

RaBitQはどのようにして想起を破壊することなく1ビット量子化を実現しているのだろうか？

RaBitQは、高次元空間における測度の集中を利用している：ベクトル間の角度は、次元が増加するにつれて個々の座標値よりも安定する。データセットの重心を基準としてベクトルを正規化し、各ベクトルを超立方体の最も近い頂点に投影する（各次元を1ビットに削減）。証明可能なエラー境界を持つ不偏距離推定器により、圧縮にもかかわらず正確な探索が維持されます。

IVF_RABITQとは何ですか？

IVF_RABITQはMilvusのベクトルインデックスタイプ（バージョン2.6から使用可能）で、ファイルクラスタリングとRaBitQ 1ビット量子化を組み合わせたものです。IVF_FLATの3.6倍のスループットで94.7%の再現率を達成し、メモリ使用量は元のベクトルのおよそ1/32です。大規模なベクトル検索（数百万から数十億のベクトル）を行う必要があり、メモリコストが主な懸念事項である場合（RAG、レコメンデーション、マルチモーダル検索ワークロードで一般的）に使用します。

ベクトル量子化は、LLMのKVキャッシュ圧縮とどのような関係がありますか？

どちらの問題も、高次元の浮動小数点ベクトルを圧縮することに関係しています。KVキャッシュは、Transformerアテンションメカニズムからのキーと値のペアを格納します。長いコンテキスト長では、メモリ使用量においてモデルの重みを超える可能性があります。RaBitQのようなベクトル量子化技術は、これらのベクトルを低ビット表現に削減します。同じ数学的原理、つまり、メジャーの集中、ランダムな回転、不偏距離推定は、データベースのインデックスにあるベクトルを圧縮する場合でも、推論エンジンのKVキャッシュにあるベクトルを圧縮する場合でも適用されます。