Reduce LLM latency with prefix-aware routing on Amazon SageMaker Inference

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Amazon SageMaker Inference의 PREFIX_AWARE는 공통 프롬프트 접두사가 있는 요청을 같은 인스턴스로 보내 KV 캐시 재사용을 높이며, Llama 3.1 70B 벤치마크에서 P50 첫 토큰 지연 시간(TTFT)을 최대 77% 줄이고 처리량을 최대 16% 높였다.

📌 핵심 요약

• 접두사 캐싱은 반복되는 프롬프트 앞부분의 KV 계산을 재사용하지만, 여러 인스턴스에 요청을 무작위로 분산하면 캐시 활용이 어려워진다. PREFIX_AWARE는 같은 접두사의 요청을 같은 인스턴스로 보내고, 과부하 시 다른 인스턴스로 우회하며 확장·축소 시 트래픽 이동을 제한한다.
• AWS는 접두사 캐싱을 활성화한 vLLM과 Llama 3.1 70B Instruct를 ml.p5.48xlarge 인스턴스 7대에서 테스트했다. 16개 구성 모두 요청 성공률 100%였으며, 8,000토큰 공통 접두사를 사용한 1시간 테스트에서 P50 TTFT는 71~77%, P90 TTFT는 33~37% 감소하고 처리량은 15~16% 증가했다.
• 길이가 가변적인 ShareGPT 스타일 대화의 30분 테스트에서는 P50 TTFT가 13~16%, P90 TTFT가 24~37% 감소하고 처리량이 1.7~2.0% 증가했다. KV 캐시 적중률은 긴 문맥에서 약 25%에서 82%로, 짧은 문맥에서 약 30%에서 80%로 상승했으며 라우팅 추가 비용은 요청당 1.3~1.9밀리초였다.
• SageMaker 실시간 엔드포인트는 RANDOM, LEAST_OUTSTANDING_REQUESTS, PREFIX_AWARE를 제공하며 프로덕션 변형별로 설정할 수 있다. PREFIX_AWARE는 RAG, 다중 턴 대화, 템플릿 기반 봇, 코드 완성처럼 공통 접두사가 반복되는 LLM 작업에 적합하고, 모델 재배포 없이 엔드포인트 구성 업데이트로 전략을 바꿀 수 있다.
• 설정값은 PrefixLength 1024~65536과 ConcurrencyThreshold 1~1024이며, PrefixLength의 단위는 네이티브 Invoke API에서 요청 본문의 바이트, OpenAI 호환 API에서 추출된 메시지 텍스트의 문자다. 효과를 얻으려면 최소 2개 인스턴스, 서빙 프레임워크의 접두사 캐싱 활성화, 일관된 요청 직렬화와 적절한 PrefixLength 설정이 필요하며, 모델 수준 KV 캐시 적중률로 효과를 확인할 수 있다.

🧩 주요 포인트

1. 캐시를 고려한 배치 → PREFIX_AWARE는 요청 태그를 직접 관리하지 않고 공통 접두사의 반복 계산을 줄이며, 동시 요청 한도와 확장 시 배치 안정성으로 캐시 재사용과 부하 분산을 조정한다.
2. 공통 접두사 길이에 따른 효과 차이 → 8,000토큰 작업의 처리량 개선은 15~16%인 반면 짧은 대화는 1.7~2.0%여서, 적용 가치는 공유 텍스트의 길이와 실제 KV 캐시 적중률에 따라 평가해야 한다.
3. 설정과 입력 형식이 효과를 좌우 → PrefixLength가 너무 짧으면 요청 집중과 우회가 늘고 너무 길면 작은 입력 차이로 요청이 분산되므로, API별 단위·일관된 요청 직렬화·ConcurrencyThreshold를 함께 고려해야 한다.

🧠 상세 정리

1. 반복 프롬프트 계산과 다중 인스턴스의 한계

