Gemma 4 31BでTurboQuant KV圧縮をテスト — 5.80倍圧縮、完璧な長文脈リコール、JSON出力が保持

Reddit r/LocalLLaMA / 2026/4/7

💬 オピニオンDeveloper Stack & InfrastructureSignals & Early TrendsTools & Practical UsageModels & Research

要点

  • Google ResearchのTurboQuant論文の簡易実装を、Googleが新たに使用しているGemma 4 31Bモデルでテストし、5.80倍のKVキャッシュ圧縮(著者のFP16ベースラインで222トークン換算:37.62MB vs 218.23MB)を達成した。
  • 観測された圧縮率は、TurboQuantの理論上の主張であるturbo3(4.9x)を上回った。著者は、その理由として、論文で用いられた合成データよりもGemma 4のK/V分布の外れ値(アウトライヤー)が少ないためだと考えている。
  • 機能テストでは、完全な圧縮/復元(compress/decompress)によるKVサイクルの後も、「完全」と表現できるマルチターンの長文脈における事実リコールが確認された。中でも、約500トークンのニードル・イン・ヘイスタック検索テストでも、隠されたフレーズがなお返ってきた。
  • 著者は、エージェント的なJSON抽出がKV圧縮後も有効なJSONのままであったと報告しており、TurboQuantのKVキャッシュブリッジを通して構造化出力の能力が保持されていることを示唆している。
  • 実務的なエンジニアリング上の落とし穴も判明した。Gemma 4は層ごとに異なるKVの形状を持つため、層ごとの量子化器インスタンスと、カスタムpast_key_valuesのインターセプト時における実行時の形状検出が必要であり、クラッシュを避けることが求められる。

簡単な実験:Google ResearchのTurboQuant論文(arXiv 2504.19874)をPythonパッケージとして実装し、Googleの最新のGemma 4 31Bモデルでテストしました。その結果は論文の主張を上回りました。

セットアップ:

  • ハードウェア:RTX PRO 6000 Blackwell(96GB VRAM)
  • モデル:google/gemma-4-31B-it(BF16、64レイヤー)
  • 圧縮:TurboQuant turbo3(3-bit PolarQuant + QJL残差)
  • バックエンド:HuggingFace Transformers(custom past_key_values のインターセプト)

圧縮結果:

指標
FP16ベースライン(222トークン) 218.23 MB
TurboQuant圧縮後 37.62 MB
圧縮率 5.80x
論文の理論値(turbo3) 4.9x

5.80xは論文の4.9xという主張を上回っています。おそらく、Gemma 4のアーキテクチャは、論文で使われた合成データよりもK/V分布における外れ値が少ないためです。

機能面の検証:

  1. マルチターンの事実想起(重要なテスト):Gemma 4に「秘密のプロジェクトコードはPHOENIX-42だ」と伝え、次のターン2で「秘密のコードは何?」と尋ねました。KVキャッシュに対してTurboQuantの圧縮/伸長(compress/decompress)を1サイクルまるごと行った後の回答です。回答:「PHOENIX-42」。完璧。
  2. ロングコンテキストの針を探す(わらの中の針)(約500トークン):ダミーの文章の中に「BLUE-DOLPHIN-7」を隠し、それを取り出すよう依頼しました。回答:「上で言及したアクティベーションフレーズはBLUE-DOLPHIN-7です。」このテスト時の圧縮:5.80x。
  3. エージェント的なJSON出力:Gemma 4にエンティティを構造化JSON({people, places, organizations})として抽出するよう依頼しました。これはGemma 4のエージェント的機能の特徴です。KV圧縮の後も、構造化出力は有効なJSONのままでした。ブリッジは、モデルが構造化出力を生成する能力を保持しています。

KV形状の不均一性:

興味深い発見として、Gemma 4はレイヤー間でKVヘッド数が異なる形で注意がインターリーブされています(Gemma 3のローカル/グローバルのパターンに似ています)。最初の実装は一様な形状を前提としていたためクラッシュしました。修正はレイヤーごとの量子化器インスタンスにし、ダミーのforward passで実行時に形状検出を行うようにしました。もし他の人がGemma 4向けに独自のKVキャッシュ処理ロジックを実装するなら、これに注意してください。

仕組み(技術的):

論文では2つのアルゴリズムが指定されています:

  • アルゴリズム1(PolarQuant):ランダム回転 → ベータ分布に従う座標に対するLloyd-Maxのスカラー量子化 → 逆回転。MSE最適。
  • アルゴリズム2(QJL残差):b-1ビットでアルゴリズム1を適用し、その後 sign(S·r) で残差を符号化する。内積は不偏。

K-cacheはアルゴリズム1を使用します(||K - K_hat||² を最小化 → attentionスコア Q·K^T に最適)。V-cacheはアルゴリズム2を使用します(不偏な内積 → attention出力 attn_weights · V に最適)。

ネイティブのturboquant-kvライブラリは計算を扱いますが、インデックスをint64として、符号をfloat32として保存しており、それでは圧縮が打ち消されます。そこで私はその上にビットパッキング層を追加しました:2-bitのインデックス + 1-bitの符号をバイトに詰め、さらにfloat16のnorms/gammasを用意します。これが実際の5.80xの正体です。

ワンラインのセットアップ:

pip install turboagent-ai[torch,native] from turboagent import TurboAgent agent = TurboAgent("google/gemma-4-31B-it") response = agent.run("Your prompt here") 

このパッケージは、バックエンドの選択、ハードウェア検出、KVブリッジの配線、そしてビットパッキングを自動で処理します。

リンク:

MITライセンス。率直なフィードバック歓迎です。特に、他の最近のモデルで試した人がいるか、あるいはビットパッキング方式に関する問題を見つけた人がいるかを知りたいです。

submitted by /u/No_Appearance_3041
[link] [comments]