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 パラメータの項を参照）
再現用コマンド: 本文「ベンチマーク方法 > 再実測条件」セクションのコマンドをそのまま使用