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

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

想像你買了一整套專業廚房裝置送到家裡。東西全在箱子裡，沒人幫你安裝。說明書假設你是有十年經驗的主廚，但你只是想先煎個蛋看看能不能用。

DGX Spark 就是這種情境。硬體很強——跟 ChatGPT 背後用的是同類模型，跑在你桌上，不需要雲端費用，資料不會離開你的網路。但從插電到能用之間，有一段沒人寫好的路。這篇就是那段路的地圖。

兩條路線：五分鐘快速上手（先煎蛋），以及正式的 production 部署（開餐廳）。每個指令都是在這台硬體上實測過的。如果你是帶著特定問題來的——過熱、推論很慢、莫名 crash——底部的系列索引會指向對的文章。

---

前言

我收到 ASUS Ascent GX10 那天，開了機，看著桌面，然後意識到我完全不知道下一步是什麼。

官方文件有裝機指南，但沒有 deployment 指南。從「開得了機」到「能跑有用的推論」中間那段路，我花了一整個週末才走完。這篇是那個週末的筆記——不是 benchmark（那是 Part 1），不是某個模型的深入分析（那是 Part 2-14），是從密封箱到推論端點的最短路線。

---

第一天：先看硬體有沒有問題

收到機器，什麼軟體都不用裝，先跑三件事。我第一天沒先做這些，結果花了半天在查 vLLM 設定，最後才發現根本是硬體的問題。

先查供電

有些 DGX Spark 出廠就帶 PD 控制器缺陷，會把功率鎖在 30W。機器正常開機、正常跑，只是慢到不行——看起來像軟體問題，其實是硬體。

開機，開 terminal：

# 先跑任何 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——再怎麼改軟體都沒用。詳見完整診斷指南。

驅動和 CUDA

nvidia-smi

需要：

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

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

確認 GPU 身分

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

預期：

NVIDIA GB10, 12.1, 128 GB

這裡的 12.1 就是 SM121——跟 GB200 的 SM100 和 RTX 4090 的 SM89 不一樣。這個差異比你想的重要：很多 CUDA kernel 還不支援 SM121，所以 vLLM 要用 cu130-nightly（stable 版不行），llama.cpp 在這台上會直接 crash。選軟體之前要先知道這件事。

---

Ollama：五分鐘跑起來

第一天我只想看到模型能跑。Ollama 一行指令搞定。

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

裝完直接跑：

ollama run qwen3-coder-next

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

Ollama 在 GB10（SM121）上開箱即用，不需要 Docker 也不用寫設定檔，/api/chat endpoint 跟 OpenAI API 夠相容，大部分工具直接能串。拿來快速試不同模型很方便。

但 Ollama 有幾個限制，用久了會碰到。沒有 prefix caching——每次 request 都要重算整個 system prompt，長 prompt 的 TTFT 要 2-4 秒。跑 agent 的話這個延遲會快速累積。量化只有 GGUF（Q4_K_M、Q8_0），沒有 vLLM 的 NVFP4——同模型慢了 30%。還有一個 KEEP_ALIVE 陷阱：Ollama 預設把模型留在記憶體 2 小時。在 128 GB 統一記憶體上，這會擋住 vLLM 啟動——後面會講到我怎麼踩到這個。

實驗和快速測試用 Ollama 完美。我的 agent 需要 prefix caching，所以最後搬到了 vLLM。

---

vLLM：讓 agent 能用的部署

vLLM 設定比 Ollama 多不少，但光 prefix caching 就足以讓 always-on agent 值得搬過來——TTFT 從 2-4 秒降到 0.12 秒，結構性的差異。

vLLM 跑在 Docker 裡。如果還沒裝：

# 安裝 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 傳輸後端——下載大檔案明顯更快。

先解除安裝 Ollama

我第一次啟動 vLLM 直接 OOM。查了半天，原來是 Ollama 的 KEEP_ALIVE 還在佔記憶體——兩者搶的是同一個 128 GB 池子，而且 nvidia-smi 顯示記憶體是 N/A，看不出來被佔了多少。要用 vLLM 的 /metrics endpoint 才看得到。

# 看 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。這是 Transformer 模型的標準最佳化，但在 SSM+MoE 混合模型（Qwen3.5、Mamba 架構）上會造成 9 倍 throughput 衰退。50 tok/s 直接掉到 5.7。
• 不要加 --kv-cache-dtype fp8。看起來是免費的記憶體最佳化，但在 GB10 上因為沒有 calibration data，輸出會在 ~500 token 後崩成重複迴圈。128 GB 統一記憶體根本不缺空間，沒必要省。

冷啟動要 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 版本在三台機器上的完整比較：全家桶指南。

---

收穫

最花時間的地方

不是軟體設定——是供電缺陷的診斷。我花了大半天在查 vLLM 的 flag 和驅動版本，最後才回頭看 nvidia-smi 的功耗數字。硬體問題要先排除，不然後面所有 debug 都是白做。

可以複用的判斷方法

收到新機器，第一件事跑 GPU 負載看功耗。不是看它能不能開機——是看它跑負載時的瓦數對不對。第二件事：確認 compute capability。SM121 不等於 SM100，軟體支援是完全不同的世界，很多你在別台機器用的 flag 在這台會直接 crash。

記住這一件事

從 Ollama 到 vLLM 的遷移不難。難的是知道哪些 flag 不能加。加了不該加的 flag，server 照樣啟動，前幾條回應照樣正常，問題在後面才出現——500 token 後開始重複、throughput 莫名掉 9 倍。這篇列的坑全是這種「看起來沒問題」的類型。

---

深入閱讀

上面每段背後都有一篇完整的踩坑紀錄：

主題	文章
模型 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%