파운데이션 모델 훈련에서 가장 흔한 오해는 GPU의 피크 FLOPS를 곧 훈련 속도로 등치시키는 것이다. AWS가 Hugging Face에 공개한 레퍼런스 아키텍처는 이 직관에 정면으로 반박하며 시작한다. 실제로 스텝 타임을 지배하는 건 Tensor Core 처리량이 아니라 노드 내외 집단통신과 메모리 이동이다. 이를 이해하면 왜 B200 인스턴스(p6-b200.48xlarge)의 설계가 BF16 피크 FLOPS 숫자보다 NVLink 5세대 14.4 TB/s와 EFAv4 기반 집단통신 개선에 더 초점을 맞추고 있는지 납득된다.
배경에는 스케일링 법칙의 분기가 있다. Kaplan 등(2020)의 멱법칙 트렌드는 대규모 사전학습 투자를 수십 년간 정당화했다. 그러나 현재 프론티어는 사전학습 외에 사후학습(SFT, RL 기반 방법론)과 테스트타임 컴퓨트(긴 추론, 검색/검증, 멀티샘플 전략)까지 세 구간으로 분기됐다. NVIDIA가 '세 개의 스케일링 법칙'으로 명명한 이 프레임이 포스트의 출발점이다. 흥미로운 역설은 이 세 구간이 각자 다른 스케일링 곡선을 따르면서도 인프라 요구사항으로는 동일하게 수렴한다는 것이다: 타이트하게 결합된 가속기, 고대역폭 저지연 네트워크, 분산 스토리지 백엔드.
AWS의 인스턴스 계보를 보면 이 설계 철학이 명확하다. P5 계열(H100, NVLink 4세대, 7.2 TB/s)에서 P6 계열(B200/B300, NVLink 5세대, 14.4 TB/s)로의 전환에서 노드 내 대역폭이 정확히 2배 증가했다. 노드 간 통신을 담당하는 EFA도 세대를 거치며 진화했다. EFAv3는 패킷 지연을 EFAv2 대비 35% 낮췄고, EFAv4는 집단통신 성능을 EFAv3 대비 18% 추가 개선했다. SRD 프로토콜 기반 OS-bypass RDMA 설계 덕분에 all-reduce 같은 collective 연산이 호스트 네트워킹 스택을 거치지 않는다. B300의 HBM3e 288GB는 H100(80GB) 대비 3.6배로, 이 규모에서는 멀티 테라바이트 체크포인트 저장·로드가 훈련 루프의 독립적 병목으로 부상한다. 컴퓨트 스펙을 논할 때 스토리지 설계를 빠뜨리면 안 되는 이유다.
소프트웨어 스택은 4계층으로 정리된다: 인프라(컴퓨트·네트워크·스토리지) → 리소스 오케스트레이션(Slurm/Kubernetes) → ML 소프트웨어(PyTorch/JAX) → 관측성(Prometheus+Grafana). 관측성 레이어가 인프라부터 ML 프레임워크까지 전 계층을 횡단하도록 설계된 것이 이 아키텍처의 특징이다. 대규모 클러스터에서 성능 병목이 어느 계층에서 발생했는지 격리해 진단하는 능력이 운용의 핵심이기 때문이다. 이 포스트는 시리즈의 인트로로, 이후 편에서 각 레이어와 AWS 인프라 컴포넌트 간 구체적인 통합 포인트를 상세히 분해한다.