はじめに

グラフィックボードの値上げを予想する報道が続いていたため、7月末に GeForce RTX 5060 Ti 16GB を2枚購入しました。その後、実際に同モデルは3万円ほど値上がりしており、あのタイミングで買っておく判断は正しかったのかもしれません。16GB×2枚をどう活かすかを考えていたところ、8月に Qwen3.8-27B が公開されました。27Bクラスの Dense モデルは、NVFP4 量子化でちょうど 32GB に収まるサイズ感で、この2枚構成の題材としてうってつけです。

そこで本記事では、テンソル並列(TP=2)の列分割・行分割の仕組みを、この実機構成の寸法(モデルの実サイズ、GPUの帯域、PCIe 5.0 x8 の実効値)に当てはめて、どこまで速度が出るのか・どこまで文脈長を伸ばせるのかを数字で見積もっていきます。

題材は Qwen3.8-27B を RTX 5060 Ti 16GB を2枚、TP=2 で動かす構成です。マザーボードは X870E 系の x8/x8 分岐(bifurcation) 環境を想定します。

本記事では、数字を3種類に区分して扱います。公式スペック(モデルカード・GPUベンダー資料)、計算による見積もり、コミュニティ実測(note.com などの報告)の3つです。表の各行に区分を明記します。

先に結論だけ早見表にまとめます。根拠はすべて本文で計算します。

問い	答え	区分
列分割と行分割、どちらが良い?	どちらか一方ではなく、列→行のペアで両方使うのが正解(Megatron方式)	計算
本記事(vLLM TP=2)はどちら?	列分割と行分割の併用。vLLM が Megatron 方式を自動適用	公式
decode の理論天井は?	約 44.8 tok/s(重み読み出し律速)	計算
通信(all-reduce)は decode をどれだけ削る?	数%〜1割(10〜20μs/回の場合)	計算
NVLink がないと遅い?	decode はほぼ影響なし、prefill は通信が3〜4割	計算
16GB ×2 に 27B は載る?	NVFP4(約20GB)なら載る。BF16/FP8 は不可	計算
最大コンテキストは?	FP8 KV でネイティブ 262K、BF16 KV で 131K	計算
実測はどのくらい?	同級構成で 18→30 tok/s(MTP併用)	コミュニティ実測

0. 前提スペックの確認

Qwen3.8-27B の公式値(Hugging Face モデルカード Qwen/Qwen3.8-27B)を整理します。

項目	値	区分
パラメータ数	27.78B(HFファイル要約では「28B」表記)	公式
レイヤ数	64	公式
Hidden dimension	5,120	公式
FFN 中間次元	17,408	公式
レイヤ構成	16 × (3×(Gated DeltaNet→FFN) → 1×(Gated Attention→FFN))	公式
線形アテンション層	48層(Gated DeltaNet, V=48 / QK=16 heads, head_dim 128)	公式
フルアテンション層	16層(Gated Attention, GQA Q=24 / KV=4, head_dim 256, RoPE 64)	公式
ネイティブ文脈長	262,144(YaRN で最大約1M)	公式
BF16 重みサイズ	約 55.6 GB(18 shards)	公式

ここで重要なのは、64層のうちフルアテンション(KVキャッシュを持つ層)は16層のみである点です(full_attention_interval: 4)。残り48層は Gated DeltaNet の線形アテンションで、固定サイズの再帰状態のみを持ち、文脈長に比例したKVキャッシュを消費しません。この構造が、後述するとおり16GB級GPUを長文脈マシンに変える鍵になります。

RTX 5060 Ti 16GB の公式値は次のとおりです。GDDR7 28Gbps を 128-bit で束ねた 448 GB/s、5th-gen Tensor Core による 759 AI TOPS、TDP 180W が確認できます。

