在 Blackwell 上託管 Qwen

NVIDIA GB200 NVL72 機架透過 72 向 NVLink 互連 NVIDIA Blackwell GPU，非常適合部署大型專家混合（MoE）模型。在此部落格文章中，我們介紹了支援 Perplexity 部分流量的後訓練 Qwen3 235B 模型推理設定。我們展示了如何調整內部推理引擎，以充分利用 NVIDIA Blackwell GPU 的先進 Tensor Core 和高速互連能力。透過此硬體，我們在不犧牲底層模型準確度的前提下，以更低的成本處理了更多的流量。

在 GB200 NVL72 上部署

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 層實作可以輕鬆調整以適應新的閘控項。為維持一致的解碼速率並最大化傳輸量，我們選擇將預填充（prefill）與解碼（decode）分拆，並為這兩類節點部署不同的並行策略。預填充器與解碼器之間的通訊透過 InfiniBand 處理，而 NVLink 頻寬則保留給預填充器和解碼器內部的通訊。本部落格文章探討了 Blackwell 裝置在執行矩陣乘法和裝置間通訊時的效能特性，這些特性決定了所使用的分片策略。與 NVIDIA Hopper GPU 相比，由於串流多處理器數量增加、記憶體頻寬提升以及點對點延遲降低，我們觀察到逐核心的效能提升。

放大

我們的 TransferEngine 實作了分拆預填充，可處理預填充器與解碼器之間任意且可能不匹配的分片。KV 快取以 HND 順序佈置在記憶體中，頭部（heads）位於前導維度，tokens 保持連續，以便在傳輸到解碼器節點的過程中，預填充器上的分片 KV 快取可以進一步拆分或串聯。

預填充器

預填充器節點接收請求的輸入 tokens，填充 KV 快取並將其傳輸給解碼器以繼續文字生成。預填充過程計算密集，因為序列中數以千計的 tokens 是同時處理的。

因此，我們發現採用張量並行部署是合適的，模型在單個 GB200 節點內的 4 個 GPU 上進行分片，並對投影和專家進行分片（TP=4, EP=4）。由於注意力機制和 MLP 均為計算密集型，兩者均受益於並行處理，將專家和注意力頭分散到不同的 rank 上。進一步的並行化邊際效益遞減，因為在每個 rank 上託管較少專家（16 個而非 32 個）帶來的傳輸量提升，無法抵銷 8 向 all-reduce 的額外成本以及跨兩個節點分割主機端程式碼所需透過乙太網路通訊的額外開銷。

Qwen3 235B 只有 4 個 key-value heads，因此如果使用 8 台設備，就需要在各個 rank 配對之間複製 k 和 v projections。我們原本可以考慮更激進的分片，以減少在每個 rank 上儲存權重所需的記憶體量，從而為 KV cache 中更多 token 釋出空間。不過，我們發現擴大部署並不值得。

假設輸入長度約為 6000 個 tokens，128 個專家中的每一個都有大約 6000 * 8 / 128 = 375 個 tokens 路由至該處，確保了 MoE GEMM 的密集問題。由於這已經飽和了裝置的計算傳輸量，預填充不需要資料並行處理。

儘管注意力成本呈二次方增長，預填充器仍能提供穩定的傳輸量，從而可以粗略估算節點每秒可處理的輸入 tokens 數量。依賴追蹤來自請求的總輸入 tokens 數量的指標，可以擴展預填充器節點的數量，以確保整體預填充傳輸量達到適當規模。為避免排隊，預填充器副本的數量與接收到的總輸入 tokens 數量相匹配。

解碼器

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

不同於 prefill，將 attention 分片已不再有益：把 attention heads 切分到多個裝置上，意味著單一裝置內的平行化機會更少。因此，只使用資料平行與 expert 平行：experts 會分片到多個裝置上，但每個裝置各自管理自己的 KV caches 和 requests。若沒有 tensor parallelism，裝置上的每 token KV cache 大小會更大。不過，透過在單一 node 上配置較少的 experts，可以在記憶體中釋出空間。不同於 Hopper，我們將 8-GPU node 中單一 NVLink domain 內的 tensor parallelism 限制住；在 Blackwell 上，我們發現擴展到同一 domain 內的多個 node，最多使用 16 台裝置，會更有利。

為了最大化傳輸量，解碼器會同時處理大量請求。即使額外請求在 MoE 層和其他投影中產生的開銷極小，但它們確實不成比例地增加了注意力成本。為維持合理的最低解碼速度，解碼器節點的數量會進行縮放，以將每個解碼器的批次大小保持在特定閾值以下。

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

節點內與節點間通訊

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

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

All-Reduce

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

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

