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

1편에서는 모델 규모에 맞는 GPU 인스턴스와 인터커넥트, 병렬화 전략, 그리고 모델 메모리 계산까지 ‘무엇을 고를까’를 다뤘습니다. 이번 2편에서는 그 선택을 수천 장 규모로 확장합니다. 수천에서 수만 개의 GPU를 하나의 학습으로 묶는 울트라클러스터와 울트라서버 아키텍처, 그리고 이런 고성능 인스턴스를 실제로 확보하는 ODCR 및 Capacity Block 전략을 다룹니다.

시리즈 블로그 보기

• 분산 학습을 위한 AWS 컴퓨트 선택 가이드 (1편: 모델 규모와 하드웨어 선택)
• 분산 학습을 위한 AWS 컴퓨트 선택 가이드 (2편: 초대규모 스케일링과 인스턴스 확보)
• 분산 학습을 위한 AWS 컴퓨트 선택 가이드 (3편: 클러스터 구축과 운영)

울트라클러스터: 수천 개의 GPU를 하나로 묶는 방법

Amazon EC2 울트라클러스터(UltraClusters)는 수천 개의 EC2 GPU 인스턴스를 하나의 고성능 네트워크 패브릭 안에 배치한, AWS가 사전에 설계, 구축, 운영하는 아키텍처입니다. 고객이 직접 AWS 클라우드 내에서 구성하는 것이 아니라, 용량을 예약(ODCR 또는 Capacity Block 방식 사용)하면 AWS가 그 인스턴스들을 동일한 네트워크 스파인 위에, 페타비트(petabit)급 논블로킹(non-blocking) EFA 패브릭으로 co-location해 줍니다. 일반적인 EC2 Placement Group과 달리 모든 인스턴스가 동일 네트워크 스파인(single spine, 물리 스위치 한 대가 아니라 여러 spine 스위치가 하나의 non-blocking 통합 패브릭으로 묶여 어느 두 노드든 full bisection 대역폭 확보 가능, 그림1 참조)에 연결되기 때문에, 어떤 두 노드 사이에서도 균일한 대역폭이 보장됩니다. 노드가 늘어나도 특정 구간만 느려지는 일이 없다는 점이 대규모 학습에서 결정적입니다.

왜 “균일한 대역폭”이 결정적인가? 대규모 분산 학습은 매 step마다 모든 GPU가 동기화되는 구조라, 전체 속도가 가장 느린 노드(straggler)에 의해 결정됩니다. 만약 클러스터 안에서 어떤 노드 쌍은 가깝게 붙어 빠르고, 어떤 쌍은 멀리 떨어져 느리다면, 그 느린 경로 하나가 매 step마다 전체 성능을 끌어내립니다. 수백 노드 규모에서 이런 불균일은 곧바로 GPU 유휴와 비용 낭비로 이어집니다. 울트라클러스터가 모든 노드를 같은 스파인에 매달아 두는 이유가 여기에 있습니다. 어느 두 노드를 골라도 구조적 병목 없이 일관되게 높은 대역폭 보장(full bisection bandwidth)이 되어야, 병렬화 전략을 짤 때 노드의 물리적 위치를 신경 쓰지 않고 균일한 클러스터로 다룰 수 있습니다.

무엇으로 묶는가?

울트라클러스터의 노드 간 연결을 실제로 담당하는 것이 AWS EFA(Elastic Fabric Adapter)입니다. EFA는 SRD(Scalable Reliable Datagram) 프로토콜을 탑재하여 TCP를 우회해 낮은 지연과 높은 대역폭을 제공하고, GPUDirect RDMA와 결합하면 한 노드의 GPU 메모리에서 다른 노드의 GPU 메모리로 CPU를 거치지 않고 직접 데이터를 옮길 수 있습니다. NCCL이 이 경로를 사용하도록(aws-ofi-nccl을 통해) 설정되어 있어야 분산 학습의 AllReduce가 제 속도를 냅니다. 반대로 EFA가 제대로 활성화되지 않으면 통신이 조용히 일반 TCP로 폴백되는데, 오류 없이 성능만 급격히 떨어지기 때문에 원인을 찾기가 매우 어렵습니다. 울트라클러스터를 쓰더라도 EFA 및 NCCL 설정 점검이 사실상 첫 체크리스트인 이유입니다.

Placement Group과 무엇이 다른가?

