TurboQuantとは？仕組み・実測精度・2026年7月時点の実装状況

TurboQuantは、GoogleのAmir Zandiehらが提案したKVキャッシュ向けのベクトル量子化手法です。論文はarXivに2025年4月に投稿され（arXiv:2504.19874）、ICLR 2026に採択されました。2026年3月24日にGoogle Researchが「LLM推論のKVメモリを少なくとも6分の1へ、精度劣化ゼロで」と発表したことでニュースにまで広がり、メモリ半導体株が売られる騒ぎにまでなっています。ところが公開から100日あまりが経ち、本家vLLMへのマージと大規模モデルでの実測、そしてllama.cpp本家での不採用という材料が出そろった結果、「精度劣化ゼロ」も「まだ誰も動かせない」もどちらも実態と食い違うことが分かってきました。ここでは仕組み、公表値と実測値の差、いま実際に動かせる環境、NVIDIAのKVTCとの使い分けまでを一次情報にあたって整理します。

まとめ

• TurboQuantはPolarQuant（回転＋スカラー量子化）とQJL（1ビット残差補正）の2段構成で、キャリブレーション用データも追加学習も不要なオンライン量子化である。
• Google Researchの発表値はKVメモリ「少なくとも6分の1」、H100でアテンションのロジット計算が最大8倍（4ビットTurboQuant対32ビット未量子化キー）。ただし同ブログの「精度劣化ゼロ」は実装レベルでは成り立たず、vLLM公式の実測では3ビット系プリセットでQwen3-30BのMRCR（長文検索）AUCが42.3%→31.2%、推論系ベンチは約20ポイント低下する。
• 2026年4月15日にvLLM本家へマージ済み（PR #38479）。--kv-cache-dtypeを切り替えるだけで使える。TensorRT-LLMは未対応。
• llama.cpp本家は2026年6月2日にPRをクローズ（不採用）。したがってOllama・LM Studioでは当面使えない。Macは MLX のコミュニティ実装が現実解。
• vLLM公式の推奨既定は今もFP8。TurboQuantが効くのは「FP8の2倍容量では足りず、なおかつ推論精度より収容量が優先される」ケースに限られる。
• 圧縮率だけならNVIDIA KVTC（最大20倍）が上。ただし12BモデルでH100 1枚・約10分のキャリブレーションが要る。準備工程を挟めないならTurboQuant。

以下、それぞれの根拠と数字を確認していきます。

KVキャッシュがモデル重みより先にVRAMを食い潰す構造

TurboQuantが狙うのはモデル重みではなくKVキャッシュです。Transformerは生成済みトークンのkey/valueを保持し続けるため、必要メモリはコンテキスト長とバッチ数に比例して伸びます。128Kトークン級の長文入力や、複数リクエストを同時に捌くサービングでは、KVキャッシュがモデル重みを追い越し、GPUのVRAMを先に食い潰す側に回ります。

効き方が重み量子化とは違うのはここです。重みを4ビットにしてもバッチ数は増えませんが、KVキャッシュを圧縮すれば同じVRAMに載る同時リクエスト数とコンテキスト長がそのまま増える。「GPU費用が減る」より「同じGPUで何倍捌けるか」が本題になります。長文コンテキストのコストを削る方向としては、DeepSeek-V3.2のDSA（スパースアテンション）のようにアテンション計算自体を疎にするアプローチもあり、TurboQuantはそれと直交する（併用しうる）レイヤーの改善です。

PolarQuantとQJLによる2段構成の圧縮機構

第1段：PolarQuantによる回転とスカラー量子化

PolarQuantはTurboQuantの部品ですが、出自は別論文です（arXiv:2502.02617、AISTATS 2026）。原論文の要点は、ベクトルを極座標に変換して角度を量子化することで、ベクトルごとの正規化定数（スケール）を明示的に持たずに済ませる点にあります。1〜2ビットの低ビット領域では、このスケールのオーバーヘッドが圧縮率を食い潰していました。vLLMやMLXの実装で「PolarQuant段」と呼ばれるのは、ランダム化Hadamard変換で回転をかけてから座標ごとにLloyd-Max量子化を当てる処理です。回転を挟むと成分ごとの値の偏りがならされ、外れ値の大きいチャネルが量子化誤差を独占する状態を避けられます。「TurboQuant vs PolarQuant」という比較で調べる人が多いのですが、両者は競合関係ではなく、後者が前者の第1段に組み込まれた関係です。

