KV 캐시 로컬리티: 로드 밸런서가 GPU 연산을 낭비하는 이유와 해결책

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

핵심 요약

기존의 라운드 로빈 방식 로드 밸런서는 GPU 간의 KV 캐시 공유 상태를 고려하지 않아 동일한 시스템 프롬프트나 RAG 컨텍스트를 여러 GPU에서 중복 계산하는 비효율을 초래한다. 트랜스포머의 Prefill 단계는 연산 집약적이며, 4,000 토큰 기준 Llama 3.1 70B 모델에서 1초 이상의 시간이 소요되는데 이를 캐시로 대체하면 지연 시간을 획기적으로 줄일 수 있다. 본 아티클은 Prefix-aware 라우팅을 통해 캐시 적중률을 12.5%에서 97.5%로 높이고, 테일 레이턴시(P99)를 85.3% 개선한 벤치마크 결과를 공유한다. 결과적으로 모델 크기가 크고 공유 컨텍스트가 긴 환경일수록 이러한 토큰 로컬리티 최적화가 GPU 비용 절감과 사용자 경험 개선에 필수적임을 입증한다.

배경

KV Cache 메커니즘에 대한 이해, Prefill vs Decode 단계의 차이점, vLLM 등 LLM 서빙 엔진의 작동 원리

대상 독자

LLM 추론 인프라를 운영하며 GPU 비용 및 지연 시간 최적화가 필요한 MLOps 엔지니어

의미 / 영향

이 기술은 대규모 LLM 서비스의 경제성을 결정짓는 핵심 요소로 작용할 것입니다. 특히 컨텍스트 윈도우가 확장됨에 따라 단순한 부하 분산이 아닌 데이터 위치 기반의 지능형 라우팅이 표준 아키텍처로 자리 잡을 것으로 보입니다.

섹션별 상세

기존 로드 밸런싱 알고리즘은 연결 수만 계산할 뿐 토큰의 로컬리티를 이해하지 못해 GPU 자원을 낭비한다. 라운드 로빈 방식은 동일한 시스템 프롬프트를 가진 요청을 서로 다른 GPU로 분산시켜, 이미 다른 카드에 존재하는 KV 캐시를 활용하지 못하고 중복 Prefill 연산을 수행하게 만든다. 이로 인해 8개의 GPU를 사용할 경우 동일한 작업을 8번 결제하는 것과 같은 비용 비효율이 발생한다.

트랜스포머 추론은 Prefill과 Decode 두 단계로 나뉘며, Prefill 단계의 KV 캐시 적중 여부가 성능을 결정한다. Prefill은 입력 토큰의 키-값 쌍을 계산하는 고비용 연산인 반면, Decode는 이를 재사용하는 저비용 단계이다. CodeLlama 13B 기준 캐시 적중 시 TTFT는 18ms이지만, 미적중 시 500ms로 약 28배의 성능 차이가 발생하며 이는 전적으로 데이터가 해당 GPU 메모리에 있는지에 달려 있다.

Prefix-aware 라우팅을 적용하면 동일 하드웨어에서 처리량과 지연 시간을 동시에 대폭 개선할 수 있다. 8개의 A100 GPU 환경에서 실험한 결과, 라운드 로빈의 캐시 적중률은 12.5%에 불과했으나 Prefix-aware 방식은 97.5%를 기록했다. 이를 통해 처리량은 22.3% 향상되었으며, 월간 GPU 비용 기준 노드당 약 $1,200~$1,800의 낭비를 방지할 수 있음이 확인됐다.

모델의 크기와 프롬프트의 길이가 길어질수록 KV 캐시 로컬리티의 경제적 가치는 더욱 커진다. Llama 3.1 70B와 같은 대형 모델은 Prefill 연산이 매우 무겁기 때문에 캐시 적중 시 응답 속도가 44% 빨라지는 효과를 본다. 또한 공유 컨텍스트가 16K 토큰에 달하는 경우 캐시 미적중 시마다 약 400ms의 GPU 연산 시간이 추가로 낭비되므로 긴 컨텍스트를 사용하는 RAG 앱에서 최적화 효과가 극대화된다.

사용자 경험의 핵심인 테일 레이턴시(P99) 개선에서 Prefix-aware 라우팅이 압도적인 성능을 보여준다. 30명의 동시 사용자가 있는 부하 상황에서 라운드 로빈의 P99 TTFT는 6.8초에 달해 서비스가 불가능한 수준이었으나, 최적화 라우팅 적용 시 1초로 단축됐다. 이는 대부분의 요청이 Prefill을 건너뛰면서 큐가 빠르게 비워지고, 간헐적인 캐시 미적중 요청도 더 빠르게 처리될 수 있기 때문이다.

실무 Takeaway

시스템 프롬프트나 지식 베이스가 반복되는 RAG 서비스라면 Prefix-aware 라우팅 도입만으로 추가 하드웨어 없이 처리량을 20% 이상 높일 수 있다.
8B 이하의 소형 모델이나 500 토큰 미만의 짧은 프롬프트 환경에서는 라우팅 오버헤드(약 10ms)가 절감액보다 클 수 있으므로 도입 전 비용 편익 분석이 필요하다.
특정 프롬프트에 요청이 몰려 발생하는 GPU 핫스팟 문제는 로드 상태에 따른 폴백(Fallback) 메커니즘을 통해 캐시 적중률과 부하 분산 사이의 균형을 맞춰야 한다.

언급된 리소스

GitHubRanvier Project