AWS에서의 Foundation Model 학습 및 추론을 위한 빌딩 블록 (Building Blocks)

모델 파라미터 (model parameters),

데이터셋 크기 (dataset size),

및

학습 컴퓨팅 (training compute). 실제로 이러한 트렌드는 대규모 가속기 용량과 이를 효율적으로 활용하는 데 필요한 주변 분산 인프라에 대한 지속적인 투자를 정당화했습니다. 하지만 프런티어(frontier)는 진화했으며, 스케일링(scaling)은 더 이상 단일 곡선이 아닙니다. NVIDIA의 "1에서 3으로의 스케일링 법칙 (from one to three scaling laws)" 프레임워크는 사전 학습(pre-training)을 넘어, 성능이 다음과 같은 방식을 통해 점점 더 확장된다는 점을 유용하게 강조합니다.

사후 학습 (post-training) (예: 지도 미세 조정 (SFT) 및 강화학습 (RL) 기반 방법) 및

테스트 시간 컴퓨팅 (test-time compute) ("긴 사고 (long thinking)", 검색/검증, 다중 샘플 전략).

그림: "AI의 세 가지 스케일링 법칙 설명 (AI's Three Scaling Laws, Explained)"에서 인용 (NVIDIA Blog).

종합하면, 이러한 스케일링 체제는 파운데이션 모델(foundation-model)의 라이프사이클인 사전 학습(pre-training), 사후 학습(post-training), 그리고 추론(inference)을 수렴하는 인프라 요구 사항으로 몰아넣습니다: 밀접하게 결합된 가속기 컴퓨팅, 고대역폭 저지연 네트워크, 그리고 분산 스토리지 백엔드입니다. 또한 이는 리소스 관리를 위한 오케스트레이션(orchestration)의 중요성과, 클러스터의 상태를 유지하고 대규모 환경에서 성능 병리 현상을 진단하기 위한 애플리케이션 및 하드웨어 수준의 관측 가능성(observability)의 중요성을 높입니다.

또 다른 주요 트렌드는 파운데이션 모델 (foundation-model) 라이프사이클이 모델 개발 프레임워크 (frameworks), 클러스터 리소스 관리 (cluster resource management), 그리고 운영 도구 (operational tooling)를 아우르는 오픈 소스 소프트웨어 (OSS) 생태계에 대한 의존도가 높아지고 있다는 점입니다. 클러스터 계층 (cluster layer)에서는 일반적으로 Slurm 및 Kubernetes와 같은 시스템에 의해 리소스 관리가 제공됩니다. 모델 개발 및 분산 학습 (distributed training)은 흔히 PyTorch 및 JAX와 같은 프레임워크에서 구현됩니다. 모니터링 및 시각화, 즉 관측 가능성 (observability)은 인프라 및 리소스 관리 상단의 운영 계층 (operational layer)으로서, 메트릭 수집을 위한 Prometheus와 시각화 및 알림을 위한 Grafana를 사용하여 달성되는 경우가 많습니다. 그림 1은 이러한 계층형 아키텍처 (layered architecture)를 보여주며, 하드웨어 인프라가 리소스 오케스트레이션 (resource orchestration)을 지원하고, 이것이 다시 ML 프레임워크를 가능하게 하며, 관측 가능성이 모든 계층에 걸쳐 적용되는 방식을 나타냅니다.

그림 1: 파운데이션 모델 학습 및 추론을 위한 오픈 소스 소프트웨어 스택의 계층형 아키텍처

이 포스트는 파운데이션 모델 학습 및 추론에 참여하며, 특히 OSS 프레임워크를 기반으로 구축된 워크플로우에 관심을 가진 머신러닝 엔지니어 및 연구자를 대상으로 합니다. 본 글은 멀티 노드 가속기 컴퓨팅 (multi-node accelerator compute), 고대역폭 저지연 네트워킹 (high-bandwidth low-latency networking), 분산 공유 스토리지 (distributed shared storage) 및 관련 관리형 서비스 (managed services)를 포함하는 AWS 인프라가 파운데이션 모델 라이프사이클 전반에 걸쳐 일반적인 OSS 스택과 어떻게 상호작용하는지 분석합니다. 주요 목표는 사전 학습 (pre-training), 사후 학습 (post-training) 및 추론 (inference)에 걸친 시스템 병목 현상 (bottlenecks)과 확장 특성 (scaling characteristics)을 이해하기 위한 기술적 토대를 제공하는 것입니다. 이 입문용 포스트는 전체 시스템 아키텍처를 드러내며, 대규모 분산 학습 및 추론을 뒷받침하는 AWS 인프라 구성 요소와 OSS 도구 간의 통합 지점 (integration points)을 강조합니다.