項目	値	区分
アーキテクチャ	Blackwell GB206, sm_120	公式
VRAM	16GB GDDR7, 128-bit, 28 Gbps	公式
メモリ帯域	448 GB/s	公式
FP4 Tensor(sparse)	759 AI TOPS	公式
FP4 Tensor(dense 換算)	約 380 TFLOPS	計算
インターフェース	PCIe 5.0(本構成では x8 動作)	公式
TDP	180W	公式
NVLink	非対応	公式

X870E 系マザーボードは、CPU 直結 PCIe 5.0 x16 スロットが2枚挿しで x8/x8 に分岐します。GPU間通信は PCIe とホストブリッジ経由になります。NVLink がないため、TP の all-reduce はすべてこの経路を通ります。

PCIe 5.0 x8 の実効帯域は片方向約 31.5 GB/s です(32 GB/s raw、128b/130b エンコーディング考慮)。これは大きな連続転送での上限であり、小メッセージはレイテンシ支配になります。

1. Linear 層の分割: 列分割と行分割

y = xW を TP=2 で割る方法は2種類あります。

図1のとおり、列分割(column parallel, 縦割り)は W を出力次元(列)で分割します。W = [W1, W2] とし、各GPUが Y1 = xW1、Y2 = xW2 を計算します。入力 x は両GPUに複製が必要です。出力は特徴次元が半分ずつ分かれた状態になります。出力を1つに揃えるなら all-gather が必要ですが、次の行分割層にそのまま食わせるなら通信は不要です。

行分割(row parallel, 横割り)は、W を入力次元(行)で分割します。入力も特徴次元で分かれている前提で、各GPUが部分和を計算します。真の出力は Y1 + Y2 なので all-reduce が必要です。

Megatron-LM の定石は次のとおりです。Attention は QKV射影=列分割、o_proj=行分割。FFN は up/gate=列分割、down=行分割。列分割の出力がそのまま行分割の入力に一致するため、中間の通信が不要になります。この結果、Transformerブロック1個あたり forward の all-reduce はちょうど2回になります(Shoeybi et al., 2019)。

ここで「結局どちらが良いのか」に答えておきます。列分割と行分割は優劣で選ぶものではなく、列→行の順にペアで組み合わせて使うのが正解です。列分割は入力を複製できる場面(ブロックの入口)に、行分割は入力が分割済みの場面(列分割の直後)に適性があり、単独で使うとどちらも余計な通信(all-gather または追加の all-reduce)を発生させます。ペアにして初めて通信が最小化されます。この根拠は次章で通信量を計算して示します。

そして本記事の構成はどちらの方式かというと、両方の併用です。vLLM の --tensor-parallel-size 2 はこの Megatron 方式を自動的に適用するため、本記事で扱う Qwen3.8-27B の TP=2 実行では、QKV と FFN up/gate が列分割、o_proj と FFN down が行分割で動いています。ユーザーが分割方式を選ぶ場面はなく、フラグ1つで図2のデータフローがそのまま構成されます。

図2が1ブロック内のデータフローです。赤い箱(all-reduce)が PCIe を通る場所で、これが1ブロックに2回だけ現れるのが Megatron 方式のポイントです。

2. なぜ「列→行」なのか: 素朴な代替案との通信量比較

Qwen3.8-27B の FFN を、decode(1トークン, BF16活性)で計算します。

Megatron 方式(up=列 → down=行)では、down 後に all-reduce が1回、対象は hidden 5,120 → 10,240 bytes/トークンです。素朴案A(列→列)では、down の入力に中間次元17,408全部が必要になり、up出力の all-gather が発生して 34,816 bytes(3.4倍)になります。素朴案B(行始まり)では、前段で追加通信が発生し、かつ SiLU/GeLU が部分和に非可換(GeLU(a+b) ≠ GeLU(a)+GeLU(b))なので非線形前に総和が必須となり、FFN内で all-reduce が2回発生します。

