Introducing Amazon SageMaker HyperPod Inference Gateway

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Amazon SageMaker HyperPod Inference Gateway는 실시간 GPU 상태에 따라 추론 요청을 배분하는 Kubernetes 네이티브 라우팅 시스템으로, 애플리케이션 코드 변경 없이 지연과 GPU 자원 낭비를 줄이며 현재 클러스터 단위 Tier 1을 제공한다.

📌 핵심 요약

• 기본 Kubernetes 라운드로빈·최소 연결 라우팅은 KV 캐시, 요청 대기열, LoRA 어댑터 적재 상태를 반영하지 못해 일부 파드에 요청이 쌓이고 GPU 유휴 용량과 지연 급증이 발생한다.
• Amazon SageMaker HyperPod Inference Gateway는 단일 EKS 관리형 애드온으로 설치되며, Envoy Gateway·Body-Based Router·Endpoint Picker를 통해 모델별 분기와 실시간 GPU 지표 기반 파드 선택을 수행한다.
• 도입에는 애드온 설치, 모델 파드 라벨 지정, InferenceGatewayConfig 적용이 필요하며, 기존 OpenAI 호환 클라이언트와 모델 서버의 코드 변경 없이 다중 모델 및 LoRA 어댑터 라우팅을 지원한다.
• AWS가 8B~235B 모델 4종을 기본 라우팅 설정으로 시험한 결과, 혼합 GPU의 Qwen3-32B는 라운드로빈 대비 TTFT P95가 98% 감소하고 처리량이 50% 증가했다. 균일한 GPU 구성과 안정적인 트래픽에서는 성능 차이가 실행 간 변동 범위 안에 머물렀다.
• Tier 1은 추론 애드온 지원 리전에서 현재 이용 가능하다. 다중 클러스터·리전 라우팅을 담당하는 Tier 2의 Global Inference Router(GIR), 카나리 트래픽 분할, 우선순위별 흐름 제어는 향후 기능으로 소개됐다.

🧩 주요 포인트

1. GPU 내부 상태를 반영한 가중치 기반 파드 선택 → 하드웨어와 부하가 불균일할 때 요청 집중을 완화하며, 개선 폭은 워크로드 조건에 좌우된다.
2. OpenAI 호환 인터페이스와 InferenceGatewayConfig 중심 구성 → 애플리케이션 코드 변경 부담을 줄이면서 모델·어댑터별 라우팅을 인프라 계층에서 처리한다.
3. 현재 제공되는 Tier 1과 예정된 Tier 2의 역할 분리 → 클러스터 내부 최적화와 다중 클러스터·리전 장애 대응의 제공 범위를 구분해야 한다.

🧠 상세 정리

1. 기본 라우팅이 만드는 GPU 낭비와 지연

원문은 대규모 LLM 운영에서 GPU 비용이 높은 상황을 기본 Kubernetes 로드 밸런서가 악화시킨다는 문제 제기로 시작한다. 라운드로빈과 최소 연결 알고리즘은 파드의 KV 캐시 포화 여부, 긴 컨텍스트 생성 작업의 진행 상태, 요청에 필요한 LoRA 어댑터의 메모리 적재 여부를 알지 못한다. 이 때문에 유휴 용량이 남아 있어도 바쁜 파드 뒤로 요청이 쌓이고, 트래픽 급증 시 첫 토큰 지연이 4초 이상으로 치솟으며 GPU 사용률도 불균일해진다고 설명한다. 운영자가 이를 과도한 자원 할당으로 보완하면 실제 작업을 하지 않는 GPU에도 비용이 발생한다는 주장이다. 도입부는 첫 토큰 지연을 최대 82% 줄인다고 홍보하고 4.4초에서 800ms 미만으로 단축되는 예를 들지만, 뒤의 벤치마크 표에서는 별도 조건과 백분위 지표에 따라 더 큰 감소율도 제시한다.

2. 클러스터 내부에서 요청을 고르는 Tier 1

Amazon SageMaker HyperPod Inference Gateway는 기존 HyperPod/EKS 클러스터에 단일 관리형 애드온으로 설치되는 GPU 인지형 라우팅 시스템이다. 현재 제공되는 Tier 1은 오픈소스 Gateway API Inference Extension을 기반으로 하며, Envoy Gateway가 들어오는 HTTPS 트래픽을 종료하고 클러스터별 단일 비공개 엔드포인트를 제공한다. Body-Based Router는 OpenAI 호환 요청 본문의 model 필드를 읽어 적절한 모델 풀로 보내고, Endpoint Picker는 각 모델 서빙 파드의 실시간 Prometheus 지표를 받아 백엔드를 선택한다. 선택에는 KV 캐시 사용률, 대기열 깊이, LoRA 어댑터 적재 여부, 프리픽스 캐시 적중률, 실행 중인 요청 수가 가중치 점수로 반영된다. 각 점수의 가중치는 조정할 수 있어 지연에 민감한 채팅과 처리량 중심 배치처럼 서로 다른 워크로드에 맞춰 라우팅 동작을 바꿀 수 있다.

