論文が出てから72時間後にGoogleのTurboQuantをvLLMプラグインとして出荷しました——他の誰も検証していないこと

Dev.to / 2026/3/28

📰 ニュースDeveloper Stack & InfrastructureIdeas & Deep AnalysisTools & Practical UsageModels & Research

要点

  • GoogleのTurboQuant論文(ICLR 2026)は、TransformerのKVキャッシュを1座標あたり4ビットに圧縮し、精度損失ゼロを謳うことで、GemmaやMistralのようなテキストモデルにおいてH100のメモリ使用量を約5〜6倍削減すると提案しています。
  • 著者はTurboQuantをvLLMプラグイン(「turboquant-vllm」)として72時間以内に実装し、PyPIで公開しました。これにより、コード変更やvLLMのフォークなしでvLLM serve経由で利用できるようになりました。
  • これまでの圧縮研究がトークン・プルーニングに焦点を当てていたのとは異なり、本記事では、視覚言語・動画の設定でTurboQuantを検証します。視覚トークン数が約11,000トークンに達し得るため、KVキャッシュが大幅に大きくなります。
  • RTX 4090上でMolmo2-4Bと約11Kの視覚トークンを用いた場合、KVキャッシュサイズが1,639 MiBから435 MiBへ(約3.76倍)減少し、報告されている比較によれば出力品質を維持できています。
  • 本記事ではTurboQuantをトークン・プルーニング手法の補完として位置付け、VLM動画ワークロードにおける高いトークン数および長いコンテキストの圧力の下でも、4ビットのKV圧縮が引き続き有効であることを示唆しています。

GoogleはICLR 2026でTurboQuantを公開しました。これは、精度損失ゼロで、TransformerのKVキャッシュを座標あたり4ビットに圧縮する手法です。論文では、H100 GPUで5〜6倍のメモリ削減を報告しており、GemmaやMistralのようなテキストモデルで検証されています。

そこで気になったのは:動画を処理するビジョン・言語モデルでも機能するのか?一般消費者向けGPUで?

72時間後、turboquant-vllmがPyPIに登場しました。

Quick Start

pip install turboquant-vllm[vllm]
vllm serve allenai/Molmo2-8B --attention-backend CUSTOM

それだけです。このプラグインはvLLMのエントリーポイント機構を通じて自動登録されます。コード変更不要、フォーク不要、モンキーパッチ不要です。

HuggingFaceユーザー向け:

from transformers import DynamicCache
from turboquant_vllm import CompressedDynamicCache

cache = DynamicCache()
compressed = CompressedDynamicCache(cache, head_dim=128, bits=4)
# Pass cache (not wrapper) to model.generate()

Why Vision-Language Models Matter

他のTurboQuantの実装は、数百トークンのテキストのみのモデルをテストしています。しかし、Molmo2-4Bに12秒の動画クリップを通すと、約11,000個の視覚トークンが生成されます。24GB GPUでのKVキャッシュは1.6GBです。

これは、メモリが10倍、そして精度バグが36層のTransformerを通じて連鎖的に増幅する機会が10倍になります。既存のVLM圧縮文献(VL-Cache、Dynamic-LLaVA、ZipVL)はすべてトークン削減——どのトークンを捨てるかを決めるものです。TurboQuantは、保持するトークンを圧縮します。これらは補完的なアプローチであり、ベクトル量子化が視覚トークンの領域でも生き残るのかどうかは、誰も検証していませんでした。

生き残ります。

Results

Molmo2-4B(RTX 4090)で、Seinfeld動画クリップからの11Kの視覚トークン:

メトリクス ベースライン TQ4 圧縮
KVキャッシュ 1,639 MiB 435 MiB(3.76x)
出力品質 詳細なシーン説明 ほぼ同一(100+トークン一致)
デコードオーバーヘッド 1.78x

Molmo2-8B:同じ3.76xの比率で、Seinfeldの登場人物をすべて正しく識別します。23分のエピソードを24 tok/sで処理しました。

What I Built Differently

Plugin, not fork

他のvLLM TurboQuantの取り組みはフォークまたはモンキーパッチです。turboquant-vllmはvLLMの公式プラグインエントリポイントを使用します:

[project.entry-points."vllm.general_plugins"]
tq4_backend = "turboquant_vllm.vllm:register_tq4_backend"

Incremental dequantization

素朴なアプローチでは、毎レイヤー、毎ステップでKVキャッシュ全体を解凍します——オーバーヘッドは3.36xです。インクリメンタルな解量子化は、各ステップで新しく1トークン分だけを解凍し、進行中のバッファに追記します。オーバーヘッドは1.78xまで下がります。これはGoogleの論文には載っていません。

Cross-platform Triton

融合カーネルは、コード変更なしでNVIDIA CUDAとAMD ROCmの両方で動作します。Radeon 890MのiGPUで84/84のGPUテストがパスします。

Bugs Nobody Else Has Found

  1. FP16ノルムはスケールすると失敗します。11,385トークンまでは動作しますが、11,397トークンで出力が壊れます。ベクトルあたり0.01%の誤差が36層にわたって複合的に積み上がります。常にfp32を使ってください。

  2. QJL補正は標準的な注意(attention)では見えません。論文のStage 2(2-bit MSE + 1-bit QJL)は1ビット分の精度を浪費します。標準のQ @ K^Tでは補正を使えません。3-bit MSEを使うと同一の出力になります。

  3. 融合カーネルにおける複数レイヤーでの精度ドリフト。fp32 Tritonとbf16 SDPAの間で、レイヤーあたりcosine差が0.023あります。これが36層で合成されると「pizza pizza pizza」という結果になります。Flash Attentionのような融合が必要です。

Validation

  • 180+件のテスト、9つのテストファイル、カバレッジ95%+
  • 失敗が文書化された16件のGPU実験
  • クロスプラットフォーム:NVIDIA RTX 4090 + AMD Radeon 890M
  • エンドツーエンド:PyPIから、標準のvllm/vllm-openai:latestコンテナにインストール

What's Next

  • vLLMへの上流貢献(issue #38171、49のアップボート)
  • 融合Tritonカーネルに対するフルのFlash Attention融合
  • VL-Cacheスタイルのトークン削減と積み重ねて、乗算的なVLM節約を実現

PyPI | Docs | GitHub

広告