🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

이 글은 파운데이션 모델의 확장이 사전학습 중심에서 사후학습·추론 시점 연산까지 넓어지면서, AWS 위에서 가속 컴퓨트·저지연 네트워크·분산 스토리지·오픈소스 운영 스택이 어떻게 함께 설계되어야 하는지 설명한다.

📌 핵심 요약

• 파운데이션 모델의 성능 확장은 과거에는 주로 모델 파라미터, 데이터셋 크기, 학습 연산량을 키우는 사전학습 스케일링으로 이해됐지만, 이제는 사후학습과 추론 시점 연산까지 포함하는 여러 스케일링 축으로 확장됐다.
• 이러한 변화는 사전학습, 사후학습, 추론 전 과정에서 공통적으로 강하게 결합된 가속기 컴퓨트, 고대역폭·저지연 네트워크, 분산 스토리지, 자원 오케스트레이션, 관측 가능성이 필요하다는 결론으로 이어진다.
• 글은 Slurm, Kubernetes, PyTorch, JAX, Prometheus, Grafana 같은 오픈소스 소프트웨어 스택이 클러스터 자원 관리, 모델 개발, 모니터링 계층에서 어떤 역할을 하는지 설명하며, AWS 인프라와의 접점을 다룬다.
• AWS 인프라 부분에서는 NVIDIA H100, H200, Blackwell B200, Blackwell Ultra B300 기반 EC2 P5·P6 계열 인스턴스의 연산 성능, HBM 용량·대역폭, NVLink/NVSwitch와 EFA 기반 통신 구조를 비교한다.
• 대규모 학습과 추론에서는 원시 연산 성능만으로는 충분하지 않고, 집단 통신, 메모리 이동, 체크포인트 저장, 모델 가중치와 KV 캐시 관리가 병목이 될 수 있으므로 NVMe, FSx for Lustre, S3, UltraClusters, UltraServers 같은 계층적 구성 요소가 중요해진다.

🧩 주요 포인트

1. 파운데이션 모델의 성능 확장은 과거에는 주로 모델 파라미터, 데이터셋 크기, 학습 연산량을 키우는 사전학습 스케일링으로 이해됐지만, 이제는 사후학습과 추론 시점 연산까지 포함하는 여러 스케일링 축으로 확장됐다.
2. 이러한 변화는 사전학습, 사후학습, 추론 전 과정에서 공통적으로 강하게 결합된 가속기 컴퓨트, 고대역폭·저지연 네트워크, 분산 스토리지, 자원 오케스트레이션, 관측 가능성이 필요하다는 결론으로 이어진다.
3. 글은 Slurm, Kubernetes, PyTorch, JAX, Prometheus, Grafana 같은 오픈소스 소프트웨어 스택이 클러스터 자원 관리, 모델 개발, 모니터링 계층에서 어떤 역할을 하는지 설명하며, AWS 인프라와의 접점을 다룬다.
4. AWS 인프라 부분에서는 NVIDIA H100, H200, Blackwell B200, Blackwell Ultra B300 기반 EC2 P5·P6 계열 인스턴스의 연산 성능, HBM 용량·대역폭, NVLink/NVSwitch와 EFA 기반 통신 구조를 비교한다.
5. 대규모 학습과 추론에서는 원시 연산 성능만으로는 충분하지 않고, 집단 통신, 메모리 이동, 체크포인트 저장, 모델 가중치와 KV 캐시 관리가 병목이 될 수 있으므로 NVMe, FSx for Lustre, S3, UltraClusters, UltraServers 같은 계층적 구성 요소가 중요해진다.

🧠 상세 정리

1. 단일 사전학습 스케일링에서 여러 스케일링 축으로의 전환

