著者 Nemotron 3.5 LightningをVPSで動かす方法
OllamaでNemotron 3.5 Lightningを自分のVPSに導入します。取得する正確なタグ、必要なRAM容量、CPUのみで実用的な速度が出るかを確認できます。
Nemotron 3.5 Lightning の用途
Nemotron 3.5 Lightning は、NVIDIA が 2026 年 8 月にリリースした、オープンな 300 億パラメータの mixture-of-experts モデルです。1 つのチャットウィンドウで使うのではなく、数時間にわたって実行するエージェント向けに設計されています。MoE（mixture of experts）は、重みを多数のエキスパートサブネットワークに分割し、各トークンをそのうち少数のネットワークだけに通す方式です。NVIDIA のモデルカードでは、総パラメータ数を 300 億、トークンごとのアクティブパラメータ数を 30 億としています。メモリには大きい方の数が必要です。速度には小さい方の数が効きます。
このトレードオフが、レンタルサーバーでこのモデルを検討する理由です。実際の処理を行うエージェントは、1 日に数千回の短いリクエストを送信します。そのため、エージェントを自分のサーバーで運用できるかどうかは、費用あたりのスループットで決まります。1 回の応答に 40 秒かかるモデルは、アシスタントとしては使えても、エージェントには適しません。1 つのタスクで 20 回呼び出し、毎回完了を待つことになるためです。
NVIDIA は、このアーキテクチャをハイブリッド方式と説明しています。Mamba-2 層と MoE 層を交互に配置し、一部に attention 層を使用します。モデルカードでは、最大コンテキスト長を最大 1M トークン、ライセンスを OpenMDW-1.1 としており、商用利用に対応していると記載されています。主な対応言語は英語とコードです。スペイン語、フランス語、ドイツ語、イタリア語、日本語も対応言語として挙げられています。
Artificial Analysis は 2026 年 8 月のリリース時の測定結果として、NVFP4 の重みを提供するリリース前の DeepInfra エンドポイントで、出力速度が毎秒約 670 トークンに達したと報告しています。これはホスト型 GPU エンドポイントでの結果です。自分の VPS で得られる性能ではなく、このアーキテクチャが発揮し得る性能として捉えてください。
どの VPS にどの Ollama タグが適しているか
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 の 4 ビットビルドで、サイズは 25 GB です。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 は移動するポインターです。ライブラリが latest を再公開すると、メモに変更理由が残らないまま、次回の pull でエージェントの動作が変わります。タグを明示してください。
curl -fsSL https://ollama.com/install.sh | sh
ollama --version
ollama pull nemotron-3.5-lightning:30b-a3b-q4_K_Mインストールスクリプトは、ollama ユーザーで実行する systemd サービスを設定し、モデルを /usr/share/ollama/.ollama/models に保存します。ほとんどの VPS イメージでは、このパスが root ファイルシステム上にあります。そのため、25 GB を要求する前に空き容量を確認してください。
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 が実行し、必要な重みをシステム RAM から読み出します。MoE はこの点で有利です。30 billion のパラメーターのうち、1 token あたりで参照されるのは約 3 billion だけなので、1 token あたりの演算量は dense 30B model より大幅に少なくなります。ただし、メモリ使用量は減りません。router は任意の token に対して任意の expert を選べるため、30 billion のパラメーターをすべてメモリ上に保持する必要があります。
そのため、この model の CPU-only inference は、core 数ではなく memory bandwidth に制限されます。すでに vCPU が妥当な数ある plan に vCPU を追加しても、性能はほとんど変わりません。必要なのは、weights と KV cache を保持できる十分な RAM と、plan で提供される最速のメモリです。
agent で使用する前に、ローカル LLM の tokens per second の測定に記載されている方法で測定してください。
ollama run --verbose nemotron-3.5-lightning:30b-a3b-q4_K_M "Write a 200 word summary of TCP slow start."末尾に表示される eval rate の行が、1 秒あたりの生成 tokens 数です。この 1 つの数値で判断できます。agent の wall-clock time は、主にこの数値で決まるためです。
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 endpoint で測定されています。Nemotron 3.5 Lightning は、1 task あたり平均 30 秒でした。gpt-oss-120b は約 204 秒、Qwen3.6 35B は約 210 秒でした。これらは差の大きさを把握するために使用し、使用する hardware で同じ結果が出る保証とは考えないでください。
誰が待つのかによって、適切な判断は変わります。人が agent の処理を待つ場合や、agent が長い call chain を連続して実行する場合は、GPU capacity を借りてください。夜間に schedule で実行し、誰も処理を監視しない場合は、大容量 RAM の CPU plan が妥当です。どちらの場合も setup は同じです。VPS で Ollama を実行する方法では、plan のサイズの決め方と、token 単位で API provider に支払う場合と GPU instance を使用する場合の比較を説明しています。損益分岐点は利用率の問題です。GPU instance は存在するすべての時間に対して課金されますが、API token は使用したときだけ課金されます。そのため、1 日の大半で稼働する agent には自分で所有する instance が向いており、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 キャッシュも大きくなるため、ウィンドウを拡大するたびにメモリを消費します。値を増やして再起動し、もう一度 ollama ps を実行して、表示されるサイズが増えることを確認してください。その変更後に PROCESSOR 列が 100% GPU から split に変わった場合、KV キャッシュによってモデルのレイヤーが 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 は、そのタグが存在しないことを示します。タグ名は完全一致する文字列です。推測で量子化のサフィックスを付けず、library ページからタグをコピーしてください。
モデルを読み込めない場合。 Error: model requires more system memory (28.4 GiB) than is available (15.6 GiB) は、現在の設定ではそのタグがこのプランに対して大きすぎることを示します。より小さい量子化に変更するか、KV cache もこの要件に含まれるため OLLAMA_CONTEXT_LENGTH を下げてください。
port 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 からあふれています。そのため、コンテキストを短くするか、より小さい量子化を使用してください。GPU のないマシンでは、遅いのが想定される結果であり、設定で改善することはできません。
エージェントがタスクの途中で指示を忘れる場合。 会話がコンテキストウィンドウの上限を超え、古いトークンが通知なく破棄されています。OLLAMA_CONTEXT_LENGTH を増やし、ollama ps でモデルが引き続き収まることを確認してください。収まらなくなった場合は、ウィンドウを小さくするのではなく、より大きなマシンを使用する必要があります。
代替候補との位置付け
小規模な用途でホストするには、30B MoE は大規模です。密な 8B モデルでタスクに対応できるなら、実行コストを大幅に抑えられ、数秒でロードできます。この判断を直接比較するには、VPS 上での Qwen 3 の 8B と 27B を参照してください。特定のプランで実際にどのモデルまで実行できるかを広く確認するには、セルフホスト可能な 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 キャッシュが確保され、設定したコンテキストウィンドウに応じて増加するためです。プランの容量が不足すると、Ollama は model requires more system memory を返し、両方の容量を表示します。
GPU のない VPS で Nemotron 3.5 Lightning を実行できますか？
モデルの重みを収容できるだけの RAM がプランにあれば実行できます。MoE 方式では、1 トークンあたり約 3000000000 個のパラメーターだけを計算するため、この点でも有利です。問題は速度です。GPU がない場合、モデルの性能はメモリ帯域幅に制限されるため、vCPU を増やしても結果はほとんど改善しません。固定したプロンプトで ollama run --verbose を実行し、eval rate の行を確認して、その値をエージェントの許容時間と比較してください。夜間のバッチ処理であれば、多くの場合は問題ありません。人が応答を待つ用途では、通常は適していません。
Ollama で 1M の完全なコンテキストウィンドウを使用できないのはなぜですか？
1M はモデルの最大値であり、Ollama のデフォルト値ではありません。Ollama はこれより大幅に小さいウィンドウを適用します。会話がその範囲を超えると、エラーを表示せずに古いトークンを破棄するため、エージェントが自身の指示を忘れたように見えます。systemd サービスに OLLAMA_CONTEXT_LENGTH を設定するか、リクエストごとに num_ctx を渡してください。値は段階的に引き上げ、そのたびに ollama ps を確認します。KV キャッシュのメモリ使用量はウィンドウの大きさに応じて増加し、モデルのレイヤーが GPU から追い出される可能性があるためです。
Nemotron 3.5 Lightning は商用利用できますか？
NVIDIA のモデルカードでは、このモデルを OpenMDW-1.1 ライセンスの下に置き、商用利用可能としています。これは、自分でダウンロードして実行する重みに適用されます。ただし、スタック内の他のソフトウェアについては何も定めていません。そのため、エージェントハーネスと接続するツールのライセンスは個別に確認してください。契約に関わる用途で利用する前に、最新のモデルカードも確認してください。