Communicator・Channel・Transport#

まず、ログや資料に出てくる 3 つの言葉を整理する。

1
Communicator（通信に参加する全 GPU の集まり）
2
├── Channel 0  ← データを分割して並列に流す通信路
3
│   ├── Ring / Tree の接続関係
4
│   └── Transport（各区間の実際の転送手段）
5
├── Channel 1
6
└── ...

Transport は区間ごとに次から決まる。

Channel を増やせば帯域を使い切りやすくなるが、公式によると CUDA の計算資源も多く使う¹。NVIDIA のブログも、増やすと計算との競合で全体が遅くなる場合があるとしている²。入門編の表で NCCL_MIN_NCHANNELS=8 が 1.16 倍遅くなったのも、少なくとも増やせば速くなるわけではないことを示している。なお、この変数は 2.17 で非推奨になり、今は NCCL_MIN_CTAS が後継である¹。

初期化の流れ#

GPU のつながり方から通信の選択肢を作るまでは、次の順に進む³。それぞれ NCCL_DEBUG=INFO と NCCL_DEBUG_SUBSYS でログを見られる。

最後の表が、次の節以降の主役である。

アルゴリズム#

NCCL_ALGO に指定できる値は次のとおりである¹。

PCIe だけの L4×4 で実際の候補になるのは Ring と Tree だけである。

プロトコル#

3 つのプロトコルの違いは、NCCL の内部を分析した論文「Demystifying NCCL」の表が分かりやすい⁵。

遅延の値は、この論文が使った GH200 と NCCL 2.19.1 での目安である。同じ論文の 16 ノードの測定では、64 KiB 未満は LL と LL128 が速く、GB 級では Simple が大きく勝っていた⁵。

LL128 が両方に強そうに見えるが、未対応の環境で有効にするとデータが壊れることがあるので、自分で指定する変数ではない¹。

L4×4 のログが読めるようになった#

入門編に載せたログは、4 バイトでも 8 KB でも Algo RING だった。小さいデータなら Tree になりそうなものだが、この式で読むと納得がいく。

1
NCCL INFO AllReduce: 4 Bytes -> Algo RING proto LL channel{Lo..Hi}={0..0}
2
NCCL INFO AllReduce: 8192 Bytes -> Algo RING proto LL channel{Lo..Hi}={0..0}
3
NCCL INFO AllReduce: 215040 Bytes -> Algo RING proto SIMPLE channel{Lo..Hi}={0..1}

PCIe・1 ノード 4 枚・LL での遅延は、ソースの定数から計算すると Ring が 12.6（6.6 ＋ 6 × 1.0）、Tree が 12.8（6.8 ＋ 6 × 1.0）である⁶。ほぼ同じなので、少なくとも遅延の項には Tree を選ぶ理由が出てこない。

ただ、見積もりと実機が常に合うわけではない。先ほどの Demystifying NCCL は、GH200 の測定でノード内でも小さいサイズでは Tree が良いと報告している⁵。

NCCL_ALGO=Tree でエラーになった理由#

前回の実験では、NCCL_ALGO=Tree にすると AllGather が invalid usage で落ちた。公式の説明を読むと、2.24 からは指定に Ring が含まれない場合、ほかに有効なアルゴリズムが無い集団通信は Ring に戻らず失敗する¹。2.29.7 での自分のエラーも、これに当てはまるとみている。

同じ 2.24 から、集団通信ごとに指定できるようになっている¹。試すなら次の形が安全である。

1
NCCL_ALGO="allreduce:tree"    # AllReduce だけ Tree を許可する
2
NCCL_ALGO="allreduce:^tree"   # AllReduce で Tree だけ外す

ノードをまたぐと Ring と Tree の差が開く#

最初の 2 行は、スタンフォードの授業プロジェクトの測定である¹¹。同じ A100 8 枚でも、1 ノードなら自動選択と最良の組の差は平均 1.2%、64 MB でも 2.3% だった。2 ノードに分けてノード間を約 10 Gbps の TCP にすると、自動選択は全サイズで Ring を選び、最良の Tree との差は 64 MB で 57.2% に広がった。授業の 6 ページの報告で、クラウド上の小さな構成である点は割り引く必要があるが、ノードをまたぐと差が開く点は先の式と合っている。

本番規模では Meta の論文が参考になる¹²。NCCL の調整は低い遅延（10 µs 未満）の環境を前提にしていて、RTT が 22 µs ある自社の環境では最適にならなかったという。Meta は、NCCL の既定より大きなサイズまで Tree や LL128 を使うように調整した。Ring の AllGather は大きなジョブで遅延が積み上がるとも書いている。

したがって、Ring と Tree の選定が効くのは主にノードをまたぐ場面で、それは多くの場合に学習である。予想が当たっていたのはこの部分である。

NVLink の推論では別の形で効く#

外れていたのは「推論では効かない」という部分である。2026 年 7 月の NVIDIA と ETH チューリッヒの論文は、長い文脈の推論を、帯域より遅延が律速になる代表例として扱っている¹⁰。バッチが小さくなって 1 回の AllReduce が小さくなり、それがトークン生成の経路に何度も並ぶからである。