方式	通信プリミティブ	通信対象次元	バイト数/トークン	区分
Megatron 列→行	all-reduce ×1	hidden 5,120	10,240	計算
素朴案A 列→列	all-gather ×1	中間 17,408	34,816	計算
素朴案B 行始まり	all-reduce ×2	hidden 5,120 ×2	20,480	計算

小メッセージはレイテンシ支配なので、回数が正義です。Megatron方式は回数もサイズも最小になります。

3. Qwen3.8-27B decode の具体数字(batch=1, 1トークン)

3.1 all-reduce ペイロード総量(計算)

10,240 bytes × 2回/層 × 64層 = 128回、計 1,310,720 bytes ≒ 1.25 MiB/トークンです。Gated DeltaNet 層も出力射影後に行分割 all-reduce が入るため、全64層で2回ずつと見積もります。ここには前提があります。Gated DeltaNet は Mamba-2 系の「状態パラメータを入力射影側にまとめる」構造のため、mixer あたりの all-reduce が1回で済み、後続FFNと合わせて層あたり2回に収まります(Mamba-1 系の構造なら層あたり3回になり、この計算は成り立ちません)。この性質は arXiv:2406.07887 の「Mamba requires two all-reduces per layer while Mamba-2 requires only one」という報告に基づきます。なお128回はバックボーン64層ぶんの数で、MTPドラフトヘッドや lm_head の通信は別枠です。

3.2 all-reduce レイテンシと tok/s 天井

10 KiB はレイテンシ支配です(arXiv:1903.04611 は16KB以下でレイテンシ不変と報告)。NVLinkなしPCIe 2枚の小メッセージ all-reduce は約10〜20μsと見積もります(根拠: arXiv:1903.04611 の PCIe reduce 実測、RTX 4090×2 P2P無効 alltoall フロア約11〜12μs、TITAN RTX×2 P2P無効クロスGPUレイテンシ約12〜21μs、カーネル起動オーバーヘッド約10μs)。なお下限の10μsはカーネル起動相当(CPU側で5〜10μs/launch)の楽観値です。P2P無効でホスト経由コピーとなる本構成では、実測がこの2〜4倍に上振れしえます。以下の天井値は上振れ余地を含む理想値として読んでください。

1回あたりレイテンシ	128回合計	通信のみの tok/s 天井	区分
10μs	1.28 ms	約 781 tok/s	計算
20μs	2.56 ms	約 390 tok/s	計算
50μs	6.40 ms	約 156 tok/s	計算

3.3 重み読み出しの compute 天井(計算)

NVFP4 約20GB → 各GPU 10GB → 10/448 ≒ 22.3 ms → 約44.8 tok/s です。

3点補足します。1点目は単位です。本記事では帯域計算を10進のGB、VRAM予算をGiBで統一します。NVFP4重みの合計約20GB(10進)は18.6GiBに相当し、1GPUあたり10GB=9.3GiBです。第4章の予算表に出てくる9.3GiBはこの同じ量の単位違いの表記です。2点目は重みサイズです。NVFP4の合計約20GBは採用ビルドに依存し、実在ビルドは約14〜25GBの幅があります。本記事は視覚エンコーダ・lm_head・MTPヘッドをBF16で保持する約20GB構成を前提とします。3点目は帯域です。448 GB/sは理論値で、実効の持続帯域は概ね理論の85〜94%(約380〜420 GB/s)に落ちるため、44.8 tok/sは絶対上限であり実測はこれを下回ります。

3.4 合算モデル: 1/(t_compute + t_comm)

レイテンシ	t_compute	t_comm	合計	推定 tok/s	compute天井比
10μs	22.3 ms	1.28 ms	23.6 ms	42.4 tok/s	0.95×
20μs	22.3 ms	2.56 ms	24.9 ms	40.2 tok/s	0.90×
50μs	22.3 ms	6.40 ms	28.7 ms	34.8 tok/s	0.78×

