AWS, GPU 인식 라우팅을 위한 SageMaker HyperPod Inference Gateway를 출시

Amazon Web Services는 2026년 9월 18일에 Amazon SageMaker HyperPod Inference Gateway를 발표했으며, 이는 기존 HyperPod 인프라에서 Amazon EKS용 단일 관리형 애드온으로 배포되는 Kubernetes 기반 GPU 인식 라우팅 시스템으로 대규모 언어 모델 추론을 지원합니다. AWS는 이 게이트웨이가 첫 토큰 지연 시간을 최대 82%까지 줄일 수 있다고 밝혔습니다.

게이트웨이 뒤의 라우팅 문제

AWS에 따르면, 라운드 로빈 및 최소 연결과 같은 기본 Kubernetes 로드 밸런싱 알고리즘은 GPU 상태를 파악할 수 없습니다. 즉, 어떤 파드가 KV 캐시를 포화 상태에 도달했는지, 어떤 파드가 긴 컨텍스트 생성 중인지, 그리고 요청에 필요한 LoRA 어댑터가 메모리에 이미 로드되어 있는지 알 수 없습니다. 회사는 바쁜 파드 뒤에 요청이 쌓이고 유휴 용량이 사용되지 않으며, 트래픽 급증 시 첫 토큰 지연 시간이 4초를 초과하고, 활용도가 고르지 않고 예측 불가능해져 운영자가 이를 보완하기 위해 과다 프로비저닝한다는 점을 지적했습니다. AWS는 챗봇 사용자가 첫 토큰을 받기 위해 4.4초를 기다리는 대신 800밀리초 이하로 확인하는 시나리오를 설명했습니다.

2계층 아키텍처

이 게이트웨이는 Kubernetes 기반 기본 요소를 활용한 2계층 설계를 사용합니다. AWS는 실시간 GPU 신호를 이용해 모든 추론 요청을 가장 적합한 파드에 배정한다고 밝혔습니다. Tier 1은 각 HyperPod 또는 EKS 클러스터에 amazon-sagemaker-hyperpod-inference 애드온으로 직접 설치되며, 모두 오픈소스 Gateway API Inference Extension을 기반으로 하는 세 가지 구성 요소로 이루어집니다. 레이어-7 프록시인 Envoy Gateway는 들어오는 HTTPS 트래픽을 종료하고 클러스터당 단일 프라이빗 엔드포인트를 노출합니다. Body-Based Router는 들어오는 OpenAI 호환 요청 본문을 검사해 모델 필드를 추출하고, 해당 모델 풀로 요청을 라우팅하여 하나의 게이트웨이가 여러 모델을 서비스할 수 있게 합니다.

Endpoint Picker는 모든 모델 서빙 파드의 실시간 Prometheus 메트릭을 수집하고 KV 캐시 활용도, 대기열 깊이, LoRA 어댑터 상주 여부, 프리픽스 캐시 적중률, 진행 중인 요청 등을 평가하는 가중 점수 알고리즘을 적용합니다. 각 스코어러는 설정 가능한 가중치를 가지고 있어, 지연 시간에 민감한 채팅과 처리량에 최적화된 배치와 같은 특정 워크로드에 맞게 라우팅 동작을 조정할 수 있습니다.

Tier 2인 Global Inference Router는 곧 출시될 예정이라고 명시되어 있습니다. AWS는 다중 클러스터 및 지역에 걸친 플릿 전체 조정, 클러스터 간 장애 복구, 전역 속도 제한, 비용 인식 트래픽 셰이핑을 추가할 것이라고 밝혔습니다. Tier 2는 Tier 1 위에 구축되며, 각 클러스터의 개별 게이트웨이는 여전히 로컬 라우팅을 담당합니다.

배포, 장애 처리 및 가시성

배포는 단일 aws eks create-addon 명령과 모델 및 라우팅 동작을 정의하는 선언형 InferenceGatewayConfig 커스텀 리소스 하나로 구성되며, 기존 모델 서버 배포는 파드 라벨을 통해 탐지됩니다. AWS는 설치에 사이드카, 서비스 메시, 애플리케이션 코드 변경이 필요 없다고 밝혔습니다. 게이트웨이는 HTTP를 통해 표준 OpenAI 호환 엔드포인트를 노출합니다; AWS에 따르면 기존 클라이언트 코드는 그대로 동작하며 SDK 변경이나 추론 트래픽에 대한 SigV4 서명도 필요하지 않습니다.

공유 기본 모델에 파인튜닝된 LoRA 어댑터를 제공하는 워크로드의 경우, Endpoint Picker의 LoRA Affinity Scorer는 요청된 어댑터가 이미 GPU 메모리에 상주하는 파드로 어댑터 요청을 라우팅합니다; 만약 해당 어댑터가 로드된 파드가 없으면 가장 가용 용량이 큰 파드로 요청이 전달됩니다. AWS는 이를 통해 어댑터 교체 지연 시간이 사라진다고 밝혔습니다.

