[DGX Spark] 從開箱到跑起來：完整部署指南

白話版：架一台自己的 AI 伺服器

你買了一台可以在本地跑 AI 模型的桌上型電腦 — 跟 ChatGPT 背後用的是同類模型，但跑在你桌上、不需要雲端費用、資料不會離開你的網路。問題是「AI 工作站」的文件預設你已經知道自己在幹嘛。

這篇假設你不知道。從插電源線到選哪個 AI 模型、為什麼選它，兩條路線：5 分鐘快速上手（實驗用），以及正式的 production 部署（always-on agent 用）。每個指令都是在這台硬體上實測過的，包含官方文件不會告訴你的坑。

如果你是帶著特定問題來的（過熱、推論很慢、崩潰），底部的系列索引會指向對的文章。

---

前言

新機器沒有部署指南，就是一箱放在桌上的位能，什麼都不做。從「開得了機」到「能跑有用的推論」之間，就是大部分人週末消失的地方。

這是我收到 ASUS Ascent GX10 時希望存在的文章。不是 benchmark（那是 Part 1），不是某個模型的深入分析（那是 Part 2-14），而是從密封箱到能用的推論端點之間的直線。

---

Day 1：硬體檢查（第一步就做這個）

Step 1：供電驗證

有些 DGX Spark 出廠就帶 PD 控制器缺陷，會把功率鎖在 30W。機器正常開機、正常跑，只是慢到不行。先查這個。

開機，開終端機：

# 先跑任何 GPU 運算（簡單的矩陣相乘就行）
python3 -c "import torch; x = torch.randn(4096, 4096, device='cuda'); y = x @ x; print('GPU works')"

# 然後看功耗
nvidia-smi --query-gpu=power.draw,utilization.gpu,clocks.sm --format=csv,noheader

正常：

35.65 W, 96 %, 2522 MHz

有問題（30W 安全模式）：

4.80 W, 2 %, 2411 MHz

如果看到第二種，停在這裡。這是硬體缺陷，要 RMA — 再怎麼改軟體都沒用。詳見完整診斷指南。

Step 2：驅動和 CUDA 版本

nvidia-smi

需要：

• Driver: 580.x 或更新
• CUDA: 13.0 或更新

舊驅動（550.x + CUDA 12.4）有另一個 bug，會讓 GPU 顯示 5W/0% 利用率。這個可以升級驅動修好。

Step 3：確認 GPU 身分

nvidia-smi --query-gpu=name,compute_cap,memory.total --format=csv,noheader

預期：

NVIDIA GB10, 12.1, 128 GB

Compute capability 12.1 就是 SM121 — 跟 SM100（GB200）和 SM89（RTX 4090）不一樣。很多 CUDA kernel 還不支援 SM121。這在選軟體時很重要（Ollama 內建支援；vLLM 要用 cu130-nightly）。

---

路線 A：Ollama（5 分鐘到第一次推論）

Ollama 是最快跑起來的路。一個安裝，一行指令。

安裝

curl -fsSL https://ollama.com/install.sh | sh

跑第一個模型

ollama run qwen3-coder-next

會下載一個 ~20 GB 的模型然後開互動聊天。第一次跑要等幾分鐘下載；之後幾秒就啟動。

為什麼先 Ollama？

• 在 GB10（SM121）上開箱即用
• 不需要 Docker、設定檔、flags
• 適合快速試不同模型
• /api/chat endpoint 跟 OpenAI API 夠相容，大部分工具能用

Ollama 的限制（為什麼最終要搬到 vLLM）

• 沒有 prefix caching：每次 request 都重新處理整個 system prompt。長 prompt 的 TTFT 要 2-4 秒。
• 沒有 NVFP4：Ollama 用 GGUF 量化（Q4_K_M、Q8_0）。vLLM 的 NVFP4 在同模型上快 30%。
• KEEP_ALIVE 陷阱：Ollama 預設保留模型在記憶體 2 小時。在統一記憶體上，這會擋住 vLLM 啟動。

實驗和快速測試用 Ollama 完美。Production agent 工作用 vLLM。

---

路線 B：vLLM（正式部署）

vLLM 是 production 推論引擎。設定多一點，但光 prefix caching 就足以讓 always-on agent 值得搬過來。

前置作業

# 安裝 Docker（如果沒有）
sudo apt-get update && sudo apt-get install -y docker.io nvidia-container-toolkit
sudo systemctl restart docker

# 驗證 Docker 能看到 GPU
docker run --rm --gpus all nvidia/cuda:13.0-base nvidia-smi

下載模型

pip install "huggingface_hub[cli,hf_transfer]"

# Qwen3.5-35B — agent 的主力馬
HF_HUB_ENABLE_HF_TRANSFER=1 hf download Qwen/Qwen3.5-35B-A3B-FP8 \
  --local-dir ~/models/qwen35-35b-hf

HF_HUB_ENABLE_HF_TRANSFER=1 啟用 Rust 傳輸後端 — 下載大檔案明顯更快。

啟動 vLLM 之前：先卸載 Ollama

Ollama 可能還把模型留在 128 GB 共用記憶體裡。vLLM 啟動時會 OOM。

# 看 Ollama 載了什麼
curl -s http://localhost:11434/api/ps

