Amazon SageMaker Prefix-Aware Routing, 지연 시간 단축의 핵심은 반복되는 컨텍스트

Amazon SageMaker의 prefix-aware routing은 반복 프롬프트가 향하는 위치를 바꿔 AWS 테스트에서 첫 토큰 생성까지 걸리는 시간의 중앙값을 최대 77% 줄였다. 모든 요청을 내용과 무관하게 분산하는 대신, SageMaker는 이제 시작 부분이 같은 요청을 동일한 모델 인스턴스에 유지할 수 있다. 그 결과 이전에 계산된 컨텍스트가 계속 활용될 가능성이 높아진다.

이 결과는 대규모 언어 모델 엔드포인트 확장에 관한 기본 가정에 의문을 제기한다. 일반적인 로드 밸런싱이 요청과 유용한 캐시 데이터를 분리하면 인스턴스를 추가한다고 해서 자동으로 효율적인 추론이 이뤄지지는 않는다. 충분한 가속기 용량을 갖춘 플릿도 같은 지침, 문서 또는 대화 이력을 반복 처리할 수 있다.

이에 따라 AWS는 라우팅을 모델 엔진, 가속기, 캐싱 소프트웨어와 함께 추론 최적화 스택의 일부로 내세우고 있다. 직접적인 상대는 작업을 고르게 분산하지만 각 인스턴스가 이미 보유한 정보를 무시하는 캐시 비인지형 로드 밸런싱이다. AWS는 상당한 개선 효과를 보고했지만, 가장 강력한 수치는 독립적인 프로덕션 테스트가 아닌 통제된 긴 컨텍스트 벤치마크에서 나왔다.

Amazon SageMaker Prefix-Aware Routing이 기본 트레이드오프를 바꾸는 방식

AWS는 프롬프트 지역성을 애플리케이션 수준의 우회책에서 관리형 엔드포인트 라우팅 계층으로 옮겼다.

AWS는 2026년 9월 10일 Amazon SageMaker 실시간 추론 엔드포인트용 기능을 발표했다. 새 전략은 들어오는 요청의 시작 부분을 확인하고, 동일한 시작 부분을 가진 요청을 일관되게 같은 인스턴스로 보낸다.

기본 아이디어는 단순하다. 많은 LLM 요청은 큰 고정 구간 뒤에 훨씬 작은 가변 구간이 이어지는 형태다. 고객 서비스 어시스턴트는 새 고객 질문마다 동일한 정책 문서와 운영 지침을 받을 수 있다.

검색 증강 생성 애플리케이션도 흔히 같은 패턴을 따른다. 검색된 문서를 사용자 질의 앞에 배치하기 때문에, 해당 문서에 관한 여러 질문은 동일한 텍스트로 시작한다. 코딩 어시스턴트 역시 파일, import, 지침, 최근 편집 컨텍스트를 다시 전송한다.

모델 서버에는 이미 이런 반복을 활용하는 메커니즘이 있다. 일반적으로 KV cache라고 부르는 키-값 캐시는 모델이 이전 토큰을 처리하며 계산한 어텐션 상태를 저장한다. Prefix caching은 프롬프트 시작 부분이 일치하는 관련 요청 간에 재사용 가능한 상태를 유지한다.

문제는 엔드포인트가 여러 인스턴스로 확장될 때 나타난다. 무작위 라우팅은 동일한 prefix를 가진 연속 요청을 서로 다른 머신으로 보낼 수 있다. 그러면 유용한 캐시 항목이 다른 곳에 존재하기 때문에 각 머신이 그 공통 컨텍스트를 다시 처리하게 된다.

Amazon SageMaker의 prefix-aware routing은 이러한 지역성을 보존하려 한다. 동일한 prefix를 공유하는 10개 요청은 일반적으로 같은 머신에 도달해야 하며, 해당 모델 서버는 캐시된 계산을 재사용할 수 있다. 다른 prefix를 가진 요청은 여전히 플릿 전체로 분산될 수 있다.

이 기능은 서빙 엔진 내부의 prefix caching을 대체하지 않는다. 컨테이너는 여전히 KV 상태를 유지하고 재사용할 수 있는 소프트웨어를 실행해야 한다. AWS는 vLLM으로 이 전략을 테스트했으며, 최근 vLLM 버전에서는 prefix caching이 기본적으로 활성화된다고 설명한다.

