LLM 애플리케이션 비용의 상당 부분은 “매번 같은 계산을 다시 하는 것”에서 나온다. Inference Caching은 이런 중복 계산을 저장하고 재사용해 응답 속도와 비용을 동시에 줄이는 기법이며, 크게 KV 캐시, 프리픽스 캐시(prefix caching), 시맨틱 캐시(semantic caching) 세 층으로 나뉜다. RAG, 에이전트, 고객지원 챗봇처럼 반복 패턴이 많은 시스템에서 특히 효과가 크다.
세 가지 캐시
1. KV 캐시
한 번의 추론 요청 안에서 이미 계산한 attention 상태(key-value pairs)를 재사용한다. 토큰을 한 글자씩 생성할 때 이전 계산을 다시 하지 않으므로, 대부분의 트랜스포머 모델에서 사실상 기본 동작에 가깝다.
2. 프리픽스 캐시(prefix caching)
여러 요청이 같은 시스템 프롬프트나 긴 기준 문서를 공유할 때, 그 앞부분의 계산 결과를 요청 간 재사용한다. 컨텍스트 캐싱(context caching), 프롬프트 캐싱(prompt caching)으로도 불린다.
3. 시맨틱 캐시(semantic caching)
애플리케이션이 과거 질문/답변 쌍을 저장해 두고, 의미적으로 비슷한 요청이 들어오면 모델 호출 자체를 건너뛴다. 가장 공격적인 비용 절감 방식이지만, 잘못 설계하면 오래된 답을 재사용할 위험이 있다.
비교
| 유형 | 적용 범위 | 누가 관리하나 | 장점 | 주의점 |
|---|---|---|---|---|
| KV 캐시 | 단일 요청 내부 | 모델 런타임 | 생성 속도 향상 | 개발자가 직접 제어하기 어려움 |
| 프리픽스 캐시 | 요청 간 공유 prefix | 모델/플랫폼 | 긴 시스템 프롬프트 비용 절감 | prefix가 조금만 달라도 미스 |
| 시맨틱 캐시 | 질문/답변 전체 | 애플리케이션 | API 호출 자체 감소 | 오답 재사용 방지 필요 |
어디에 쓰면 좋은가
- 긴 시스템 프롬프트를 반복 사용하는 챗봇
- 동일한 정책 문서·제품 설명서를 계속 붙이는 고객지원 시스템
- rag처럼 정적 문서를 자주 재사용하는 검색 증강 생성 파이프라인
- 동일 질문이 반복되는 내부 도구
실전 설계 팁
프리픽스 캐시는 정적 부분을 분리해야 효과가 난다
시스템 프롬프트, 공통 예시, 변하지 않는 정책 문서를 앞쪽에 모아야 한다. 매 요청마다 순서가 흔들리면 캐시 효율이 급감한다.
시맨틱 캐시는 정답 보증 조건이 중요하다
비슷한 질문이라고 해서 항상 같은 답을 재사용하면 안 된다. 날짜·가격·재고·사용자별 권한처럼 동적인 값은 캐시 대상에서 제외하는 편이 안전하다.
캐시 적중률보다 품질 보호가 우선이다
응답 시간이 빨라도 틀린 답을 재사용하면 시스템 신뢰를 잃는다. TTL, 출처 버전, 유사도 임계치, 캐시 무효화 규칙을 반드시 설계해야 한다.
간단한 애플리케이션 레벨 예시
cached = semantic_cache.lookup(query)
if cached and cached.score > 0.92:
return cached.answer
answer = llm.generate(query)
semantic_cache.store(query, answer)
return answer관련 문서
- rag — 검색 증강 생성 기본 개념
- rag-tips-long-context — 장문 컨텍스트 RAG 최적화 기법
- portkey-models — 모델별 비용 구조를 확인할 때 참고
참고 자료
- The Complete Guide to Inference Caching in LLMs — Machine Learning Mastery (2026-04-17)