파운데이션 모델 인프라(Foundation Model Infrastructure)는 대규모 모델의 사전학습, 후학습, 추론을 안정적으로 돌리기 위한 하드웨어와 소프트웨어 스택이다. 단순히 GPU를 많이 붙이는 문제가 아니라, 가속기 메모리, 노드 내부·외부 네트워크, 분산 파일시스템, 잡 스케줄러, 커널 라이브러리, 추론 서빙 프레임워크, 관찰성까지 맞물려야 한다. AWS와 Hugging Face가 정리한 2026년형 스택은 이 요구사항을 네 계층으로 나눠 볼 수 있다.
왜 인프라 요구사항이 다시 수렴하는가
과거 스케일링은 주로 사전학습(pre-training) 컴퓨트 확대를 의미했다. 지금은 세 축으로 나뉜다.
| 스케일링 축 | 예시 | 인프라 압력 |
|---|---|---|
| 사전학습 | 더 큰 데이터·파라미터·학습 FLOPs | 대규모 GPU 클러스터, 체크포인트 스토리지 |
| 후학습 | SFT, RLHF, GRPO, 선호 최적화 | 반복 실험, 롤아웃 엔진, 잡 격리 |
| 테스트타임 컴퓨트 | 긴 사고, 샘플링, 검색·검증 | 저지연 추론, KV 캐시, 프리필·디코드 분리 |
세 축의 워크로드는 다르지만 기반 요구는 비슷하다. 고대역 가속 컴퓨팅, 낮은 지연의 집단 통신, 큰 체크포인트를 다루는 스토리지, 장애를 빨리 감지하는 관찰성이 모두 필요하다.
1. 인프라: 컴퓨트, 네트워크, 스토리지
AWS 기준 대규모 파운데이션 모델의 기본 블록은 EC2 P 계열 GPU 인스턴스다. H100 기반 P5, H200 기반 P5e/P5en, Blackwell B200/B300 기반 P6 계열로 이어지며, 주요 차이는 Tensor Core 처리량, HBM 용량·대역폭, NVLink와 EFA 대역폭이다.
중요한 구분은 스케일업(scale-up)과 스케일아웃(scale-out)이다.
- 스케일업: 한 노드 내부 GPU들이 NVLink/NVSwitch로 통신한다. 텐서 병렬, 파이프라인 병렬, MoE의 일부 통신이 여기서 이득을 본다.
- 스케일아웃: 여러 노드가 EFA(Elastic Fabric Adapter)로 통신한다. 수백~수천 GPU 학습에서 all-reduce, all-gather, all-to-all 병목을 줄인다.
- 스토리지: 로컬 NVMe는 핫 데이터, FSx for Lustre는 공유 고성능 파일시스템, S3는 내구성 있는 원본 데이터와 체크포인트 저장소 역할을 한다.
MoE 모델처럼 토큰을 여러 전문가 GPU로 보내는 구조에서는 all-to-all 통신이 지배적 병목이 된다. 이때 NVLink 도메인을 넓히는 UltraServer류 구성이 유리하다. 반대로 일반 데이터 병렬 학습은 EFA와 NCCL 튜닝, 체크포인트 I/O가 더 큰 영향을 줄 수 있다.
2. 자원 오케스트레이션: Slurm과 Kubernetes
512 GPU 학습 작업은 8-GPU 노드 64개를 동시에 잡아야 한다. 일부 노드만 먼저 할당되면 작업은 시작할 수 없고, 장애가 나면 전체 진행률이 영향을 받는다. 그래서 파운데이션 모델 클러스터에는 일반 서버 운영보다 엄격한 오케스트레이션이 필요하다.
| 도구 | 강점 | 적합한 환경 |
|---|---|---|
| Slurm | HPC식 배치 스케줄링, 대규모 동시 할당, 단순한 잡 모델 | 연구소·학습 클러스터 |
| Kubernetes | 서비스 운영, 멀티테넌시, 컨테이너 생태계, 추론 서빙 | 플랫폼 팀·프로덕션 운영 |
| SageMaker HyperPod | AWS 관리형 학습 클러스터, 장애 복구, EKS 연동 | AWS 기반 대규모 학습 |
Kubernetes에서는 Kueue 같은 큐·쿼터 관리, Karpenter 기반 노드 프로비저닝, 토폴로지 인식 스케줄링이 중요하다. 학습에서는 체크포인트 기반 복구뿐 아니라 피어 간 상태 복제로 복구 지연을 줄이는 체크포인트리스(checkpointless) 접근도 등장하고 있다.
3. ML 소프트웨어 스택
분산 학습·추론 스택은 아래에서 위로 쌓인다.
| 계층 | 구성 요소 | 역할 |
|---|---|---|
| 하드웨어 활성화 | NVIDIA 드라이버, EFA 드라이버, Lustre 클라이언트 | GPU·네트워크·파일시스템 접근 |
| 런타임·커널 | CUDA, CUTLASS, Triton, FlashAttention | 커널 실행, 연산 융합, HBM 트래픽 절감 |
| 통신 | NCCL, aws-ofi-nccl, libfabric | GPU 집단 통신과 EFA 연결 |
| ML 프레임워크 | PyTorch, JAX | 자동미분, 텐서 연산, 분산 추상화 |
| 상위 프레임워크 | Transformers, Accelerate, Megatron, NeMo, veRL, vLLM, SGLang | 학습·후학습·추론 워크플로 |
학습에서는 DDP, FSDP2, 텐서 병렬, 파이프라인 병렬, 전문가 병렬을 조합한다. 추론에서는 vllm-recipes와 SGLang 같은 서빙 프레임워크가 중요하다. vLLM의 PagedAttention은 KV 캐시를 가상 메모리처럼 다뤄 배치 크기와 메모리 효율을 높이고, SGLang은 프리픽스 재사용과 캐시 인식 라우팅으로 반복 요청을 최적화한다.
최근 추론 인프라에서는 프리필(prefill)과 디코드(decode)를 서로 다른 GPU 풀로 분리하는 구조도 늘고 있다. 이 경우 KV 캐시를 인스턴스 간 이동해야 하므로 집단 통신뿐 아니라 point-to-point 전송 라이브러리와 메모리 계층 설계가 중요해진다.
4. 관찰성: 병목과 장애를 빨리 찾기
수천 GPU 규모에서는 “GPU 사용률이 낮다”는 정보만으로 아무것도 고칠 수 없다. 병목은 네트워크 재전송, FSx 메타데이터 지연, NCCL 토폴로지 선택, 특정 GPU의 ECC 오류, 데이터로더 지연 중 어디에나 있을 수 있다.
관찰성은 세 범주로 나눈다.
- 인프라 지표: GPU SM activity, HBM 사용량, 전력, 온도, ECC/XID 오류, EFA 패킷·재전송, FSx 처리량
- 워크로드 지표: 학습 step time, tokens/sec, loss, 큐 대기시간, 체크포인트 시간
- 추론 지표: TTFT, inter-token latency, batch size, KV 캐시 사용량, 요청 실패율
Prometheus와 Grafana는 이 영역의 기본 조합이다. AWS에서는 Amazon Managed Service for Prometheus와 Amazon Managed Grafana로 운영 부담을 줄일 수 있다. GPU 쪽은 DCGM Exporter가 표준에 가깝고, NCCL 문제는 NCCL_DEBUG=INFO와 EFA 카운터를 함께 봐야 원인을 좁힐 수 있다.
어떤 팀에 필요한가
이 수준의 인프라는 모든 LLM 사용자에게 필요하지 않다. 다음 조건에 해당할 때 검토할 만하다.
- 수십~수천 GPU 규모의 사전학습·후학습을 운영한다.
- 자체 모델을 반복적으로 학습하고 체크포인트를 자주 저장한다.
- self-hosted-llm을 넘어서 다중 사용자 추론 서비스를 직접 운영한다.
- 비용보다 데이터 통제, 성능 튜닝, 장애 대응 능력이 더 중요하다.
- vLLM, SGLang, Megatron, NeMo, FSDP 같은 오픈소스 스택을 내부 플랫폼으로 표준화하려 한다.
단일 애플리케이션을 만드는 팀이라면 프론티어 API나 관리형 추론 서비스가 더 낫다. 파운데이션 모델 인프라는 GPU 구매 목록이 아니라, 장애와 병목을 계속 다루는 플랫폼 운영 역량에 가깝다.
관련 문서
- llm-inference — 프리필·디코드·KV 캐시 관점의 LLM 추론 원리
- self-hosted-llm — 자체 LLM 운영의 현실적 제약
- vllm-recipes — vLLM 기반 추론 실행 레시피
- inference-caching — 추론 캐싱 전략
- kv-caching — KV 캐시의 성능·메모리 트레이드오프
참고 자료
- Building Blocks for Foundation Model Training and Inference on AWS — Hugging Face Blog / Amazon (2026-05-11)