図3が示すとおり、decode の時間の大半は青い部分(重み読み出し 22.3 ms)で、赤い通信部分はレイテンシが50μsまで悪化してようやく2割強です。「NVLink がないと decode が遅い」という直感がこの構成では成り立たないことが視覚的に分かります。

1枚に20GB載せられたら 44.6 ms → 22.4 tok/s です。TP=2 は約1.8×(楽観上限)になります。実測のPCIe接続コンシューマGPUのTPスケーリングは1枚あたり約1.4×が典型で、2枚合計でも約1.4倍にとどまります。答え合わせとして、note.com の報告では RTX 5060 Ti ×2、Qwen3.6-27B-NVFP4、vLLM + MTP(n=3) で 18→30 tok/s(コミュニティ実測)が出ています。compute天井44.8に対し妥当な着地です。

4. GPU 1枚あたりメモリ会計

4.1 KVキャッシュ(計算)

フルアテンション16層、KV 4 heads を TP=2 で各GPU 2 heads に割ります。

バイト/トークン(GPU1枚, BF16) = 16層 × 2 heads × 256 × 2(K+V) × 2 bytes = 32,768 bytes = 32 KiB です。

文脈長	BF16 KV/GPU	FP8 KV/GPU	区分
32,768	1.0 GiB	0.5 GiB	計算
131,072	4.0 GiB	2.0 GiB	計算
262,144	8.0 GiB	4.0 GiB	計算

もし64層全部フルアテンションなら4倍になります。SGLangドキュメントのモデル全体値 bf16 65.5KB/token, fp8 32.8KB/token とは、TP=2換算で一致します。

4.2 16GBの内訳(計算+コミュニティ実測)

項目	サイズ	区分
NVFP4 重み(半分)	約 10 GB	計算
KVキャッシュ(FP8, 131K)	約 2 GiB	計算
CUDA graphs / 活性 / フレームワーク	約 1〜2 GB	見積もり
合計	約 13〜14 GB	計算

コミュニティ実測の GPU0=14.4GB / GPU1=13.5GB(128K, KV FP8)と整合します。

4.3 NVFP4 前提のコンテキスト最大値(計算)

16GB ×2 でどこまで文脈を伸ばせるかを逆算します。KVキャッシュに使える残量を出し、トークンあたりKVサイズで割ります。

GPU 1枚あたりの予算は次のとおりです。

項目	サイズ	区分
物理VRAM	16 GiB	公式
vLLM 確保分(gpu_memory_utilization=0.92)	14.7 GiB	計算
NVFP4 重み(約20GBの半分)	約 9.3 GiB	計算
CUDA graphs / 活性 / NCCLバッファ	約 1.2 GiB	見積もり
KVキャッシュに残る予算	約 4.2 GiB	計算

図4が16GBの取り合いです。重みが9.3 GiBを占めた後、KVキャッシュに残るのは緑の約4.2 GiBです。

トークンあたりKV(GPU1枚, TP=2)は、BF16 で 32 KiB、FP8 で 16 KiB です。最大コンテキストの逆算は次のとおりです。

KV精度	計算式	最大トークン数	判定
BF16	4.2 GiB ÷ 32 KiB	約 137K	131,072 が実用上限(KV 4.0 GiB)
FP8	4.2 GiB ÷ 16 KiB	約 275K	ネイティブ上限 262,144 に到達(KV 4.0 GiB)

図5のとおり、FP8 KV(青線)は262Kでちょうど4.0 GiBとなり、予算線(緑破線 4.2 GiB)の内側に収まります。BF16 KV(赤線)は131Kで予算に到達するため、そこが上限です。FP8 KV ならネイティブ文脈長 262K をフルに使える計算になります。KV FP8 化が文脈長2倍と等価です。

補足を3点挙げます。

1点目は、Gated DeltaNet 48層の再帰状態です。これは文脈長非依存の固定サイズで、概算 40MB/GPU 程度(見積もり)であり、誤差として無視できます。64層すべてフルアテンションの通常モデルなら、FP8 でも 262K に 16 GiB/GPU 必要で、この構成では不可能です。ハイブリッドアテンションが 5060 Ti 級を長文脈マシンにしていると言えます。

