왜 이 결과가 그냥 '또 NVIDIA 1등' 뉴스가 아닌가
솔직히 MLPerf 결과만 보면 매번 NVIDIA가 1등이라 뉴스 가치가 떨어져 보일 수 있어요. 그런데 이번 MLPerf Training v6.0은 결이 좀 달라요. MLCommons가 새로운 프리트레이닝 워크로드 두 개를 처음으로 추가했거든요.
- DeepSeek-V3 671B (MoE) — 671B 파라미터 규모의 거대 MoE 모델이자, 화제의 DeepSeek-R1 추론 모델의 베이스
- GPT-OSS-20B — 작지만 실속 있는 MoE 모델
문제는 이 두 워크로드가 기존 dense 모델과 완전히 다른 학습 패턴을 요구한다는 점이에요. 토큰이 전문가(expert)로 동적으로 라우팅되기 때문에 통신 패턴이 불규칙하고, CPU-GPU 동기화가 자주 끼어들어 학습 효율을 갉아먹거든요. NVIDIA는 이 두 벤치마크에 유일하게 결과를 제출했고, 동시에 전 부문 1위를 차지했어요. 즉, 경쟁사들이 아직 최적화를 못 끝낸 영역에서 이미 '실측 성능'을 내놨다는 뜻이에요.
근거자료: NVIDIA Developer Blog - MLPerf Training 6.0
숫자로 보는 성적표: GB300 NVL72가 찍은 기록
먼저 이번 라운드의 핵심 결과를 표로 정리해볼게요. 시간 단위에 주목해 주세요. '분(min)'이지 '시간'이 아니에요.
| 워크로드 | GPU 플랫폼 | 클러스터 규모 | 학습 시간 |
|---|---|---|---|
| DeepSeek-V3 671B (MoE) | GB300 NVL72 | 8,192 GPUs | 2.02분 |
| GPT-OSS 20B (MoE) | GB300 NVL72 | 512 GPUs | 7.43분 |
| Llama 3.1 405B | GB200 NVL72 | 8,192 GPUs | 7.07분 |
| Llama 3.1 8B | GB200 NVL72 | 1,024 GPUs | 4.46분 |
| Llama 2 70B LoRA | GB300 NVL72 | 512 GPUs | 0.4분 |
| FLUX.1 | GB300 NVL72 | 512 GPUs | 17.1분 |
| DLRM-dcnv2 | GB300 NVL72 | 64 GPUs | 0.67분 |
DeepSeek-V3 671B가 8,192개 GPU로 2분 만에 학습됐다는 건, 개별 GPU가 아니라 클러스터 전체가 하나의 '컴퓨터'처럼 스케일링됐다는 뜻이에요. 이게 가능하려면 네트워크 패브릭, 통신 오버랩, 파이프라인 밸런싱이 모두 맞아떨어져야 해요. 하나라도 어긋나면 병목이 생겨서 시간이 몇 배로 늘어나거든요.
특히 MoE의 expert parallelism은 low-entropy, bursty flow를 만들어요. 쉽게 말해 특정 전문가로 트래픽이 몰리면서 링크 충돌이 발생하고, 기존 ECMP 해싱으로는 유효 대역폭이 뚝 떨어져요. NVIDIA는 Spectrum-X Ethernet의 Advanced Adaptive Routing으로 패킷 단위로 실시간 로드에 따라 경로를 분산시켜서, 패브릭 이론 대역폭에 가까운 성능을 유지했어요. 수신 측 ConnectX SuperNIC이 out-of-order 전달을 처리해 주는 구조예요.
추가로 특정 expert에 여러 sender가 동시에 몰리는 incast 상황에서는 Spectrum-X Congestion Control이 실시간 텔레메트리로 조기에 감지하고 sender를 미리 pacing해요. 그래서 all-to-all 통신이 compute 뒤에 숨겨지고, tail latency가 튀지 않아요.
진짜 무서운 건 소프트웨어: 6가지 최적화 뜯어보기
벤치마크 숫자는 결과일 뿐이고, 이번 라운드의 진짜 승부는 소프트웨어 스택에서 났어요. 개발자 관점에서 실제로 참고할 만한 6가지를 정리했어요.
1. Token-dropless MoE를 위한 Full-iteration CUDA Graphs
기존에는 MoE의 동적 라우팅 때문에 CPU-GPU 동기화가 계속 끼어들어서 CUDA Graph로 전체 iteration을 감싸는 게 불가능했어요. NVIDIA는 expert 연산자(quantizer, grouped GEMM, token dispatcher)를 동기화 없는 모드로 전환하고, 입력 shape을 GPU 값에서 직접 도출하도록 바꿨어요. 디바이스 메모리는 paged stashing으로 호스트 개입 없이 관리했고요. 결과적으로 2,000개 이상 GPU 클러스터에서 CPU가 critical path에서 완전히 빠졌어요.
2. CuTe DSL과 커널 퓨전
메모리 대역폭 바운드 레이어와 grouped GEMM을 퓨전하려면 하드웨어 레벨에서 수학 연산과 메모리 처리를 결합해야 해요. CuTe DSL로 레지스터 로컬리티를 유지하면서 global memory 왕복을 줄였어요. DeepSeek-V3에서 8% 이상, GPT-OSS에서 93% E2E 스피드업이 나왔어요.
3. MXFP8 Attention Block
기존 MoE 학습은 attention에 16-bit 정밀도를 썼는데, 이번엔 MXFP8 attention 레시피를 개발했어요. batched matmul 입력 텐서를 8-bit로 유지해 FP8 연산 이점을 살리면서도 모델 품질은 유지했어요. cuDNN의 Transformer Engine 라이브러리를 통해 사용 가능해요.
4. Router 및 Hybrid EP 최적화
MoE router의 elementwise 커널들을 퓨전하고, FP64 → FP32로 전환해서 커널 속도 5배를 뽑았어요. HybridEP 내부의 메타데이터 처리 커널도 퓨전하고 permute/unpermute 커널을 튜닝해서 E2E 5% 이득을 봤어요.
5. 1F1B All-to-All Overlap
Megatron-Core에 있던 1F1B A2A 오버랩 스킴을 CUDA Graph로 감싸서 호스트 오버헤드를 제거했어요. 통신 스트림 우선순위 조정, 동적 CuTe DSL 커널, delayed wgrad 지원까지 더해서 **A2A 통신 오버랩이 거의 100%**에 도달, 8% 성능 이득을 얻었어요.
6. 파이프라인 스테이지 불균형 최소화
커널이 빨라질수록 파이프라인 병렬 스테이지 간 불균형이 도드라져요. DeepSeek-V3의 하이브리드 레이어 구성(앞 3개 dense + 뒤 MTP/logits GEMM)을 Megatron-Core의 flexible pipeline layout으로 재배치하고, logit projection GEMM에 MXFP8을 적용해서 파이프라인 불균형 1% 미만, E2E 4% 절감을 달성했어요.
실무 적용 관점에서 중요한 포인트
이 최적화들은 대부분 NVIDIA 내부 커널 작업이지만, Megatron Bridge가 이 모든 개선을 패키징해서 개발자에게 바로 제공해요. 최신 NeMo 컨테이너 26.06 기준으로 GB300에서 DeepSeek-V3 학습 성능이 3개월 만에 1,298 → 1,648 TFLOPS/GPU (6,338 tokens/sec/GPU) 로 1.3배 올랐어요. 실리콘은 그대로인데 소프트웨어만으로 이만큼 뽑았다는 게 핵심이에요.
MoE 구조 자체에 대한 이해가 부족하다면, Mixture of Experts (MoE) 완벽 해부 글을 먼저 읽고 오시면 이번 최적화들이 왜 필요한지 훨씬 잘 보여요.
한국 개발 생태계에서 이 뉴스를 어떻게 받아들여야 할까
솔직히 말하면, 국내에서 8,192개 GPU 클러스터를 직접 굴리는 팀은 극소수예요. 그래서 이 뉴스를 '남의 나라 이야기'로 넘기기 쉬운데, 사실 챙겨야 할 포인트는 따로 있어요.
첫째, 소프트웨어 최적화의 ROI가 하드웨어 교체보다 크다는 신호예요. 실리콘은 그대로인데 3개월 만에 1.3배 성능 향상이 나왔다는 건, 여러분이 쓰는 추론/학습 스택도 버전업만으로 상당한 이득을 볼 수 있다는 뜻이에요. 특히 vLLM, TensorRT-LLM, Megatron-LM 같은 스택의 릴리즈 노트를 무시하지 마세요.
둘째, 국내 SI 환경에서는 네트워크 패브릭이 여전히 병목이에요. Spectrum-X나 Quantum InfiniBand 없이 일반 Ethernet으로 MoE 학습을 돌리면 expert parallelism에서 대역폭이 급락해요. 클라우드 벤더 선택 시 네트워크 토폴로지를 반드시 확인해야 해요.
셋째, 이 기술의 한계도 분명해요. 이번 결과는 closed division 기준이고, NVIDIA 자체 스택에 극도로 최적화된 수치예요. 오픈소스 프레임워크(PyTorch vanilla)나 다른 하드웨어에서 동일 성능을 기대하면 안 돼요. 그리고 MoE 최적화는 모델 구조에 강하게 결합되어 있어서, 새로운 라우팅 방식이 나오면 또 다시 튜닝이 필요해요.
다음 단계 학습 방향: MoE 학습을 직접 다룬다면 Megatron-Core의 pipeline layout 문서와 Transformer Engine의 FP8 레시피를 먼저 보시고, 그다음에 CUDA Graph 캡처가 MoE에서 왜 어려운지 이해하는 순서가 좋아요.
데이터 주권이나 규제 환경 때문에 폐쇄망에서 AI를 돌려야 하는 팀이라면, 클라우드 연결이 끊겨도 안전하게 AI를 구동하는 법 글도 함께 보시면 인프라 전략 세우는 데 도움이 될 거예요.
결론적으로 이번 MLPerf 6.0은 'NVIDIA가 또 이겼다'가 아니라, 풀스택 공동 설계(full-stack co-design)가 AI 학습의 실질적 병목을 어떻게 제거하는지 보여주는 사례예요. 여러분의 파이프라인에서도 병목이 하드웨어가 아니라 소프트웨어 스택 어딘가에 숨어 있을 가능성이 커요.