이 시리즈의 나머지 부분에서는 이러한 계층적 아키텍처 (layered architecture)가 AWS에서 어떻게 구현되는지 인프라 (infrastructure), 리소스 오케스트레이션 (resource orchestration), ML 소프트웨어 스택 (ML software stack), 그리고 관측성 (observability) 순으로 살펴봅니다. 다음 섹션에서는 각 계층에 대한 개요를 제공합니다.

그림 1에서 설명된 바와 같이, 인프라는 세 가지 결합된 빌딩 블록 (building blocks)을 중심으로 구성됩니다. 즉, 대용량 디바이스 메모리를 갖춘 가속 컴퓨팅 (accelerated compute), 집합 통신 (collective communication)을 위한 광대역 인터커넥트 (wide-bandwidth interconnect), 그리고 데이터 및 체크포인트 (checkpoints)를 위한 확장 가능한 분산 스토리지 (scalable distributed storage)입니다.

가속 컴퓨팅 (accelerated compute)은 대규모 파운데이션 모델 (foundation model)의 사전 학습 (pre-training), 사후 학습 (post-training) 및 추론 (inference)의 토대를 형성합니다. AWS는 Amazon EC2 가속 컴퓨팅 인스턴스의 일부로 Amazon EC2 P 인스턴스 패밀리를 포함하여 여러 세대의 NVIDIA GPU를 제공합니다. P5 인스턴스 패밀리에는 8개의 NVIDIA H100 GPU를 탑재한 p5.48xlarge, 소규모 워크로드를 위한 단일 H100 GPU 탑재 p5.4xlarge, 그리고 NVIDIA H200 GPU를 탑재한 p5e.48xlarge/p5en.48xlarge 변형 모델이 포함됩니다. P6 인스턴스 패밀리는 p6-b200.48xlarge를 통한 NVIDIA Blackwell B200 아키텍처와 p6-b300.48xlarge를 통한 Blackwell Ultra B300을 도입합니다. 이러한 세대 전반에 걸쳐 주요 스케일링 축 (scaling axes)은 피크 텐서 처리량 (peak Tensor throughput), HBM 용량 및 대역폭, 그리고 인터커넥트 대역폭 (노드 내부 및 노드 간)입니다.

1차 근사치로서, 초당 부동 소수점 연산 수 (FLOPS)로 측정되는 피크 텐서 코어 처리량 (peak Tensor Core throughput)은 이러한 가속기들을 공통된 축 위에 배치하는 데 도움이 됩니다. 아래 표는 NVSwitch/NVLink 기반의 멀티 GPU 노드와 일치하는 SXM/HGX급 사양을 사용하여, 밀집(dense) BF16/FP16 및 FP8 텐서 연산에 대한 GPU당 피크 처리량과 HBM 용량 및 HBM 대역폭을 요약한 것입니다.

GPU (대표 변형)	BF16/FP16 텐서 피크 (밀집)	FP8 텐서 피크 (밀집)	FP4 텐서 피크 (밀집)	HBM 용량	HBM 대역폭
H100 (SXM)	0.9895 PFLOPS	1.979 PFLOPS	—	80 GB HBM3	3.35 TB/s
...
*참고: NVIDIA 제품 표에는 텐서 처리량이 "희소성 (sparsity)"을 포함하여 보고되는 경우가 많으나, 이 표는 밀집 (dense) 처리량을 보고합니다. 해당되는 경우, NVIDIA의 HGX급 플랫폼 가이드라인(NVIDIA)에 따라 밀집 처리량은 희소 처리량의 절반으로 계산되었습니다. DGX 수치는 시스템 레벨 기준입니다. B200 HBM 용량 및 대역폭 값은 DGX 총합을 8로 나누어 GPU당 값으로 표현되었습니다 (NVIDIA).

모델의 규모가 커짐에 따라, 단계 시간 (step time)은 순수 연산 처리량보다는 집합 통신 (collective communication) 및 메모리 이동에 의해 지배되는 경우가 많으며, 이는 명시적인 스케일업 (scale-up) 및 스케일아웃 (scale-out) 대역폭 산정의 동기가 됩니다.
멀티 GPU 인스턴스의 경우, GPU 통신은 두 가지 영역에 걸쳐 있습니다. **내부 스케일업 (NVLink/NVSwitch)**은 노드 내에서 고대역폭, 저지연 GPU 간 연결을 제공하여, all-reduce 및 all-gather와 같은 집합 연산이 호스트 네트워킹 스택을 거치지 않고 실행될 수 있도록 합니다. **외부 스케일아웃 (EFA)**은 노드 간 OS-bypass 네트워킹을 제공하며, AWS는 이를 통신 집약적인 집합 연산이 수천 개의 인스턴스에 걸쳐 발생하는 Amazon EC2 UltraClusters의 빌딩 블록 (building block)으로 사용합니다. 다음 표는 이러한 인스턴스 유형별 주요 사양을 요약한 것입니다:

