왜 GPU 메모리 대역폭 측정이 LLM 비용 최적화의 첫걸음일까?
LLM(거대 언어 모델)을 서빙하다 보면 GPU Utilization이 30~40%에서 맴도는 경우가 많습니다. "GPU가 놀고 있네?" 싶지만, 실제로는 메모리 대역폭이 병목이라서 연산 유닛이 데이터를 기다리는 현상이 발생합니다. 특히 멀티 GPU 환경에서 모델 병렬화나 텐서 병렬화를 적용할 때 GPU 간 데이터 전송 속도가 전체 추론 지연 시간을 결정합니다.
이런 상황에서 NVIDIA가 공개한 NVbandwidth는 GPU 시스템의 메모리 전송 특성을 정밀하게 진단할 수 있는 CUDA 기반 벤치마크 도구입니다. 이 도구로 다음을 측정할 수 있습니다:
- CPU → GPU (Host to Device, H2D)
- GPU → CPU (Device to Host, D2H)
- GPU ↔ GPU (Device to Device, D2D)
- 단방향/양방향/멀티 노드 전송
이 글에서는 NVbandwidth의 설치부터 실전 활용까지를 코드와 함께 단계별로 안내합니다. LLM 추론 비용 폭탄? NVIDIA Runai와 NIM으로 GPU 활용률 2배 높이는 법 글과 함께 보면 GPU 효율화 전략의 완성판이 됩니다.
NVbandwidth 설치 및 기본 사용법
시스템 요구 사항
- CUDA 11.x 이상 (싱글 노드), CUDA 12.3 + 드라이버 550+ (멀티 노드)
- C++17 호환 컴파일러 (GCC 7.x 이상)
- CMake 3.20+ (3.24 권장)
- Boost program options 라이브러리
빌드하기
# 저장소 클론
git clone https://github.com/NVIDIA/nvbandwidth.git
cd nvbandwidth
# CMake 빌드
mkdir build && cd build
cmake .. -DCMAKE_BUILD_TYPE=Release
make -j$(nproc)
# 실행 파일 확인
./nvbandwidth --help
기본 실행: 시스템 전체 대역폭 측정
# 모든 테스트 실행 (기본값)
./nvbandwidth
# 특정 테스트만 실행: Device to Device (Copy Engine, 단방향)
./nvbandwidth -t device_to_device_memcpy_read_ce -b 1024 -i 10 -j
옵션 설명:
-t: 테스트 이름 (전체 목록은--help)-b: 버퍼 크기 (MiB 단위, 기본 256)-i: 반복 횟수 (기본 5)-j: JSON 형식 출력
예제 출력 해석
Running host_to_device_memcpy_ce.
memcpy CE CPU(row) -> GPU(column) bandwidth (GB/s)
0 1
0 55.63 55.64
SUM host_to_device_memcpy_ce 111.27
COEFFICIENT_OF_VARIATION host_to_device_memcpy_ce 0.00
55.63 GB/s: GPU 0으로의 단일 스트림 대역폭SUM 111.27: 두 스트림 합계 (양방향이 아님, 단순 합)COEFFICIENT_OF_VARIATION: 변동 계수 (0에 가까울수록 안정적)
💡 실무 팁: 실제 LLM 서빙에서는 모델 병렬화 시 GPU 간 P2P 대역폭이 중요합니다.
device_to_device_memcpy_read_ce테스트로 NVLink 대역폭을 확인하세요. 만약 PCIe를 통해 데이터가 흐른다면 대역폭이 절반 이하로 떨어질 수 있습니다.
고급 활용: 멀티 노드 및 양방향 테스트
양방향 대역폭 측정
양방향 테스트는 데이터가 동시에 양방향으로 흐를 때의 실제 대역폭을 측정합니다. LLM 학습 시 gradient all-reduce 같은 collective communication의 성능을 예측하는 데 필수적입니다.
# Device to Device 양방향 (Copy Engine)
./nvbandwidth -t device_to_device_memcpy_bidirect_ce -b 1024 -i 10
멀티 노드 설정 (MNNVL 환경)
NVIDIA Multi-Node NVLink (MNNVL) 시스템에서 노드 간 대역폭을 측정하려면 추가 설정이 필요합니다.
# 1. IMEX 서비스 시작
sudo systemctl start nvidia-imex.service
# 2. 노드 설정 파일 작성 (/etc/nvidia-imex/nodes_config.cfg)
node1 slots=4
node2 slots=4
# 3. MPI 실행
mpirun --allow-run-as-root --map-by ppr:4:node --bind-to core \
-np 8 --report-bindings \
-q -mca btl_tcp_if_include enP5p9s0 \
--hostfile /etc/nvidia-imex/nodes_config.cfg \
./nvbandwidth -p multinode
멀티 노드 출력 예시 (8 GPU, 2노드):
memcpy CE GPU(row) -> GPU(column) bandwidth (GB/s)
0 1 2 3 4 5 6 7
0 N/A 397.4 397.4 397.6 397.5 397.5 397.7 397.6
1 397.7 N/A 397.4 397.5 397.5 397.5 397.5 397.6
...
⚠️ 주의사항: 멀티 노드 테스트는 반드시 동일한 NVLink 도메인에 속한 노드끼리만 가능합니다. IMEX 서비스가 정상 동작하지 않으면 PCIe를 통한 fallback이 발생해 대역폭이 급감합니다. 또한, 멀티 노드 모드는 CUDA 12.3 이상에서만 지원됩니다.
실무 적용: NVbandwidth로 LLM 인프라 진단하기
1단계: 베이스라인 측정
새로운 GPU 클러스터를 도입했거나 드라이버/펌웨어를 업데이트했다면, 변경 전후로 NVbandwidth를 실행해 대역폭 변화를 기록하세요. 예상보다 낮은 수치가 나온다면 하드웨어 문제나 드라이버 설정 오류를 의심할 수 있습니다.
2단계: 병목 지점 식별
LLM 서빙 중 GPU Utilization이 낮다면 다음을 체크하세요:
- 모델 병렬화 사용 시: GPU 간 P2P 대역폭이 충분한가? (NVLink vs PCIe)
- 데이터 로딩 병목: H2D 대역폭이 CPU 메모리 대역폭보다 낮은가?
- 멀티 노드: 노드 간 대역폭이 단일 노드 내 NVLink 대역폭의 1/10 이하라면 네트워크 토폴로지 재검토 필요
3단계: 최적화 방향 설정
NVbandwidth 결과를 바탕으로 다음과 같은 최적화를 고려하세요:
- Copy Engine vs SM Copy: SM copy는 연산 유닛을 사용하므로 학습 중에는 피하고, 추론 전용 노드에서만 사용
- 버퍼 크기 조정: 작은 버퍼(1MB 이하)에서는 latency가 지배적이므로 큰 배치(batch)를 사용해 대역폭 활용도 향상
- GPU 친화적 데이터 레이아웃:
cudaMemcpyAsync와 스트림을 활용해 데이터 전송과 연산을 overlap
함께 보면 좋은 글
- 게임에서 AI 에이전트 추론 비용, 이렇게 줄이세요 NVIDIA IGI SDK 코드 에이전트 실전 가이드
- LLM 추론 비용 폭탄? NVIDIA Runai와 NIM으로 GPU 활용률 2배 높이는 법
다음 단계 학습 방향
NVbandwidth로 대역폭을 측정했다면, 이제 NVIDIA Nsight Compute로 커널 수준의 메모리 접근 패턴을 분석하고, NCCL의 all-reduce 성능을 프로파일링하는 것을 추천합니다. 실제 LLM 학습/추론 파이프라인에서의 end-to-end 성능 최적화로 이어가세요.