3. 애드온 설치부터 OpenAI 호환 요청까지

원문은 도입을 5분 안에 시작할 수 있는 과정으로 소개하며, 단일 애드온과 선언형 InferenceGatewayConfig 리소스를 사용한다고 설명한다. 설치 예시는 amazon-sagemaker-hyperpod-inference 애드온의 v2.0.0-eksbuild.1 버전에서 inferenceGateway와 inferenceOperator를 활성화한다. 이어 기존 모델 서버 배포에 app: vllm-llama 라벨을 붙이고, 구성 리소스에서 llama-3.1-70b 모델과 해당 라벨, 대상 포트 8000, llm-d 스케줄러를 연결한다. 클라이언트는 게이트웨이의 /v1/chat/completions 경로로 model과 messages 등이 담긴 표준 OpenAI 호환 요청을 전송한다. 이 방식에는 사이드카나 서비스 메시, 애플리케이션 코드 및 SDK 변경이 필요 없으며, 추론 트래픽에 SigV4 서명도 요구하지 않는다고 명시한다.

4. 다중 모델과 LoRA 어댑터의 요청 배분

한 클러스터에서 여러 모델을 운영할 때는 구성에 스케줄러를 여러 개 정의하면 Body-Based Router가 요청 본문의 model 값에 따라 올바른 모델 풀을 선택한다. 따라서 단일 게이트웨이로 여러 모델을 제공하면서 애플리케이션에 모델별 라우팅 로직을 추가할 필요가 없다는 설명이다. 공유 기반 모델 위에서 미세 조정된 LoRA 어댑터를 제공하는 경우에는 요청한 어댑터가 이미 GPU 메모리에 올라간 파드를 우선한다. Endpoint Picker의 LoRA Affinity Scorer가 이러한 적재 상태를 식별하며, 원문은 이를 통해 비용이 큰 어댑터 교체 지연을 제거할 수 있다고 설명한다. 다만 어느 파드에도 해당 어댑터가 적재되지 않았다면 사용 가능한 용량이 가장 많은 파드로 요청을 보내 빠른 적재를 유도하므로, 모든 요청에서 기존 어댑터 적재 상태를 활용할 수 있다는 뜻은 아니다.

5. 장애 대응과 계층별 관측 지표

파드 장애에 대해서는 Endpoint Picker가 지표가 오래된 파드를 제외하고 정상 파드로 요청을 보내며, 지표 수집이 재개되면 자동으로 복구하는 동작을 설명한다. 모델 풀의 용량이 소진되면 Retry-After 헤더를 포함한 HTTP 429를 반환하고, 용량 추가는 오토스케일링이 맡는다. 장애 대응 표에는 GIR이 오래된 하트비트를 감지해 클러스터 장애 시 35초 이내에 트래픽을 전환하고 재편입 시 점진적으로 부하를 늘리는 동작도 제시된다. 리전 장애는 자동 교차 리전 라우팅으로 지연은 늘지만 가용성에는 영향이 없다고 기술하나, GIR 자체는 출시 예정인 Tier 2이므로 현재 Tier 1의 제공 범위와 구분해야 한다. 관측 항목은 파드의 KV 캐시·대기열·어댑터 상태, 풀의 요청 수·소요 시간·토큰 수, 클러스터의 평균 KV 캐시·오류율·P99 지연, 전체 클러스터 집합의 라우팅 결정·장애 전환·속도 제한 발생으로 나뉘며 Prometheus, Grafana, Amazon CloudWatch를 통해 제공한다고 설명한다.

6. 벤치마크 구성과 개선이 발생하는 조건

AWS는 8B부터 235B까지의 모델 4종을 p5.48xlarge의 H100과 g5의 A10G 인스턴스에 배포해 비교했다고 밝힌다. 모든 트래픽은 실제 운영 요청 경로에 맞춘 내부 Application Load Balancer를 통과했으며, 부하 생성 클라이언트와 모델 서버를 별도 노드 그룹에 두어 높은 동시성에서도 자원 경합이 없도록 구성했다. 결과는 모두 게이트웨이 기본 라우팅 설정을 사용하고 동일한 모델 복제본의 Kubernetes 라운드로빈을 기준으로 측정했다. 혼합 GPU 환경에서는 메모리가 작은 인스턴스의 포화를 감지하고, 급증하는 트래픽에서는 여유 용량이 있는 파드로 요청을 보내는 효과를 시험했다. 공통 프롬프트 프리픽스를 사용하는 대화와 문서 질의응답에서는 캐시가 있는 파드를 선택해 중복 연산을 줄이는 시나리오를 평가했다. 반면 GPU 구성이 완전히 균일하고 트래픽도 일정하면 복제본 사용률이 비슷해져 라운드로빈과 대등한 성능을 보이며, 원문은 운영 환경의 불균일성이 클수록 이점이 커진다고 정리한다.