글은 파운데이션 모델의 확장이 오랫동안 사전학습에 더 많은 연산 자원을 투입하면 성능이 오른다는 직관에 기대어 왔다고 설명한다. Kaplan 등 2020년 연구처럼 모델 파라미터, 데이터셋 크기, 학습 연산량을 키울 때 손실이 예측 가능한 거듭제곱 법칙을 따른다는 경험적 결과가 이 관점을 뒷받침했다. 실제로 이런 경향은 대규모 가속기 용량과 이를 효율적으로 활용하기 위한 분산 인프라 투자를 정당화했다. 그러나 글은 현재의 프런티어가 더 이상 하나의 곡선으로 설명되지 않는다고 전환점을 제시한다. 사전학습뿐 아니라 지도 미세조정과 강화학습 기반 방법을 포함한 사후학습, 그리고 긴 사고, 검색·검증, 다중 샘플 전략 같은 추론 시점 연산도 성능 확장의 축이 되고 있다는 점이 핵심이다.

2. 모델 생애주기 전반에서 수렴하는 인프라 요구사항

사전학습, 사후학습, 추론이라는 세 단계가 서로 다른 목적을 갖더라도, 글은 이들이 요구하는 시스템 구성요소가 점점 수렴한다고 설명한다. 대규모 모델을 다루려면 강하게 결합된 가속기 컴퓨트, 고대역폭·저지연 네트워크, 분산 스토리지 백엔드가 공통적으로 필요하다. 또한 클러스터 자원을 관리하기 위한 오케스트레이션과, 하드웨어 및 애플리케이션 수준의 관측 가능성도 중요해진다. 규모가 커질수록 단순히 많은 GPU를 확보하는 것만으로는 부족하고, 클러스터 상태를 유지하며 성능 이상 징후를 진단할 수 있어야 한다. 따라서 글은 파운데이션 모델 인프라를 개별 장비의 성능 문제가 아니라 전체 생애주기를 지탱하는 계층적 시스템 문제로 다룬다.

3. 오픈소스 소프트웨어 스택의 계층 구조

글은 파운데이션 모델 개발과 운영이 오픈소스 소프트웨어 생태계에 크게 의존하고 있다는 점을 또 하나의 주요 흐름으로 제시한다. 클러스터 계층에서는 Slurm과 Kubernetes 같은 시스템이 자원 관리를 담당하고, 모델 개발 및 분산 학습은 PyTorch와 JAX 같은 프레임워크에서 구현되는 경우가 많다. 모니터링과 시각화, 즉 관측 가능성은 Prometheus가 지표를 수집하고 Grafana가 시각화와 알림을 제공하는 방식으로 구성되는 사례가 언급된다. 이 계층 구조에서는 하드웨어 인프라가 자원 오케스트레이션을 떠받치고, 그 위에서 머신러닝 프레임워크가 동작한다. 관측 가능성은 특정 한 층에만 붙는 기능이 아니라 인프라, 자원 관리, ML 프레임워크 전체를 가로지르는 운영 계층으로 자리 잡는다.

4. 글의 목적과 다루는 범위

이 글은 파운데이션 모델 학습과 추론에 관여하는 머신러닝 엔지니어와 연구자를 주요 독자로 설정한다. 특히 오픈소스 프레임워크 위에서 워크플로를 구축하는 경우를 염두에 두고, AWS 인프라가 일반적인 오픈소스 스택과 어떻게 상호작용하는지를 분석한다고 밝힌다. 다루는 인프라 요소는 다중 노드 가속기 컴퓨트, 고대역폭·저지연 네트워킹, 분산 공유 스토리지, 관련 관리형 서비스다. 목표는 사전학습, 사후학습, 추론에 걸친 시스템 병목과 확장 특성을 이해하기 위한 기술적 토대를 제공하는 것이다. 또한 이 글은 시리즈의 도입부로서 전체 시스템 아키텍처와 AWS 인프라 구성요소, 오픈소스 도구 사이의 통합 지점을 먼저 드러내는 역할을 한다.

5. 가속 컴퓨트: EC2 P 계열과 GPU 세대별 성능 축