第2段：QJLの1ビット残差による内積バイアス除去

論文の核心は「MSE最適な量子化器は内積推定に系統的なバイアスを生む」という指摘です。アテンションが計算するのはqueryとkeyの内積なので、二乗誤差が小さくてもバイアスが乗れば出力はずれ続けます。そこでQJL（Quantized Johnson-Lindenstrauss、Zandiehらの先行研究）の1ビット射影を残差に当て、内積推定を不偏化します。QJLもPolarQuant同様、TurboQuantの構成部品であって別系統の手法ではありません。

キャリブレーション不要が効く場面

この2段構成は入力データの分布を前提にしないため、代表データを集めて統計を取る工程（キャリブレーション）も、モデルの再学習も要りません。実運用ではこれが導入コストの差になります。社内文書やコード、多言語の問い合わせなど入力分布が読めないワークロードでは、キャリブレーション前提の手法は「用意したデータと本番が違う」だけで性能が崩れますが、TurboQuantはその失敗モードを最初から持ちません。Unslothのようなファインチューニングと違い、モデルの重みに一切触らないのも運用上は大きな差です。

「精度劣化ゼロ」の出所と、マージ後に判明した実測値

まず数字の出所を整理します。「KVメモリ6分の1」「最大8倍」「精度劣化ゼロ」は論文の要旨ではなく、2026年3月24日のGoogle Researchブログの表現です。原文は “at least 6x”、つまり最大ではなく少なくとも6分の1。8倍はH100上でのアテンションのロジット計算に限った値で、4ビットTurboQuantを32ビットの未量子化キーと比べたものです。モデル全体の推論が8倍になるわけではありません。論文の要旨が主張しているのは「3.5ビット/チャネルで品質中立、2.5ビット/チャネルで軽微な劣化」であり、こちらのほうが慎重です。

vLLM本家に実装が入ったことで、公表値の答え合わせができるようになりました。PR #38479 が公開しているQwen3-4B（head_dim=128）の測定値がこちらです。

スループットの幅はワークロード依存で、下限がデコード主体、上限が超長文プリフィル主体のときの値です。デコードが重い対話・エージェント用途ほど圧縮のオーバーヘッドが効いてきます。NIAH（干し草の山から針を探す合成タスク）はどのプリセットでも100%で頭打ちのため、プリセット選定の材料になりません。この100%だけを見て「長文検索なら3ビットまで攻めてよい」と判断すると失敗します。vLLMが2026年5月11日に公開した大規模モデルでの追試（”A First Comprehensive Study of TurboQuant”）では、より実務に近い長文検索ベンチのMRCRでQwen3-30B-A3B-InstructのAUCがBF16 45.8%、FP8 43.1%、k8v4 43.0%、4bit_nc 42.3%と保たれる一方、k3v4_ncで33.5%、3bit_ncで31.2%まで崩れました。推論系（AIME25、LiveCodeBench-v6）に至っては積極的なプリセットで約20ポイントの低下です。合成ベンチの100%は実務精度を保証しません。

さらに厳しい事実として、vLLM公式の推奨既定は今もFP8です。FP8はKV容量を2倍にしてスループットをほとんど落とさないのに対し、TurboQuantは最も安全なk8v4でもBF16比80%（Qwen3-30B）、3bit_ncでは73%まで落ちます。FP8で足りるならFP8を使うべきで、TurboQuantを入れる理由は「2倍容量では収まらないが、精度をいくらか譲ってでも収容量を稼ぎたい」という条件が立つときだけです。圧縮率の大きさだけで選ぶのは失敗パターンで、自社の評価セットで測らずに本番へ入れてはいけません。

2026年7月時点の実装状況：vLLM本家、llama.cpp不採用、MLX

vLLM：–kv-cache-dtypeの切り替えだけで利用可能

