從密封箱到跑出第一個 LLM 的所有步驟。硬體檢查、Ollama 快速上手、vLLM 正式部署、模型選擇、5 個會浪費你整天的坑。

在 NVIDIA GB10（128GB 統一記憶體）上，用 7 個任務類別評測 8 個本地 LLM。量化的意外結論、一個連 JSON 都出錯的 120B 模型，以及把整個 token budget 用來思考的 thinking model。

Gemma 4 E2B / E4B / 26B MoE / 31B Dense 在 DGX Spark、RTX 5090、MacBook Pro 上的完整對照表。一張表看完速度、記憶體、量化格式。附選擇建議。

DGX Spark 2026 年中現況整理:現在該用 vLLM、官方 Gemma 4 NVFP4 權重、MTP、長 context 多模態,以及仍然會咬人的坑。

同一個 Gemma 4 26B-A4B、同一張 GPU，vLLM NVFP4 跑 52 tok/s，Ollama Q4_K_M 只有 40。根因：Marlin kernel、CUDA graphs，以及 Ollama 靜默的 CPU/GPU split 陷阱。

Gemma 4 31B-IT NVFP4 在 GB10 上只有 7.0 tok/s — 273 GB/s 頻寬是天花板。算術預測 4.4 tok/s，NVFP4 壓縮多了 60% 但逃不出牆。請選 MoE。

Gemma 4 E4B NVFP4A16 在 DGX Spark 上跑 49.9 tok/s — 比 BF16 快 2.6 倍。HuggingFace 上第一個 NVFP4 checkpoint。PLE 架構解析、FP8 vs NVFP4、以及差點讓我們放棄的 llm-compressor 版本地獄。

Gemma 4 E2B 在 M1 Max 跑到 81 tok/s，比 E4B 快 44-82%。三台機器、相同方法論、每輪獨立 prompt，排除 Ollama 快取干擾後的真實數據。

Gemma 4 E2B 到 31B 在 RTX 5090、M1 Max、DGX Spark、M4 上用 Ollama 完整測試。E2B 在 5090 上 310 tok/s。31B 在 MBP 上 1.5 tok/s — swap 殺死一切。記憶體容量 > 頻寬速度。

可行性測試：開源模型能免費在本地跑 SWE-Bench 嗎？Gemma 4 26B 在 OpenHands 上失敗（40+ 錯誤），但在 SWE-agent 上 9 步修好測試 bug。同一個模型，差別在 action 格式。

在 GX10 用 mini-swe-agent + vLLM 跑 SWE-bench Lite 單題，從假成功的 doc 一路修到 Gemma 4 38 步乾淨 submit 正確 patch 的 scaffold engineering 紀錄。

Gemma 4 26B-A4B FP8 在 SWE-bench Lite 解了 116/300 題，全球排名 #16。跑在 DGX Spark 上，零 API 費。差距在 scaffold 設計，不是模型大小。

一套 scaffold（backticks + edit-tool + budget prompt），三個模型（Gemma 4 E4B、Gemma 4 26B、Qwen 3.6 35B），跑之間零程式碼改動。Qwen 3.6 拿到 48.33%——超越 SWE-agent + Claude 3.7 Sonnet。Scaffold 是固定成本，模型是變數。

NVFP4 理論上更快——位元更少、頻寬更省。但在 DGX Spark 的 GB10 (SM121) 上反而慢 32%。根因：缺硬體指令。vLLM 和 SGLang 雙引擎驗證。

同一台 DGX Spark、同一套 harness、同樣 22,690 題。Qwen 3.6 35B-A3B 拿到 75.07%，Gemma 4 26B-A4B 拿到 46.30%。Qwen 在 51 個子科目上一個都沒輸——連我原本以為 Gemma 會贏的台灣題目都沒贏。

把 huihui-ai 的 abliterated Qwen 3.6 35B 丟進 Part 21 同一套 TMMLU+ 測下去。總分從 75.07% 掉到 73.22%。代價分布不平均：規範性題目（信託 −7.7、行政法 −7.1）失血最重，純邏輯反而略好。台語也變更差——abliteration 解不了資料缺乏。

Qwen 3.6 35B-A3B 在 SWE-bench Lite 拿 48.33%(145/300),貼近 SWE-agent + Claude 3.7 Sonnet。但剩下的 155 題告訴你模型還差什麼:76% 是「找對檔案、改錯邏輯」。Gemma 4 26B 同一套 scaffold 拿 38.67% — 9.66% 落差大概率來自不同失敗類型的比例不同。

十天前我說 NVFP4 在 DGX Spark 上是個坑、FP8 比較快。今天同一台機器跑 Nemotron 3 Nano W4A16 飆到 74.75 tok/s，連我自己之前的 FP8 hack 紀錄一起踩過去。這篇講 4 層 patch、quant variant 怎麼選、跟記憶體頻寬天花板的算法。

同一台 DGX Spark，這次不拚速度，改拚「看完英文影片講給我聽」。3 分鐘 Karpathy 演講 89 秒處理完，5 萬 4 千 prompt token，逐字稿和畫面內容都對。記錄兩個踩過的雷：use_audio_in_video flag 放錯位置會幻覺音訊、b12x patch 過的 image 在 Omni 上會吐 NaN。

