실제 Claude Code 추적 재현에서 agentic KV 캐시 정책 3종이 radix-leaf LRU에 모두 패배

저자가 말하는 요지는 이거임. 393개 실제 Claude Code 세션을 정책과 무관하게 분석해 보니, 5분 TTL을 넘긴 요청은 재계산의 17.5%뿐이고 10초 안의 요청이 33.1%였음. 88k 토큰 작업 집합이 캐시 용량을 넘는 촘촘한 도구 호출 루프가 주된 낭비라서, 세션 생존 예측으로는 못 푼다는 결론임.

짧은 작성자 댓글까지 Claude가 쓴 듯한 문체라 읽기 불편함. 완벽하지 않아도 사람이 직접 쓴 설명을 보고 싶음.

에이전트가 왜 유휴 상태일 거라고 가정하는지 궁금함. 끝날 때까지 캐시된 프롬프트 접두사를 쓰며 계속 작업할 거라고 생각했음.

README 문체는 거칠지만, Belady 같은 오프라인 최적 정책이 처음에는 LRU에 졌다는 실패를 공개한 건 흥미로움. 거의 찬 캐시에 긴 체인을 넣을 때 빌드 중인 접두사 자체를 축출하는 하네스 버그였고, 새 블록의 타임스탬프가 최신인 LRU는 우연히 이를 피했음.

실패한 정책보다 실패 원인을 공개한 쪽이 더 유용할 수 있음. 에이전트로 실험 비용이 낮아지면서 이런 null finding도 공개되는 건 좋다고 봄.

LLM 관련 작업은 대체로 최근 정보 편향이 있으니 LRU가 이상적인 전략처럼 보임. 장기 작업에서 새로 준 정정 정보는 통계적으로 보정하지 말고 이전 정보보다 우선해야 함.

그런 최근 정보 우선은 모델을 예스맨으로 만들 수 있음.

반박한다는 'papers'가 어디에도 인용되지 않아 주장을 평가할 수 없음. TTL도 왜 중요한지 불분명하고, 잘 연구된 admission과 eviction 정책을 거의 언급하지 않는데 왜 이 글을 읽어야 하는지 모르겠음.

LLM 자동 연구 루프가 몇 번 실험해 낸 결과만으로 최선이라고 할 수는 없음. 개인 연구자는 2,200만 달러 규모의 무차별 탐색을 할 수 없고, LRU의 단점과 트레이드오프를 모르는데 Claude 요약만 받아도 가치가 없다고 봄.

그런 제약과 트레이드오프는 모델에게 설명하라고 요청할 수도 있음.

가끔은 맞는 답을 인정하고 그 답에 관한 직관을 조금씩 쌓는 것만으로도 충분함. 학술적 문제 해결은 원래 직선 경로가 아님.

추론 인프라 규모가 커지면 경제성과 쓸 수 있는 도구가 달라짐. GB300에서는 NVLink가 빠르고 KV 캐시를 DRAM과 디스크로 오프로드해도 도구 중심 워크로드의 SLA와 비용을 맞출 수 있어서, 상황에 따라 아주 긴 TTL도 가능함.

지연시간 민감 LLM 시스템에서는 prefill을 고려한 ping-pong 비동기 컨텍스트 구성에 의존하게 됐음. 드문 최악 지연도 인터랙티브 시스템에서는 문제라서, 내 goulash 실험에는 mutation rate와 RoPE 친화적 구조도 넣었음.

4부 표를 보면 더 큰 KV 캐시에서는 일부 정책이 LRU를 앞질렀을 수도 있어 보임. 선택한 모든 캐시 크기에서 5분 축출이 거의 발동하지 않았다는 결과가 나왔으면, 그 크기 범위부터 다시 검토했어야 함.