AWS에서 기초 모델 트레이닝 및 추론을 위한 빌딩 블록

AWS의 파운데이션 모델(FM) 학습 및 추론 인프라는 크게 컴퓨팅(EC2 Trn1/Trn2, P5/P5e — Trainium 및 NVIDIA H100/H200 기반), 네트워킹(EFA, SRD 프로토콜 기반 초저지연 통신), 스토리지(FSx for Lustre, S3 Express One Zone), 그리고 오케스트레이션(SageMaker HyperPod, EKS) 계층으로 구성된다. 수천 개의 GPU/Trainium 가속기를 클러스터로 묶을 때 핵심은 단순 연산 성능이 아니라 collective communication(AllReduce, AllGather)의 효율인데, AWS는 EFA(Elastic Fabric Adapter)와 NCCL 플러그인을 통해 OS 커널을 우회한 RDMA 유사 통신을 제공해 분산 학습의 스케일링 효율을 개선한다. 추론 측에서는 Inferentia2, Bedrock의 매니지드 엔드포인트, 그리고 SageMaker의 컨테이너 기반 서빙을 조합해 배치/온디맨드 워크로드를 분리하며, 최근에는 GB200 NVL72 같은 차세대 GPU도 도입 중이다.

개발자 관점에서 가장 큰 변화는 "모델 학습은 더 이상 단일 머신 문제가 아니다"라는 점이다. 100B+ 파라미터 모델을 학습하려면 Tensor Parallel, Pipeline Parallel, FSDP 같은 분산 전략을 PyTorch 코드에 직접 녹여야 하고, 노드 장애가 일상적으로 발생하므로 체크포인트 빈도와 자동 재시작 로직 설계가 비즈니스 비용에 직결된다. SageMaker HyperPod의 resilience 기능, EKS의 Karpenter 기반 노드 풀, 그리고 S3 Express One Zone으로의 체크포인트 오프로드는 이런 운영 부담을 줄여주는 빌딩 블록이지만, 한국 엔지니어 입장에서는 서울 리전(ap-northeast-2)에 일부 최신 인스턴스가 도입되지 않거나 쿼터 확보가 어려워 us-east-1 또는 us-west-2를 함께 고려해야 하는 현실적 제약이 있다.

실제 업무에 적용한다면 우선 워크로드 성격을 명확히 구분하는 것이 좋다. 파인튜닝/도메인 어댑테이션 수준이라면 Bedrock Custom Models나 SageMaker JumpStart로 충분하고, 사전학습부터 직접 한다면 HyperPod + Trainium 조합의 비용 효율성이 H100 대비 30~40% 우위에 있다는 점을 검토해볼 만하다. 다만 Trainium은 PyTorch XLA 컴파일러(Neuron SDK)에 의존하므로 커스텀 CUDA 커널이나 FlashAttention 변형을 쓰는 코드라면 이식 비용이 크다. 추론 비용 최적화는 Inferentia2 + vLLM/TGI 조합, 또는 Bedrock의 토큰 단가 모델 중 선택지를 비교 분석해야 한다.

당장 액션 아이템은 세 가지다. 첫째, 회사 워크로드의 토큰 처리량과 P99 레이턴시 SLO를 측정해 "자체 호스팅 vs Bedrock" 손익분기점을 산출할 것. 둘째, 분산 학습을 시작한다면 EFA가 지원되는 인스턴스 타입과 placement group 설정을 IaC(Terraform/CDK)로 먼저 표준화할 것. 셋째, GPU 쿼터는 신청부터 승인까지 수일~수주가 걸리므로 PoC 단계에서 미리 확보하고, 비용 폭주를 막기 위해 AWS Budgets와 Cost Anomaly Detection을 가속기 인스턴스 태그 단위로 설정하는 것이 안전하다.