AWS, SageMaker Inference 지연 해소 위해 HyperPod 모델 캐싱과 접두사 라우팅 도입
AWS가 SageMaker HyperPod에 모델 캐싱을, SageMaker Inference에 접두사 인식 라우팅을 추가해 더 빠른 스케일아웃과 낮은 LLM 지연 시간을 노린다.
AWS가 대규모 언어 모델 서빙의 서로 다르지만 관련된 병목을 겨냥한 두 가지 인프라 기능을 추가하고 있다. Amazon SageMaker HyperPod용 모델 캐싱과 SageMaker Inference용 접두사 인식 라우팅이다. 전자는 새 추론 Pod를 온라인으로 올리는 데 걸리는 시간을 줄이도록 설계됐고, 후자는 자주 재사용되는 프롬프트 계산을 같은 인스턴스에 유지해 응답 지연 시간을 낮추는 것을 목표로 한다.
이 변화는 특히 변동성 높은 트래픽에서 대형 모델을 운영하는 팀에 중요하다. 캐싱이 없으면 스케일아웃 이벤트 때 새 노드가 요청을 처리하기 전에 수 기가바이트 크기의 컨테이너 이미지와 모델 가중치를 다운로드해야 할 수 있다. 프롬프트 내용을 고려하지 않는 라우팅이 없으면 동일한 프롬프트 구간이 전체 플릿에 분산되어 서빙 프레임워크의 접두사 캐시가 충분히 활용되지 못할 수 있다.
두 발표 모두 AWS Machine Learning Blog에서 나온 것이므로 성능 수치와 운영 관련 주장은 AWS가 보고한 것이며 독립적으로 검증된 것은 아니다. 함께 보면 추론 콜드 스타트와 안정 상태에서의 첫 토큰까지의 시간을 모두 줄이기 위한 보다 조율된 접근을 보여준다.
HyperPod 캐싱이 스케일아웃 격차를 줄인다
AWS는 SageMaker HyperPod에서의 모델 배포가 두 번의 연속 다운로드로 지연될 수 있다고 말한다. Kubernetes가 먼저 Amazon Elastic Container Registry에서 추론 서버 이미지를 가져오고, 그 뒤 서버가 Amazon S3, Amazon FSx for Lustre, Hugging Face Hub, JumpStart 같은 소스에서 모델 가중치를 다운로드한다.
작은 모델의 경우 이 과정은 몇 분이 걸릴 수 있다. AWS는 145GB 모델의 예를 들며, 네트워크 조건에 따라 Amazon S3에서 가중치를 다운로드하는 데 20분 이상 걸릴 수 있다고 설명한다. AWS가 인용한 시나리오에서 600GB가 넘는다고 설명하는 DeepSeek-R1 같은 모델의 경우, 이 과정은 30분 이상 걸릴 수 있다. 일반적인 수 기가바이트 추론 이미지의 컨테이너 이미지 pull만 해도 AWS는 5~7분으로 추정한다.
이 지연은 오토스케일링과 실제 용량 사이에 불일치를 만든다. HorizontalPodAutoscaler는 추가 Pod를 빠르게 요청할 수 있지만, 이미지와 가중치가 준비되기 전까지는 트래픽을 받을 수 없다. 따라서 갑작스러운 요청 급증이 운영 대응을 유발하더라도 실제 대응은 수십 분 늦게 도착할 수 있다.
새로운 모델 캐싱 기능은 대상 노드의 로컬 NVMe 스토리지에 가중치를 미리 적재한다. AWS에 따르면 HyperPod Inference Operator가 가중치를 미리 다운로드하고, 노드를 캐시 준비 완료로 표시한 뒤 대상 노드들이 과정을 끝낼 때까지 기다렸다가 추론 배포를 생성한다. 준비된 노드에서 Pod가 시작되면 네트워크로 모델을 다운로드하는 대신 초당 약 7GB 속도로 로컬에서 읽을 수 있다.
AWS는 별도의 이미지 캐시도 제공한다. DaemonSet이 추론 컨테이너 이미지를 노드에 사전 pull해 이후 Pod가 Amazon Elastic Container Registry 다운로드를 건너뛸 수 있게 한다. 같은 이미지를 사용하는 여러 배포는 이 캐시를 공유할 수 있으며, 오퍼레이터가 참조와 정리를 관리한다.
두 캐싱 시스템이 운영 환경에서 작동하는 방식
가중치 캐싱과 이미지 캐싱은 동일한 배포 의미를 갖지 않는다. AWS는 가중치 캐싱이 모든 대상 노드가 준비될 때까지 추론 배포 생성을 지연시킬 수 있는 반면, 이미지 캐싱은 배포 생성 자체를 막지 않는다고 말한다. 따라서 특정 노드에서 이미지 캐시가 완료되기 전에 Pod가 시작되어 일반 이미지 pull로 되돌아갈 수 있다.
두 메커니즘 모두 강제보다 선호 기반 스케줄링을 사용한다. Pod는 가능하면 따뜻한 데이터가 있는 노드로 유도되지만, 다른 곳에서 실행되는 것을 막지는 않는다. 빠른 스케일아웃이 준비된 노드 수를 초과하면 Pod는 원래 모델 소스를 사용하고 이미지를 정상적으로 가져올 수 있다. 트레이드오프는 실패한 배포가 아니라 더 느린 시작이다.
오퍼레이터는 모델 가중치용 ModelDataCacheConfig와 컨테이너 이미지용 ModelImageCache라는 두 개의 기반 커스텀 리소스를 관리한다. 사용자는 이러한 라이프사이클 오브젝트를 직접 관리하는 대신 InferenceEndpointConfig 또는 JumpStartModel 리소스의 modelCacheConfig를 통해 캐싱을 활성화한다.
AWS는 모델 소스나 이미지가 바뀔 때 캐시 업데이트도 처리된다고 말한다. 오퍼레이터는 새 캐시를 만들고, 업데이트된 배포를 롤아웃한 뒤, 오래된 캐시를 제거한다. 이는 오래된 가중치를 방지하면서 무중단 전환을 지원하려는 목적이지만, 실제 결과는 여전히 사용 가능한 노드 스토리지와 대체 캐시를 채우는 데 필요한 시간에 좌우된다.
접두사 인식 라우팅이 LLM 프롬프트 캐시를 유용하게 유지한다
두 번째 SageMaker 변경은 서빙 스택의 다른 계층을 겨냥한다. 많은 LLM 요청은 시스템 지시문, 검색한 문서, 대화 기록, 소스 코드 같은 길고 반복되는 접두사와 짧은 사용자별 접미사를 포함한다. vLLM과 TensorRT-LLM 같은 프레임워크는 이 반복되는 접두사에 대해 계산된 키-값, 즉 KV 캐시를 재사용할 수 있다.
요청을 무작위로 분산하면 다중 인스턴스 엔드포인트에서 이런 이점이 약해진다. 같은 접두사를 가진 연속 요청이 서로 다른 머신에 도착하면 각 인스턴스가 공유 컨텍스트를 다시 계산해야 할 수 있다. SageMaker Inference의 새로운 접두사 인식 라우팅 전략은 요청의 시작 부분을 검사해 일치하는 접두사를 같은 인스턴스로 일관되게 보낸다.
AWS는 이 기능이 지나치게 인기 있는 접두사로부터 플릿을 보호할 수도 있다고 말한다. 선호 인스턴스가 설정된 동시성 한도에 도달하면 요청을 덜 바쁜 인스턴스로 재지정할 수 있다. 이는 한 요청의 캐시 적중을 포기할 수 있지만, 트래픽이 한 대의 머신에 집중되는 것을 막는다. AWS는 또 인스턴스를 추가하거나 제거해도 이동하는 트래픽 비중이 제한적이어야 하며, 스케일링 중 캐시 지역성을 유지하는 데 도움이 된다고 덧붙인다.
이 전략은 프로덕션 변형별로 구성하며 모델을 재배포하지 않고 엔드포인트 설정으로 바꿀 수 있다. AWS는 여전히 기본값으로 무작위 라우팅을 제공하며, 요청 시간이 제각각인 워크로드를 위한 가장 적은 대기 요청 라우팅도 제공한다. 접두사 인식 라우팅은 공유된 앞부분 컨텍스트와 활성화된 접두사 캐시가 있는 LLM 워크로드를 위해 특별히 고안됐다.
근거, 벤치마크, 한계
AWS는 vLLM과 접두사 캐싱을 활성화한 상태에서 7개의 ml.p5.48xlarge 인스턴스에 Llama 3.1 70B Instruct를 사용해 접두사 인식 라우팅과 무작위 라우팅을 비교 벤치마크했다. 서로 다른 엔드포인트와 API 구성을 포괄한 16개 테스트 설정에서 AWS는 첫 토큰까지의 중앙값 시간을 최대 77% 단축하고, 처리량을 최대 16% 높였으며, KV 캐시 적중률을 약 25%에서 80% 이상으로 끌어올렸다고 보고한다.
이는 공급업체가 보고한 벤치마크 결과로, 독립 평가가 아니다. AWS는 테스트에서 트래픽이 균형을 유지했으며 각 인스턴스가 요청의 13.3%에서 15.4%를 받았다고 말한다. 또한 테스트된 구성에서 모델의 첫 토큰까지의 시간이 63~280밀리초였던 것과 비교해, 요청당 1.3~1.9밀리초의 추가 라우팅 비용이 있었다고 보고한다.
이점의 크기는 워크로드 형태에 크게 좌우된다. AWS는 공유 접두사가 길수록 더 많은 계산을 건너뛸 수 있어 이득이 커진다고 말한다. AWS가 꼽는 사용 사례에는 같은 문서를 반복적으로 조회하는 RAG 시스템, 다중 턴 대화, 템플릿 기반 어시스턴트, 코드 완성이 포함된다. 짧거나 대부분 고유한 프롬프트를 가진 워크로드는 상대적으로 이점이 적다.
HyperPod 관련 주장 역시 소스에서 완전히 명시되지 않은 조건에 의존한다. 여기에는 노드 가용성, 캐시 채우기 시간, 스토리지 용량, 모델 형식, 초기 사전 적재 중 네트워크 성능이 포함된다. 수십 분에서 수 초로의 전환은 관련 데이터가 이미 캐시된 노드에 Pod가 배치될 때 적용되며, 준비되지 않은 노드는 일반 다운로드 경로를 따른다.
AI 인프라 팀에 미치는 의미
빌더와 엔터프라이즈 플랫폼 팀에게 이번 발표는 흔히 하나의 지연 시간 문제로 취급되던 두 결정을 분리한다. 모델 캐싱은 탄력성을 높여, 트래픽이 늘 때 새 용량을 더 빨리 유용하게 만든다. 접두사 인식 라우팅은 요청 효율을 높여, 용량이 이미 온라인 상태가 된 뒤 반복되는 prefill 작업을 줄일 수 있다.
이 조합은 버스트성 트래픽과 큰 반복 컨텍스트를 모두 가진 RAG 애플리케이션과 어시스턴트에 유용할 수 있다. 팀은 HyperPod 캐싱으로 스케일아웃용 노드를 준비하면서, 접두사 인식 라우팅으로 문서 또는 대화 접두사를 활성 플릿 전반에서 따뜻하게 유지할 수 있다. 하지만 로컬 NVMe 용량 산정, 동시성 한도 구성, 실제 트래픽에서의 캐시 적중률 측정 필요성은 사라지지 않는다.
구매자가 시험해봐야 할 비용 및 신뢰성 문제도 있다. 각 대상 노드에 가중치를 유지하면 로컬 스토리지를 소모하고 배포 준비 전 준비 시간을 늘릴 수 있다. 접두사 친화성은 지연 시간을 개선할 수 있지만, 내용 의존적 라우팅 동작을 도입하므로 팀은 큐 깊이, 인스턴스 사용률, 캐시 점유율, 꼬리 지연 시간과 함께 관찰해야 한다. AWS가 라우팅을 자동으로 처리하더라도 라우팅 결정이 요청 페이로드의 시작 부분을 검사하므로, 개인정보와 데이터 거버넌스 검토도 중요할 수 있다.
다음에 볼 것
이 기능을 평가하는 팀은 AWS의 Llama 3.1 70B 테스트를 넘어선 모델, 하드웨어, 프롬프트 분포에 대한 독립 재현 결과를 찾아야 한다. 특히 유용한 지표는 p95 및 p99 첫 토큰까지의 시간, 스케일아웃 중 캐시 적중률, 그리고 준비되지 않은 노드에 도착하는 요청 비율이다.
로컬 NVMe 크기 산정, 캐시 워밍 오케스트레이션, 멀티모델 클러스터에 대한 운영 지침도 중요하다. 구매자는 캐시 준비가 배포 롤아웃, 노드 교체, 스팟 또는 중단 시나리오, 사전 적재된 플릿을 넘어서는 빠른 스케일링에 어떤 영향을 미치는지 확인해야 한다.
마지막으로, 호스티드 서빙 플랫폼이 모델 접근성만이 아니라 예측 가능한 지연 시간으로 경쟁하게 되면서 AWS의 엔드포인트 수준 라우팅 제어는 더 중요해질 수 있다. 주목할 신호는 고객이 이러한 제어를 상당한 스케줄링 복잡성을 추가하거나 균형 잡힌 GPU 활용을 희생하지 않고 사용할 수 있는지다.
Creati.ai 관점
AWS는 새로운 모델 기능을 도입하기보다 LLM 운영의 두 가지 실질적인 약점을 해결하고 있다. HyperPod 모델 캐싱은 용량 추가의 페널티를 줄이고, 접두사 인식 라우팅은 기존 서빙 최적화인 KV 캐시 재사용을 여러 인스턴스에 걸쳐 더 신뢰할 수 있게 만든다.
가장 강한 사례는 큰 모델의 사전 로드를 정당화할 만큼 트래픽이 있는 예측 가능하고 반복 컨텍스트가 있는 워크로드다. 대부분 고유한 프롬프트나 드문 배포를 가진 팀이라면 스토리지와 준비 오버헤드가 이득보다 클 수 있다. AWS의 벤치마크 수치는 고무적이지만, 인프라 구매자는 캐싱을 보장된 개선으로 여기기 전에 자신의 프롬프트 중복, 스케일링 패턴, 지연 시간 목표에 맞춰 검증해야 한다.