TurboQuantはvLLM本家に取り込まれています（PR #38479「[Attention Backend] TurboQuant: 2-bit KV cache compression with 4x capacity」、2026年4月15日マージ）。プラグインは不要で、起動時のKVキャッシュ型を切り替えるだけです。

vllm serve Qwen/Qwen3-4B \
  --kv-cache-dtype turboquant_4bit_nc \
  --max-model-len 131072

指定できるのは turboquant_k8v4（FP8キー＋4ビット値）、turboquant_4bit_nc、turboquant_k3v4_nc、turboquant_3bit_nc の4種です。対象はフルアテンションのGQA/MHAモデル（Qwen・Llama・Mistral系）です。Mambaとアテンションのハイブリッド構成、およびGemma 4のようにレイヤーごとにスライディングウィンドウを挟み込むinterleaved SWAのモデルは、PR #38479自身が「follow-up PRで対応予定」として対象外と明記しています。一様なスライディングウィンドウについてはPRとvLLM公式ブログで記述が食い違っているため、この構成を使うなら投入前に自分の環境で検証してください。なお本番サービングの選択肢としてはvLLM一択で、TensorRT-LLMは2026年7月時点で未対応です。Google自身の公式実装コードも公開されていません。

Ollama・LM Studioで使えない理由

「TurboQuantをLM StudioやOllamaで試したい」という需要は多いのですが、結論は2026年7月時点でどちらも非対応、しかも見通しは明るくありません。両者の推論エンジンはllama.cpp／ggml系です。そのllama.cpp本家では、CPU向けKVキャッシュ型を追加するPR #21089（TBQ3_0 / TBQ4_0）が2026年6月2日にクローズ＝不採用になりました。クローズの直接の理由は貢献手順に沿っていない点でしたが、メンテナのJohannes Gaessler氏は同時に「追加コストを正当化する証拠がまだ提示されていない」と述べ、他のメンテナからも「Hadamard回転自体はすでに別途マージ済みで、新規性の主張が弱い」「既存の量子化型に対するKLDでの優位を示すべき」との指摘が出ています。手続きを整えれば通る、という状況ではありません。Discussion #20969 ではMetal・CUDA・CPUの各フォークが並走していますが、本家が一度突き返した以上、公式ビルドに載る時期は読めません。GGUFの量子化はモデル重みの話で、KVキャッシュの型とは別物である点も混同しやすいので注意してください。

Apple Silicon（MLX）とHugging Face経由の利用

Macではコミュニティ実装の arozanov/turboquant-mlx がMetalカーネルを備えており、Qwen2.5-32BをM4 Pro（48GB）で動かした場合に16Kコンテキストのキャッシュが4.2GB→897MB、FP16比98%程度の速度と報告されています。Hugging Face上に「TurboQuant版の重み」を探しに来る人もいますが、TurboQuantは推論時にKVキャッシュを圧縮する手法なので、配布モデルの形式としては存在しません。transformersから触りたい場合は、コミュニティ実装 turboquant-vllm の CompressedDynamicCache で標準の DynamicCache を差し替える形になり、Haystackのチュートリアル49に手順がまとまっています。GPUを新規に選ぶ段階なら、32GB VRAMのIntel Arc Pro B70/B65のような大容量カードで殴るか、vLLM＋TurboQuantで手持ちGPUを延命するかの二択です。

KVTC・KIVI・SnapKVとの選定基準

KVキャッシュ圧縮はTurboQuantの独壇場ではありません。「KVTC」で検索してこの記事に行き着く人が多いので、代表的な手法との違いを判断軸で並べます。

NVIDIAのKVTC（arXiv:2511.01815）は、JPEGなどの画像圧縮で使われる変換符号化をKVキャッシュに持ち込んだ手法です。PCAで特徴を無相関化し、適応量子化とエントロピー符号化をかけることで最大20倍（用途によっては40倍超）の圧縮を達成します。アテンションシンク（先頭4トークン）と直近128トークンは圧縮せずに残す設計で、長文推論の精度を守っているのが特徴です。8Kコンテキストでは、キャッシュを再計算する場合と比べてTTFT（最初のトークンが返るまでの時間）が最大8倍短縮すると報告されています。必要な準備は、12BモデルでH100 1枚・約10分程度のキャリブレーションです。

