每當人們談起NVIDIA DGX Spark，首先想到的往往是兩件事。第一是它的核心規格：一台售價約4,000美元的桌上型設備，卻配備了128GB的統一記憶體。即使在兩年前，這樣的配置也讓人難以置信。第二是設備背面的200GB網路介面。桌面設備上擁有真正的資料中心級網路架構，這才是真正吸引人的地方，因為它不僅僅意味著一台速度更快的單機工作站，更意味著可以連接多個Spark伺服器並進行實體複製，這種多節點部署方式過去只能在機架中實現。
本次評測旨在檢視該能力。我們對所有三個 OEM Spark 實作（均基於 200 Gb 的互連網路）進行了分散式推理基準測試，測試物件包括我們手頭上的三個 OEM Spark 實現，並將它們兩兩配對組成雙節點叢集。測試涵蓋了不同的模型變體和三種工作負載類型。此外，我們也刻意採用了一種不同於 NVIDIA 預設建議的模型分配方法，並以資料加以論證。不過，在此之前，有兩個關鍵因素會影響後續的討論：首先是實現集群的網絡，其次是用戶可能選擇或不選擇使用集群的原因。
200 GB Fabric
我們在先前的 DGX Spark 評測中詳細介紹了網路實現，但基本原理值得重申，因為本次評測的所有內容都基於此。每台 Spark 的背面都配備兩個 QSFP56 插槽，由整合的 NVIDIA ConnectX-7 智慧網路卡驅動。理論上，這兩個插槽可提供 400Gb 的總連接容量，但 PCIe 才是真正的瓶頸：ConnectX-7 位於兩個 Gen5 x4 連結之後，無論插槽如何連接，該平台的可用頻寬上限均為 200Gb。單一 QSFP56 插槽即可提供裝置支援的全部 200Gb 頻寬，因此第二個連接埠的作用更多在於拓撲結構的靈活性，而非額外的吞吐量。
這種靈活性體現在三種常見配置中。最簡單的配置是使用一個 200 Gb 連接埠作為 Spark 之間的直接連結，NVIDIA 驗證的雙節點設定就採用了這種配置，這也是我們本次評測所使用的配置。第二種配置是使用兩個 100 Gb 連接埠在 Spark 之間建立環形拓撲結構，無需交換器即可實現叢集。第三種配置是角色分離配置，其中一個連接埠連接到用於叢集的對等 Spark，另一個連接埠連接到透過 NVMe-oF 協定傳輸的高速儲存設備，這種配置在工作資料集無法放入 Spark 內部 NVMe 儲存時非常有用。
NVIDIA 銷售的 Spark 提供三種配置，分別對應不同的網路使用場景。單 Spark 適用於個人桌面工作；經過驗證的雙 Spark 叢集透過 200 Gb 的互連架構直接連接，適用於擴展型機型；而今年 GTC 大會上，NVIDIA 也公開展示了四節點配置，以響應用戶突破雙節點限制的需求。雙 Spark 配置是 NVIDIA 積極推廣的配置，也是大多數讀者實際部署的配置，我們認為它代表了該硬體在生產級推理方面的合理上限。本次評測也正是基於此組態進行端對端基準測試。
為什麼要先使用集群火花？
Spark叢集的顯而易見的優勢與其他任何叢集一樣：一台128GB的伺服器無法容納所有重要的模型。將一個120億參數的模型擴展到兩台伺服器上，可以運行一些原本無法處理的工作負載。這是Spark叢集最主要的用例，也是示範最多的用例。
不太明顯的原因，但對於NVIDIA在該平台上的實際客戶群來說，或許更為重要，那就是學習。 NVIDIA將Spark定位為入門級產品。 官方文件範例筆記本和合作夥伴手冊將這套設備視為教學工具。它們提供了一流的指南，涵蓋了從在本地聊天介面後啟動預構建模型、到針對託管端點運行編碼助手、再到微調小型模型以及使用 PyTorch 和 JAX 構建端到端應用程式等方方面面。其理念是，即使是從未編寫過 CUDA 核心的人，也能在周末內從零開始建立一個可用的 AI 工作流程。對於非機器學習領域的工程師來說，如果他們想要一個完全可控的獨立沙箱環境，也能輕鬆實現。雙 Spark 叢集將教學範圍擴展到了多節點領域：同一個人現在還可以學習張量並行、管線並行和集體通訊庫的實際運作方式，並且該網路足夠真實，能夠暴露真正的瓶頸。
然而，NVIDIA 本身的產品定位中卻明顯缺少了「Spark 適用於生產級推理服務」這一說法。過去幾年，Jensen 幾乎在每次主題演講中都談到了軟硬體協同設計，而這項原則也適用於 Spark。每個 NVIDIA 平台都針對特定的工作負載進行了最佳化，Spark 針對的是獨立的探索和學習，而非流量服務。我們先前的 Spark 評測已經表明，該平台在大多數推理任務中都嚴重受限於記憶體頻寬，而一旦進行集群，網路頻寬的限制就會更加明顯。雖然 200 Gb 的單一連結對於桌面等級來說已經相當不錯，但與單一機殼內的 PCIe Gen5 x16 連線相比，速度明顯較慢。在資料中心 GPU 之間透過 NVLink 橋接流暢的集體通訊模式，一旦遷移到 200 Gb 的網路架構，就會產生明顯的延遲損失。
這正是NVIDIA長期以來將官方支援的配置限制在兩台Spark的真正原因，也是GTC大會上四台Spark的演示是為了響應用戶需求而非產品自然擴展的原因。軟體堆疊完全可以運行在四台或八台節點上，許多用戶和媒體也發布了更大規模叢集的測試結果。但這些實驗的性能數據通常並不理想：節點間互連成為主要的性能瓶頸，整體性能急劇下降；此外，對於任何足以支撐集群規模的用戶模型，在這些配置的末端，每個用戶的吞吐量都可能降至每秒個位數令牌。此時，這套系統其實更像是學習實驗室，而非服務平台。
這並非否定Spark集群。 Spark叢集確實是一種極佳的方式，能夠幫助我們培養對分散式推理和訓練的直覺，而這種直覺通常需要價值數十萬美元的資料中心硬體才能實現。能夠在自己擁有的系統上實際觀察流水線氣泡、全歸約瓶頸和並行權衡等問題，其教育價值非常顯著。我們原本計劃更進一步，在雙Spark集群上從零開始訓練一個小型1億參數或小於1億參數的模型。我們選擇的設定盡可能模擬真實分散式預訓練運行的條件，以便準確展示此類叢集的適用範圍和限制。目前，由於我們正在處理其他一些您可能已經看到的內容，並且等待新的800Gb實驗室核心交換機的光纖到貨，該項目暫時擱置。我們預計在實驗室搭建完成後會重新開始研究。
接下來將重點介紹雙 Spark 配置最適用的用例：對規模足夠大、需要兩台設備才能運行的模型進行分散式推理，並對我們手頭上所有三家 OEM 廠商的實現方案進行了基準測試。在給出每個模型的具體數據之前，下一節將解釋為什麼我們採用管線並行配置而非 NVIDIA 官方文件通常預設的張量並行配置來報告這些數據。
性能測試
為什麼我們報告的是管線並行，而不是張量並行？
英偉達發布的 DGX Spark 指南 他們的大部分參考資料都依賴張量並行（TP）來描述如何在兩個 Spark 伺服器上擴展模型。 TP 將每個矩陣乘法運算分配到兩個 GPU 上，因此每一層都在兩個裝置上同時運行，並且在每個注意力機制和 MLP 模組之後，透過 all-reduce 操作將部分結果合併。管線並行（PP）則採用了不同的方法：它按層將模型一分為二，將前半部放在一個伺服器上，後半部放在另一個伺服器上，然後在它們之間傳輸啟動值。每個請求仍然會流經整個模型，但在任何給定時刻，只有一個伺服器在處理給定標記的計算，而另一個伺服器則在處理下一個微批次。
權衡的關鍵在於網路傳輸的資料量。雙 Spark 堆疊透過 ConnectX-7 200 GbE 連結連接兩個系統，這條連結對於網路連結來說速度很快，但與單一 Spark 的記憶體頻寬相比卻很慢。 TP 的 all-reduce 操作在每個 Transformer 層觸發兩次，因此，一個運行 TP=2 的 80 層模型對於每個輸出令牌都會產生 160 次跨盒交換，而每次交換都會阻塞下一次計算。 PP=2 則每個令牌只在模型兩部分之間的連接處傳遞一次啟動。在延遲不低的 200 GbE 連結上，這種差異會壓倒其他所有因素。
我們的 GPT-OSS-120B 測試結果清楚地證實了這一點。除了批次大小為 1 的情況（此時工作負載過小，無法掩蓋兩種策略的開銷）之外，PP=2 始終領先，並且隨著並發量的增加保持領先優勢。在 Equal ISL/OSL 工作負載下，TP=2 在批次大小為 128 時達到 252.01 tok/s，而 PP=2 在相同硬體上則攀升至 554.69 tok/s，優勢高達 2.20 倍。 Prefill Heavy 也呈現類似的趨勢，PP=2 的最終速度為 310.63 tok/s，而 TP=2 為 164.99 tok/s。 Decode Heavy 場景是三種場景中最接近的，但 PP=2 在批次大小為 8 到 64 時仍然領先，只有在批次大小為 128 時略微落後，這是因為 8K 的長輸出放大了流水線氣泡的成本。
TP=2 的確存在一個優勢明顯的視窗期。在所有場景下，當批次大小為 1 時，TP 都能帶來雖小但切實的優勢：在 Equal 場景中為 39.55 tok/s 對比 28.79 tok/s，在 Prefill Heavy 場景中為 37.97 tok/s 對比 29.60 tok/ 30.28 tok/s。由於只有一個請求正在處理，沒有第二個微批處理來保持空閒管線階段的運行，因此 PP 需要為每一步的空閒插槽付費，而 TP 則可以利用兩個 GPU 處理唯一的令牌。 NVIDIA 的 TP 指南正是針對這種情況而設計的：互動式單流服務，其中第一個也是唯一一個請求的延遲比總吞吐量更為重要。如果部署真正是聊天式的，每個裝置只有一個用戶，而且 TTFT 目標很嚴格，那麼 TP=2 是正確的選擇，這也與 NVIDIA 對 Spark 的看法一致。
對於大規模服務基礎架構的工作負載，如果採用批量推理和大量並發請求，那麼在跨伺服器擴展時，管道並行（Pipeline Parallelism）是更合適的選擇，尤其是在不使用專家並行（Expert Parallelism）等策略的情況下。 200 GbE 網路無法在不造成運算資源閒置的情況下支援管道並行（TP）的逐令牌全歸約流量，而一旦批次大小達到 4 或 8，專家並行（PP）的初始開銷就會融入穩定流中。因此，本文後續部分中每個模型的計算結果均基於 TP=1 和 PP=2 的配置。這種配置能夠真實反映雙 Spark 部署在實際工作中能夠達到的效能水準。
我們特意選擇 GPT-OSS-120B 作為 TP 與 PP 比較圖表的主角，因為它展現了最大的差距。然而，我們也想說明，並非所有模型都如此，而且這些參數取決於模型的特定參數。 BF16 上的 Llama-3.1-8B-Instruct 模型則呈現較為保守的情況。此模型規模較小，因此每一層的計算速度都很快，TP 的 all-reduce 流量也相應較低。相較之下，PP 的每步驟協調成本是固定的，與模型規模無關。因此，在幾乎整個批次掃描過程中，TP=2 都保持領先。在 ISL/OSL 相等的測試中，TP=2 從批次大小 1（23.2 對 13.4 tok/s）到批次大小 32（388.7 對 349.3 tok/s）都保持領先，僅在批次大小 64（524.8 對 638.2 tok/s. tok/s）時落後 PP=2。預填充重型測試也遵循相同的模式，TP=2 在批次大小 32 之前一直領先，之後 PP=2 在批次大小 64 和 128 時反超。解碼重型測試的結果最為顯著：TP=2 在所有批次大小下都勝出，在批次大小 128 時以 366.7 tok/s 的速度領先於 PP=2 的 330.5 tok/s。
這個反例強化而非否定了背後的機制。 PP=2 只有在批次大小足夠大，能夠填滿流水線並完全攤銷氣泡成本，且模型本身足夠小，使得 TP 的每層全歸約成本很低時才能勝出；這個臨界點會被進一步推遲。解碼密集型測試的結果也與之一致：更長的輸出序列意味著更多的解碼步驟，更多的管線氣泡需要連續支付，以及 PP 彌補差距的時間窗口更小。換句話說，PP 在批次大小為 128 時在 GPT-OSS-120B 上取得 2.20 倍優勢的物理機制，也解釋了為什麼它在 8B 模型上只在前兩個批次大小下勝出，並且從未在解碼密集型測試中獲勝。
GPT-OSS-120B
在 ISL/OSL 相等的測試中，戴爾的初始速度為 67.06 tok/s，批次大小為 64 時可達 927.93 tok/s。技嘉的初始速度略低，為 65.77 tok/s，但最終以 994.53 tok/s 的成績收尾，而惠普則以 1,009.75 tok/s 的速度領跑。在整個測試過程中，各廠商之間的差距一直很小，惠普從批次大小 32 開始逐漸領先。
在預填重型列印模式下，各廠商的吞吐量全面大幅提升。戴爾的吞吐量從 164.42 tok/s 提升至 2,097.80 tok/s，技嘉從 162.96 tok/s 提升至 2,086.72 tok/s，而惠普的表現最為突出，從 165.95 tok/s 躍升至 2,208.16。惠普幾乎在所有批次大小下都處於領先地位，而戴爾和技嘉的吞吐量則非常接近，尤其是在批次大小為 32 和 64 時。
在解碼密集型任務中，整體效能較低，這與解碼工作負載的預期相符。戴爾的解碼速度範圍為 41.20 tok/s 至 563.98 tok/s，技嘉為 40.83 tok/s 至 617.96 tok/s，惠普為 41.63 tok/s 至 593.56 tok/s。技嘉在批處理大小為 64 時表現最佳，惠普在中等性能水平上領先，戴爾緊隨其後，但在更高並發量下略遜一籌。
GPT-OSS-20B
在 ISL/OSL 相等的測試中，戴爾在大部分測試中都處於領先地位，其處理速度從批次大小為 1 時的 88.73 tok/s 提升至批次大小為 64 時的 1,953.55 tok/s。技嘉緊隨其後，處理速度從 88.42 tok/s 提升至 1,904.62 tok/s，而惠普的處理速度則在 83.49 tok/s 至 1,831.45 tok/s 之間波動。戴爾的整體性能保持著最強的高端擴展性，尤其是在批次大小從 16 開始。
在預填重載測試中，三款系統的吞吐量均呈現快速成長。戴爾在此測試中表現最佳，批次大小為 64 時，吞吐量從 216.05 tok/s 提升至 4,261.96 tok/s。技嘉緊隨其後，吞吐量為 4,011.86 tok/s，惠普則達到 3,785.25 tok/s。在較小的批次大小下，三款系統的效能差距並不大，但從批次大小 16 開始，戴爾開始拉開差距，並在後續測試中保持領先優勢。
在解碼重任務中，效能提升較為平緩，但在所有平台上均保持強勁動能。戴爾的性能從 54.88 tok/s 提升至 1,173.31 tok/s，技嘉從 55.24 tok/s 提升至 1,181.94 tok/s，惠普則從 53.20 tok/s 提升至 1,082.23 tok/s。在最高批次大小下，技嘉略勝戴爾一籌，而惠普在高並發級別下則落後於這兩家系統。
Llama 3.1 8B 指令基礎
在 ISL/OSL 相等的測試中，戴爾在批次大小為 64 時，效能從 27.69 tok/s 提升至 1,376.38 tok/s，略微領先於技嘉（27.23 tok/s 至 1,372.27 tok/s）。惠普在整個測試過程中略微落後，性能從 26.89 tok/s 提升至 1,235.32 tok/s。在批次大小為 16 之前，三款系統的性能非常接近，之後戴爾在更高的並發級別下開始略微領先。
在預填重型列印任務中，隨著批次大小的增加，吞吐量顯著提升。戴爾的吞吐量從 68.60 tok/s 成長到 2,575.25 tok/s，而技嘉的表現最為出色，在批次大小為 64 時，吞吐量從 67.49 tok/s 提升至 2,694.25 tok/s。惠普的吞吐量達到 2,315.15 tok/s，保持了一定的競爭力，但在較高批次大小下始終落後於戴爾和技嘉。技嘉在高端市場佔據領先地位，尤其是在批次大小為 64 或更大時。
在解碼重任務測試中，各平台的效能提升幅度維持穩定。戴爾的解碼速度範圍為 17.19 tok/s 至 726.22 tok/s，技嘉為 16.96 tok/s 至 720.57 tok/s，惠普為 16.79 tok/s 至 663.31 tok/s。在大部分測試過程中，戴爾和技嘉的表現幾乎不相上下，僅在併發量較高時戴爾略佔優勢。而惠普在大批量處理時性能則略遜一籌。
Llama 3.1 8B 指令 FP4
在 ISL/OSL 相等的測試環境中，戴爾在批次大小為 64 時，效能從 69.71 tok/s 提升至 2,849.20 tok/s，而技嘉略勝一籌，效能從 70.92 tok/s 提升至 2,912.03 tok/s。惠普的性能也保持競爭力，範圍在 69.52 tok/s 至 2,821.50 tok/s 之間。這三款系統在整個工作負載下效能表現都非常接近，只有在高並發等級下才出現微小的差距。
在預填充重負載測試中，效能擴展性顯著提升，尤其是在較大批次規模下。戴爾的吞吐量從 170.09 tok/s 提升至 4,417.65 tok/s，而技嘉的表現最為出色，在批次規模為 64 時，吞吐量從 173.55 tok/s 提升至 4,767.43 tok/s。惠普的吞吐量也從 170.12 tok/s 提升至 4,214.57 tok/s。技嘉在批次規模達到 32 後開始與其他廠商拉開差距，在該工作負載下實現了最高的吞吐量。
在解碼重任務測試中，三款系統在大部分測試時間內效能依然保持接近。戴爾的性能範圍為 43.19 tok/s 至 1,260.24 tok/s，技嘉的性能範圍為 43.53 tok/s 至 1,258.05 tok/s，惠普的性能範圍為 42.54 tok/s 至 1,178.74 tok/s。戴爾和技嘉的性能會根據批次大小交替領先，而惠普在最大並發量下略遜於這兩款系統。
Llama 3.1 8B 指令 FP8
在 ISL/OSL 相等的測試中，戴爾在批次大小為 64 時，效能從 46.93 tok/s 提升至 2,206.52 tok/s，而技嘉則從 46.16 tok/s 提升至 2,175.44 tok/s。惠普緊隨其後，性能從 46.40 tok/s 提升至 2,149.15 tok/s。在整個測試過程中，三款系統的效能差距始終保持在較小範圍內，在批次大小達到 32 之前，它們的效能提升表現幾乎完全相同。
在預填重載測試中，隨著同時數量的增加，吞吐量提升更為顯著。戴爾的吞吐量從 115.85 tok/s 成長到 3,794.52 tok/s，而技嘉的整體表現最為出色，在批次大小為 64 時，吞吐量從 113.34 tok/s 提升至 4,133.76 tok/s。惠普的吞吐量達到 3,624.73 tok/s。技嘉在高批次大小下，尤其是在批次大小從 32 開始，優勢更加明顯。
在解碼重載任務中，三款系統在低並發水平下性能接近，但在高並發水平下才出現細微差距。戴爾的性能範圍為 29.11 tok/s 至 1,077.07 tok/s，技嘉的性能範圍為 28.64 tok/s 至 1,068.92 tok/s，惠普的性能範圍為 28.68 tok/s 至 1,000.20 tok/s。戴爾在大部分工作負載下保持著微弱的領先優勢，技嘉緊隨其後，而惠普在大批量處理時略遜一籌。
米斯特拉爾小型 3.1 24B
在 ISL/OSL 相等的測試中，戴爾在批次大小為 64 時，性能從 10.41 tok/s 提升至 498.56 tok/s，而技嘉在性能上限略勝一籌，從 9.76 tok/s 提升至 509.18 tok/s。惠普的性能略遜於這兩款系統，範圍在 9.25 tok/s 至 477.25 tok/s 之間。在整個工作負載範圍內，各系統之間的差距始終相對較小，尤其是在中低並發水準下。
在預填重載任務中，三個系統的擴展性均顯著提升。戴爾的性能從 25.91 tok/s 提升至 1,079.19 tok/s，技嘉的性能也從 24.25 tok/s 提升至 1,071.07 tok/s。惠普在批次大小為 64 時達到了 988.82 tok/s。在大部分測試階段，戴爾和技嘉的性能幾乎不相上下，僅在最高並發級別下戴爾略佔優勢。
在解碼密集型任務中，整體吞吐量仍然顯著降低，這與預期相符，畢竟解碼工作負載集中在較大尺寸的機型上。戴爾的吞吐量範圍為 6.49 tok/s 至 297.82 tok/s，技嘉為 6.10 tok/s 至 297.23 tok/s，惠普為 5.77 tok/s 至 276.55 tok/s。戴爾和技嘉在整個測試過程中表現不相上下，而惠普在大批量處理時始終略遜於這兩家系統。
Qwen3 編碼器 30B A3B 基地
在 ISL/OSL 相等的測試條件下，戴爾在批次大小為 64 時，速度從 59.05 tok/s 提升至 817.82 tok/s，而技嘉的速度範圍為 59.81 tok/s 至 809.88 tok/s。惠普的性能略遜於這兩款系統，速度從 56.51 tok/s 提升至 780.21 tok/s。在大部分測試條件下，戴爾和技嘉的表現幾乎完全相同，僅在高批次大小下出現微小差異。
在預填重負載測試中，吞吐量隨著並發數的增加而顯著提升。戴爾的吞吐量從 144.81 tok/s 成長到 1,756.99 tok/s，而技嘉的整體擴展性最強，在批次大小為 64 時，吞吐量從 147.55 tok/s 增長到 1,862.40 tok/s。惠普的吞吐量達到 1,751.17 tok/s，保持了競爭力，但在高端性能上略遜於其他兩款系統。技嘉從批次大小約為 32 開始建立起一定的領先優勢，並在測試的最後階段保持了這一優勢。
在解碼密集型任務中，三款系統在大部分工作負載下效能依然非常接近。戴爾的性能範圍為 36.69 tok/s 至 427.48 tok/s，技嘉的性能範圍為 36.92 tok/s 至 417.42 tok/s，惠普的性能範圍為 35.30 tok/s 至 403.32 tok/s。在最大批次大小下，戴爾略佔優勢，而惠普在以解碼為主的工作負載下略遜於戴爾和技嘉。
Qwen3 程式設計師 30B A3B FB8
在 ISL/OSL 相等的情況下，戴爾在批次大小為 64 時，吞吐量從 98.65 tok/s 提升至 1,379.26 tok/s，而技嘉的吞吐量範圍為 100.20 tok/s 至 1,308.79 tok/s。惠普始終保持競爭力，吞吐量從 97.06 tok/s 提升至 1,354.23 tok/s。惠普在一些中低批次大小下曾短暫領先，但戴爾最終憑藉其整體最強勁的高端吞吐量脫穎而出。
在預填重型列印任務中，三款系統的吞吐量均實現了顯著提升。戴爾的吞吐量從 240.43 tok/s 增長至 3,041.72 tok/s，而技嘉的整體表現最為出色，在批次大小為 64 時，吞吐量從 245.92 tok/s 增長至 3,088.62 tok/s。惠普的吞吐量達到了 2,857.80 tok/s。技嘉從批次大小為 4 開始就建立了明顯的領先優勢，並在整個測試過程中保持了這一優勢。
在解碼重負載測試中，戴爾的整體高階擴充性最強。戴爾的解碼速度範圍為 60.91 tok/s 至 705.77 tok/s，技嘉為 61.53 tok/s 至 639.80 tok/s，惠普則從 59.85 tok/s 提升至 635.25 tok/s。惠普在小批量處理時曾短暫領先，但戴爾在高並發水平下更勝一籌，最終以最高的解碼吞吐量領跑該組。
雙火星塞系統峰值輸出概要
下表總結了在戴爾、技嘉和惠普雙Spark系統上進行分散式PP=2測試時觀察到的峰值令牌輸出吞吐量。每個值代表在測試批次大小下，該工作負載場景所達到的最高測量輸出吞吐量（tok/s）。粗體數字表示在該特定工作負載場景中表現最佳的系統。
| 型號 | 場景（BS – 64） | 戴爾峰值輸出 | 技嘉峰值輸出 | 馬力峰值輸出 |
|---|---|---|---|---|
| GPT-OSS模型 | ||||
| GPT-OSS-120B | 等同ISL/OSL | 463.97 噸/秒 | 497.26 噸/秒 | 504.88 噸/秒 |
| GPT-OSS-120B | 預填充重型 | 419.56 噸/秒 | 417.34 噸/秒 | 441.63 噸/秒 |
| GPT-OSS-120B | 解碼重 | 451.18 噸/秒 | 494.37 噸/秒 | 474.85 噸/秒 |
| GPT-OSS-20B | 等同ISL/OSL | 976.77 噸/秒 | 952.31 噸/秒 | 915.72 噸/秒 |
| GPT-OSS-20B | 預填充重型 | 852.39 噸/秒 | 802.37 噸/秒 | 757.05 噸/秒 |
| GPT-OSS-20B | 解碼重 | 938.65 噸/秒 | 945.55 噸/秒 | 865.78 噸/秒 |
| 羊駝模特兒 | ||||
| Llama-3.1-8B-指令 | 等同ISL/OSL | 689.53 噸/秒 | 687.48 噸/秒 | 618.87 噸/秒 |
| Llama-3.1-8B-指令 | 預填充重型 | 515.45 噸/秒 | 539.27 噸/秒 | 463.39 噸/秒 |
| Llama-3.1-8B-指令 | 解碼重 | 581.43 噸/秒 | 576.91 噸/秒 | 531.07 噸/秒 |
| Llama-3.1-8B-FP4 | 等同ISL/OSL | 1427.39 噸/秒 | 1458.86 噸/秒 | 1413.51 噸/秒 |
| Llama-3.1-8B-FP4 | 預填充重型 | 884.22 噸/秒 | 954.23 噸/秒 | 843.57 噸/秒 |
| Llama-3.1-8B-FP4 | 解碼重 | 1008.98 噸/秒 | 1007.23 噸/秒 | 943.73 噸/秒 |
| Llama-3.1-8B-FP8 | 等同ISL/OSL | 1105.42 噸/秒 | 1089.85 噸/秒 | 1076.68 噸/秒 |
| Llama-3.1-8B-FP8 | 預填充重型 | 759.50 噸/秒 | 827.40 噸/秒 | 725.51 噸/秒 |
| Llama-3.1-8B-FP8 | 解碼重 | 862.33 噸/秒 | 855.81 噸/秒 | 800.78 噸/秒 |
| Mistral 和 Qwen 模型 | ||||
| 米斯特拉爾-小型-3.1-24B | 等同ISL/OSL | 249.77 噸/秒 | 255.09 噸/秒 | 239.09 噸/秒 |
| 米斯特拉爾-小型-3.1-24B | 預填充重型 | 216.01 噸/秒 | 214.38 噸/秒 | 197.92 噸/秒 |
| 米斯特拉爾-小型-3.1-24B | 解碼重 | 238.44 噸/秒 | 237.97 噸/秒 | 221.41 噸/秒 |
結語
本輪測試中最有價值的發現與哪家OEM廠商在哪項工作負載下表現較佳關係不大。在我們測試的所有型號和工作負載類型中，戴爾、技嘉和惠普的三款Spark產品性能相差無幾。在特定批次規模下，各平台略有優勢，但沒有哪個平台完全勝出，也沒有哪個平台始終落後。因此，消費者在三款產品中做出選擇時，應該多考慮機箱設計、散熱性能、保固條款和售後支持，而不是基準測試的差異。因為基準測試的差異更接近任何桌面級系統在持續負載下運行時的波動。
更有趣的結果在於方法論層面。在連接兩台 Spark 的 200 GbE 網路上，張量並行和管線並行之間的選擇比三家 OEM 廠商之間的任何差異都更為重要；對於任何合理並發量的批量推理，管線並行都是更佳選擇。 TP=2 的每層全歸約流量無法在 ConnectX-7 鏈路上傳輸而不導致計算資源閒置，而 PP=2 的流水線氣泡成本會在批次填滿流水線後立即攤銷到穩定流中。 NVIDIA 的文件預設使用 TP 是有充分理由的：他們將 Spark 的主要定位放在具有嚴格 TTFT 的互動式單流服務上，而這正是 TP=2 完全勝出的唯一場景。一旦工作負載看起來像是服務基礎設施而不是聊天介面，情況就完全相反了。
這種反轉強化了 Spark 的本質和非本質特徵。雙節點 Spark 叢集是一個開發和學習平台，它允許單一工程師在足夠快的網路環境下直接觀察分散式推理行為，該網路速度足以模擬真實的資料中心架構，同時又足夠有限，可以暴露生產部署大規模運行時所面臨的瓶頸。
更大規模的 Spark 配置值得單獨研究，需要針對其規模開發合適的工作負載和並行策略，我們已將這項工作列入路線圖。此外，排在本實驗之後的下一個實驗將從推理轉向訓練：在雙 Spark 集群上從頭開始訓練一個參數量小於 1 億的模型，該集群的配置旨在模擬規模更大的系統的分佈式預訓練條件。由於我們正在等待新的 800 Gb 實驗室核心交換機的光纖到位，這項工作暫時暫停，我們預計在新核心交換機上線後發布相關成果。
Amazon