생성형 AI 추론의 구조적 한계와 AWS의 이원화 전략
수십에서 수백 기가바이트(GB)에 달하는 거대언어모델(LLM)을 상용 서비스에 배포할 때 가장 큰 문제는 컴퓨팅 자원의 낭비와 긴 지연시간입니다. 기존 인프라 환경에서는 콜드 스타트 시 이미지와 가중치를 내려받는 데 수 분이 소요되고, 기존 로드 밸런서는 GPU 내부의 KV 캐시 점유율이나 큐 상태를 감지하지 못한 채 라운드로빈(Round-robin) 방식으로 트래픽을 분배해 특정 GPU에 부하가 집중되는 병목이 발생했습니다.
AWS는 이러한 문제를 해결하기 위해 인프라 관리 부담을 최소화하는 완전 관리형 세이지메이커 AI 엔드포인트(Managed Endpoints)와 쿠버네티스 네이티브 제어권을 제공하는 세이지메이커 하이퍼팟 추론(SageMaker HyperPod Inference)의 두 가지 경로에 걸쳐 총 13개 이상의 신규 기능을 발표했습니다.
- 추론 최적화 추천 및 벤치마킹
- 인스턴스 풀 구성 및 폴백
- 접두사/GPU 상태 기반 지능형 라우팅
- 실시간 OpenTelemetry 관측성 확보
---
관리형 엔드포인트: 배포 속도와 호환성 극대화
2026년 공개된 관리형 세이지메이커 엔드포인트 기능들은 모델 배포 준비부터 스케일아웃, 트래픽 라우팅까지 운영 전반의 오버헤드를 줄이는 데 집중되었습니다.
1. 추론 권장 사항 및 자동 벤치마킹
모델 크기, 메모리 요구사항을 분석한 뒤 EAGLE 3.0 투기적 디코딩(Speculative decoding), 커널 튜닝, 텐서 병렬성을 적용해 최적 인스턴스를 도출합니다. NVIDIA AIPerf 기반 테스트를 거쳐 TTFT(첫 토큰 시간), ITL(토큰 간 지연시간), 비용 지표를 포함한 모델 패키지를 생성하며, GPT-OSS-20B 벤치마크 기준 동일 지연시간에서 2배의 처리량(초당 토큰 수)을 기록했습니다.
2. 용량 인지형 인스턴스 풀(Capacity-aware instance pools)
단일 인스턴스 유형 고정으로 인한 배포 실패를 방지하기 위해 최대 5개의 인스턴스 유형을 우선순위 리스트로 지정할 수 있습니다. 용량 부족 시 즉각 대체 인스턴스로 넘어가며, 축소(Scale-in) 시에는 대체 인스턴스부터 먼저 제거되어 선호 하드웨어 비중을 유지합니다.
3. OpenAI 호환 API 및 컨테이너 캐싱
기존 SigV4 서명 대신 12시간 유효한 베어러(Bearer) 토큰을 지원하고 `/openai/v1` 엔드포인트를 노출하여 엔드포인트 URL 변경만으로 기존 OpenAI SDK 코드를 그대로 사용할 수 있습니다. 또한 10GB 이상의 대용량 서빙 컨테이너를 새 인스턴스에 사전 로드하는 컨테이너 캐싱 기술을 적용했습니다.
| 모델 및 인스턴스 | 컨테이너 용량 | 시작 지연시간 (기존 → 적용 후) | 단축률 |
|---|---|---|---|
| Qwen3-8B (ml.g6.2xlarge) | 17.7 GB (LMI) | 525초 → 258초 | 51% 감소 |
| Qwen3-8B 모델 다운로드 시간 | - | 168초 → 77초 | 대역폭 경합 해소 |
4. 접두사 인식 라우팅(Prefix-aware routing)
시스템 프롬프트나 대화 기록처럼 반복되는 프롬프트의 지문을 식별해 동일 인스턴스로 라우팅함으로써 KV 캐시 재사용률을 극대화합니다. Llama 3.1 70B 모델(8,000토큰 접두사 조건) 테스트 결과, KV 캐시 적중률이 약 25%에서 82%로 상승했고 P50 TTFT는 71~77%, P90 TTFT는 33~37% 감소했습니다. 라우팅 오버헤드는 요청당 1.3~1.9밀리초(ms)에 불과합니다.
---
세이지메이커 하이퍼팟 추론 게이트웨이의 GPU 인지 라우팅
쿠버네티스 환경(EKS)에서 대규모 GPU 클러스터를 직접 운영하는 팀을 위해 세이지메이커 하이퍼팟 추론 게이트웨이(HyperPod Inference Gateway)가 도입되었습니다. 기본 EKS 로드 밸런서의 단순 라운드로빈 분배로 인해 첫 토큰 지연시간이 4초 이상 치솟고 GPU 자원이 불균등하게 낭비되던 문제를 근본적으로 해결합니다.
"챗봇 사용자가 첫 번째 토큰을 받기까지 4.4초를 기다려야 했던 환경이 이제 800ms 미만으로 단축됩니다."
하이퍼팟 추론 게이트웨이는 애플리케이션이나 모델 서버 코드를 변경하지 않고 단일 EKS 관리형 애드온(`amazon-sagemaker-hyperpod-inference`) 및 CRD(`InferenceGatewayConfig`) 설정만으로 배포됩니다.
``` [클라이언트 요청] (OpenAI 호환 포맷) │ ▼ [L7 프록시 / Body-Based Router] (모델 식별 및 분기) │ ▼ [엔드포인트 피커 (EPP)] ── 프로메테우스 실시간 메트릭 수집
- KV 캐시 점유율 분석
- 큐 깊이(대기열) 확인
- LoRA 어댑터 상주 여부 확인
- 접두사 캐시 적중률 평가
│ ▼ [최적 GPU Pod로 요청 전달] ```
이 구조를 통해 미세조정된 LoRA 어댑터 요청 시 해당 어댑터가 이미 GPU 메모리에 올라가 있는 파드로 우선 전달함으로써 어댑터 스왑 지연을 방지합니다. 또한 향후 출시될 Tier 2 글로벌 추론 라우터(Global Inference Router, GIR)를 통해 멀티 클러스터 및 리전 간 장애 복구, 전역 레이트 리밋, 비용 기반 트래픽 제어가 지원될 예정입니다.
---
하이퍼팟 게이트웨이 벤치마크 및 이기종 GPU 대응
8B부터 235B 파라미터 규모의 모델을 대상(H100 기반 p5.48xlarge 및 A10G 기반 g5 인스턴스)으로 테스트한 결과, 하드웨어 구성이 이기종으로 혼합되어 있거나 버스트성 트래픽이 발생할 때 성능 개선 폭이 가장 컸습니다.
- 이기종 GPU 혼합 환경: 메모리가 작은 인스턴스가 포화 상태일 때 라운드로빈은 지속적으로 요청을 보내 장애를 유발하지만, 추론 게이트웨이는 여유 인스턴스로 트래픽을 즉시 재배치합니다.
- 버스트 트래픽 환경: 개별 복제본이 유휴와 과부하를 오갈 때 트래픽을 분산해 지연시간 급증을 억제합니다.
- 공유 프롬프트 워크로드: 프롬프트 접두사가 이미 캐시된 파드를 우선 탐색하여 중복 계산을 줄입니다.
---
비동기 추론 및 OpenTelemetry 기반 관측성 강화
인프라 모니터링과 비동기 호출 아키텍처 역시 크게 간소화되었습니다.
- 인라인 페이로드 지원(Async inference inline payloads): 기존에는 수백 바이트의 작은 입력값도 S3 버킷에 먼저 업로드한 뒤 호출해야 했으나, 이제 `InvokeEndpointAsync` API에서 최대 128,000바이트까지 직접 Body 파라미터로 전달할 수 있어 S3 PUT 비용과 네트워크 홉을 줄였습니다.
- 기본 OpenTelemetry 관측성: 엔드포인트 생성 시 기본 활성화되며 2분 내에 100개 이상의 상세 추론 메트릭이 수집됩니다. TTFT, ITL, KV 캐시 사용률, 큐 깊이, GPU 온도/메모리 및 콜드 스타트 구간별 소요 시간(모델 다운로드, GPU 로드, 컨테이너 시작)을 클라우드워치 대시보드와 PromQL 호환 엔드포인트를 통해 실시간 분석할 수 있습니다.