LLM 애플리케이션의 프롬프트는 일반적으로 지침·참고 문서·대화 이력 같은 고정 부분과 실제 사용자 입력인 가변 부분으로 구성된다. 원문은 AnyCompany 고객 지원 봇이 매번 3,000토큰의 지침 뒤에 50토큰의 고객 질문을 붙이는 예를 들어, 같은 앞부분이 수백~수천 번 처리되는 문제를 설명한다. vLLM과 TensorRT-LLM의 접두사 캐싱은 이미 계산한 키-값(KV) 쌍을 저장하고 동일한 접두사가 다시 들어오면 재사용해 첫 토큰 지연 시간인 TTFT를 줄인다. 그러나 여러 인스턴스 뒤에 엔드포인트를 두고 요청을 분산하면 같은 접두사가 매번 다른 인스턴스에 도착할 수 있다. 이 경우 각 인스턴스가 같은 계산을 반복하고 캐시를 충분히 재사용하지 못하므로, 캐싱 기능이 있어도 라우팅 방식 때문에 효과가 제한된다.

2. 접두사 기반 라우팅과 두 가지 보호 장치

Amazon SageMaker Inference의 PREFIX_AWARE는 요청 페이로드의 앞부분을 보고 처리할 인스턴스를 선택하며, 같은 시작 부분을 가진 요청은 같은 인스턴스로 보낸다. 예를 들어 접두사를 공유하는 요청 10개가 같은 머신에 도착하면 해당 접두사의 KV 캐시가 유지되고 재사용될 가능성이 높아진다. 사용자가 요청에 태그를 붙이거나 인스턴스와의 연결 관계를 직접 관리할 필요 없이 엔드포인트가 내용에 따라 배치를 처리한다. 특정 접두사가 지나치게 인기를 끌어 대상 인스턴스가 설정된 동시 요청 한도에 도달하면, 캐시 적중 기회를 일부 포기하고 덜 바쁜 인스턴스로 요청을 우회한다. 인스턴스를 추가하거나 제거할 때도 대부분의 요청은 기존 목적지를 유지하고 일부 트래픽만 이동하도록 해, 규모 변경 때마다 캐시 활용이 크게 흔들리는 것을 방지한다.

3. 벤치마크 구성과 긴 문맥의 성능 개선

AWS는 접두사 캐싱이 활성화된 vLLM에서 Llama 3.1 70B Instruct를 실행하고, ml.p5.48xlarge 인스턴스 7대를 사용해 PREFIX_AWARE를 기본 무작위 라우팅과 비교했다. 테스트는 단일 모델 엔드포인트, 추론 컴포넌트 엔드포인트, 네이티브 Invoke API, OpenAI 호환 API를 포함한 16개 구성이었고 모두 요청 성공률 100%를 기록했다. 8,000토큰의 공통 접두사를 사용하는 긴 문맥 작업을 1시간 지속했을 때 P50 TTFT는 71~77%, P90 TTFT는 33~37% 감소했다. 같은 조건에서 KV 캐시 적중률은 약 25%에서 82%로 올라갔고 처리량은 15~16% 증가했다. 이 결과는 긴 공통 접두사일수록 캐시 적중 한 번으로 생략할 수 있는 계산이 많다는 설명을 뒷받침하지만, 제시된 개선 폭은 해당 모델과 테스트 구성에서 측정된 값이다.

4. 짧은 문맥의 효과와 라우팅 비용

길이가 가변적인 ShareGPT 스타일 대화를 30분간 실행한 짧은 문맥 테스트에서는 P50 TTFT가 13~16%, P90 TTFT가 24~37% 감소했다. KV 캐시 적중률은 약 30%에서 80%로 상승했지만 처리량 증가는 1.7~2.0%로, 긴 문맥 테스트보다 작았다. 원문은 공유 접두사가 짧으면 요청마다 생략할 수 있는 계산량도 작아지기 때문에 이러한 차이가 나타난다고 설명한다. 접두사 기반 라우팅 자체의 추가 비용은 요청당 1.3~1.9밀리초였고, 테스트에서 모델 TTFT는 63~280밀리초여서 AWS는 이 비용을 미미한 수준으로 평가했다. 모든 시나리오에서 각 인스턴스가 받은 요청 비중은 13.3~15.4%로 균등 분배에 가까웠으며, 특정 인스턴스에 부하가 집중되는 현상은 관찰되지 않았다고 보고했다.

