BlackwellでQwenをホストする

NVIDIA GB200 NVL72ラック（72ウェイNVLinkで相互接続されたNVIDIA Blackwell GPUを搭載）は、大規模なMixture-of-Experts（MoE）モデルの展開に最適です。本ブログ記事では、Perplexityのトラフィックの一部をサポートする、ポストトレーニング済みのQwen3 235Bモデルを提供する推論環境について解説します。また、NVIDIA Blackwell GPUの高度なTensorコアと高速インターコネクトを活用するために、当社の社内推論エンジンをどのように適応させたかを紹介します。このハードウェアを使用することで、モデルの精度を犠牲にすることなく、より多くのトラフィックを低コストで処理することが可能となりました。

GB200 NVL72でのデプロイメント

GB200 NVL72ラックは、ARMベースのNVIDIA Grace CPUを2基と、それぞれ180GBのHBMを搭載したBlackwellベースのGPUを4基備えた18個のノードで構成されています。72基のGPUは、NVLinkおよび18個のNVLinkスイッチASICを介して相互接続されており、任意の2つのピア間で1800GB/sの帯域幅を提供し、兆パラメータ規模のモデルをホストするのに十分なメモリを共有します。さらに、ConnectX-7 InfiniBandアダプターにより、ラック内の各ノード間および隣接するラック間で、追加で400Gb/sの帯域幅が提供されます。

トラフィックを処理するため、当社はQwenモデルをポストトレーニングし、提供することを選択しました。本ブログ記事ではQwen3 235Bに焦点を当てていますが、議論するサービング技術やパフォーマンス特性の多くは、現在移行を進めている新しいQwen3.5 397Bおよび122Bモデルと共通しています。並列化の観点では、線形アテンションは完全なセルフアテンションと類似しており、既存のMoE層の実装は新しいゲート項に対応できるよう容易に適応可能です。デコードレートを一定に保ちつつスループットを最大化するために、当社はプリフィル（prefill）とデコード（decode）を分離し、これら2種類のノードに対して異なる並列化戦略を展開することを選択しました。プリフィラー（prefiller）からデコーダー（decoder）への通信はInfiniBand経由で処理され、NVLink帯域幅はプリフィラーおよびデコーダー内の通信のために確保されています。本ブログ記事で調査した、行列乗算およびデバイス間通信を実行する際のBlackwellデバイスのパフォーマンス特性が、使用するシャーディング戦略を決定づけています。NVIDIA Hopper GPUと比較すると、より多くのストリーミングマルチプロセッサ、強化されたメモリ帯域幅、および低減されたピアツーピア遅延により、カーネル単位での改善が見られます。

拡大

分散プリフィルを実装する当社のTransferEngineは、プリフィラーとデコーダー間で任意かつ不一致が生じうるシャーディングを処理しました。KVキャッシュは、ヘッドを先頭次元とし、トークンを連続した状態でメモリ上にHND順で配置されるため、プリフィラー上のシャード化されたKVキャッシュは、デコーダーノードへの転送中に、インフライトでさらに分割または結合が可能となっています。

プリフィラー

プリフィラーノードはリクエストの入力トークンを受け取り、KVキャッシュを格納し、テキスト生成を継続するためにデコーダーへ転送します。プリフィルは、シーケンスに属する数千のトークンを同時に処理するため、計算負荷が高いプロセスです。

その結果、テンソル並列展開が適していることが判明しました。モデルは単一のGB200ノード内で4基のGPUにシャード化され、プロジェクションとエキスパートもシャード化（TP=4、EP=4）されています。アテンションとMLPの両方が計算制約型であるため、両者とも並列化の恩恵を受け、エキスパートとアテンションヘッドを別々のランクに分散させます。さらなる並列化は、各ランクでホストするエキスパートを減らす（32から16へ）ことによるスループット向上効果が、8ウェイのオールリデュースの追加コストや、Ethernet経由の通信を必要とする2ノード間でのホスト側コード分割のオーバーヘッドを相殺できず、収益逓減を招くことになります。

Qwen3 235Bにはキー・バリューヘッドが4つしかないため、8つのデバイスを使用する場合、kおよびvのプロジェクションを各ランクペア間で複製する必要があります。各ランク上のウェイト保存に必要なメモリを削減し、KVキャッシュ内のより多くのトークン用にスペースを確保するため、よりアグレッシブなシャーディングを検討することも可能でした。しかし、より広範な展開にはそれだけの価値がないことがわかりました。

