作者： Nemotron 3.5 Lightning VPS 部署與 Ollama 教學
了解如何在自有 VPS 以 Ollama 執行 NVIDIA Nemotron 3.5 Lightning，包含正確 tag、RAM 需求，以及僅用 CPU 是否足以提供可用速度。
Nemotron 3.5 Lightning 的用途
Nemotron 3.5 Lightning 是 NVIDIA 開放的 30B 混合專家模型，於 2026 年 8 月發布，專為可連續執行數小時的 agent 設計，而不是只處理單一聊天視窗。MoE（mixture of experts）表示模型權重分散在多個專家子網路中，每個 token 只會經過其中少數幾個子網路。NVIDIA 的 model card 指出，模型共有 30 billion 個參數，每個 token 實際啟用 3 billion 個參數。記憶體需求取決於較大的總參數量，處理速度則受較小的啟用參數量影響。
這項取捨正是租用伺服器時值得考慮此模型的原因。執行實際工作的 agent 一天會送出數千個簡短請求，因此每美元的吞吐量會決定它是否適合部署在自己的主機上。每次回覆需要 40 秒的模型可以作為一般助理使用，但不適合作為 agent，因為單一工作可能需要呼叫 20 次，而且每次都必須等待。
NVIDIA 將此架構描述為混合式架構：交錯使用 Mamba-2 與 MoE 層，並搭配特定的 attention 層。model card 指出，最大 context length 可達 1M tokens，並採用 OpenMDW-1.1 license，標示為可用於商業用途。主要語言為 English 與 code，另外也列出 Spanish、French、German、Italian 和 Japanese。
Artificial Analysis 在 2026 年 8 月發布的上線測試顯示，使用提供 NVFP4 weights 的預發布 DeepInfra endpoint 時，輸出速度接近每秒 670 個 token。這是代管的 GPU endpoint。應將這項數據理解為該架構可能達到的效能，而不是你的 VPS 實際能達到的效能。
哪個 Ollama tag 適合哪種 VPS
Ollama library 會針對相同的權重發布多個 build。它們的差異在於 quantisation，也就是每個權重使用多少 bit 儲存；這會大幅影響下載大小。
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 的 tag 都解析至與 30b-a3b-q4_K_M 相同的 digest，因此預設下載內容是 25 GB 的四 bit build，並完整支援 1M context。Q8_0 為 35 GB，bf16 為 66 GB，兩者同樣支援 1M context。大小為 23 GB 的 MLX build 適用於 Apple silicon，context 上限為 256K，因此不適合 Linux VPS。
這些是下載大小，不是記憶體需求。NVIDIA 沒有公布 Ollama build 所需的最低 VRAM（video RAM），因此只能將下載大小視為下限，不能作為其他判斷。權重必須常駐於某處：如果 GPU 能容納，就會放在 GPU memory；否則會放在 system RAM。此外還會加上 KV cache（key/value cache，也就是模型針對對話內容所維持的逐 token 記憶體）。你的硬體實際需要多少記憶體，必須透過下方的 command 取得，不能只靠計算。如果你尚未決定 quantisation level，Q4、Q8 和 FP16 各自需要犧牲什麼 會說明每個階段的取捨。
請拉取確切標籤，絕不要使用 latest
latest 是會移動的指標。程式庫重新發布該標籤後，agent 下一次拉取時的行為就會改變，而你的筆記中沒有任何原因可供追查。請指定標籤。
curl -fsSL https://ollama.com/install.sh | sh
ollama --version
ollama pull nemotron-3.5-lightning:30b-a3b-q4_K_M安裝指令碼會建立 systemd 服務，讓服務以 ollama 使用者身分執行，並將模型存放在 /usr/share/ollama/.ollama/models。在大多數 VPS 映像檔中，該路徑位於 root 檔案系統，因此在要求 25 GB 空間前，請先確認剩餘容量。
df -h /usr/share/ollama拉取作業中途停止並回報 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"模型仍載入期間，請在第二個 shell 中執行：
ollama ps這個指令會直接回答該模型在您機器上的記憶體使用情況。ollama ps 會顯示已載入的模型、模型占用的記憶體大小，以及 PROCESSOR 欄位。100% GPU 表示模型全部位於 VRAM。100% CPU 表示模型完全不在 VRAM，所有 token 都由處理器使用系統 RAM 計算。像 65%/35% CPU/GPU 這樣的分配表示所有層無法全部容納，CPU 所占比例會決定速度。不要估算需求。直接載入模型，讀取這一行。
如果完全無法載入，Ollama 會正常拒絕，而不是當機：
Error: model requires more system memory (28.4 GiB) than is available (15.6 GiB)CPU-only VPS 的速度是否足夠？
一般用途的 VPS 沒有 GPU，因此所有工作都由 CPU 處理，並從系統 RAM 讀取所需的每個權重。MoE 在這方面有所幫助，因為每個 token 只會使用約 3 billion 個參數，而不是 30 billion 個參數，因此每個 token 所需的運算量遠低於 dense 30B 模型。不過，記憶體需求完全不會降低。所有 30 billion 個參數都必須常駐記憶體，因為 router 可能為任何 token 選取任何 expert。
因此，此模型在 CPU-only 推論時，瓶頸是記憶體頻寬，而不是核心數量。對於已經配置合理 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 的實際經過時間主要取決於它。
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 在發布時回報的每項工作所需分鐘數換算而來；測量環境是代管的 GPU endpoint，而不是 VPS。Nemotron 3.5 Lightning 平均每項工作約需 30 秒，其中 gpt-oss-120b 約需 204 秒，Qwen3.6 35B 約需 210 秒。請將這些數據用於了解差距的幅度，不要視為你的硬體一定能達到的結果。
實際建議取決於等待者是誰。如果有人在等待 agent，或 agent 會連續執行很長的呼叫鏈，請租用 GPU 資源。如果它按照排程在夜間執行，且沒有人需要等待，大容量 RAM 的 CPU 方案就是合理選擇。無論採用哪種方式，設定流程都相同；在 VPS 上執行 Ollama 會說明方案容量規劃，以及 GPU instance 與按 token 支付 API provider 費用的比較。損益平衡取決於使用率：GPU instance 只要存在就會按小時計費，而 API token 只在使用時計費。因此，幾乎整天都忙碌的 agent 適合使用自有 instance；每小時只執行兩次的 agent 通常不適合。
1M context window 並非免費
1M tokens 是模型的上限，但 Ollama 預設不會提供完整大小。Ollama 會使用小得多的預設 window；當對話超過此上限時，會捨棄最早的 tokens。發生這種情況時不會留下任何 log，因此對 agent 而言，模型看起來像是忘記了自己任務的開頭。
請明確設定 window。若要套用至整台伺服器，請編輯服務：
sudo systemctl edit ollama加入以下內容，然後執行 sudo systemctl restart ollama：
[Service]
Environment="OLLAMA_CONTEXT_LENGTH=32768"若只套用至單一 request，請改在 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 會隨允許的 tokens 數量增加。提高數值並重新啟動後，再次執行 ollama ps，觀察顯示的大小上升。如果變更後 PROCESSOR 欄位從 100% GPU 變成 split，表示 KV cache 已將模型層推出 VRAM，速度會大幅下降。在 Ollama 中選擇 num_ctx 詳細說明了這項取捨。不要因為 model card 允許就直接設為 1000000，因為配置會在一開始就完成，載入會直接失敗。
將其接入常駐 agent
Ollama 的此模型發布文章記載了一個捷徑，可啟動已支援且預先指向此模型的 agent：
ollama launch claude --model nemotron-3.5-lightning該文章在此位置記載了 claude、opencode、openclaw 和 hermes。此子命令需要目前版本的 Ollama，因此請先檢查 ollama --version；如果不存在，請自行將 agent 指向 API。Ollama 提供與 OpenAI 相容的端點，大多數 agent harness 都能使用：
export OPENAI_BASE_URL=http://localhost:11434/v1
export OPENAI_API_KEY=ollamaOllama 會忽略此金鑰，但大多數用戶端若未設定金鑰就不會啟動。harness 端的設定請參閱 將 coding agent 指向 Ollama 及 建立自己的 OpenClaw agent。
agent 無人值守執行後，有兩項伺服器設定十分重要。OLLAMA_KEEP_ALIVE 控制模型在最後一個請求後於記憶體中保留多久；預設值會在五分鐘後卸載模型，因此下一次呼叫又必須支付完整的載入時間。對於大小為 25 GB 且未使用 GPU 的檔案，這段暫停時間可能長到造成 timeout。設定 OLLAMA_KEEP_ALIVE=-1，讓模型常駐記憶體。OLLAMA_HOST=0.0.0.0:11434 會讓其他機器也能連線至 API，而且完全不提供任何驗證機制，因此只能在防火牆規則或私有網路後方開放。
故障模式與可見訊息
拉取會立即失敗。 Error: pull model manifest: file does not exist 表示該標籤不存在。標籤名稱必須完全相符，因此請從 library 頁面複製標籤名稱，不要自行猜測量化後綴。
模型無法載入。 Error: model requires more system memory (28.4 GiB) than is available (15.6 GiB) 表示依目前設定，該標籤對此方案而言過大。請改用較小的量化版本，或降低 OLLAMA_CONTEXT_LENGTH，因為 KV cache 也會計入此需求。
11434 埠沒有任何回應。 curl: (7) Failed to connect to localhost port 11434 表示服務未執行，或未在預期的位置監聽。請查看 systemctl status ollama 與 journalctl -u ollama -n 50。如果你也曾手動啟動 ollama serve，第二個執行個體會因 Error: listen tcp 127.0.0.1:11434: bind: address already in use 而結束。
服務有回應，但速度非常慢。 進行任何變更前，先檢查 ollama ps。在 GPU 機器上，只要 PROCESSOR 欄位出現任何 CPU 使用量，就表示部分模型已溢出 VRAM，因此請降低 context，或改用較小的量化版本。在沒有 GPU 的機器上，速度慢是預期結果，無法透過設定修正。
代理程式在工作進行到一半時忘記指示。 對話已超過 context window，最早的 token 因此在未顯示通知的情況下被捨棄。請提高 OLLAMA_CONTEXT_LENGTH，再用 ollama ps 確認模型仍能載入。如果模型已無法載入，解法是使用更大的機器，而不是縮小視窗。
這個模型與其他選項的比較
對於小型工作負載而言，託管 30B MoE 模型需要較多資源。如果 8B dense 模型已能處理你的工作，執行成本會低得多，載入時間也只需幾秒；VPS 上的 Qwen 3 8B 與 27B 可直接比較這項選擇。若要更全面了解特定方案實際能容納哪些模型，請先參閱可自行託管哪些 AI 模型。如果你計畫同時提供多個 agent 的服務，而不是只服務單一 agent，請先閱讀Ollama 與 vLLM 的比較。這是因為 Ollama 不會像正式環境的推論伺服器那樣，對並行請求進行批次處理；單一使用者的架構也會在此限制下停止擴展。
FAQ
在 Linux VPS 上應該拉取哪個 Nemotron 3.5 Lightning 標籤？
請使用 nemotron-3.5-lightning:30b-a3b-q4_K_M。大小為 25 GB，支援完整的 1M 最大上下文，且截至 August 2026，這是 latest、30b 和 30b-a3b 標籤所指向的相同 digest。請明確指定此標籤，不要拉取 latest，以免未來重新發布該指標時，在你未察覺的情況下改變 agent 的行為。mlx 標籤是 Apple silicon 組建，在 Linux 上無法提供協助。
Nemotron 3.5 Lightning 需要多少 RAM？
NVIDIA 沒有公布 Ollama 組建的最低記憶體需求，因此應實際測量，不要估算。拉取標籤並執行模型一次，在模型載入期間讀取 ollama ps：它會顯示實際占用的大小，以及模型是載入 GPU 還是 CPU。預設標籤的下載大小為 25 GB，這只是最低需求，因為 KV cache 會另外占用記憶體，且會隨你設定的上下文視窗增長。如果方案太小，Ollama 會以 model requires more system memory 拒絕執行，並列出這兩個數值。
沒有 GPU 的 VPS 可以執行 Nemotron 3.5 Lightning 嗎？
可以，但方案必須有足夠的 RAM 來容納模型權重。MoE 架構也有所幫助，因為每個 token 只會計算約 30 billion 個參數中的 3 個。限制在於速度。沒有 GPU 時，模型效能受記憶體頻寬限制，因此增加 vCPU 幾乎不會改善結果。使用固定的 prompt 執行 ollama run --verbose，讀取 eval rate 行，再根據 agent 的期限評估該數值。對於夜間執行的批次工作，通常可以接受。對於需要由人員等待結果的工作，通常無法接受。
Ollama 為什麼不提供完整的 1M 上下文視窗？
1M 是模型的最大值，不是 Ollama 的預設值。Ollama 使用小得多的視窗；對話超過此限制後，它會捨棄最舊的 token，且不會輸出錯誤，因此看起來就像 agent 忘記了自己的指示。請在 systemd 服務上設定 OLLAMA_CONTEXT_LENGTH，或在每個請求中傳入 num_ctx。請逐步提高設定，並在每次變更後重新檢查 ollama ps，因為 KV cache 的記憶體用量會隨視窗大小增加，可能導致部分模型層移出 GPU。
Nemotron 3.5 Lightning 可以免費用於商業用途嗎？
NVIDIA 的 model card 將此模型置於 OpenMDW-1.1 授權條款下，並標示為可用於商業用途。這涵蓋你自行下載並執行的模型權重，但不涵蓋技術堆疊中的其他軟體。因此，請另外確認 agent harness 及其連接工具的授權條款；如果用途涉及合約，依賴這項資訊前也應閱讀目前版本的 model card。