에이전트 시대의 LLM 서빙, 캐시가 곧 돈이에요
요즘 LLM 서비스의 비용을 결정하는 건 모델 크기만이 아니에요. 같은 프롬프트의 앞부분을 얼마나 재사용하느냐, 즉 KV 캐시 히트율이 GPU 비용을 좌우하거든요. 특히 AI 에이전트 워크로드에서 이게 극단적으로 중요해졌어요. 에이전트는 수천 토큰짜리 시스템 프롬프트와 툴 정의를 매 턴 다시 보내고, 툴을 호출할 때마다 대화가 한 단계씩 길어지면서 같은 앞부분을 수십 번 반복하니까요.
그래서 최근 논문들이 '에이전트 워크로드에 맞춘 똑똑한 KV 캐시 관리 정책'을 앞다퉈 제안하는데요. 대부분 '우리 정책이 LRU보다 훨씬 낫다'는 그래프로 끝나요. 그런데 이걸 직접 시뮬레이션으로 검증해 본 GitHub 저장소가 나왔어요. 결론이 제목 그대로예요. 논문들이 말하는 것만큼 LRU를 이기기가 쉽지 않더라는 거죠.
KV 캐시가 뭐냐면
트랜스포머 모델은 다음 토큰을 만들 때 앞에 나온 모든 토큰의 Key와 Value라는 중간 계산값을 참조해요. 이걸 매번 다시 계산하면 너무 느리니까 GPU 메모리에 저장해 두는데, 그게 KV 캐시예요. 여기서 한 발 더 나간 게 프리픽스 캐싱이에요. 요청 A와 요청 B의 앞부분(예: 시스템 프롬프트)이 똑같으면, A가 계산해 둔 KV 값을 B가 그대로 가져다 쓰는 거죠. 잘 되면 프롬프트 처리 시간이 몇 분의 일로 줄어요.
문제는 GPU 메모리가 비싸고 작다는 거예요. 캐시가 꽉 차면 뭔가를 버려야 하는데, 이때 '뭘 버릴까'를 정하는 규칙이 축출(eviction) 정책이에요. 가장 단순한 게 LRU(Least Recently Used), 즉 가장 오래 안 쓴 걸 먼저 버리는 방식이고요. 운영체제 페이지 캐시부터 Redis까지 어디에나 있는 그 정책이에요.
논문들은 뭘 제안하고, 왜 실험에선 안 먹혔을까
논문들이 내놓는 정책은 대개 이런 식이에요. 사용 빈도를 함께 고려한다든가(LFU 계열), 다시 계산할 때 드는 비용이 큰 긴 프리픽스를 우선 보호한다든가, 에이전트의 툴 호출 패턴을 학습해서 '이 프리픽스는 곧 다시 온다'를 예측한다든가, 대화 트리 구조를 인식해서 부모 노드를 먼저 지킨다든가 하는 거죠. 이론적으로는 다 그럴듯해요.
그런데 이 저장소의 시뮬레이션에서 이런 정책들이 LRU를 압도하지 못한 이유를 곱씹어보면 몇 가지 시스템 연구의 오래된 교훈이 보여요.
첫째, 에이전트 워크로드는 시간적 지역성이 아주 강해요. 방금 쓴 프리픽스가 다음 턴에 바로 또 쓰이는 구조라서, '최근에 쓴 걸 남긴다'는 LRU의 단순한 가정이 이미 워크로드 특성을 거의 다 설명해 버려요. 복잡한 정책이 추가로 얻을 여지가 별로 없는 거죠.
둘째, 논문의 비교 조건이 자기 정책에 유리하게 잡혀 있는 경우가 많아요. 합성 워크로드의 분포, 캐시 크기, 요청 도착 패턴을 살짝 바꾸면 LRU와의 격차가 사라지거나 뒤집히기도 하거든요. 이건 KV 캐시만의 문제가 아니라, 캐시 연구 전반에서 ARC나 LIRS 같은 고급 정책이 나왔을 때부터 반복된 이야기예요.
셋째, 정책의 오버헤드가 히트율 이득을 잡아먹어요. 예측 모델을 돌리거나 우선순위 큐를 유지하는 비용이 서빙 경로에 얹히면, 히트율이 몇 퍼센트 올라도 지연 시간은 오히려 나빠질 수 있어요. LRU는 연결 리스트와 해시맵 하나면 끝이니까 이 부분에서 거의 무적이에요.
실제 서빙 엔진들은 어떻게 하고 있냐면
vLLM의 자동 프리픽스 캐싱과 SGLang의 RadixAttention은 둘 다 기본적으로 LRU 기반 축출을 써요. SGLang은 프리픽스를 기수 트리(radix tree)로 관리해서 트리 구조 인식은 하지만, 뭘 버릴지는 결국 LRU로 정하거든요. 그리고 Anthropic이나 OpenAI 같은 API 제공사들이 프롬프트 캐싱을 과금 항목으로 만든 뒤로는, 캐시 히트가 곧 청구서 금액이 됐어요. 이 실험은 '화려한 정책을 넣기 전에 기본 정책이 이미 얼마나 잘하는지부터 재라'는 메시지를 업계에 다시 던지는 셈이에요.
한국 개발자에게 주는 시사점
에이전트 서비스를 만들고 계시다면, 정책보다 프롬프트 구조가 히트율에 훨씬 큰 영향을 준다는 걸 기억하세요. 고정되는 부분(시스템 프롬프트, 툴 정의)은 맨 앞에, 매번 바뀌는 부분(현재 시각, 사용자 정보)은 맨 뒤에 두는 것만으로 캐시 효율이 확 달라져요. 셀프 호스팅으로 vLLM이나 SGLang을 운영 중이라면, 축출 정책을 건드리기 전에 현재 히트율을 계측하는 게 먼저예요. 그리고 논문의 벤치마크를 곧이곧대로 믿지 말고, 이 저장소처럼 자기 워크로드로 재현해 보는 습관이 시스템 엔지니어링에서는 정말 중요해요.
정리하자면
'단순한 기준선은 생각보다 세다'는 시스템 연구의 고전적 교훈이 LLM KV 캐시에서도 그대로 확인됐어요. 여러분 서비스의 프롬프트 캐시 히트율은 몇 퍼센트인가요? 혹시 LRU를 이기는 정책을 실제 운영에서 보신 적 있다면 어떤 워크로드였는지 댓글로 나눠주세요.
🔗 출처: Hacker News