OllamaでGemma 4をCPU推論：e2bがe4bの2倍速かった理由とthinkingモードの罠
TL;DR
CPU-only環境（Intel i5-8365U）でGemma 4のローカルモデルをテストしたところ、e4bが3.8 tok/s、e2bが8.5 tok/sという結果に（2026-04-12 再実測）。初期測定では e4b が 4.1 tok/s、e2b が 4.6 tok/s だったが、再測定で e2b が大幅に高速であることが判明した。デフォルトではthinkingモードがONになっており、生成トークン数が思考過程に吸収されてしまう罠がある。対策はthink:falseの明示指定と/api/chatエンドポイントの使用。オフライン・プライバシー重視なら常時ロードしてバッチ処理向けに使えるレベル。
テスト環境
- CPU: Intel Core i5-8365U (1.6GHz, 4コア/8スレッド)
- RAM: 30GB
- GPU: なし（CPU-only推論）
- OS: Linux 6.17.0-20-generic
- Ollama: v0.20.2（v0.15.5からアップデート）
モデル情報
| モデル名 | サイズ | 特徴 |
|---|---|---|
| gemma4:e4b | 9.6GB | 高精度版 |
| gemma4:e2b | 7.2GB | 高速版 |
ベンチマーク方法
Ollamaの/api/chatエンドポイントを使用し、think:falseを明示指定（thinkingモードを無効化）。
再実測条件（2026-04-12）
-
プロンプト:
"AIエージェント運用の最大の課題を3つ挙げてください。"（同一プロンプトで両モデル測定） - num_predict: 80
- think: false
- 測定回数: 各モデル3回（Run 1〜3）
- warmup: Run 1 はロード込み、Run 2〜3 はモデル常駐状態
- コマンド:
curl -s http://localhost:11434/api/chat \
-d '{"model":"gemma4:e4b","messages":[{"role":"user","content":"AIエージェント運用の最大の課題を3つ挙げてください。"}],"stream":false,"options":{"num_predict":80},"think":false}'
初回測定条件（2026-04-06）
- プロンプト・num_predict が異なるため、初回測定値は参考値扱い
結果
ロード時間（初回測定・参考値）
- gemma4:e4b: 83.8秒
- gemma4:e2b: 81.7秒
→ ほぼ同じ（CPUボトルネック）
再実測：生成速度（2026-04-12、num_predict=80、think=false）
gemma4:e4b (9.6GB)
| Run | トークン数 | eval_duration | 速度 | 備考 |
|---|---|---|---|---|
| 1 | 80 | 20,973 ms | 3.8 tok/s | ロード込み（load: 927ms） |
| 2 | 80 | 20,324 ms | 3.9 tok/s | モデル常駐 |
| 3 | 80 | 20,837 ms | 3.8 tok/s | モデル常駐 |
| 平均 | 80 | 20,711 ms | 3.8 tok/s | — |
gemma4:e2b (7.2GB)
| Run | トークン数 | eval_duration | 速度 | 備考 |
|---|---|---|---|---|
| 1 | 80 | 8,684 ms | 9.2 tok/s | ロード込み（load: 49,665ms） |
| 2 | 80 | 9,399 ms | 8.5 tok/s | モデル常駐 |
| 3 | 80 | 10,054 ms | 8.0 tok/s | モデル常駐 |
| 平均 | 80 | 9,379 ms | 8.5 tok/s | — |
注記: 初回測定（2026-04-06）では e4b=4.1 tok/s、e2b=4.6 tok/s とほぼ同速度だったが、再実測で e2b が e4b の2倍以上であることが確認された。初回測定は num_predict=50 でトークン数が少なく（17〜19 tok）、測定誤差が大きかった可能性が高い。e2b の Run 1 で load に約50秒かかっているが、これは e4b 測定後にメモリから追い出されたためと推定される。
初回測定値（参考）
| 項目 | gemma4:e4b | gemma4:e2b |
|---|---|---|
| eval_duration | 4.1秒 | 4.1秒 |
| トークン数 | 17トークン | 19トークン |
| 速度 | 4.1 tok/s | 4.6 tok/s |
thinkingモードの罠（重要！）
デフォルトではthink:trueとなり、指定したnum_predictが全部思考過程に消費されてしまう。
問題例：
curl ... -d '{"num_predict":50}' # thinkingに50トークン全部使われ、content=""
対策：
curl ... -d '{"model":"gemma4:e4b","messages":[{"role":"user","content":"..."}],"stream":false,"options":{"num_predict":150},"think":false}'
GPU環境との速度比較（一般的な目安・同一環境比較ではない）
注意: 以下のGPU数値は公開ベンチマーク等の一般的な目安であり、本記事のCPU実測環境との同一条件比較ではありません。モデル・量子化・プロンプト・コンテキスト長によって大きく変動します。
- RTX 3060 (12GB): 約20-30 tok/s の目安
- RTX 4090: 約80-120 tok/s の目安
- GPUがあれば実用的なインタラクティブ利用も可能
CPU-only環境での実用Tips
- 常時ロードしておく - ロードに80秒かかるため、バックグラウンドで起動済みにしておく
- バッチ処理向き - 要約、翻訳、テキスト抽出など、即時レスポンスが不要なタスクに
- プロンプト設計 - 思考過程を活かした設計も可能（例：段階的推論を促す）
-
API選択 -
/api/chat+think:falseを標準に - モデル選択 - e2bは e4b の2倍以上速いため、CPU-onlyなら基本 e2b を推奨。精度重視のタスクのみ e4b を検討
まとめ
CPU-only環境でもGemma 4は動くが、e4bは3.8 tok/s、e2bは8.5 tok/sという結果。e2bならバックグラウンドタスクで実用に耐えるが、e4bでのチャットボット的なリアルタイム利用は厳しい。ただし、オフライン・完全プライベート・無料というメリットは大きい。セキュリティ機密度の高い環境や、ネットワーク不可の場面では十分な選択肢となる。
【追記：OpenClawは動くか？】
なお、このThinkPadのCPU-only環境（e4b/e2b速度）をバックエンドにしてAIエージェント「OpenClaw」を動かしてみたが、思考ステップやツール実行のレイテンシが大きすぎ、タイムアウトが頻発してまともに動作させることはできなかった。エージェントの自律運用には、やはりGPU環境か高速なクラウドAPIの利用が現実的である。
今後の展望
- eGPUや外部アクセラレータでCPU+GPUハイブリッド構成
- 量子化モデル（GGUF形式など）でのさらなる高速化
- 特化タスク向けファインチューニング（要約特化モデルなど）
参考リンク
- Ollama公式: https://ollama.com/
- Gemma 4モデル詳細: https://ollama.com/library/gemma4
- thinkingモード（reasoning model）の仕様: https://github.com/ollama/ollama/blob/main/docs/api.md （
thinkパラメータの項を参照） - 再現用コマンド: 本文「ベンチマーク方法 > 再実測条件」セクションのコマンドをそのまま使用