이번 출시는 SageMaker 실시간 엔드포인트에 세 번째 라우팅 선택지를 추가한다. 무작위 라우팅은 기본값으로 유지되며 요청 간 관계를 고려하지 않고 트래픽을 분산한다. least-outstanding-requests routing은 가장 많은 처리 여력을 가진 인스턴스를 우선한다.

Prefix-aware routing은 다른 선택을 한다. 완전히 상호 교환 가능한 트래픽의 가치를 일부 포기하는 대신, 절감된 프롬프트 계산이 그 비용을 상쇄할 수 있다는 점에 주목한다.

AWS는 이 위험을 억제하기 위해 과부하 보호 기능을 추가했다. 우선 인스턴스가 구성된 동시성 임계값에 도달하면 SageMaker는 요청을 덜 바쁜 인스턴스로 보낸다. 해당 요청은 캐시 히트를 놓칠 수 있지만, 과부하된 대기열에 합류하는 일은 피할 수 있다.

이 서비스는 플릿 규모가 변할 때도 대부분의 요청 배치를 유지하도록 설계됐다. AWS에 따르면 인스턴스를 추가하거나 제거해도 트래픽의 일부만 이동한다. 이러한 동작은 전체 재분배가 초래할 캐시 중단을 줄인다.

공식 routing configuration은 과부하 동작을 확인한다. 이 문서는 random, least-outstanding-requests, prefix-aware 전략을 지원되는 선택지로 열거한다.

이는 지속적인 시스템 문제를 누가 처리하는지를 바꾸기 때문에 단순한 편의 설정 이상이다. 기존에는 팀이 세션 어피니티를 구축하거나, 특수 라우터를 배포하거나, 낮은 캐시 재사용률을 감수해야 했다. 이제 SageMaker는 관리형 엔드포인트 계층 안에서 콘텐츠 민감형 배치를 제공한다.

이 구분은 이 기능을 모델 라우팅과도 분리한다. 가격, 품질 또는 작업 유형에 따라 서로 다른 foundation model 중 하나를 선택하는 기능이 아니다. 동일하게 배포된 워크로드의 어느 인스턴스가 요청을 받아야 하는지를 선택한다.

이처럼 범위가 좁다는 점은 중요하다. AWS는 하나의 스위치가 LLM 서빙의 모든 부분을 최적화한다고 주장하지 않는다. 애플리케이션이 매 요청에 길고 반복되는 컨텍스트를 첨부할 때 특히 비용이 커지는 반복 prefill 작업을 겨냥한다.

77% 지연 시간 개선 결과는 긴 공통 프롬프트에서 나왔다

AWS는 각 요청이 8,000토큰 prefix를 재사용했을 때 가장 큰 개선을 기록했으며, 이는 캐시 지역성에 유리한 벤치마크 조건이다.

회사는 prefix-aware routing을 SageMaker의 기본 무작위 전략과 비교했다. 테스트에는 Llama 3.1 70B Instruct, ml.p5.48xlarge 인스턴스 7개, 그리고 prefix caching이 활성화된 vLLM이 사용됐다.

AWS는 단일 모델 엔드포인트, inference component 엔드포인트, 네이티브 Invoke API, OpenAI 호환 API에 걸쳐 16개 구성을 실행했다. 회사는 모든 테스트가 성공적으로 완료됐다고 보고했다.

가장 강력한 결과는 1시간 동안 유지된 긴 컨텍스트 워크로드에서 나왔다. 각 요청은 8,000토큰 prefix를 공유했고, 캐시가 제거할 수 있는 반복 계산 블록이 크게 형성됐다.

이 조건에서 AWS는 P50 첫 토큰 생성 시간이 71%에서 77% 감소했다고 밝혔다. P50은 중앙값 결과로, 측정된 요청의 절반은 더 빨리 응답했고 나머지 절반은 더 느리게 응답했다는 의미다.

P90 첫 토큰 생성 시간은 33%에서 37% 감소했다. 이 백분위수는 요청 분포 중 더 느린 구간을 나타내므로 서비스 수준 목표에서 더 중요한 경우가 많다. P90 개선 폭이 더 작다는 점은 라우팅이 모든 꼬리 지연 요인을 제거할 수는 없음을 시사한다.

AWS는 KV cache hit rate가 약 25%에서 최대 82%로 증가했다고 보고했다. 처리량은 15%에서 16% 늘었으며, 건너뛴 prefill 작업이 처리 용량도 확보했음을 보여준다.

