在 Blackwell 上託管 Qwen

透過 72 通道 NVLink 互聯的 NVIDIA GB200 NVL72 機架非常適合部署大型混合專家（MoE）模型。在此部落格文章中，我們介紹了支援 Perplexity 部分流量的微調後 Qwen3 235B 模型的推論設定。我們展示了如何調整我們的內部推論引擎，以充分利用 NVIDIA Blackwell GPU 的先進張量核心與高速互聯。借助此硬體，我們能在不犧牲底層模型準確度的情況下，以更低的成本處理更多流量。

GB200 NVL72 機架由 18 個節點組成，配備 2 個基於 ARM 的 NVIDIA Grace CPU 與 4 個基於 Blackwell 的 GPU，每個 GPU 均配備 180GB HBM。這 72 個 GPU 透過 NVLink 和 18 個 NVLink Switch ASIC 互聯，在任意兩個同級之間提供 1800 GB/s 的頻寬，並共用充足的記憶體來託管兆級參數模型。此外，ConnectX-7 InfiniBand 網路卡在機架內部節點之間以及相鄰機架之間提供了額外 400 Gb/s 的頻寬。

為處理流量，我們選擇微調並提供 Qwen 模型服務。在此部落格文章中，我們主要探討 Qwen3 235B，但許多討論的服務技術和效能特性與我們正在遷移的較新 Qwen3.5 397B 和 122B 模型相似。在並行性方面，線性注意力機制與完整自注意力機制類似，且現有的 MoE 層實作可以輕鬆調整以適應新的閘極項。為了在最大化吞吐量的同時保持一致的解碼速率，我們選擇將預填充與解碼分離，並針對這兩種節點部署不同的並行策略。預填充器到解碼器的通訊透過 InfiniBand 進行，而 NVLink 頻寬則保留給預填充器和解碼器內部的通訊。本部落格文章中探討的 Blackwell 裝置在執行矩陣乘法和裝置間通訊時的效能特性決定了所使用的分片策略。與 NVIDIA Hopper GPU 相比，由於串流多處理器數量增加、記憶體頻寬提升以及點對點延遲降低，我們看到了逐核心的效能提升。

解耦預填充與解碼，在 prefillers 與 decoders 之間使用 InfiniBand，並在各個部署內使用 NVLink。

我們的 TransferEngine 實作了分離式預填充，可處理預填充器和解碼器之間任意且可能不匹配的分片。KV 快取在記憶體中以 HND 順序排列（首部位於主導維度，且 Token 保持連續），允許預填充器上的分片 KV 快取在傳輸至解碼器節點的過程中進一步分割或串接。

預填充器節點接收請求的輸入 Token，填入 KV 快取並將其傳輸至解碼器以繼續文字生成。由於需要同時處理屬於一個序列的數千個 Token，因此預填充是運算密集型的。

因此，我們發現張量並行部署非常合適，模型在單一 GB200 節點內的 4 個 GPU 上進行分片，且投影和專家均進行分片（TP=4, EP=4）。由於注意力機制和 MLP 均受運算限制，兩者皆受惠於並行性，將專家和注意力頭分佈在不同的排位（Rank）上。進一步的並行性會產生遞減的效益，因為在每個排位上託管較少專家（16 個對比 32 個）所帶來的吞吐量提升，無法抵消 8 路 all-reduce 的額外成本，以及跨兩個節點分割主機端程式碼所需透過乙太網路通訊的額外開銷。

Qwen3 235B 僅有 4 個鍵值頭，若使用 8 個裝置，則需要將 k 和 v 投影在各對排位之間複製。我們本可以考慮更積極的分片來減少每個排位上儲存權重所需的記憶體量，從而為 KV 快取中的更多 Token 釋放空間。然而，我們發現更廣泛的部署並不值得。

假設輸入長度約為 6000 個 Token，128 個專家中的每一個大約有 6000 * 8 / 128 = 375 個 Token 路由至其中，從而確保 MoE GEMM 具有密集的運算問題。由於這已經飽和了裝置的運算吞吐量，因此預填充不需要資料並行性。

