DGX Spark 2026 現況:哪些還能跑、哪些已經過時、我現在會怎麼配

白話版:舊文是實驗紀錄,這篇是 2026 年中導航

DGX Spark 這個系列一路寫下來,其實像一疊實驗筆記:這個模型塞得進去嗎?那個量化為什麼反而慢?為什麼照文件跑,結果吐出來一堆驚嘆號?每一篇都有用,但你如果從第一篇照日期讀到第 40 篇,很容易把「當時救火用的做法」誤會成「現在應該照抄的做法」。

所以這篇不是再跑一次 benchmark。這篇是索引:2026 年中我現在會怎麼配、哪些舊結論還成立、哪些做法已經該收起來。要翻完整系列,從 DGX Spark 系列 hub 進去就好。想先拿現況答案,看這篇。

---

前言:我現在不照時間順序讀這個系列

硬體文老化的方式很討厭。數字還有用,但安裝步驟會變舊。4 月救命的 Docker image,7 月可能只是考古。當時非掛不可的 bind mount,現在反而是你應該刪掉的東西。

所以我現在看自己的 DGX Spark 系列,不是從 Part 1 一路讀。我會先看「現在建議」,再把舊文當 receipts。那些 receipts 還是重要:GB10 還是同一顆 GB10,頻寬牆沒有突然消失,選錯 runtime 還是一樣會痛。只是 2026 年中的答案,已經比 4 月乾淨很多。

2026 年中我會這樣配:先 vLLM,再看用途換模型

如果你的目標是找一條穩的本機 AI 路線,我不會從最大模型開始。我會先找「現在 runtime 原生支援、少補丁、量過速度」的路線。

用途	我會先試	理由
日常聊天 / 本機助理	nvidia/Gemma-4-26B-A4B-NVFP4 + current vLLM	同一類路線在 GB10 上量到約 52 tok/s,官方權重也拿掉早期社群量化 shim。
長 context 文字	先用 26B-A4B NVFP4,再量你自己的 context 形狀	長 context 不是免費的。KV cache、讀進去的成本、runtime 行為,都比 model card 上的最大數字重要。
長 context 多模態	Gemma 4 12B Unified	這是 2026 年的新選項:encoder-free 多模態,model card 寫 256K context。這種工作我會先測它,不會硬塞給原本偏文字聊天的 26B 路線。
高吞吐聊天 / 助理 serving	vLLM + MTP 路線,但只在 target/drafter 配對正確時開	MTP 路線已量到 108 tok/s。現在 vLLM 原生支援,不用舊的 preview image。配對錯一樣會哭。
diffusion 語言模型實驗	DiffusionGemma on vLLM,但把它當另一類模型	它可以很快,但 diffusion 的 tok/s 不能拿來跟一般 AR 模型硬比。先讀 diffusion 那篇再看數字。

助理用途尤其不要只盯模型。工具型助理慢,可能是模型慢;也可能是每一輪都把太多 context 重丟一次。換模型救不了壞掉的迴圈。

半年內變最多的是工具鏈,不是 GB10 的物理限制

這半年最大的變化,不是這台機器突然變快。是周邊工具補齊了。

第一個變化是 NVIDIA 官方 nvidia/Gemma-4-26B-A4B-NVFP4 權重在 2026-04-30 發出來,而且 vLLM 支援。這讓預設路線從「社群量化 + gemma4_patched.py」變成「先用官方權重」。早期那篇 52 tok/s 實測 還是速度 receipt,但裡面的安裝路線不該無腦照抄。

第二個變化是 Gemma 4 MTP 從預覽路線變成正常 runtime 功能。vLLM PR #41745 在 2026-05-06 merge,並隨 vLLM v0.21.0 在 2026-05-15 出貨。現在 stable 是 2026-06-29 的 vLLM v0.24.0。MTP 108 tok/s 那篇 還是證明速度存在;preview image 和 bind-mount 則是歷史。

