見出し画像

Gemma 4 QAT 徹底解説 ── 同じ賢さのままメモリ3分の1、ローカルAIの新常識

zephel01

2026年6月5日、GoogleがGemma 4ファミリーに**QAT（Quantization-Aware Training＝量子化を意識した学習）**を適用したチェックポイントを一斉公開しました。ざっくり言えば「ほぼ同じ賢さのまま、メモリを約3分の1に圧縮したモデルを、無料で配り始めた」という話です。

ローカルでLLMを動かしている人にとって、これは地味に見えて相当大きな一歩です。これまで「VRAMが足りなくて諦めていたサイズ」が、急に手元のGPUやノートPCの射程に入ってくる。この記事では、何が変わったのか、なぜ品質が落ちにくいのか、そして実際に自分の環境でどう試すのかまでを、できるだけ実務目線で整理します。

この記事は公式ブログ・公式ドキュメントで確認できた事実をベースにまとめています。数値はツールや環境で変動するため、最終的にはご自身の環境での実測をおすすめします。

1. 何がリリースされたのか

Gemma 4はもともと2か月ほど前に登場し、その後も継続的に拡張されてきました。直近では推論を高速化するMulti-Token Prediction（MTP）が導入され、つい数日前（6月3日）にはE4Bと26B MoEの間を埋める12Bの統合マルチモーダルモデルが追加されたばかり。そして今回、その全ラインナップにQAT版が乗りました。

公式（Google DeepMind）のリリース文を要約すると、こうです。

Gemma 4ファミリーの新バージョンを、Quantization-Aware Training（QAT）で最適化。メモリ要件を大幅に削減し、オンデバイス性能を最大化した。

対象は次のモデルとそれぞれの**drafter（投機的デコード用の小型モデル）**です。

  • E2B：実効2B。超モバイル／エッジ／ブラウザ向けの最小クラス。音声入力をネイティブ対応。

  • E4B：実効4B。E2Bの上位。こちらも音声ネイティブ。

  • 12B：6月3日に追加された「encoder-free な統合マルチモーダル」モデル（E4Bと26B MoEの中間を埋める枠）。

  • 26B A4B：MoE（総パラメータ26B／推論時の活性は約4B）。高スループット・高度な推論向け。

  • 31B：Dense（密）大規模モデル。サーバー級の性能とローカル実行の橋渡し。

配布フォーマットは、Q4_0版（llama.cpp向けGGUF、vLLM向けcompressed tensors）と、モバイル特化フォーマット、さらに各自で変換・量子化できるunquantized版。Hugging Faceから今すぐ落とせます。

ちなみに「E」は effective（実効）パラメータの意味で、E2B/E4Bは**Per-Layer Embeddings（PLE）**という仕組みで効率化されています。埋め込みテーブルが大きいため、ロード時の実メモリは実効パラメータ数の印象より少し大きくなる、という点だけ頭の隅に置いておくと数値のズレに戸惑いません。

2. QATとは？ PTQとの根本的な違い

量子化は、モデルの重みを16bitから4bitなどに落として、メモリ使用量を削り、デコード速度も上げる基本技術です。ただしやり方で品質の落ち方が変わります。

**PTQ（Post-Training Quantization）**は、学習が終わったモデルの重みを後から丸めるだけ。手軽ですが、低精度化のしわ寄せがそのまま出やすく、特に推論（reasoning）や長文脈で品質が落ちることがあります。

**QAT（Quantization-Aware Training）**は、学習の最中に量子化の影響をシミュレートしながら最適化します。「最終的に4bitに丸められる」ことをモデルが“知った上で”重みを調整するので、圧縮後の劣化を最小化できる。Googлеは今回、「PTQも十分有効だが、QATはPTQベースラインよりさらに高い総合品質が得られた」と説明しています。

参考までに、前世代のGemma 3 QATでは、llama.cppでのPerplexity劣化を約54%低減し、BF16に極めて近い品質を保ちつつ3倍規模のメモリ削減を達成した、という実績が公表されていました。Gemma 4でも同じ方向の効果が、より洗練された形で効いているという位置づけです。