儘管注意力機制的成本呈二次方增長，但預填充器仍能提供穩定的吞吐量，從而可以粗略估計節點在一秒內可以處理的輸入 Token 數量。透過依賴追蹤請求總輸入 Token 數量的指標，可以擴展預填充器節點的數量，以確保整體預填充吞吐量的大小相應調整。為了避免排查佇列等待，預填充器複本的數量與收到的總輸入 Token 數量相匹配。

解碼器節點接收來自預填充器的 KV 快取並逐個生成 Token。解碼通常受記憶體限制：在只有少量輸入 Token 的情況下，矩陣乘法完全受限於將權重從 HBM 載入到張量核心的成本。除了採用不同的分片策略外，還必須調整幾個核心，以更好地並行化運算和記憶體存取。

與預填充不同，分片注意力機制不再具有優勢：跨多個裝置分割注意力機制意味著單一裝置內的並行機會減少。因此，僅使用資料並行和專家並行：專家跨多個裝置分片，但每個裝置管理自己的 KV 快取和請求。在沒有張量並行的情況下，裝置上每個 Token 的 KV 快取大小較大。然而，透過在單一節點上放置較少專家，記憶體中的空間得以釋放。與 Hopper（我們將 8-GPU 節點內單一 NVLink 域內的張量並行限制在內）不同，在 Blackwell 上，我們發現跨域內多個節點進行擴展（最多使用 16 個裝置）是有益的。

為了最大化吞吐量，解碼器會同時處理更多數量的請求。即使額外請求在 MoE 層和其他投影中產生的額外開銷微乎其微，它們還是會不成比例地增加注意力機制的成本。為了維持合理的最低解碼速度，需要調整解碼器節點的數量，以將每個解碼器的批次大小保持在特定閾值以下。

與先前的 Hopper 部署類似，我們使用內部訓練的 MTP 層進行推測解碼，以提高解碼速率。幸運的是，底層硬體和程式設計框架足夠相似，可以在兩個架構之間完全共用實作。

GB200 NVL72 與先前 Hopper 節點的主要區別在於大型 NVLink 域，它支援超出先前 8 個裝置限制的點對點通訊。儘管 Blackwell 裝置已部署在 8-GPU 節點中，但與較慢的 InfiniBand 網路相比，透過 NVLink 跨多個節點擴展具有極高的價值。

在預填充器節點上，我們依賴注意力層內的 all-reduce 通訊以及與 all-reduce 非常相似的專家並行縮減。在 4 個 GPU 跨越中，我們同時利用了 NVLink 和 NVIDIA SHARP（可擴展階層式聚合與縮減協定）：除了點對點頻寬外，我們還利用 NVLink Switch 中的縮減來進一步降低延遲並實作快速廣播。在解碼器節點上，使用了透過 NVLink 的自訂 all-to-all 調度與合併實作。這些核心已內部使用 CuTeDSL 與 cuMem 對應或多播對應實作。

預填充器在注意力層的輸出投影中執行 all-reduce 操作，將跨參與排位分片的頭部的貢獻相加。只有當 all-reduce 開銷的成本被較小矩陣乘法問題的降低延遲所抵消時，張量並行才有效。這種假設通常適用於預填充。

在資料中心級別的 NVIDIA HGX H200 和 GB200 NVL72 系統上，GPU 通常透過 NVLink Switch 連接。除了路由之外，Switch 還可以透過 SHARP 在連接的裝置上執行縮減操作。在建立記憶體對應並使用 CUDA API 將其註冊到多播群組後，核心可以使用 multicast.ld_reduce 和 multicast.st 透過 Switch 聚合和廣播值。為了建立基礎和可重複使用的元件（可融合到其他內部核心中），我們內部維護了一個使用這些原語的 CuTeDSL all-reduce 核心。

在擁有 N 個 GPU 且縮減 B 位元組的系統中，簡單的實作會讓一個對等節點從所有其他對等節點載入值，總共產生 N * (N - 1) * B 位元組的讀取流量。更有效率的實作會將要縮減的資料分割到各個對等節點之間，每個對等節點縮減輸入的一部分，然後将其廣播給其餘部分。這會導致 (N - 1) * (B / N) 位元組被讀入對等節點並廣播給其餘部分，總共產生 (N - 1) * B * 2 次讀寫，從而減少 Switch 上的流量。

