日別アーカイブ: 2026年4月12日

コンピュータ

OpenClawでOpenRouter経由のfreeモデルを使ってみる

1件のコメント

※この記事はOpenClaw + Gemma4 e2bで書いています。ちょっと怪しい部分もあえて残しています。まぁ、このレベルは書けるということで。

LiteLLMとFreeモデル：OpenClawでの効率的なLLM利用術

LiteLLMを導入し、OpenRouter経由で利用可能なFreeモデルをOpenClawで賢く使おうと考えた際、実運用で直面した課題と、その解決策についてまとめます。

導入の背景と課題

LiteLLMを使ってFreeモデル（OpenRouter経由）を導入することで、コストを抑えつつ多様なモデルを試したいと考えました。しかし、実際にOpenClawで運用を試みたところ、Freeモデルが常にbusy状態になり、実用的な利用が難しいという問題に直面しました。

解決策：モデルの選択と切り替え戦略

この問題を解決するために、モデルごとに最適な動作環境を定義するというアプローチを取りました。

1. モデルごとの設定定義

LiteLLMの設定ファイル（/home/ubuntu/litellm/config.yaml）を用いて、利用するモデルに応じてバックアップモデルを設定しました。

モデル名 LiteLLMパラメータ 備考
fast model: openrouter/google/gemma-4-26b-a4b-it:free OpenRouterのFreeモデルを試す
fast-local model: ollama/gemma4-e2b-agent, api_base: http://localhost:11434 ローカルのOllamaモデルに切り替えるフェールオーバー先
smart model: openrouter/qwen/qwen3-coder:free Qwenモデルを試す
smart-mid model: openrouter/nvidia/nemotron-3-super-120b-a12b:free より高性能なモデルを試す
smart-local model: ollama/gemma4-e2b-agent, api_base: http://localhost:11434 ローカルのOllamaモデルに切り替えるフェールオーバー先
local model: ollama/gemma4-e2b-agent, api_base: http://localhost:11434 Ollamaのみを使用する

2. フェールバックの仕組み

モデル選択の際に、もしOpenRouter経由のFreeモデルが利用できない場合や動作が不安定な場合に備えて、ローカルで動作するOllamaモデルへ自動的に切り替えるフェールバックの仕組みを導入しました。

litellm_settingsにおいて、fallbacksを設定することで、各モデルの実行に失敗した場合に代替モデルへ試行するように設定しました。

実運用上の考察

この戦略により、OpenRouterのFreeモデルの不安定さや利用制限を回避しつつ、ローカル環境で動作するGemmaモデルを利用する選択肢を確保できました。

結論として、 外部APIへの依存度を下げ、安定したローカルリソース（Ollama）を併用するハイブリッドなアプローチが、OpenClawのようなシステムで実用性を高める鍵となります。

これで、LiteLLMとFreeモデルに関する疑問にお答えできたかと思います。

人間のコメント(笑)

こんな感じでGemma4 e2bでもそれなりの文章は書けますが、微妙なニュアンスは伝わりにくいですね。この記事で書きたかったのはGemmma4 e2bだとやっぱり、コードを書いたりさせるとヨワヨワなので。そうはいっても課金モデルをOpenClawに使うのもなぁ。。。と思い、OpenRouterで無料で使えるモデルを寄せ集めて知能をブーストできないかと考えたのですが。。。甘かった。freeで出てるモデルは想像以上で利用制限がかかってて全然使わせてくれない。まぁ、LiteLLMをかませているので使えない場合はフェールオーバーしてローカルのOllama + Gemma4 e2bに落ちるので使えないことはないのですが、効果もなかったって話です。。。

コンピュータ

Gemma4-E4Bだとコンテクストメモリを確保できなかった。。。

コメントする

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

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

すぐ問題が出た。

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

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

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

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

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

E4B vs E2B：量子化の違い

ここで少し技術的な話。

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

バリアント VRAM 量子化 精度
E4B 9.6 GB 4-bit 高め
E2B 7.2 GB 2-bit 低め

量子化（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。

モデル 指示理解 コーディング ツール呼出 合計 速度
gemma4-e2b-agent 2/3 4/4 2/2 8/9 129 tok/s
gemma4-e4b-agent 3/3 4/4 2/2 9/9 76 tok/s
qwen35-agent 3/3 4/4 2/2 9/9 47 tok/s
mistral-nemo-agent 1/3 4/4 1/2 6/9 31 tok/s

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

約1.7倍速い。

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

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

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

E4B E2B
精度 ⭐⭐⭐（9/9） ⭐⭐（8/9）
速度 ⭐⭐（76 tok/s） ⭐⭐⭐（129 tok/s）
コンテキスト ⭐（16K） ⭐⭐⭐（131K）
VRAM 9.6 GB 7.2 GB

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がパンパンになるので、 実際のタスクの長さに応じて調整が必要かも。

まとめ

ポイント 内容
E4Bの問題 VRAM 9.6GB消費でコンテキスト16Kに制限される
E2Bへ切り替え 7.2GBに削減 → コンテキスト131Kに拡大
精度の変化 9/9 → 8/9（指示理解1問失点）
速度の変化 76 tok/s → 129 tok/s（1.7倍速く）
結論 エージェント用途ならE2Bがベストバランス

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

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