7. 모델과 부하별 성능 수치 및 한계

혼합 GPU 조건에서 Llama-3.1-8B는 첫 토큰 도착 시간인 TTFT의 P95와 P99가 각각 97% 감소하고 처리량이 8% 증가했으며, Qwen3-32B는 P95가 98%, P99가 97% 감소하고 처리량이 50% 증가했다. 급증하는 트래픽에서 Llama-3.1-70B는 TTFT P95가 94%, P99가 98% 감소했으며 처리량은 12% 증가했다. 같은 급증 조건의 Qwen3-235B는 TTFT P99가 89% 감소했지만 P95와 처리량은 비교 가능한 수준이었다. 공통 프롬프트 프리픽스를 사용한 Llama-3.1-8B는 TTFT P95가 26%, P99가 43% 감소했고 처리량은 비교 가능한 수준으로 제시됐다. 균일한 GPU 구성과 안정적인 트래픽의 Qwen3-235B에서는 세 지표 모두 비교 가능한 수준이었으며, 원문은 이 표현을 실행 간 변동 범위 안의 차이라고 정의하므로 모든 환경에서 동일한 개선을 기대할 근거는 아니다.

8. Kubernetes 통합, 현재 제공 범위와 향후 기능

원문은 이 게이트웨이가 Kubernetes 옆에 별도 플랫폼을 추가하는 방식이 아니라 공식 Gateway API와 Inference Extension에 기반한 Kubernetes 네이티브 구성이라는 점을 강조한다. 단일 InferenceGatewayConfig CRD로 라우팅 구성을 선언하며, vLLM·SGLang·TGI 등 OpenAI 호환 모델 서버와 기존 kubectl·GitOps·Helm·ArgoCD 도구를 활용할 수 있다고 설명한다. 설치와 업그레이드, 롤백은 aws eks CLI 또는 콘솔의 EKS 애드온 수명주기로 관리하고, 현재 Tier 1은 추론 애드온을 사용할 수 있는 리전에서 제공된다. 출시 예정인 Tier 2의 Global Inference Router는 중앙 집중형 게이트웨이, 다중 클러스터·리전 라우팅, 전역 속도 제한, 비용 계층을 고려한 트래픽 배분을 추가하며 각 클러스터의 Tier 1 위에서 동작한다. 추가 예고 기능으로는 InferenceModelRewrite CRD를 이용한 신규 모델 버전으로의 일정 비율 카나리 트래픽 분할과 Critical·Standard·Sheddable 등급별 요청 수용 제어가 제시된다.

🧾 핵심 주장 / 시사점

• 핵심 개선 요인은 요청 수를 고르게 나누는 데서 나아가 GPU 메모리·대기열·캐시 상태에 맞춰 요청을 배치하는 데 있으며, 불균일한 환경에서 그 가치가 커진다.
• 첫 토큰 지연과 처리량의 개선은 항상 함께 나타나지 않는다. Qwen3-235B의 급증 트래픽 결과는 처리량 차이가 실행 간 변동 범위에 있어도 P99 지연은 크게 줄어들 수 있음을 보여준다.
• 애플리케이션 코드 변경이 없다는 설명은 인프라 설정까지 불필요하다는 뜻은 아니다. 애드온 설치, 파드 라벨 지정, 선언형 구성 적용이 필요하며 전역 장애 대응은 예정된 GIR의 범위를 따로 확인해야 한다.

✅ 액션 아이템

• 혼합 GPU와 트래픽 불균일 여부를 기준으로 Amazon SageMaker HyperPod Inference Gateway의 적용 효과 검토.
• OpenAI 호환 인터페이스, 모델 파드 라벨, InferenceGatewayConfig를 기준으로 기존 환경의 도입 조건 확인.
• 현재 제공되는 Tier 1과 예정된 Tier 2를 구분해 다중 클러스터·리전 라우팅 요구의 충족 범위 검토.

❓ 열린 질문

• 대상 워크로드의 GPU 구성과 트래픽은 불균일한가, 아니면 성능 차이가 실행 간 변동 범위에 머문 균일한 GPU 구성과 안정적인 트래픽에 가까운가?
• 기존 OpenAI 호환 클라이언트와 모델 서버는 모델 파드 라벨 및 InferenceGatewayConfig 구성으로 필요한 모델·어댑터별 라우팅을 지원할 수 있는가?
• 현재 제공되는 Tier 1만으로 요구를 충족할 수 있는가, 아니면 예정된 Tier 2의 다중 클러스터·리전 라우팅이 필요한가?