OpenClawの必要VRAM:エージェントのコンテキストで手持ちのGPUに収まるローカルLLM

OpenClawをローカルLLMで動かすときの必要VRAM。要求されるコンテキスト長とそのメモリ消費、12GB・16GB・24GBのGPUで最適なツール呼び出し対応モデルをまとめました。

更新日 · 7分で読めます · 推定値はその旨を明記しています

結論

Ollamaがローカルモデルに推奨する64kコンテキスト・Q4で最適なツール呼び出し対応モデルは、12GBか16GBのGPUならGemma 4 12B、24GBのGPUならMuse Glimmer 30Bです。

12GBのGPU
Gemma 4 12B Q4・64kで9.1GB、68トークン/秒。
16GBのGPU
Gemma 4 12B Q4・64kで9.1GB、97トークン/秒。
24GBのGPU
Muse Glimmer 30B Q4・64kで19.4GB、41トークン/秒。
OpenClawではなくHermes Agentを使う場合
64,000トークン以上のコンテキストウィンドウ それより小さいウィンドウのモデルは起動時に拒否されます。コンテキスト長を自分では設定できないため、Ollama側で引き上げてください。
目次

OpenClawには、ツール呼び出し(tool calling)に対応し、長い会話を保持できるローカルモデルが必要です。GPUの選び方を左右するのは、このうち長い会話のほうです。OpenClawは既定でOllamaに32,768トークンを要求し、Ollamaはローカルモデルに64k以上を推奨しています。さらにOpenClawのドキュメントの例では、最初のメッセージより前に、OpenClaw自身のシステムプロンプトとツールスキーマだけで約17,600トークンを使っていました。

OpenClawが実際に使うコンテキスト