入力長を約6000トークンと仮定すると、128個のエキスパートそれぞれに約6000 * 8 / 128 = 375個のトークンがルーティングされ、MoE GEMMにとって十分な密度の問題が確保されます。これはすでにデバイスの計算スループットを飽和させているため、プリフィルにデータ並列処理は必要ありません。

アテンションのコストが二次関数的に増加するにもかかわらず、プリフィラーは一貫したスループットを提供し、ノードが1秒間に処理できる入力トークン数の概算を可能にします。リクエストからの入力トークン総数を追跡するメトリクスを基に、プリフィラーノードの数をスケールアップすることで、全体のプリフィルスループットを適正なサイズに調整できます。キューイングを避けるため、プリフィラーレプリカの数は、受信した入力トークンの総数に合わせて調整されます。

デコーダー

デコーダーノードはプリフィラーからKVキャッシュを受け取り、トークンを1つずつ生成します。デコードは一般にメモリ制約型です。入力トークンが少ない場合、行列乗算は完全にHBMからTensorコアへのウェイト読み込みコストに縛られます。異なるシャーディング戦略を採用する以外にも、計算とメモリへのアクセスをより効率的に並列化するために、複数のカーネルを微調整する必要があります。

プリフィルとは異なり、アテンションをシャード化する利点はもはやありません。アテンションヘッドを複数のデバイスに分割すると、単一デバイス内での並列化の機会が減少することを意味するためです。結果として、データ並列とエキスパート並列のみが使用されます。エキスパートは複数のデバイスにシャード化されますが、各デバイスは独自のKVキャッシュとリクエストを管理します。テンソル並列を使用しない場合、デバイスあたりのトークンごとのKVキャッシュサイズは大きくなります。しかし、単一ノードに配置されるエキスパートを減らすことで、メモリ上のスペースが解放されます。8基のGPUを搭載したノード内の単一NVLinkドメイン内でテンソル並列を制限していたHopperとは異なり、Blackwellでは、最大16基のデバイスを使用してドメイン内の複数ノードに拡張することが有益であると判断しました。

スループットを最大化するため、デコーダーはより多くのリクエストを同時に処理します。リクエストの追加は、MoE層やその他のプロジェクションにおいてわずかなオーバーヘッドを生じさせますが、アテンションのコストを不釣り合いに増大させます。妥当な最小デコード速度を維持するために、デコーダーあたりのバッチサイズを一定の閾値以下に保つよう、デコーダーノードの数をスケーリングします。

以前のHopperの展開と同様に、デコードレートを向上させるために自社トレーニングしたMTP層を用いた投機的デコード（speculative decoding）を使用しています。幸いなことに、基盤となるハードウェアとプログラミングフレームワークが十分に類似しているため、両アーキテクチャ間で実装を完全に共有することが可能です。

ノード内およびノード間通信

GB200 NVL72と従来のHopperノードとの主な違いは、大規模なNVLinkドメインであり、これにより8基のデバイスという以前の制限を超えたピアツーピア通信が可能になります。Blackwellデバイスは8基のGPUを搭載したノードで展開されていますが、低速なInfiniBandネットワークと比較して、NVLinkを介して複数ノード間でスケーリングすることには非常に大きな価値があります。

プリフィラーノードでは、アテンション層内でのオールリデュース通信と、オールリデュースに近いエキスパート並列リダクションに依存しています。4基のGPU間で、NVLinkとNVIDIA SHARP（Scalable Hierarchical Aggregation and Reduction Protocol）の両方を活用します。ピアツーピアの帯域幅に加えて、NVLinkスイッチ内でのリダクションも活用してさらなる遅延短縮と高速ブロードキャストを実装しています。デコーダーノードでは、NVLinkを介したカスタムのオールトゥオール（all-to-all）ディスパッチおよび結合実装が使用されます。カーネルは、CuTeDSLとcuMemマッピングまたはマルチキャストマッピングを使用して社内で実装されました。

オールリデュース

プリフィラーはアテンション層の出力プロジェクションでオールリデュース演算を実行し、参加しているランク間でシャード化されたヘッドの寄与を合計します。テンソル並列は、オールリデュースのオーバーヘッドコストが、小さな行列乗算問題の低遅延によって相殺される場合にのみ有効です。この前提条件は通常、プリフィルでは成り立ちます。

