멀티 리전 LLM 서빙과 KV 캐시 지역성(Multi-Region LLM Serving and KV Cache Locality)

라운드 로빈 부하 분산(round-robin load balancing)은 캐시(cache)를 활용하는 LLM 추론(inference)에 오히려 해롭습니다. 자신의 접두부(prefix)를 보유한 노드(node)에 도달하지 못한 요청은 전체 프리필(prefill) 비용을 지불해야 합니다. 긴 프롬프트(prompt)에서 캐시가 빗나가면 P50 기준 약 800ms가 걸리고, 캐시에 적중하면 약 80ms 수준입니다. 2026년의 운영 환경(production) 패턴은 캐시 인식 라우터(cache-aware router)입니다. 예를 들어 Rust로 작성된 vLLM Router나 llm-d router는 KV 캐시 이벤트(KV-cache event)를 구독하면서 접두부 해시(prefix-hash)가 일치하는 노드로 라우팅합니다. 최근 연구인 GORGO는 리전(region)간 네트워크 지연(network latency)을 라우팅 목적 함수(routing objective)의 명시적인 항으로 포함시킵니다. Bedrock cross-region inference나 GKE multi-cluster gateway 같은 상용 "리전간 추론(cross-region inference)" 기능은 추론 자체를 불투명한(opaque) 박스로 취급합니다. 이들은 가용성(availability)은 다루지만 첫 토큰 응답 시간(Time To First Token; TTFT)을 최적화하지는 않습니다. JPMorgan과 Mayo Clinic은 2024년 11월 us-east-1 장애 조치(failover) 훈련에서 약 22분을 기록했습니다. 재해 복구(Disaster Recovery; DR)의 현실은 이렇습니다. LLM DR 실패의 32%는 팀이 가중치(weights)는 백업했지만 토크나이저(tokenizer) 파일이나 양자화 설정(quantization config)을 잊어버려서 발생합니다.

유형: Learn 언어: Python (표준 라이브러리, 장난감 수준의 접두부 캐시 인식 라우터 시뮬레이터(prefix-cache-aware router simulator)) 선수 지식: Phase 17 · 04 (vLLM Serving), Phase 17 · 06 (SGLang RadixAttention) 예상 시간: 약 60분

학습 목표

• 라운드 로빈 부하 분산이 캐시 기반 추론을 어떻게 깨뜨리는지 설명하고, TTFT 페널티(penalty)를 정량화할 수 있습니다.
• 캐시 인식 라우터를 도식화할 수 있습니다. 입력은 KV 캐시 이벤트, 알고리즘은 접두부 해시 일치 판단, 동률 처리(tie-breaker)는 GPU 사용률입니다.
• LLM DR 실패 원인의 32%를 차지하는 핵심 요인, 즉 토크나이저 파일이나 양자화 설정 누락 문제를 짚어내고 세 파일 단위의 DR 체크리스트(checklist)를 제시할 수 있습니다.
• Bedrock CRI, GKE Multi-Cluster Gateway 같은 상용 리전간 추론 기능과 KV 인식 라우팅(KV-aware routing)을 구분할 수 있습니다.

문제

서비스가 us-east-1, us-west-2, eu-west-1 세 리전에서 동시에 동작하고 있다고 가정합니다. 앞단에는 라운드 로빈 방식으로 트래픽을 분산하는 ALB를 두었습니다. 그러자 운영 환경의 접두부 캐시 적중률(prefix cache hit rate)이 8%까지 떨어지고, TTFT P50은 세 배로 늘어납니다. vLLM 로그를 들여다보면 모든 요청이 전체 프리필 비용을 처음부터 다시 치르고 있습니다.

라운드 로빈은 상태가 없는(stateless) 서비스에는 최적의 선택입니다. 하지만 LLM 추론은 설계 자체가 상태 기반(stateful)입니다. KV 캐시는 모델이 지금까지 본 모든 토큰의 상태를 인코딩(encode)하고 있기 때문입니다. 캐시 상태를 모른 채 라우팅하는 것은 결국 잘못된 캐시로 요청을 흘려보내는 것과 같습니다.

여기에 더해, 팀에는 별도의 DR 계획이 있다고 합시다. 모델 가중치를 S3의 리전간 복제(cross-region) 버킷(bucket)에 백업해 둡니다. 어느 날 특정 리전에 장애가 발생하고 장애 조치를 시도하지만, 복제본(replica)은 시작조차 거부합니다. 이유는 단순합니다. tokenizer.json, 양자화 설정, RoPE 스케일링(scaling) 설정 같은 파일들이 동기화하지 않은 별도 버킷에 들어 있었기 때문입니다.

