きっかけ#

Kaggle の ARC Prize 2026（ARC-AGI-2）で、NVIDIA L4 を 4 枚積んだノートブックを使って LLM の推論を回していた¹。生成できるトークン数がそのままスコアに効くコンペなので、少しでも速くしたい。そこで、トークンを生成する前向き計算 1 回（以下、1 歩）の内訳を測ると、約 1/3 が GPU の計算ではなく GPU 間の通信だった。

ここで初めて NCCL をちゃんと調べた。複数 GPU で学習している人たちにとっては当たり前の話だと思う。ただ、1 枚の GPU でやってきた身には、ログに出てくる via SHM も Algo RING も意味が分からなかった。

この記事は当時の自分のような、これから複数 GPU を触る人向けの解説である。後半の実測は学習ではなく推論のものなので、そこは割り引いて読んでほしい。

NCCL は GPU どうしの通信係#

NCCL は NVIDIA Collective Communications Library の略で、「ニッケル」と読む²。名前のとおり、複数の GPU の間でデータをやり取りするための NVIDIA 製ライブラリである。

普段はこれを直接呼ばない。学習フレームワークや推論エンジンの下で動いている。

PyTorch を使っているなら、CUDA 版を入れた時点で NCCL も使える状態になっていることが多い。Linux の PyTorch は NCCL を含んだ形でビルドされているからである³。PyTorch の指針も分かりやすく、CUDA の GPU で分散学習するなら NCCL、CPU なら Gloo を使う³。

手元の版は次のように確かめられる。

1
python -c "import torch; print(torch.cuda.nccl.version())"

なぜ GPU 間の通信が必要なのか#

GPU を 4 枚に増やしても、それぞれが勝手に計算するだけでは 1 つのモデルを動かせない。途中で結果を合わせる必要がある。学習と推論で、合わせるものが違う。

1
実行前: GPU0=1  GPU1=2  GPU2=3  GPU3=4
2
実行後: GPU0=10 GPU1=10 GPU2=10 GPU3=10

1
import os
2
import torch
3
import torch.distributed as dist
4
from torch.nn.parallel import DistributedDataParallel as DDP
5

6
dist.init_process_group(backend="nccl")  # ここで NCCL を指定する
7
local_rank = int(os.environ["LOCAL_RANK"])
8
torch.cuda.set_device(local_rank)
9

10
model = MyModel().cuda(local_rank)
11
model = DDP(model, device_ids=[local_rank])  # 開始時に rank 0 の重みを全員へ配る（Broadcast）
12

13
# 学習ループの中
14
loss.backward()  # 勾配を全員で平均する（AllReduce）

1
torchrun --nproc_per_node=4 train.py

NCCL ができること#

こうした「全員が参加する通信」を集団通信（Collective）と呼ぶ。代表的なものは次のとおりで、ほかに Reduce、ReduceScatter、AlltoAll、Gather、Scatter と、1 対 1 の Send / Recv がある²。

まずは AllReduce だけ覚えておけば、ログや資料はだいぶ読める。

どの経路で通信するか#

通信の速さを大きく左右するのは、GPU どうしのつながり方である。まず次のコマンドで確認できる。

1
nvidia-smi topo -m

L4×4 の Kaggle ノートブックでは、次のように出た。

1
        GPU0    GPU1    GPU2    GPU3
2
GPU0     X      PHB     PHB     PHB
3
GPU1    PHB      X      PHB     PHB
4
GPU2    PHB     PHB      X      PHB
5
GPU3    PHB     PHB     PHB      X
6

7
PHB  = Connection traversing PCIe as well as a PCIe Host Bridge (typically the CPU)
8
NV#  = Connection traversing a bonded set of # NVLinks

PHB は、CPU 側のブリッジを越える PCIe 接続という意味である。ここが NV# になっていれば、GPU 専用の高速な線である NVLink でつながっている。手元の L4×4 に NVLink は無かった。

同じマシンの中では、NCCL は主に次の経路（トランスポート）を使い分ける。

• SHM: CPU 側のメモリを受け渡し場所にする
• P2P: GPU どうしが直接やり取りする。NVLink があればそれを使う

別のマシンへは、InfiniBand や RoCE、普通の IP ソケットを使う²。

手元の L4 で測ると、GPU の中のメモリのコピーは 231 GB/s、PCIe を越えて別の GPU へ送るコピーは約 10 GB/s だった。GPU の外に出た瞬間に、20 分の 1 ほどの細さになる。通信が重くなるのはこのためである。

通信のやり方も NCCL が選ぶ#

経路のほかに、NCCL はアルゴリズムとプロトコルも選んでいる。NCCL はコストモデルで所要時間を見積もり、大きさごとに組み合わせを決める⁵。

• アルゴリズム: データを回す順番のこと。輪になって順に渡す Ring はピーク帯域に強く、木の形で渡す Tree は中くらいのサイズに強い
• プロトコル: データの送り方のこと。Simple は帯域向き、LL は遅延向きで、LL128 はその中間である

自動で選ばれている様子は、ログで実際に見える。次は L4×4 での実物で、同じ AllReduce でも大きさでプロトコルが変わっている。

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}

L4×4 で環境変数をいじってみた#

