LLM 캐시 관리: LRU가 여전히 강력한 이유
LRU is harder to beat than the KV-cache papers suggest
Hacker News에이전트 LLM 서비스에서 캐시 미스의 주원인은 세션의 유휴 시간(TTL) 때문이라는 기존 가설과 달리, 실제로는 메모리 용량 부족으로 인한 잦은 도구 호출 루프가 핵심 원인입니다.
- 실제 트레이스 분석 결과, 캐시 용량 한계(Capacity-bound)가 가장 큰 병목이며, 이 환경에서는 기존의 LRU 기반 정책이 여전히 매우 강력한 기준선임을 입증했습니다.
- LLM 서비스 설계 시, 병목 지점이 '캐시 용량 부족'인지 아니면 '제공사 시간 제한(TTL)'인지를 먼저 파악해야 최적화 전략을 수립할 수 있습니다.
- 본 연구는 실제 트레이스 기반의 캐시 정책 시뮬레이션 결과이며, 시스템의 최종 처리량이나 지연 시간 같은 실시간 성능은 반영하지 못한다는 한계가 있습니다.
실제 서비스 트레이스 분석 결과, 기존에 주장되던 것처럼 캐시 미스의 주원인이 세션의 유휴 시간(TTL) 만료 때문은 아니었습니다. 대신 재계산되는 의 주요 원인은 잦고 짧게 발생하는 도구 호출 루프에서 비롯되며, 이는 시스템이 메모리 용량 한계(Capacity-bound)에 직면했기 때문입니다. 분석된 트레이스는 SemiAnalysis AgentX와 Mooncake 등 실제 에이전트 세션에서 수집되었으며, 이 과정에서 캐시가 포화 상태일 때의 동작을 측정했습니다.
캐싱 구조 측면에서, LLM 서비스는 크로스-요청 KV 접두사 캐싱(Cross-request KV prefix caching) 방식을 사용하며, 이는 라딕스 구조에 의해 제약됩니다. 이 구조적 특성상 단순히 가장 오래된 블록을 제거하는 평면적인 LRU 정책으로는 실제 성능을 예측하기 어렵습니다. 또한, 분석된 트레이스의 경우 세션 간 평균 요청 간격(inter-req gap)의 중앙값은 2.1초로 측정되어, 유휴 상태를 감지하여 캐시를 관리하려는 생존성 추정기(liveness estimator)가 구별할 수 있는 차이가 거의 없다는 점이 확인되었습니다.
따라서 LLM 서비스 최적화 시 가장 먼저 파악해야 할 것은 병목 지점이 '캐시 용량 부족'인지 아니면 '제공사 시간 제한(TTL)'인지를 구분하는 것입니다. 만약 시스템이 용량 한계에 놓여 있다면, 세션의 생존성을 예측하기보다는 N개의 동시 세션을 위한 대규모 작업 공간(working set)을 어떻게 효율적으로 배치할지에 초점을 맞춰야 합니다. 이 연구는 이러한 용량 제한 환경에서 LRU 기반 정책이 여전히 강력한 기준선임을 보여주었습니다.
용어 풀이
- 에이전트
- 목표를 받으면 스스로 계획을 세우고 도구를 써서 여러 단계의 작업을 해내는 AI.
- LLM
- 방대한 글을 학습해 문장을 이해하고 만들어 내는 AI 모델. ChatGPT, Claude, Gemini가 여기에 속해요.
- 토큰
- AI 모델이 글을 처리하는 단위. 단어보다 작은 조각이며 사용량과 요금을 셀 때 기준이 돼요.