待っていたゾ🤗「ちょうどいい」ローカルLLM Gemma 4 12B QATを整理してみる

AI LLM コンピュータ

ローカルLLM環境をいろいろ触っていると、必ずぶつかるのがVRAMの壁なんですよね。12Bクラスのモデルをbf16のまま動かそうとすると、重みだけで約24GBのメモリが必要になり、手元のGPUでは厳しい…という場面が多いのではないでしょうか。自分のデスクトップPCはRTX 4070 Ti(VRAM 12GB)なのですが、bf16の12BはそもそもVRAMに載りません😅

そこで気になっていたのが、Google DeepMindが公開しているGemma 4 12Bの軽量版「QAT(Quantization-Aware Training：量子化適応トレーニング)」です。今回は、この軽量版がどういうものなのか、なぜ「ただの量子化」と違うのか、公式版とサードパーティ版のどちらを使えばいいのかを整理して、最終的にOllamaで実際に動かしてみようと思います。

⚠️本記事の情報は2026-06時点のものです。

1. Gemma 4 12B Unified(ユニファイド＝統合版)ってどんなモデル？

まず、ベースとなるモデルの概要から整理します。

Gemma 4 12B Unifiedは、Google DeepMindが公開した約12B(119.5億)パラメータのマルチモーダルモデルです。名前にあるUnified(ユニファイド＝統合版)は、「テキスト・画像・音声の処理を1つのモデルに統合した」ことを表しています。後で出てくる「エンコーダ不要」のアーキテクチャを指すものになります。

Gemma 4ファミリー自体は2026年3月末に公開され、12Bモデルは2026年6月3日に追加されたばかりの新しいモデルです。そして、そのわずか2日後の6月5日にQAT版のチェックポイントがリリースされました。つまり本記事執筆時点でかなりホットな話題なんですよね。

  • 構成　…　48層のデコーダ型トランスフォーマー
  • 対応モダリティ　…　テキスト・画像・音声の3つ
  • コンテキスト長　…　 最大256Kトークン
  • 語彙サイズ　…　262K
  • ライセンス　…　Apache 2.0
  • 公開時期　…　2026年6月3日(QAT版は6月5日)

「エンコーダ不要」とはどういうこと？

先ほどの「エンコーダ不要」という言葉を補足します。専門用語が続きますが、仕組み自体はシンプルなので順を追って説明します。

ご存知のようにLLMは、文章を「トークン」という小さな単位に区切って処理しています。つまりLLM本体が読めるのは、基本的にテキスト(を変換したトークン)だけなんですよね。では、画像や音声をどうやって読ませるのか？ ここがマルチモーダルモデルの工夫の点になります。

従来のやり方は、画像や音声を「LLMが読める形」に変換する専用の変換係を別途準備する方法でした。この変換係をエンコーダと呼びます。画像用、音声用とそれぞれ専門のエンコーダがあり、入力をいったん変換してからLLM本体(デコーダ)に渡すことになります。例えるなら、外国語の文書を専属の翻訳者に訳してもらってから本体が読む、という分業体制です。

12B Unifiedでは、この翻訳者を置きません。代わりに、画像なら48×48画素の小さなタイル状に切り分け、音声ならそのままの波形データを、ごく簡単な変換だけでトークンと同じ形に整えて、直接LLM本体に流し込みます。本格的な翻訳をせず、最低限の下ごしらえだけして本体に丸ごと読ませてしまう、というイメージです。テキストも画像も音声も、すべて同じ1つのモデルが処理します。

この構造を整理すると以下のようになります。

長所

  • 学習(追加トレーニング)がやりやすい　…　変換係とLLM本体が別々だと、「どちらをどう調整するか」という面倒な問題が出てきます。1つのモデルにまとまっていれば、全体をそのまま一括で調整できます
  • パラメータをムダなく使える　…　変換係に割いていた容量が不要になる分、同じモデルサイズでも本体に性能を集中できます

短所

  • 学習データが余計に必要　…　専用エンコーダは「画像とはこういうものだ」という処理の得意技をあらかじめ持っていますが、エンコーダ不要型はすべてをゼロから学ぶ必要があります。そのため、同じレベルの画像理解性能に到達するには、より多くの学習データが必要になる傾向があるようです。