이 수치들은 Amazon SageMaker prefix-aware routing의 핵심 근거를 이룬다. 중앙값 지연 시간 개선은 두드러지지만, 캐시 히트율 변화가 그 원인을 설명한다. 라우터가 기존의 캐시된 계산에 더 자주 접근할 수 있게 만든 것이다.

더 짧고 길이가 가변적인 ShareGPT 스타일 대화에서는 결과가 더 완만했다. 30분 실행 기준으로 첫 토큰 생성 시간의 중앙값은 13%에서 16% 개선됐다. 처리량 증가는 1.7%에서 2%에 그쳤다.

그 짧은 테스트에서도 P90 지연 시간은 24%에서 37% 개선됐다. AWS에 따르면 캐시 히트율은 약 30%에서 80%로 상승했다. 다만 재사용 가능한 prefix가 더 짧았기 때문에, 성공적인 각 히트가 건너뛴 작업량도 더 적었다.

이 대조는 AWS benchmark에서 가장 유용한 세부 사항이다. Prefix-aware 배치는 모든 LLM 애플리케이션에 적용되는 고정 배수가 아니다. 그 가치는 얼마나 많은 컨텍스트가 반복되는지, 그리고 그 컨텍스트 처리 비용이 얼마나 큰지에 달려 있다.

보고된 라우팅 오버헤드는 요청당 1.3~1.9밀리초였다. AWS는 테스트 중 모델의 첫 토큰 생성 시간을 63~280밀리초로 측정했다. 이 범위에서 라우팅 계산이 응답 시간에서 차지하는 비중은 비교적 작았다.

테스트한 시나리오에서는 트래픽도 균형을 유지했다. 7개 인스턴스는 각각 요청의 13.3%에서 15.4%를 받았다. 이상적인 분배라면 각 인스턴스에 약 14.3%씩 할당된다.

이 결과는 prefix 어피니티에 대한 가장 명백한 반론을 다룬다. 일치하는 요청을 함께 유지하면 특정 prefix가 불균형적으로 인기 있을 경우 핫스팟이 생길 수 있다. AWS는 과부하 임계값이 벤치마크에서 이 문제를 방지했다고 밝혔다.

그럼에도 이 수치는 신중하게 해석할 필요가 있다. AWS가 테스트를 수행하고 공개했으며, 독립 기관이 보고된 개선 효과를 검증한 것은 아니다. 회사는 관련 없는 고객들로부터 얻은 광범위한 프로덕션 트레이스 모음도 제시하지 않았다.

긴 컨텍스트 테스트는 의도적으로 상당한 재사용을 만든다. 이는 기능이 의도한 효과를 측정하는 데 적절하지만, 모든 엔드포인트를 대표하지는 않는다. 서로 관련 없는 짧은 프롬프트를 처리하는 서비스는 재사용 가능한 작업이 훨씬 적다.

또한 이 벤치마크는 새 전략을 무작위 라우팅과 비교한다. 이미 맞춤형 캐시 인식 라우터, 세션 어피니티 또는 분산 KV cache를 사용하는 팀은 추가적인 이점이 더 작을 수 있다. 이들에게 관련 기준선은 반드시 SageMaker의 기본값은 아니다.

따라서 가장 명확한 결론에는 조건이 따른다. 요청이 긴 prefix를 공유하고 서빙 엔진이 해당 KV 상태를 유지할 때 이 기능은 지연 시간을 크게 줄일 수 있다. 다양하고 캐시 재사용이 어려운 트래픽에 대해서는 같은 약속을 하지 않는다.

이 조건부 결과는 prefix caching에 관한 더 광범위한 연구를 반영한다. 2025년 NeurIPS paper는 더 똑똑한 캐시 유지가 효율성을 개선한다는 사실을 발견했지만, 제한된 캐시 용량과 eviction 문제도 기록했다.

라우팅은 이 시스템의 한 부분을 해결한다. 요청이 관련 상태를 보유한 인스턴스에 도달할 가능성을 높인다. 요청이 도착할 때 그 상태가 메모리에 남아 있음을 보장할 수는 없다.

Cache-Aware Routing이 일반적인 로드 밸런서에 가하는 압력

이번 출시는 기존 요청 분산 방식과 현대 LLM 추론의 상태 기반 동작 사이의 불일치를 드러낸다.

