※この記事はClaude Codeで書いています。評価もClaude Codeが実施しています。

前回の記事でGemma4-E4BをOpenClawのメインモデルとして採用した、と書いたんだけど——

すぐ問題が出た。

コンテキストが足りなくなるんだよね😅

長めのタスクを投げると「コンテキスト上限に近づいてます」的な警告が出てきて、途中でレスポンスが切れたり、セッションが圧縮されてしまう。

E4BはVRAMを9.6GBも使うから、KVキャッシュ（会話履歴を保持するメモリ）に割ける余裕が少ない。 contextTokensを16384（約16K）に制限せざるを得なかったのが原因だった。

「もっとコンテキスト長を伸ばしたい…でもVRAMが足りない…」

というジレンマを解決するために 量子化を落とすという選択をした話です。

E4B vs E2B：量子化の違い

ここで少し技術的な話。

Gemma4には複数の量子化バリアントがある：

量子化（quantization）というのは、モデルの重みを圧縮する技術。 4-bit → 2-bit にすると精度は落ちるが、モデルサイズが約2.4GB削減される。

その削減分をKVキャッシュ（コンテキスト）に回せるのがポイント。

結果として：

• E4B: contextTokens = 16,384（16K）
• E2B: contextTokens = 131,072（131K）

コンテキストが8倍になった。エージェント用途ではこれが大きい。

ベンチマーク結果：E2BはE4Bより速い

量子化を落とすと精度が下がる、という一般論があるけど、 速度はどうかも気になったのでベンチマークを回してみた。

条件は前回と同じく /api/chat + ツール定義 + think: false。

E2Bは 129 tok/s、E4Bは 76 tok/s。

約1.7倍速い。

モデルが軽くなる分、推論が速くなるのは理屈どおりだけど、 ここまで差が出るとは思わなかった（笑）

トレードオフ：精度 vs コンテキスト vs 速度

結果をまとめるとこんな感じ：

E2Bで失点したのは「指示理解」の1問のみ。 具体的には「疑問文の末尾に？をつけてください」という条件を守りきれなかったケース。 コーディングとツール呼び出しは満点。

実用上どちらを選ぶか、というのは用途次第だけど：

• 短いチャット・精度重視 → E4B
• 長文コンテキスト・速度重視のエージェント → E2B

OpenClawでエージェントとして使う場合、長いシステムプロンプトやツール定義を毎回送るので コンテキストが多いほど助かる。今の使い方だとE2Bの方が合っている。

openclaw.jsonの設定

参考まで、現在のE2B設定はこんな感じ：

{
  "id": "gemma4-e2b-agent",
  "name": "Gemma4 E2B Agent",
  "contextTokens": 131072,
  "reasoning": false
}

reasoning: false は前回の記事で解説したthinkingモード対策。 contextTokens: 131072 でKVキャッシュをフル活用する設定。

ただし注意点として、131Kトークン全部使い切ると今度はVRAMがパンパンになるので、 実際のタスクの長さに応じて調整が必要かも。

まとめ

VRAMが12GBしかない環境でも、量子化を工夫することで長いコンテキストと高速推論を両立できた。

精度的にはE4Bを使いたいところだけど、ないメモリは振れないですね 🙂

※この記事はClaude Codeで書いています。評価もClaude Codeが実施しています。

前回、RTX 3060（12GB VRAM）で5つのローカルLLMをベンチマークしてみた記事を書いた。 結果としては coder14b が満点で圧倒的！という内容だったんだけど…

実際にAIエージェント（OpenClaw）として動かしてみたら、全然違う結果になった😅

「あれ？ベンチマークで高得点だったのに、なんでまともに動かないの？」

という沼にはまった話です。

前回のベンチマーク（/api/generate）の結果おさらい

前回は Ollama の /api/generate エンドポイントでシンプルにテキスト生成させてスコアを出した。

