본문으로 건너뛰기
AWS ML Blog조회 1회

SageMaker, Prefix-Aware Routing으로 LLM 지연 단축

SageMaker의 Prefix-Aware Routing이 반복되는 LLM 입력을 같은 인스턴스로 보내 KV 캐시 재사용을 높인다

이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.

TL;DR

LLM 서비스에서 긴 프롬프트 앞부분이 반복되면 vLLM과 TensorRT-LLM의 Prefix Caching이 KV 캐시를 재사용해 TTFT를 줄일 수 있지만, 여러 인스턴스에 요청이 무작위로 분산되면 같은 prefix가 서로 다른 캐시에 흩어져 효과가 약해집니다. Amazon SageMaker Inference의 Prefix-Aware Routing은 요청 앞부분을 기준으로 같은 prefix를 같은 인스턴스에 보내 캐시를 유지하며, Llama 3.1 70B와 7개 ml.p5.48xlarge 인스턴스를 사용한 테스트에서 P50 TTFT를 최대 77% 줄이고 처리량을 최대 16% 높였습니다. 긴 8,000-token 공통 prefix에서는 KV cache hit rate가 약 25%에서 82%까지 올랐고, 라우팅 오버헤드는 요청당 1.3–1.9밀리초였습니다. 다만 PrefixLength와 동시 요청 한도를 workload에 맞게 조정하고, 컨테이너에서 Prefix Caching을 활성화해야 실제 효과를 얻을 수 있습니다.

섹션별 상세

01
LLM 요청은 정책, 참조 문서, 대화 기록처럼 반복되는 고정 prefix와 사용자가 새로 입력하는 가변 부분으로 구성됩니다. vLLM과 TensorRT-LLM은 고정 prefix를 처리한 뒤 생성되는 key-value 쌍을 KV 캐시에 저장하고, 같은 prefix가 다시 오면 끝부분의 새 토큰만 계산합니다. 그러나 여러 인스턴스에 요청을 무작위로 분산하면 동일한 3,000-token prefix가 각 인스턴스에서 충분히 반복되지 않아 캐시가 안정적으로 쌓이지 않는 문제가 생깁니다.
02
Amazon SageMaker Inference의 Prefix-Aware Routing은 요청 payload의 앞부분을 읽어 같은 시작 구간을 같은 인스턴스로 보내는 방식입니다. 같은 prefix를 공유하는 10개 요청이 한 머신에 모이면 해당 머신의 KV 캐시가 warm 상태를 유지하고 후속 요청에서 계산을 재사용합니다. 사용자가 요청에 affinity 태그를 붙이거나 별도 세션 관리를 할 필요 없이 endpoint 라우팅 계층에서 처리됩니다.
03
특정 prefix가 지나치게 많이 몰리는 상황에서는 대상 인스턴스의 동시 요청 수가 설정한 ConcurrencyThreshold를 넘을 때 덜 바쁜 인스턴스로 요청을 넘깁니다. 이 경우 한 번의 캐시 적중을 놓칠 수 있지만 단일 머신 과부하를 피할 수 있습니다. 인스턴스를 추가하거나 제거할 때도 트래픽 대부분은 기존 배치를 유지하고 변경된 fleet에 맞춰 일부 요청만 이동하므로 전체 캐시가 매번 무효화되지 않습니다.
04
Llama 3.1 70B Instruct를 7개 ml.p5.48xlarge 인스턴스에서 vLLM Prefix Caching과 함께 실행한 16개 테스트 구성에서 모든 요청이 100% 성공했습니다. 8,000-token 공통 prefix를 1시간 동안 유지한 장문 workload에서는 P90 TTFT가 33–37%, P50 TTFT가 71–77% 줄었고, KV cache hit rate가 약 25%에서 82%로 상승했으며 처리량은 15–16% 늘었습니다. ShareGPT-style 가변 길이 대화에서는 P90 TTFT가 24–37%, P50 TTFT가 13–16% 줄고 처리량이 1.7–2.0% 증가해 공통 prefix가 길수록 이득이 커졌습니다.
bash
aws sagemaker create-endpoint-config \
 --endpoint-config-name example-llm-config \
 --production-variants '[{ "VariantName": "AllTraffic", "ModelName": "example-llm-model", "InitialInstanceCount": 3, "InstanceType": "ml.p5.48xlarge", "RoutingConfig": { "RoutingStrategy": "PREFIX_AWARE", "PrefixAwareRoutingConfig": { "PrefixLength": 4096, "ConcurrencyThreshold": 10 } } }]'

PREFIX_AWARE 라우팅과 PrefixLength 4096, ConcurrencyThreshold 10을 포함한 SageMaker endpoint configuration을 생성합니다.

bash
aws sagemaker create-endpoint \
 --endpoint-name example-llm-endpoint \
 --endpoint-config-name example-llm-config