GB200 4 枚では、小さなサイズの AllReduce が NCCL の Ring の 11.0 µs から低遅延カーネルの 2.37 µs に縮み、Llama 3.1 70B のトークン間の時間が 8.7% 減った。条件ごとの最良の設定では、4 枚で 7〜13%、8 枚で 9〜11% 減っている¹⁰。1 回が 4.6 倍速くなっても全体は 1 割前後である一方、1 割はサービスの費用としては大きい。

このカーネルは、NCCL_ALGO で Ring と Tree を切り替える話とは別物である。

• NCCL は対称メモリ（全 GPU で同じ仮想アドレスを持つバッファ）に登録すると使える低遅延カーネルを 2.27 から用意している¹³
• vLLM も独自の custom AllReduce を持ち、NCCL の対称メモリを使う VLLM_USE_NCCL_SYMM_MEM=1 も入っている¹⁴

つまり、推論ではアプリと NCCL の境界を変える形で選定が進んでいる。vLLM の PR の表には、8 GPU・8 MB で通常の呼び出しが 0.074、対称メモリが 0.037（単位の記載なし）という行がある。ただし、同じ PR のスループットの比較は +3.5% で、比較元の条件が明記されていないので参考程度である¹⁴。

PCIe の推論では、そもそも帯域で決まっていた#

手元の L4×4 に低遅延の話が当てはまらなかったのは、1 回の通信の大半が帯域で決まっていたからである。データを約 215 KB と約 645 KB にした 2 点で直線を引くと、1 回は固定で約 58 µs、残りはサイズに比例していて、645 KB の 1 回（約 0.25 ms）の 77% が比例の部分だった。2 点だけの概算だが、遅延を削っても縮む余地は小さく、帯域の良い Ring・Simple が選ばれたのは自然である。

vLLM の custom AllReduce の結果も分かりやすかった。

2 枚なら速いのに、4 枚に強制すると 4.40 倍遅い。vLLM は PCIe だけの 3 枚以上で custom AllReduce を切っていて、自分はそれを上書きして試した。P2P が TP4 で遅かった入門編の結果と同じ種類の崩れに見えるが、原因は特定できていない。NCCL 側も 2.29 系のリリースノートに「PCIe では性能が出ないので、組み込みの対称カーネルは NVLink が全結合の環境だけで有効にした」と書いている¹⁵。

NVLink 向けの低遅延の工夫は、PCIe の複数枚にはそのまま持ち込めない。これが自分の環境での答えだった。

学習なら L4×4 でも効くのか#

ここは未測定である。DDP の 25 MiB は手元の 600 KB よりずっと大きく、1 ノードなら段数の差も無いので、帯域に強い Ring・Simple がそのまま選ばれ、やはり差は小さいと予想している。ただ、自分の実験は推論だけで、これは式からの推測にすぎない。

なお、1 ノードでも既定が常に最良とは限らない。B300 8 枚の測定では、4〜128 MiB の AllReduce で既定の NVLS より Ring のほうが最大で約 27% 速かった¹⁶。NVSwitch があると候補が増えるので、PCIe より選定の余地が大きいのかもしれない。

1. 何が選ばれているかを見る#

1
NCCL_DEBUG=INFO NCCL_DEBUG_SUBSYS=TUNING torchrun --nproc_per_node=4 train.py

通信のたびに行が出るので、ログを出したまま速さを測らないようにしたい。

2. サイズごとの所要時間を測る#

公式の nccl-tests を使えば、サイズを振った測定を簡単にできる¹⁷。自分の実験は自作のベンチで、このコマンドは手元の L4×4 では回していない。

1
# 1 ノード 4 枚で、8 B から 128 MiB まで 2 倍ずつ
2
./build/all_reduce_perf -b 8 -e 128M -f 2 -g 4

実際の通信サイズの近くで 2 点を取り、直線を引く。傾きの部分が大きければ帯域で決まっていて、切片の部分が大きければ遅延で決まっている。前者なら量を減らす手、後者なら回数を減らす手や低遅延カーネルが候補になる。

3. ノードをまたぐなら Tree も試す#

複数ノードで通信が重いときは、Tree を試す価値がある。1 つの集団通信だけに絞れば、ほかを壊さない。MPI を有効にしてビルドした nccl-tests なら、次のように 2 ノードで比べられる¹⁷。

1
# 2 ノード 8 プロセスで、AllReduce だけ Tree を許可する（OpenMPI の例）
2
mpirun -np 8 -N 4 -x NCCL_ALGO="allreduce:tree" ./build/all_reduce_perf -b 8 -e 128M -f 2 -g 1

差が再現して、組織で長く運用するなら、環境変数で固定するより tuner プラグインが筋が良い。NCCL_TUNER_PLUGIN で読み込むプラグインは、サイズや規模ごとの選択を上書きできる¹²。環境変数はプロセス全体に効くうえ、NCCL を更新したあとも残り続けるからである²。

主な環境変数#

公式はデバッグの区分の変数について「実験や問題の切り分けには使ってよいが、本番のコードには基本的に設定しない」としている¹。

名前に DEBUG が付くものがシステム設定で、NCCL_BUFFSIZE がデバッグ側なのは少し意外だった。