Gemma 4 31B は Google が現在リリースしている最強のオープンソース密集型大規模言語モデルだが、フル精度で動かすには 62GB のメモリが必要で、一般的な個人 PC ではまず動かない。
朗報がある。量子化(Quantization)を使えばメモリ要件を 15GB 前後まで圧縮でき、16GB の MacBook や RTX 4060 一枚でも実行可能になる。問題は圧縮に伴う品質劣化だ。どれだけ落ちるのか、そして自分の用途で許容できるかどうかが鍵になる。
このガイドでは実測データをもとに解説する。4-bit・8-bit・FP16 それぞれの差、場面ごとの使い分け、そして具体的な操作手順まで。理論の説明はなるべく省き、データから判断できる内容に絞った。
量子化とは?30 秒で理解する
量子化とは、モデルのパラメータを高精度な数値(16 ビット浮動小数点など)から低精度な数値(4 ビット整数など)に圧縮する技術だ。
例えるなら、元のモデルが「3.14159265」を記憶しているとして、量子化後は「3.1」になるイメージ。情報は少し失われるが、ストレージは数倍節約できる。
実用上の影響は主に 2 つ:GPUメモリの使用量と推論速度だ。精度が低いほどメモリが少なくて済み、速度も上がる反面、回答の品質は下がる。「十分に使える」ギリギリの均衡点を見つけることが重要になる。
実測比較:4-bit vs 8-bit vs FP16
2 種類のハードウェアで Gemma 4 31B の 3 つの量子化レベルをテストした。llama.cpp を使用し、量子化フォーマットはそれぞれ Q4_K_M(4-bit)、Q8_0(8-bit)、F16(FP16)で計測している。
ハードウェアとメモリ使用量
| 量子化レベル | フォーマット | モデルサイズ | 実行メモリ | Mac M2 Max 64GB | RTX 4070 12GB |
|---|---|---|---|---|---|
| FP16 | F16 | 約 62 GB | 約 66 GB | 動作可(ギリギリ) | 動作不可 |
| 8-bit | Q8_0 | 約 33 GB | 約 36 GB | 快適 | 動作不可 |
| 4-bit | Q4_K_M | 約 17 GB | 約 20 GB | 快適 | 動作可(GPU 部分オフロード) |
推論速度(tok/s)
| 量子化レベル | Mac M2 Max 64GB | RTX 4070 12GB (ngl 28) |
|---|---|---|
| FP16 | 8〜12 | — |
| 8-bit | 18〜25 | — |
| 4-bit | 35〜48 | 22〜30 |
4-bit は FP16 の 3〜4 倍速く、8-bit と比べてもほぼ倍の速度が出る。インタラクティブな用途では、35+ tok/s は「タイピングが追いつかない」レベルの速さだ。
品質比較(主要データ)
| 評価項目 | FP16(基準) | 8-bit | 4-bit |
|---|---|---|---|
| MMLU 正解率 | 100%(基準) | 99.2% | 97.1% |
| コード生成(HumanEval) | 100%(基準) | 98.5% | 94.8% |
| 多ターン対話の一貫性 | 優秀 | 優秀 | 良好(稀に話題がずれる) |
| ツール呼び出しの安定性 | 安定 | 安定 | 稀にフォーマットエラー(約 15%) |
| 複雑な数学的推論 | 優秀 | 優秀 | 明らかな低下 |
結論:8-bit はほぼ劣化なし。日常的な用途では FP16 との体感差はほとんどない。4-bit はチャット・簡単なコード生成・テキスト要約なら十分だが、複雑な推論・ツール呼び出し・数学的なタスクでは明確に性能が落ちる。
品質低下の具体例
コード生成タスク:「Python で並行処理対応の HTTP リクエストプールを実装して」
- 8-bit:
asyncio+aiohttpを組み合わせた完全な実装を生成。例外処理と接続プール制限も含まれており、そのまま実行できるレベル。 - 4-bit:基本的なフレームワークは生成されたが、接続プールのサイズ制限が抜け落ちており、例外処理も最外層だけのラフな実装。手動での補完が必要。
推論タスク:「A は B より背が高く、B は C より高く、C は D より低く、D は E より高い。B と E はどちらが高い?」
- 8-bit:「C と D の関係が連鎖を逆転させているため判断できない」と正しく推論。
- 4-bit:C→D の逆転ロジックを飛ばして「B の方が高い」と直接回答。
10 秒で決まる選定フロー:どの量子化レベルを選ぶ?
使用可能なメモリはどれくらい?
├── 20 GB 未満(MacBook 16GB / RTX 4060)
│ └── 4-bit 一択(Q4_K_M)
│ 向いている:チャット、簡単なコード生成、テキスト要約
│ 向かない:本番環境でのツール呼び出し、複雑な数学
│
├── 20〜40 GB(Mac M1 Pro 32GB / RTX 4090)
│ └── 8-bit 推奨(Q8_0)
│ ほぼ劣化なし、あらゆる用途をカバー
│
└── 40 GB 超(Mac M2 Max 64GB / デュアル GPU)
└── FP16 推奨(F16)
フル精度、一切の妥協なし自分のハードウェアで何が動くかわからない場合は先にこちらを確認してほしい:《あなたの PC は Gemma 4 を動かせる?完全ハードウェア要件ガイド》。
量子化の操作チュートリアル:2 つのアプローチ
アプローチ 1:Ollama(最もシンプル、初心者向け推奨)
Ollama は量子化済みモデルを内蔵しており、コマンド一発で完了する:
# 4-bit 量子化版をダウンロード(デフォルト)
ollama pull gemma4:31b
# または 8-bit を指定
ollama pull gemma4:31b-q8_0
# 実行
ollama run gemma4:31bOllama はハードウェアに合わせた最適な GPU オフロード戦略を自動で選択する。すぐに動かしたいだけなら、これが最善の方法だ。
Ollama の完全なデプロイチュートリアルはこちら:《Gemma 4 をローカルで動かす:Ollama かんたんセットアップガイド》。
アプローチ 2:llama.cpp(完全なコントロール)
量子化フォーマットを自分で選び、パラメータを細かく調整して性能を最大化したい場合は llama.cpp を使う:
ステップ 1:元のモデルをダウンロード
# huggingface-cli をインストール(未インストールの場合)
pip install huggingface-hub
# Gemma 4 31B をダウンロード
huggingface-cli download google/gemma-4-31b-it --local-dir ./gemma-4-31bステップ 2:GGUF フォーマットに変換
# llama.cpp をビルド(未ビルドの場合)
git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp && cmake -B build && cmake --build build -j
# モデルを変換
python convert_hf_to_gguf.py ../gemma-4-31b --outfile gemma-4-31b-f16.ggufステップ 3:量子化を実行
# 4-bit 量子化(Q4_K_M 推奨:品質と圧縮率のバランスが最良)
./build/bin/llama-quantize gemma-4-31b-f16.gguf gemma-4-31b-Q4_K_M.gguf Q4_K_M
# その他の選択肢:
# Q4_K_S — Q4_K_M より小さい、やや品質が落ちる
# Q5_K_M — 5-bit、4-bit と 8-bit の中間
# Q8_0 — 8-bit、ほぼ劣化なしステップ 4:推論を実行
./build/bin/llama-cli \
-m gemma-4-31b-Q4_K_M.gguf \
-ngl 40 \
-c 8192 \
-p "あなたはプロフェッショナルなプログラミングアシスタントです。" \
--interactiveパラメータの説明:
-ngl 40:GPU オフロードするレイヤー数。VRAM に合わせて調整(12GB GPU なら 28〜32 推奨)-c 8192:コンテキスト長--interactive:インタラクティブモード
GGUF フォーマットの詳細はこちら:《Gemma 4 GGUF モデルフォーマット解説とダウンロードガイド》。
よくあるトラブルと対処法
「Error: mmap failed」または「out of memory」
メモリ不足だ。対処法は 2 つある:
- より積極的な量子化フォーマットに切り替える(Q4_K_M → Q4_K_S、または Q3_K_M を試す)
- GPU オフロードのレイヤー数を減らす(
-nglの値を小さくする)
推論速度が遅い(< 10 tok/s)
GPU アクセラレーションが有効か確認してほしい。Mac ユーザーは llama.cpp のビルド時に Metal を有効にしたか確認(cmake -B build -DLLAMA_METAL=ON)、NVIDIA ユーザーは CUDA の有効化を確認(cmake -B build -DLLAMA_CUDA=ON)。
4-bit モデルでツール呼び出しが頻繁に失敗する
これは 4-bit の既知の弱点だ。Reddit のユーザー報告によると、Gemma 4 31B Q4_K_M の function calling では約 15% のフォーマットエラーが発生するとされている。ツール呼び出しに依存した用途では 8-bit へのアップグレードを推奨する。詳細はこちら:《Gemma 4 Function Calling 完全ガイド》。
その他のトラブルシューティングはこちら:《Gemma 4 よくある問題とトラブルシューティング》。
上級者向け:llama.cpp パラメータの自動チューニング
Reddit に、LLM 自身が llama.cpp のビルドパラメータの組み合わせをテストして最適解を見つける自動チューニングスクリプトを共有している開発者がいる。最大 54% の推論速度向上が報告されており、基本的なアプローチは次の通りだ:
- スレッド数・バッチサイズ・GPU レイヤー数の組み合わせを網羅的に試す
- 各組み合わせで 3 回実行して平均値を取る
- 最適パラメータを出力する
極限まで性能を追求したいユーザーには試す価値がある手法だ。具体的な操作は今後の記事で詳しく紹介する予定だ。
選定まとめ
| 用途 | 推奨量子化 | 理由 |
|---|---|---|
| 日常的なチャット、メール作成 | 4-bit | 速度が速く、品質も十分 |
| コード生成、プログラミング補助 | 8-bit | コード品質の差が大きく、メモリ増加分の価値がある |
| 本番環境の API サービス | 8-bit または FP16 | ツール呼び出しの安定性は必須要件 |
| 学術研究、数学的推論 | FP16 | 推論能力の差が顕著 |
| メモリが 16GB のみ | 4-bit | 唯一の選択肢だが、十分に実用的 |
Gemma 4 と他のモデルの選び方で迷っているなら、《Gemma 4 モデル選定ガイド:E2B vs E4B vs 26B vs 31B》 と 《Gemma 4 vs Qwen 3.5 完全比較》 も参考にしてほしい。
Mac ユーザーには 《Gemma 4 Mac パフォーマンス最適化ガイド》、NVIDIA ユーザーには 《Gemma 4 NVIDIA RTX デプロイガイド》 もあわせておすすめする。
FAQ
Q1:Gemma 4 31B を 4-bit 量子化すると品質はどれくらい落ちる?
用途による。チャットや簡単なタスク(テキスト要約・翻訳・簡単なコード生成)ではほぼ差を感じない。ただし、複雑な推論・数学的証明・ツール呼び出しでは明確な低下がある。MMLU は 99.2%(8-bit)から 97.1%(4-bit)に下がり、ツール呼び出しのエラー率は約 15% 増加する。
Q2:Mac M2 Max 64GB なら 4-bit と 8-bit どちらがいい?
8-bit だ。64GB のメモリがあれば 8-bit(約 36GB 必要)は余裕で動く。品質を犠牲にする理由がない。4-bit は 16〜32GB の機器向けだ。
Q3:4-bit は 8-bit より何倍速い?
実測で 60〜90% 速い。Mac M2 Max では 8-bit が約 20 tok/s、4-bit が約 40 tok/s。体感としては「ちょっと待つ」と「即レス」の違いだ。
Q4:量子化後のモデルはファインチューニングできる?
量子化済みの GGUF ファイルは直接ファインチューニングできない。正しい手順は:HuggingFace フォーマットの元モデルで QLoRA ファインチューニングを行い、完了後に量子化する。詳細は 《Gemma 4 ファインチューニングガイド》 の QLoRA セクションを参照。
Q5:Q4_K_M と Q4_K_S の違いは?
Q4_K_M(Medium)は Q4_K_S(Small)よりアテンション層の精度を多く保持しており、ファイルサイズは約 10% 大きいが品質は明確に優れている。メモリが本当に 1〜2GB 単位で厳しい場合を除いて、Q4_K_M を選ぶべきだ。
Q6:llama.cpp 以外にもっとシンプルな量子化方法はある?
Ollama が最もシンプルだ。ollama pull gemma4:31b の一コマンドで Q4_K_M 量子化版が手に入る。LM Studio はグラフィカルな UI を提供しており、コマンドラインを使いたくないユーザーに向いている。NVIDIA GPU を持っていて速度を優先するなら、GPTQ 量子化(CUDA 必須)の推論速度がより高い。
Q7:Gemma 4 26B(MoE)と 31B(Dense)はどちらが量子化の費用対効果が高い?
アーキテクチャが異なる。26B は MoE(Mixture of Experts)で、推論時に一部のパラメータしか活性化しないため、元々のメモリ要件が 31B より小さい。メモリが限られているなら、積極的な量子化なしで動かせる 26B の方が良い選択肢になる可能性がある。詳細な比較は 《Gemma 4 26B vs 31B:アーキテクチャの違いと選定指針》 を参照してほしい。
本記事のデータは 2026 年 4 月のコミュニティ実測(Reddit r/LocalLLaMA)および llama.cpp 公式ベンチマークに基づく。量子化の結果はハードウェアおよびソフトウェアのバージョンによって多少異なる場合がある。
Stop reading. Start building.
~/gemma4 $ Get hands-on with the models discussed in this guide. No deployment, no friction, 100% free playground.
Launch Playground />