일반적인 placement group은 인스턴스를 물리적으로 가깝게 배치해 지연을 줄이고 처리량을 높여 줍니다. 다만 이 근접 배치의 효과는 비교적 작은 규모에서 확실하고, 규모가 커질수록 모든 노드에 균일한 성능을 보장하기는 어렵습니다.

울트라클러스터는 이 개념을 수천~수만 노드 규모로 끌어올려, 모든 인스턴스를 하나의 non-blocking 네트워크 패브릭 아래에 둡니다. 여기서 오해하기 쉬운 점이 두 가지 있습니다.

첫째, 이 패브릭은 단일 스위치가 아닙니다. 스위치는 포트 수(radix)가 유한해 수천 노드를 한 대에 물릴 수 없으므로, 실제로는 여러 단(段)의 folded Clos 구조(포트 수가 유한한 스위치 여러 대를 여러 단으로 쌓아 하나의 거대한 스위치처럼 동작시키는 구조)로 구성됩니다. AWS는 세대를 거치며 이 단수를 줄여, 호스트에서 호스트까지 거치는 네트워크 장치 수를 3-tier Clos의 최대 7홉에서 2-tier Clos의 최대 5홉으로 단축(울트라클러스터 2.0 기준)했습니다. 따라서 어느 두 노드가 통신하느냐에 따라 거치는 경로 길이가 다릅니다. 같은 leaf(ToR) 스위치에 붙은 노드끼리는 가장 짧은 경로로, 멀리 떨어진 노드는 상위 단(spine)까지 올라갔다 내려오는 더 긴 경로로 통신합니다.

둘째, 그럼에도 “평평한(flat) 네트워크”라고 부르는 이유는 지연이 아니라 대역폭이 균일하기 때문입니다. non-blocking이라는 것은, 어느 노드 쌍이 통신하든 – 홉 수나 위치와 무관하게 – full bisection 대역폭(클러스터를 반으로 나눴을 때 두 그룹 사이를 오가는 총 대역폭)을 받는다는 의미입니다. 즉 클러스터의 절반이 나머지 절반으로 한꺼번에 데이터를 쏟아붓는 극단적인 통신 상황에서도 네트워크 상단에서 대역폭이 무너지지 않습니다. 지연은 홉 수에 따라 다소 차이가 있지만 그 차이는 작고 예측 가능하며, EFA/SRD가 트래픽을 여러 경로로 분산해 실효 성능을 평탄화합니다.

대규모 분산학습의 집합통신(all-reduce, all-to-all)에서 성능을 좌우하는 것은 절대적인 경로의 지연이 아니라 총 대역폭과 병목 없음입니다. 울트라클러스터가 제공하는 이 “대역폭 균일성”이 바로 학습에 적합한 이유이며, AWS가 이를 “petabit-scale non-blocking network” 로 설명하는 배경입니다.

AWS 생태계와의 통합

울트라클러스터는 고립된 네트워크가 아니라 다른 AWS 서비스와 맞물려 동작하도록 설계되었습니다. 학습 데이터는 보통 Amazon S3에 원본으로 두고, 이를 Amazon FSx for Lustre에 연결해 수천 노드가 병렬로 읽어 들입니다. 다만 여기서 한 가지 전제가 있습니다. Amazon FSx for Lustre의 처리량은 무한이 아니라 프로비저닝한 용량과 스루풋 티어(throughput tier)에 비례하고, Amazon S3 연동 데이터는 접근 시점에 가져오는 지연 로딩(lazy load)과 미리 끌어오는 preload 두 방식이 있습니다. 따라서 “수천 노드가 동시에 고속으로 읽는다”는 것은 자동으로 보장되는 성질이 아니라, 워크로드 규모에 맞게 파일시스템을 충분히 크고 빠르게 프로비저닝하고 데이터를 샤딩한 뒤 preload를 완료해 두었을 때 성립합니다. 학습 중 GPU가 데이터 로딩에서 멈춰 있다면, preload 완료 여부부터 확인하는 이유가 이것입니다. 그 위에서 잡(job)은 Amazon SageMaker HyperPod, AWS PCS(Parallel Computing Service), Amazon EKS 같은 오케스트레이션이 스케줄링하고, 체크포인트는 다시 FSx와 S3로 흘려보내 노드 장애나 스팟 회수에 대비합니다. 정리하면 울트라클러스터는 GPU를 빠르게 연결하는 고속 네트워크의 한 조각일 뿐이고, 그 위에 제대로 프로비저닝된 데이터 파이프라인과 스케줄러, 그리고 체크포인트 기반 장애 복구가 얹혀야 비로소 완결된 학습 플랫폼이 됩니다.

