16個請求併發時每秒607.8 token：輝達以兩台GB300 DGX Station分散執行GLM-5.3

輝達（NVIDIA，NVDA）以兩台GB300 DGX Station分散執行GLM-5.3，在16個請求同時處理時，總吞吐量達每秒607.8個token。

輝達於13日在技術部落格公開模型部署方式與內部效能測試結果。Station A提供相容於OpenAI的API，Station B則連接為工作節點，使用者只需呼叫單一API。

GLM-5.3是Z.ai開發的混合專家（MoE）模型。模型共有7,530億個參數，每次處理token時會啟用其中400億個。

實作採用以NVFP4格式量化的原始模型。量化後的checkpoint約464GB，大於單張GB300 GPU的高頻寬記憶體（HBM3e）容量252GB。

兩台設備的儲存裝置都會複製完整checkpoint，但執行時由兩張GPU分攤權重與計算工作。兩張GPU的記憶體不會合併成單一記憶體，執行時也不會將權重移至CPU記憶體。

每生成一個token，兩台設備都會透過RoCE連線交換中間結果。因此，分散執行模型時，GPU之間的通訊也會納入處理流程。

實作使用vLLM v0.30.0-aarch64映像檔，張量平行度設為2。輸入與輸出合計的最大上下文長度設定為9萬8,304個token。

測試也使用FP8 KV快取與前綴快取。多token預測（MTP）則設定為每個階段產生4個token草稿。

指南列出從確認連線狀態、複製checkpoint，到確認API回應及檢查設備間通訊的步驟，也提供在兩台設備部署模型的方法與內部負載測試設定。

輝達的AIPerf測試使用SPEED-Bench Coding中的80段對話，共89輪。推論強度採預設的「max」，輸出上限為8,192個token，暖機請求不納入測量。

總吞吐量方面，同時處理1個請求時為每秒107.4個token，8個請求時為386.0個，16個請求時為607.8個；請求數增至32個時，則降至每秒385.0個。吞吐量統計也包含推論token。

平均請求延遲方面，同時處理1個請求時為49.84秒，8個請求時為114.17秒，16個請求時為136.46秒；32個請求時則增至453.54秒。

因此，每秒607.8個token是16個請求同時處理時的整體吞吐量，不等同於單一使用者收到回答的速度。這是輝達在指定的程式碼資料集與快取、MTP設定下測得的結果。

此前，StorageReview於10月5日測試兩台GB300 DGX Station執行相同模型。在輸入與輸出各512個token的工作中，同時處理256個請求時，輸出吞吐量為每秒5,018個token。該測試使用vLLM 0.27.1，並設定MTP每次產生5個草稿token，測試條件與設定有所不同。

本刊先前曾報導在DGX Spark上測試Nemotron 3.5 Lightning的MTP效能。當時測量的是不同設備與模型的接受token數；此次測試則測量同時處理程式碼請求時的總吞吐量。

輝達也在實作範例中提醒，提供API的Station A管理介面在內的所有網路介面，都可能暴露給未經驗證的連線。若要連接外部服務，輝達建議設定防火牆，並啟用驗證與TLS。