앞서 만든 endpoint configuration으로 SageMaker endpoint를 생성합니다.

05
Prefix-Aware Routing은 요청당 1.3–1.9밀리초의 라우팅 비용을 추가하지만, 테스트에서 모델 TTFT가 63–280밀리초였기 때문에 전체 지연에서 차지하는 비중은 작았습니다. 7개 인스턴스에는 각각 전체 요청의 13.3–15.4%가 배분되어 이상적인 균등 분배와 1% 이내 차이를 보였고 hot spot도 발생하지 않았습니다. SageMaker real-time endpoint는 기존 RANDOM과 LEAST_OUTSTANDING_REQUESTS에 새 PREFIX_AWARE를 추가하며, 모델을 재배포하지 않고 production variant의 endpoint configuration을 갱신해 전략을 바꿀 수 있습니다.
bash
aws sagemaker-runtime invoke-endpoint \
 --endpoint-name example-llm-endpoint \
 --content-type application/json \
 --body fileb://request.json \
 output.json

기존 InvokeEndpoint API를 사용해 prefix-aware routing이 적용된 endpoint를 호출합니다.

python
from openai import OpenAI
from sagemaker.core.token_generator import generate_token
client = OpenAI(
 base_url=f"https://runtime.sagemaker.us-west-2.amazonaws.com"
 f"/endpoints/example-llm-endpoint/openai/v1",
 api_key=generate_token(region="us-west-2")
)
response = client.chat.completions.create(
 model="example-model",
 messages=[
 {"role": "user", "content": "What is your return policy?"},
 ],
)

SageMaker의 OpenAI-compatible Chat Completion API를 기존 OpenAI client 형식으로 호출합니다.

용어 해설

Prefix Caching
— LLM 요청에서 반복되는 프롬프트 앞부분의 key-value(KV) 쌍을 저장해 재사용하는 기법입니다. 같은 prefix가 다시 들어오면 모델이 해당 토큰을 처음부터 계산하지 않고 캐시된 중간 결과를 불러온 뒤 새 입력만 처리합니다. 이 방식은 첫 토큰 생성 시간인 TTFT와 반복 계산 비용을 줄이는 데 중요합니다.
KV 캐시(KV Cache)
— Transformer가 이전 토큰을 처리하며 계산한 key와 value를 저장하는 메모리 구조입니다. 후속 요청이나 이어지는 대화에서 동일한 토큰 구간을 다시 계산하지 않고 저장된 값을 재사용해 추론 지연을 줄입니다. Prefix Caching의 실제 재사용 단위로 작동합니다.
첫 토큰 생성 시간(Time-to-First-Token)
— 요청을 받은 뒤 모델이 첫 번째 출력 토큰을 반환할 때까지 걸리는 시간입니다. 긴 입력 prefix를 매번 다시 계산하면 TTFT가 커지며, prefix-aware routing과 KV 캐시는 반복되는 prefix 계산을 건너뛰어 이 지연을 낮춥니다.
Prefix-Aware Routing
— 요청의 앞부분을 기준으로 동일한 prefix를 가진 요청을 같은 추론 인스턴스로 보내는 라우팅 전략입니다. 한 인스턴스에 해당 prefix의 KV 캐시가 계속 쌓이므로 여러 인스턴스에 요청이 흩어져 캐시가 무효화되는 문제를 줄입니다.
검색 증강 생성(Retrieval-Augmented Generation)
— 사용자 질문과 관련된 문서를 검색한 뒤 그 내용을 LLM 입력 앞부분에 붙여 응답을 생성하는 방식입니다. 여러 사용자가 같은 문서에 질문하면 문서 구간이 공통 prefix가 되므로, Prefix-Aware Routing과 Prefix Caching을 함께 적용할 수 있습니다.

기술

  • Amazon SageMaker Inference
  • vLLM
  • TensorRT-LLM
  • Llama 3.1 70B Instruct
  • AWS CLI
  • InvokeEndpoint API
  • InvokeEndpointWithResponseStream API
  • OpenAI-compatible Chat Completion API
  • LoRA

활용 사례

  • Retrieval-Augmented Generation 애플리케이션
  • Multi-turn 대화
  • 정책과 형식 규칙을 반복해서 보내는 템플릿 기반 bot과 assistant
  • 파일 내용을 반복 입력하는 code completion
AI 분석 전체 내용 보기

AI 요약 · 북마크 · 개인 피드 설정 — 무료

출처 · 인용 안내

원문 발행 2026. 09. 11.수집 2026. 09. 11.출처 타입 RSS

인용 시 "요약 출처: AI Trends (aitrends.kr)"를 표기하고, 사실 확인은 원문 보기 기준으로 진행해 주세요. 자세한 기준은 운영 정책을 참고해 주세요.