인프라 계층의 첫 번째 축은 대용량 장치 메모리를 갖춘 가속 컴퓨트다. 글은 AWS가 Amazon EC2 가속 컴퓨팅 인스턴스, 특히 P 인스턴스 패밀리를 통해 여러 세대의 NVIDIA GPU를 제공한다고 설명한다. P5 계열에는 H100 기반 p5.48xlarge와 단일 H100을 사용하는 p5.4xlarge가 포함되고, H200 기반 p5e.48xlarge와 p5en.48xlarge 변형도 언급된다. P6 계열은 Blackwell B200 기반 p6-b200.48xlarge와 Blackwell Ultra B300 기반 p6-b300.48xlarge를 도입한다. 글은 세대가 바뀔수록 주요 확장 축이 Tensor 처리량, HBM 용량과 대역폭, 노드 내부 및 노드 간 인터커넥트 대역폭으로 정리된다고 설명한다. 표에서는 H100, H200, B200, B300의 BF16/FP16, FP8, 일부 FP4 밀집 Tensor 성능과 HBM 사양을 비교한다.

6. 통신 병목과 내부·외부 연결 구조

글은 모델이 커질수록 스텝 시간이 원시 연산 성능보다 집단 통신과 메모리 이동에 의해 좌우되는 경우가 많다고 강조한다. 다중 GPU 인스턴스에서는 GPU 통신이 크게 두 체제로 나뉜다. 내부 스케일업은 NVLink와 NVSwitch를 통해 한 노드 안의 GPU 사이를 고대역폭·저지연으로 연결하며, all-reduce나 all-gather 같은 집단 연산이 호스트 네트워크 스택을 거치지 않고 실행되도록 한다. 외부 스케일아웃은 EFA를 통해 노드 간 OS 우회 네트워킹을 제공하고, AWS의 EC2 UltraClusters에서 수천 개 인스턴스에 걸친 통신 집약적 집단 연산의 기반이 된다. 표에서는 p5.4xlarge부터 p6-b300.48xlarge까지 GPU 수, GPU 메모리, NVLink 세대와 총 대역폭, EFA 버전과 총 대역폭을 비교하며, 특히 P6 B300 구성에서 더 큰 GPU 메모리와 EFA 대역폭이 제시된다.

7. EFA, UltraClusters, 그리고 대규모 노드 간 통신

Elastic Fabric Adapter는 Amazon EC2용 네트워크 인터페이스로, Scalable Reliable Datagram 프로토콜을 사용해 OS 우회 RDMA 기능을 제공한다고 설명된다. 애플리케이션이 Libfabric API를 통해 네트워크 장치와 직접 통신하게 함으로써 운영체제 커널을 우회하고, 분산 학습의 집단 연산에서 지연을 줄이고 처리량을 높이는 것이 목적이다. 글은 EC2 P5와 P5e 인스턴스에는 EFAv2가, P5en에는 EFAv3가, P6에는 EFAv4가 제공된다고 구분한다. EFAv3는 EFAv2 대비 패킷 지연을 약 35% 낮추며, EFAv4는 EFAv3 대비 집단 통신 성능을 추가로 18% 개선한다고 제시된다. 이러한 노드 간 네트워크는 UltraClusters에서 수천 개 가속 인스턴스를 하나의 가용 영역 안에 촘촘히 배치하고 페타비트 규모의 논블로킹 네트워크로 연결하는 기반이 된다.

8. 스토리지 계층과 체크포인트·가중치·KV 캐시 관리

대규모 학습과 추론에서는 스토리지도 핵심 병목이 될 수 있다고 글은 설명한다. 분산 학습은 대규모 코퍼스를 스트리밍하고 멀티테라바이트 체크포인트를 기록해야 하며, 대규모 추론은 모델 가중치를 준비하고 KV 캐시 증가를 관리해야 한다. 이를 위해 핫 데이터에는 로컬 NVMe SSD를, 공유 고처리량 접근에는 Lustre를, 내구성 있는 보존에는 Amazon S3를 사용하는 계층적 스토리지 구조가 제시된다. 주요 다중 GPU 인스턴스에서는 인스턴스 스토어 형태의 임시 로컬 NVMe가 제공되며, 예시로 8개 3.84TB NVMe SSD로 구성된 30.72TB 원시 용량이 언급된다. Amazon FSx for Lustre는 Lustre를 완전관리형 서비스로 제공하며, 병렬 파일 시스템으로서 초당 테라바이트급 처리량, 수백만 IOPS, 밀리초 미만 지연을 제공할 수 있다고 설명된다. S3와의 Data Repository Associations는 학습 데이터의 지연 로딩과 체크포인트 자동 내보내기를 통해 내구성을 보완한다.