전통적인 웹 서비스는 상호 교환 가능한 복제본을 바람직한 설계로 취급하는 경우가 많다. 로드 밸런서는 무작위성이나 큐 깊이를 활용해 각 요청을 정상 서버 어느 곳으로든 보내며 작업을 분산할 수 있다. 애플리케이션은 배치 위치와 관계없이 같은 결과를 내야 한다.

LLM 복제본은 동등한 답변을 생성할 수 있지만 준비 비용은 크게 다를 수 있다. 한 GPU는 긴 계약서, 코드 파일 또는 대화를 위한 어텐션 상태를 이미 보유하고 있을 수 있다. 다른 GPU는 첫 토큰을 생성하기 전에 그 상태를 다시 구성해야 할 수 있다.

캐시 비인지형 라우팅은 이 차이를 무시한다. 가장 비어 있는 큐를 선택하면서도 중복 prefill 작업이 가장 많은 머신을 고를 수 있다. 로컬에서 더 바쁜 머신이라도 이미 일치하는 prefix를 담고 있다면 더 빨리 응답할 수 있다.

이러한 긴장은 AWS만의 문제는 아니다. 오픈 소스 추론 시스템도 요청 스케줄링과 캐시 위치를 연결된 문제로 다루고 있다. 이 흐름에는 vLLM 기반 스택, 특수 Kubernetes 게이트웨이, 분산 캐시, prefill-decode 아키텍처가 포함된다.

AWS는 SageMaker HyperPod 내에서 더 정교한 버전을 논의한 바 있다. intelligent routing은 계층형 캐싱과 함께 prefix-aware, KV-aware, round-robin 전략을 지원한다.

HyperPod 설계는 캐시된 접두사를 추적하고 스토리지를 GPU 메모리 너머로 확장할 수 있습니다. 로컬 CPU 메모리를 하나의 캐시 계층으로 사용하며, 분산형 두 번째 계층도 제공할 수 있습니다. 이 접근 방식은 더 심층적인 운영 제어가 필요한 대규모 Kubernetes 관리 인프라에 적합합니다.

새로운 실시간 엔드포인트 기능의 역할은 더 단순합니다. 사용자가 추론 클러스터나 분산 캐시를 운영하지 않아도 요청을 캐시가 있을 가능성이 높은 위치에 가깝게 유지합니다. 이를 통해 표준 관리형 엔드포인트를 사용하는 팀도 이 기술을 활용할 수 있습니다.

관리형 환경은 특정 방식으로 맞춤형 라우팅 프로젝트에도 압박을 가합니다. AWS가 이러한 프로젝트가 지원하는 모든 배치 신호나 캐시 관리 정책을 반드시 제공하는 것은 아닙니다. 대신 의미 있는 수준의 이점을 얻는 데 필요한 노력을 줄입니다.

플랫폼 팀에게 이는 자체 구축과 구매 사이의 판단을 바꿀 수 있습니다. 맞춤형 라우터에는 배포, 업그레이드, 텔레메트리, 장애 처리, 오토스케일링 연동이 필요합니다. 제약 조건이 워크로드에 맞는다면 프로덕션 변형 구성은 도입하기가 더 쉽습니다.

경쟁 압력은 다른 관리형 추론 제공업체에도 미칩니다. 고객은 사용 가능한 모델이나 가속기 유형뿐 아니라 라우팅, 캐싱, 확장을 얼마나 잘 조율하는지를 기준으로 LLM 플랫폼을 점점 더 평가할 수 있습니다.

이는 추론 효율성이 전체 서빙 경로에 점점 더 의존하기 때문에 중요합니다. 모델 양자화는 메모리 사용량을 줄일 수 있습니다. 연속 배칭은 활성 요청을 결합할 수 있습니다. 적절한 조건에서는 추측 디코딩이 토큰 생성을 가속할 수 있습니다.

캐시 인식 배치는 또 다른 낭비 원인을 겨냥합니다. 시스템이 이미 완료한 프롬프트 처리를 반복하지 않도록 합니다. 이러한 방법들은 함께 사용할 수 있으므로 인프라 제공업체는 이를 통합 스택으로 패키징할 유인이 있습니다.

AWS의 분리형 추론 작업은 이러한 방향을 보여 줍니다. 이 아키텍처는 연산 집약적인 프리필을 메모리 대역폭 집약적인 디코딩과 분리하고, 워커 간 KV 전송을 조율합니다.