그림1. Amazon EC2 울트라클러스터 아키텍처

그림1은 울트라클러스터를 구성하는 두 축 – 컴퓨트 네트워크와 데이터 공급 – 을 한 장에 담고 있습니다. 오른쪽이 컴퓨트 영역입니다. 아래쪽에 늘어선 것이 GPU 인스턴스이고, 각 인스턴스는 여러 개의 EFA(ENI)로 상단의 Top of Rack(leaf) 스위치에 연결됩니다. 다시 각 Top of Rack은 그 위의 Backplane(spine) 스위치들에 full-mesh로 연결되어, 스위치 한 대가 아니라 여러 단으로 쌓인 folded Clos 패브릭을 이룹니다(“Petabit-scale non-blocking network”). 노드와 패브릭을 연결하는 링크가 노드당 3,200 Gbps의 EFA(Elastic Fabric Adapter)입니다(p5 세대 기준). 여기서 “논블로킹”이 핵심입니다. 다수 노드가 동시에 트래픽을 쏟아내도 서로의 경로를 막지 않도록(full bisection bandwidth) 설계됐다는 뜻으로, 특정 구간에 트래픽이 몰려 병목이 생기는 over-subscribed 네트워크와 대비됩니다. 같은 Top of Rack에 붙은 노드는 스파인을 거치지 않는 짧은 경로로, 멀리 떨어진 노드만 스파인을 경유하지만, 어느 두 노드 쌍이든 홉 및 위치와 무관하게 동일한 full bisection 대역폭을 받습니다. 대규모 분산 학습에서 AllReduce가 매 step 전 노드에 걸쳐 폭주해도 특정 구간이 병목이 되지 않는 근거가 바로 이 non-blocking, 균일 대역폭 구조입니다.

왼쪽은 데이터 공급 영역입니다. Amazon FSx for Lustre가 TB/s급 처리량과 수백만 IOPS로 GPU에 데이터를 밀어 넣는 구조로, 지난 블로그에서 이야기한 “비싼 GPU를 굶기지 않는다”는 원칙의 물리적 구현입니다. 네트워크와 GPU가 아무리 빨라도 데이터가 제때 도착하지 않으면 GPU가 유휴 상태가 되므로, 고대역 및 높은 IOPS 스토리지가 컴퓨트 패브릭과 한 묶음으로 그려져 있습니다. 정리하면 울트라클러스터는 균일한 non-blocking EFA 패브릭(오른쪽)과 그 GPU를 굶기지 않는 FSx 데이터 공급(왼쪽)이 결합된 하나의 학습 인프라입니다.

한 가지 짚어둘 점은, 울트라클러스터는 고객이 별도로 “구매”하는 상품이 아니라 고사양의 GPU 인스턴스가 사전 배치되어 있는 고성능 클러스터라는 점입니다. 고객이 ODCR(On-Demand Capacity Reservation)이나 Capacity Block으로 p5 및 p6 인스턴스를 원하는 개수만큼 예약하면, AWS는 그 요청 수량만큼의 인스턴스를 하나의 울트라클러스터 내에서 할당하여 고객에게 제공합니다. 즉 예약한 노드들이 자동으로 동일한 고성능 EFA패브릭에 묶여, 앞서 말한 “어느 두 노드를 골라도 균일한 대역폭”이 확보되는 것입니다. 여기서 중요한 차이는 유연성입니다. 울트라클러스터는 고객이 요청한 만큼(수십~수천 노드)의 규모로 할당되므로 워크로드 크기에 맞춰 자유롭게 인스턴스의 개수를 정할 수 있습니다. 반면 뒤에서 다룰 Amazon EC2 울트라서버(UltraServer)는 9개 인스턴스(36개 GPU)나 18개 인스턴스(72개 GPU)처럼 NVLink로 물리적으로 묶인 고정 단위로 제공된다는 점이 다릅니다. 한쪽은 “EFA로 원하는 수만큼 묶는 유연한 클러스터”, 다른 한쪽은 “NVLink로 고정 크기로 묶인 초고속 도메인”인 셈입니다.