「分業をやめて一人で全部読む」方式は構造としてはすっきりしているのですが、その一人を育てる手間は余計にかかるということかもしれません。

2. 「あとから圧縮」・「圧縮前提で育てる」

量子化の基本

量子化(Quantization)は、モデルの重みやアクティベーションを低ビットで表現し、メモリ使用量や演算量を削減する技術です。ローカルLLM界隈でおなじみのGGUF形式の「Q4_0」「Q4_1」といった表記も量子化方式の名前です。

  • Q4_0　…　ブロックごとにスケール値のみを保存する対称量子化(ゼロ点なし)
  • Q4_1　…　スケールに加えてオフセット(ゼロ点)も保存する非対称量子化

「あとから圧縮」の限界と「圧縮前提で育てる」発想

学習が終わったモデルに、後処理として量子化をかける方法をPTQ(Post-Training Quantization)と呼びます。いわば「あとから圧縮」方式ですね。手軽な反面、4ビットや2ビットといった極端な低ビット化では精度劣化が目立ちやすいという弱点があります。これまでOllamaなどで使っている量子化モデルの多くはこのタイプのようです。

これに対してQAT(Quantization-Aware Training)は、訓練の段階から量子化をシミュレートしながら学習する手法です。順伝播時に重みやアクティベーションへ擬似量子化ノード(Fake Quantization)を挿入し、量子化後の誤差を勾配伝播で考慮させます。

つまり、モデル自身が「低ビット表現された状態でも正しく動くように」重みを調整していくわけです。「あとから圧縮」に対して「圧縮されることを前提に育てる」方式、と言ってもいいかもしれません。結果として、16ビットモデルとほぼ同等の性能を維持したまま、大幅な省メモリ化が可能になります。

Googleの発表でも、Gemma 4のQATモデルは高ビット精度モデルとほぼ同等の品質を保ちつつメモリを削減できるとのことでした。

3. どれくらい軽くなるのか

数値にするとQATの効果が見えてきます。

モデル 品質 必要メモリの目安 ファイルサイズ
Gemma 4 12B(bf16・元モデル) ベースライン 24GB超 約24GB
Gemma 4 12B QAT(Q4_0) ほぼ同等 ※ 約8GB〜 約7GB

👉️Googleの説明では、QATは精度低下の抑制を目的としており、ベースラインに非常に近い品質を目指す設計です。なお、具体的なベンチマーク数値の完全な一覧は公開時点では出そろっていないという指摘もあるので、細かい数値は公式モデルカードで確認するのが確実です。

ポイントを整理すると次のようになります。

  • 精度　…　QAT版は元モデルとほぼ同等の品質を保つとGoogleは説明しています。一方で量子化版どうしの比較ではUnslothによる検証(後述)もあり、変換方法によって差が出ます
  • 推論速度　…　読み込むデータ量が減る分、メモリバンド幅がボトルネックになる環境では速度面のメリットも期待できます
  • サイズ　…　Unslothの整理ではQATにより約72%のメモリ削減。12B QATは約7GBのメモリで動作し、小型のE2Bに至ってはモバイル向け形式でbf16版11.4GBが約1GBになっています

つまり、bf16なら24GB必要だったモデルが、8GB台のメモリから動かせるということです。これなら自分のRTX 4070 Ti(12GB)にも余裕をもって載る計算ですし、メインメモリ16GBクラスのノートPCでもCPU動作が現実的なサイズ感になってきます。

4. 公式モデルとサードパーティ版、どちらを使う？

ここが今回いちばん整理しておきたかったポイントです。

まず前提として、Gemma 4のQATモデルはGoogle DeepMindが公式に提供しているものです。Hugging Face上のgoogle/名前空間で配布されており、E2B、E4B、12B、26B A4B、31Bの全サイズにQAT版が用意されています。サードパーティが後から量子化したものではなく、学習段階からQATを適用した正規のチェックポイントなんですよね。

公式の配布形式は次の3つがあります。

  • GGUF形式　…　llama.cpp、Ollama、LM Studio向け
  • 圧縮テンソル形式　…　vLLM向け
  • 非量子化チェックポイント　…　自分でQ4_0対応形式へ変換・量子化するためのベース

