GPU를 더 사지 않고 첫 토큰을 82% 단축했다…라우팅의 효과
AWS의 2026년 9월 18일 공식 발표 에 따르면 Amazon SageMaker HyperPod Inference Gateway는 같은 모델 복제본을 사용한 비교에서 첫 토큰 지연시간을 최대 82%, 4.4초에서 800ms 미만으로 줄였다. Kubernetes 라운드로빈 대신 GPU와 모델 서버의 실시간 상태를 읽어 요청을 배치한 결과로, 비교 과정에서 GPU를 추가한 것은 아니다.
이번에 제공되는 것은 HyperPod의 Amazon EKS 클러스터 안에서 파드를 선택하는 로컬 라우팅 계층이다. 독립 기술 분석 도 현재 출시된 Tier 1과 향후 교차 클러스터·교차 리전 조정을 담당할 Global Inference Router를 구분하면서, 성능 수치는 AWS가 보고한 시험 결과이지 모든 모델과 트래픽에 적용되는 독립적인 보장은 아니라고 짚었다.
라운드로빈이 놓치는 GPU 내부 상태를 읽는다
일반적인 라운드로빈은 사용 가능한 백엔드에 요청을 차례로 보내지만 각 요청이 요구하는 계산량이나 파드 내부 상태는 알지 못한다. 한 파드가 긴 문맥을 처리하거나 생성 작업을 계속하는 동안에도 새 요청이 그 뒤에 배치될 수 있고, 상대적으로 한가한 GPU는 충분히 활용되지 않을 수 있다.
Inference Gateway는 먼저 Body-Based Router가 OpenAI 호환 요청 본문의 model 값을 읽어 요청에 맞는 모델 풀을 찾는다. 이어 모델별 Endpoint Picker가 후보 파드의 대기열 깊이, 실행 중인 요청 수와 KV 캐시 사용률을 평가해 실제 백엔드를 선택한다.
접두어 캐시와 LoRA 어댑터의 위치도 선택 신호다. 동일한 프롬프트 접두어가 이미 캐시된 파드로 요청을 보내면 반복되는 전처리 계산을 줄일 수 있고, 필요한 LoRA 어댑터가 GPU 메모리에 상주한 파드를 고르면 다른 파드에서 어댑터를 불러오거나 교체하는 지연을 피할 수 있다.
각 신호에는 조정 가능한 가중치가 적용된다. 캐시 일치도가 높더라도 대기열이 깊거나 실행 중인 요청이 많다면 다른 파드가 선택될 수 있어, 캐시 재사용과 부하 분산 가운데 하나만 고정적으로 우선하는 구조는 아니다.
헤드라인 수치는 상한 사례다
개선의 원인은 모델 연산 자체가 빨라진 것이 아니라 이미 존재하는 여유 용량을 더 정확히 찾은 데 있다. 요청 수만 균등하게 나누는 기준선과 달리 게이트웨이는 대기열과 캐시 상태가 불균형한 파드를 피함으로써 첫 토큰이 나오기 전의 대기시간을 줄인다.
효과는 복제본들의 상태가 서로 다를수록 커질 수 있다. 서로 다른 GPU가 섞였거나 트래픽이 순간적으로 몰리는 환경, 여러 요청이 공통 접두어를 공유하는 환경에서는 라운드로빈이 바쁜 파드를 선택할 가능성이 커지고 상태 기반 라우팅이 개입할 여지도 늘어난다.
반대로 같은 하드웨어의 복제본들이 일정한 부하를 받고 캐시와 대기열 상태도 비슷하면 선택 결과가 라운드로빈과 크게 다르지 않을 수 있다. 모든 후보 파드가 포화된 경우에도 라우터는 새로운 연산 용량을 만들어내지 못하므로, 증설이나 오토스케일링을 대신하는 기능으로 해석해서는 안 된다.
따라서 제목의 ‘GPU를 더 사지 않고’는 시험의 동일한 복제본 집합에서 요청 배치만 바꿔 지연을 낮췄다는 의미다. 실제 운영 환경의 개선 폭은 모델 크기, 프롬프트 분포, 동시 요청량, 캐시 재사용률과 하드웨어 구성에 따라 달라질 수 있다.
EKS 인프라는 바뀌지만 클라이언트 코드는 유지할 수 있다
AWS의 현재 배포 문서 는 게이트웨이를 HyperPod Inference Amazon EKS 애드온 v2.0.0-eksbuild.2부터 제공하며, 라우팅 지표 호환을 위해 vLLM 0.9.2 이상과 SGLang 0.3.5.post1 이상을 요구한다고 명시한다. 이전 vLLM에서는 KV 캐시 지표가 게이트웨이가 읽는 이름과 달라 해당 신호가 조용히 제외되고, 이전 SGLang은 필요한 메트릭 옵션을 지원하지 않아 컨테이너가 시작되지 않을 수 있다.
기존 HyperPod Inference Operator는 모델 배포와 서비스, 오토스케일링 등 오케스트레이션을 계속 담당한다. 게이트웨이는 모델 서버 앞에 추가되며, 운영자는 애드온을 설치하거나 업데이트하고 모델의 InferenceEndpointConfig에서 연결을 활성화해야 한다. 직접 구성할 때는 InferenceGatewayConfig에 모델별 스케줄러와 파드 레이블 선택 조건도 정의한다.
‘애플리케이션 코드 변경 없음’은 이 인프라 작업이 사라진다는 뜻이 아니다. 표준 HTTP와 OpenAI 호환 요청 형식은 유지할 수 있지만 호출 대상은 게이트웨이 엔드포인트로 전환해야 하며, 요청 본문의 모델명이 구성된 모델 또는 어댑터와 일치해야 한다.
클러스터 의존성도 확인해야 한다. 자동 TLS 인증서 발급 경로에는 cert-manager와 관련 IAM 권한이 필요하고, Application Load Balancer 방식에는 AWS Load Balancer Controller가 요구된다. 요청 단위 인증·인가는 기본으로 켜지지 않으므로 JWT를 구성하지 않으면 접근 통제는 VPC와 네트워크 경계에 의존한다.
글로벌 라우터는 아직 출시 범위가 아니다
현재 이용 가능한 Tier 1은 각 HyperPod EKS 클러스터 안에서 동작한다. Envoy Gateway가 들어오는 트래픽을 받고 Body-Based Router가 모델 풀을 정한 뒤, Endpoint Picker가 해당 클러스터의 후보 파드 중 하나를 선택한다. 다른 클러스터나 리전의 여유 용량까지 비교하는 기능은 포함되지 않는다.
향후 Tier 2로 예고된 Global Inference Router의 범위에는 교차 클러스터 장애 우회, 글로벌 속도 제한과 비용을 고려한 트래픽 조정이 포함된다. 구체적인 출시 일정과 글로벌 계층의 성능 자료는 아직 제시되지 않았으므로, 지금 애드온을 설치해도 이 기능들이 함께 활성화되는 것은 아니다.
현재 확정된 변화는 기존 모델 서버를 교체하지 않고도 클러스터 내부의 요청 배치 기준을 GPU와 캐시의 실제 상태로 바꿀 수 있다는 점이다. 다만 최대 개선 폭의 재현성은 각 운영 환경에서 별도로 검증해야 하며, 여러 클러스터와 리전을 아우르는 라우팅은 후속 출시를 기다려야 한다.
함께 읽기:
뉴스레터 구독
최신 Web3, AI, 암호화폐 뉴스를 이메일로 받아보세요.