この結果を見て「よし、coder14b をメインにしよう！」と思ったんだけど、 実際にエージェントに組み込んだらすぐ問題が出てきた。

問題① thinkingモードで content が空になる

OpenClaw（AIエージェントフレームワーク）は内部で Ollama の /api/chat エンドポイントを使う。 そしてツール定義（function calling の仕様）を一緒に渡す。

ここで Gemma4・Qwen3・Qwen35 が 盛大にこけた。

Ollama のログを見ると：

500 | 59.996s | POST /api/chat

60秒でタイムアウト。毎回。

原因を調べてみると、これらのモデルは「thinkingモード」を持っていて、 ツール定義を受け取ると思考プロセスを <think>...</think> トークンに費やしてしまう。 その結果、実際の content フィールドが 空文字列 になってしまうのだ。

{
  "content": "",
  "thinking": "Let me analyze the tools available..."  // ← これが問題
}

エージェント側は空のレスポンスを受け取って「タイムアウトかな？」と判断 → フェールオーバー。 という流れで、何度やっても落ちていた。

問題② coder14b はネイティブ tool_calls に非対応

一方、coder14b はというと…こちらは別の問題。

ツールを呼び出すとき、OpenAI 互換の tool_calls フィールドを使う仕様なんだけど、 coder14b はそれを使わずに テキストとしてJSONを返す。

// 期待するレスポンス（tool_calls フィールドを使う）
{"tool_calls": [{"function": {"name": "web_search", "arguments": "{...}"}}]}

// coder14b が実際に返すもの
```json
{"name": "web_search", "arguments": {...}}

エージェントが「ツールを呼んだ」と認識できないので、正常に動作しない。

---

## 解決策：`reasoning: false` を設定する

調べてみると、OpenClaw の設定ファイル（openclaw.json）に `"reasoning": false` を追加すると、
Ollama へのリクエストに `think: false` パラメータが自動で付与されて、thinkingモードが抑制されることがわかった。

```json
{
  "models": [
    {
      "provider": "ollama",
      "modelId": "gemma4-e4b-agent",
      "reasoning": false
    }
  ]
}

これを設定してから再テストしたら、Gemma4もQwen系もちゃんと動くようになった🎉

改訂版ベンチマーク（/api/chat + think:false）

今度は実際のエージェント動作に近い条件でテスト。 /api/chat エンドポイント + ツール定義 + think: false を使用。

結果が がらっと変わった。

前回のベンチマーク覇者だった coder14b は、ツール呼び出しで 0/2 という惨敗。 逆に Gemma4・Qwen3・Qwen35・mistral-nemo は全員満点🏆

前回の「Qwen3が低スコア」も、thinkingモードのせいだったということが判明。 あれ、全然 Qwen3 が弱かったわけじゃなかった（笑）

MVPは Gemma4-E4B

速度と精度のバランスを考えると Gemma4-E4B が最強という結論になった。

• 全テスト満点（9/9）
• 速度は 63 tok/s でトップクラス
• RTX 3060 12GB に収まる（~9.6GB VRAM）

Qwen3.5 も満点で 48 tok/s と速く、サブモデルとして優秀。

というわけで、OpenClaw のメインモデルを gemma4-e4b-agent に切り替えた。

教訓：「ベンチマーク環境 ≠ 実際の使用環境」

今回の一番の学びはこれだった。

/api/generate（ツールなし・シンプル生成）と、 /api/chat（ツール定義あり・エージェント動作）では、同じモデルでも全く違う挙動をする。

特に thinking モード搭載モデルは、ツールと組み合わせると無音になるという罠がある。 これ、知らなかったら永遠に「なんか不安定だな〜」で終わってた気がする。

ローカルLLMをエージェントとして使いたい人は、必ずエージェント条件でテストしてね！

まとめ

自宅 GPU でローカル LLM を動かすの、なかなか沼ですが楽しいです😄 同じ環境で試してみたい人の参考になれば！