Google 2026-05-05 發 Multi-Token Prediction drafter,vLLM PR 同日開、官方 preview docker 同日有。DGX Spark 上實測 Gemma 4 26B-A4B-it FP8 + MTP γ=4:單流 108 tok/s(2.66× baseline)、8 路並行 674 tok/s 總吞吐。一個沒寫進文件的雷:drafter 不能配 base model,要配 -it。

在 DGX Spark GB10 上把 RedHatAI EAGLE-3 drafter fine-tune 對齊 huihui Gemma 4 26B-A4B abliterated FP8 body 的 distribution。1 epoch / 50k Magpie samples / 11h 訓練。Inference bench(raw `/v1/completions`)pos 3 acceptance 從 vanilla 的 20.5% → 72.7%、n=4 throughput 從 50 → 100.36 tok/s aggregate。**後續 paired bench 發現原 throughput 比較 baseline 跟 retrain 用了不同 endpoint(chat vs raw)— production chat workload 上 retrain drafter 的真實提升遠小於 2×,詳見文首 endpoint correction**。Part 28 證實的「abliterated body deep speculation acceptance 散開」這個機制觀察仍成立。順帶找到 Speculators upstream create_empty_sample dtype bug + Phase 0 整理 6 個社群 prior art。

GB10 DGX Spark 上，純 dense 模型單流 decode，NVFP4 比 FP8 快約 1.5 倍。但快的是頻寬（權重檔變小），不是 FP4 tensor core——最快那條路根本沒碰它。

GB10 上 NVFP4 W4A4 拔掉 --enforce-eager 後從 23 衝到 67 tok/s,贏 FP8 29% 還省 16GB。Part 32 說 cudagraph 沒用——那只對 dense,MoE 完全相反。

NVFP4 把蒸餾版 Sulphur 2(LTX-2.3)影片模型從 29 砍到 19.5 GB,在 GB10 DGX Spark 上畫質速度都沒掉。影片 diffusion 是 compute-bound,跟 LLM decode 剛好相反。

我在 DGX Spark GB10 上量化 Google 新的 omni Gemma 4 12B。weight-only NVFP4 只要 7.7GB、跑 24.9 tok/s,而且圖片/語音/影片都還能用 —— 全 W4A4 反而沒比較快,還把多模態弄壞。

我在 DGX Spark 上把 gemma-4-12B 量化成 BF16 / FP8 / NVFP4 weight-only，分別測英文 MMLU 跟繁中 TMMLU+。FP8 兩邊都近無損；NVFP4 繁中掉 6 分、英文只掉 3 分。

DiffusionGemma 26B-A4B 用官方現成 image 就能在 128GB DGX Spark 上跑 vLLM,不用等 PR、不用 cherry-pick。NVFP4 單條 158 tok/s、四條同時 257。但單一個 tok/s 數字會騙人:diffusion 的速度取決於 256 token 的畫布有沒有填滿。

從零把 33B 影音同步模型跑在 GB10 上。哪些參數非設不可、時間到底花在哪、為什麼 NVIDIA 自家的放大器在這台裝不上，以及換成 4.3 MB 的開源 SPAN 之後省了 22%。

GB10 的頻寬 273 GB/s、語言主幹 18.77 GB，每個 token 都要整份讀過，上限 14.54 tok/s。實測無投機 12.32，吃掉 85%，換 kernel 撈不回來。投機解碼把它拉到 5.28 倍，而關鍵不是換方法，是把草稿預算從 8 調到 12。

NVIDIA 官方 NVFP4 checkpoint + vLLM nightly + 九個 overlay 檔，一台 DGX Spark 上 40 題中位 41.7 tok/s、散文 27.4、程式 45，比同機 llama.cpp 快 78%。六張圖講模型結構，與 47.68 GiB n-gram 表為何放硬碟。

兩台 DGX Spark 用 QSFP 直連跑 vLLM 跨節點 TP=2,Qwen3.8-Flash-Next NVFP4 從單機 41.7 tok/s 到 51.9,KV 池翻倍。完整接線、起服務順序與驗證步驟。

MiniMax-H3 只畫 672×384 草稿、LTX-2.5 精修到 1344×768，在 DGX Spark 上 118.8 秒，原生直出要 237.7 秒。附完整設定步驟、必要的版本組合，以及為什麼這台機器吃得到這個好處。

跑 MiniMax-H3 影片生成時，DGX Spark 兩次整台斷電，連 log 都來不及寫。這篇是儀器就位之後怎麼重現它、鎖頻 2200 MHz 怎麼修好、以及為什麼我們後來又把鎖頻關掉。

距離 #46 十六天，同一套 40 題重測：51.9 → 72.0 tok/s，評分沒掉。幅度最大的是拿自己常用的中文補進 MTP 草稿詞表，常用主題快 60%；多輪對話修好 prefix cache 對齊，第二輪從 3.30 秒變 0.23 秒。