표1. 일반 EC2 클러스터와 울트라클러스터 비교

울트라서버: 인스턴스 경계를 지우는 초대규모 컴퓨트

울트라서버는 그림2와 같이 여러 p 시리즈 인스턴스를 NVLink Switch(NVS, NVSwitch ASIC들로 구성된 랙 스케일 스위치 패브릭)로 물리적으로 연결해, 인스턴스 경계를 넘어 GPU들이 하나의 컴퓨트 풀처럼 동작하게 만드는 아키텍처입니다. 울트라클러스터가 EFA로 인스턴스를 이어 붙인 것이라면, 울트라서버는 NVLink 수준의 초고속 인터커넥트로 인스턴스 사이의 GPU를 직접 연결한 것이라고 이해하면 됩니다.

현재 대표 구성은 NVIDIA GB200 기반의 NVL72로, 72개 GPU를 하나의 NVLink 도메인으로 묶은 풀 랙 구성입니다. AWS는 이를 p6e-gb200 인스턴스 기반의 울트라서버로 제공하며, 크기는 두 가지입니다. 36 GPU의 u-p6e-gb200x36과 72 GPU의 u-p6e-gb200x72이며, 이 중 후자(x72)가 곧 GB200 NVL72 풀 구성입니다. 아래 그림2는 이해를 돕기 위해 절반 크기인 x36 구성을 예로 듭니다.

여기서 한 가지 짚을 점은 인스턴스 한 대의 구조입니다. 그림2의 왼쪽에서 보이듯 컴퓨트 노드 한 대(p6e-gb200.36xlarge)는 GB200 Superchip 2개로 이루어지고, 각 Superchip은 Grace CPU 1개와 Blackwell GPU 2개를 묶은 단위입니다. 따라서 일반 p 시리즈가 노드당 GPU 8개인 것과 달리, 이 컴퓨트 노드는 GPU 4개를 담습니다. 노드 안의 GPU들은 NVSwitch로 연결되고, 네트워킹을 위한 NIC와 Nitro 카드가 함께 붙습니다.

그림2. 울트라서버 아키텍처, u-p6e-gb200x36 기준

그림 오른쪽에서 보이듯, 이 노드를 9개 묶으면 GPU 36개(u-p6e-gb200x36, 본 그림 구성)가 되고, 18개 묶으면 GPU 72개(u-p6e-gb200x72)가 됩니다. 풀 구성(x72) 기준으로 72개 Blackwell GPU가 단일 NVLink 도메인으로 묶여 약 13.4 TB의 HBM3e 메모리를 하나의 풀처럼 활용하며, 360 PFLOPS(FP8, non-sparsity)의 컴퓨팅 파워를 제공합니다. AWS 공식 자료는 이를 p5en 인스턴스 대비 NVLink 하에서 p6e-gb200 인스턴스가 20배 이상의 컴퓨트와 11배 이상의 메모리를 제공한다고 표현합니다(막연한 “이전 세대”가 아니라 비교 대상이 p5en으로 명시되어 있습니다).

표2. p6e-GB200 울트라서버 비교

구조적으로 울트라서버도 일반 p 시리즈와 마찬가지로 AWS Nitro 시스템 위에서 구동됩니다. NVLink로 GPU를 직결해 성능을 끌어올리면서도, 네트워킹, 스토리지, 보안은 Nitro가 떼어내 처리하는 AWS 고유의 운영 모델을 그대로 따릅니다. 덕분에 Amazon SageMaker HyperPod, Amazon EKS, Amazon FSx for Lustre 같은 관리형 서비스와 자연스럽게 통합되어, 특수 하드웨어임에도 기존 분산 학습 워크플로우에 그대로 얹을 수 있습니다.

표3. p 시리즈 인스턴스 사양 비교

울트라클러스터와 울트라서버의 차이는 “필요한 책이 어디에 있느냐”로 비유하면 분명해집니다. 연구를 위해 여러 권의 책(다른 GPU의 데이터)을 수시로 꺼내 봐야 한다고 해보겠습니다.

single spine(EFA)으로 묶인 울트라클러스터는 그 책들이 여러 건물에 흩어져 있는 상태입니다. 건물 사이는 넓고 신호등 없는 전용 고속도로로 이어져 오가는 속도 자체는 빠르지만, 다른 건물의 책이 필요할 때마다 밖으로 나가 도로를 건너 다녀와야 합니다. 이 “건물 밖 왕복”이 노드 간 네트워크 통신이고, 그래서 마이크로초 단위의 지연이 붙습니다.