データセンターグレードのNVIDIA HGX H200およびGB200 NVL72システムでは、GPUは通常NVLinkスイッチを介して接続されています。ルーティングに加えて、スイッチはSHARPを介して接続されたデバイス間でリダクション演算を実行できます。CUDA APIを使用してメモリマッピングを作成し、マルチキャストグループに登録した後、カーネルはmulticast.ld_reduceおよびmulticast.stを使用して、スイッチを介して値を集約およびブロードキャストできます。他のカーネルに統合可能な基礎的で再利用可能なコンポーネントを作成するため、当社は社内でこれらのプリミティブを使用したCuTeDSLオールリデュースカーネルを維持しています。

N個のGPUがBバイトをリデュースするシステムにおいて、単純な実装では、ピアが他のすべてのピアから値を読み込むため、合計N * (N - 1) * Bバイトの読み取りトラフィックが発生します。より効率的な実装では、リデュースするデータをピア間で分割し、各ピアが入力の一部をリデュースしてから残りのピアにブロードキャストします。これにより、各ピアが読み込み、残りにブロードキャストされるのは(N - 1) * (B / N)バイトとなり、合計で(N - 1) * B * 2回の読み取りおよび書き込みが発生し、スイッチ間のトラフィックが削減されます。

拡大

SHARPを使用すると、リダクションとブロードキャストをより効率的に実行できます。ローカル蓄積のためにデバイスに(N - 1) * (B / N)バイトを読み込む代わりに、スイッチがピアからのデータを使用してリダクション自体を実行するため、スイッチから移動するのはB / Nバイトのみです。ブロードキャストについても同様の改善があり、NVLinkチャンネルを介したGPUとスイッチ間のトランザクション数が大幅に削減されます。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モデルにおいて、ディスパッチおよび結合カーネルは、後続のMoE GEMM問題のためにトークンをピア間で移動およびグループ化し、結合時に加重蓄積を実行します。当社は既存のディスパッチおよび結合カーネルをBlackwellに適応させ、CuTeDSLに移植し、ブロック割り当てを微調整し、プリフィルとデコードの間でそれぞれアグレッシブに最適化しました。

エキスパート並列

エキスパート並列（EP）カーネルはプリフィラーで使用されます。その入力はすべてのランク間で複製されるため、ディスパッチカーネルは現在のランクのエキスパートにルーティングされるトークンを選択するだけで済みます。これはルーティング情報を集約し、MoE GEMMへの入力として使用されるバッファにトークンを準備します。結合カーネルは、まず現在のランクのエキスパートにルーティングされたトークンの寄与分をローカルで蓄積し、次にすべてのランク間でオールリデュースを実行します。

デコードでは、カーネル全体が1つに融合されます。ルーティングとオールリデュースはローカル結合ステップよりも少ないブロックを必要とするため、プリフィルカーネルは複数のカーネルに分割されます。CuTeDSLを使用することで、SHARPとNVLinkオールリデュース、およびピアツーピア同期の両方に対応する汎用ライブラリを構築し、それをオールリデュースカーネルとエキスパート並列カーネルの両方に組み込むことができました。

拡大

パフォーマンスに関しては、転送速度の向上、メモリ帯域幅の増大、計算スループットの向上により、BlackwellがHopperよりも大幅に高速であることを確認しています。GB200の8基のデバイスと複数ノードにわたってシャード化されると（EP=8）、ローカル蓄積が各デバイスのより少ないトークンで実行され、SHARPによってランク間リダクションコストが効率的にスケーリングされるため、カーネルは高速化されます。ただし、実際にはすべてのカーネルでこれらの高速化が普遍的ではないため、並列化を4基のデバイスに制限しています。

データ並列およびエキスパート並列

データ並列およびエキスパート並列（DP-EP）カーネルは、データ並列デコーダーで使用されます。これは、全ランクからの異なるトークンをエキスパートにブロードキャストし、結果を元のランクに転送して蓄積します。疎なオールトゥオール問題を実装しているため、NVLinkのみに依存します。