이처럼 더 발전된 설계는 추론을 분산 시스템 문제로 다룹니다. 라우팅 결정은 대기열 압력, 캐시 위치, 특화된 워커 역할을 고려합니다. 일반적인 네트워크 로드 밸런서는 이러한 애플리케이션 수준 신호를 갖고 있지 않습니다.

그렇다고 일반 라우팅의 용도가 사라지는 것은 아닙니다. 요청이 독립적이거나 모델에 효과적인 접두사 캐시가 없을 때는 무작위 배치가 적합합니다. 처리 시간이 다양하고 공유 컨텍스트의 지역성이 낮을 때는 최소 미처리 요청 방식이 도움이 될 수 있습니다.

따라서 접두사 인식 라우팅은 범용 대체 수단이 아닙니다. 완벽하게 균등한 요청 분배보다 재사용 가능한 컨텍스트를 우선하는 워크로드별 전략입니다. AWS의 과부하 제어는 두 목표의 균형을 맞추려 합니다.

이 기능은 문서 도우미와 내부 검색 시스템을 구축하는 팀의 관심을 끌 수 있습니다. 이러한 애플리케이션은 질문을 바꾸기 전에 동일한 매뉴얼, 정책, 사양 또는 프로젝트 기록을 반복적으로 제시합니다.

검색 가능한 지식 기반을 구축하는 팀은 이 패턴을 알아볼 수 있습니다. 검색 품질은 어떤 컨텍스트가 프롬프트에 들어가는지를 결정하고, 라우팅은 해당 컨텍스트 처리 결과를 재사용할 수 있는지에 영향을 줍니다.

멀티턴 에이전트도 유력한 후보입니다. 새 턴에는 이전 메시지, 도구 지침, 누적된 작업 상태가 자주 포함됩니다. 공통된 시작 부분이 길어질수록 프리필 단계의 비용이 증가하는 동시에 캐시 재사용 기회도 생깁니다.

코딩 도우미 역시 뚜렷한 지역성을 보입니다. 여러 요청이 리포지토리 지침, 열려 있는 파일, 인접한 심볼, 대화 기록을 공유할 수 있습니다. 최종 완성 요청은 달라지지만 그 이전 컨텍스트의 상당 부분은 안정적으로 유지됩니다.

이러한 패턴은 라우팅이 지금 경쟁 기능이 된 이유를 설명합니다. 더 긴 컨텍스트 윈도우는 애플리케이션이 매 호출마다 더 많은 참고 자료를 보내도록 만들었습니다. 에이전트 워크플로도 여러 단계에 걸쳐 상당한 지침과 기록을 반복합니다.

새로운 병목은 생성되는 토큰 수만이 아닙니다. 생성이 시작되기 전에 크고 익숙한 입력을 반복적으로 준비하는 일입니다. 이 때문에 첫 토큰까지 걸리는 시간은 토큰 생성 속도와 별개의 제품 문제로 떠오릅니다.

벤치마크가 보장하지 않는 것

접두사 인식 라우팅은 캐시 재사용 가능성을 높이지만, 직렬화, 제거, 테넌트 격리, 트래픽 편중은 기대한 이점을 없앨 수 있습니다.

첫 번째 불확실성은 워크로드 적합성입니다. 서로 관련 없는 프롬프트를 처리하는 엔드포인트는 유용한 접두사 일치를 거의 만들지 못할 수 있습니다. 이 환경에서는 라우터가 많은 모델 연산을 건너뛰지 못한 채 작은 판단 비용만 추가합니다.

겉으로 비슷한 프롬프트도 일치하지 않을 수 있습니다. SageMaker의 기본 Invoke API는 요청 본문 바이트를 기준으로 라우팅 접두사를 구성합니다. JSON 공백, 필드 순서 또는 서식의 차이가 해당 바이트를 바꿀 수 있습니다.

따라서 애플리케이션은 요청을 일관되게 직렬화해야 합니다. 클라이언트 라이브러리가 서로 다르게 패키징한다면 안정적인 시스템 프롬프트만으로는 충분하지 않습니다. 여러 서비스나 프로그래밍 언어를 사용하는 팀은 동등한 요청이 동일한 라우팅 입력을 생성하는지 테스트해야 합니다.

OpenAI 호환 API는 메시지 텍스트에서 추출한 문자를 대신 사용합니다. 이 방식은 원시 JSON에 대한 민감도를 일부 제거하지만, 메시지 시퀀스 내의 변경은 여전히 접두사에 영향을 줍니다. 프롬프트 초반에 배치한 동적 메타데이터는 관련 요청을 분산시킬 수 있습니다.