3. メモリ使用量の改善（公式の目安）

ここが一番わかりやすい変化です。Google公式ドキュメントに載っている、各モデルをロードするのに必要なメモリの目安は次のとおり（ツールや環境で変動する点に注意）。

※12Bは追加されたばかりで、上記の公式メモリ表にはまだ載っていません。クラス感としてはQ4_0で概ね7〜9GB前後と見込まれますが、これは概算なので実測で確認してください。
※この数値は静的な重みのロード分のみ。実際にはソフトウェアのオーバーヘッドと、コンテキスト長（KVキャッシュ）に応じたメモリが上乗せされます。長いコンテキストを使うほどVRAMは増えます。
※MoEの26B A4Bは「活性は4Bでも、ルーティングのため26B全体をメモリに載せる」ため、ベースのメモリは4Bモデルではなく密な26Bに近い、という点に注意。

ポイントは、Q4_0でBF16比およそ3分の1になること。たとえば31Bは58.3GB → 17.4GBへ。これで「ハイエンド1枚のGPU + 大容量メインメモリ」のローカル環境なら、31Bクラスや26B MoEが現実的な常用候補に入ってきます。

筆者の環境（RTX 5090・32GB VRAM＋大容量メインメモリ機）を例にすると、31BのQ4_0をオフロード併用で動かしつつ、長コンテキストやマルチモーダルを乗せても破綻しにくい、という感触になります。複数モデルの同時待機や、用途別の使い分けもしやすくなりました。

4. モバイル最適化の中身（エッジ勢向け）

今回の隠れた主役は、E2B/E4Bのために設計されたモバイル特化の量子化スキーマです。標準的な圧縮フォーマットはモバイルプロセッサで効率よく動かしづらいため、エッジハード向けに作り込んでいます。

  • Static Activations（静的アクティベーション）：通常は実行時に「データをどうスケールするか」を都度計算して処理を食う。これを学習時に事前計算しておき、モバイルチップの負荷を下げて応答を速くする。

  • Channel-Wise Quantization（チャネル単位量子化）：圧縮データの構造をモバイルアクセラレータの設計に合わせ、遅い回避策なしでネイティブに計算させる。

  • Targeted 2-Bit Quantization（部分的2bit化）：トークン生成に関わる部分を2bitまで強く圧縮しつつ、中核の推論層は高精度を維持。賢さを落とさずにストレージを節約。

  • Embedding / KVキャッシュ最適化：語彙テーブルと短期記憶（KVキャッシュ）に圧縮を集中させ、アクティブなメモリ使用量を大きく削減。長い対話でもメモリが尽きにくい。

極めつけは、このモバイルフォーマットでGemma 4 E2Bのメモリフットプリントを1GBまで圧縮したこと。音声・画像エンコーダは多くの用途で不要なので、必要なモダリティだけをデプロイすればさらに削れます（PLEなしのText-only E2Bで1GB未満）。スマホやエッジデバイスで“ちゃんと使えるLLM”が、いよいよ現実的なサイズに収まってきました。

なお、コンテキスト長は小型（E2B/E4B）が128K、中型（31B/26B A4B）が256K。長文脈の用途は中型側が担当します。

5. 性能はどこまで保てるのか

「3分の1に縮めて、本当に賢さは残るのか？」という疑問は当然です。現時点で言えることを正直に整理します。

確かなのは、Google自身が「QATはPTQベースラインより高い総合品質」と明言していること。前世代Gemma 3 QATでもBF16に肉薄する評価が出ていたこと。そして今回、推論層の精度を意図的に温存する設計（部分的2bit化）を採っていることです。方向性としては「圧縮しても賢さを残す」ことに全振りした作りになっています。

