동일한 NVIDIA H100, GB200 NVL72 또는 GB300 NVL72 시스템으로 구성된 두 AI 컴퓨팅 클러스터라 할지라도, 실제 현장에서는 학습 처리량에서 큰 차이가 나는 경우가 있습니다. 동일한 워크로드, 동일한 모델, 동일한 글로벌 배치 크기로 실행하더라도, 파트너 배포 환경과 NVIDIA 레퍼런스 아키텍처 간에 8%~12%의 성능 격차가 발생하는 사례를 자주 접하게 됩니다.
원인은 대개 커널, 하이퍼바이저, BIOS, NVIDIA Collective Communications Library(NCCL) 설정에서의 구성 선택들이 누적된 결과입니다. 각각 몇 퍼센트씩 손실을 일으키는 이 요소들이 합산되면 NVIDIA Exemplar Cloud 인증에 필요한 95% 임계값을 충족하지 못할 만큼 큰 격차로 벌어집니다.
이 글은 실제 파트너 클러스터에서 진행한 네 가지 디버깅 사례를 다룹니다. 각 사례는 스택의 서로 다른 계층을 분리하여 분석합니다. NVIDIA Grace CPU의 SMMU(System Memory Management Unit)과 페이지 테이블 동작, x86 기반 CPU의 전력 관리 및 Non-Uniform Memory Access 배치, 1.6 Tbps 패브릭에서의 NVIDIA NCCL 큐 페어 동시성, 그리고 눈에 띄지 않는 하드웨어 설치 결함이 그 대상입니다. 또한 perf, NVIDIA Nsight Systems 또는 NVIDIA NCCL tests에서 근본 원인을 지목하는 구체적인 신호와 함께, 격차를 좁힌 튜닝 변경 사항도 소개합니다.
이 벤치마크를 이미 실행하고 있는 인프라 엔지니어와 성능 아키텍처 전문가라면, 정식 레퍼런스 아키텍처 검증에 앞서 내부적으로 사용하는 이러한 진단 패턴을 자체 클러스터에 직접 적용해 유용하게 활용할 수 있습니다.
선결 조건
이 글에 소개된 진단 절차를 재현하려면 다음 항목이 필요합니다.
- NVIDIA Quantum InfiniBand 또는 RoCE 인터커넥트 기반의 NVIDIA HGX H100, HGX H200, HGX B200, GB200 NVL72 또는 GB300 NVL72 시스템 클러스터
- 안정적인 이터레이션 타임이 확보된 분산 학습 워크로드(Llama 3 모델 기반 NVIDIA NeMo, NVIDIA Nemotron 또는 DeepSeek 구성이 적절한 레퍼런스가 됩니다.)
perf, BIOS/UEFI 변경 및 커널 파라미터 수정을 수행할 수 있는 최소 1개 노드의 루트 권한- 학습 스택에서 사용하는 것과 동일한 버전의 NCCL로 빌드된
nccl-tests, NVIDIA Nsight Systems, 그리고 커널 심볼을 사용할 수 있는 Linux perf
학습 성능 격차를 유발하는 공통 패턴
최근 Exemplar 학습 참여 사례를 보면, 성능 격차는 단 하나의 명확한 결함에서 비롯되는 경우가 드뭅니다. 대부분 워크로드 부하 상태에서만 드러나는 구성 세부 사항에서 비롯됩니다. 반복적으로 나타나는 패턴은 다음과 같습니다:
- Grace 및 가상화 준비 상태: 누락된 플랫폼 기능, SMMU 오버헤드, IOMMU 동작, 또는 예상 구성과 일치하지 않는 페이지 크기 설정
- CPU 전력 및 프로세스 배치: 예상 터보 주파수 이하로 동작하는 코어, 잘못된 코어에 배치된 랭크 또는 헬퍼 스레드, 또는 플랫폼 토폴로지와 일치하지 않는 NUMA/PCT 바인딩
- 런타임 토폴로지: 노드에서는 올바르게 설정된 호스트 토폴로지 파일이나 NCCL 설정이 워크로드 컨테이너나 런처 환경 내부로 전파되지 않는 경우
- 패브릭 및 집합 통신 동작: 대상 패브릭, 메시지 크기, 또는 학습 워크로드 규모에 맞지 않는 NCCL 설정
- 애플리케이션-플랫폼 바인딩: 토폴로지 인식 어피니티 대신 코어 ID나 랭크 순서로 바인딩되는 학습 프로세스
이러한 요소들이 학습 성능 격차의 모든 원인을 설명해 주는 것은 아니며, 본 점검 과정이 실제 애플리케이션을 통한 검증을 대체할 수도 없습니다.
이어지는 네 가지 사례 연구는 최근 학습 작업에서 이러한 패턴들이 실제로 어떻게 발생하는지 보여줍니다. 각 사례별로 문제를 나타낸 신호, 적용된 수정 사항, 그리고 이를 검증한 방법을 구체적으로 다룹니다. 단, 제시된 사례의 순서가 절대적인 진단 우선순위를 의미하지는 않으며, 워크로드의 특성과 플랫폼 환경, 프로파일러에서 최초로 포착된 신호에 따라 적절한 분석 시작점을 선택해야 합니다.
사례 연구 1: NVIDIA GB200 NVL72 FP8 사전 학습, 가상 머신(VM) 환경에서 베어메탈 대비 12% 성능 저하
계층: 가상화 및 SMMU
VM 내에서 DeepSeek-V3 Mixture-of-Experts(MoE) FP8 사전 학습을 실행 중인 GB200 NVL72 파트너 배포 환경에서 반복 시간이 베어 메탈 RA 대비 12%~14% 길게 나타났습니다. Llama 3 70B와 같은 밀집 모델의 사전 학습 레시피는 RA 성능의 3% 이내로 동작했지만, 반복당 소규모 커널을 다수 실행하는 DeepSeek-V3 MoE가 유독 이상 수치를 보였습니다.
파트너 클러스터에서 캡처한 Nsight Systems 트레이스를 보면 워크로드의 소규모 커널 영역에서 CPU 오버헤드가 현저히 높게 나타났습니다. CPU 단일 스레드 성능만을 대상으로 한 마이크로벤치마크에서는 파트너 클러스터와 RA 클러스터 노드가 거의 동일한 성능을 보였습니다. 이를 통해 호스트에서 perf record -a -g로 30초간 캡처한 후 perf report로 확인했을 때, 예상치 못한 최상위 프레임이 발견되었습니다. CPU 사이클의 24%가 arm_smmu_cmdq_issue_cmdlist에 소비되고 있었습니다.
arm_smmu_cmdq_issue_cmdlist는 Arm SMMU의 커맨드 큐에 무효화 명령을 제출하는 함수입니다. 가상화 환경에서 map/unmap이 발생할 때마다 게스트의 무효화 요청이 호스트를 트랩하고 단일 커맨드 큐를 통해 직렬화되어, 프로파일에서 보이는 스핀락 경합이 발생합니다. Virtual Command Queue(VCMDQ)는 표준 Arm SMMUv3의 Command Queue Virtualization 확장을 통해 제공되는 기능으로, 게스트가 VM 탈출 없이 하드웨어에 직접 SMMU 무효화 명령을 발행할 수 있게 합니다.
수정 방법: 파트너 클러스터의 호스트 커널에서 CMDQV/VCMDQ를 활성화하고 게스트에 노출합니다. 이를 위해서는 tegra241-cmdqv 드라이버로 빌드된 커널과 그에 맞는 하이퍼바이저 지원이 필요합니다. 최신 QEMU/libvirt 버전에는 게스트에 이를 노출하기 위한 cmdqv IOMMU 속성이 추가되어 있습니다.
이 변경 이후, linux perf에서 arm_smmu_cmdq_issue_cmdlist가 최상위 프레임에서 사라지고 dTLB 미스율이 베어 메탈 수준으로 돌아왔습니다. MoE 반복 시간 격차도 12%에서 RA 허용 범위 이내로 좁혀졌습니다.
핵심 교훈은 Grace 기반 가상화 배포 환경에서 메모리 매핑이 집중된 워크로드를 처리하려면 VM 스택이 올바른 SMMU 기능을 노출해야 한다는 점입니다. 호스트 커널에서 CMDQV/VCMDQ가 활성화되고 게스트에 노출되면, 불필요한 SMMU 직렬화를 방지하여 MoE 학습 성능을 레퍼런스 아키텍처 허용 범위 이내로 복구할 수 있습니다.
다음 계층은 CPU 자체이며, 여기서는 전혀 다른 형태의 성능 이슈가 나타납니다.
사례 연구 2: CPU 경합 및 NUMA 바인딩 오류로 인해 12% 성능 저하가 발생한 H100 클러스터
계층: CPU 전력 및 프로세스 배치
NVIDIA의 HGX RA와 동일한 NCCL 버전 및 NeMo 컨테이너를 사용하는 파트너의 H100 SXM5 클러스터가 Llama 3 70B 사전 학습에서 레퍼런스 대비 12% 느린 성능을 보였습니다. GB200 NVL72 사례와 달리, 이번에는 커널 수준의 문제가 아니었습니다. 모든 것이 사용자 공간과 BIOS에서 발생했습니다.
두 가지가 눈에 띄었습니다:
- CPU 주파수: 학습 중
turbostat -i 1실행 결과, 해당 SKU가 3.8 GHz 터보로 규정되어 있음에도 불구하고 사용 중인 코어가 3.0 GHz에 고정되어 있었습니다. 유휴 코어도 C6로 내려가지 않고 C1에 머물며 3.0 GHz를 유지했습니다. - NUMA 원격 트래픽:
numastat -p를 실행하니 학습 프로세스의 메모리 접근 중 약 18%가 원격 NUMA 노드로 향하고 있었습니다.
근본 원인:
- 파트너 클러스터의 CPU는 BIOS에서 C-state가 C1로 제한되어 있었습니다. 이는 AI 학습 워크로드에 실질적으로 해가 되는 흔한 “저지연” 기본 설정입니다. 유휴 코어가 C1에 머물면서 패키지 전력을 계속 소비하므로, GPU에 커널을 공급하는 사용 중인 코어가 터보에 도달할 만큼 충분한 패키지 전력 예산을 확보할 수 없었습니다. 유휴 코어가 C6로 진입하도록 허용하자 전력 여유가 생겼고, 사용 중인 코어가 3.8 GHz까지 올라가 이 워크로드에서 약 4%를 회복했습니다.
- 하이퍼바이저 하우스키핑 스레드가 학습 프로세스의 데이터 로더 워커와 동일한 물리 코어에 고정되어 있었습니다. VM 내부에서는 이것이 파이썬 스레드의 산발적인 50~100ms 지연으로 나타났고, 이것이 스텝 시간의 긴 꼬리로 이어졌습니다. 수정 방법은
cpuset분리였습니다. 코어 0~7과 56~63은 하이퍼바이저 및 호스트 서비스용, 나머지는 학습 프로세스용으로 분리했습니다.
결과: 12%의 격차가 3%로 줄어들었으며, 남아 있는 차이는 다음 사례 연구에서 다룰 별도의 NCCL 튜닝 문제 때문인 것으로 확인되었습니다.
이 사례가 보여주는 패턴은 단 하나의 수정만으로 전체 성능 격차를 회복할 수는 없다는 점입니다. C-state 변경이 약 4% 개선을 끌어내며 가장 큰 요인으로 작용했고, 나머지는 NUMA 바인딩을 통한 프로세스 격리에서 비롯되었습니다. 이렇게 CPU와 가상화 문제를 해결하고 나면 다음 병목은 네트워크가 됩니다.
사례 연구 3: NVIDIA ConnectX-8 SuperNIC 기반 GB300 NVL72 환경의 1.6 Tbps 패브릭 성능 미달
핵심: ConnectX-8 SuperNIC 집합 통신 튜닝
노드당 1.6 Tbps 성능을 제공하는 NVIDIA ConnectX-8 SuperNIC 기반 GB300 NVL72 배포 환경에서 Nemotron-4 15B 사전 학습을 실행했을 때, NVIDIA 레퍼런스 대비 31%의 성능 격차가 나타났습니다. 단일 노드 처리량은 양호했으나 512개 GPU 규모에서 격차가 발생했으며, 프로파일러 확인 결과 AllGather와 ReduceScatter 시간이 노출되고 있었습니다. 이는 연산 능력이 아닌 ConnectX-8 패브릭의 집합 통신 경로에 문제가 있음을 보여주는 신호였습니다.
조사에서는 NCCL Tests(nccl-tests)를 사용하여 반복 횟수, UCX/UCC 동작, NUMA 매핑, NVLS, NCCL 버전 등 여러 변수를 테스트했습니다. 워크로드의 네트워킹 성능에 있어 유효한 튜닝 변경은 더 좁은 범위였습니다. NCCL_IB_QPS_PER_CONNECTION을 기본값인 1에서 4로 늘리는 것이었습니다.
낮은 QPS 값에서 통신 오버헤드가 노출되어 학습 반복 시간이 길어지는 것을 보여주는 Nsight Systems 트레이스
신호는 워크로드와 nccl-tests 집합 통신 측정 모두에서 확인되었습니다. NVIDIA 레퍼런스 클러스터에서 기본 구성은 반복당 약 1.09초로 실행되었습니다. QPS=4를 적용하자 동일한 레퍼런스 워크로드가 약 0.83초로 개선되었습니다. 프로파일에서 AllGather 시간은 약 375ms에서 262ms로, ReduceScatter는 약 389ms에서 273ms로 감소했습니다. 비교 실행은 약 0.76초였으며 다른 NCCL 버전을 사용했습니다. 따라서 잔여 차이는 부분적으로 비교 환경과 레퍼런스 환경 간의 NCCL 버전 불일치에 기인했으며, 버전을 맞추자 잔여 격차가 더욱 좁혀졌습니다. NCCL 버전 변경은 일반적인 Exemplar 튜닝 범위를 벗어나므로, 권장 튜닝은 배포된 NCCL 버전을 유지하는 방향입니다.
교훈: QPS를 모든 환경에 무조건 높여 적용하지 마세요. 최적의 QPS는 패브릭 구성과 워크로드 특성에 따라 달라집니다. 본 GB300 ConnectX-8 워크로드에서는 QPS=4 설정이 대규모 메시지의 AllGather 및 ReduceScatter 처리 성능을 향상시켰으나, 패브릭 환경이나 메시지 크기 프로파일이 다를 경우 동일한 설정이 학습 처리량 개선 없이 CPU 오버헤드만 가중시킬 수 있습니다. 올바른 접근 방식은 워크로드의 실제 메시지 크기 기반으로 집합 통신을 테스트하고, 대상 패브릭에서 설정값 스윕(sweep)을 진행한 뒤, 실제 학습 워크로드에서 그 결과를 검증하는 것입니다.
사례 연구 4: 전달되지 않은 환경 변수
가상화된 B200 배포 환경에서, 호스트에서 실행한 nccl-tests 결과가 정상 성능을 보였음에도 불구하고 학습 처리량은 NVIDIA 레퍼런스 대비 13%~53% 낮게 나왔습니다. enroot 워크로드 컨테이너 내부에서 AllGather 및 ReduceScatter 동작이 2~4배 느려지면서, 원인 분석의 방향이 패브릭 상태 확인에서 VM 및 학습 작업 내부에서 조회되는 NCCL 토폴로지 구성의 직접적인 비교로 전환되었습니다.
호스트 (VM) 컨테이너 (enroot)
───────── ─────────
NCCL_TOPO_FILE=/etc/nccl/topo.xml → NCCL_TOPO_FILE (전파되지 않음)
/etc/nccl/topo.xml 존재 → /etc/nccl/topo.xml (마운트되지 않음)
↓
NCCL이 자동 감지로 폴백
→ 레퍼런스 대비 13~53% 낮음| 플랫폼 | B200, 가상화 스택 |
|---|---|
| 증상 | 레퍼런스 대비 13~53% 낮음; AllGather/ReduceScatter 2~4배 느림; 호스트의 NCCL tests는 정상 통과 |
| 근본 원인 | VM에는 NCCL_TOPO_FILE이 설정되어 있었지만, 변수도 토폴로지 파일도 enroot 컨테이너에 마운트되지 않음 |
| 수정 | –mount type=bind,source=/etc/nccl/topo.xml,target=/etc/nccl/topo.xml |
핵심 교훈: 벤치마크를 실행할 환경과 동일한 컨테이너, 런치 스크립트, Slurm 할당 영역 내부에서 직접 점검을 진행하세요. 호스트가 아닌 작업 컨테이너 내부에서 echo $NCCL_TOPO_FILE && cat $NCCL_TOPO_FILE 명령어를 실행해 보는 것이 가장 확실한 확인법입니다. 지정된 경로를 찾지 못하더라도 NCCL은 아무 메시지 없이 넘어가기 때문에, 어디를 봐야 할지 모르면 원인을 찾아내기가 매우 어렵습니다.
수정 사항 요약
| 사례 | 플랫폼 | 계층 | 진단 신호 | 수정 | 회복량 |
|---|---|---|---|---|---|
| 1 | GB200 NVL72 (VM) | SMMU | perf에서 arm_smmu_cmdq_issue_cmdlist 지배적; dTLB 미스 수배 증가 | VMDQV 활성화 | ~12% |
| 2 | H100 (VM) | CPU + NUMA | 코어 3.0 GHz에 고착; 이중 분포 스텝 시간; NUMA 원격 18% | C-state 튜닝, cpuset 격리, numactl 바인딩, SMT/마이그레이션 비활성화 | 9% (12→3) |
| 3 | GB300 NVL72 | NCCL 동시성 | AllGather busbw 약 28 GB/s (QPS=4 시 약 61 GB/s) | NCCL_IB_QPS_PER_CONNECTION을 CX8용으로 1에서 4로 업데이트 | 반복 시간 31% |
| 4 | B200 (VM) | 런타임 가시적 토폴로지 | 호스트 NCCL 토폴로지는 올바르나, enroot 컨테이너 내부에서 NCCL_TOPO_FILE 미전파 및 /etc/nccl/topo.xml 미마운트; AllGather/ReduceScatter 2~4배 느림 | 토폴로지 파일을 컨테이너에 바인드 마운트하고 작업 컨테이너 내부에서 NCCL_TOPO_FILE 확인 | 레퍼런스 대비 13~53% 격차 해소 |
풀스케일 학습 디버깅 전 사전 점검 목록
클러스터 성능이 NVIDIA 레퍼런스 아키텍처 규격에 미치지 못할 때, 풀스케일 워크로드 튜닝에 들어가기에 앞서 다음 점검 항목들을 통해 흔히 발생하는 플랫폼 문제를 미리 배제할 수 있습니다.
| 영역 | 점검 항목 | 유용한 도구 |
|---|---|---|
| GPU 및 하드웨어 상태 | 지속 부하 하에서 클럭, 전력, 열, NVLink 대역폭 일관성 | nvidia-smi, DCGM, dcgm-exporter |
| Grace 및 VM 준비 상태 | CMDQV 지원, 게스트 페이지 크기, IOMMU 패스스루 동작, 대용량 페이지 가용성 | perf, dmesg, 커널 구성, 부트 파라미터 |
| CPU 전력 및 배치 | 사용 코어 터보, cpuset 격리, GPU 인접 NUMA/PCT 바인딩 | turbostat, lscpu, numactl, nvidia-smi topo -m |
| 런타임 토폴로지 | 작업 컨테이너 내부의 토폴로지 파일, NCCL 환경 변수, HCA 가시성 | env, cat $NCCL_TOPO_FILE, NCCL_DEBUG=INFO |
| 패브릭 집합 통신 | 워크로드 메시지 크기에서의 AllGather 및 ReduceScatter 동작 | nccl-tests, 워크로드 트레이스 |
| 워크로드 튜닝 | 파이프라인 병렬성, 마이크로배치 크기 조정, 통신 오버랩 — 플랫폼 문제 해결 이후에만 | Nsight Systems, 워크로드 로그 |
조기 디버깅으로 시착 줄이기
클라우드 학습 배포 환경과 NVIDIA 레퍼런스 아키텍처 간의 성능 격차는 여러 레이어의 손실이 누적되어 발생하는 경우가 많습니다. CPU 전력 설정에서 수 퍼센트, NUMA나 PCT 바인딩의 추가 손실, 누락된 커널 기능, 컨테이너에 노출되는 토폴로지 구성, 패브릭 설정 문제 등이 복합적으로 작용하기 때문입니다. 정식 검증에 앞서 이러한 항목들을 미리 점검하지 않으면, 향후 대규모 환경에서 훨씬 번거롭고 소모적인 디버깅을 거쳐야 합니다.
다만 사전 점검을 모두 마쳤다고 해서 Exemplar Cloud 인증 통과가 무조건 보장되는 것은 아닙니다. 일부 문제는 실제 모델과 정밀도, 토폴로지, 컨테이너, 런치 스크립트, 네트워크 조건이 완벽히 결합된 실제 검증 워크로드를 돌려봐야만 비로소 드러나기 때문입니다. 결국 실무에서의 핵심은 알려진 플랫폼 리스크를 미리 제거한 뒤, 대규모 환경에서만 발생하는 성능 격차를 학습 워크로드 트레이스 데이터로 하나씩 다듬어 나가는 데 있습니다.
참고자료 및 관련 링크
- GTC 세션 (VOD): S81845 — Drive Optimal Tokens per Watt on any AI Infrastructure Using Benchmarking Recipes
- NVIDIA Grace CPU 튜닝 가이드: NVIDIA Grace CPU Performance Tuning Guide
- NCCL 환경 변수 설정: NCCL Environment Variables (NCCL_IB_QPS_PER_CONNECTION, NCCL_IB_SPLIT_DATA_ON_QPS, NCCL_IB_HCA, NCCL_DEBUG 등)
- NVIDIA NeMo 프레임워크: NGC Container Registry (Llama 3, DeepSeek, Nemotron 최적화 컨테이너)
- NVIDIA Performance Explorer: NVIDIA Performance Explorer – TCO Calculator
- NVIDIA 벤치마킹 레시피: NVIDIA Performance Benchmarking Recipes
