NVIDIA NeMo AutoModel 글에서 가장 눈에 띄는 부분은 성능 숫자보다 접근 방식이다. Hugging Face Transformers의 from_pretrained() 경험은 크게 건드리지 않으면서, MoE 학습에 필요한 Expert Parallelism, DeepEP fused all-to-all dispatch, TransformerEngine kernel을 아래쪽에 붙인다. 개발자가 보는 표면은 익숙한 AutoModel 계열인데, 실제 실행 경로는 훨씬 더 분산 학습에 맞춰진다.
30B급 벤치마크는 차이를 꽤 선명하게 보여준다. Qwen3-30B-A3B를 8x H100 단일 노드에서 돌렸을 때 Transformers v5는 3,075 TPS/GPU, NeMo AutoModel은 11,340 TPS/GPU를 기록했다. peak memory도 68.2GiB에서 48.1GiB로 줄었다. Nemotron 3 Nano 30B A3B에서는 v5 4,583 TPS/GPU에서 AutoModel 15,421 TPS/GPU로 올라간다. 숫자만 보면 단순 최적화처럼 보이지만, 실제로는 expert dispatch와 sharding 구조의 차이다.
더 큰 모델에서는 성능 비교보다 실행 가능성이 먼저 온다. Nemotron 3 Ultra 550B A55B full fine-tune은 16개 H100 노드, 128 GPU, EP=64 조건에서 실행된다. Transformers v5는 이 스케일에서 메모리가 부족해 비교 결과가 없다. AutoModel이 experts를 GPU 전체에 나눠 담는 구조가 아니면 full fine-tune 자체가 어려운 영역이다.
다만 벤치마크를 읽을 때는 조건도 같이 봐야 한다. 30B 결과의 NeMo AutoModel 수치는 balanced routing gate를 사용한다. dummy token 분포 때문에 특정 expert에 부하가 몰리는 노이즈를 줄이고, MoE가 학습을 통해 도달하려는 균형 상태에 가까운 조건을 만든 것이다. 실제 데이터와 router 상태에 따라 체감 성능은 달라질 수 있다.
그래도 이 글이 던지는 메시지는 실용적이다. MoE 시대의 fine-tuning 성능은 모델 파일을 읽는 API보다, experts를 어떻게 배치하고 통신을 얼마나 겹치며 커널을 어떻게 fused하느냐에서 갈린다. NeMo AutoModel은 HF checkpoint 호환성과 save_pretrained() 흐름을 유지하면서 그 실행 레이어를 교체하려는 시도다. 그래서 플러그인처럼 보이지만, 실제로는 MoE 학습 런타임의 설계 문제에 더 가깝다.