[26'ICML] EpiCache

ICML 2026 (Apple) 논문 리뷰 · “Chat Agent가 한 달치 대화를 기억하려면 폰 메모리가 몇 GB 필요할까?”

Chat Agent가 사용자와 나눈 한 달치 대화를 전부 기억하려면 메모리가 얼마나 필요할까? 3B짜리 작은 모델(LLaMA3.2-3B) 기준으로 대화 기억(KV Cache)만 7GB가 넘는다. 모델 파라미터보다 대화 기억이 더 큰 셈이라, 폰에서는 감당이 안 된다. EpiCache는 이 KV 캐시를 약 1/4로 줄이면서 정확도는 거의 잃지 않는 training-free 프레임워크다.

논문 기본 정보

항목	내용
논문명	EpiCache: Episodic KV Cache Management for Long-Term Conversation on Resource-Constrained Environments
저자 / 소속	Minsoo Kim, Arnav Kundu, Han-Byul Kim, Richa Dixit, Minsik Cho / Apple
게재	ICML 2026 (Seoul; PMLR 306)
프리프린트	arXiv:2509.17396 (v4, 2026-05-19)
핵심 기여	Block-wise prefill + 에피소드 단위 KV 압축 + 민감도 기반 레이어별 예산 배분을 결합한 training-free KV 캐시 관리

문제: 기존 방식은 왜 안 됐나

KV Cache 압축 연구는 이미 많지만, 다들 하나씩 구멍이 있다. 크게 두 부류로 나뉜다.

첫 번째는 “일단 다 읽고 나서 줄이자” 부류다(H2O 등). 대화 전체를 메모리에 올린 뒤 중요한 것만 남기는데, 줄이기 전에 전체를 한 번은 메모리에 올려야 하므로 피크 메모리가 그대로다. 폰에서는 이 피크를 못 버텨 시작조차 못 한다.

두 번째는 “지금 들어온 질문에 필요한 것만 남기자” 부류다(SnapKV 등). 이번 질문엔 강하지만, 다음 질문에 필요할 내용을 이미 지워버린다.

즉 딜레마다. 메모리를 잡으면 정확도가 죽고, 정확도를 잡으면 메모리가 터진다. 게다가 근본적으로 미래에 어떤 질문이 올지는 아무도 모른다.

Fig. 1 — (a) post-prefill: 디코딩 시 KV는 줄지만 프리필 피크 메모리는 무제한. (b) block prefill: 블록마다 압축해 메모리 상한 보장. (c) 위: 입력이 길어져도 block prefill(파란색)은 피크 메모리가 평탄. 아래: 순진하게 블록 압축만 하면(KVzip-Block) 정확도가 크게 하락 — 이 간극을 메우는 것이 EpiCache.

핵심 아이디어

“미래 질문을 예측하지 말자. 대신 대화가 원래 ‘주제(에피소드)’ 단위로 반복된다는 걸 이용하자.”

사람도 Chat Agent와 대화할 때 게임, 영화, 일정 같은 몇 개 주제를 왔다 갔다 한다. 저자들이 LoCoMo에서 통제 실험을 해보니, 미래 질문과 주제가 비슷한 과거 발화만 힌트(patched prompt)로 써도 정답 질문을 미리 아는 오라클 세팅과 거의 같은 정확도가 나왔다. 질문을 정확히 맞힐 필요가 없다는 뜻이다. 문제가 “예측”에서 “분류”로 바뀌는 것이다.

Fig. 2 — 미래 질문을 미리 아는 오라클(Exact-Question, 회색)과 비교해, 주제가 가장 비슷한 발화 상위 10%만 힌트로 써도(Closest-Top10%) 정확도가 거의 같음 (LoCoMo, LLaMA3.1-8B).

방법: 3단계

비유하자면 “대화록을 주제별 노트로 미리 정리해두고, 질문이 오면 맞는 노트만 꺼내 보는” 방식이다.

Fig. 3 — EpiCache 3단계: (a) 대화 클러스터링(1회) → (b) 에피소드별 KV 캐시 구축(1회) → (c) 질문-에피소드 매칭 후 해당 캐시로 디코딩(매 턴). 활성 캐시 외에는 CPU/스토리지에 대기.

① 주제 나누기 (1회, 오프라인)

대화 이력을 발화 4개 단위 세그먼트로 쪼갠 뒤, 경량 임베딩 모델(Qwen3-Embedding-0.6B)로 인코딩하고 K-means로 클러스터링한다. 게임/영화/날씨 같은 에피소드가 자동으로 나뉜다(기본 E=4개). 이 오프라인 단계 전체가 1분도 걸리지 않는다.

② 주제별 압축 노트 만들기 (1회, 오프라인)

에피소드마다 전체 이력을 블록 단위(128~2048토큰)로 읽으면서, 그 에피소드의 대표(medoid) 세그먼트를 힌트로 붙여 관련 깊은 토큰만 남긴다. 블록 단위로 처리하기 때문에 피크 메모리에 상한이 딱 걸린다. 만들어진 노트들은 평소엔 CPU/스토리지에 치워둔다.

③ 질문 오면 매칭 (매 턴)

새 질문을 임베딩해 가장 가까운 에피소드 노트를 꺼내 답한다. 매칭에 0.04초, 노트 교체(로드+기록)에 0.3초가 든다. 완전히 새로운 주제면 노트를 새로 하나 만든다.

+α: 레이어별 예산 배분

레이어마다 압축에 민감한 정도가 다르다는 점을 발견해, 민감한 레이어엔 캐시 예산을 더, 둔감한 레이어엔 덜 준다(쏠림 강도 α=2~4가 최적). 흥미로운 점은 이 민감도가 데이터가 아니라 모델 자체의 성질이라는 것이다. 그래서 BookSum 장문 문서 샘플 딱 1개로 캘리브레이션이 끝난다. 사용자 데이터가 필요 없다.

Fig. 4 — (a) 블록 프리필 전후 Key 상태 유사도가 레이어마다 다름(모델 고유 패턴). (b) 민감도 기반 배분(Sensitivity)이 균등 배분 대비 full KV와의 예측 차이(ΔKL)를 가장 많이 줄임 (평균 −0.80).

실험 설정

실제 사람 간 장기 대화 2종과 사용자-LLM 대화 1종, 총 3개 벤치마크에서 6개 모델과 9개 비교 방법으로 검증했다.

벤치마크	데이터 특징	지표
RealTalk	실제 참여자 쌍이 16~21일간 나눈 일상 메시징, 10개 대화. 오타·축약어 등 실제 대화 특성 반영	GPT 채점 (gpt-4o-mini)
LoCoMo	페르소나 기반 LLM 에이전트 생성 + 사람 검수, 10개 대화, 최대 35세션·약 300턴	F1 (*Adversarial 제외)
LongMemEval	사용자-LLM 멀티세션. 세션 스태킹으로 20K~100K 토큰 이력 구성	F1

LoCoMo의 Adversarial(답변 불가 인식) 과제는 제외했다. 압축된 캐시에서는 모델이 “정보 없음”을 남발해 점수가 허위로 높아지는 편향이 있기 때문이다(예: LLaMA3.2-3B에서 Full KV 12.1점 → KVzip 4K 압축 49.8점으로 급등).

모델·예산·비교 대상은 다음과 같다. 주 평가 모델은 Qwen3-4B/8B이고, 일반화 검증에 LLaMA3.2-3B, LLaMA3.1-8B, Qwen2.5-3B/7B를 썼다. KV 캐시 예산 M은 {2K, 4K, 6K, 8K} 토큰, 에피소드 수 E=4로 고정했다. 비교 방법은 Full KV, RAG-2K/Episodic, StreamingLLM, SnapKV, InfiniPot, KeyDiff, KVzip, OracleKV 등 9종이며, 대화 밖 일반화는 LongBench 문서 QA 4종으로 확인했다.

결과

핵심 숫자는 세 개다. 각각 측정 조건이 붙는다.

• 정확도: 기존 압축 대비 최대 +30점(절대 점수). RealTalk에서 4개 모델 × 예산 2K~8K로 StreamingLLM·SnapKV·KeyDiff·InfiniPot과 비교한 결과이며, 4~6배 압축에서도 Full KV에 근접한다. (⚠️ 초록의 “30%”는 본문 기준 “30 absolute score improvement”다. 상대 30% 향상으로 옮겨 쓰지 않도록 주의.)
• 피크 메모리: 36.3GB → 9.6GB (3.7배↓).
• 턴당 응답: 3.5초 → 1.8초 (~2배↑), 총 지연 1,062.8초 → 545.4초.

Fig. 5 — 3개 벤치마크 × Qwen3-4B/8B, 예산 2K~8K. EpiCache(진한 파랑)가 전 구간 최상위이고, 저예산(2~4K)에서 격차가 가장 큼.

Fig. 6 — RealTalk에서 4개 모델(LLaMA3.2-3B/3.1-8B, Qwen2.5-3B/7B) 일반화 검증. “기존 압축 대비 최대 +30점”이 나온 실험이 바로 이것.

메모리·속도 수치의 측정 조건은 LLaMA3.2-3B, GPU 서버(single-batch), 90K 토큰(약 30일치) 대화 이력 + 이후 300턴 상호작용, 캐시 예산 8K, prefix caching 대비 기준이다. 캐싱 없이 매 턴 재프리필하는 Full KV(9,339초)와 비교하면 약 18배 빠르다. 이때 QA 정확도는 Full KV 46.2 대 EpiCache 45.6으로 거의 동일했다.

방법	총 지연	턴당	QA 점수	피크 메모리
Full KV (캐싱 없음, 매 턴 재프리필)	9,339.0초	31.1초	46.2	36.3GB
Full KV + Prefix Caching	1,062.8초	3.5초	46.2	36.3GB
EpiCache	545.4초	1.8초	45.6	9.6GB

Table 3 요약 — LLaMA3.2-3B, 90K 토큰 이력 + 300턴, M=8K.

예산이 빡빡할수록(2~4K) 격차가 벌어진다. 메모리가 제일 귀한 환경, 즉 모바일에서 제일 빛나는 방법이라는 뜻이다. LongBench 문서 QA에서도 전 예산 구간에서 우위여서, 대화 구조를 넘어 일반 문서에도 통한다.

설계 검증 (ablation)

RealTalk, Qwen3-4B, 8K 예산 기준이다.

• 세그먼트는 발화 단위(49.8)가 토큰(47.9)·단어(47.5)보다 낫다 — 화자 턴 경계를 지키는 게 중요.
• 임베딩은 0.6B(49.8)로 충분, 4B(50.6)로 키워도 이득이 미미하다.
• 에피소드 수는 많을수록 좋지만(E=2: 47.9 → E=8: 51.3), E=4만으로도 KVzip(36.0) 대비 큰 폭 우위다.
• 레이어 예산 배분 sharpness는 α=2~4가 최적(53.9), 과하게 쏠리면(α=8) 역효과다.
• K-means 시드, 캘리브레이션 도메인·샘플 수(1개 vs 100개)를 바꿔도 표준편차 0.5 미만 — “샘플 1개 캘리브레이션”의 근거.

한계와 해석 주의점

세 묶음으로 짚는다.

첫째, 평가 규모·방식이다. RealTalk과 LoCoMo는 각 10개 대화로 규모가 크지 않고, RealTalk 점수는 GPT(gpt-4o-mini) 자동 채점에 의존한다. LoCoMo의 adversarial 과제는 앞서 말한 편향 때문에 주요 결과에서 빠졌다.

둘째, 시스템 제약이다. 에피소드 수가 E=4로 고정되어 있고(적응적 결정은 향후 과제), 새 대화가 쌓였을 때 캐시를 증분 갱신하는 기능은 아직 없어 고정 예산 하에 재압축이 필요하다.

셋째, 범위다. 암묵적 사용자 선호 추적, 시간에 따른 정보 갱신·삭제는 평가되지 않았다. 그리고 효율 수치는 GPU 서버에서 single-batch로 측정한 것이므로, “스마트폰에서 실증된” 것이 아니라 “온디바이스 적용 가능성을 보여준” 연구로 이해하는 것이 정확하다.

우리 관점에서 본 시사점

여기부터는 논문 자체가 아니라 칩 벤더 관점의 해석이다.

• ① 전장이 연산 → 메모리로. 디코딩은 memory-bound이고, 온디바이스 병목은 TOPS가 아니라 DRAM 용량·대역폭·에너지다. 칩 경쟁 지표가 “몇 TOPS”에서 “같은 메모리로 얼마나 긴 대화를 버티나” 로 이동한다(토큰당 에너지 J/token도 같은 맥락의 KPI).
• ② 알고리즘이 HW 숙제를 던진다. 활성 KV는 NPU, 나머지는 CPU/스토리지에 두고 스왑하는 구조라 빠른 DMA 경로·eviction용 top-k·상시 임베딩 NPU가 필요하다 — 이종 IP co-design 기회.
• ③ 칩 벤더가 흡수 가능. training-free에 캘리브레이션 샘플 1개면 되니, 모델 벤더 없이 SDK·런타임 기본 최적화로 제공 가능하다. 피크 메모리 1/4은 8~12GB 중가폰까지 장기 기억 기능을 확산시킬 근거다.

요약

한 문장으로 줄이면 “미래를 예측하지 말고, 구조를 발견하라” 다. 다음 질문을 맞히려던 기존 연구와 달리, 대화가 몇 개 에피소드로 나뉜다는 구조 하나만으로 메모리 약 1/4·속도 약 2배를 얻으면서 정확도는 거의 지켰다. 이런 압축 기법이 늘수록 캐시를 잘 옮기고 잘 버리는 메모리 중심 설계의 가치도 함께 커진다.

참고문헌

• Kim, M., Kundu, A., Kim, H.-B., Dixit, R., & Cho, M. (2026). EpiCache: Episodic KV Cache Management for Long-Term Conversation on Resource-Constrained Environments. ICML 2026, PMLR 306. arXiv:2509.17396.
• Kim, J.-H., Kim, J., Kwon, S., Lee, J. W., Yun, S., & Song, H. O. (2025). KVzip: Query-Agnostic KV Cache Compression with Context Reconstruction. NeurIPS 2025 (Oral). arXiv:2505.23416.
• Kim, M., Shim, K., Choi, J., & Chang, S. (2024). InfiniPot: Infinite Context Processing on Memory-Constrained LLMs. EMNLP 2024.
• Kryscinski, W., Rajani, N., Agarwal, D., Xiong, C., & Radev, D. (2022). BookSum: A Collection of Datasets for Long-form Narrative Summarization. Findings of EMNLP 2022.
• Lee, D.-H., Maharana, A., Pujara, J., Ren, X., & Barbieri, F. (2025). REALTALK: A 21-Day Real-World Dataset for Long-Term Conversation. arXiv:2502.13270.
• Lewis, P., Perez, E., Piktus, A., et al. (2020). Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. NeurIPS 2020.
• Li, Y., Huang, Y., Yang, B., et al. (2024). SnapKV: LLM Knows What You are Looking for Before Generation. NeurIPS 2024.
• Maharana, A., Lee, D.-H., Tulyakov, S., Bansal, M., Barbieri, F., & Fang, Y. (2024). Evaluating Very Long-Term Conversational Memory of LLM Agents (LoCoMo). ACL 2024.
• Park, J., Jones, D., Morse, M. J., Goel, R., Lee, M., & Lott, C. (2025). KeyDiff: Key Similarity-Based KV Cache Eviction for Long-Context LLM Inference in Resource-Constrained Environments. NeurIPS 2025.
• Wu, D., Wang, H., Yu, W., Zhang, Y., Chang, K.-W., & Yu, D. (2025). LongMemEval: Benchmarking Chat Assistants on Long-Term Interactive Memory. ICLR 2025.
• Xiao, G., Tian, Y., Chen, B., Han, S., & Lewis, M. (2024). Efficient Streaming Language Models with Attention Sinks (StreamingLLM). ICLR 2024.
• Zhang, Y., Li, M., Long, D., et al. (2025). Qwen3 Embedding: Advancing Text Embedding and Reranking Through Foundation Models. arXiv:2506.05176.
• Zhang, Z., Sheng, Y., Zhou, T., et al. (2023). H2O: Heavy-Hitter Oracle for Efficient Generative Inference of Large Language Models. NeurIPS 2023.
• Zheng, L., Yin, L., Xie, Z., et al. (2024). SGLang: Efficient Execution of Structured Language Model Programs. NeurIPS 2024.
• Zhu, Y., Tang, Z., Liu, X., et al. (2025). OracleKV: Oracle Guidance for Question-Independent KV Cache Eviction. ICML 2025 Workshop on Long-Context Foundation Models.