nemoclaw-user-configure-inference

ローカル推論サーバーを使用する

注意点

• Ollamaはローカルチャットに便利ですが、現実的なエージェント負荷のもとでは、モデルとテンプレートの組み合わせによって、ツール呼び出しがプレーンテキストとして返されることがあります。

前提条件

• NemoClawがインストールされていること。
• ローカルモデルサーバーが実行中であること。または、NemoClawのオンボードウィザードで使用、起動、インストールできる、対応するOllama、vLLM、NIMのセットアップがあること。

NemoClawでは、クラウドAPIの代わりに、マシン上で実行中のモデルサーバーへ推論をルーティングできます。 このページでは、Ollama、その他のサーバー向けの互換エンドポイントの使用方法、vLLMとNVIDIA NIM向けの実験的なマネージドオプションについて説明します。

すべての方法で、同じinference.localルーティングモデルを使用します。 サンドボックス内のエージェントがモデルサーバーに直接接続することはありません。 OpenShellが推論トラフィックをインターセプトし、設定したローカルエンドポイントに転送します。

Ollama

Ollamaは、ローカル推論のデフォルトオプションです。 Ollamaがホストにインストールされているか、実行中の場合、オンボードウィザードが自動的に検出します。

Ollamaがインストール済みで実行されていない場合、NemoClawが起動します。 macOSとLinuxでは、Ollamaが存在しない場合にウィザードからインストールすることもできます。 ホスト上のOllamaが、NemoClawのスターターモデルに必要な最小バージョン（現在は0.7.0）より古い場合、ウィザードは古いデーモンを暗黙的に再利用するのではなく、プロバイダーメニューに明示的なOllamaをアップグレード項目を表示し、エクスプレスセットアップの経路もこの項目に解決されます。 ウィザードはCLIバイナリ（ollama --version）とローカルで実行中のデーモン（:11434上の/api/version）の両方を調べます。そのため、たとえば新しいユーザーローカルバイナリと、元のシステムデーモンが組み合わさっている場合など、どちらか一方だけが古くてもアップグレード項目が表示されます。 このチェックでは、WSLからhost.docker.internal経由でアクセスするWindowsホスト上のOllamaは対象外です。この場合は、別のWindowsホスト上のOllamaを使用／起動／インストール項目を使用し、Windows側でそれぞれの処理を実行します。 macOSでは、ウィザードはbrew upgrade ollamaを使って、プラットフォームに応じたインストールまたはアップグレード手順を実行します。 Linuxでは、ウィザードは公式のhttps://ollama.com/install.sh手順を実行します。 Linuxでのアップグレードは、常にsudoを使うシステム向けの手順で実行されます。sudo不要のユーザーローカルの代替手段では、既存のシステムデーモンが:11434で古いバイナリを引き続き提供するためです。 非対話型の実行でsudoを使用できない場合、NemoClawはこの手順を暗黙的に切り替えることはせず、対話形式で再実行するか、Ollamaを手動でアップグレードするよう求めます。 アップグレードの完了後、NemoClawは実行中のデーモンの/api/versionを再確認し、デーモンが引き続き最小バージョン未満を報告する場合は実行を失敗させます。 新規インストールでは、同梱のインストーラーが最小バージョン以上のデーモンをインストールするため、この再確認は行われません。 WSLでは、ウィザードからPowerShell相互運用機能を通じて、Windowsホスト上のOllamaを使用、起動、再起動、またはインストールできます。

Linux のインストールモード

ネイティブ Linux では、インストール方法によって、システムインストール（/usr/local 配下、公式の https://ollama.com/install.sh を使用）と、sudo 不要のユーザーローカルインストール（${HOME}/.local 配下）が選択されます。 NemoClaw はモードを自動的に選択します。

• root として実行するか、パスワードなしの sudo（sudo -n true が 0 を返す）を使用できる場合は、システムインストールが選択されます。
• 非対話実行（NEMOCLAW_NON_INTERACTIVE=1 または stdin に TTY がない場合）で、パスワードなしの sudo を使用できない場合は、ユーザーローカルインストールが選択されます。 この方法なら、ヘッドレスホストでも sudo パスワードの入力を求められずにオンボーディングを完了できます。
• パスワードなしの sudo を使用できない対話型シェルでは、システムインストールが選択され、通常どおり公式インストーラーからパスワードの入力を求められます。