9. UltraServers와 확장된 NVLink 도메인

글은 통신 강도가 높은 워크로드에서는 NVLink 도메인의 크기가 중요한 제약이 될 수 있다고 설명한다. 예를 들어 MoE 모델의 expert parallelism처럼 all-to-all 토큰 디스패치가 많은 GPU에 걸쳐 발생하는 경우, 성능에 중요한 통신이 NVLink 패브릭 밖으로 나가는 빈도를 줄이는 것이 중요하다. Amazon EC2 UltraServers는 여러 구성 인스턴스를 전용 가속기 인터커넥트로 연결해 단일 EC2 인스턴스를 넘어 NVLink 도메인을 확장하는 방식으로 소개된다. AWS는 P6e-GB200 UltraServers가 NVIDIA GB200 NVL72 플랫폼에 기반하며, 하나의 NVLink 도메인 안에서 최대 72개의 Blackwell GPU와 13.4TB의 집계 HBM3e를 제공한다고 설명한다. 더 큰 규모에서는 EFA가 여러 UltraServer 작업의 노드 간 패브릭으로 남지만, 한 도메인 안의 GPU 수를 늘리면 성능 민감 통신이 NVLink 밖으로 나가는 빈도를 낮출 수 있다. 또한 Grace CPU 메모리와 Blackwell GPU HBM을 캐시 일관성 있는 NVLink-C2C로 연결해, 명시적인 호스트-장치 복사 없이 CPU 및 GPU 연결 메모리에 접근할 수 있다는 점도 제시된다.

🧾 핵심 주장 / 시사점

• 이 글의 핵심은 GPU 세대별 FLOPS 비교가 아니라, 사전학습·사후학습·추론이 모두 통신, 메모리, 스토리지, 관측 가능성의 제약을 공유한다는 시스템 관점이다.
• 대규모 모델 인프라에서는 연산 성능보다 NVLink/EFA 같은 통신 경로와 HBM·스토리지 계층이 실제 병목을 결정할 수 있으므로, 인스턴스 선택은 GPU 수만이 아니라 통신 도메인과 데이터 흐름까지 함께 봐야 한다.
• 오픈소스 프레임워크와 관리형 인프라의 결합이 전제되어 있으므로, PyTorch나 JAX 코드 최적화만으로는 충분하지 않고 Slurm/Kubernetes, Prometheus/Grafana, FSx for Lustre, S3까지 포함한 운영 설계가 중요하다.

✅ 액션 아이템

• 원문에서 강조한 핵심 변화와 이해관계자를 기준으로 Building Blocks for Foundation Model Training and Inference on AWS의 영향을 정리한다.
• 다음 의사결정이나 제품/정책 판단에 연결될 수 있는 근거를 원문 문장과 함께 기록한다.
• 기사에서 제시한 수치·사례·제약 조건을 분리해 과장 없이 검토한다.
• 후속 모니터링이 필요한 발표·제품·정책 변화가 있는지 출처 링크를 기준으로 추적한다.

❓ 열린 질문

• Unlocking AI flexibility in Europe A guide to cross region inference for EU data processing and model access Amazon Web]]" "282. 이 변화가 실제 사용자나 조직의 선택 기준을 어떻게 바꿀까?
• Introducing NVIDIA Nemotron 3 Nano Omni Long Context Multimodal Intelligence for Documents, Audio and Video Agents.md.bak action questions 2026 06 15T103532Z" "184. 이 근거가 다른 산업이나 지역에서도 동일하게 적용될 수 있을까?
• Gemma 4 QAT models Optimizing model compression for mobile and laptop efficiency" "222. 기사에서 아직 검증되지 않은 전제나 리스크는 무엇일까?
• NVIDIA Blackwell Leads on First Agentic AI Infrastructure Benchmark" "[[242. 후속 발표나 데이터가 나오면 어떤 지표를 먼저 비교해야 할까?