노드를 추가하면 GPU가 늘고, GPU가 늘면 서빙 속도가 빨라질 것이라는 직관은 자연스럽다. 그런데 단일 노드 8-GPU 구성을 2노드 16-GPU로 확장해보면 throughput이 되려 줄어드는 일이 드물지 않다. Qwen2.5-72B를 TP=8 단일 노드에서 TP=16 2노드로 옮겼더니 decode throughput이 66% 감소했다는 측정 결과가 있다. GPU는 2배인데 성능은 1/3이 됐다.
노드 경계가 만드는 대역폭 절벽
단일 노드 안에서 GPU는 NVLink로 연결된다. H100 기준 NVLink 4.0은 GPU당 양방향 900 GB/s를 제공하고, NVSwitch를 통해 8개 GPU가 풀메시로 직결된다. AllReduce가 수 마이크로초 안에 끝나는 건 이 구조 덕분이다.
노드 경계를 넘으면 이 경로가 사라진다. 대신 InfiniBand 또는 RoCE/이더넷이 들어온다.
| 기술 | 단방향 실효 대역폭 | 레이턴시 |
|---|---|---|
| NVLink 4.0 (H100) | ~450 GB/s | < 1 μs |
| InfiniBand NDR | ~50 GB/s | < 1 μs |
| InfiniBand HDR | ~25 GB/s | < 1 μs |
| RoCE v2 (100GbE) | ~12.5 GB/s | 1~5 μs |
| RoCE v2 (400GbE) | ~50 GB/s | 1~5 μs |
IB HDR 기준으로 NVLink 대비 단방향 대역폭이 18배 낮다. 이 수치가 LLM Multi-Node 서빙에서 throughput 상한을 결정하는 구조적 원인이다.
AllReduce가 Multi-Node에서 느려지는 구조
Tensor Parallel 추론은 매 트랜스포머 레이어에서 AllReduce를 동기화 지점으로 통과한다. Attention과 MLP 출력을 각 GPU가 나눠 계산하고, 그 부분합을 합산해야 다음 레이어로 넘어갈 수 있다. Ring AllReduce의 통신 볼륨은 2 × (N-1)/N × 메시지 크기다.
70B BF16 모델의 hidden dim은 8192다. 배치 크기 32, decode 1스텝이면 레이어 출력 텐서 크기는 32 × 8192 × 2 bytes = 512 KB다. TP=8 단일 노드에서 Ring AllReduce 총 전송량은 GPU당 2 × 7/8 × 512 KB ≈ 896 KB이고, NVLink에서는 수 마이크로초 안에 완료된다.
TP=16으로 2노드를 구성하면 모든 AllReduce 트래픽이 IB HDR(25 GB/s)을 타고 흐른다. 70B 모델은 트랜스포머 레이어 80개 각각에서 Attention 1회, MLP 1회 AllReduce를 발생시킨다. 토큰 1개 생성에 160번의 cross-node collective operation이 필요하다는 뜻이다. TTFT가 단일 노드 19ms에서 2노드 cross-node TP 구성에서 58.5ms로 3배 뛰는 건 이 구조에서 나온다.
Decode 단계에서 통신 숨김이 작동하지 않는 이유
이론적으로 AllReduce를 연산 뒤에 배치하고 다음 레이어 연산을 미리 시작해 통신을 겹칠 수 있다. prefill 단계처럼 배치가 크고 연산량이 충분할 때는 어느 정도 먹힌다.
decode는 다르다. 각 step에서 배치 내 모든 시퀀스가 토큰 1개씩만 생성한다. 처리할 시퀀스 길이가 1이므로 각 GPU의 행렬 연산 시간 자체가 짧다. TP degree가 높을수록 각 GPU가 담당하는 행렬 크기도 더 작아진다. TP=16이면 TP=8보다 연산량이 절반이고, 그 안에서 통신을 숨길 시간적 여유는 더 줄어든다.
32-way TP 구성의 MFU가 33%, 16-way TP가 46%로 나타나는 건 이 구조에서 비롯된다. TP degree를 올릴수록 통신 비용의 상대적 비중이 커지고 GPU가 idle로 기다리는 시간이 늘어난다. 배치 크기 1~8 구간 decode가 가장 취약하다.
Pipeline Parallel을 섞으면 해결되는가
Multi-Node로 나가야 하는 상황에서 TP를 노드 수에 맞춰 단순히 늘리는 것보다 노드 내 TP + 노드 간 PP 혼합이 실제 서빙에서 낫다.
PP는 레이어를 노드별로 분할해 각 노드가 해당 레이어 구간만 처리하고 결과를 다음 노드로 전달한다. 노드 간 전송 데이터는 레이어 경계의 activation 텐서 하나뿐이다. TP처럼 레이어마다 전체 GPU가 동기화하지 않아도 되므로 통신 볼륨 자체가 줄어든다.
단점은 파이프라인 버블이다. 배치 크기가 작을수록 버블 비율이 높아진다. 405B 모델을 다양한 병렬화 전략으로 구성할 때 이론 수치를 비교하면 이렇다.
| 전략 | 노드 간 통신 볼륨 | 파이프라인 버블 |
|---|---|---|
| TP=16, pure TP | 80레이어 × 2 × activation 전체 | 없음 |
| PP=8, pure PP | 레이어 경계 7개 × activation 1개 | ~50% (micro-batch=1) |
| TP=4+PP=2 혼합 | PP 경계 1개 × activation |
TP=8+PP=2 (노드 내 TP, 노드 간 PP) 구성은 pure cross-node TP=16 대비 거의 2배의 throughput을 보인다 (아래 실측 표 참조). 혼합 전략의 우위는 분명하지만, 최적 분할은 배치 크기와 모델 구조에 달려 있어 벤치마크 없이 결정할 수 없다. vLLM에서는 tensor_parallel_size와 pipeline_parallel_size를 각각 지정해 조합 실험이 가능하다.
구성별 throughput 실측
아래는 Qwen2.5-72B 단일 요청 기준 decode throughput 비교다. 단일 요청은 배치 크기 1이므로 통신 비용이 가장 두드러지는 worst-case 조건이다.
| 구성 | GPU 수 | throughput (tok/s) | 단일 노드 대비 |
|---|---|---|---|
| TP=8, 단일 노드 (NVLink) | 8 | 99.5 | 기준 |
| TP=8+PP=2, 2노드 (IB, 노드 내 TP) | 16 | 67.5 | -32% |
| TP=16, 2노드 (IB, cross-node TP) | 16 | 34.3 | -66% |
| TP=4, 단일 노드 | 4 | 60.8 | — |
GPU가 2배인 TP=16 구성이 단일 노드 TP=8보다 66% 느리다. IB 링크를 통해 토큰당 160번의 AllReduce를 수행하는 비용이 연산 병렬화 이득을 압도한 결과다. 배치 크기를 32~128로 키우면 통신 대기 비율이 줄어 절대적 격차는 좁혀지지만, 구성 간 순위 자체는 바뀌지 않는다.
노드를 늘려도 되는 조건
Multi-Node 확장이 throughput 개선으로 이어지려면 세 조건이 동시에 충족돼야 한다.
단일 노드 메모리로 모델이 올라가지 않아야 한다. Llama-3.1 405B처럼 8×H100 (640GB)으로도 부족한 규모라면 분산은 필수다. Qwen2.5-72B는 BF16으로 약 144GB라 8×H100에 올라간다. 이 모델을 굳이 2노드로 쪼갤 이유가 없다.
IB HDR 이상의 네트워크도 필요하다. RoCE 100G (12.5 GB/s)에서 cross-node TP를 돌리면 IB HDR 대비 AllReduce 처리량이 다시 절반으로 줄어든다. 잘 튜닝된 RoCE 400G는 IB NDR에 근접하지만, 기본 구성의 100G RoCE로는 LLM AllReduce가 실질적인 병목이 된다. Meta가 프로덕션 RoCE 클러스터에서 수천 GPU로 LLM 운영이 가능한 건 400G 이상의 백엔드를 갖춘 덕분이다.
배치 크기가 충분히 커서 통신을 연산 뒤에 숨길 수 있어야 한다. 배치 1~8 구간 decode는 통신이 노출되는 구간이 연산보다 길다.
확장 결정 전 확인해야 할 수치는 (1) 모델 파라미터 크기 × 2 (BF16 바이트), (2) 네트워크 실효 대역폭, (3) 서빙 배치 크기 분포다.
통신 병목 현장 측정
# nccl-tests로 단일 노드 vs 멀티 노드 AllReduce 대역폭 측정
# 단일 노드 (8 GPU)
./build/all_reduce_perf -b 512M -e 4G -f 2 -g 8
# 2노드 16-GPU (MPI 사용)
mpirun -np 16 -H node1:8,node2:8 \
./build/all_reduce_perf -b 512M -e 4G -f 2 -g 8
nccl-tests 출력의 busbw 컬럼이 실제 비교 지표다. 단일 노드에서 수백 GB/s가 나왔다면 멀티 노드에서는 IB 링크 대역폭인 20~50 GB/s 수준으로 떨어지는 걸 확인할 수 있다. 이 낙폭이 클수록 cross-node AllReduce가 병목임을 의미한다.
통신이 병목인지 연산이 병목인지는 SM utilization을 같이 봐야 구분된다.
# NCCL AllReduce 소요 시간 로그
NCCL_DEBUG=INFO NCCL_ALGO=Ring python serve.py 2>&1 | grep AllReduce
# GPU SM activity 측정
dcgmi dmon -e 1001,1002,1003
SM utilization이 60~70%로 낮은데 throughput도 낮다면 통신 대기가 원인이다. SM이 90% 이상이면서 throughput이 낮다면 연산 자체가 병목이므로 네트워크를 업그레이드해도 수치가 개선되지 않는다. 이 두 케이스를 구분하지 않으면 IB 업그레이드 비용을 쓰고도 결과를 못 보는 일이 생긴다.