접두사 길이는 또 다른 튜닝 문제를 만듭니다. SageMaker는 1,024에서 65,536까지 구성 가능한 범위를 허용합니다. 기본 API에서는 이 값이 바이트를, OpenAI 호환 API에서는 문자를 나타냅니다.

선택 길이가 짧으면 너무 많은 요청이 일반적인 시작 부분으로 묶일 수 있습니다. 이는 하나의 인스턴스로 과도한 트래픽이 향할 가능성을 높입니다. 이후 동시성 임계값이 오버플로를 유발해 용량을 유지하는 대신 캐시 친화성을 희생합니다.

선택 길이가 길면 반대 문제가 생깁니다. 선택 영역 내에 나타나는 작은 차이가, 그렇지 않았다면 비용이 큰 컨텍스트를 공유했을 요청들을 분리할 수 있습니다. 플릿은 균형을 유지하지만 캐시 적중률 개선은 줄어듭니다.

올바른 값은 실제 프롬프트 구조에 달려 있습니다. 팀은 공유 지침이 끝나고 고유한 자료가 시작되는 위치를 알아야 합니다. 또한 널리 쓰이는 템플릿이 하나의 라우팅 버킷이 되는 것을 방지할 만큼 충분한 구분 콘텐츠가 필요합니다.

캐시 제거는 라우터의 직접적인 제어 밖에 있습니다. GPU 메모리는 제한적이며, 모델 서버는 새 요청이 도착할 때 KV 블록을 회수해야 합니다. 요청은 관련 항목이 이미 사라진 뒤에 예상 인스턴스에 도달할 수 있습니다.

앞서 인용한 접두사 캐시 연구는 제거 정책이 적중률에 실질적인 영향을 준다는 사실을 확인했습니다. 이는 배치와 보존을 함께 평가해야 함을 시사합니다.

오토스케일링은 캐시 변동의 또 다른 원인입니다. AWS는 플릿 변경 중에도 대부분의 트래픽이 매핑된 상태로 유지된다고 말하지만, 새 인스턴스는 유용한 로컬 접두사 없이 시작합니다. 인기 컨텍스트가 해당 머신을 워밍업할 때까지 스케일아웃 이벤트는 일시적으로 적중률을 낮출 수 있습니다.

스케일인 이벤트는 가치 있는 항목을 보유한 머신을 제거할 수 있습니다. 안정적인 재매핑은 혼란을 줄이지만, 사라지는 인스턴스의 캐시 콘텐츠를 보존할 수는 없습니다. 따라서 갑작스러운 트래픽 변화는 정상 상태의 벤치마크 결과를 약화할 수 있습니다.

인기 접두사는 근본적인 충돌도 만듭니다. 일치하는 모든 요청을 하나의 머신에 유지하면 그 머신이 포화될 때까지 지역성은 극대화됩니다. 트래픽을 분산하면 부하 상황의 지연 시간은 보호되지만, 더 많은 인스턴스에 캐시된 연산이 중복됩니다.

SageMaker의 ConcurrencyThreshold는 이 절충을 직접 드러냅니다. 허용값 범위는 진행 중인 요청 1개에서 1,024개입니다. 보수적인 임계값은 부하 분산에 유리하며, 더 높은 설정은 더 오래 친화성을 보호합니다.

모든 모델에 맞는 단일 임계값은 없습니다. 대형 프롬프트, 긴 출력, 양자화 설정, 텐서 병렬화, 배칭 동작은 모두 안전한 동시성에 영향을 미칩니다. 운영자는 자신의 서비스 수준 목표에 맞춰 값을 조정해야 합니다.

테넌트 분리에도 비슷한 주의가 필요합니다. 두 조직이 동일한 시스템 지침을 사용할 수 있지만 독립적인 운영 처리가 필요할 수 있습니다. SageMaker는 라우팅 그룹을 분리하기 위한 선택적 접두사 인식 식별자를 지원합니다.

기본 API 사용자는 최대 64개의 ASCII 문자로 X-Amzn-SageMaker-Prefix-Aware-Id를 제공할 수 있습니다. OpenAI 호환 요청은 prompt_cache_key 필드를 사용할 수 있습니다. AWS는 인스턴스를 선택할 때 식별자와 접두사를 결합합니다.