借助 SHARP，可以更有效率地執行縮減和廣播：不必將 (N - 1) * (B / N) 位元組讀入裝置進行本地累積，而是僅從 Switch 移動 B / N 位元組，因為它本身使用來自對等節點的資料執行縮減。對於廣播，也有類似的改進，因為大大減少了 GPU 與 Switch 之間透過 NVLink 通道進行的交易次數。在沒有 SHARP 的情況下，累積裝置將與 Switch 透過 NVLink 執行 (N - 1) * (B / N) 次交易，而 Switch 從對等節點讀取相同數量的資料，總共進行 2 * (N - 1) * (B / N) 次交易。有了 SHARP，GPU 與 Switch 之間會執行 B / N 次交易，並與對等節點執行進一步的 (N - 1) * (B / N) 次交易，總共進行 B 次交易。

由於其簡單性，SHARP 是一個有價值的工具，因為它為演算法提供了一個直接的硬體實作。儘管傳輸量按理論上的 N / (2 * (N - 1)) 分數減少（使用 4 個對等節點時計算結果為 33%），但在實踐中，我們觀察到 H200 和 GB200 NVL72 系統上的預填充和解碼延遲均改善了 10%。

在 TP=4 且使用 16K tokens 時，H200 與 GB200 上的 NVLink 與 NVLS 發派延遲。

對於 MoE 模型，調度和合併核心在對等節點之間移動和群組 Token，以進行後續的 MoE GEMM 問題，隨後在合併中執行加權累積。我們已將現有的調度和合併核心調整為適用於 Blackwell，方法是將其移植到 CuTeDSL、調整區塊配置，並在預填充和解碼之間積極進行專門化。

專家並行（EP）核心用於預填充器。由於其輸入在所有排位中複製，因此調度核心只需要簡單地選擇路由至目前排位上專家的 Token。它聚合路由資訊並將 Token 準備到用作 MoE GEMM 輸入的緩衝區中。合併核心首先在路由至目前排位上專家的 Token 的貢獻之間執行本地累積，然後在所有排位之間執行 all-reduce。

對於解碼，整個核心被融合為一個。預填充核心被分割成多個核心，因為路由和 all-reduce 所需的區塊比本地合併步驟少。借助 CuTeDSL，我們可以為 SHARP 和 NVLink all-reduce 以及點對點同步建構一個通用的程式庫，將其組合成 all-reduce 和專家並行核心。

就效能而言，我們觀察到 Blackwell 顯著快於 Hopper，這是由於傳輸速度提升、記憶體頻寬更高以及運算吞吐量更好。在 GB200 上的 8 個裝置和多個節點上進行分片（EP=8）時，核心變得更快，因為本地累積在每個裝置上執行的 Token 數量少得多，並且透過 SHARP，跨更多排位的縮減成本擴展得更好。然而，在實踐中，我們將並行性限制在 4 個裝置，因為這些速度提升並非在所有核心中都普遍存在。

資料並行和專家並行（DP-EP）核心用於資料並行解碼器。它將來自所有排位的不同 Token 廣播給專家，將結果傳輸到原始排位並進行累積。由於它實作了稀疏的 all-to-all 問題，因此它完全依賴 NVLink。

在 Hopper 上，此核心受限於單一節點 NVLink 域內的 8 個裝置。然而，在 GB200 系統上，我們可以將其擴展到整個機架。大部分程式碼都被重複使用。唯一的區別是使用 fabric 句柄透過 IMEX 交換對等資訊以進行初始設定。

由於解碼期間產生的傳輸大小很小，它們遠未飽和 NVLink 頻寬，而是受延遲限制。延遲在幾十微秒範圍內，並且隨著對等節點數量的增加而保持相對穩定，這使我們能夠將部署擴展到更多的裝置，而不會產生顯著的額外延遲。