TTFT 從幾秒降到 0.12s。DGX Spark GB10 上 Qwen3.5-35B 從 Ollama 換到 vLLM 的實戰筆記，含六個坑：SSM + chunked prefill 陷阱、記憶體衝突、docker 重啟順序。

在 GB10 上用 vLLM 0.19 部署 Gemma 4 26B-A4B MoE NVFP4 — 52 tok/s decode、16.5 GB 模型、82 GB KV cache 可用。包含 Phase 0 決策過程和完整踩坑記錄。

Part 19 證明 NVFP4 在 DGX Spark 上是陷阱。這篇直接動手：寫 Triton kernel 把 NVFP4 轉成 FP8，餵 FP8 tensor core。從 40.8 提升到 47.6 tok/s，附完整程式碼。

把 huihui-ai 的 Qwen3.6-35B-A3B abliterated BF16 量化成 FP8，部署到 DGX Spark GB10。從 4 次 OOM 到 1.68× over BF16 的完整旅程：UMA 物理上限、save_pretrained 的 50GB shard 陷阱、語言模型 prefix bug、MTP speculative decoding，以及為什麼第一個成功的版本根本沒做 FP8 cast。

Part 28 是 mechanism,這篇是 recipe:abliterated Gemma 4 26B-A4B FP8 跑在 GB10 上,搭官方 vanilla draft 開 num_speculative_tokens=1,baseline 39.3 → 52.6 tok/s (+34%),不用重訓 drafter。30 行 docker run + bind-mount PR #41745 head 的 gemma4_mtp.py 就能拿到。包含 sanity check 跟什麼時候 n=1 不夠用的判斷。

Qwen3.8-Flash-Next 在單台 DGX Spark 上跑 UD-Q4_K_XL，原生 262,144 context 全開，改檔案 76.65 tok/s。完整設定、四格速度、記憶體怎麼分配。

單台 DGX Spark(121 GB 統一記憶體)跑 GLM-5.3-Flash 的完整配方:量化怎麼選、CUDA toolkit 為什麼只能是 13.0、中文為什麼比英文快、以及原生視覺跟投機解碼為什麼現在不能一起開。

在 ASUS GX10（SM121，128GB）上跑 NVIDIA Nemotron-3-Super-120B-NVFP4。四個 SM121 專屬坑、一個沒有任何作用的環境變數，以及最終可用的 docker 指令。

CUTLASS FP4 kernel 是針對 SM120（GB200）編譯的。在 SM121（GB10，DGX Spark）上它會靜默執行，但輸出垃圾。完整除錯過程——4 個 bug、row-identical 失敗特徵，以及有效的修正方案。

vLLM serve script 加了 --kv-cache-dtype fp8，GB10 上輸出在約 500 token 後退化成重複字。根本原因：沒有 calibration data，q_scale 預設 1.0。

DGX Spark 的供電和過熱問題在 Carmack 批評後引爆社群。這篇整理三種不同症狀的診斷方法：30W PD controller 缺陷（需 RMA）、100W 功耗上限（散熱降頻）、5W driver bug（可修）。一個指令 30 秒確認。

Gemma 4 31B 在 MBP M1 Max 上用 Ollama 只有 1.5 tok/s（swap）。解法：降 context window（9 tok/s）或用 oMLX（12.8 tok/s）。真正的兇手是 KV cache 分配，不是模型大小。

自量化 huihui Gemma 4 26B-A4B abliterated 成 FP8 ship 上 HF。完整 n=1..4 sweep 後發現:abliterated body 跟 vanilla baseline 完全一樣快,n=1 上 MTP 加成也一樣;但 n=4 deep speculation 上 huihui 因為 per-position decay 陡(每 step 22pp)而被 vanilla 拉開兩倍。Tax 的真實樣貌是 conditional on num_speculative_tokens,不是固定百分比。

Round 1 在 chat workload 上沒有 2× speedup 後,Round 2 加 30K 中文 instruction data + huihui body 重生 response,訓練 41 小時。結果:Round 2 B drafter chat EN 45 tok/s / ZH 29 tok/s,跟 v1 基本相同,**遠輸 vanilla MTP n=4 的 EN 53 / ZH 45**。確認 EAGLE-3 small head 對上 abliterated body 的架構天花板,more data 救不了。順帶找到 vLLM Gemma 4 preview image(`gemma4-0505-arm64-cu130`,內部 build `0.20.2rc1.dev49+g9b4e83934`)在 long-run extract_hidden_states 的 scheduler deadlock(三次踩到 + watchdog 補完)。

本機 35B agent 生圖生影片一直亂試,我差點跑去微調它。動手前先讀 tool-call log:格式 0% 出錯。模型沒問題,是一個壞掉的 ComfyUI 工具逼它即興。解法是一個乾淨的 ACI skill,不是微調。

ds4 引擎內建 directional steering — 推理當下推一個方向向量改變模型行為,數學上就是 abliteration 的連續可逆版。我在 GB10/CUDA 上跑通了(官方工具其實偏 Metal,但 CUDA 的 activation dump 也能觸發),抽了一條 verbosity 向量。結果:在 abliterated Q2 上 gradient 非單調、正向 scale 直接崩成標題碎片 —— 兩刀同源,疊起來互相打架。