重點摘要
- 一台 DGX Spark 就夠當公司私密 AI 分身:USD 4,699、128GB 統一記憶體、全 CUDA、可離線(air-gapped)。
- 它的死穴是記憶體頻寬只有 273 GB/s——dense 70B 模型只跑 3–8 tok/s,慢到不能互動。
- 解法是 MoE 模型:gpt-oss-120B 約 55 tok/s、Qwen3.6 35B-A3B 約 97 tok/s,單台就順。
- 第二台反而更慢:兩台跑 Qwen3-235B 單流只有 11.7 tok/s,比單台的 120B 還差,且雙倍預算。
- Day 1 落地三步:Ollama(v0.14 起免 proxy)→ 拉 gpt-oss-120B → Claude Code 設
ANTHROPIC_BASE_URL指向它。
當公司有「資料不能上雲」的合規剛需,雲端 AI API 就直接出局,你需要一個跑在自己機房裡的私密 AI 分身。NVIDIA DGX Spark 是 2026 年最常被點名的桌上型候選,但「買幾台、跑哪個模型、到手後怎麼接上 Claude Code」這三個問題,網路上的行銷數字會誤導你。這篇用實測數據把它講清楚,並給出 Day 1 可照做的落地步驟。
延伸閱讀:如果你還在猶豫雲端訂閱、API、自架還是本地,先看 Claude 分流實戰:訂閱 / API / Foundry / 本地怎麼選 + 省 Token。
DGX Spark 是什麼?一台的真實規格
DGX Spark 是 NVIDIA 的桌上型 AI 主機,搭載 GB10 Grace Blackwell 晶片。它賣的不是「快」,而是「能在桌上塞下別人塞不下的大模型」。一台的核心規格如下。
| 項目 | 規格 |
|---|---|
| 晶片 | GB10 Grace Blackwell(CPU+GPU 整合) |
| 記憶體 | 128 GB LPDDR5x 統一記憶體 |
| 記憶體頻寬 | ⚠️ 僅 273 GB/s(真正的天花板) |
| 算力 | 約 1 PFLOP(FP4 稀疏)/ 1000 TOPS |
| 連接 | ConnectX-7 200GbE、4TB SSD |
| 價格(2026) | USD 4,699(2026/2 因記憶體短缺自 3,999 漲 18%) |
注意那個 273 GB/s。LLM 出 token 的速度幾乎被記憶體頻寬綁死,而不是算力。對照:H100 約 3,300 GB/s、Mac Studio M3 Ultra 約 800 GB/s。這個數字決定了下面所有結論。
致命真相:273 GB/s 在 70B 會崩盤
DGX Spark 跑小模型很快,跑大的 dense 模型很慢。速度跟模型大小成反比,因為每出一個 token 都要把整個模型的權重在記憶體裡搬一遍。
| 模型(dense) | 單台出 token 速度 | 評價 |
|---|---|---|
| Llama 3.1 8B | 38 tok/s | ✅ 快 |
| gpt-oss 20B | ~50–58 tok/s | ✅ 快 |
| Llama 70B FP8 | ~3 tok/s | 🚫 慘 |
| 405B / 235B(dense) | 個位數 | 🚫 能跑不能用 |
所以如果你的目標是「跑 dense 70B 當互動分身」,DGX Spark 是錯的工具。但別急著放棄——下一節是整個方案的轉折點。
解法:用 MoE 模型繞過頻寬死穴
MoE(Mixture of Experts,混合專家)模型每出一個 token 只啟動一小部分專家,所以「權重總量很大、但實際搬動量很小」。這正好繞過 DGX Spark 的頻寬瓶頸:你拿到大模型的腦袋,卻只付小模型的速度代價。
| MoE 模型 | 單台單流速度 | 定位 |
|---|---|---|
| Qwen3.6 35B-A3B(NVFP4) | ~97 tok/s* | 求快、反應飛快 |
| gpt-oss-120B(MXFP4) | ~55 tok/s(NVIDIA 官方 55.37) | 主力分身(品質速度最佳平衡) |
| Qwen3.5-122B-A10B | ~38 tok/s(調校可達 51) | 122B 級替代主力 |
這就是 DGX Spark 當私密分身能成立的關鍵:用 MoE,你在單台上就有 120B 級的腦袋 + 約 55 tok/s 的互動速度。
* Qwen3.6 35B-A3B 的 97 tok/s 目前為單一來源實測,物理上合理(約 3B active params)但尚未獨立複現;Qwen3.5-122B 預設約 38 tok/s,51 tok/s 是加上 MTP-2 等優化的調校峰值。gpt-oss-120B 的 55.37 tok/s 為 NVIDIA 官方數據,最紮實。
一台還是兩台?兩台聯合反而更慢
NVIDIA 主打「兩台用 ConnectX-7 直連可組 256GB、跑到 405B」。但對單人互動分身來說,這是個陷阱。兩台之間靠一條 200Gbps 銅纜交換 activation,每一個 forward pass 都要跨機,這條鏈路太慢。
| 配置 | 模型 | 單流速度 |
|---|---|---|
| 一台 | gpt-oss-120B | ~55 tok/s ✅ |
| 兩台 | Qwen3-235B-A22B | 只有 11.7 tok/s 🚫 |
看清楚:兩台跑 235B(11.7 tok/s)比單台跑 120B（55 tok/s）還慢 5 倍,而 235B 比 120B 聰明的幅度,撐不起雙倍預算 + 慢 5 倍。兩台「唯一」值得的情況是多人/多 agent 同時打、要批次併發吞吐——那時擴的是總量,不是單流速度。單人互動分身用不到。
公司私密剛需 → 本地。互動分身 → 一台 DGX Spark + MoE 模型。第二台對單人互動是「貴 + 慢」的反效果,別買。
同價位對手:該不該改買 Mac Studio?
如果你不在乎 CUDA 生態,Mac Studio M3 Ultra 的 800+ GB/s 頻寬在 dense 70B 上會快很多。但對綁 NVIDIA 工具鏈的公司,DGX Spark 的生態相容性才是真正價值。
| 機器 | 價格 | 70B 速度 | 生態 |
|---|---|---|---|
| DGX Spark 一台 | USD 4,699 | 3–8 tok/s(dense) | ✅ 全 CUDA + NVIDIA 企業棧 |
| Mac Studio M3 Ultra | USD 3,999 起 | 12–18 tok/s | ⚠️ macOS / MLX,無 CUDA |
| RTX Pro 6000 Blackwell 96GB | GPU ~13,250(上市 MSRP 8,565)+ 主機 | ~31.8 tok/s | ✅ 全 CUDA,但總價最高 |
結論:要綁 CUDA 生態 + air-gapped 合規 + 用 MoE 模型,DGX Spark 一台 CP 最高;要純跑 dense 70B 又便宜,Mac Studio 較快;要互動級速度 + 高併發又有預算,才上 RTX Pro 6000。
Day 1 落地:DGX Spark 到手後怎麼做
機器到手第一天,目標是把 gpt-oss-120B 跑起來,並讓 Claude Code 的後端指向它。2026/1 起 Ollama v0.14 原生支援 Anthropic Messages API,免 proxy,這讓整套變得很簡單。照「簡潔優先」原則,Day 1 只載一顆模型、起一個服務。
步驟 1:在 DGX 上裝 Ollama 並拉模型
# On the DGX Spark
curl -fsSL https://ollama.com/install.sh | sh
ollama serve # starts the server on port 11434
ollama pull gpt-oss:120b # ~60-65GB, fits in 128GB unified memory步驟 2:Claude Code 把後端指向 DGX
在跑 Claude Code 的那台機器,設三個環境變數即可。本地端點不驗 token,ANTHROPIC_AUTH_TOKEN 隨便填。
# On the machine running Claude Code (point it at the DGX box)
export ANTHROPIC_BASE_URL="http://<dgx-ip>:11434"
export ANTHROPIC_AUTH_TOKEN="local-dummy"
export ANTHROPIC_MODEL="gpt-oss:120b"
claude # Claude Code now talks to your private local model, zero cloud, zero API cost步驟 3:先驗證工具呼叫穩不穩,再丟真活
Claude Code 是重度 agentic loop(一直 Read / Edit / Bash)。本地模型的 tool-calling 比真 Claude 脆,先用簡單任務試,確認不會「工具呼叫失敗 / Edit 格式跑掉」再進真專案。
步驟 4(可選):要榨速度就換 vLLM
那些 55–59 tok/s 的數字來自 vLLM。vLLM 有官方 Claude Code 整合,起服務時記得開工具呼叫:
# Faster path: serve gpt-oss-120B with vLLM (OpenAI/Anthropic-compatible)
vllm serve openai/gpt-oss-120b \
--served-model-name my-model \
--enable-auto-tool-choice \
--tool-call-parser openai \
--port 8000步驟 5(可選):加一顆快模型 + 接上 ccbot
嫌 120B 慢、想秒回時,用 ollama pull qwen3.6:35b-a3b 加一顆,同一個服務用名字切,不用起第二個 process。若要用 ccbot(Telegram 觸發層)驅動,架構是 ccbot → Claude Code → ANTHROPIC_BASE_URL → DGX 本地模型。
- 工具呼叫可靠度:gpt-oss 與 qwen3-coder 是本地裡最穩的,但仍比 Claude 多失敗。
- 腦力落差:gpt-oss-120B 做私密/日常活夠用,但複雜架構推理仍不及 Claude Opus。把它當「私密資料的分身」,不是「Opus 替身」。
- ccbot 自身的坑跟換後端無關:主 session 不可直接呼叫
claude -psubprocess(會卡死),這是編排層問題,換本地模型不會修好它。
最終定案
公司私密剛需 → 本地。互動分身 → 一台 DGX Spark(USD 4,699)。模型 → gpt-oss-120B 主力(~55 tok/s)+ Qwen3.6 35B-A3B 求快(~97 tok/s)。第二台不要買。落地 → Ollama(免 proxy)接 Claude Code,需要時再上 vLLM 與 ccbot。它的定位很清楚:雲端不能碰的資料,交給一個夠用、私密、CUDA、常駐的分身——是安全換能力的取捨,不是便宜版 Claude。