이 기능은 라우팅 격리를 제공하지만, AWS의 발표를 모든 서빙 프레임워크에서의 데이터 격리에 관한 광범위한 주장으로 해석해서는 안 됩니다. 팀은 여전히 컨테이너 동작, 메모리 관리, 로깅 및 전체 보안 모델을 평가해야 합니다.

의미 있는 라우팅 차이를 만들려면 이 기능에 최소 두 개의 인스턴스가 필요합니다. 인스턴스가 하나라면 모든 요청은 이미 같은 위치에 도달합니다. 따라서 소규모 배포는 배치 친화성 자체로는 아무런 이득을 얻지 못합니다.

AWS는 엔드포인트 라우팅 계층에서 모델 컨테이너 변경이 필요 없다고 말합니다. 그러나 서빙 프레임워크에는 여전히 정상 작동하는 접두사 캐싱이 필요합니다. 호환되지 않거나 잘못 구성된 엔진은 기본 연산을 재사용하지 못한 채 지역화된 트래픽만 받게 됩니다.

Llama 3.1 70B와 vLLM의 벤치마크 조합은 하나의 중요한 구성을 검증합니다. 그렇다고 모든 아키텍처, 런타임, 양자화 방식, 어댑터 구성 또는 프롬프트 분포에서 동일한 개선이 나타난다는 뜻은 아닙니다.

동적 Low-Rank Adaptation 어댑터는 배치에 또 다른 계층을 더합니다. AWS는 접두사 인식 선택이 이미 요청된 어댑터를 보유한 인스턴스 내에서 작동한다고 말합니다. 이처럼 더 좁은 적격 집합은 라우터의 부하 분산 선택지를 제한할 수 있습니다.

마지막으로 가장 눈에 띄는 지표가 전체 사용자 경험을 뜻하는 것은 아닙니다. 첫 토큰까지 걸리는 시간은 특히 대화형 제품에서 체감 응답성에 영향을 줍니다. 이는 출력 품질, 전체 생성 시간 또는 완료 신뢰성을 직접적으로 설명하지 않습니다.

처리량 개선도 중앙값 지연 시간 개선보다 훨씬 작았습니다. AWS 테스트에서 긴 컨텍스트 처리량은 최대 16% 증가했지만, 짧은 컨텍스트 처리량은 2%를 넘지 않았습니다. 용량 계획은 헤드라인 지연 시간만이 아니라 관련 지표를 사용해야 합니다.

이러한 이유로 77% 수치는 AWS 벤치마크에서 나온 상한 결과로 봐야 합니다. 이는 지역성이 큰 영향을 줄 수 있다는 증거이지, 모든 SageMaker 엔드포인트의 성능을 보장하는 수치는 아닙니다.

세 가지 신호가 프로덕션에서의 효과 지속 여부를 보여줄 것입니다

다음 검증은 고객이 불안정한 핫스팟이나 광범위한 프롬프트 엔지니어링 작업 없이 AWS의 캐시 적중률 향상을 재현할 수 있는지입니다.

첫 번째 신호는 프로덕션 캐시 텔레메트리입니다. 팀은 동일한 트래픽 추적, 플릿 규모, 서빙 엔진, 오토스케일링 정책으로 무작위 라우팅과 접두사 인식 라우팅을 비교해야 합니다. 중앙값 지연 시간만으로는 결과를 설명할 수 없습니다.

KV 캐시 적중률은 낮아진 프리필 지연 시간과 함께 상승해야 합니다. 운영자는 P90 및 P99 첫 토큰 도달 시간, 대기열 깊이, 오버플로 빈도, 인스턴스 수준 트래픽 분포도 추적해야 합니다.

캐시 적중률이 개선되는 동시에 꼬리 지연 시간이 안정적으로 유지된다면 AWS의 핵심 주장은 더 강해집니다. 중앙값 지연 시간은 떨어지지만 오버플로나 P99 지연 시간이 악화된다면, 이점은 더 좁은 배포 기준을 필요로 할 것입니다.

비교에는 콜드 스타트와 확장 기간도 포함해야 합니다. 1시간짜리 정상 상태 벤치마크는 배포, 인스턴스 교체 또는 갑작스러운 스케일아웃 후에 나타나는 워밍업 비용을 가릴 수 있습니다. 실제 서비스는 이러한 전환을 정기적으로 겪습니다.

