DGX Spark 可以跑什麼模型？GB10 模型實證表

先分清三種「可以跑」

大家問「DGX Spark 可以跑什麼模型」時，常把三件事混在一起：

證據層級	它能回答什麼	不能代表什麼
容量估算	權重大約能不能放進記憶體	框架一定支援、速度一定可用
官方工作流	NVIDIA 有文件化、可照步驟重現的路徑	所有版本與工作負載都有相同性能
社群實測	某台 GB10 在特定模型、引擎與測法下的結果	官方保證、你的正式環境也會一樣快

真正的採用判斷，還要再做第四層：用自己的 prompt、context、資料、併發與可接受延遲跑 PoC。

可下載的模型證據快照

本站把本頁採用的模型、引擎、量化、結果、限制與來源整理成機器可讀資料：

• 下載 JSON 證據快照
• 下載 CSV 證據快照

資料日期是 2026-08-15。它是來源索引與判讀表，不是本站自有 DGX Spark 實測，也不代表完整模型相容清單。

NVIDIA 已文件化的單機工作流

以下只表示 NVIDIA 有對應的 DGX Spark 文件或配方。版本、下載權限、容器、Arm64 相容性與模型授權仍要逐項確認。

模型或工作負載	引擎 / 格式	官方文件證明的路徑	先注意什麼
Qwen3.6 35B-A3B	Ollama；NVFP4、Q8、BF16	官方 coding agent 工作流列出約 22GB、39GB、71GB 三種模型包	檔案大小不等於完整 runtime 占用
Qwen3.6 35B-A3B MTP	llama.cpp；GGUF Q4_K_XL	官方示範 CUDA 編譯、OpenAI 相容 API 與 MTP speculative decoding	context 與四路併發會再吃 KV cache
Nemotron-3 Nano / Super	vLLM 或 TensorRT-LLM；Super 為 NVFP4 路徑	官方提供單機部署與 API 驗證步驟	容器 tag、plugin、模型權限都要照文件版本
Llama 3.1 70B	PyTorch；LoRA / QLoRA	官方提供 70B 參數高效率微調配方	這不是 70B 全參數訓練，也不是從零訓練
Qwen3-8B	NeMo AutoModel；全參數 SFT 範例	官方提供 Spark 專用設定與短步數驗證流程	範例 20 steps 只驗證流程，不代表模型品質成果
FLUX.1 / SDXL	TensorRT；FP16、FP8、FP4	官方提供文字生成影像的多精度推論工作流	需要 gated model 權限，量化可能影響品質

這張表最重要的用途，是把「官方說最高 200B」拆成真的可操作工作流。官方上限仍有價值，但不能取代模型與引擎層級的驗證。

社群單機實測怎麼看

SparkBench 公開單台 GB10 的配方、context、推論引擎與量測頁。本站採用的是它在 2026-08-15 可查到的資料快照，並保留失敗旗標；這些結果不是 NVIDIA 官方測試，也不是本站親測。

模型	測試設定	公開結果	限制
Qwen3.6 35B-A3B NVFP4 MTP	vLLM、FP8 KV、固定 context fill	4k 為 86.3 tok/s；50k 為 78.8；100k 為 31.5	單機、單一配方；50k 的 agent run 曾有 tool check fail
Qwen3-30B-A3B NVFP4	vLLM、40k context 設定	4k 為 74.2 tok/s	另一個約 18k fill 的 agent run 有 tool check fail
Qwen3-Coder-Next 80B NVFP4	vLLM、256k context 設定	4k 為 58.9 tok/s	50k fill 的 agent run 有 tool check fail，不能把速度等同工具正確率

這裡的 tok/s 是特定 benchmark 的 decode throughput。它不能直接回答首 token 延遲、多人併發、RAG 端到端延遲、輸出品質或工具呼叫是否正確。

128GB 可以放多大的模型？

先用權重下限估算，再另外保留系統、runtime、KV cache 與工作緩衝：

權重精度	每 10 億參數的理論權重	70B 權重下限	200B 權重下限
BF16 / FP16	約 2GB	約 140GB	約 400GB
FP8 / 8-bit	約 1GB	約 70GB	約 200GB
4-bit	約 0.5GB	約 35GB	約 100GB

這只是十進位粗估，不含量化 metadata、對齊、runtime buffer、KV cache、context、batch、顯示與作業系統占用。白話說：200B 的 4-bit 權重理論上接近 100GB，不代表剩下的空間一定足以穩定服務。

MoE 還要再多看一欄：active parameters 會影響每個 token 的計算量，但通常不會讓完整模型權重憑空消失。把 35B total / 3B active 直接當成 3B 模型，會低估記憶體。

依工作負載選模型，不要先選最大模型

需求	比較合理的第一輪	驗收重點
單人 coding agent	30B 到 80B 量化模型，先跑 32k 到 100k context	首 token、decode、工具正確率、長任務穩定性
內部問答 / RAG	先用較小模型搭配真實文件與檢索	召回率、引用正確、端到端延遲、多人併發
模型微調	先分清 SFT、LoRA、QLoRA 與全參數微調	峰值記憶體、訓練時間、checkpoint、品質提升
影像生成	先核對模型授權、格式與 TensorRT 路徑	首張時間、穩態速度、畫質、OOM 與磁碟占用
正式 API 服務	不能只看單流 tok/s	p95 延遲、吞吐、併發、監控、重啟與故障恢復

模型越大不一定越適合。對 coding agent 或 RAG，工具正確率、context 穩定性與回應時間常比「最大參數量」更接近實際價值。

自己重跑時至少記錄這些欄位

1. DGX OS、driver、CUDA 與容器版本。
2. 模型完整名稱、revision、量化格式與檔案來源。
3. vLLM、llama.cpp、Ollama 或 TensorRT-LLM 的版本與啟動參數。
4. context、KV cache 精度、batch、併發、prompt tokens 與 output tokens。
5. 首 token 延遲、decode tok/s、總吞吐、峰值記憶體與錯誤率。
6. 工具呼叫、RAG 引用或任務品質是否通過，不只記速度。

沒有這些欄位的單一數字，很難跨模型、跨版本或跨機器公平比較。

DGX Spark 和物理 AI 的交界

DGX Spark 可以放在模型開發、合成資料、模擬、VLA 原型與離線評估這一側；它不是因為能跑大模型，就自動成為機器人的即時安全控制器。上機端還要另外驗證 I/O、延遲抖動、功耗、環境條件與安全責任。

要拆清楚兩者邊界，可接著看工作站、本地 AI 主機與機器人運算平台怎麼分與機器人模擬、合成資料與 Sim-to-Real。

本頁怎麼更新

新資料只有在來源能追到模型、引擎、量化、context、方法與日期時才會加入。官方新增工作流會標成「官方工作流」；外部實測會標成「社群實測」；本站沒有硬體親測時，不會寫成本站 benchmark。

最後更新：2026-08-15；本頁已複查 NVIDIA DGX Spark 硬體、Qwen3.6、llama.cpp、Nemotron、PyTorch / NeMo 微調、多模態推論工作流，以及 SparkBench 單機 GB10 配方與量測頁。