NEMOCLAW_OLLAMA_INSTALL_MODE=system または NEMOCLAW_OLLAMA_INSTALL_MODE=user を指定して、自動検出を上書きできます。

ユーザーローカルインストールでは、公式インストーラーのバイナリ展開手順のみを再現します。 リリースの tarball をダウンロードして ${HOME}/.local に展開し、${HOME}/.local/bin/ollama serve を一度起動します。 systemd サービスの設定や ollama システムユーザーの作成、CUDA ドライバーのインストールは行わないため、再起動後はデーモンを手動で再起動する必要があります。 また、${HOME}/.local/bin が PATH に含まれていない場合、NemoClaw は PATH に関するヒントを1行表示します。ollama を直接実行できるようにするには、シェルのプロファイルに export PATH="${HOME}/.local/bin:$PATH" を追加します。

どちらのモードでも、アーカイブの展開に zstd が必要です。Debian と Ubuntu では、システムインストールの手順で sudo apt-get を使って zstd が自動的にインストールされ、続行前に確認内容が説明されます。 ユーザーローカルインストールでは、昇格した権限なしにシステムパッケージをインストールできません。そのため、zstd が見つからない場合はディストリビューションごとのインストール方法が表示され、処理が終了します。zstd を手動でインストールしてから、オンボーディングを再実行してください。

オンボーディングウィザードを実行します。

$ nemoclaw onboard

プロバイダーの一覧から Local Ollama を選択します。 NemoClaw は、インストール済みモデルを一覧表示します。インストール済みモデルがない場合は、スターターモデルを提示します。 より大きなスターターモデルを現在利用可能な GPU メモリに収められるホストでは、スターターの一覧に qwen3.6:35b が含まれ、デフォルトで選択されます。 オンボーディング時に別の GPU ワークロードがメモリの大半を使用している場合、NemoClaw はメニューを、メモリに収まる最大のモデルに切り替えます。 選択したモデルを取得してメモリに読み込み、続行前に検証します。 Ollama が読み込んだモデルのコンテキスト長を報告した場合、NemoClaw は、自分で NEMOCLAW_CONTEXT_WINDOW を設定していない限り、その値を openclaw.json に設定する contextWindow に使用します。 選択したモデルがツール呼び出しに対応していないと宣言されている場合、オンボーディングは停止し、ollama show <model> の機能に tools が含まれるモデルを選ぶよう案内します。 この検証では、構造化されたチャット補完のツール呼び出しも必須です。 モデルがツール呼び出しの JSON を通常のメッセージテキストとして出力する場合、期待されるレスポンスフィールドにツール呼び出しを返すモデルを選べるよう、オンボーディングは停止します。 WSL で Windows ホスト上の Ollama を選択した場合、NemoClaw は host.docker.internal:11434 を使用し、WSL 内に ollama CLI がなくても、Ollama HTTP API 経由で不足しているモデルを取得します。

WSL と Windows ホストの Ollama

NemoClaw を WSL 内で実行すると、プロバイダーメニューに Windows ホストの Ollama の操作が表示されることがあります。

• Windows デーモンにすでに接続できる場合は、Windows の Ollama を使用します。
• デーモンはインストール済みでも Windows のループバックにのみバインドされている場合は、Windows の Ollama を再起動します。
• Ollama はインストール済みでも実行されていない場合は、Windows の Ollama を起動します。
• Windows に Ollama がインストールされていない場合は、Windows に Ollama をインストールします。

インストールと再起動の処理では、Windows 側で OLLAMA_HOST=0.0.0.0:11434 を設定し、Docker と WSL が host.docker.internal 経由でデーモンに接続できるようにします。 インストールまたは再起動の処理後、NemoClaw は検出した Windows のトレイアプリ、または検証済みの ollama.exe パスから Ollama を再起動し、host.docker.internal:11434 が応答するまで待機します。

HTTP エンドポイントにまだ接続できない場合、NemoClaw は PowerShell 相互運用機能を通じて Windows の ollama.exe プロセスも確認し、Windows ホストの経路を非表示にせず、起動または再起動の操作を提示できるようにします。 デーモンに接続できるようにならない場合は、オンボーディングで Windows 側のプロセスとポートの状態を調べるために実行できる PowerShell コマンドが表示されます。一度に使用する Ollama インスタンスはポート 11434 上の 1 つだけにしてください。 WSL と Windows ホストの両方で Ollama が実行されている場合は、オンボーディング中に目的のメニュー項目を選択し、NemoClaw が適切なデーモンに対してモデルを検証して取得するようにしてください。

