見出し画像

Google公式QAT vs Unsloth版、どっちのGemma 4 12Bが優秀？ — 自分の環境でガチ検証してみた【第1回】

zephel01

こんにちは、くーるぜろです。

Fahd Mirza氏のYouTube動画「Google QAT vs Unsloth Q4_0 - Which Gemma 4 12B Quantization Is Better?」を見て、これは自分の環境で追試すべきだと思い立ちました。動画ではUnsloth版がほぼ全テストで勝つという結果でしたが、他人のベンチを鵜呑みにしないのがこのnoteの流儀です。

今回は第1回として、両モデルのダウンロードから初回比較まで。実測ログ込みで書きます。

何を比較するのか：同じ7GB級、思想が違う2つの量子化

面白いのは、ほぼ同じファイルサイズなのに量子化の考え方が根本的に違うことです。

Google公式 QAT（gemma-4-12b-it-qat-q4_0.gguf、6.98GB）

QAT = Quantization-Aware Training。学習時から量子化を織り込んで訓練したモデルです。Google公表値では、12BのQ4_0 QATは5-shot MMLUで**67.07%と、BF16フル精度の67.15%**にほぼ並びます。つまり「量子化してもほぼ劣化しない」が売り。

Unsloth版（gemma-4-12B-it-qat-UD-Q4_K_XL.gguf、6.72GB）

GoogleのQAT重みをベースに、UnslothがDynamic 2.0手法でllama.cpp向けに再最適化したもの。Unslothによれば、QATチェックポイントを素直にQ4_0へGGUF変換すると逆に精度が落ちることを発見し、llama.cpp互換フォーマットと真のBF16 QAT重みの一致度を高める動的処理を適用。結果、より小さく、より正確になったと主張しています。

  • KLD（元モデルとの分布のずれ）: 小型変種（E2B）の例で mean KLD 0.00173 vs 0.05109（相対29倍改善）、しかも22%小型化

  • 大型変種では、素朴なQ4_0変換で失われるtop-1精度を8.8〜15.4ポイント回復

なおUnslothは「UD-Q4_K_XLより高精度のGGUFを上げない」方針です。理由が面白くて、これ以上精度を上げるとむしろ劣化するから、とのこと。

主張が本当か、手元で確かめましょう。

ダウンロード

pip install -U huggingface_hub

# Google公式版
hf download google/gemma-4-12B-it-qat-q4_0-gguf \
  gemma-4-12b-it-qat-q4_0.gguf \
  --local-dir ~/llm/models/gemma4-12b-qat-google

# Unsloth版
hf download unsloth/gemma-4-12B-it-qat-GGUF \
  gemma-4-12B-it-qat-UD-Q4_K_XL.gguf \
  --local-dir ~/llm/models/gemma4-12b-qat-unsloth

実測では6.98GBが4分02秒、6.72GBが3分31秒で落ちてきました（28.8〜31.8MB/s）。

検証環境

  • マシン: GMKtec NucBox EVO-X2（AMD Ryzen AI MAX+ 395、ユニファイドメモリ128GB）+ RTX 5090 32GB（外付け接続）

  • 実行デバイス: CUDA0（RTX 5090）に全レイヤーオフロード（`-ngl 99`、起動ログで確認済み）

  • ランタイム: llama.cpp（build b9536-308f61c31、CUDAビルド）

  • 設定: 両モデル完全同一 — `--temp 0.7 --top-p 0.95 --top-k 64`

公平な比較のコツはひとつだけ。温度・top_p・top_k・コンテキスト長を完全に揃えること。ここが揃っていない比較動画は参考になりません。

第1ラウンド：図らずも「指示の崩れ」への対応テストに

最初のプロンプトはSQL最適化のつもりだったんですが、実は仕込みに失敗しまして。

あなたは優秀なプログラマーです。以下のSQLを最適化してください：...

肝心のSQLが「...」のまま。ただ、これが怪我の功名でした。「不完全な指示にどう対応するか」という、実用上かなり重要なテストになったからです。ローカルLLMは壊れた入力で平気でハルシネーションすることがあるので。

結果：両者とも合格。ただし差はある

Google QAT版は、thinkingで「ユーザーはまだSQLを提供していない」と正しく認識し、SQLの提示を依頼。あわせてDB製品・スキーマ・問題点・データ件数の4項目をヒアリングし、SARGability確認やJOIN最適化など、自分が行う分析プロセスを5ステップで提示しました。存在しないSQLをでっち上げて「最適化」を始めなかったのは偉い。

Unsloth版も同様にSQL未提供を認識して提示を依頼。こちらはヒアリングが5項目で、Google版の4項目に加えて「EXPLAIN（実行計画）の結果」を要求してきました。チェックポイントの提示も「Filter earlyの原則」「パフォーマンス・可読性・保守性・スケーラビリティの観点」など一段具体的です。

1プロンプトで断定する気はありませんが、第一印象としてはUnsloth版の方が回答の解像度が少し高い。実務でSQLチューニングをやる人なら、EXPLAINを最初に要求してくる方を信頼するでしょう。

速度（実測）

生成速度はほぼ互角（誤差レベル）ですが、プロンプト処理はUnsloth版が約17%速い。ファイルが260MB小さいことも含め、同じ精度帯なら軽い方が正義です。RTX 5090なら12B Q4は余裕の140 t/s超。VRAM 32GBに対して7GBなので、コンテキストを盛大に積んでもまだ余ります。

現時点の所感と、次回予告

1ラウンド時点のまとめ:

  • どちらも壊れた指示に対して堅牢。12B Q4クラスの実用性は十分

  • 回答の具体性はUnsloth版がわずかにリード（EXPLAIN要求、観点の明示）

  • 速度・サイズもUnsloth版が微優位

  • ただしこの差が量子化品質によるものかは、まだ分からない。temp 0.7なので出力のブレもある

Fahd氏の動画と Unslothの主張（KLD改善）に沿う方向の第一印象ではありますが、断定には全然足りません。次回は本腰を入れて検証します。予定メニュー:

  1. Coding: 実物のSQL最適化（EXPLAIN付き）、Pythonコード生成

  2. Multilingual: 日本語↔英語翻訳の精度（動画にない日本語視点はこのnoteの強みなので）

  3. Visualization: matplotlib/plotlyのコード生成と実行可否

  4. 同一プロンプト×複数回で出力のブレを均す（temp 0固定の決定論比較も）

「このプロンプトで比較してほしい」というリクエストがあればコメントへ。LM StudioやOllama（ModelfileのFROMにGGUFパスを指定すればOK）で追試した結果の報告も歓迎です。

主な出典

ハッシュタグ: #ローカルLLM #Gemma4 #量子化 #Unsloth #llamacpp

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

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