GPU 수만 보고 성능을 예상하면 안 된다

같은 8-GPU 학습이라도 어떤 장비에서는 step time이 안정적이고, 어떤 장비에서는 통신 때문에 거의 확장이 되지 않는다. 차이를 만드는 핵심은 토폴로지다.

  • GPU끼리 NVLink로 직접 연결되어 있는가
  • 같은 node 안에서도 PCIe switch를 어떻게 공유하는가
  • node 간 연결이 Ethernet인가, InfiniBand인가
  • NIC와 GPU의 배치가 NUMA 관점에서 맞는가

이 조건이 바뀌면 같은 all-reduce라도 비용이 크게 달라진다.

NCCL은 무엇을 해주는가?

NCCL은 NVIDIA 환경에서 GPU 간 collective 통신을 효율적으로 수행하기 위한 라이브러리다. all-reduce, all-gather, reduce-scatter 같은 연산을 토폴로지에 맞춰 선택하고 최적화한다.

중요한 점은 NCCL이 마법은 아니라는 것이다. 토폴로지가 나쁘면 NCCL도 그 제약 안에서만 움직일 수 있다.

즉 우리가 이해해야 하는 것은:

  • 어떤 collective가 많이 발생하는가
  • 그 collective가 intra-node인지 inter-node인지
  • NCCL이 어떤 링크를 주로 사용하게 되는가

실무에서 보는 대표적인 병목

1. inter-node 구간이 느린 경우

한 node 안에서는 NVLink로 빠르게 통신하지만, node 사이에서는 훨씬 느린 링크를 타면 scaling efficiency가 급격히 떨어진다. 이 경우 bucket 크기, overlap, parallel strategy를 다시 봐야 한다.

2. rank 배치가 비효율적인 경우

프로세스를 잘못 배치하면 동일 node 안에서 끝낼 수 있는 통신이 불필요하게 더 먼 경로를 탈 수 있다.

3. 네트워크가 병목인데 compute만 보고 있는 경우

프로파일에서 kernel은 짧은데 step time이 길다면, NCCL 대기나 straggler rank를 의심해야 한다.

관찰해야 할 신호

  • GPU utilization은 높은데 scaling efficiency가 낮다
  • node 수를 늘릴수록 step time이 선형보다 더 나빠진다
  • 특정 collective에서 시간이 튄다
  • 일부 rank만 반복적으로 늦다

이런 신호는 모델 코드보다 시스템 배치 쪽 문제일 수 있다.

왜 이제 tensor parallel로 넘어갈 수 있는가

data parallel과 NCCL 토폴로지를 이해하면, 이제 "모델 자체를 나누는 전략"으로 넘어갈 준비가 된다. tensor parallel은 단순한 통신 최적화가 아니라, 연산 자체를 여러 GPU에 분산하는 방식이기 때문이다.

다음 글에서는 tensor parallel의 기본 아이디어와 어떤 연산이 잘 분할되는지부터 본다.