Hopperでは、このカーネルは単一ノードのNVLinkドメイン内の8基のデバイスに制限されていました。しかし、GB200システムでは、ラック全体にスケーリング可能です。コードのほとんどは再利用されています。唯一の違いは、初期セットアップのためにIMEX経由でピア情報を交換する際にfabricハンドルを使用することです。

拡大

デコード中に発生する転送サイズは小さいため、NVLink帯域幅を飽和させるには程遠く、代わりに遅延が制限要因となります。遅延は数十マイクロ秒であり、ピア数が増加しても比較的安定しているため、大幅な遅延を伴うことなく、より多くのデバイスに展開を分散させることが可能です。

MoE GEMM

MoEモデルはエキスパート並列の恩恵を受けます。全トークンと全エキスパートの乗算コストを複数のデバイス間で簡単に並列化できるためです。プリフィラーでのテンソル並列により、高密度な問題では各ランクが実行する計算量が減るため、メリットは明白です。デコードの場合、データ並列がエキスパート並列に加えて利点をもたらします。より多くの並列リクエストが各エキスパートにより多くのトークンをルーティングし、問題を高密度化するためです。

当社の実装では、現時点で行列乗算にCUTLASS CUDA/C++カーネルを使用しています。デコーダーの最適なシャーディング戦略を決定するために、さまざまな量子化スキームと並列レベルを用いて、疎なデコード入力でベンチマークを行いました。以下のベンチマークでは、すべてのエキスパートが1つのトークンでアクティブ化されています。

拡大

128個のエキスパートを16ランク以上にスケーリングすると、CUTLASSでは収益逓減が生じることがわかりました。2つのエキスパートを乗算するコストが4つを乗算する場合と比べて大幅に低くはないためです。最適ではないブロックスケーリング戦略を用いた場合でも、Blackwellでの改善はHopperに対して明確です。EP=8からEP=16へのディスパッチ/結合の遅延増加は約5μsですが、GEMMのコストが10μs以上減少することで相殺されるため、GB200システムにおいて16ランク間でデコーダーをシャード化することは正当化されます。これはエンドツーエンドのベンチマークによっても確認されています。

量子化

Blackwellは、新しい8ビットおよび4ビット量子化スキームのハードウェアサポートを導入しています。テンソルごとまたはブロックごとのスケーリング係数に依存していたHopperとは異なり、Blackwellは最良のプリフィルおよびデコードスループットを達成するためにマイクロスケーリングを必要とします。DeepSeekやKimiのようなモデルで使用されるブロックスケーリングスキームも利用可能ですが、マイクロスケーリングの方が効率的です。

当社はQwen3 235BをMXFP8量子化スキームで展開し、モデルのファインチューニング後にウェイトを静的に変換しました。精度への影響は確率的量子化を用いたブロックスケーリングと同等でしたが、MoE GEMMマイクロベンチマークで示されるように、パフォーマンスは大幅に向上しました。また、MXFP4およびNVFP4量子化スキームも検討しましたが、Quantization-Aware Trainingなしでの精度への影響が、HopperからBlackwellへの初期移行には大きすぎました。今後の作業で、これらの形式をより徹底的に調査する予定です。

エンドツーエンドのパフォーマンス

Blackwell Qwen3 235Bのデコーダー展開をベンチマークし、以前のHopper展開と比較しました。このセットアップでは、並列化の影響に焦点を当てるため、両方の展開でブロックスケーリングを考慮しました。TP=4プリフィラーは、デコードパフォーマンスを分離するために両アーキテクチャで個別に設定されました。以下の図は、当社のMTP層が提供する現実的なドラフト許容率を想定したデコードスループットを示しています。

拡大

Hopperでは、特にEFAアダプター上のInfiniBand経由の遅延が大幅に遅いため、8基のGPUを超えて展開をシャード化することは実用的ではありません。しかし、Blackwellでは、より大きなNVLinkドメインのおかげで、大幅に高いスループットを達成しています。

既存のHopperカーネルを汎用化し、NVLinkベースのカーネルのパフォーマンスを追求することで、初期のBlackwell実装を達成しました。今後、量子化の改善やデコードパフォーマンスおよびパイプライン内の他のカーネルのプリフィルスループットを微調整することで、Qwenのサービングコストをさらに削減する予定です。

参考文献

Transfer Engineブログ記事

CuTeDSLブログ記事

Prefill-Disaggブログ記事

Speculative Decodingブログ記事

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