一方で、トーンダウンして見ておくべき点もあります。コミュニティの初期報告では「reasoning・tool calling・マルチモーダルとも体感の劣化はほぼない」という声が多いものの、複雑な数学や超精密タスクではわずかな劣化が残るケースもあり得ます。Unslothなどのファインチューン文脈で「QATで一部ベンチがむしろ改善した」という報告も見かけますが、数値の出方はタスク依存です。自分の用途のベンチで実測するのが結局いちばん確実、というのは変わりません。

6. エコシステム対応（即戦力）

公式が「today（本日から）」と強調するとおり、主要ツールが最初から対応しています。落としてすぐ試せるのは大きい。

  • llama.cpp：GGUFがそのまま使える（Unsloth/Bartowski版も）

  • Ollama：ライブラリ（`gemma4`）から取得

  • LM Studio：デスクトップGUIで手軽に

  • vLLM：compressed tensorsで大型モデルを効率サービング

  • MLX：Apple Silicon最適化

  • LiteRT-LM / Transformers.js：エッジ／ブラウザ実行

  • Unsloth（+ Hugging Face Transformers）：QATを保ったままファインチューン

さらに、drafterもQAT済みなので**投機的デコード（Speculative Decoding）**で高速化でき、MTP（Multi-Token Prediction）のQATチェックポイントを使えば量子化しつつMTPの高速化も維持できます。「軽くする」と「速くする」を同時に取りにいける構成です。

7. 誰にとっての朗報か

  • VRAMに悩むローカル勢：RTX 30/40/50シリーズやゲーミングノートで、これまで一段上だったサイズが射程に。

  • オンデバイス／モバイル開発者：プライバシー重視アプリ、オフライン・リアルタイム推論が現実的に。

  • エージェント運用派：長文脈＋マルチモーダル＋function callingをローカルで回す構成が組みやすい。

  • コスト・プライバシー重視：クラウド依存を減らしつつ、日本語含む多言語で使える。

筆者のようにローカルファーストでエージェントを組んでいる場合、「Q4_0の31B（または26B MoE）＋長コンテキスト＋マルチモーダル」を一台で回しつつ、CodeRouterやOpenClawのワークフローに組み込む、といった使い方が一気に現実的になります。

8. 実践Tips：まず触ってみる

  1. 入手：Hugging Faceの公式コレクション（`google/gemma-4-qat-q4-0` ／ モバイル版）から取得。

  2. すぐ試す：Ollamaなら `ollama run gemma4`（タグはライブラリで最新の QAT 版を確認）。llama.cppならGGUFを直接ロード。

  3. ベンチを取る：Perplexity、コーディング系（例：LiveCodeBench）、そして自分の日本語タスクで評価。公開ベンチより自分の用途のスコアが効きます。

  4. メモリ計画：コンテキスト長（KVキャッシュ）の上乗せを忘れずに。長文脈を使うなら中型（256K対応）を。

  5. エッジ用途：必要なモダリティだけデプロイ＋Text-onlyモードで徹底的に軽量化。E2Bなら1GB級も狙える。

  6. ファインチューン：Unsloth＋Hugging Face TransformersでQATを保ったまま継続学習。

9. まとめ：競争軸が「大きさ」から「効率」へ

Gemma 4 QATが象徴しているのは、「モデルを大きくする競争」から「効率的に強くする競争」への移行です。ほぼ同じ賢さを保ったまま、必要メモリを3分の1にし、スマホでも1GB級で動かせるところまで持ってくる。これはローカルAIの民主化を確実に一段進めます。

派手な新モデルの発表ではないけれど、ローカルで動かす人間にとっては「今日から手元の機材でできることが増える」タイプの、実利の大きいアップデートです。まずは手持ちのGPUで一つ落として、自分のタスクで殴ってみるのがおすすめです。

参考リンク

#Gemma4 #QAT #量子化 #ローカルLLM #ローカルAI #llamacpp #Ollama #LMStudio #エッジAI #生成AI

いいなと思ったら応援しよう！

zephel01 サーバー代とコーヒー代になります☕ 役に立ったら応援よろしくお願いします！