Ollamaモデルが遅い — 5つの最適化
OpenClaw内でOllamaモデルが毎秒5トークン未満しか生成しない場合、最も多い原因はGPUアクセラレーションなしでCPU上で実行されている、VRAMに収まらない全精度（F16）モデルを使用している、またはコンテキストウィンドウが不必要に大きいことです。以下の各最適化はこれらの根本原因の1つを対象としています。gpu_layers: -1とQ4_K_M量子化を設定したMac Mini M4では、スループットが4-6 tok/sから80-120 tok/sに向上するのが一般的です。
🔍 最初に：ベースライン診断
出力で2つのことを確認してください：'ollama ps'の「device」列 — 「GPU」または「Metal」の代わりに「CPU」と表示されている場合、ハードウェアアクセラレーションが無効です。そして --verboseの「eval rate」行 — Apple Siliconで10 tok/s未満、または独立NVIDIAで20 tok/s未満は設定の問題を示しています。最適化を続ける前にこの値をメモしてください。
✅ 5つの最適化（順番に適用）
デフォルトでは、Ollamaはすべての層がVRAMに収まるか確認できない場合、一部をCPUにオフロードします。gpu_layers: -1を設定すると全層をGPUに強制します。収まらない場合はサイレントデグレードではなく警告が出ます。Apple SiliconとNVIDIAシステムでの性能向上の主な要因はこの設定です。
アテンション計算はコンテキスト長と共に二乗で増加します。ほとんどのOpenClaw会話は実際には1,500トークン未満しか使用しないため、デフォルトの4096ウィンドウは無駄が多いです。長いドキュメント分析以外は半分にしてください。短いハートビートを送るだけのエージェントには512で十分です。
Q4_K_Mはほとんどのユースケースで推奨される量子化です：Q8より40-50%小さく、ベンチマーク性能の損失は1%未満です。Q2_Kはより速いですが、複数ステップの論理を必要とするエージェントタスクでは使用を避けてください。
毎日の挨拶、ハートビートping、静的なFAQクエリなど同じプロンプトの繰り返しはほぼゼロレイテンシでキャッシュから提供できます。OllamaデータディレクトリをDockerボリュームとしてマウントすれば、キャッシュエントリは再起動後も保持されます。1日に同じプロンプトを複数回送るスケジュールドエージェントに最も効果的です。
インテント分類で「シンプル」なクエリを2-3Bモデルにルーティングします。OpenClawのルーティング設定で、挨拶、状態確認、短い返答に高速モデルを指定し、大きなモデルを深い推論が必要なタスクに温存できます。Gemma 2Bは7Bモデルの2倍の速度でほとんどの会話交流を処理できます。
コールドスタート：再起動後の最初のリクエストで 「model not found」
再起動後に最初の応答が遅い、あるいは 「model not found」 で失敗するのは、同じ問題を別の角度から見たものです。モデルがまだメモリに載っていないだけです。以下の対処で、最初のリクエストを10回目と同じ挙動にできます。
✅ 修正1 — OpenClawのOllamaリクエストタイムアウトを増やす
# openclaw.yamlでOllamaタイムアウトを増やす
providers:
- id: local-ollama
type: ollama
baseUrl: http://localhost:11434
timeout: 120000 # 120秒（デフォルト：30）
coldStartTimeout: 300000 # 初回ロードに5分✅ 修正2 — ゲートウェイ起動前にOllamaを事前ウォームアップ
# スタートアップスクリプトでopenclaw gateway startの前に追加 ollama run llama3.1:8b-q4_K_M '' --nowordwrap & sleep 30 # モデルロードを待つ openclaw gateway start
✅ 修正3 — モデルのアンロードを無効化（常にロード状態を維持）
# モデルを無期限に保持（より多くのRAMを使用）
{
"ai": {
"keep_alive": -1
}
}
# または長いタイムアウトを設定
{
"ai": {
"keep_alive": "24h"
}
}