반면 울트라서버(NVL72)는 원하는 책이 전부 하나의 거실에 모여 있는 상태입니다. 다른 책이 필요해도 건물을 나갈 필요 없이 손만 뻗으면 됩니다. NVLink가 72개 GPU를 직접 연결해 각 GPU가 다른 GPU의 HBM에도 CPU를 거치지 않고 접근할 수 있고, 그 결과 72개 GPU의 메모리가 논리적으로 하나의 거대한 풀처럼 동작합니다. “책을 가지러 건물 밖으로 나가느냐, 같은 거실에서 손만 뻗느냐” – 이 차이가 두 아키텍처의 본질입니다.

이 차이가 결정적으로 드러나는 지점이 노드 경계의 통신 병목(inter-node communication bottleneck)입니다. single spine 환경에서는 모델이 한 노드(GPU 4~8개)를 넘는 순간 반드시 노드 간 네트워크 통신이 끼어듭니다. AWS의 EFA는 SRD(Scalable Reliable Datagram)로 TCP 및 커널을 우회해 이 통신을 크게 최적화하지만, 데이터가 GPU를 떠나 NIC를 거치고 스위치 홉을 넘는 네트워크 횡단 비용까지 0이 되지는 않습니다. 울트라서버는 이 경계 자체를 없애 최대 72개 GPU메모리를 하나의 로컬 메모리처럼 다루므로, 다른 GPU의 데이터를 “옆 서버에 물어보는” 네트워크 요청이 아니라 “내 메모리 저쪽에서 가져오는” 로컬 접근처럼 처리합니다.

다만 울트라서버의 이 통합 도메인은 72 GPU가 상한이며, 소프트웨어로 더 키울 수 없습니다. 그 이상은 울트라서버끼리 EFA로 연결해 확장하는데, 이 방식은 일반 클러스터의 확장과 다르지 않습니다. 그래서 울트라클러스터와 울트라서버는 대체재가 아니라 서로 다른 계층(layer)의 개념입니다. 울트라서버가 “NVLink 도메인 안”이라면, 울트라클러스터는 그런 도메인(또는 일반 p5 또는 p6 인스턴스)을 EFA로 수천 단위까지 연결하는 “도메인 사이”입니다. 중요한 점은 울트라클러스터가 여러 울트라서버를 하나의 더 큰 NVLink 도메인으로 융합하지는 않는다는 것입니다. 각 울트라서버는 독립된 72-GPU 도메인으로 남고 그 사이는 EFA로 연결되므로, 울트라클러스터의 구성 단위가 꼭 울트라서버일 필요도 없습니다. 일반 인스턴스 수천 대를 EFA로 묶어도 울트라클러스터입니다.

이 “도메인 안 vs 도메인 사이” 구조가 병렬화 배치의 기본 원칙을 결정합니다. 통신이 가장 잦은 병렬화(Tensor Parallel, MoE의 All-to-All)는 NVLink 도메인 하나(72 GPU) 안에 가두고, 빈도가 낮은 병렬화(Pipeline, Data Parallel)는 EFA 경계를 넘도록 배치합니다. 72 GPU 경계를 넘는 순간 통신이 훨씬 느린 EFA로 떨어지므로, 이 경계에 맞춰 병렬화 전략을 설계하는 것이 핵심입니다.

표4. single spine 보장 p6 클러스터 vs GB200 울트라서버(NVL72)

수천에서 수만 개의 GPU로 장기 대규모 학습을 한다면, single spine이 보장된 인스턴스 클러스터(울트라클러스터)가 경제적이고 현실적인 최상급 선택입니다. 통신 빈도가 상대적으로 낮은 Data/Pipeline Parallel 중심 워크로드에서 특히 그렇습니다. 반면 GPU 간 통신이 극도로 잦은 워크로드 – 초거대 모델의 실시간, long-context 추론, 추론 단계에서 연산을 더 투입해 답의 질을 높이는 reasoning 모델의 test-time compute, 통신이 극도로 잦은 MoE 미세조정처럼 GPU 간 빠른 통신을 전제로 하는 기법 – 에서는 GB200 울트라서버(NVL72)가 최적의 성능을 냅니다. 필요한 GPU가 72개를 넘으면 울트라서버 여러 대를 EFA로 연결(울트라서버당 최대 28.8 Tbps)해, 각 서버 내부는 NVLink, 서버 사이는 EFA인 2단 구조로 확장합니다.