MoE 模型受益於專家並行，因為將所有 Token 與所有專家相乘的成本可以輕鬆跨多個裝置並行化。透過預填充器上的張量並行，在密集問題上，好處非常直接，因為每個排位現在需要執行的運算更少。在解碼情況下，資料並行在專家並行的基礎上提供了額外的好處，因為更多數量的並行請求將更多 Token 路由至每個專家，從而使問題密集化。

在我們的實作中，目前依賴 CUTLASS CUDA/C++ 核心進行矩陣乘法。我們在具有各種量化方案和並行級別的稀疏解碼輸入上對其進行了基準測試，以便為解碼器決定最佳的分片策略。在以下的基準測試中，所有專家皆由單一 Token 啟用。

H200 與 GB200 在各種專家並行配置及量化方案下的分組 MoE GEMM 延遲。

我們發現將 128 個專家擴展到 16 個以上的排位會使 CUTLASS 產生遞減的效益，因為乘 2 個專家的成本並不比乘 4 個低多少。與 Hopper 相比，Blackwell 有了明顯的改進，即使在次優的區塊縮scaling（縮放）策略上也是如此。由於調度/合併在 EP=8 和 EP=16 之間大約 5 us 的延遲增加被 GEMM 成本減少超過 10 us 所抵消，因此在 GB200 系統上，跨 16 個排位分片解碼器是合理的，這也得到了端到端基準測試的證實。

Blackwell 引入了對新型 8 位元和 4 位元量化方案的硬體支援。與依賴基於張量或區塊縮放比例的 Hopper 不同，Blackwell 需要微縮放（microscaling）來實現最佳的預填充和解碼吞吐量。雖然用於 DeepSeek 或 Kimi 等模型的區塊縮放方案可用，但微縮放更有效率。

我們已部署了採用 MXFP8 量化方案的 Qwen3 235B，在對模型進行微調後靜態轉換權重。準確度影響與帶有隨機量化的區塊縮放的影響相似，但效能得到了極大改善，正如 MoE GEMM 微基準測試所示。我們還考慮了 MXFP4 和 NVFP4 量化方案，儘管在沒有量化感知訓練（Quantization-Aware Training）的情況下，準確度影響對於從 Hopper 到 Blackwell 的初始轉型來說太大了。我們計劃在未來的工作中更深入地探討這些格式。

我們對 Blackwell Qwen3 235B 部署的解碼器進行了基準測試，並將其與我們先前的 Hopper 部署進行了比較。在此設定中，我們考慮了兩個部署之間的區塊縮放，以專注於並行性的影響。為了隔離解碼效能，兩種架構均分離了 TP=4 預填充器。下圖展示了假設由我們的 MTP 層提供的實際草稿接受率時的解碼吞吐量。

假設 draft 接受長度為 0.8，Qwen3 235B FP8 解碼速度與每 GPU 吞吐量在 H200 與 GB200 專家並行配置下的表現。

在 Hopper 上，將部署分片到 8 個以上的 GPU 是不可行的，因為跨 InfiniBand（特別是在 EFA 網路卡上）的延遲明顯較慢。然而，在 Blackwell 上，由於更大的 NVLink 域，我們實現了顯著更高的吞吐量。

我們透過泛化現有的 Hopper 核心並推進基於 NVLink 的核心的效能，實現了最初的 Blackwell 實作。我們將透過改善量化並微調管線中其他核心的解碼效能和預填充吞吐量，進一步降低提供 Qwen 服務的成本。

Transfer Engine 部落格文章

BibTeX

@online{perplexity2026HostingQwenOnBlackwell,
  author = {{Perplexity} and Nandor Licker and Kevin Hu and Bex Brooker and Erin McKnight},
  title = {{Hosting Qwen on Blackwell}},
  date = {2026-05-12},
  url = {https://www.perplexity.ai/hub/blog/hosting-qwen-on-blackwell}
}

在 GB200 NVL72 上部署

預填充器

解碼器

節點內部與節點之間通訊

All-Reduce

MoE 調度 - 合併

專家並行

資料並行與專家並行

MoE GEMM

量化

端到端效能

參考資料

引用