OpenClawのドキュメントにある/contextの例では、32,000トークンのコンテキストウィンドウのうち、システムプロンプトが9,603トークン、ツールスキーマが7,997トークンを占めています。入力を始める前に32kのウィンドウの半分以上を使ってしまうため、多くのランタイムの初期設定のままではうまく動きません。ローカルモデルでは、OpenClawはツール検索(Tool Search)を有効にします。ツールスキーマを必要になるまで送らない機能なので、実際の使用量はこの例より少なくなることがあります。

  • 強制的な下限:「It warns below 20% with an 8k floor. It hard-blocks below 10% with a 4k floor.」(訳:20%を下回ると警告します。この基準の下限は8kです。10%を下回ると強制的にブロックします。この基準の下限は4kです)[出典]
  • ローカルモデルの自動検出:「An existing LLM is offered automatically only when LM Studio reports tool training and at least 16K of effective context.」(訳:既存のLLMが自動で候補に出るのは、LM Studioがツール学習済みで、実効コンテキストが16K以上だと報告した場合だけです)[出典]
  • Ollamaに要求する値:「Local discovery normally caps contextTokens at 32,768 (or the model's smaller native window)」(訳:ローカル検出では通常、contextTokensの上限を32,768(モデルのネイティブのウィンドウがそれより小さければその値)にします)[出典]
  • OllamaのOpenClaw向けの推奨:「It is recommended to use a context window of at least 64k tokens if using local models.」(訳:ローカルモデルを使う場合は、64kトークン以上のコンテキストウィンドウを使うことを推奨します)[出典]

今もよく引用される「Minimum is 16000」(訳:最小値は16000)というエラーは、もう古い情報です。これはOpenClaw v2026.4.15で出ていたものです(該当のissue)。2026年4月以降、下限はモデルのウィンドウに対する割合で決まり、その最小値が上記の4kと8kです。Hermes Agentはさらに厳しく、64,000トークン未満のモデルを起動時に拒否します。

GPU(グラボ)別:OpenClawに最適なモデル

対象はツール呼び出し対応モデルだけで、量子化はQ4_K_M、コンテキスト長は各列のとおりです。選び方はGPUごとのページと同じルールで、コンテキストの分をあらかじめ含めています。まず、そのコンテキストで収まり、実用的な速度で動くこと。次に、条件を満たすなかで最も大きいクラス。最後に、最も新しいリリースです。メモリの95%近くを使うモデルは、列のコンテキストより長くする余裕がありません。また、モデルのネイティブのコンテキスト長がその列のコンテキスト長以上である必要があるため、上限が40kのモデルは64kの列には出てきません。

機種使える容量32kコンテキスト64kコンテキスト
RTX 5070 12GB Gemma 4 12B 8.6GB · 68トークン/秒Gemma 4 12B 9.1GB · 68トークン/秒 確認
RTX 5080 16GB Gemma 4 12B 8.6GB · 97トークン/秒Gemma 4 12B 9.1GB · 97トークン/秒 確認
RX 7900 XT 20GB Muse Glimmer 30B 19GB · 32トークン/秒Gemma 4 12B 9.1GB · 80トークン/秒 確認
RTX 4090 24GB Muse Glimmer 30B 19GB · 41トークン/秒Muse Glimmer 30B 19.4GB · 41トークン/秒 確認
RTX 5090 32GB Muse Glimmer 30B 19GB · 73トークン/秒Muse Glimmer 30B 19.4GB · 73トークン/秒 確認
RTX PRO 5000 Blackwell 48GB Muse Glimmer 30B 19GB · 54トークン/秒Muse Glimmer 30B 19.4GB · 54トークン/秒 確認
H100 SXM 80GB Llama 3.3 70B 53.8GB · 57トークン/秒Llama 3.3 70B 64.6GB · 57トークン/秒 確認
RTX PRO 6000 Blackwell 96GB Llama 3.3 70B 53.8GB · 31トークン/秒Llama 3.3 70B 64.6GB · 31トークン/秒 確認
RTX Spark 102GB Mistral Small 4 119B (MoE) 73GB · 56トークン/秒Mistral Small 4 119B (MoE) 73.8GB · 56トークン/秒 確認
DGX Spark 126GB Mistral Small 4 119B (MoE) 73GB · 51トークン/秒Mistral Small 4 119B (MoE) 73.8GB · 51トークン/秒 確認
Mac Studio M2 Ultra 144GB Muse Glimmer 30B 19GB · 32トークン/秒Muse Glimmer 30B 19.4GB · 32トークン/秒 確認

速度はメモリ帯域幅から求めた1ストリームでの上限(理論値)で、生成速度(トークン/秒)推定ツールと同じ計算式です。エージェントは長いプロンプトの読み込み(プロンプト処理)にも時間を使いますが、ここには含めていません。Appleシリコンでは、このプロンプト処理が遅くなります。「確認」を押すと、そのGPUとモデル、64kコンテキストを選んだ状態でローカルLLM動作チェッカーが開き、別のモデルや量子化も試せます。機種名のリンク先(GPUのページ)は英語です。

この表で、64kでツール呼び出し対応モデルを動かせる最も小さいマシンはRTX 5070で、モデルはGemma 4 12Bです。

64kコンテキストのメモリ消費

コンテキストを32kから64kにすると、すべてのトークンを保持するレイヤーのKVキャッシュは倍になります。一方、スライディングウィンドウのレイヤーはウィンドウの大きさで止まり、線形アテンションのレイヤーは一定の大きさの状態を保つだけです。そのため64kのメモリ消費を左右するのは、モデルの大きさよりも、はるかにアテンションの設計のほうです。下の表のメモリはKVキャッシュだけの量(FP16)で、重みの分は別にかかります。

モデル32kのキャッシュ64kのキャッシュ64k・Q4の合計
Qwen3.5 4B1.1GB2.2GB5.5GB
Qwen3.5 9B1.1GB2.2GB8.5GB
Gemma 4 12B0.9GB1.4GB9.1GB
Llama 3.2 3B3.8GB7.5GB9.9GB
Llama 3.1 8B4.3GB8.6GB13.9GB
gpt-oss 20B0.8GB1.6GB14.8GB
Granite 4.2 8B5.4GB10.7GB16.5GB
Gemma 4 26B-A4B (MoE)0.9GB1.6GB17.6GB
Muse Glimmer 30B0.5GB1GB19.4GB
Ministral 3 14B5.4GB10.7GB19.7GB
Nemotron 3.5 Lightning 30B-A3B (MoE)0.3GB0.5GB20GB
Qwen3.6 27B2.3GB4.4GB21.7GB
Qwen3.8 27B2.3GB4.4GB21.7GB
GLM-4.7 Flash 30B-A3B (MoE)1.8GB3.5GB22.9GB
Qwen3.6 35B-A3B (MoE)0.7GB1.4GB23.6GB
Gemma 4 31B3.5GB6.2GB25.6GB
Devstral Small 2 24B5.4GB10.7GB25.7GB
Granite 4.2 30B8.6GB17.2GB35.4GB

エージェントに合うモデルが、単に読み込める最大のモデルとは限らないのは、この差があるからです。64kでのキャッシュは、Nemotron 3.5 Lightning 30B-A3B (MoE)が0.5GB、Granite 4.2 30Bが17.2GBです。ハイブリッド構成(線形アテンション)やスライディングウィンドウ・アテンションを使うモデルは、大半のレイヤーをキャッシュに載せずに済みます。これはまさに、エージェントの長いコンテキストに必要な性質です。キャッシュをQ8に量子化するとこの数字はおよそ半分になり、チェッカーにはその切り替えがあります。

ツールを呼び出せるモデル

エージェントは、リクエストのたびにツール定義を送ります。モデルがそれを使えるのは、チャットテンプレートがツール定義を受け渡す場合だけです。そこで当サイトでは、各モデルの公式テンプレートを読んで確認しました。掲載している34モデルのうち27モデルが対応しています。対応していないのは次のモデルです。

対応しているモデルの中にも、注意が必要なものがあります。

  • Llama 3.2 3B:ツール呼び出しに対応しているのはInstruct版です。ベースモデルにはチャットテンプレートがありません。
  • Llama 3.1 8B:ツール呼び出しに対応しているのはInstruct版です。ベースモデルにはチャットテンプレートがありません。
  • Qwen3.5 9B:Qwenは、思考を保つためにコンテキストを128K以上確保するよう勧めています。
  • Gemma 4 12B:テンプレートでは思考モードが既定でオフです。
  • Ministral 3 14B:Mistralはツールの数を少なく抑えるよう勧めていますが、OpenClawは多くのツールを送ります。
  • gpt-oss 20B:OpenAIのharmony形式で動かす必要があります。モデルカードには、そうしないと正しく動かないと書かれています。
  • Gemma 4 26B-A4B (MoE):テンプレートでは思考モードが既定でオフです。
  • Qwen3.6 27B:Qwenは、思考を保つためにコンテキストを128K以上確保するよう勧めています。
  • GLM-4.7 Flash 30B-A3B (MoE):Z.aiは、複数ターンにわたるエージェントの作業ではPreserved Thinkingを有効にするよう勧めています。
  • Nemotron 3.5 Lightning 30B-A3B (MoE):NVIDIAのドキュメントには、コーディングエージェント向けのテンプレートの追加フラグが記載されています。
  • Qwen3.6 35B-A3B (MoE):Qwenは、思考を保つためにコンテキストを128K以上確保するよう勧めています。
  • Qwen3-Coder-Next 80B-A3B (MoE):非思考モードのみです。
  • gpt-oss 120B:OpenAIのharmony形式で動かす必要があります。

OllamaとLM Studioでのコンテキストの設定

Ollama自体の初期値は、お使いのGPUによって変わります。「Ollama defaults to the following context lengths based on VRAM: < 24 GiB VRAM: 4k context; 24-48 GiB VRAM: 32k context; >= 48 GiB VRAM: 256k context」(訳:Ollamaは、VRAMに応じて次のコンテキスト長を初期値にします。VRAM 24GiB未満:4k、24〜48GiB:32k、48GiB以上:256k)。24GB未満なら4kで、エージェントにはまったく足りません。OpenClawは、Ollamaのネイティブのエンドポイントへのリクエストのたびに、独自のコンテキスト長(32,768か、モデルのネイティブのコンテキスト長のほうが小さければその値)を送ります。そのため、OpenClawを使う場合はたいてい設定は不要です。GPUに64kを載せる余裕があるなら、OpenClawのプロバイダー設定でより大きい値を指定しましょう。LM Studioのモデルは、OpenClawが64,000トークンで読み込みます(モデルの最大値が上限)。Hermes Agentはコンテキスト長を自分では設定できないため、起動する前にOllama側で引き上げてください。

OllamaのURLは、OpenAI互換の/v1ではなく、ネイティブのものを使ってください。OpenClawのドキュメントによると、/v1のパスではツール呼び出しが動かなくなります。

よくある質問

OpenClawに必要なVRAMは?

OpenClaw自体よりも、コンテキスト長で決まります。OpenClawは既定でOllamaに32,768トークンを要求し、Ollamaはローカルモデルに64k以上を推奨しています。64k・Q4で最適なツール呼び出し対応モデルは、16GBのGPUならGemma 4 12B(Q4で9.1GB、97トークン/秒)、24GBのGPUならMuse Glimmer 30B(Q4で19.4GB、41トークン/秒)です。

12GBのGPUでOpenClawに最適なローカルLLMは?

32kコンテキストならGemma 4 12B(Q4で8.6GB、68トークン/秒)です。64kならGemma 4 12B(Q4で9.1GB、68トークン/秒)です。

16GBのGPUでOpenClawに最適なローカルLLMは?

64kコンテキストならGemma 4 12B(Q4で9.1GB、97トークン/秒)です。32kならGemma 4 12B(Q4で8.6GB、97トークン/秒)です。

24GBのGPUでOpenClawに最適なローカルLLMは?

64kコンテキストならMuse Glimmer 30B(Q4で19.4GB、41トークン/秒)です。32kならMuse Glimmer 30B(Q4で19GB、41トークン/秒)です。

OpenClawに必要なコンテキスト長は?

OpenClaw自体の下限は低く、4kトークン(またはモデルのウィンドウの10%)未満のモデルは拒否し、8k(または20%)未満では警告を出します。ただし実際には、ドキュメントの例では、最初のメッセージより前に、システムプロンプトとツールスキーマだけで約17,600トークンを使っていました。そのため実用上の最低ラインは32kで、Ollamaは64kを推奨しています。最小値を16000トークンとしていた以前のエラーはv2026.4.15のもので、2026年4月に削除されました。

Hermes Agentに必要なコンテキスト長は?

64,000トークン以上が必須です。Hermes Agentは、それより小さいウィンドウのモデルを起動時に拒否します。HermesはOpenAI互換のエンドポイント経由でOllamaとやり取りし、コンテキスト長を自分では設定できません。そのため、Ollama側でコンテキスト長を引き上げてください。

ツール呼び出しに対応したローカルLLMは?

当サイトで扱う34のオープンモデルのうち、27モデルは公式チャットテンプレートがツールを受け渡します。Gemma 3 12B、Phi-4 14B、Mistral Small 3.1 24B、Gemma 3 27B、DeepSeek-R1 Distill Qwen 32B、DeepSeek-R1 Distill Llama 70Bは対応していません。テンプレートがツール定義を落とすか無視するため、エージェントはこれらを当てにできません。

数字は、月に一度。

新しいオープンモデルと必要なメモリ、価格の動き、私たちの最新の実測値。メールは月に1通で、ワンクリックで解除できます。

メールは月に1通。ワンクリックで解除でき、アドレスをほかの目的には使いません。 プライバシーポリシー(英語)