警告：

Ollama はローカルでのチャットに便利ですが、モデルとテンプレートの組み合わせによっては、現実的なエージェント負荷のもとでツール呼び出しがプレーンテキストとして返されることがあります。TUI でツールが実行されず、{"name":"memory_search","arguments":{...}} のような生の JSON が表示される場合は、--enable-auto-tool-choice と正しい --tool-call-parser を指定して vLLM に切り替えてください。ツール呼び出しの信頼性を参照してください。

認証付きリバースプロキシ

WSL 以外のホストでは、NemoClaw は Ollama を 127.0.0.1:11434 にバインドしたまま、トークン認証が必要なリバースプロキシを 0.0.0.0:11435 で起動します。 ネイティブのインストール／起動経路でも、NemoClaw が管理する systemd 起動設定はループバックバインドにリセットされます。 コンテナーやローカルネットワーク上のほかのホストは、リクエストを転送する前に Bearer トークンを検証するプロキシ経由でのみ Ollama にアクセスできます。 このネイティブ経路では、NemoClaw が認証なしで Ollama を公開することはありません。

WSL の Ollama 経路では、このプロキシを使用しません。 Windows ホストの Ollama では、host.docker.internal を介して Windows デーモンを使用します。

WSL 以外の Ollama セットアップでは、オンボードウィザードがプロキシを自動的に管理します。

• 初回実行時にランダムな 24 バイトのトークンを生成し、0600 のアクセス許可で ~/.nemoclaw/ollama-proxy-token に保存します。
• Ollama の起動後にプロキシを起動し、続行する前に動作を確認します。
• 前回の実行で残ったプロキシプロセスをクリーンアップします。
• 推論経路を確定する前に、サンドボックスの Docker ネットワーク経路からプロキシへの接続を確認します。
• アンインストール時に、NemoClaw の状態を削除する前に該当するプロキシプロセスを停止します。
• ホストの再起動後も保存済みのトークンを再利用するため、オンボードをやり直す必要はありません。

ネイティブ Linux ホストでは、ファイアウォールによってホストからのプロキシのヘルスチェックを許可しながら、OpenShell Docker ブリッジ上のサンドボックスコンテナーをブロックできる場合があります。 サンドボックス側のプロキシ接続確認が TCP エラーで失敗すると、オンボーディングは推論経路を保存する前に終了し、次のようなコマンドを表示します。

$ sudo ufw allow from <openshell-docker-subnet> to any port 11435 proto tcp
$ nemoclaw onboard

たとえば Docker Desktop または WSL が異なるホストルーティングモデルを使用しているために、接続確認を実行できない場合、オンボーディングは続行し、通常のプロキシヘルスチェックに依存します。

サンドボックスプロバイダーは、プロキシポート 11435 と、生成されたトークンを OPENAI_API_KEY 認証情報として使用するように設定されます。 OpenShell の L7 プロキシがエグレス時にトークンを挿入するため、サンドボックス内のエージェントがトークンを直接見ることはありません。

GET /api/tags を含むすべてのプロキシエンドポイントで、Bearer トークンが必要です。 プロキシ経由の内部ヘルスチェックと接続確認では、HTTP レスポンス（401 を含む）があればプロキシが稼働中であることを確認できます。何も応答しない場合にのみ失敗します。

オンボードの開始時に Ollama がループバック以外のアドレスで実行中の場合、ウィザードは Ollama を 127.0.0.1:11434 で再起動し、モデルサーバーへのネットワーク経路がプロキシ経由のみになるようにします。

GPU メモリのクリーンアップ

Ollama 以外に切り替えるとき、ホストサービスを停止するとき、または Ollama を使用するサンドボックスを破棄するとき、NemoClaw は Ollama に対して、現在 GPU メモリに読み込まれているモデルのアンロードを要求します。 クリーンアップでは、Ollama が報告した各モデルに keep_alive: 0 を送信し、ベストエフォートで実行されます。そのため、Ollama がすでに停止している場合もシャットダウンは続行されます。 ダウンロード済みのモデルファイルは削除されません。