在一個擁有 N 個 GPU 歸約 B 位元組的系統中，簡單的實作會讓對等節點從所有其他對等節點載入數值，總共產生 N * (N - 1) * B 位元組的讀取流量。更有效率的實作會將待歸約資料拆分到各個對等節點，每個節點歸約輸入的一部分，然後廣播給其餘節點。這會產生 (N - 1) * (B / N) 位元組讀取到一個對等節點並廣播給其餘節點，總共 (N - 1) * B * 2 次讀寫，從而減少透過交換器的流量。

放大

透過 SHARP，歸約和廣播可以更有效率地執行：無需將 (N - 1) * (B / N) 位元組讀入裝置進行本地累加，僅需移動 B / N 位元組，因為交換器使用來自對等節點的資料自行執行歸約。對於廣播，也有類似的改善，因為 GPU 與交換器之間透過 NVLink 通道進行的交易數量大幅減少。沒有 SHARP 時，累加裝置會透過 NVLink 與交換器進行 (N - 1) * (B / N) 次交易，交換器則從對等節點讀取相同數量的資料，總共 2 * (N - 1) * (B / N) 次交易。使用 SHARP 後，GPU 與交換器之間進行 B / N 次交易，與對等節點進行另外 (N - 1) * (B / N) 次交易，總共 B 次交易。

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

放大

MoE 調度 - 合併

對於 MoE 模型，調度（dispatch）和合併（combine）核心會在對等節點之間移動並分組 tokens 以處理後續的 MoE GEMM 問題，並在合併時執行加權累加。我們已透過將現有的調度與合併核心移植到 CuTeDSL、調整區塊配置並針對預填充和解碼進行積極的專業化處理，使其適應 Blackwell 架構。

專家並行

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

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

放大

在效能方面，我們觀察到 Blackwell 明顯快於 Hopper，這得益於傳輸速度提升、記憶體頻寬更高以及計算傳輸量更好。分片到 8 個裝置以及 GB200s 上的多個節點（EP=8）後，核心執行速度更快，因為本地累加在每個裝置上的 tokens 少得多，而且有了 SHARP，跨更多 rank 的歸約成本擴展得更好。然而，在實踐中，我們將並行度限制在 4 個裝置，因為這些速度提升並非所有核心都通用。

資料並行與專家並行

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

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

放大

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

MoE GEMM

MoE 模型受益於專家並行，因為將所有 tokens 與所有專家相乘的成本可以輕鬆地在多個裝置上進行並行化處理。在預填充器上採用張量並行時，在密集問題上的好處相當直接，因為每個 rank 現在只需執行較少的計算。在解碼情況下，資料並行在專家並行的基礎上提供了額外好處，因為較多的並行請求將更多的 tokens 路由至每個專家，從而使問題密集化。

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

放大

我們發現，將 128 個專家擴展到超過 16 個 rank 在使用 CUTLASS 時會產生邊際效益遞減，因為乘法 2 個專家的成本並不顯著低於 4 個。即使在次優的區塊縮放策略下，Blackwell 相對於 Hopper 也有明顯的改善。由於調度/合併在 EP=8 和 EP=16 之間的延遲增加約 5 微秒，被 GEMM 成本減少超過 10 微秒所抵銷，因此在 GB200 系統上，將解碼器分片到 16 個 rank 是合理的，這也得到了端到端基準測試的證實。

量化

Blackwell 引入了對新型 8-bit 和 4-bit 量化方案的硬體支援。與依賴每個張量或每個區塊縮放因子的 Hopper 不同，Blackwell 需要微縮放（microscaling）才能實現最佳的預填充和解碼傳輸量。雖然 DeepSeek 或 Kimi 等模型所使用的區塊縮放方案可用，但微縮放更有效率。

我們已部署 Qwen3 235B 並採用 MXFP8 量化方案，在對模型進行微調後靜態轉換權重。準確度影響與帶有隨機量化的區塊縮放影響相似，但效能得到了顯著提升，如 MoE GEMM 微基準測試所示。我們還考慮了 MXFP4 和 NVFP4 量化方案，儘管對於從 Hopper 到 Blackwell 的初始過渡而言，在沒有量化感知訓練的情況下，準確度影響過於顯著。我們計畫在未來的工作中更深入地探索這些格式。

端到端效能

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

放大

在 Hopper 上，將部署分片到超過 8 個 GPU 是不可行的，因為 InfiniBand（特別是在 EFA 轉接器上）的延遲明顯較慢。然而，在 Blackwell 上，得益於更大的 NVLink 網域，我們獲得了明顯更高的傳輸量。

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

參考資料

Transfer Engine 部落格文章

CuTeDSL 部落格文章

Prefill-Disagg 部落格文章

推測性解碼部落格文章

CUTLASS

NVLink

引用

@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}
}