# 卸載
curl -s -X POST http://localhost:11434/api/generate \
  -d '{"model": "MODEL_NAME", "keep_alive": 0}'

能用的 Docker 指令

docker run -d --name qwen35 --restart unless-stopped \
  --gpus all --ipc host --shm-size 64gb -p 8000:8000 \
  -v ~/models/qwen35-35b-hf:/models/qwen35 \
  vllm/vllm-openai:cu130-nightly \
  --model /models/qwen35 \
  --served-model-name qwen3.5-35b \
  --max-model-len 200000 \
  --gpu-memory-utilization 0.90 \
  --max-num-batched-tokens 4096 \
  --enable-prefix-caching \
  --reasoning-parser qwen3 \
  --enable-auto-tool-choice \
  --tool-call-parser qwen3_coder

關鍵注意事項：

• 用 cu130-nightly，不是 stable。Stable 不支援 GB10/SM121。
• 不要加 --enable-chunked-prefill — 在 SSM+MoE 模型上會造成 9 倍效能衰退。
• 不要加 --kv-cache-dtype fp8 — 在 GB10 上會造成輸出重複迴圈。

冷啟動要 2-3 分鐘（模型載入 + torch.compile + FlashInfer 自動調校）。看 log：

docker logs -f qwen35

看到 vLLM engine started 就代表可以用了。

驗證

# 健康檢查
curl -s http://localhost:8000/health

# 測試推論
curl -s http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "qwen3.5-35b",
    "messages": [{"role": "user", "content": "你好，我在什麼硬體上？"}],
    "chat_template_kwargs": {"enable_thinking": false}
  }'

chat_template_kwargs 是 Qwen3.5 必要的 per-request 設定，用來關閉 thinking mode。無法在 server 端設定。

---

該跑哪個模型？

取決於用途和硬體。決策樹：

在 DGX Spark 上（128 GB, 273 GB/s）

用途	模型	Runtime	速度	為什麼
Agent 工作	Qwen3.5-35B-A3B FP8	vLLM	47 tok/s	Tool calling 最強，SSM hybrid 長 context 穩定
視覺任務	Gemma 4 26B-A4B NVFP4	vLLM	52 tok/s	多模態，只佔 16 GB — 有空間跑其他模型
快速實驗	任何模型	Ollama	看模型	一行指令，不需要設定
最大能力	gpt-oss-120B MXFP4	vLLM	~40 tok/s	120B 參數，128 GB 裝得下

速度門檻原則

聰明比速度重要 — 但有一個可用門檻。大約 ~15-20 tok/s 是互動使用的底線。低於這個，再聰明也會被等待的挫折感抵消。

在 DGX Spark 上，31B Dense 只有 7 tok/s — 低於門檻。選 MoE 版本。在 RTX 5090 上，同一個 31B Dense 跑 62 tok/s — 遠超門檻，讓它成為最聰明的舒適選擇。

四個 Gemma 4 版本在三台機器上的完整比較：全家桶指南

---

5 個沒人預先告訴你的坑

這些是會讓你浪費整天的陷阱。每個都有連結到完整文章。

1. 供電缺陷

有些批次的機器永久鎖在 30W。看起來像軟體問題。其實是硬體。完整診斷 →

2. 統一記憶體是共用的

Ollama 和 vLLM 搶同一個 128 GB 池子。nvidia-smi 顯示記憶體 N/A — 要用 vLLM 的 /metrics endpoint 查。詳情 →

3. SM121 不是 SM100

GB10 的 compute capability（SM121）跟 GB200（SM100）不同。很多 CUDA kernel 不支援。這就是為什麼 vLLM 要用 cu130-nightly，也是為什麼 llama.cpp 在這台機器上會 crash。

4. FP8 KV Cache 會造成重複

加 --kv-cache-dtype fp8 看起來是免費的記憶體優化。在 GB10 上，會因為缺少 calibration data 導致輸出在 ~500 token 後退化成重複迴圈。根因 →

5. Chunked Prefill 會殺掉 SSM 模型

--enable-chunked-prefill 是 Transformer 模型的標準 vLLM 優化。在 SSM+MoE 混合模型（Qwen3.5、Mamba 架構）上，會造成 9 倍效能衰退。分析 →

---

這次的收穫

最短路線：安裝 Ollama → ollama run qwen3-coder-next → 5 分鐘內出推論。不需要 Docker、不需要 flags、不需要設定。

Production 路線：vLLM 用 cu130-nightly → prefix caching 讓 TTFT 從 2-4s 降到 0.12s → agent 工作變得有反應。

診斷：所有事情之前先跑一次 nvidia-smi。如果負載下功耗顯示 5W，就不要再查軟體了。

---

深入閱讀

上面每個段落背後都有完整文章：

主題	文章
模型 benchmark（8 個模型）	Part 1: 找最佳組合
Ollama → vLLM 搬家	Part 2: Qwen3.5 跑 47 tok/s
120B 模型部署	Part 3: Nemotron-120B 踩坑日誌
FP8 KV cache bug	Part 5: 重複迴圈
供電/散熱診斷	Part 6: 30W 安全模式
Gemma 4 選型	Part 14: 全家桶指南
vLLM vs Ollama 速度差	Part 8: 為什麼快 30%