이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.
TL;DR
LLM 애플리케이션은 시스템 지침, 대화 기록, 검색 문서, 도구 정의처럼 여러 요청에서 반복되는 입력을 매번 다시 처리하면서 비용과 지연이 커집니다. KV cache는 한 요청의 토큰 생성 과정에서 이미 계산한 Key와 Value 상태를 재사용하고, Prefix Cache는 여러 요청의 동일한 prefix를 블록 단위 KV 상태로 공유해 prefill을 줄입니다. Prompt Caching은 API 제공자가 반복 프롬프트를 관리하는 방식이며, Semantic Caching은 질문의 의미가 이전 질문과 충분히 비슷하면 저장된 답변을 반환해 LLM 호출 자체를 생략합니다. 네 방식은 서로 대체하는 단일 캐시가 아니라 모델 내부, 요청 처리, API, 애플리케이션 계층에서 함께 적용할 수 있지만, 안정적인 prefix 유지와 의미 유사도 오판 방지가 핵심 조건입니다.
섹션별 상세
LLM은 응답을 한 번에 만들지 않고 토큰을 autoregressive하게 하나씩 생성하므로 이전 토큰과의 Attention 상태를 반복해서 활용합니다. KV cache는 각 토큰에서 계산한 Key와 Value 텐서를 GPU 메모리에 저장하고 다음 decoding 단계에서 다시 읽어 전체 이전 문맥을 재계산하지 않게 합니다. 이 방식은 현재 요청의 생성 속도를 높이지만, 요청이 종료된 뒤 unrelated request에 그 상태를 그대로 재사용하는 기능은 아닙니다.
Prefix Cache는 서로 다른 요청이 같은 시스템 프롬프트와 지침으로 시작할 때 공통 prefix의 계산 결과를 공유합니다. serving system은 프롬프트를 고정 크기 토큰 블록으로 나누고 내용과 prefix 내 위치에서 만든 해시로 기존 KV 블록을 찾은 뒤, 적중한 블록은 재사용하고 cache miss 이후의 토큰만 모델에 전달합니다. 캐시가 가득 차면 LRU 방식으로 최근 사용 빈도가 낮은 블록을 제거하며, 이미지나 오디오가 포함된 multimodal 입력은 텍스트가 같아도 입력 전체가 동일한지 별도로 판단해야 합니다.
Prompt Caching은 모델을 직접 호스팅하지 않고 API 제공자의 LLM을 사용할 때 반복되는 대규모 시스템 프롬프트를 제공자 인프라에서 재사용하는 방식입니다. 시스템 지침과 도구 정의처럼 안정적인 내용을 앞에 배치하고 최신 도구 결과나 동적 문맥을 뒤에 두면 cache hit 가능성을 높일 수 있지만, 시간·브랜치·열린 파일·MCP 서버·JSON 직렬화 방식의 변화와 TTL 만료는 cache miss를 만들 수 있습니다. 글에 제시된 표에서는 여러 제공자의 cache hit 비용이 정가의 0.1x 또는 0.15x로 표시되지만, 실제 TTL·최소 토큰 수·저장 비용은 제공자별로 확인해야 합니다.
Semantic Cache는 토큰이나 KV 상태를 재사용하는 대신 이미 비슷한 질문에 대한 답변이 존재하는지 먼저 확인합니다. 새 질문을 embedding 벡터로 바꾸고 저장된 질문 벡터와 similarity search를 수행해 임계값을 넘으면 LLM을 호출하지 않고 기존 답변을 반환하므로 네 방식 중 가장 높은 수준에서 전체 추론을 생략합니다. 그러나 “Apple의 매출”과 “Apple의 2025년 매출”처럼 관련성은 높아도 답이 다른 질문이 있어, 공격적인 임계값은 부정확한 답변을 반환할 위험이 있습니다.
네 캐시는 경쟁 관계가 아니라 서로 다른 처리 계층에서 누적되는 최적화 기회입니다. Semantic Cache가 먼저 유사 답변을 찾고, 적중하지 않으면 Prefix Cache나 API 수준 Prompt Caching이 반복 입력 처리를 줄이며, 실제 토큰 생성 단계에서는 KV cache가 Attention 상태를 재사용하는 흐름을 구성할 수 있습니다. 고객지원 agent처럼 회사 정책·제품 문서·도구 정의가 매 요청에 포함되고 유사 질문도 반복되는 서비스에서는 네 계층을 함께 적용해 prefill, decoding, 입력 비용, 전체 LLM 호출을 각각 줄일 수 있습니다.
용어 해설
- KV 캐시(KV Cache)
- — KV 캐시는 Transformer의 Attention 계산에서 이미 처리한 토큰의 Key와 Value 텐서를 메모리에 저장하는 방식입니다. 다음 토큰을 생성할 때 이전 토큰의 상태를 다시 계산하지 않고 저장된 값을 재사용하므로 autoregressive decoding의 반복 연산과 지연을 줄입니다. 일반적으로 현재 요청의 활성 시퀀스에 연결되며 요청이 끝나면 다른 요청에 자동으로 재사용되지는 않습니다.
- Prefix Caching
- — Prefix Caching은 여러 요청에서 반복되는 프롬프트 앞부분의 KV 상태를 블록 단위로 저장하고 재사용하는 기법입니다. 토큰 블록의 내용과 위치에서 해시를 만들어 캐시 적중 여부를 판단하며, 적중한 블록은 다시 prefill하지 않고 새로 달라진 부분만 처리합니다. 공유 시스템 프롬프트와 문서가 많은 서비스에서 prefill 계산량을 줄이는 데 쓰입니다.
- Prompt Caching
- — Prompt Caching은 LLM API 제공자가 반복되는 프롬프트 내용을 인프라에서 저장하고 이후 요청의 동일한 부분을 재사용하는 기능입니다. 애플리케이션은 제공자의 캐싱 규칙에 맞춰 프롬프트를 보내고, 저장·재사용·TTL·가격 정책은 제공자가 관리합니다. 안정적인 prefix가 유지될수록 입력 처리 비용과 지연을 줄일 가능성이 커집니다.
- Semantic Caching
- — Semantic Caching은 새 질문을 embedding 벡터로 변환한 뒤 이전 질문의 벡터와 유사도를 비교해 이미 생성된 답변을 재사용하는 방식입니다. 문자열이 정확히 같지 않아도 의미가 설정한 임계값을 넘으면 LLM 호출 자체를 건너뛸 수 있습니다. 다만 관련성은 높지만 세부 조건이 다른 질문까지 같은 답변으로 처리할 수 있어 임계값과 추가 검증이 필요합니다.
- Prefill
- — Prefill은 LLM이 입력 프롬프트 전체를 처음 처리해 각 토큰의 Attention 상태를 계산하는 단계입니다. Prefix Cache는 이미 계산된 공통 prefix의 KV 상태를 재사용해 이 단계에서 새로 처리해야 할 토큰 수를 줄입니다. 따라서 긴 시스템 지침과 문서가 반복되는 요청에서는 decoding 이전의 입력 처리 비용을 낮추는 역할을 합니다.
기술
- Transformer
- vLLM
- MCP
- OpenAI
- Anthropic
- Gemini
- GPT-5.6
- Claude Opus 5
- Kimi K3
- Grok 4.5
- DeepSeek V4 Pro
활용 사례
- 공통 시스템 프롬프트를 사용하는 LLM API 애플리케이션
- 회사 정책과 제품 문서를 포함하는 AI 고객지원 agent
- 동일하거나 의미가 유사한 질문이 반복되는 질의응답 서비스
- 텍스트와 이미지·오디오가 함께 입력되는 vision-language model serving
언급된 리소스
AI 분석 전체 내용 보기
AI 요약 · 북마크 · 개인 피드 설정 — 무료
출처 · 인용 안내
원문 발행 2026. 09. 08.수집 2026. 09. 08.출처 타입 RSS
인용 시 "요약 출처: AI Trends (aitrends.kr)"를 표기하고, 사실 확인은 원문 보기 기준으로 진행해 주세요. 자세한 기준은 운영 정책을 참고해 주세요.