2点目は、MTP です。有効時はドラフトヘッド分の重みが数百MB上乗せされます。262K を狙うなら util を 0.93〜0.94 に上げるか、max-model-len を 240K 程度に落とす必要があります。0.14GB 不足で起動拒否される世界なので、シビアに効きます。

3点目は、これが「載る」上限であって「快適」の上限ではない点です。prefill 262K は第5章の外挿で、通信だけで約11秒、FP4計算(GEMM相当)で約19秒(計算)になります。ただしこの19秒は線形層だけの下限見積もりです。フルアテンションの計算量はトークン数の二乗で増えるため、262Kではフルアテンション16層の寄与が支配的になり、実効のprefill時間はこれを大きく上回ります(しかもアテンション部はFP4ではなくBF16/FP16実行です)。実運用ではchunked prefillで分割投入してピークを平準化します。日常用途なら、max-model-len を 65K〜131K に絞り、KV予算を同時シーケンス数に回す方が実用的です。

262K を狙う場合の vLLM 起動例は次のとおりです。

vllm serve <NVFP4モデル> \
  --tensor-parallel-size 2 \
  --quantization modelopt \
  --kv-cache-dtype fp8 \
  --max-model-len 262144 \
  --gpu-memory-utilization 0.92 \
  --disable-custom-all-reduce

5. prefill と decode の違い

prefill は all-reduce ペイロードが系列長に比例します。8Kプロンプト例(計算)では、8,192 × 10,240 bytes ≒ 80 MiB/all-reduce → 31.5 GB/s で約2.66ms → 128回で約341ms になります。これは完全に帯域支配で、TTFT に直結します。FP4計算量(線形層のGEMM相当)は 2 × 27.78e9 × 8,192 ÷ 2GPU ≒ 2.3e14 FLOPs/GPU → 約0.6秒です。この見積もりにはトークン数の二乗で増えるフルアテンション項を含めていませんが、8K程度なら線形層が支配的なので近似として成り立ちます(長文脈での二次項の効きは4.3節の補足を参照)。8K prefill では通信が3〜4割を占めます。NVLink の効きどころは prefill です。

図6のとおり、同じ all-reduce 128回でも、decode ではレイテンシ(回数)が、prefill では帯域(ペイロード)が効きます。フェーズによって律速要因が入れ替わるのが TP 構成の読み解きどころです。

小メッセージでは ring より tree が有利です(レイテンシが台数線形 vs 対数)。NCCL は小メッセージで LL/LL128 + tree を自動選択します。P2P 無効時はホスト経由コピーにフォールバックし、レイテンシが上昇します。

6. 実践 vLLM Tips(コンシューマ Blackwell 2枚)

6.1 起動フラグ

--tensor-parallel-size 2(載せるための設定と割り切る)、--quantization modelopt(NVFP4のBlackwell専用パス)、--kv-cache-dtype fp8、--speculative-config で MTP(num_speculative_tokens=3)を指定します。

6.2 Blackwell PCIe 必須ワークアラウンド

NVLinkなし・P2PなしのTPでは、vLLM custom all-reduce がワーカー初期化でハングする既知問題があります。--disable-custom-all-reduce または NCCL_P2P_DISABLE=1 が推奨ワークアラウンドとして案内されています。トレードオフとして、custom all-reduce は8MB未満の小ペイロードをNCCLより速く捌く実装ですが、P2P不可環境では選択の余地がありません。

6.3 監視とCUDA graphs

nvidia-smi topo -m で SYS/NODE 表示を確認し、nvidia-smi dmon で PCIe RX/TX を観察します。CUDA graphs はデフォルト有効のままにします(--enforce-eager は避ける)。小カーネル起動オーバーヘッド(約10μs/回)をまとめることで、小バッチ decode で約10〜20%底上げできます。

