2026-05-09
DGX Spark + Mac Studio 解耦推論 — GPT-OSS-120B 達 2.8× 加速：分離 prefill 與 decode
社群模式：DGX Spark 負責 prefill（GPT-OSS-120B 約 1,723 tok/s），Mac Studio M3 Ultra 負責 decode（819 GB/s 記憶體頻寬），相對單張 Spark FP8 達 2.8× 端到端加速。
5 月 5 日發布的一篇社群文章在 DGX Spark 論壇整週擴散：將 DGX Spark 與 Mac Studio M3 Ultra 透過解耦推論（disaggregated serving）配對使用，在 GPT-OSS-120B 上相對單張 Spark FP8 基準達到 2.8× 端到端加速。
模式背後的頻寬數學
DGX Spark 與 Mac Studio M3 Ultra 的優勢是不對稱的，正好對應 LLM 工作負載的兩個階段：
| 階段 | 瓶頸 | DGX Spark（GB10） | Mac Studio M3 Ultra |
|---|---|---|---|
| Prefill（處理輸入） | 算力（TFLOPS） | 強 — Blackwell tensor core | 弱 — 統一記憶體 ALU |
| Decode（生成 token） | 記憶體頻寬 | 273 GB/s LPDDR5X | 819 GB/s 統一記憶體 |
GPT-OSS-120B 在 DGX Spark 上的 prefill 實測 約 1,723 tok/s（算力受限，Spark 勝）。同硬體上的 decode 卡在頻寬下限（FP8 約 36 tok/s）。Mac Studio 的記憶體頻寬高出 3 倍，使其 decode 約快 2 倍。把工作負載拆開 —— Spark 負責 prefill、Mac Studio 負責 decode —— 就能結合兩者的優勢。
實測結果
| 配置 | GPT-OSS-120B tok/s | 備註 |
|---|---|---|
| 單張 Spark FP8 | 36 | decode 受頻寬限制 |
| 單張 Spark NVFP4（CES 後） | 49.7 | NVFP4 打包有幫助 |
| Spark + Mac Studio 解耦 | 約 100+ 端到端 | 比 Spark FP8 基準快 2.8× |
解耦透過 NIXL 或類似的 prefill/decode 控制器串接。vLLM 0.20+ 與 TensorRT-LLM 1.3.0rc14+ 都原生支援此模式 —— TRT-LLM PR #13198（「KV-aware ADP routing」）剛在本週的釋出中合併，是 NVIDIA 堆疊上最乾淨的路徑。
何時值得做、何時不值得
強候選：
- FP8 / NVFP4 下的 70B–150B 稠密模型（decode 被頻寬綁住）
- 長上下文工作負載，prefill 成本主導每次請求
- 多輪 agent 迴圈，TTFT 決定使用者體驗
弱候選：
- A3B 級 MoE（如 Qwen3.6-35B-A3B）—— 啟用參數的數學減輕了 decode 頻寬壓力；單張 Spark 已能以 55+ tok/s 競爭力地服務
- 任何低於 30B 的規模 —— 解耦本身的開銷會吃掉收益
行動項
如果你有一台 Mac Studio M3 Ultra（甚至 M2 Ultra）閒置，這對任何跑 70B+ 稠密模型的 DGX Spark 操作者來說，是 ROI 最高的週末專案。設置大致如下：
- 在 Spark 上安裝 TRT-LLM 1.3.0rc14，加上
--enable-disaggregated - 在 Mac Studio 上安裝 MLX 或 llama.cpp Metal，擔任 decode 角色
- 透過 NIXL 或 TRT-LLM 原生 KV transfer（PR #13198）連線
- 透過 vLLM 的 prefill/decode router 或一層自製薄層做路由
對只用 Spark 的操作者，反向結論同樣有用：在持續性單張 Spark 服務時，優先選擇 A3B 級 MoE 而非 30B+ 稠密。即使在 NVFP4 下，27B 以上稠密的頻寬數學依然不利。