인스턴스 유형 (Instance Type)	GPU	GPU 개수	GPU 메모리	NVLink	NVLink 대역폭 (합계)	EFA	EFA 대역폭 (합계)
p5.4xlarge	H100	1	80 GB HBM3	—	—	v2	12.5 GB/s
...
참고: EFA 대역폭은 다른 대역폭 지표와의 일관성을 위해 Gbps에서 GB/s로 변환되었습니다 (÷8). 자세한 내용은 EC2 가속 컴퓨팅 네트워킹 사양을 참조하십시오. NVLink 및 EFA 대역폭 수치는 링크당 값이 아닌 인스턴스당 합계 값으로 표시됩니다. 해당 노드 내 상호 연결(intra-node interconnect) 및 네트워킹 특성에 대해서는 P5 인스턴스 제품군 페이지 및 P6 인스턴스 제품군 페이지를 참조하십시오.

Elastic Fabric Adapter (EFA)는 Scalable Reliable Datagram (SRD) 프로토콜을 사용하여 OS-bypass 원격 직접 메모리 액세스 (RDMA, Remote Direct Memory Access) 기능을 제공하는 Amazon EC2용 네트워크 인터페이스입니다. EFA는 애플리케이션이 Libfabric API를 통해 운영 체제 커널을 우회하여 네트워크 장치와 직접 통신할 수 있게 함으로써, 분산 학습 (distributed training) 시 집합 연산 (collective operations)의 지연 시간 (latency)을 줄이고 처리량 (throughput)을 향상시킵니다.

다양한 인스턴스 제품군에서 여러 세대의 EFA를 사용할 수 있습니다. Amazon EC2 P5 및 P5e 인스턴스에는 EFA 버전 2 (EFAv2)가 탑재되어 있습니다. P5en 인스턴스에서 제공되는 EFA 버전 3 (EFAv3)는 EFAv2와 비교하여 패킷 지연 시간을 약 35% 감소시킵니다. P6 인스턴스에서 사용할 수 있는 EFA 버전 4 (EFAv4)는 EFAv3 대비 집합 통신 (collective communication) 성능을 추가로 18% 향상시킵니다.

대규모 환경에서는 분산 학습 (코퍼스 스트리밍 및 멀티 테라바이트 체크포인트 쓰기)과 대규모 추론 (가중치 스테이징 및 KV 캐시 성장 관리) 모두 계층화된 스토리지 계층 구조를 필요로 합니다. 즉, 핫 데이터 (hot data)를 위한 로컬 NVMe SSD, 공유 고대역폭 액세스를 위한 Lustre, 그리고 내구성이 있는 영구 저장을 위한 Amazon S3가 사용됩니다.

본 시리즈의 주요 멀티 GPU 인스턴스에서는 로컬 NVMe가 **30.72 TB 원시 용량 (8 × 3.84 TB NVMe SSD)**을 갖춘 **인스턴스 스토어 (instance store, 휘발성)**로 제공됩니다. 자세한 내용은 EC2 가속 컴퓨팅 인스턴스 스토어 사양을 참조하십시오.

Lustre는 오픈 소스이며 POSIX를 준수하는 분산 파일 시스템 (distributed file system)으로, 고성능 컴퓨팅 (HPC)에서 많은 클라이언트 전반에 걸쳐 높은 집계 처리량 (aggregate throughput)을 가진 공유 네임스페이스 (shared namespace)를 제공하기 위해 널리 사용됩니다. Amazon FSx for Lustre는 Lustre를 완전 관리형 서비스 (fully managed service)로 제공하며, 초당 테라바이트 단위의 처리량, 수백만 IOPS, 그리고 밀리초 미만의 지연 시간 (sub-millisecond latencies)을 구현할 수 있는 병렬 파일 시스템 (parallel file system)으로 노출합니다. 데이터 저장소 연결 (Data Repository Associations)을 통해 Amazon S3와의 통합을 지원하며, 학습 데이터셋의 지연 로딩 (lazy loading) 및 내구성을 위한 자동 체크포인트 내보내기 (automatic checkpoint export)를 지원합니다.

클러스터 규모에서는 이러한 인스턴스들이 Amazon EC2 UltraClusters에 배포됩니다. UltraClusters는 가용 영역 (Availability Zone) 내에서 수천 개의 가속 인스턴스를 단일한 밀집 클러스터 (tightly placed cluster)로 프로비저닝하며, 페타비트 규모의 논블로킹 네트워크 (nonblocking network)를 사용하여 이들을 상호 연결합니다.

그림: 2세대 Amazon EC2 UltraClusters (P5 UltraCluster 예시).