참고로 최신 세대 GPU일수록 초기에는 가용 리전이 제한적인 경향이 있으므로, 도입을 검토할 때는 원하는 리전에서 p6e-gb200을 쓸 수 있는지 EC2 공식 페이지에서 최신 현황을 확인하시길 권합니다.

고성능 GPU 인스턴스 확보 전략 – ODCR

p5, p6 같은 최신 고성능 GPU 인스턴스는 전 세계적으로 수요가 많아, 필요할 때 원하는 수량을 바로 확보하기 어렵습니다. 콘솔에서 버튼 하나로 100대가 곧바로 켜지는 상황을 기대하기 어렵다는 뜻입니다. 그래서 대규모 GPU가 필요한 워크로드라면 용량을 미리 잡아두는 예약 전략이 사실상 필수가 되며, AWS는 이를 위해 성격이 다른 두 가지 방법을 제공합니다. 바로 ODCR(On-Demand Capacity Reservation)과 Capacity Block(Capacity Blocks for ML)입니다. 둘의 차이는 익숙한 비유로 요약할 수 있습니다. ODCR은 “주차장 월 정기권”에 가깝습니다. 내 자리를 계속 확보해두는 대신, 실제 차를 주차하지 않아도 자리값(요금)이 계속 나갑니다. 예약을 취소할 때까지 용량이 유지되고 과금도 이어집니다. 반면 Capacity Block은 “호텔 예약”에 가깝습니다. 특정 날짜부터 며칠 간을 미리 결제해 잡아두며, 그 기간에 실제로 투숙(사용)하지 않더라도 이미 지불한 예약 비용은 발생합니다. 다만 기간이 끝나면 자동으로 반납되어, ODCR처럼 취소를 잊어 요금이 계속 새어나가는 일은 없습니다.

ODCR은 “특정 타입의 인스턴스 몇 대 분량의 자리를 나를 위해 잡아 둬”라고 요청하는 방식입니다. 예약을 거는 것 자체는 무료지만, 예약한 용량이 확보되어 활성화되는 순간부터는 인스턴스를 실제로 켜지 않더라도 그 용량만큼 시간당 On-Demand 요금이 청구됩니다. 이 점이 ODCR에서 가장 유의해야 할 부분입니다. 자리를 잡아둔 것만으로 돈이 나가기 때문에, 예를 들어 오늘 p6 100대를 ODCR로 확보해놓고 데이터와 코드 준비가 늦어져 5일간 한 대도 켜지 않았다면, 그 5일치 100대분 On-Demand 요금이 고스란히 청구됩니다. 그래서 준비가 거의 끝난 시점에 예약을 맞추는 것이 비용 낭비를 줄이는 요령입니다.

시작 시점은 두 가지 중에서 고를 수 있습니다. 하나는 즉시(now) 확보로, 지금 당장 용량을 잡는 방식입니다. 다만 그 순간 재고가 없으면 대기 없이 예약 자체가 실패하며, p5나 p6처럼 인기있는 인스턴스는 즉시 100대를 확보하지 못할 수 있습니다. 다른 하나는 미래 날짜 지정(future-dated)으로, “8월 1일부터 시작”처럼 미래의 시작일을 정해 예약하는 방식입니다. 이 경우 시작일 전 대기 기간에는 요금이 발생하지 않고, 시작일에 용량이 확보되는 순간부터 과금이 시작됩니다. 준비 기간이 길다면 이 미래 날짜 예약이 유용합니다.

유연성 측면에서 ODCR은 기간 약정 없이 언제든 만들고 취소할 수 있으며, 취소해야 과금이 멈춥니다. 다만 이는 즉시 예약에 해당하는 이야기이고, 미래 날짜 예약(future-dated)에는 최소 유지 기간(commitment duration)이 있어 프로비저닝된 뒤 그 기간 동안은 약정한 인스턴스 수 미만으로 줄이거나 그보다 이른 종료일을 지정할 수 없습니다. 취소 자체는 가능하지만 취소 수수료가 부과될 수 있습니다. 최소 유지 기간은 대부분의 인스턴스 유형이 14일, U·X 계열은 12주이며, 미래 날짜 예약은 시작일 기준 5~120일 전에 요청할 수 있습니다(8주 전 요청 권장). 요금은 기본적으로 On-Demand이지만, 이미 Savings Plans나 예약 인스턴스(RI)를 보유하고 있다면 결합해 할인을 받을 수 있습니다. 필수는 아니고 선택입니다.