5. 라우팅 전략 선택과 적합한 사용 사례

SageMaker 실시간 엔드포인트의 기본 전략인 RANDOM은 요청을 인스턴스에 균등하게 분산하며, 범용 작업이나 비LLM 모델처럼 특정 요청을 특정 인스턴스에 보낼 이점이 없는 경우에 권장된다. LEAST_OUTSTANDING_REQUESTS는 처리 중인 요청이 가장 적은 인스턴스를 선택하므로 요청별 처리 시간이 달라 느린 요청이 한 머신에 쌓일 수 있는 상황에 적합하다. PREFIX_AWARE는 공통 프롬프트 앞부분이 반복되고 서빙 프레임워크의 접두사 캐싱이 켜진 LLM 작업에 권장된다. 대표 사례로 같은 문서를 질문 앞에 붙이는 RAG, 이전 대화 이력을 포함하는 다중 턴 대화, 긴 정책·형식·역할 지침을 반복하는 봇, 파일 내용을 문맥으로 제공하는 코드 완성이 제시된다. 라우팅 전략은 프로덕션 변형별로 지정하며, 모델을 재배포하지 않고 엔드포인트 구성을 업데이트해 전환할 수 있다.

6. 설정 범위와 기존 호출 방식의 유지

접두사 기반 라우팅은 엔드포인트 구성을 만들 때 RoutingStrategy를 PREFIX_AWARE로 지정하고 PrefixAwareRoutingConfig 안에 두 매개변수를 넣어 활성화한다. PrefixLength의 범위는 1024~65536이며, 네이티브 Amazon SageMaker Invoke API에서는 요청 본문 시작부터의 바이트 수, OpenAI 호환 API에서는 추출된 메시지 텍스트의 문자 수를 뜻한다. ConcurrencyThreshold의 범위는 1~1024이고, 대상 인스턴스에서 처리 중인 요청이 이 한도에 도달하면 덜 바쁜 인스턴스로 우회한다. 원문의 구성 예시는 ml.p5.48xlarge 인스턴스 3대에 PrefixLength 4096과 ConcurrencyThreshold 10을 설정한 뒤 해당 구성으로 엔드포인트를 생성한다. 기능은 엔드포인트 라우팅 계층에서 동작하므로 모델 컨테이너나 서빙 프레임워크를 변경할 필요가 없으며, 기존 InvokeEndpoint, InvokeEndpointWithResponseStream, OpenAI 호환 Chat Completion API 호출 방식도 유지된다.

7. 테넌트 분리와 추론 컴포넌트·LoRA 지원

서로 다른 테넌트가 같은 프롬프트 지침을 사용하더라도 캐시 문맥을 독립적으로 유지하도록 라우팅을 분리하고 싶다면 선택적 식별자를 전달할 수 있다. 네이티브 Invoke API에서는 최대 64개 ASCII 문자의 X-Amzn-SageMaker-Prefix-Aware-Id 헤더를 사용하고, OpenAI API에서는 요청 본문에 prompt_cache_key 필드를 포함한다. 원문에 따르면 이 식별자가 접두사와 결합되어, 접두사가 같아도 식별자가 다른 요청은 서로 다른 인스턴스로 전달된다. 접두사 기반 라우팅은 추론 컴포넌트 엔드포인트에서도 지원되며, 이 경우 단일 모델 엔드포인트와 동일하게 동작한다. 동적 Low-Rank Adaptation(LoRA) 어댑터를 사용할 때는 해당 어댑터가 이미 로드된 고정 인스턴스 집합 안에서 접두사에 따라 인스턴스를 선택한다.

