著者 Nemotron 3.5 LightningをVPSで動かす方法
OllamaでNVIDIA Nemotron 3.5 Lightningを自分のサーバーで実行します。取得する正確なtag、必要なRAM容量、CPUのみで十分な速度かを確認できます。
Nemotron 3.5 Lightning の用途
Nemotron 3.5 Lightning は、NVIDIA が 2026 年 8 月にリリースした、オープンな 30B mixture-of-experts モデルです。1 つのチャットウィンドウで使うのではなく、数時間にわたって動作するエージェント向けに設計されています。MoE (mixture of experts) では、重みを多数の expert サブネットワークに分割し、各 token をそのうち少数のネットワークだけに振り分けます。NVIDIA の model card では、総パラメーター数を 30 billion、token あたりの active パラメーター数を 3 billion としています。メモリでは大きい数の分を消費します。速度では小さい数の分の性能を得られます。
このトレードオフが、レンタルするサーバーでこのモデルを検討する理由です。実際の作業を行うエージェントは、1 日を通して数千回の短いリクエストを送信します。そのため、自分のサーバーで運用できるかどうかは、1 ドルあたりのスループットで決まります。1 回の応答に 40 秒かかるモデルは、使いやすいアシスタントにはなっても、エージェントには不向きです。1 つのタスクで 20 回呼び出し、毎回の完了を待つことになるためです。
NVIDIA は、このアーキテクチャを hybrid と説明しています。Mamba-2 層と MoE 層を交互に配置し、一部に attention 層を使用します。model card では、最大 context length を最大 1M token、ライセンスを OpenMDW-1.1 としており、商用利用に対応すると記載されています。主な対応言語は English と code で、Spanish、French、German、Italian、Japanese も挙げられています。
Artificial Analysis は 2026 年 8 月のリリース時の測定結果として、NVFP4 weights を提供するリリース前の DeepInfra endpoint で、出力速度が毎秒約 670 token に達したと公表しています。これは hosted GPU endpoint での値です。この数値は、そのアーキテクチャで可能な性能として捉えてください。使用する VPS で同じ性能が出るという意味ではありません。
どの Ollama タグがどの VPS に適しているか
Ollama ライブラリでは、同じ重みについて複数のビルドが公開されています。違いは量子化です。量子化は各重みを何ビットで格納するかを指定するもので、ダウンロードサイズが大きく変わります。
The data behind this chart
[
{
"label": "30b-a3b-q4_K_M",
"size_gb": 25
},
{
"label": "30b-a3b-q8_0",
"size_gb": 35
},
{
"label": "30b-a3b-bf16",
"size_gb": 66
},
{
"label": "30b-a3b-mlx",
"size_gb": 23
}
]latest、30b、30b-a3bという名前のタグは、いずれも 30b-a3b-q4_K_M と同じダイジェストを指します。そのため、デフォルトのダウンロードは、完全な 1M コンテキストに対応した 25 GB の 4 ビットビルドです。Q8_0 は 35 GB、bf16 は 66 GB で、どちらも 1M コンテキストに対応しています。23 GB の MLX ビルドは Apple silicon 用で、コンテキスト長が 256K に制限されるため、Linux VPS では適していません。
これらはダウンロードサイズであり、必要なメモリ容量ではありません。NVIDIA は Ollama ビルドの最小 VRAM（ビデオ RAM）容量を公開していないため、ダウンロードサイズは下限にすぎないと考えてください。重みはどこかに常駐する必要があります。GPU が保持できる場合は GPU メモリに、それ以外の場合はシステム RAM に配置されます。さらに、KV キャッシュ（key/value cache。モデルが会話をトークン単位で保持するためのメモリ）が加わります。使用するハードウェアでの実際の値は計算ではなくコマンドで確認します。そのコマンドは以下に示します。量子化レベルをまだ決めていない場合は、Q4、Q8、FP16 でそれぞれ何が必要になるかで、各段階で何を失うかを説明しています。
正確なタグを取得し、latest は使用しない
latest は変動するポインターです。ライブラリがこれを再公開すると、ノートに理由を記録していなくても、次回の pull でエージェントの動作が変わります。タグを明示してください。
curl -fsSL https://ollama.com/install.sh | sh
ollama --version
ollama pull nemotron-3.5-lightning:30b-a3b-q4_K_Mインストールスクリプトは、ollama ユーザーで実行し、モデルを /usr/share/ollama/.ollama/models に保持する systemd サービスを設定します。ほとんどの VPS イメージでは、このパスは root ファイルシステム上にあります。そのため、25 GB を要求する前に空き容量を確認してください。そのファイルシステムの空き容量が少ない場合は、pull の前に Ollama がモデルを保存する場所と移動方法 を確認してください。ディスクが満杯になってから読むよりも有効です。
df -h /usr/share/ollamapull が途中で停止して no space left on device を報告した場合、その意味は文字どおりです。部分的に取得された blob は、削除するまでディスク上に残ります。続いて、取得された内容を確認します。
ollama show nemotron-3.5-lightning:30b-a3b-q4_K_Mollama show では、アーキテクチャ、パラメーター数、コンテキスト長、ファイルが実際に使用している量子化方式を確認できます。いずれかがライブラリページの内容と一致しない場合、意図したものとは別のタグを取得しています。
実行し、実際にどこで動作したかを確認します
sudo systemctl enable --now ollama
ollama run nemotron-3.5-lightning:30b-a3b-q4_K_M "Reply with one word: ready"モデルを読み込んだまま、2 つ目のシェルで次を実行します。
ollama psこのコマンドで、マシンのメモリ使用状況を確認できます。ollama ps には、読み込まれたモデル、メモリ上で占有しているサイズ、PROCESSOR 列が表示されます。100% GPU は、モデル全体が VRAM に収まっていることを示します。100% CPU は、モデルが VRAM にまったく収まらず、すべてのトークンをシステム RAM 上でプロセッサが計算していることを示します。65%/35% CPU/GPU のように分割されている場合、すべてのレイヤーが収まっておらず、CPU の使用割合が処理速度を左右します。必要量を推測しないでください。モデルを読み込み、この行を確認します。
まったく読み込めない場合、Ollama はクラッシュせずに正常に拒否します。
Error: model requires more system memory (28.4 GiB) than is available (15.6 GiB)CPU のみの VPS で十分な速度が出ますか？
一般的な VPS には GPU がないため、すべての処理を CPU が担い、必要な重みを system RAM から読み出します。MoE はこの点で有利です。30 billion 個のパラメーターのうち、1 token あたり実際に処理されるのは約 3 billion 個だけなので、token あたりの演算量は dense 30B モデルより大幅に少なくなります。ただし、メモリ使用量はまったく減りません。router はどの token に対しても任意の expert を選択できるため、30 billion 個すべてのパラメーターをメモリ上に保持する必要があります。
そのため、このモデルの CPU のみの推論は、コア数よりもメモリ帯域幅に制約されます。すでに十分な vCPU 数があるプランでは、vCPU を追加しても速度はほとんど変わりません。必要なのは、重みと KV cache を保持できるだけの RAM と、プランで提供される最速のメモリです。
agent で使用する前に、ローカル LLM の token/秒を測定する方法を使って速度を測定してください。
ollama run --verbose nemotron-3.5-lightning:30b-a3b-q4_K_M "Write a 200 word summary of TCP slow start."最後に出力される eval rate の行が、token/秒単位の生成速度です。この数値だけで判断できます。agent の経過時間は、主にこの速度で決まるためです。想定する返信の長さを掛けて、待てる時間を超える場合は、num_predict で出力を制限することが、ハードウェアを変更せずに単一の呼び出し時間を制限する方法です。
The data behind this chart
[
{
"label": "Nemotron 3.5 Lightning",
"sec_per_task": 30
},
{
"label": "gpt-oss-120b",
"sec_per_task": 204
},
{
"label": "Qwen3.6 35B",
"sec_per_task": 210
}
]これらは公開されている第三者の測定値です。Artificial Analysis がリリース時に報告したタスクごとの所要時間を換算したもので、VPS ではなくホスト型 GPU エンドポイントで測定されています。Nemotron 3.5 Lightning のタスクあたりの平均所要時間は約 30 秒でした。gpt-oss-120b は約 204 秒、Qwen3.6 35B は約 210 秒でした。これらは差の大きさを把握するために使い、自分のハードウェアで同じ結果が出る保証とは考えないでください。
実際の判断は、誰が待つのかで分かれます。人が agent の応答を待つ場合や、agent が長い呼び出しを連続して実行する場合は、GPU の計算資源を借りるべきです。夜間にスケジュール実行し、誰も監視しない場合は、大容量 RAM の CPU プランが妥当です。いずれの場合もセットアップは同じです。VPS で Ollama を実行するでは、必要なプラン容量と、GPU インスタンスを API プロバイダーに token 単位で支払う場合との比較を説明しています。損益分岐点は利用率で決まります。GPU インスタンスは存在する間、毎時間課金されますが、API の token は使用時だけ課金されます。そのため、1 日の大半で稼働する agent には自前のインスタンスが有利ですが、1 時間に 2 回だけ実行する agent には通常適していません。
1M のコンテキストウィンドウは無料ではない
1M トークンはモデルの最大値であり、Ollama がデフォルトで割り当てる値ではありません。Ollama はデフォルトでは、はるかに小さいウィンドウを使用します。会話がその上限を超えると、古いトークンから削除されます。このときログには何も記録されません。そのため、エージェントから見ると、モデルが自分のタスクの冒頭を忘れたように見えます。
ウィンドウサイズは意図的に設定してください。サーバー全体に適用する場合は、サービスを編集します。
sudo systemctl edit ollama次の設定を追加し、その後 sudo systemctl restart ollama を実行します。
[Service]
Environment="OLLAMA_CONTEXT_LENGTH=32768"リクエスト単位で設定する場合は、代わりに options オブジェクトへ num_ctx を渡します。
curl http://localhost:11434/api/chat -d '{
"model": "nemotron-3.5-lightning:30b-a3b-q4_K_M",
"messages": [{"role": "user", "content": "Say ready"}],
"options": {"num_ctx": 32768},
"stream": false
}'ウィンドウを拡大するたびにメモリ使用量が増えます。許可するトークン数に応じて KV cache が拡大するためです。値を増やして再起動し、もう一度 ollama ps を実行して、表示されるサイズが増えることを確認します。その変更後に PROCESSOR 列が 100% GPU から split に変わった場合、KV cache によってモデルのレイヤーが VRAM から追い出されています。この状態では速度が大幅に低下します。Ollama での num_ctx の選択では、このトレードオフを詳しく説明しています。モデルカードで許可されているからといって、1000000 を設定しないでください。割り当ては起動時に行われるため、ロード自体が失敗します。
常時稼働エージェントへの組み込み
Ollama のこのモデルに関するリリース記事には、対応するエージェントをモデルに接続した状態で起動するショートカットが記載されています。
ollama launch claude --model nemotron-3.5-lightning記事では、この位置に claude、opencode、openclaw、hermes が記載されています。このサブコマンドには現行の Ollama が必要です。まず ollama --version を確認し、見つからない場合は自分でエージェントを API に接続します。Ollama は OpenAI 互換エンドポイントを提供しており、ほとんどのエージェント実行基盤で利用できます。
export OPENAI_BASE_URL=http://localhost:11434/v1
export OPENAI_API_KEY=ollamaOllama はキーを無視しますが、多くのクライアントはキーが設定されていないと起動しません。実行基盤側の設定については、コーディングエージェントを Ollama に接続する と 独自の OpenClaw エージェントを構築する で説明しています。
エージェントを無人で実行する場合は、2 つのサーバー設定が重要です。OLLAMA_KEEP_ALIVE は、最後のリクエスト後にモデルをメモリへ保持する時間を制御します。デフォルトでは 5 分後にアンロードされるため、次の呼び出しでは再び完全なロード時間が発生します。GPU のない 25 GB ファイルでは、この待ち時間によってタイムアウトする可能性があります。OLLAMA_KEEP_ALIVE=-1 を設定して、モデルをメモリに保持します。OLLAMA_HOST=0.0.0.0:11434 を設定すると他のマシンから API に接続できますが、認証機能は一切ありません。そのため、ファイアウォールルールまたはプライベートネットワークの内側でのみ公開してください。
失敗する場合と表示される文字列
pull がすぐに失敗します。 Error: pull model manifest: file does not exist は、そのタグが存在しないことを示します。タグ名は完全一致する文字列です。推測で量子化サフィックスを付けず、ライブラリページからタグをコピーしてください。
モデルを読み込めません。 Error: model requires more system memory (28.4 GiB) than is available (15.6 GiB) は、現在の設定ではこのプランに対してタグが大きすぎることを示します。より小さい量子化に変更するか、OLLAMA_CONTEXT_LENGTH を小さくしてください。この要件には KV キャッシュも含まれます。
ポート 11434 で応答がありません。 curl: (7) Failed to connect to localhost port 11434 は、サービスが起動していないか、想定した場所で待ち受けていないことを示します。systemctl status ollama と journalctl -u ollama -n 50 を確認してください。手動で ollama serve も起動している場合、2 つ目のプロセスは Error: listen tcp 127.0.0.1:11434: bind: address already in use で終了します。
応答はありますが、非常に遅いです。 変更を加える前に ollama ps を確認してください。GPU を搭載したマシンで PROCESSOR 列に CPU の使用割合が表示されている場合、モデルの一部が VRAM に収まらず、CPU 側へ移されています。コンテキストを小さくするか、より小さい量子化を使用してください。GPU のないマシンでは、遅いことが想定される動作であり、設定変更で改善することはできません。
エージェントがタスクの途中で指示を忘れます。 会話がコンテキストウィンドウの上限を超え、古いトークンが通知なく破棄されています。OLLAMA_CONTEXT_LENGTH を大きくし、ollama ps でモデルが引き続き収まることを確認してください。収まらなくなった場合は、ウィンドウを小さくするのではなく、より大きなマシンを使用する必要があります。
このモデルを他の選択肢と比較した位置付け
小規模な用途で運用するには、30B MoE は大きすぎます。密な 8B モデルでタスクを処理できるなら、実行コストは大幅に下がり、数秒で読み込めます。この判断を直接比較するには、VPS 上での 8B と 27B の Qwen 3 を参照してください。利用するプランで実際にどのモデルを収容できるかを広く確認するには、まず セルフホストできる AI モデル を確認してください。1 つのエージェントではなく複数のエージェントに同時にサービスを提供する予定なら、先に Ollama と vLLM の比較 を読んでください。Ollama は本番用の推論サーバーのように同時リクエストをバッチ処理しないため、単一ユーザー構成ではこの点がスケールの限界になります。
FAQ
Linux VPS では、Nemotron 3.5 Lightning のどのタグを pull すべきですか？
nemotron-3.5-lightning:30b-a3b-q4_K_M を使用してください。サイズは 25 GB で、最大 1M のコンテキストに完全対応しています。また、2026年8月時点では latest、30b、30b-a3b の各タグが指すものと同じ digest です。latest を pull するのではなく、タグ名を明示してください。そうすれば、将来このポインターが再公開されても、気付かないうちにエージェントの動作が変わることを防げます。mlx のタグは Apple silicon 向けのビルドなので、Linux では使用できません。
Nemotron 3.5 Lightning には、どの程度の RAM が必要ですか？
NVIDIA は Ollama ビルドの最小メモリ量を公開していないため、見積もりではなく実測してください。タグを pull してモデルを1回実行し、ロード中に ollama ps を確認します。実際に使用しているサイズと、GPU または CPU のどちらに配置されたかが表示されます。デフォルトタグのダウンロードサイズである 25 GB は最低限の目安です。これに加えて KV cache が必要になり、設定したコンテキストウィンドウに応じて増加します。プランの容量が不足すると、Ollama は model requires more system memory を出力し、両方の数値を示して失敗します。
GPU のない VPS で Nemotron 3.5 Lightning を実行できますか？
はい。モデルの重みを保持できる RAM がプランにあれば実行できます。MoE 構成では、30 billion 個のパラメーターのうち、1トークンの計算に使用するのは約 3 billion 個だけなので、この点でも有利です。ただし、速度が問題になります。GPU がない場合、モデルはメモリ帯域幅によって制限されるため、vCPU を増やしても結果はほとんど改善しません。固定したプロンプトで ollama run --verbose を実行し、eval rate の行を確認して、その数値をエージェントの処理期限と比較してください。一晩かけて実行するバッチジョブなら、問題ないことが多いです。人が応答を待つ処理では、通常は適していません。
Ollama で完全な 1M コンテキストウィンドウを使用できないのはなぜですか？
1M はモデルの最大値であり、Ollama のデフォルト値ではありません。Ollama はこれより大幅に小さいウィンドウを適用します。会話がその範囲を超えると、エラーを出力せずに古いトークンを破棄するため、エージェントが自分の指示を忘れたように見えます。systemd サービスに OLLAMA_CONTEXT_LENGTH を設定するか、リクエストごとに num_ctx を渡してください。設定値は段階的に増やし、その都度 ollama ps を再確認してください。KV cache のメモリ使用量はウィンドウサイズに応じて増加し、モデルのレイヤーが GPU から追い出される可能性があります。
Nemotron 3.5 Lightning は商用利用できますか？
NVIDIA の model card では、モデルは OpenMDW-1.1 license の下で提供され、商用利用可能とされています。これは、自分でダウンロードして実行する重みに適用されます。スタック内の他のソフトウェアについては説明されていないため、エージェントハーネスや接続するツールのライセンスは個別に確認してください。また、契約に関係する用途で依拠する前に、最新の model card を確認してください。