現階段大型語言模型執行推理任務有兩個截然不同的階段：第一個 Prefill（提示預處理）吃大量 GPU 運算，第二是 Decode（解碼；逐詞生成）則是記憶體頻寬的戰場。Nvidia 的 Blackwell GPU 擅長前者，Apple Silicon 的統一記憶體架構擅長後者，那如果把它們接在一起，讓各自主攻自己擅長的環節，會不會比任何一台獨自跑都快？知名科技 YouTuber Jeff Geerling 決定用行動回答這個問題。他花了數個月時間，將 Nvidia DGX Spark（代號 GB10）與 Mac Mini M4 Pro 及 Mac Studio M3 Ultra 透過 Exo 開源框架串接，實測「異質分散式推理」（disaggregated prefill/decode）。
什麼是 Disaggregated Inference？
在深入了解實驗之前，先快速釐清一個概念。AI 模型的推論分為兩個階段。第一階段叫 Prefill（又稱 Prompt Processing），是模型讀懂你輸入的整個提示，把它壓縮成 KV Cache。這個階段是 GPU 運算密集（compute-bound），Blackwell、H100 這種擁有大量 Tensor Core 的 GPU 表現最好。
第二階段叫 Decode，是模型逐字吐出回應。這個階段的瓶頸在於記憶體頻寬（memory-bound），因為每次生成一個 token，都要從記憶體讀取整個模型的權重。Apple Silicon 的統一記憶體架構正好擅長這件事：M4 Pro 有 273 GB/s、M3 Ultra 更高達 819 GB/s 的記憶體頻寬。
這並不是學術空談。DeepSeek、字節跳動等公司早已在資料中心大規模部署 disaggregated inference，將 prefill 和 decode 分配給不同機器，各自優化，這也是近年推理成本持續下降的原因之一。但將這個概念搬到一般消費者的桌機上，是另一回事。
實驗配置：Spark 當 Prefill、Mac 當 Decode
Jeff 選擇這幾台手上有的機器：
- MSI Edge Expert（等同 DGX Spark / GB10）：搭載 Nvidia Blackwell GPU，128GB 統一記憶體，專攻 compute-heavy 的 prefill
- Mac Mini M4 Pro（第一階段）：64GB 記憶體，273 GB/s 頻寬，擅長 decode
- Mac Studio M3 Ultra（第二階段加入）：512GB 記憶體，819 GB/s 頻寬
選擇這兩種架構不是偶然，DGX Spark 有 Blackwell 的強勁 GPU 運算力，但記憶體頻寬遠不及 Apple Silicon；而 Mac 正好相反。Jeff 想測試的是「讓兩台機器各做自己最擅長的事」這個直覺是否成立。
軟體端使用的是開源專案 Exo，它已經有實驗性的 disaggregated prefill/decode 支援，只是從未在真實硬體驗證過。Jeff 讓 Claude Code 寫了大量程式碼、SSH 進兩台機器編譯 Rust 網路層、編譯 Blackwell 的 CUDA kernel、以及在 Mac 端從原始碼編譯 MLX 的 Metal shader 花了好幾天把整套環境搭建起來。
卡關：mDNS Bug 與網路噩夢
最大的技術難關是網路，Exo 使用 mDNS 來發現網路上的 peers，但 libp2p 的 mDNS 在 macOS 上有 bug，兩台機器始終看不見對方。
Jeff 花了數小時嘗試：直接乙太網路線、USB 轉接器、修改 Rust 網路層、Thunderbolt 連接線——全都失敗。最後他用 tcpdump 抓到問題根源：原來是 libp2p 的 mDNS 實作在 macOS 上有問題。
結果解法出乎意料地簡單，讓 GB10 主動撥號（dial）Mac Mini，而非等待被 mDNS 發現。加上一個環境變數設定後，連線立刻建立成功。
升級網路：Thunderbolt 5 外接 Mellanox 50Gb 網卡
即使連上了，2.5Gb USB 乙太網路的瓶頸馬上浮現。在 25,000 tokens 的提示下，GB10 不到一秒就算出 KV Cache 但透過 2.5Gb 網路傳輸過去，卻花了 25 秒。96% 的時間都花在網路上。
為了解決這個問題，Jeff 翻出了他的 Thunderbolt 5 外接盒，裡面插了一張 Mellanox ConnectX4 50Gb 網卡，macOS 從 2019 年起就內建驅動，插上即用。透過 Microsec CSR812 交換器連接後，KV Cache 傳輸時間減少了約 30%。這也點出了 disaggregated inference 在消費級環境的最大物理限制：你必須有夠快的區域網路，否則 prefill 省下的時間全部會被網路吃掉。
第一回合：Mac Mini + Spark 實測
換上非思考型模型 Llama 3.1 8B 後，數據開始有意義了：
- GB10 獨自 Prefill：最高近 1,800 tokens/sec
- Mac Mini 獨自 Decode：52 tokens/sec
- Disaggregated 模式 Time to First Token：2.4 秒，抵近 GB10 單機的 2.3 秒
- Disaggregated Decode：34 tokens/sec（比 Mac Mini 單機慢，因為 KV Cache 注入 overhead）
時間到第一個 token 幾乎追平了 GB10 水準，也就是說，你得到了 GB10 等級的 prefill 速度，配上 Mac 等級的 decode。雖然 decode 因為 KV Cache 傳輸 overhead 略有損失，但整體方向是對的。
第二回合：換上 Mac Studio M3 Ultra
Jeff 真正的目標是 Mac Studio M3 Ultra，擁有 512GB 記憶體與三倍的記憶體頻寬。
同樣測試 Llama 3.1 8B：
| 指標 | Spark 獨自 | Mac Studio 獨自 | Disaggregated |
|---|---|---|---|
| Prefill 4K (tok/s) | 1,585 | 1,420 | 1,584 |
| Decode (tok/s) | 14 | 106 | 84 |
Disaggregated 的 decode 84 tok/s 雖然比 Mac Studio 單機的 106 略低（KV Cache 注入 overhead 吃掉約 20%），但已經是 Spark 單機 14 tok/s 的 6 倍。而 50Gb 網路鏈路只增加約 18 毫秒的 overhead，幾乎可以忽略。頻寬假說在 8B 模型上完全成立，Mac Studio 解碼是 Spark 的 8 倍快，而 disaggregated 方案成功保留了這個優勢。
放大模型：32B 與 27B 測試
接下來 Jeff 把模型放大。Qwen 2.5 32B（BF16 on Spark、4-bit on Mac Studio）：
- Spark 獨自 prefill：875 tok/s
- Mac Studio 獨自 prefill：356 tok/s
- Disaggregated：792 tok/s（追蹤 Spark 水準）
Gemma 2 27B 也是類似模式：Spark 779、Mac Studio 379、Disaggregated 722。
有趣的是，當模型從 8B 放大到 27B/32B 時，Mac Studio 在 decode 上的優勢反而縮小了：8B 時 Mac Studio decode 是 Spark 的 8 倍快；到了 27B-32B，差距縮小到僅 1.25-1.3 倍。這是因為大模型的架構特性，Gemma 的 sliding window attention 與 Qwen 的 kernel fusion，降低了 decode 階段的頻寬需求，讓 Spark 的 decode 表現相對變好了。
誠實結論：酷炫但一張 RTX Pro 6000 可能更強
在展示完所有數據後，Jeff 給了這段令人印象深刻的總結：
「作為異質推論的概念驗證，這真的很酷。如果你已經擁有這兩台機器，那很好，試著多榨一點 Juice 出來吧。但現實是，DGX Spark 和 Mac Studio 都不便宜。如果我要花這種錢買新的桌上設備，我寧可去買一張 RTX Pro 6000，圍繞它打造一台主機。」
這不是客套話。一張 RTX Pro 6000（Blackwell 工作站顯卡）的記憶體頻寬是 GB10 的 6 倍、算力是 3.5 倍，很可能在 prefill 和 decode 兩端都打爆這兩台機器的組合。
有興趣的朋友可以去看看 Jeff 這次的瘋狂實驗，雖然結果不如人意就是了：
EXO 與 Nvidia 也在做同樣的事
Jeff 的實驗並非孤例。開源框架 Exo 一直以來都在推動「把任何設備變成 AI 推論叢集」的願景——無論是桌機、筆電、伺服器，甚至智慧型手機，都能加入協作網格。
EXO Labs 自身的測試顯示，用兩台 DGX Spark 搭配一台 M3 Ultra Mac Studio，在 Llama 3.1 8B 上可達到 2.8 倍的整體加速，匹配 Spark 的 prefill 速度同時保有 Mac Studio 的快速生成時間。
Nvidia 自己也看到了這個趨勢。其即將推出的 Rubin CPX 平台，將使用運算密集的 Rubin CPX 處理器負責 prefill，標準 Rubin 晶片則以大量 HBM3e 頻寬處理 decode，與 Exo 和 Jeff 在一般消費硬體上展示的原則完全相同。
結語
Jeff Geerling 的實驗雖然誠實地承認了「單張 RTX Pro 6000 可能更實用」，但它證明了 disaggregated inference 完全可以在消費級硬體上運作，即使需要繞過 mDNS 的 bug、自製 Thunderbolt 外接網卡、編譯各種 kernel。
更重要的是，它展示了 AI 硬體生態正在走向一條不以「單一超級晶片」為唯一解的道路。在消費市場上，我們可能很快就會看到更多這種異質運算的組合：買一台 Blackwell GPU 設備做 prefill、配一台 Apple Silicon 設備做 decode——各取所長。Nvidia 的 Rubin 架構已經在資料中心層級擁抱這個概念，它何時下放到桌面，只是時間問題。
但如果你問 Jeff 的建議？「買一張 RTX Pro 6000，謝謝。」