멀티턴 에이전트 서빙에서 프리픽스 캐시 히트율은 왜 무너졌나?

원인은 캐싱 자체가 아니라 라우팅이었다. round-robin 로드밸런서가 같은 대화의 연속 턴을 서로 다른 replica로 흩뿌리면서, 프리픽스 캐시가 있어도 재사용될 기회 자체가 사라졌다. prefix-aware 라우팅으로 바꾸자 같은 워크로드에서 히트율이 vLLM 블로그가 보고한 1.7%에서 92.2%로 올라갔고, throughput은 3.8배, P50 TTFT는 46배 개선됐다.

  • 프리픽스 캐싱은 히트율 0%에서도 throughput 손실이 1% 미만이라, 상시 켜두는 데 드는 비용은 거의 없다.
  • 문제는 대개 "캐시가 있는가"가 아니라 "같은 prefix가 같은 replica에 도달하는가"다.
  • round-robin은 hit rate 15.8%, prefix-tree-aware 스케줄링은 82.6% 수준으로 4~5배 차이가 난다.
  • 배치 크기와 히트율은 트레이드오프 관계라, 배치를 무작정 키우면 오히려 캐시 정렬이 깨진다.
  • GPU 메모리 확장만으로는 히트율이 50% 근처에서 막히는 구조적 한계가 있다.

증상은 트래픽 증가 이후에 나타났다. 에이전트 API가 단일 replica로 운영되던 시점엔 p99 TTFT가 SLO 안에 있었다. 스케일아웃 후 round-robin LB를 붙였고, 그 직후부터 같은 대화의 2턴째부터 TTFT가 튀기 시작했다. 대화가 길어질수록(중앙값 33턴짜리 에이전트 trace 기준) 지연은 누적됐고, throughput은 replica 수를 늘려도 비례해서 오르지 않았다.

배치 사이즈를 키우면 히트율도 따라 오르는가?

아니다. 오히려 반대 방향으로 움직였다. cache pressure가 높은 환경에서는 최적 batch size가 2~4배 낮아진다는 관찰이 있는데, 우리 환경에서도 배치를 키워 처리량을 확보하려 했더니 prefix 정렬이 깨지면서 히트율이 더 떨어졌다. 배치와 히트율은 같은 다이얼로 동시에 최적화되는 관계가 아니었다.

프리픽스 캐싱이 꺼져 있던 게 문제였나?

아니다. 캐싱은 켜져 있었다. vLLM V1 기준으로 프리픽스 캐싱은 히트율이 0%인 최악의 경우에도 오버헤드가 1% 미만이라, "켜져 있었는데 왜 효과가 없었나"가 실제 질문이었다. 캐싱 기능의 유무가 아니라 캐싱이 작동할 조건(같은 replica 도달)이 갖춰지지 않은 게 문제였다.

GPU 메모리를 늘리면 해결되는 문제였나?

아니다. 메모리를 늘려 KV 캐시 보관 용량을 키워도, 프리픽스 캐싱만으로는 히트율이 50% 수준에서 막힌다는 관찰이 있다. 우리 상황은 그 이전 단계, 즉 애초에 같은 prefix가 같은 노드로 라우팅되지 않는 문제였기 때문에 메모리 증설은 근본 처방이 아니었다.

그럼 실제 원인은 무엇이었나?

round-robin 로드밸런싱이 요청의 대화 맥락(같은 세션의 연속 턴)을 전혀 고려하지 않았다는 것이 원인이었다. 8 pod, pod당 GPU, 다수 고객 그룹, 그룹별 수천 토큰 공유 prefix 같은 구조에서는 라우팅 정책이 곧 히트율 정책이 된다. round-robin은 이 구조를 무시했고, 그 결과가 15.8% 수준의 히트율로 나타났다.

무엇을 바꿨고, 무엇이 달라졌나?

로드밸런서를 세션/prefix 인지형으로 바꾸고 shared KV store를 도입했다. 같은 조건에서 히트율은 92.2%까지 올랐고, throughput 3.8배, P50 TTFT 46배 개선이 확인됐다. 별도 벤치마크에서는 prefix-affinity 라우팅이 cache-blind 대비 히트율을 64.1%에서 93.2%로 끌어올리면서 p99 SLO 3.5초 안에서 QPS를 유지한 사례도 있어, 방향성은 일치했다. Red Hat 개발자 블로그가 정리한 V1 아키텍처 문서도 이 재구성이 multi-step scheduling 없이 throughput 개선을 낸다고 설명한다.

이 사례에서 스택 밖으로 가져갈 교훈은 무엇인가?

2026년 기준으로 정리하면, 프리픽스 캐싱을 켜는 결정과 라우팅을 프리픽스 인지형으로 바꾸는 결정은 별개의 문제다. 캐싱은 켜두는 비용이 거의 없으니 항상 켜두되, 히트율은 결국 로드밸런서가 같은 prefix를 같은 노드로 보내는가에 달려 있다. round-robin이나 least-load 같은 캐시 무관 정책은 구조적으로 낮은 히트율에 수렴하므로, 멀티턴·에이전트 워크로드에서는 라우팅 정책 자체를 캐시 위상에 맞춰 설계해야 한다.

핵심 정리

  • 프리픽스 캐싱은 히트율 0%에서도 손실이 1% 미만이라 상시 활성화가 합리적이다.
  • 히트율 저하의 실제 원인은 대개 캐싱 기능이 아니라 라우팅 정책이다.
  • round-robin(15.8%)과 prefix-tree-aware(82.6%) 사이에는 4~5배 격차가 존재한다.
  • 배치 크기 확대는 처리량뿐 아니라 캐시 정렬도 함께 흔들므로 별도로 튜닝해야 한다.
  • 멀티턴/에이전트 워크로드에서는 shared KV store·prefix-aware 라우팅 도입이 히트율과 TTFT를 동시에 개선한 사례가 반복적으로 보고된다.

더 알아보기

LLM 추론 서빙: 처리량과 지연의 트레이드오프를 보는 법 — 이 주제의 종합 가이드