문서화된 장애 동작은 파드 장애, 풀 고갈, 클러스터 장애 및 지역 장애를 포함합니다. 파드 장애 발생 시, Endpoint Picker는 오래된 메트릭을 가진 파드를 제외하고 정상 파드로 라우팅하며, 메트릭이 재개되면 자동으로 복구됩니다. 풀 고갈 시, 게이트웨이는 Retry-After 헤더와 함께 HTTP 429를 반환하고 자동 스케일링이 용량을 추가합니다. 클러스터 장애 시, Global Inference Router는 오래된 하트비트를 감지하고 35초 이내에 트래픽을 재지정하며, 클러스터가 복구될 때 점진적으로 트래픽을 증가시킵니다. 지역 장애 시, 교차 지역 라우팅이 자동으로 활성화되며, AWS는 이 경우 지연 시간은 증가하지만 가용성에는 영향을 미치지 않는다고 밝혔습니다.

게이트웨이는 파드, 풀, 클러스터 및 플릿 수준에서 메트릭을 방출합니다: 파드 수준에서는 Prometheus를 통해 KV 캐시 활용도, 대기열 깊이, 진행 중인 요청 및 어댑터 상주 정보를 제공합니다; 풀 수준에서는 Prometheus와 Grafana를 통해 요청 총량, 지속 시간 히스토그램 및 토큰 수를 제공합니다; 클러스터 수준에서는 Amazon CloudWatch를 통해 평균 KV 캐시, 오류율 및 P99 지연 시간을 제공합니다; 플릿 수준에서는 CloudWatch를 통해 라우팅 결정, 장애 복구 이벤트 및 속도 제한 히트 수를 제공합니다.

AWS가 보고한 벤치마크 결과

AWS는 H100 GPU가 탑재된 p5.48xlarge 인스턴스와 A10G GPU가 탑재된 g5 인스턴스에서 8B에서 235B 파라미터에 이르는 네 가지 모델을 벤치마크했다고 밝혔습니다. 모든 트래픽은 내부 Application Load Balancer를 통해 라우팅되어 실제 프로덕션 요청 경로와 일치했으며, 전용 클라이언트 노드 그룹이 제어된 부하를 생성하고 모델 서버는 별도의 서버 노드 그룹으로 격리되었습니다. 모든 결과는 튜닝 없이 게이트웨이의 기본 라우팅 구성을 사용했으며, 동일한 모델 복제본에 대한 Kubernetes 라운드 로빈 기준과 비교하여 측정되었습니다.

보고된 결과에서, 혼합 세대 GPU 플릿은 Llama-3.1-8B에 대해 최초 토큰 도달 시간(P95 및 P99 지연)을 각각 97% 감소시켰으며, 처리량이 8% 증가했고, Qwen3-32B에 대해서는 각각 98%와 97% 감소와 처리량 50% 증가를 보였다. 트래픽이 급증하는 상황에서는 Llama-3.1-70B가 P95와 P99 지연을 각각 94%와 98% 감소시키고 처리량을 12% 높였으며, Qwen3-235B는 유사한 P95 지연과 P99가 89% 낮아졌다. 프롬프트 접두어를 공유할 경우, Llama-3.1-8B의 P95와 P99 지연이 각각 26%와 43% 감소했다.

AWS는 트래픽이 일정한 완전 균일 플릿에서는 게이트웨이가 라운드 로빈과 동등한 성능을 보이며, 비교 가능한 결과를 실행 간 변동 범위 내 차이로 정의했다고 밝혔다. 회사는 라운드 로빈이 가장 어려움을 겪는 상황, 즉 혼합 하드웨어, 급증하는 수요, 그리고 프롬프트 접두어가 공유되는 경우에 개선 효과가 가장 크다고 말했다.

가용성 및 로드맵

AWS는 게이트웨이가 Kubernetes Gateway API 및 해당 추론 확장과 호환되며, 단일 사용자 정의 리소스 정의를 통해 구성되고, vLLM, SGLang, TGI를 포함한 OpenAI 호환 모델 서버와 호환된다고 설명한다. 관리 작업은 kubectl, GitOps, Helm, ArgoCD를 통해 수행되며, 설치, 업그레이드 및 롤백은 EKS 애드온 수명 주기를 통해 처리된다.

Tier 1 클러스터당 라우팅은 2026년 9월 18일부터 추론 애드온이 제공되는 지역에서 사용할 수 있다. Global Inference Router 외에도 AWS가 제시한 로드맵 항목에는 카나리 트래픽 분할이 포함되며, 이는 InferenceModelRewrite 사용자 정의 리소스를 사용해 트래픽의 일정 비율을 새로운 모델 버전으로 라우팅한다. 또한 흐름 제어 기능은 요청을 Critical, Standard, Sheddable로 분류하고 밴드별 입장 제어를 제공한다.