選定の判断軸は「事前準備を挟めるか」に尽きます。代表データを用意でき、圧縮率を詰めてGPU台数を削りたいならKVTC。準備工程を挟めない、あるいは入力分布が読めないならTurboQuant。KIVI（arXiv:2402.02750）は2ビット非対称量子化で同じくチューニング不要ですが、TurboQuantほど低ビット域の精度を守れません。SnapKV（arXiv:2404.14469）はトークンそのものを捨てる方式なので、捨てた部分を後から参照しうる対話やエージェント用途では原理的に危険で、単発の要約・分類のような使い切りタスクに向きます。

メモリ半導体株の急落と「需要はむしろ増える」という反論

2026年3月24日の発表後、メモリ関連株が売られました。発表週の下落率はMicronが約12%、SK hynixが6.2%、Samsungが4.8%と、AIメモリ需要が縮むという連想が働いた形です。

ただしCNBCなどが伝えたアナリストの評価は「利益確定売りの側面が強く、長期のAIメモリ需要が減るシグナルではない」というものでした。効率化が単価を下げ、下がった単価が新しい用途を呼び込んで総需要はむしろ増える——ジェヴォンズのパラドックスと呼ばれる現象です。技術的にもその見方には筋があります。KVキャッシュが数分の一になれば、これまで採算が合わなかった長文コンテキストや常時稼働のエージェントが実用ラインに乗り、浮いたVRAMは「削減」ではなく「より長いコンテキスト」「より多い同時実行」として消費されるからです。「メモリ価格」で調べる読者向けに補足すると、下がったのは株価であってDRAMの取引価格そのものではありません。TurboQuantが節約するのはGPU上のVRAM使用量であり、メモリの生産量や単価に直接作用する技術ではない点は切り分けてください。

よくある質問

TurboQuantの実用化はいつですか？

すでに実用段階です。vLLM本家に2026年4月15日にマージされており、--kv-cache-dtypeにTurboQuantのプリセットを指定すれば追加のプラグインなしで動きます。「実用化待ち」なのはllama.cpp系（Ollama・LM Studio）とTensorRT-LLMの方です。

OllamaやLM StudioでTurboQuantは使えますか？

2026年7月時点では使えません。両者が使うllama.cpp本家では、TurboQuantのKVキャッシュ型を追加するPR #21089が2026年6月2日にクローズ（不採用）となりました。コミュニティのフォークは複数ありますが、公式ビルドには含まれていません。

3ビット化すると精度は落ちますか？

落ちます。vLLM公式の追試では、3ビット系プリセットでQwen3-30BのMRCR（長文検索）AUCが42.3%→31.2%へ、推論系ベンチは約20ポイント低下しました。合成ベンチのNIAHが100%でも実務精度は保証されないため、既定はturboquant_k8v4かturboquant_4bit_ncに留めるのが安全です。

TurboQuantとNVIDIAのKVTCはどちらを選ぶべきですか？

キャリブレーション用データを用意できるかで決まります。用意できてGPU台数を削りたいならKVTC（最大20倍、12BモデルでH100 1枚・約10分の準備）、準備工程を挟まず既存のサービングへ即入れたいならTurboQuant（学習・キャリブレーション不要）です。

論文と実装はどこで確認できますか？

論文はarXiv:2504.19874「TurboQuant: Online Vector Quantization with Near-optimal Distortion Rate」（Zandieh、Daliri、Hadian、Mirrokni／ICLR 2026採択）、第1段のPolarQuantはarXiv:2502.02617です。実装はvLLMのPR #38479が本家経路、llama.cpp向けの各フォークはDiscussion #20969にまとまっています。Google自身の公式実装は未公開です。

関連記事

• Gemma 4とは｜モデル一覧・必要スペック(VRAM)・量子化(GGUF/AWQ)・ローカル実行を解説【2026年版】
• DeepSeek-V3.2とは？V3.2-Speciale・DSAの仕組みと性能・使い方・料金を徹底解説
• Intel Arc Pro B70/B65とは？32GB搭載Big Battlemageのスペック・価格・性能を比較
• Unslothとは？読み方・使い方・対応モデルと高速ファインチューニングの仕組み