두 번째 신호는 더 폭넓은 런타임 및 모델 관련 증거다. AWS는 vLLM으로 주요 오픈 모델을 테스트했지만, 고객들은 다양한 아키텍처와 컨테이너를 운영한다. 소형 모델, mixture-of-experts 모델, 양자화 모델, 긴 출력 워크로드 전반의 결과는 이 기능의 적용 범위를 분명히 해줄 것이다.

짧은 컨텍스트 워크로드는 AWS가 이 환경에서 이미 더 작은 처리량 향상을 확인했기 때문에 특히 주목할 필요가 있다. 독립적인 테스트에서도 개선 폭이 제한적인 것으로 재현된다면, prefix-aware routing은 주로 문서 중심 및 에이전트형 애플리케이션에서 가치를 유지할 것이다.

다양한 모델과 프롬프트 패턴에서 비슷한 이점이 나타난다면, 라우팅 지역성은 표준적인 관리형 추론 요구사항으로 자리 잡을 가능성이 크다. 다른 제공업체들은 유사한 구성 옵션과 관측 기능을 제공해야 한다는 압박을 받게 될 것이다.

세 번째 신호는 휴리스틱 기반 prefix affinity에서 명시적인 캐시 상태 라우팅으로의 이동이다. 프리픽스 유사성은 유용한 상태가 존재해야 할 위치를 추정한다. KV-aware 시스템은 플릿 전반에서 실제 블록, 제거 이벤트 또는 전송을 추적할 수 있다.

AWS는 이미 SageMaker HyperPod를 통해 더욱 심층적인 캐시 인식 옵션을 제공하고 있다. 향후 실시간 엔드포인트에서는 더 풍부한 캐시 신호, 분산 캐시 지원 또는 더 적응적인 정책을 제공할 수 있다. 경쟁사와 오픈 소스 프로젝트들도 유사한 방향을 추구하고 있다.

관리형 엔드포인트가 정확한 캐시 상태 인식 기능을 갖추게 된다면, 이번 출시는 더 큰 전환의 접근 가능한 첫 단계로 보일 것이다. 반대로 복잡성 때문에 이런 기능이 특수 클러스터에만 제한된다면, prefix-aware routing은 실용적인 중간 지대로 남을 수 있다.

개발자에게 당장 필요한 것은 가정에 따른 마이그레이션이 아니라 측정이다. 반복되는 프롬프트 구간을 식별하고, 직렬화를 정규화하며, 엔진 수준의 프리픽스 캐싱을 활성화하고, 여러 프리픽스 길이를 테스트해야 한다. 평균뿐 아니라 지연 시간 분포를 비교해야 한다.

엔터프라이즈 구매자는 공급업체에 라우팅 인텔리전스가 어디에 구현되어 있는지, 어떤 지표를 제공하는지 물어야 한다. 프리픽스 캐싱을 내세우면서도 복제본 간 지역성을 유지하지 않는 플랫폼은 규모가 커질수록 기대 이하의 히트율을 보일 수 있다.

지식 노동자들은 이 효과를 간접적으로 경험하게 될 것이다. 동일한 컨텍스트를 반복적으로 사용하는 문서 보조 도구, 코딩 도구, 장기 실행 에이전트는 더 빠르게 응답하기 시작할 것이다. 이 이점은 반드시 답변 전체에 걸쳐 나타나지는 않더라도, 첫 생성 토큰 이전에 드러나야 한다.

Amazon SageMaker prefix-aware routing은 로드 밸런싱이 재사용 가능한 LLM 컨텍스트를 이해해야 한다는 점을 설득력 있게 보여준다. AWS의 결과는 8,000토큰의 공유 프리픽스가 있을 때 캐시를 고려하지 않는 배치가 얼마나 큰 비용을 초래할 수 있는지를 보여준다.

남은 질문은 실제 트래픽이 그러한 유리한 형태와 얼마나 자주 일치하느냐다. 팀은 헤드라인 수치를 운영 예측치로 간주하기 전에 스케일링 이벤트와 혼잡한 프리픽스를 포함한 자체 트레이스를 테스트해야 한다.

캐시 히트율, 가장 느린 요청, 오버플로 라우팅의 빈도를 살펴봐야 한다. 이 지표들을 함께 보면 SageMaker가 유용한 컨텍스트를 보존하고 있는지, 아니면 단지 트래픽을 재배치하고 있는지를 알 수 있다.