스텝당 통신 강도 (per-step communication intensity)가 높은 워크로드(예: 모든 토큰 디스패치가 많은 GPU에 걸쳐 발생하는 MoE 모델의 전문가 병렬성 (expert parallelism))의 경우, NVLink 도메인 (NVLink domain)의 크기가 1차적인 제약 요인이 될 수 있습니다. 내부 스케일업 (scale-up) 축의 확장으로서, NVLink 도메인을 확장하면 성능에 결정적인 통신이 NVLink 패브릭 (NVLink fabric)을 벗어나야 하는 빈도를 줄일 수 있습니다.

Amazon EC2 UltraServers는 전용 가속기 상호 연결 (dedicated accelerator interconnect)을 통해 여러 구성 인스턴스를 연결함으로써 NVLink 도메인을 단일 EC2 인스턴스 너머로 확장합니다. AWS의 보고에 따르면, P6e-GB200 UltraServers는 NVIDIA GB200 NVL72 플랫폼을 기반으로 구축되었으며, 하나의 NVLink 도메인 내에서 최대 72개의 Blackwell GPU와 13.4 TB의 집계 HBM3e를 제공합니다. 더 큰 규모에서는 EFA가 멀티-UltraServer 작업을 위한 노드 간 패브릭 (cross-node fabric) 역할을 유지하지만, 도메인 내 GPU 수를 늘림으로써 성능에 결정적인 통신이 NVLink 패브릭을 벗어나야 하는 빈도를 줄일 수 있습니다.

이 시스템은 NVIDIA Grace–Blackwell 슈퍼칩(superchips)으로 구축되며, 이 칩은 캐시 일관성(cache-coherent) NVLink-C2C를 통해 Grace CPU 메모리와 Blackwell GPU HBM을 결합하여, 명시적인 호스트-디바이스(host–device) 복사 없이도 CPU 및 GPU 부착 메모리 간의 직접 액세스를 가능하게 합니다. 실제로 이는 로컬 HBM보다 지연 시간(latency)은 높고 대역폭(bandwidth)은 낮지만, PCIe 규모의 복사 오버헤드를 피하면서 GPU 워크로드에 사용할 수 있는 유효 메모리를 확장할 수 있습니다(예: 상대적으로 덜 사용되는 모델 상태나 KV 캐시를 CPU 부착 메모리에 배치).

P6e-GB200 UltraServer의 컴포넌트 인스턴스 유형은 p6e-gb200.36xlarge이며, 이는 4개의 GPU와 Elastic Fabric Adapter (EFA) v4 네트워킹을 제공합니다. 아래 표는 인스턴스당 구성 및 구성된 UltraServer 구성을 요약한 것입니다.

인스턴스 유형	GPU	GPU 수	GPU 메모리	메모리 대역폭	NVLink	NVLink 대역폭	EFA	EFA 대역폭
p6e-gb200.36xlarge	GB200 NVL72	4	740 GB HBM3e	—	—	—	v4	200 GB/s

참고: p6e-gb200.36xlarge의 EFA 대역폭은 발표된 총합 EFA 네트워킹(4 × 400 Gbps)을 GB/s로 변환(÷8)한 값입니다. EC2 가속 컴퓨팅 네트워킹 사양을 참조하십시오.

UltraServer	컴포넌트 인스턴스 유형	GPU (NVLink 도메인)	HBM3e (총합)	EFA	EFA 대역폭
u-p6e-gb200x36	p6e-gb200.36xlarge	36	6.7 TB	v4	1,800 GB/s
u-p6e-gb200x72	p6e-gb200.36xlarge	72	13.4 TB	v4	3,600 GB/s

참고: UltraServer EFA 대역폭은 AWS에서 보고한 초당 테라비트(Tbps)를 GB/s로 변환(÷8)한 값입니다. P6e-GB200 UltraServer 발표 및 P6 인스턴스 제품군 페이지를 참조하십시오.

학습이 수백 또는 수천 개의 가속기(accelerators)에 걸쳐 수행될 때, 수동 리소스 관리(manual resource management)는 다루기 힘들어집니다. 예를 들어, 512개의 GPU를 필요로 하는 학습 작업은 64개의 8-GPU 노드(P-instances)를 동시에 공동 스케줄링(co-schedule)해야 하며, 작업이 완료되거나 실패했을 때 원자적(atomically)으로 리소스를 해제해야 합니다. Slurm과 Kubernetes는 모두 컨트롤 플레인(control-plane) 아키텍처를 통해 이 과제를 해결합니다. 즉, 중앙 집중식 스케줄러(centralized scheduler)가 클러스터 상태를 유지하고 할당 결정을 내리는 동안, 워커 노드(worker nodes)는 할당된 워크로드(workloads)를 실행합니다.

그림 2: AWS에서의 Slurm 기반 및 Kubernetes 기반 리소스 오케스트레이션 (resource orchestration)의 상위 수준 아키텍처