老實說，我感到很驚訝。當我將兩台 DGX Spark 單元組成叢集並執行 DeepSeek-V4-Flash 時，與 Mac Studio M3 Ultra 相比，總生成時間（實際掛鐘時間）快了 1.78 倍——這表示它在大約一半的時間內就完成了任務。而且這是在 DGX Spark 執行官方的 FP8 模型、沒有進行任何額外量化情況下得到的結果。
在進行這些基準測試時，我覺得我一直以來反覆強調的觀點再次得到了數據的證實。那就是：
LLM 的效能不能僅用基於記憶體頻寬的解碼速度（每秒 tokens，TPS）來衡量。
GPU 的運算能力、節點間的溝通、記憶體層級結構、量化品質、上下文長度、平行處理等等——所有這些因素的「平衡」決定了實際的使用者體驗。而 DGX Spark 就是擁有更好的平衡性。
使用的基準測試：shi3z 的程式設計基準測試
在測量方面，我使用了來自 shi3z 的日語 LLM 基準測試的程式設計基準測試。任務是「在單次生成中完成一個在 React 上運行的聊天應用程式」。生成的程式碼實際上會在 Docker 中啟動，並使用 Playwright 自動測試登入、好友、私訊和即時更新等功能，最後得到一個滿分 80 分的功能評分。
在 Mac Studio M3 Ultra 上透過 antirez 的 ds4 推理引擎執行 DeepSeek-V4-Flash Q4（4 位元量化）的結果已列在 shi3z 的儲存庫中。下面的表格將這些結果與這次 DGX Spark 2 單元叢集 + 官方 FP8 的結果進行了比較。
基準測試結果
為何「tok/s 輸了，但掛鐘時間卻贏了」
如果你看著表格心想：「等等，Mac 在 tok/s 方面比較快」，你是對的。只看吐出單個 token 的即時速度（解碼 TPS），Mac Studio M3 Ultra 快了 1.58 倍。這歸功於 Apple Silicon 巨大的記憶體頻寬。
但這裡有個陷阱。為了完成同一個「80/80 滿分」的聊天應用程式，Mac 寫了 8,036 個 tokens，而 DGX Spark 只寫了 2,866 個 tokens。 這大約是 2.8 倍的差距。
兩者都使用官方宣稱品質無損的 DeepSeek-V4-Flash，但很自然地可以推斷，量化到 Q4 的 Mac 端輸出變得冗長，而以全品質 FP8 運行的 Spark 端則保持了簡潔。量化對輸出分佈的影響不會表現在解碼速度上，但會悄悄地影響生成策略，這是一個常見的現象。
因此，計算結果如下：
實際掛鐘時間 = (輸出 Tokens) ÷ (tok/s)
Mac：8,036 ÷ 26.2 = 307 秒 我們：2,866 ÷ 16.6 = 172 秒
在 tok/s 上輸了，但在掛鐘時間上贏了，這意味著「用更少的步驟達到了同樣的正確答案」。在實際使用中，人類感受到的是「任務完成的時間」，而非即時的 tok/s。
使用的配置
- 硬體：DGX Spark × 2（NVIDIA GB10，Blackwell 架構，每個 128 GB 統一記憶體）
- 節點互連：透過 ConnectX-7 200 Gbps RoCE 直接連接（Tensor Parallel = 2，PyTorch 分散式後端）
- 推理引擎：Aiden 的方案，將 b12x（一組 GB10 專用的 CuTe DSL 核心）整合到 vLLM 0.21.1dev 中
- 模型：DeepSeek-V4-Flash 官方 FP8（154 GB，FP8 注意力，MXFP4 MoE——這是 DeepSeek 發布的官方格式）
- 上下文：524,288 tokens（512K），util 0.82，KV 快取 19.85 GiB，並發度 3.89×
- 多 Token 預測（MTP）：投機解碼，接受率約 62%（在不犧牲輸出品質的情況下提升速度）
深入檢視效能
除了這個基準測試的數字之外，我另外測量了純解碼和預填充的速度：
- 純解碼速度（短文本，排除 TTFT）：穩定在約 39 tok/s
- 預填充速度（大型上下文）：1,277 tok/s（這比沒有 b12x 核心的舊配置的 196 tok/s 快了約 6.5 倍）
- 長上下文下的解碼：即使我從 8K → 64K → 128K → 256K → 512K → 768K 逐步增加，解碼速度並沒有急劇下降；實際上反而加速了（在 768K 時為 106 tok/s）。這是因為 DeepSeek 的稀疏注意力（DSA）在 b12x 核心中原生實現，使得注意力計算幾乎與上下文長度無關。
這是「無量化、全品質」的結果
我想強調的另一點是，DGX Spark 端沒有對模型進行任何額外的量化。我們直接載入了 HuggingFace 上分發的官方 154 GB 模型，並以 DeepSeek 設計的官方量化格式執行：FP8 注意力 + MXFP4 MoE。
在本地 LLM 的世界裡，將巨大模型壓縮到 IQ2（2 位元）或 Q4 以使其能夠運行，已經成為常識，但這些做法肯定會削減品質。事實上，我先前嘗試過 DeepSeek-V4-Flash 的 IQ2XXS（2 位元）版本，在同一個基準測試中看到了 55/80 分加上 Agent 行為崩潰的結果。量化不是免費的午餐。
一個能夠用兩台 DGX Spark 確保 256 GB 統一記憶體的配置，首次讓「以全品質運行巨大模型」這個選項成為現實。我認為這比數字所顯示的更具意義。
為何 Spark 的「平衡性」奏效了
分解支持這個結果的技術要素：
- b12x 核心套件：使用 CuTe DSL 專門為 GB10 / SM12.x 編寫的四種核心（NVFP4 融合 MoE GEMM、NVFP4 密集 GEMM、FP8 分頁注意力和稀疏 MLA 注意力）。與一般 vLLM 中的 MARLIN 路徑不同，這些核心以融合模式直接計算，無需反量化。
- 200 Gbps RoCE 直接連接：雖然 TP=2 節點間的全域歸約每層發生兩次，但 200 Gbps 的直接連接保持了有效的低延遲，使其不會成為解碼的瓶頸。
- 128 GB 統一記憶體 × 2：這是 Grace Blackwell 的優勢，它沒有區分 HBM 和 DDR。這使得 154 GB 的官方 FP8 模型可以按原樣分割到兩個單元上，並為 512K 上下文的 19.85 GiB KV 快取留下了足夠的空間。
- DeepSeek 稀疏注意力（DSA）的原生實現：b12x 核心正確處理了這種設計，利用 GB10 的原生稀疏運算，使注意力複雜度不依賴於上下文長度。這導致了解碼速度不會隨上下文長度而暴跌的結果。
換句話說，如果這些要素中只有一項——記憶體頻寬、運算能力、節點通訊、長上下文最佳化或量化品質——表現突出，這個結果就不會發生。Spark 在同價位範圍內，以高於任何單機配置的水平提供了所有這些要素。這就是其「平衡性」的真正本質。
實際使用中會有哪些改變？
為了超越抽象理論，這裡列出一些具體的好處：
- 大型文件的摘要和程式碼分析變得切實可行：憑藉 512K 上下文和 1,277 tok/s 的預填充速度，你可以在大約 4 分鐘內載入並摘要一整本書（約 300,000 tokens）。
- Agent 循環不會卡住：憑藉 3.89× 的並發度，你可以同時運行聊天和長篇摘要（例如，使用 Hermes Agent），而不會導致解碼崩潰。
- 不會因量化失敗而產生「Agent 只會空談」的問題：這是我在 IQ2 系列模型上多次掉入的陷阱；使用全品質時，這種情況根本不會發生。
- 在功耗方面與 Mac 具有競爭力：推理時兩個 GB10 的總功耗約為 100W–140W，接近滿載時的 Mac Studio M3 Ultra。考慮到 1.78 倍的效能，能效表現也不差。
結論：僅用 TPS 評判 LLM 效能的時代已經結束
吐出 token 的即時速度——解碼 TPS——當然是一個重要的指標。然而，這就像「100 公尺衝刺的極速」。實際需要的是「達到同樣正確答案所需的時間」、「答案的品質」、「能同時運行多少個」、「能處理多長的上下文」以及「Agent 循環是否有效」。這些才是總分。
這個結果所顯示的是，DGX Spark 在總分上開始領先。我們已經進入了一個時代，只需將兩台設備叢集連接，就能以官方品質、長上下文、同時保持 Agent 相容性，以 Mac Studio 1.78 倍的掛鐘速度運行巨大模型。
在過去幾年中，人們常說「LLM 全靠記憶體頻寬」和「解碼 TPS 就是一切」，但在實際運行 Spark 之後，我覺得我的「平衡性才是實際效能」的主張終於得到了數字的證實。
RTX Spark 也發布了，感覺事情比預期還要激烈（雖然價格出來後氣氛可能會冷卻...）。我對社群的成長以及更多最佳化和專業知識的積累抱有很高的期望！
黃仁勳真是太厲害了……他的統治會持續很久嗎？
**
**
**
**
**
額外補充
敏銳的讀者可能會有這樣的批評：
「那麼，在 Mac Studio 上也運行原始的官方 FP8 來比較，不是更公平嗎？」
「這樣的比較不公平吧？Mac Studio 只是因為量化到了 Q4 才變得冗長。如果在 Mac Studio 上運行原始的官方 FP8，在品質上不是站在同樣的基礎上嗎？」這是個合理的問題。
直接說結論：目前，沒有辦法在 Mac Studio 上以實用速度運行「原始的官方 FP8 + MXFP4 MoE」。
- 首先，沒有相容的推理引擎。
似乎沒有一個引擎能在 Apple Silicon 上完全支援 DeepSeek-V4-Flash 的官方格式（FP8 注意力 + MXFP4 MoE + Lightning Indexer + DSA 稀疏注意力）（根據 Claude Code 的搜尋結果）。
- MLX（Apple 官方的 Apple Silicon LLM 框架）：沒有 MXFP4 MoE 融合 GEMM 的原生實現，沒有 FP8 分頁注意力，也沒有 DeepSeek DSA 稀疏注意力的 MLX 實現。如果試圖運行，很可能需要向上轉換為 bf16。
- llama.cpp：無法直接載入 MXFP4，因此需要重新量化為 GGUF = 最終會轉換為 Q4 / Q5 / IQ2 等，不再是「原始官方」版本。
- vLLM：Apple Silicon 的支援本身就有限，而且像 b12x 這樣的 GB10 專用核心無法在 Mac 上運行。
- antirez/ds4：這是一個基於 MLX 編寫的專用引擎，專門針對 DeepSeek V4 Flash 並假設使用 Q4。這是在 Mac Studio 上運行它的當前最佳解決方案，但它並不是為了處理「原始 FP8」而構建的。
antirez 為 DeepSeek V4 Flash 專門編寫了一個針對 Q4 的專用引擎，這恰恰說明了目前還沒有在 Apple Silicon 上按原始品質運行的實用途徑。
- 即使使用 bf16 向上轉換運行，頻寬也幾乎會被完全耗盡。
為了便於討論，假設有人創建了一個 MLX 實現，將官方權重向上轉換為 bf16。你可以用粗略的頻寬計算來估計會發生什麼：
- DeepSeek-V4-Flash 的 MoE 配置約有 300 億個活躍參數。
- 在 Q4（4 位元）下，活躍參數約佔 15 GB，ds4 達到了 26.2 tok/s（已測量）。
- 如果同一個模型以 FP8（8 位元）保存，活躍參數約佔 30 GB = 頻寬需求增加 2 倍 = 在同一引擎上理論上約為 13 tok/s。
- 此外，在 MLX 中向上轉換為 bf16 會使活躍參數約佔 60 GB = 頻寬需求增加 4 倍 = 理論上約為 6.5 tok/s。
- 由於 Mac Studio M3 Ultra 的有效記憶體頻寬約為 800 GB/s，每個 token 讀取 60 GB 將會達到頻寬上限。
換句話說，目前在 Apple Silicon 上選擇「原始品質」的代價是「犧牲超過一倍的速度」。使用 ds4 + Q4 達到 26.2 tok/s 比使用全品質 bf16 僅獲得 6 tok/s 是更實用的選擇。
- 這就是 Spark 的結構性優勢所在。
另一方面，這個 DGX Spark 配置「原生地」運行了「原始官方 FP8 + MXFP4 MoE」。這得益於：
- b12x 這套 GB10 專用核心，它具有「無需反量化」即可運行 NVFP4 融合 MoE GEMM 和 FP8 分頁注意力的實現。
- 這尚未為 Apple Silicon 編寫。
- 因此，Spark 目前是唯一能實現「原始官方品質」和「實用速度」的現實解決方案。
總結來說，如果只看硬體頻寬，Mac Studio 單一單元的絕對值處於相似水平，但「能夠原生運行官方量化格式的核心實現的有無」造成了決定性的差異。Spark 的優勢不僅來自晶片，還來自與 b12x 等 GB10 專用軟體堆疊的整體組合。
如果未來有人為 Apple Silicon 在 MLX 中編寫 MXFP4 融合 MoE GEMM、FP8 分頁注意力和 DSA 稀疏注意力，這個前提將會瓦解。情況將取決於社群實現而改變。目前的事實是，Spark 在達成「官方品質 × 實用速度」的組合方面領先了一步。
以上就是 Claude Code 提供的分析結果。