고성능 GPU 인스턴스 확보 전략 – Capacity Block

Capacity Block은 “○월 ○일부터 며칠간, GPU 몇 대를 통째로 빌린다”라고 시작 및 종료 시점을 못 박아 예약하는 방식으로, 호텔을 미리 예약하는 것과 같습니다. 예약을 확정하는 시점에 전체 기간 요금을 선불로 결제하며, 가격은 그때그때 수요에 따라 정해지는 시장 가격입니다. 고정 할인율이 있는 것이 아니라 시점에 따라 저렴할 수도, 비쌀 수도 있으며, Savings Plans나 RI는 적용되지 않습니다. 예약은 최대 8주(56일) 전까지 미리 걸 수 있지만, 실제 예약 가능 여부는 그날 열리는 재고 상황에 따라 달라집니다. 참고로 예약 기간은 최소 1일부터 최대 182일까지 가능합니다.

Capacity Block의 핵심 가치는 일정이 확정된 대규모 학습에 용량을 미리, 그리고 확실하게 잡아둘 수 있다는 점입니다. 다만 한 가지 실무에서 자주 걸리는 부분은 예약 기간의 단위 규칙입니다. 기간을 아무 숫자로나 정할 수 없고, 표5와 같이 정해진 단위를 따라야 합니다.

표5. Capacity Block 예약 기준

ODCR과 Capacity Block의 차이를 표6에 정리하였습니다.

표6. ODCR과 Capacity Block 선택 기준

각주 ¹: ODCR 미래 날짜 예약은 시작일 5~120일 전 범위에서 요청하며, AWS가 최대 5일간 지원 가능 여부를 심사합니다. 최소 유지 기간(대부분 14일, U, X 인스턴스는 12주)과 최소 규모(32 vCPU) 조건이 있습니다. (AWS 권장: 지원 가능성을 높이려면 56일(8주) 이상 미리 요청)

정리하면, 언제 얼마나 쓸지 유동적이고 약정 없이 유연하게 관리하고 싶다면 ODCR이 맞습니다. 다만 인스턴스를 확보한 기간에는 실제로 켜지 않아도 요금이 나간다는 점을 늘 염두에 두어야 합니다. 반대로 특정 시기에 대규모 학습이 이미 확정되어 있고 그 최신 GPU 물량을 미리 확실히 확보해야 한다면 Capacity Block이 강합니다. 한쪽이 항상 우월한 것이 아니라 용도가 다르며, 유연성과 장기 상시 운영에는 ODCR이, 미래 특정 기간의 확실한 대규모 확보에는 Capacity Block이 제격이라고 이해하면 됩니다.

맺음말

2편에서는 수천에서 수만 장의 GPU를 하나의 학습으로 묶는 두 아키텍처를 살펴봤습니다. 울트라클러스터는 EFA 기반의 균일한 고대역폭 패브릭으로 대규모 노드를 single spine으로 연결하고, 울트라서버는 NVLink 도메인을 인스턴스 경계 너머로 확장해 최대 72개 GPU 메모리를 하나의 메모리 풀처럼 다룹니다. 둘은 대체재가 아니라 계층 관계로, 울트라서버가 NVLink 도메인을 키우고 그 위를 울트라클러스터가 EFA로 연결합니다. 또한 이런 고성능 인스턴스는 수요가 많아, ODCR이나 Capacity Block으로 용량을 미리 확보하는 계획이 사실상 필수입니다.

다음 3편에서는 이렇게 선택하고 확보한 컴퓨트 리소스를 실제로 런치(launch)하고 운영하는 단계로 넘어갑니다. 컨테이너 환경 구성(Enroot 및 Pyxis), 클러스터를 띄우기 전 점검사항, 온프레미스 환경과의 비교, GPU와 AWS 자체 AI 가속기인 AWS Trainium의 선택, 그리고 현장에서 자주 마주치는 문제의 해결까지 다룹니다.