非対話型セットアップの詳しい手順については、references/use-local-inference-details.md をご覧ください。

OpenAI 互換サーバー

このオプションは、vLLM、TensorRT-LLM、llama.cpp、LocalAI など、/v1/chat/completions を実装するあらゆるサーバーで動作します。 互換性のあるエンドポイントでは、NemoClaw はデフォルトで /v1/chat/completions を使用します。 これにより、ローカルバックエンドが /v1/responses リクエストを受け付けても、システムプロンプトとツール定義を黙って破棄する場合に発生する一連の障害を回避できます。 /v1/responses を使用するには、オンボードの実行前に NEMOCLAW_PREFERRED_API=openai-responses を設定します。

モデルサーバーを起動します。 以下の例では vLLM を使用していますが、OpenAI 互換サーバーであればどれでも動作します。

$ vllm serve meta-llama/Llama-3.1-8B-Instruct --port 8000

オンボードウィザードを実行します。

$ nemoclaw onboard

ウィザードで推論プロバイダーを選択するよう求められたら、Other OpenAI-compatible endpoint を選択します。 ローカルサーバーのベース URL を入力します。例：http://localhost:8000/v1

ウィザードで API キーの入力を求められます。 サーバーで認証が不要な場合は、空でない任意の文字列（例：dummy）を入力します。

NemoClaw は、続行する前にテスト推論リクエストを送信してエンドポイントを検証します。 互換エンドポイントプロバイダーでは、ウィザードはデフォルトで /v1/chat/completions を確認します。 NEMOCLAW_PREFERRED_API=openai-responses を設定した場合、NemoClaw は代わりに /v1/responses を確認し、OpenClaw が必要とするストリーミングイベントが応答に含まれている場合にのみ、それを選択します。 推論モデルが最終回答を生成する前に推論内容のみを返した場合、NemoClaw は応答の予算を増やしてスモークテストリクエストを再試行します。 ルート、設定、認証のエラーは、引き続き即座に失敗します。

非対話型セットアップと API パスの選択に関する詳しい手順は、references/use-local-inference-details.md を参照してください。

Anthropic 互換サーバー

詳しい手順は、references/use-local-inference-details.md を参照してください。

vLLM

vLLM がすでに localhost:8000 で実行されている場合、NemoClaw は自動的に検出し、/v1/models エンドポイントに問い合わせて読み込まれているモデルを特定できます。 NVIDIA GPU を搭載したサポート対象の Linux ホストでは、オンボードウィザードから管理対象の vLLM コンテナーをインストールまたは起動することもできます。

すでに実行中の vLLM サーバーを使用する場合は、nemoclaw onboard を実行し、プロバイダーの一覧から Local vLLM [experimental] を選択します。

$ nemoclaw onboard

vLLM がすでに実行中の場合、NemoClaw は実行中のモデルを検出し、エンドポイントを検証します。 vLLM が実行されておらず、ホストが DGX Spark または DGX Station の管理対象プロファイルに一致する場合、NemoClaw はデフォルトで Install vLLM または Start vLLM の項目を表示します。 汎用 Linux NVIDIA GPU ホストでは、管理対象の項目を表示するために、引き続き NEMOCLAW_EXPERIMENTAL=1 または NEMOCLAW_PROVIDER=install-vllm が必要です。 NemoClaw は vLLM イメージを取得し、モデルの重みを ~/.cache/huggingface にダウンロードして、localhost:8000 で nemoclaw-vllm コンテナーを起動します。モデルの読み込み中は進行状況を示すマーカーを出力します。 初回の実行には 10～30 分かかる場合があります。 次回以降の実行では、キャッシュされたイメージとモデルの重みが再利用されます。

管理対象の vLLM では、以下のプロファイルを使用します。

ホストプロファイル	デフォルトモデル
DGX Spark	Qwen/Qwen3.6-27B-FP8
DGX Station	Qwen/Qwen3.6-27B-FP8
NVIDIA GPU 搭載の Linux	nvidia/NVIDIA-Nemotron-3-Nano-4B-FP8

注：

NemoClaw は vLLM で chat/completions API パスを強制的に使用します。 vLLM の /v1/responses エンドポイントは --tool-call-parser を実行しないため、ツール呼び出しは生テキストとして届きます。