8. 실제 효과를 얻기 위한 운영 조건

PREFIX_AWARE는 반복 접두사를 같은 인스턴스로 전달하는 기능이므로, KV 쌍을 실제로 저장하고 재사용하려면 서빙 프레임워크의 접두사 캐싱이 활성화되어 있어야 한다. 최근 vLLM 버전에서는 기본 활성화되어 있지만 다른 프레임워크는 명시적 설정이 필요할 수 있으며, 인스턴스가 하나뿐이면 모든 요청의 목적지가 같으므로 최소 2개가 필요하다. 네이티브 Invoke API의 PrefixLength는 원시 바이트를 기준으로 하므로 JSON 공백·키 순서·형식이 달라지면 같은 프롬프트도 다른 인스턴스로 갈 수 있어 직렬화를 일관되게 유지해야 한다. PrefixLength가 너무 짧으면 공통 앞부분을 가진 요청이 몰려 우회가 발생하고, 너무 길면 temperature 값 같은 작은 차이로 요청이 흩어질 수 있으므로 원문은 공통 접두사 길이에 적당한 여유를 더한 값에서 시작하도록 권한다. SageMaker 상세 관측 기능으로 모델 수준 KV 캐시 적중률을 추적해 실제 작업에서 효과를 확인할 수 있다. 원문은 이 기능이 SageMaker 실시간 추론 엔드포인트에서 제공된다고 밝히며, 새 설정 매개변수에 접근하려면 AWS SDK 또는 CLI를 최신 버전으로 업데이트하도록 안내한다.

🧾 핵심 주장 / 시사점

• 접두사 캐싱의 성능은 캐시 기능 자체뿐 아니라 반복 요청이 어느 인스턴스에 도착하는지에도 좌우된다. 라우팅 계층과 서빙 프레임워크의 캐싱을 함께 맞춰야 재사용 효과가 나타난다.
• 짧은 문맥에서도 캐시 적중률은 크게 상승했지만 처리량 증가는 제한적이었다. 캐시 적중률 상승만으로 전체 성능 개선을 판단하기보다 접두사 길이, TTFT, 처리량을 함께 해석할 필요가 있다.
• 과부하 우회는 개별 요청의 캐시 적중보다 인스턴스 부하 한도를 우선한다. 따라서 PrefixLength와 ConcurrencyThreshold는 캐시 재사용과 요청 집중 사이의 균형에 영향을 주는 설정이다.

✅ 액션 아이템

• RAG, 다중 턴 대화, 템플릿 기반 봇, 코드 완성에서 공통 접두사의 길이와 반복 여부를 파악해 PREFIX_AWARE 적용 적합성 평가.
• 최소 2개 인스턴스와 접두사 캐싱 활성화를 확인하고, API별 단위 및 일관된 요청 직렬화를 고려해 PrefixLength와 ConcurrencyThreshold 설정 검토.
• PREFIX_AWARE 적용 전후의 KV 캐시 적중률, P50·P90 TTFT, 처리량을 비교해 실제 작업의 개선 폭 확인.

❓ 열린 질문

• 적용 대상의 공통 접두사 길이와 반복 양상은 8,000토큰 작업과 짧은 ShareGPT 스타일 대화 중 어느 테스트 조건에 더 가까운가?
• API별 PrefixLength 단위와 요청 직렬화를 고려할 때, 요청 집중과 불필요한 분산을 줄일 PrefixLength 및 ConcurrencyThreshold 값은 무엇인가?
• 최소 2개 인스턴스와 접두사 캐싱 활성화 조건에서 PREFIX_AWARE를 적용하면 KV 캐시 적중률, P50·P90 TTFT, 처리량은 각각 얼마나 달라지는가?