멀티 리전 LLM 서빙은 결국 캐시 문제이자 라우팅 문제이고, DR 위생(hygiene) 문제입니다. 단순한 부하 분산기(load balancer) 문제로 환원되지 않습니다.

개념

캐시 인식 라우팅(cache-aware routing)

요청이 프롬프트와 함께 들어오면, 라우터는 먼저 접두부를(예를 들어 첫 512 토큰을) 해시(hash)합니다. 그리고 각 복제본에게 "이 접두부를 캐시에 가지고 있는가?"를 묻습니다. 복제본들은 블록(block)을 할당(allocate)하거나 축출(evict)할 때마다 게시·구독(pub/sub) 채널로 KV 캐시 이벤트를 발행(publish)합니다. 라우터는 일치하는 복제본이 있으면 그쪽을 선택하고, 일치하는 복제본이 없을 때는 GPU 사용률(GPU utilization)이나 대기열 길이(queue depth)를 동률 처리 기준으로 사용합니다.

vLLM Router는 2026년 production-stack에서 사용하는 Rust 라우터입니다. kv.cache.block_added 이벤트를 구독(subscribe)하면서 접두부 해시에서 복제본으로 향하는 색인(prefix-hash → replica index)을 관리하고, O(1) 조회(lookup)로 라우팅합니다. 일치하는 복제본이 없을 때는 가장 대기열이 짧은(least-queue-depth) 복제본으로 떨어집니다.

llm-d router도 같은 패턴(pattern)을 따릅니다. Kubernetes 네이티브(Kubernetes-native)로 동작하며 ControlPlane API를 통해 이벤트를 발행합니다.

SGLang RadixAttention(Phase 17 · 06)은 복제본 내부(intra-replica)에서 작동하는 동일한 개념의 메커니즘입니다. 복제본간 라우팅(cross-replica routing)은 그보다 한 단계 위인 상위 계층(upstream)에 위치합니다.

숫자로 본 차이

H100에서 Llama 3.3 70B FP8 모델, 2K 토큰 프롬프트 기준 TTFT P50은 다음과 같습니다.

• 캐시 적중(같은 복제본에 접두부가 상주(resident)함): 약 80ms.
• 캐시 미스(차가운(cold) 상태의 프리필): 약 800ms.

10배 차이입니다. 라우터가 여러 복제본에 걸쳐 접두부 캐시를 60~80% 적중시키면, N개의 복제본 용량으로도 단일 복제본(single-replica) 수준의 응답 성능에 근접하게 됩니다. 반대로 적중률이 10% 수준에 머문다면 캐시를 활용하지 못하는 단순 확장(naive scaling)과 다를 바 없는 성능을 얻습니다.

리전간 라우팅에는 새로운 제약이 따릅니다 — 네트워크 지연

리전간 RTT는 대략 다음과 같습니다.

• us-east-1 ↔ us-west-2: 약 65ms.
• us-east-1 ↔ eu-west-1: 약 75ms.
• us-east-1 ↔ ap-southeast-1: 약 220ms.

라우터가 us-east-1에서 들어온 요청을 인기 접두부(hot prefix)가 있는 ap-southeast-1로 보내면, 프리필 절감 효과(800 → 80ms)는 440ms의 왕복 네트워크 지연에 의해 완전히 잠식됩니다. GORGO(2026 연구)는 이 점을 명시적으로 다룹니다. 프리필만 따로 최소화하지 말고 prefill_time + network_latency를 한꺼번에 최소화해야 한다는 것입니다. 정답은 대개 라우팅을 리전 단위로 유지하는 것이며, 수 MB에 달하는 거대 접두부처럼 프리필 비용이 네트워크 지연을 압도하는 경우에만 예외가 됩니다.

상용 "리전간 추론"은 여기서 충분한 해답이 되지 못합니다

AWS Bedrock cross-region inference는 용량 압박(capacity pressure)이 발생할 때 요청을 다른 리전으로 자동 라우팅합니다. 이는 가용성을 최적화하지 TTFT를 최적화하는 것이 아니며, 추론 자체를 불투명한 박스로 취급합니다. GKE Multi-Cluster Gateway도 마찬가지로 서비스 단위 장애 조치(service-level failover)는 제공하지만 KV 캐시 상태는 알지 못합니다.

이런 기능을 사용하더라도 애플리케이션 계층(app-layer)의 캐시 인식 라우터는 별도로 필요합니다. 상용 기능은 "us-east-1에 불이 났다" 같은 가용성 시나리오를 다루고, 캐시 인식 라우팅은 TTFT 문제를 다룹니다.