非対話型セットアップと管理対象 vLLM モデルの上書きに関する詳しい手順は、references/use-local-inference-details.md を参照してください。

NVIDIA NIM（実験的）

NemoClaw は、NIM 対応の NVIDIA GPU を搭載したホストで、NIM コンテナの取得、起動、管理を行えます。

実験的フラグを設定して、オンボーディングを実行します。

$ NEMOCLAW_EXPERIMENTAL=1 nemoclaw onboard

プロバイダー一覧から Local NVIDIA NIM [experimental] を選択します。 NemoClaw は GPU VRAM に基づいて利用可能なモデルを絞り込み、NIM コンテナイメージを取得して起動し、正常な状態になるまで待機してから続行します。 NVIDIA GPU のモデルが混在するホストでは、事前チェックの概要に検出された各 GPU モデルと VRAM の合計が表示されるため、モデル選択に使用されたデバイスクラスを確認できます。

NIM コンテナイメージは nvcr.io でホストされており、docker pull を実行するには、事前に NGC レジストリで認証する必要があります。 Docker が nvcr.io にログインしていない場合、オンボーディング時に NGC API キーの入力を求め、--password-stdin を使って docker login nvcr.io を実行するため、キーがディスクやシェル履歴に書き込まれることはありません。 入力中はキーがマスクされ、キーが無効な場合は失敗する前に一度再試行します。 非対話モードでは、Docker がすでに認証済みでない場合、オンボーディングはログイン手順を表示して終了します。自分で docker login nvcr.io を実行してから、nemoclaw onboard --non-interactive を再実行してください。 NGC_API_KEY または NVIDIA_API_KEY がすでにエクスポートされている場合、NemoClaw はコマンドライン引数ではなく、プロセス環境を介して管理対象の NIM コンテナに渡します。 ヘルスエンドポイントが利用可能になる前に NIM コンテナが終了した場合、オンボーディングは早期に停止し、コンテナログの末尾を表示します。

注：

NIM は内部で vLLM を使用します。 同じ chat/completions API パスの制限が適用されます。

非対話型セットアップの詳細な手順については、references/use-local-inference-details.md を読み込んでください。

タイムアウトの設定

詳細な手順については、references/use-local-inference-details.md を読み込んでください。

設定の確認

詳細な手順については、references/use-local-inference-details.md を読み込んでください。

実行時のモデル切り替え

詳細な手順については、references/use-local-inference-details.md を読み込んでください。

参考資料

• 推論プロバイダーの切り替え、モデルの実行環境の変更、または推論ルーティングの再設定を行う場合は、references/switch-inference-providers.md を読み込んでください。サンドボックスを再起動せずに、アクティブな推論モデルを変更します。
• ユーザーから、2 つ目のモデルの追加方法、サブエージェントモデルの設定方法、ビジョンタスクでの Omni の使い方、agents.list の設定方法、または NemoClaw での sessions_spawn の使い方について尋ねられた場合は、references/set-up-sub-agent.md を読み込んでください。補助的な OpenClaw サブエージェントモデルを追加するための、NemoClaw 固有のファイルパスと更新手順を説明しています。
• references/tool-calling-reliability.md — Ollama でツール呼び出しが漏出する症状、ツール呼び出しパーサーを備えた vLLM が推奨される状況、パーサー対応のローカルエンドポイントに NemoClaw の接続先を変更する方法について説明しています。
• 利用可能なプロバイダー、オンボーディングウィザードに表示される内容、または推論ルーティングの仕組みを説明する場合は、references/inference-options.md を読み込んでください。NemoClaw のオンボーディング時に提供されるすべての推論プロバイダーを一覧にしています。
• 非対話型セットアップ、API パスの選択、Anthropic 互換サーバー、および関連する詳細な手順が必要な場合は、references/use-local-inference-details.md を読み込んでください。

関連スキル

• オンボーディング時に利用可能なプロバイダーの全一覧については、Inference Options を参照してください。
• ローカルモデルから生の JSON ツール呼び出し出力が返される問題の診断については、Tool-Calling Reliability を参照してください。
• 実行時のモデル切り替えについては、Switch Inference Models を参照してください。
• nemoclaw-user-get-started — 初回インストール用のクイックスタート（nemoclaw-user-get-started スキルを使用）