ここからは手元の実験記録である。先に書いたとおり、学習ではなく推論での値になる。

• 環境: NVIDIA L4（24 GB）× 4、PCIe、vLLM 0.32 の TP4、NCCL 2.29.7

profiler で 1 歩の内訳を見ると、AllReduce が 27%、AllGather が 7% だった。AllReduce は 1 歩で 135 回、1 回の中央値は 256 µs で、1 回あたり 600 KB 前後を送っている。

通信が 1/3 なら設定で詰められるのではないかと思い、NCCL の環境変数を 24 設定試した。目標は通信時間の −15% である。

NCCL が選んだ既定の組み合わせを、大きく超えるものは無かった。分かったことは 3 つある。

1 つ目は、設定で縮む余地が小さかったこと。最良でも 2〜3% で、しかも本数が少ないと逆に遅くなる。バッファを小さくする設定は、公式が「一部の PCIe 構成で効くことがある」と書いているとおり、少ない本数では 5% ほど縮んだ⁶。ただ、同時に流す本数が多い 1 歩ではほぼ差が無く、サーバーに負荷をかけて 1 MiB にしたときも +0.8% だった。

2 つ目は、直接通信のほうが遅かったこと。ホストメモリを経由する SHM より、GPU どうしが直接やり取りする P2P のほうが速そうに見える。実際は TP4 で 3.9〜7.6 倍遅くなった。同じ機の TP2 では P2P のほうがわずかに速かった（0.86 倍）ので、TP4 に固有の崩れのようだが、原因は特定できていない。少なくともこの構成では、NCCL が既定で SHM を選んだのは正解だった。

3 つ目は、効いたのは通信の量を減らす手だったこと。vLLM の use_local_argmax_reduction は、下書きトークンを選ぶときに全 GPU の logits を集めず、各 GPU の中の候補だけを集める設定である。答えの分布を変えずに 1 歩が約 2.6% 速くなり、提出の候補まで進めた。ただし、回数を減らせば何でもよいわけではない。1 サーバーの GPU を 2 枚にして TP2 × 2 組にすると、通信は減るのに生成は 0.38 倍になった。1 サーバーの KV キャッシュが足りなくなったためで、この話は vLLM と SGLang の記事 に書いた。

数字の範囲も書いておく。L4×4 の数回のセッションでの結果で、各設定は基本的に 1 回の測定である。24 設定には、既定と処理が変わらなかったものや、読み込まれたか確かめられなかったものも含む。NVLink のある機や別の版では結果が変わりうる。公式ドキュメントは 2026-11-06 時点で 2.32.3 まで進んでいる。

速くしたいときの順番#

以上を踏まえて、初めて複数 GPU を触る人に勧める順番をまとめる。

1
NCCL_DEBUG=INFO NCCL_DEBUG_SUBSYS=INIT,GRAPH torchrun --nproc_per_node=4 train.py

1
NCCL INFO NCCL version 2.29.7+cuda13.2
2
NCCL INFO Channel 00 : 0[0] -> 1[1] via SHM/direct/direct

つまずきやすいところ#

速い遅い以前に動かない場合は、次のあたりを見る。

• Docker で初期化に失敗する: SHM は /dev/shm を使うので、コンテナの既定のサイズだと足りないことがある。NCCL_DEBUG=WARN で failed to extend /dev/shm/nccl-... と出たら、docker run に --shm-size=1g --ulimit memlock=-1 を足す⁸
• 複数ノードで無言のまま止まる: 使うネットワークの指定が実際の配線とずれていることがある。DGX Spark 2 台をつないだときに踏んだ話は こちらの記事 に書いた

自分の結論#

NCCL の既定はかなり賢い。少なくとも PCIe の L4×4 では、環境変数を 24 設定試しても、既定を大きく超えるものは無かった。

だから、速くしたいときは環境変数をいじる前に nvidia-smi topo -m と NCCL_DEBUG=INFO で経路を確かめ、通信の回数と量を減らす側を考えること。普段は意識しなくていいが、通信が律速になったときに「何を見ればいいか」を知っているかどうかで、回り道の長さが変わると思う。

参考文献#

1. ARC Prize https://arcprize.org/
2. Overview of NCCL — NCCL documentation https://docs.nvidia.com/deeplearning/nccl/user-guide/docs/overview.html
3. Distributed communication package - torch.distributed — PyTorch documentation https://docs.pytorch.org/docs/stable/distributed.html
4. Distributed Data Parallel — PyTorch documentation https://docs.pytorch.org/docs/stable/notes/ddp.html
5. Understanding NCCL Tuning to Accelerate GPU-to-GPU Communication — NVIDIA Technical Blog https://developer.nvidia.com/blog/understanding-nccl-tuning-to-accelerate-gpu-to-gpu-communication/
6. Performance and tuning — NCCL documentation https://docs.nvidia.com/deeplearning/nccl/user-guide/docs/troubleshooting/performance_and_tuning.html
7. Environment Variables — NCCL documentation https://docs.nvidia.com/deeplearning/nccl/user-guide/docs/env.html
8. Runtime and MPI issues — NCCL documentation https://docs.nvidia.com/deeplearning/nccl/user-guide/docs/troubleshooting/runtime_and_mpi_issues.html