第三個變化是 Google 在 2026-06-03 推出 Gemma 4 12B Unified。這讓 Spark 多了一條長 context 多模態路線,不必什麼都逼 26B-A4B 接。我不會說它取代所有東西;我會說,只要工作是「大 context 加多模態」,它是現在該先列入測試的模型。

仍然沒變:GB10 吃 sparse activation,不愛 dense decode

舊 benchmark 沒有報廢。它們變成護欄。

舊數字	到現在仍然有用的結論
26B-A4B NVFP4 on vLLM:約 52 tok/s	日常聊天夠快,現在官方權重讓路線更乾淨。
MTP 路線:108 tok/s	高吞吐 serving 值得測 speculative decoding,但 target/drafter 要配對。
E4B NVFP4:約 50 tok/s	小一點或 PLE 類模型仍有位置,不是每件事都要 26B。
31B dense:約 7 tok/s	Dense decode 在 GB10 上還是不適合。模型大不代表坐在椅子上用起來比較好。
同模型 vLLM 比 Ollama 快約 30%	Runtime 不是包裝差異,它會直接改變結果。

這其實就是 Gemma 4 選型總表 的主軸:在 DGX Spark 上,我更在乎每個 token 實際搬多少權重,而不是模型總參數寫多大。MoE 會好用,是因為每次只叫一部分專家出來。PLE 類的小模型也有自己的位置。31B dense 紙面上很強,坐下來等它吐字就知道痛。

仍然會咬人:量化、KV cache、runtime 狀態

幾個煩人的坑也還活著。

第一個坑是「NVFP4 一定比較快」。沒有。NVFP4 vs FP8 那篇 會存在,就是因為 GB10 的硬體路線有細節:看起來比較小的格式,不一定走到比較快的 kernel。現在我仍然把官方 26B-A4B NVFP4 當預設起點,但不會把這句話推廣成「NVFP4 到處都比 FP8 快」。

第二個坑是把 Ollama 當無害備案。vLLM vs Ollama 那篇 量到同模型 vLLM 約快 30%,而且 CPU split 那類問題,就是會讓你以為模型壞掉。方便時我會用 Ollama;但要量這台機器的能力,我不拿 Ollama 當效能基準。

第三個坑是把 context window 當免費額度。長 context 代表 KV cache 壓力、讀進去的成本,也代表助理每一輪可能反覆付同一段文字的錢。Gemma 4 12B Unified 帶來 256K context 的多模態新選項,但它沒有讓成本模型消失。要量你的工作形狀,不要只看最大窗口。

別照日期讀:從系列 hub 開始跳

如果你是第一次進來,我會這樣讀:

你想問	先看這篇
「Gemma 4 到底選哪顆?」	Gemma 4 選型總表
「現在預設文字模型怎麼跑?」	26B-A4B NVFP4 at 52 tok/s
「MTP 值不值得開?」	Gemma 4 MTP at 108 tok/s
「vLLM 還是 Ollama?」	同模型 vLLM vs Ollama
「為什麼 NVFP4 有時候反而怪?」	NVFP4 trap:GB10 FP8 wins
「diffusion / 多模態-ish 怎麼看?」	DiffusionGemma NVFP4 on vLLM
「整個系列地圖在哪?」	DGX Spark 系列 hub

日期可以幫你判斷脈絡,但它不是現在的閱讀順序。

收穫:把 DGX Spark 當容量機,不要把它當 5090

最花時間的地方: 不是「模型能不能跑」。最花時間的是找到模型格式、runtime 支援、GB10 硬體路線三者哪裡互相打架。

可以帶走的診斷方法: 一個 setup 覺得怪,我現在會先看 runtime,再看 active parameter 形狀,再看量化格式,最後看 context 行為。這比盯著模型大小有用。

一句話原則: 2026 年的 DGX Spark,適合拿來做本機 serving 和容量型工作。它不是純速度競賽機。用現在的 vLLM 路線,有官方權重就先用官方權重,吞吐需求再測 MTP,舊文留著當 receipts。

現在地圖大概就這樣。實驗還在那裡;先從 系列 hub 進去,再沿著你真的要做的事往下跳。