6.4 MTP の効き

投機が当たれば、確定複数トークンあたりの実効 all-reduce 回数(128回/トークン)を薄められます。通信ボトルネック環境で特に有効です。18→30 tok/s は NVFP4 + MTP + PagedAttention の合わせ技によるものです。

7. 列分割 vs 行分割まとめ表

観点	列分割(縦割り)	行分割(横割り)
W の割り方	出力次元(列)	入力次元(行)
入力	全GPUに複製	特徴次元で分割済み
出力	特徴次元が分割	部分和(要総和)
必要な通信	単独なら all-gather	all-reduce
活性 all-gather が要る場面	次に列分割/非線形が来る時	基本不要
bias の扱い	各GPUが自分の列ぶんを保持	1GPUのみ加算(重複回避)
Megatron での担当	QKV, FFN up/gate	o_proj, FFN down
メモリ均衡	均等	均等

改めて結論です。この表は2方式の性質の違いを整理したものであって、どちらか一方を選ぶための表ではありません。層の役割に応じて列分割(ブロック入口の QKV / up / gate)と行分割(出口の o_proj / down)を使い分け、列→行のペアで通信を2回/ブロックに抑えるのが唯一の実用解です。本記事の vLLM TP=2 構成もこの併用方式で動いています。

8. 実測とベンチの答え合わせ

コミュニティ実測とベンチマークを並べます。

構成	モデル/設定	結果	区分
RTX 5060 Ti ×2, TP=2	Qwen3.6-27B-NVFP4 + MTP, vLLM, 128K文脈	18→30 tok/s, VRAM 14.4/13.5GB, ピーク約190W	コミュニティ実測
RTX 5090 単体	Qwen3.8-27B-NVFP4 + 専用ドラフタ	88.5→180.3 tok/s	コミュニティ実測
RTX 4090 ×2, PCIe, TP=2	vLLM 各種モデル	2枚で約1.4倍前後(報告により幅あり)	コミュニティ実測
RTX 3090 ×2	NVLink 有無比較	TP推論で約+50%差	コミュニティ実測

要点は次のとおりです。

NVFP4 が2枚16GBに載る唯一の現実解です(BF16≈55GB, FP8≈28GB, NVFP4≈14〜20GB)。
PCIe接続TPは1枚あたり約0.70×、NVLink(H100 SXM)は約0.92×/枚が一般則です。
vLLM 公式ドキュメントも、ノード内GPUがNVLink非対応なら TP より PP を用いる方がスループットが高く通信オーバーヘッドも小さいと記載しています。ただし2枚16GBは「まず載せる」が最優先で、TP=2 が唯一 27B-NVFP4 を動かせる構成です。

9. 結論と推奨

decode はメモリ帯域律速です。compute 天井は約44.8 tok/s。通信は10〜20μs/回なら合計1〜2.5msで、数%〜1割の目減りにとどまります。「NVLinkがないとdecodeが遅い」は半分だけ正しいと言えます。
実測30 tok/s は理論の妥当な着地です。
prefill は帯域支配です。8Kで通信341msは無視できません。NVLinkの効きどころです。
FP8 KVキャッシュならネイティブ262Kコンテキストまで到達可能で、BF16 KVなら131Kが上限です。
推奨手順は次のとおりです。(1)NVFP4+KV FP8でまず載せる (2)--disable-custom-all-reduce と NCCL_P2P_DISABLE=1 (3)MTP有効化、CUDA graphsデフォルト維持 (4)長文脈prefill重視や50 tok/s以上必須なら単体大VRAM GPUへ。
しきい値として、実測が約27 tok/s(天井の0.6倍)を大きく下回るなら、通信かオーバーヘッドを疑い、nvidia-smi dmon と設定を確認します。

10. 注意点