DR 위생 — 32% 누락 파일 문제

널리 인용되는 2026년 통계에 따르면 LLM DR 실패의 32%는 가중치는 백업했지만 다음과 같은 파일들을 잊어버렸기 때문에 발생합니다.

• tokenizer.json 또는 tokenizer.model
• 양자화 설정 (quantize_config.json, AWQ scale, GPTQ zero-point)
• 모델 고유 설정 (RoPE scaling, attention mask, chat template)
• 엔진 설정 (vllm_config.yaml, sampling 기본값, LoRA adapter manifest)

해결책은 세 파일 단위의 최소 DR 매니페스트(manifest)를 유지하는 것입니다.

1. HF 모델 저장소(repository) 아래의 모든 파일(가중치 + 설정 + 토크나이저).
2. 엔진별(engine-specific) 서빙 설정.
3. 배포 매니페스트(K8s YAML, Dockerfile, 의존성 lock 파일).

추가로 분기마다 DR 훈련(drill)을 실시해야 합니다. JPMorgan이 2024년 11월 us-east-1 훈련에서 22분 만에 복구를 마칠 수 있었던 것은 플레이북(playbook)을 실제로 반복 연습해 두었기 때문입니다.

데이터 거주성(data residency)은 별개의 제약입니다

EU 고객의 보호 대상 건강 정보(Protected Health Information; PHI)는 EU 밖으로 나갈 수 없습니다. 캐시 인식 라우터가 접두부 일치를 이유로 파리에서 출발한 요청을 us-east-1로 보낸다면, TTFT 이득이 얼마든 GDPR을 위반한 것이 됩니다. 캐시를 최적화하기 전에 라우터를 거주성 경계(residency boundary)별로 분할(partition)해야 합니다.

기억해야 할 숫자

• 캐시 적중 대비 빗나감의 TTFT 격차: 약 10배 (2K 프롬프트에서 80ms vs 800ms).
• 미국 ↔ 유럽 리전간 RTT: 약 75ms.
• DR 실패 원인: 32%가 토크나이저 또는 양자화 설정 누락.
• JPMorgan us-east-1 장애 조치, 2024년 11월: 22분 (30분 SLA).

사용해보기

code/main.py는 멀티 리전 워크로드(workload) 위에서 세 가지 라우팅 전략, 즉 round-robin, cache-aware regional, cache-aware global을 시뮬레이션합니다. 캐시 적중률, TTFT P50/P99, 리전간 트래픽 비용을 함께 보고합니다.

산출물 만들기

이 lesson은 outputs/skill-multi-region-router.md를 만듭니다. 리전 구성, 거주성 제약, SLA가 주어지면 그에 맞는 라우팅 계획을 설계하는 skill입니다.

연습문제

1. 쉬움: code/main.py를 실행해 보세요. RTT가 75ms일 때, 어떤 프롬프트 길이에서부터 리전간 라우팅(cross-region routing)이 로컬 전용 라우팅(local-only routing)을 이기게 됩니까?
2. 중간: 캐시 적중률이 70%에서 12%로 떨어졌습니다. 가능한 원인을 세 가지 들고, 각 원인을 확인할 수 있는 관찰 지표(observable)를 함께 제시하세요.
3. 중간: vLLM에서 5개의 LoRA 어댑터(adapter)와 함께 서빙되는 70B AWQ 양자화 모델의 DR 매니페스트를 설계하세요. 필요한 모든 파일과 설정을 나열하세요.
4. 어려움: 엄격한 TTFT SLO를 가진 핀테크(fintech) 회사에 Bedrock cross-region inference가 "충분한" 해답인지 논증해 보세요. 근거가 되는 구체적인 동작을 함께 인용하세요.
5. 어려움: 파리에서 출발한 요청이 us-east-1의 접두부와 일치하는 상황을 가정하세요. 이 요청을 그쪽으로 라우팅하겠습니까? 정책(policy)을 작성해 보세요.

핵심 용어

더 읽을거리

• BentoML — Multi-cloud and cross-region inference
• arXiv — GORGO (2602.11688) — 네트워크 지연 항을 포함한 리전간 KV 캐시 재사용 연구입니다.
• TianPan — Multi-Region LLM Serving Cache Locality
• AWS Bedrock Cross-Region Inference — 가용성 장애 조치 관련 공식 문서입니다.
• vLLM Production Stack Router — 캐시 인식 라우터의 소스 코드입니다.