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

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

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

Google TurboQuant 在 GX10 (GB10/SM121) 上的實測數據 — 3-bit KV cache 壓縮的真實壓縮率、Qwen2.5-3B 精度驗證、以及 Qwen3.5-35B 的 hybrid attention 架構為什麼讓事情變得複雜。

在 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 秒確認。

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

同一個 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 殺死一切。記憶體容量 > 頻寬速度。

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

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

可行性測試：開源模型能免費在本地跑 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 雙引擎驗證。

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

同一台 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 解不了資料缺乏。

把 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。

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% 落差大概率來自不同失敗類型的比例不同。