분산 학습을 위한 AWS 컴퓨트 선택 가이드 (2편: 초대규모 스케일링과 인스턴스 확보)

대규모 분산 학습에서 수천~수만 GPU 를 묶는 두 가지 AWS 아키텍처와, 그 인스턴스를 실제로 확보하는 방법을 다룬 2편이다. 울트라클러스터는 EFA 패브릭으로 노드를 넓게 잇고, 울트라서버는 NVLink 로 72 GPU 를 하나처럼 묶는다. 확보 전략은 ODCR 과 Capacity Block 중 학습 일정의 확정성에 따라 갈린다.

핵심 포인트

울트라클러스터는 수천 EC2 GPU 인스턴스를 하나의 non-blocking 네트워크에 배치해, 어떤 두 노드를 잡아도 대역폭이 균일하다
균일성이 중요한 이유는 매 스텝 모든 GPU 가 동기화돼 느린 노드 하나가 전체 속도를 결정하기 때문이다
울트라서버 NVL72 는 NVSwitch 로 인스턴스 경계를 지워 72 GPU·약 13.4TB HBM3e 를 단일 풀처럼 쓴다
ODCR 은 예약 자체는 무료지만 안 켜도 On-Demand 요금이 나가고, Capacity Block 은 기간 전체를 선불로 낸다
개발·실험처럼 일정이 유동적이면 ODCR, 시작·종료가 확정된 대규모 학습이면 Capacity Block 이 맞다

상세 정리

울트라클러스터 구조: Folded Clos 2~3단으로 petabit 급 EFA 패브릭을 구성하고 모든 노드를 같은 스파인에 붙인다
홉 수: 3-tier 를 2-tier 로 줄이면 최대 7홉이 5홉으로 짧아진다
대역폭: p5 기준 노드당 EFA 3,200Gbps 를 쓴다
울트라서버 규모: u-p6e-gb200x36 은 GPU 36개(컴퓨트 노드 9), x72 는 72개(노드 18)로 GB200 NVL72 풀 구성이다
성능: FP8 기준 360 PFLOPS 이며 p5en 대비 컴퓨트 20배, 메모리 11배 이상이다
선택 기준: 데이터·파이프라인 병렬 중심 장기 학습은 울트라클러스터가 경제적이고, GPU 간 통신이 극도로 잦은 추론·reasoning·MoE 미세조정은 울트라서버가 유리하다
울트라서버 한계: 72 GPU 고정이라 초과분은 서버 간 EFA 로 나가야 한다
ODCR 시점: 즉시 또는 5~120일 뒤 미래 날짜로 잡을 수 있고, 미래 예약은 최소 유지 기간이 붙는다(대부분 14일, U/X 계열 12주)
ODCR 위험: 100대를 잡아두고 5일간 한 대도 안 켜면 그 5일치 100대분이 그대로 청구된다
Capacity Block 단위: 1~14일은 1일 단위, 15~182일은 7일 단위로만 끊을 수 있고 최대 8주 전 예약이다
Capacity Block 장점: 자동 회수되므로 미사용 과금이 새지 않는다
소프트웨어 스택: NCCL 과 aws-ofi-nccl, GPUDirect RDMA 로 통신을 태운다
데이터 공급: Amazon FSx for Lustre 로 TB/s 급 처리량과 수백만 IOPS 를 받치고, S3 에서 preload 를 끝내둔다
오케스트레이션: SageMaker HyperPod, AWS PCS, EKS 중에서 고른다

왜 읽나수백 GPU 이상 규모의 학습 인프라를 처음 설계하면서 EFA 와 NVLink, 예약 방식 사이에서 판단이 필요한 엔지니어에게 기준을 준다.

AWS Korea Tech 블로그

원문은 여기서 이어서 읽을 수 있어요

원문 읽기

읽음 (0)

·takedown 요청

분산 학습을 위한 AWS 컴퓨트 선택 가이드 (2편: 초대규모 스케일링과 인스턴스 확보)

이 글과 비슷한

엔터프라이즈 보안 요구사항을 충족하는 프라이빗 Amazon Bedrock AgentCore 구축하기

OpenTofu와 Argo CD로 구성하는 GitLab 기반 AWS 제어 플레인

Amazon Bedrock 기반 사내 LLM, 키 발급부터 비용 차단까지: F&F의 LiteLLM 게이트웨이 운영 사례