⚠️ファインチューニングライブラリで知られるUnslothの開発者Daniel Han氏が、「公式QATチェックポイントを素朴にllama.cpp用のGGUF形式へ変換すると、測定可能な精度低下が起きる」とのことです。記事末尾の参考リンクで確認してみてください。

要するに「公式QATだからどう変換しても安全」というわけではなく、変換のやり方まで含めて品質が決まるということですね。

使い分けの目安を表にまとめるとこんな感じです。

利用シーン おすすめ 理由
vLLMで使う 公式版 Googleが対応フォーマットを直接提供している
業務利用・出どころの明確さ重視 公式版 google/名前空間の正規チェックポイント
自分で変換・追加量子化のベースにする 公式版(非量子化) 変換用のチェックポイントが用意されている
llama.cppやOllamaでGGUFをそのまま使う サードパーティ版も検討 素朴な変換による精度低下を回避できる可能性
同じ4ビットでも精度を稼ぎたい サードパーティ版も検討 Unsloth Dynamicなどの改善報告がある

⚠️サードパーティ版のモデルを使う場合は配布元の信頼性確認も忘れずに。Hugging Faceでは同名モデルの量子化版が乱立しがちなので、ダウンロード数や配布元の実績、変換方法の説明があるかどうかをチェックしてから使うとよいでしょう。

5. GPUなしノートPC・メインメモリの環境でOllamaで動かしてみる

整理はここまでにして、実際に動かしてみたいと思います。

デスクトップのGPUで動くのはある意味当然なので、今回はあえてGPUを積んでいないノートPCで試してみました。QAT版の本領は「ふつうのPCでどこまで動くか」が気になるところです。

GPUがない環境ではモデルはメインメモリに読み込まれ、CPUで推論することになります。 モデル本体が約7GBなので、メインメモリは16GB以上ある機種が現実的なスペックになります。

まずはOllamaでモデルを取得します。執筆時点ではQAT版にqatタグが用意されています。コマンドラインでも問題ありませんが、OllamaもGUI環境で動作するのでそちらを使用して導入するのが簡単かもしれません。

$ ollama pull gemma4:12b-it-qat

ダウンロードが終わったら実行してみます。生成速度を計測したいので--verboseオプションを付けて起動します。（⚠️GUIモードではこの機能はオミットされています）

$ ollama run gemma4:12b-it-qat --verbose

生成中のメモリ使用量も見てみます。

CPU動作では、実用性としてはちょっと難しいかなという印象ではありますが、生成結果に関しては割と満足できるような印象です🙄

せっかくのマルチモーダルモデルなので、画像入力も試してみます。これはGUI環境で行なっています。

以下の画像を認識しどのような画像になっているかを教えてもらいます。

プロンプトは「この画像はどんな画像ですか？」としました。

問題なく認識してくれてますね。画像内のテキストの内容も問題なく認識してくれています。

おわりに

今回はGemma 4 12BのQAT版について、仕組みと「公式版・サードパーティ版どちらを使うか」の観点で整理し、GPUなしのノートPCで実際に動かしてみました。

ポイントを振り返ると、

  • QATは圧縮されることを前提に育てるもので、「あとから圧縮」(PTQ)で起きがちな精度劣化を抑える手法
  • ただし素朴なGGUF変換では精度低下の話もあり。
  • 12B QATなら約7GB・メモリ8GB台から動くサイズ感になり、メインメモリ16GBクラスのノートPCでのCPU動作も視野に入る

ということになります。

ローカルLLMを試す際の最大のハードルだった「メモリの壁」が、QATによって確実に下がってきているのを感じますね🤗

参考

  • Google公式ブログ「Introducing Gemma 4 12B: a unified, encoder-free multimodal model」 blog.google
  • Google公式ブログ「Gemma 4 with quantization-aware training」 blog.google
  • Google AI for Developers「Gemma 4 model card」 ai.google.dev
  • Unsloth Documentation「Gemma 4 QAT」(GGUF変換時の精度検証とDynamic量子化の解説) unsloth.ai