ローカルLLMを動かしている人間なら、VRAMとの戦いは日常だと思います。モデルの重みを量子化してなんとかGPUに載せる——これはもう当たり前の作業です。Q4_K_SだのQ5_K_Mだの、GGUFの量子化フォーマットを選ぶのに慣れている人は多いでしょう。
でも、推論時にVRAMを食い潰すのはモデルの重みだけではありません。KVキャッシュという、もう一つの巨大なメモリ消費源があります。長いコンテキストを扱えば扱うほど、こいつが膨れ上がる。70Bモデルで32kコンテキストを処理すると、KVキャッシュだけで20〜40GB消費することもあります。
2026年3月、Google Researchがこの問題に対する新しいアプローチを発表しました。TurboQuantです。ICLR 2026で発表される論文に基づいており、KVキャッシュをわずか3ビットまで圧縮しながら、精度をほぼ維持するという手法です。
従来の量子化とは何が違うのか
まず前提を整理します。普段我々がやっている量子化はモデルの重みを圧縮する技術です。float16やbfloat16をint8やint4に落とすことで、モデルサイズを小さくしてGPUに載せやすくする。これはこれで重要な技術ですが、推論中に動的に生成されるKVキャッシュには効きません。
TurboQuantが狙っているのは、この推論時に動的に生成されるKVキャッシュの圧縮です。つまり、モデルの重みの量子化とは完全に別のレイヤーで動作します。両方を組み合わせれば、メモリ効率はさらに上がるということです。
TurboQuantの仕組み
TurboQuantは大きく2つのステップで動作します。
ステップ1: PolarQuant（ランダム回転＋最適スカラー量子化）
まず、KVキャッシュのベクトルにランダムな直交行列を掛けて「回転」させます。これによってベクトルの各成分がガウス分布に近い予測可能な分布に変わるので、各次元を独立に最適なスカラー量子化（Lloyd-Max量子化）で圧縮できます。従来のベクトル量子化では、ブロックごとにスケール係数やセントロイドをフル精度で保存する必要があり、これが1〜2ビットのオーバーヘッドになっていました。PolarQuantはこのオーバーヘッドを数学的に排除します。
ステップ2: QJL（量子化Johnson-Lindenstrauss変換）
ステップ1で残った微小な誤差に対して、たった1ビットの符号情報を使って補正をかけます。これにより内積の推定が不偏になり、Attentionスコアの精度が上がる——というのが論文の主張です。
ただし、ここには注意点があります。
実装してみた人たちの報告：QJLは実用上微妙
論文の理論は美しいのですが、実際にKVキャッシュ圧縮として実装した複数の独立チームが、QJL（ステップ2）は実用上は逆効果になる場合があると報告しています。
理由はsoftmaxです。Attentionの計算では内積の後にsoftmaxを通しますが、softmaxは値を指数関数的に増幅します。QJLは「不偏だが分散が大きい」推定を生むので、softmaxがその分散を増幅してしまう。結果として、「バイアスはあるが分散が小さい」MSEのみの圧縮のほうが、softmax後の精度は高くなるケースが多いとのこと。
これは論文では議論されていない点で、実装者たちが独立に発見した知見です。llama.cppのDiscussionやGitHub上の複数リポジトリで、少なくとも6つの独立したチームが同じ結論に達しています。理論と実装の間に落ちている、典型的な”論文には書いていないが実用上は重要な話”です。
ローカルLLMユーザーにとっての意味
ここからが本題です。TurboQuantは我々ローカルLLMユーザーにとって何を意味するのか。
llama.cppへの統合が進行中です。
llama.cppのDiscussion #20969でTurboQuantの統合が活発に議論されています。すでにCPU実装（C、依存なし）が18/18テスト通過、CUDAカーネルも書かれています。llama.cppへの統合は6フェーズ計画が立てられており、--cache-type-k turbo3 --cache-type-v turbo3のようなフラグで使えるようになる予定です。
実験的なフォーク（TheTom/turboquant_plus）では、Apple Silicon上のMetalで動作確認済み。turbo2/turbo3/turbo4がサポートされており、Qwen2.5-7BからCommand-R+ 104Bまで複数のモデルで検証が行われています。特筆すべきは、104Bモデルが128Kコンテキストで74GBピークメモリ、MacBook上で動作したという報告です。
具体的に何が嬉しいか：
- コンテキスト長を大幅に伸ばせる。同じVRAMで、より長い文脈をモデルに渡せるようになります
- Qwen3.5-27BのようなモデルをRTX 3090×4で動かした場合、turbo3圧縮で約30GBのKVキャッシュメモリが解放されたという報告があります
- 重みの量子化と併用可能。Q4_K_Mで重みを圧縮し、KVキャッシュをturbo3で圧縮するという二段構えが可能です
注意点もあります：
- 重みの量子化レベルとの相性がある。Q8_0以上の重みではturbo3の対称設定で問題なく動くが、Q4_K_Mの重みだとKeyを高精度に保ったほうが良い場合がある（Keyの精度がsoftmaxによるAttentionルーティングを支配するため）
- モデルのKey/Valueベクトルのノルム比によって最適なビット配分が変わる。Qwenモデルはこの比率が大きい（Keyノルム172〜778 vs Valueノルム2〜4）ので、KeyとValueで異なるビット幅を使うほうが良い場合がある
- 小さいモデル（1B以下）では品質劣化が目立つ。論文の主張はある程度のサイズ以上のモデルで成立する
- 2ビットValue量子化はcos_sim=0.94まで劣化する。品質重視なら4ビットValue（cos_sim=0.997）を使うべき
重みの量子化にも応用できる
TurboQuantは元々KVキャッシュ圧縮の手法ですが、同じアルゴリズムをモデルの重みの量子化にも応用する実装が登場しています（cksac/turboquant-model）。nn.Linearのドロップイン置き換えとして使え、4ビット量子化でbf16比3.2倍のメモリ削減、レイテンシのオーバーヘッドは27%とのこと。残差量子化（2パス）を使えばさらに品質を上げられます。
Qwen3.5-0.8B-Baseで1434MB→361MB（4.0倍圧縮）という数字が出ています。GGUFの量子化とは異なるアプローチなので、将来的にどちらが主流になるか、あるいは共存するかは注目に値します。
vLLM・SGLangへの統合も進行中
サーバー用途としては、vLLMとSGLangへの統合も進んでいます。SGLangでは--kv-cache-dtype turboquantフラグでの利用を目指すissueが立てられており、Tritonカーネルを含む実装がWIP段階です。ローカルで推論サーバーを立てている人にとっても、近い将来使えるようになる可能性が高いです。
まとめ：圧縮の理論的な壁が見えてきた
TurboQuantが面白いのは、単にKVキャッシュのメモリを減らすだけでなく、情報理論的な最適に近い圧縮率を達成しているという点です。つまり、KVキャッシュ圧縮はこのあたりが限界であり、ここから先の大幅な改善は圧縮だけでは難しい——という境界線が見えてきたということでもあります。
ローカルLLMの世界では、モデルの重みの量子化はすでに日常的に使われています。TurboQuantが安定してllama.cppやvLLMに統合されれば、KVキャッシュの圧縮も同様に「当たり前の最適化」になるでしょう。コンテキスト長の制約が緩和されれば、エージェント的なワークフローや長い文書の処理がローカル環境でも現実的になります。
llama.cppのturbo3/turbo4サポートが安定したら、RX7900XTXでQwen3.5-27Bを回しているときのコンテキスト長がどこまで伸びるか、実際に試してみたいところです。
参考リンク:
コメント