Gemma 4が遅い？Mac・Windows・Linux別の速度改善ガイド

Gemma 4をダウンロードして実行したら...ものすごく遅い。2トークン/秒くらい。もっとひどいかも。モデルのせいにする前に、実際に何が問題なのか調べましょう — ほとんどの場合、いくつかの設定調整で速度が5〜10倍になります。

ステップ1: なぜ遅いのか診断する

Gemma 4が遅くなる一般的な理由は5つ。それぞれ確認しましょう。

原因1: CPUフォールバック

速度低下の最大の原因。モデルがGPUではなくCPUで動いていて、気づいていない可能性があります。

確認方法：

# Mac: アクティビティモニタ → GPU履歴（ウインドウメニュー）
# またはMetalが使われているか確認：
sudo powermetrics --samplers gpu_power -n 1

# NVIDIA: GPU使用率が0%以上であるべき
nvidia-smi

# AMD: 同様の確認
rocm-smi

推論中にGPU使用率が0%のままなら、CPUで動いています。まずこれを修正 — GPUアクセラレーションが動くまで他の最適化は無意味です。

原因2: 量子化の選択ミス

すべての量子化で速度が同じわけではありません：

量子化	ファイルサイズ（12B）	速度	品質	最適な用途
Q4_K_M	約7 GB	最速	良好	日常使い、ほとんどのタスク
Q5_K_M	約8.5 GB	高速	より良い	品質が重要な場合
Q6_K	約10 GB	中速	非常に良好	バランス型
Q8_0	約13 GB	低速	ほぼオリジナル	品質最優先のタスク
FP16	約24 GB	最低速	オリジナル	VRAMが十分にある場合のみ
IQ4_XS	約6 GB	最速	許容範囲	VRAMが厳しい場合

Q8やFP16で動かして「なぜ遅い？」と思っているなら、Q4_K_Mに切り替えましょう。ほとんどのタスクで品質差はわずかですが、速度差は劇的です。GGUFガイドに各量子化レベルの詳細ベンチマークがあります。

原因3: コンテキスト長が長すぎる

Gemma 4は最大256Kコンテキストをサポートしますが、コンテキストが長い = 推論が遅い。関係は線形ではなく、長くなるほど悪化：

コンテキスト長	相対速度	VRAM使用量（12B Q4）
2K	1.0x（基準）	約7 GB
8K	約0.9x	約8 GB
32K	約0.7x	約12 GB
128K	約0.4x	約20 GB
256K	約0.25x	約30 GB+

修正： タスクに合った適切なコンテキスト長を設定：

# Ollama: コンテキスト制限
ollama run gemma4:12b --ctx-size 8192

# llama.cpp
./llama-server -m model.gguf -c 8192

# 本当に必要でない限り256Kは使わない

原因4: KVキャッシュの肥大化

KV（キー・バリュー）キャッシュはアテンション情報を保存し、会話が長くなるにつれて増大。長い会話はVRAMを消費し、速度を低下させます。

修正： 定期的に新しい会話を始めるか、キャッシュ制限を設定：

# llama.cpp: KVキャッシュを制限
./llama-server -m model.gguf -c 8192 --cache-type-k q8_0 --cache-type-v q8_0

# 量子化KVキャッシュは品質低下わずかでVRAMを節約

原因5: バッチサイズの問題

複数リクエストを処理している場合、バッチサイズが不適切だとスループットが低下：

# vLLM: バッチサイズ調整
python -m vllm.entrypoints.openai.api_server \
  --model google/gemma-4-12b-it \
  --max-num-batched-tokens 4096 \
  --max-num-seqs 8

プラットフォーム別の修正

Mac（Apple Silicon）

MacのパフォーマンスはMetal GPUアクセラレーションが正しく動作するかに完全に依存：

# Metalサポートを確認
system_profiler SPDisplaysDataType | grep Metal

# OllamaはApple Siliconで自動的にMetalを使用
# それでも遅い場合、ユニファイドメモリの圧力を確認：
memory_pressure

# llama.cppの場合、Metalが有効か確認
cmake -B build -DGGML_METAL=ON
cmake --build build

# M1/M2/M3推奨設定
./llama-server -m model.gguf -ngl 999 -c 8192

Macモデル	ユニファイドメモリ	12B Q4速度	備考
M1 8GB	8GB	約12 tok/s	使えるがきつい
M1 Pro 16GB	16GB	約18 tok/s	快適
M2 Pro 16GB	16GB	約22 tok/s	日常使いに良好
M3 Pro 18GB	18GB	約25 tok/s	スイートスポット
M3 Max 36GB	36GB	約30 tok/s	27B Q4も動作
M4 Max 48GB	48GB	約35 tok/s	すべて動く

Mac固有のコツ： 大型モデル実行前にメモリ消費の多いアプリ（Chrome、Docker）を閉じましょう。Apple SiliconはCPUとGPUでメモリを共有するため、別のVRAMプールはありません。

Windows（NVIDIA CUDA）

# CUDAが実際に使われているか確認
# Ollamaで確認：
ollama ps

# Windows固有の問題：電源設定
# Windowsの電源オプションで「高パフォーマンス」に設定
# ノートPCのGPUは「バランス」で積極的にスロットリング

# llama.cpp on Windows:
cmake -B build -DGGML_CUDA=ON
cmake --build build --config Release

Windows固有のコツ： モデルディレクトリに対してWindows Defenderのリアルタイムスキャンを無効化。すべてのファイル読み込みをスキャンするため、パフォーマンスが低下：

# PowerShell（管理者）
Add-MpPreference -ExclusionPath "C:\Users\you\models"

Linux（NVIDIAまたはAMD）

# NVIDIA: パーシステンスモードを有効に
sudo nvidia-smi -pm 1

# GPUを最大パフォーマンスに設定
sudo nvidia-smi -ac 1215,1410  # 値はGPUにより異なる

# AMD: ROCmがアクティブか確認
rocm-smi

# 両方共通: Waylandコンポジタを使っていないか確認
# X11はコンピュートタスクのGPUオーバーヘッドが少ない

クイック速度チェックリスト

速度を最大化するためのチェックリスト：

1. [ ] GPUアクセラレーションが動作している（CPUフォールバックでない）
2. [ ] Q4_K_M量子化を使用（品質最優先でない限り）
3. [ ] コンテキスト長を必要な分だけに設定（256Kデフォルトではなく）
4. [ ] KVキャッシュを量子化（--cache-type-k q8_0）
5. [ ] Flash Attentionを有効化（利用可能な場合）
6. [ ] メモリ消費の多いバックグラウンドアプリなし
7. [ ] 電源設定を「ハイパフォーマンス」に（ノートPC）
8. [ ] 最新ドライバーをインストール済み