通信レイテンシ10〜20μsは推定レンジです。下限10μsはカーネル起動相当の楽観値で、P2P無効のホスト経由コピーでは2〜4倍に上振れしえます。nccl-tests の all_reduce_perf で実測を推奨します(コンシューマGPUはP2P不備でクラッシュ報告もあります)。
NVFP4 総サイズ約20GBはビルド依存で、実在ビルドは約14〜25GBの幅があります。本稿は視覚エンコーダ等をBF16保持する約20GB構成を前提とします。
重み読み出し天井 44.8 tok/s は理論帯域448 GB/sに基づく絶対上限です。実効の持続帯域(約380〜420 GB/s)では相応に下がります。
FP4 dense 約380 TFLOPSは sparse 759 TOPSの半分としての換算値です。
全64層 all-reduce 2回の見積もりは、Gated DeltaNet が Mamba-2 系構造(mixerあたり1回)であることを前提とします。実装詳細で微差が出えます。
262K prefill の計算時間19秒は線形層のみの下限で、フルアテンションの二次項を含めると実効はこれを大きく上回ります。
パラメータ数表記は 27B/28B/27.78B と揺れがあり、本稿は 27.78B を採用します。
スケーリング数値は他モデルのコンシューマ2枚実測からの外挿を含みます。RTX 4090 ×2 の約1.4倍前後は報告により幅があります。
コミュニティ実測(note.com)は単一の実践者による1回計測であり、環境差で変動します。
本文中の図(図1〜図6)はすべて本記事の計算値に基づく作図です。

参考資料

関連記事「LLMの計算はほぼ全部 GEMM (General Matrix Multiply) である」
https://qiita.com/sukimaengineer/items/2708b7d559c70697e105
関連記事「MXFP4 と NVFP4 は何が違うのか調べてみた」
https://qiita.com/sukimaengineer/items/373e39b42b394d88c890
Qwen3.8-27B モデルカード(Hugging Face)
https://huggingface.co/Qwen/Qwen3.8-27B
vLLM Recipes: Qwen/Qwen3.8-27B
https://recipes.vllm.ai/Qwen/Qwen3.8-27B
SGLang Documentation: Qwen3.8-27B(KVキャッシュ諸元)
https://docs.sglang.io/cookbook/autoregressive/Qwen/Qwen3.8-27B
vLLM Documentation: Parallelism and Scaling
https://docs.vllm.ai/en/stable/serving/parallelism_scaling/
vLLM Forums: vLLM hangs during worker initialization on Blackwell PCIe GPUs unless --disable-custom-all-reduce is used
https://discuss.vllm.ai/t/vllm-hangs-during-worker-initialization-on-blackwell-pcie-gpus-unless-disable-custom-all-reduce-is-used/2540
Shoeybi et al., Megatron-LM: Training Multi-Billion Parameter Language Models Using Model Parallelism, arXiv:1909.08053
https://arxiv.org/abs/1909.08053
Li et al., Evaluating Modern GPU Interconnect: PCIe, NVLink, NV-SLI, NVSwitch and GPUDirect, arXiv:1903.04611
https://arxiv.org/abs/1903.04611
Waleffe et al., An Empirical Study of Mamba-based Language Models, arXiv:2406.07887(Mamba-1/Mamba-2 の all-reduce 回数)
https://arxiv.org/abs/2406.07887
Demystifying NCCL: An In-depth Analysis of GPU Communication Protocols and Algorithms, arXiv:2507.04786
https://arxiv.org/abs/2507.04786
How I went from 18 to 30 tok/s with Qwen3.6-27B on 2x 5060 Ti using vLLM + NVFP4-MTP(note.com, cute_agapan9087)
https://note.com/cute_agapan9087/n/nb4b3456ca8b4
VLLM Performance Benchmarks 4x RTX 3090 (Power Limits, and NVLINK)(Himesh's Blog)
https://himeshp.blogspot.com/2025/03/vllm-performance-benchmarks-4x-rtx-3090.html