Cache Hit
Cache Hit는 요청한 데이터가 캐시에 이미 존재하여 즉시 사용할 수 있는 경우를 의미합니다.
기본 개념
Cache Hit (캐시 적중):
요청 → 캐시 확인 → 발견! ✅ → 즉시 반환
Cache Miss (캐시 미스):
요청 → 캐시 확인 → 없음 ❌ → 원본에서 계산/가져오기LLM에서의 Cache Hit
1. KV Cache Hit
Prefix Caching 시나리오:
첫 번째 요청:
입력: [시스템프롬프트][질문1]
결과: Cache Miss → 전체 계산 (500ms)
캐시 저장: key="시스템프롬프트"
두 번째 요청:
입력: [시스템프롬프트][질문2]
캐시 확인: "시스템프롬프트" 찾음!
결과: Cache Hit ✅ → 일부만 계산 (50ms)
90% 시간 절약!2. Cache Hit Rate (캐시 적중률)
Cache Hit Rate = (Cache Hits) / (Total Requests) × 100%
예시:
총 요청: 100개
Cache Hit: 80개
Cache Miss: 20개
→ Hit Rate = 80%실제 예시
예시 1: 챗봇 시스템 프롬프트
시스템 프롬프트 (1000토큰):
"당신은 친절한 AI 어시스턴트입니다. 항상 공손하게..."
요청 1: [시스템][사용자: "안녕"]
- Cache Miss
- Prefill: 1000 + 5 = 1005 토큰
- 시간: 100ms
요청 2: [시스템][사용자: "날씨 알려줘"]
- Cache Hit! (시스템 프롬프트 부분)
- Prefill: 0 + 10 = 10 토큰만 계산
- 시간: 10ms
- 절약: 90ms (90%)예시 2: RAG 시스템
문서 컨텍스트 (5000토큰):
"제품 매뉴얼 전체 내용..."
질문 1: "이 제품의 보증 기간은?"
- Cache Miss
- Prefill: 5010 토큰
- 시간: 500ms
질문 2: "반품 정책은?"
- Cache Hit! (문서 부분)
- Prefill: 10 토큰만 추가
- 시간: 50ms
- 절약: 450ms (90%)
질문 3: "가격은 얼마야?"
- Cache Hit!
- 시간: 50msCache Hit 계산
측정 방법
cache_stats = {
'hits': 0,
'misses': 0,
'total_saved_time': 0
}
def process_request(prefix, query):
cache_key = hash(prefix)
if cache_key in cache_store:
# Cache Hit!
cache_stats['hits'] += 1
saved_time = calculate_prefill_time(len(prefix))
cache_stats['total_saved_time'] += saved_time
kv_cache = cache_store[cache_key]
return generate_with_cache(kv_cache, query)
else:
# Cache Miss
cache_stats['misses'] += 1
kv_cache = compute_full_prefill(prefix, query)
cache_store[cache_key] = kv_cache
return generate(kv_cache, query)
# Hit Rate 계산
total = cache_stats['hits'] + cache_stats['misses']
hit_rate = cache_stats['hits'] / total * 100
print(f"Cache Hit Rate: {hit_rate:.1f}%")Hit Rate에 영향을 주는 요인
1. 프롬프트 패턴
높은 Hit Rate (90%+):
- 고정된 시스템 프롬프트 사용
- 동일한 문서에 대한 여러 질문
- 템플릿 기반 프롬프트
낮은 Hit Rate (10%):
- 매번 다른 프롬프트
- 타임스탬프/무작위 요소 포함
- 사용자별 맞춤 컨텍스트2. 캐시 크기
작은 캐시 (메모리 부족):
- 자주 Eviction (제거)
- Hit Rate 낮음
큰 캐시 (충분한 메모리):
- 더 많은 prefix 보관
- Hit Rate 높음3. 트래픽 패턴
집중된 트래픽:
사용자들이 비슷한 시간에 같은 기능 사용
→ Hit Rate 높음
분산된 트래픽:
다양한 시간에 다양한 요청
→ 캐시 Eviction 증가, Hit Rate 낮음성능 영향
TTFT에 미치는 영향
Prefix: 2000토큰 (Prefill 시간: 200ms)
Query: 50토큰 (Prefill 시간: 5ms)
Cache Miss:
TTFT = 200ms + 5ms = 205ms
Cache Hit:
TTFT = 0ms + 5ms = 5ms
↓
97.5% 개선!처리량(Throughput) 향상
캐시 없이:
10 요청/초 (각 205ms TTFT)
80% Hit Rate:
- 80% 요청: 5ms TTFT
- 20% 요청: 205ms TTFT
- 평균: 45ms TTFT
→ 22 요청/초 (2.2배 향상)최적화 전략
1. 프롬프트 구조화
❌ 나쁜 예:
"{질문} | 시스템: {프롬프트}"
→ Prefix가 매번 달라짐
✅ 좋은 예:
"{시스템프롬프트} | 질문: {질문}"
→ Prefix가 일정하여 Hit Rate 높음2. 캐시 워밍 (Cache Warming)
# 서버 시작 시 자주 사용되는 prefix 미리 캐싱
common_prefixes = [
system_prompt,
system_prompt + common_document_1,
system_prompt + common_document_2
]
for prefix in common_prefixes:
warm_cache(prefix)3. 배치 그룹핑
동일한 prefix를 가진 요청들을 묶어서 처리:
시간 t:
요청 A: [prefix_1][query_A]
요청 B: [prefix_1][query_B]
요청 C: [prefix_1][query_C]
→ prefix_1을 한 번만 계산
→ 100% Hit Rate (첫 요청 제외)4. TTL (Time To Live) 조정
# 사용 패턴에 따라 TTL 설정
cache_config = {
'system_prompt': ttl=3600, # 1시간 (자주 사용)
'user_document': ttl=300, # 5분 (일시적)
'temp_context': ttl=60 # 1분 (단기)
}모니터링 지표
핵심 메트릭
1. Hit Rate (%)
- 목표: 70-90% (워크로드에 따라 다름)
2. Average Saved Time per Hit
- 목표: 100ms+
3. Cache Size
- 현재 사용량 / 최대 용량
4. Eviction Rate
- 시간당 제거된 항목 수
- 높으면 캐시 크기 증가 고려대시보드 예시
━━━━━━━━━━━━━━━━━━━━━━━━━━
Cache Performance Dashboard
━━━━━━━━━━━━━━━━━━━━━━━━━━
Hit Rate: 85.3% ✅
Miss Rate: 14.7%
Total Requests: 10,000
Cache Hits: 8,530
Cache Misses: 1,470
Time Saved: 42.1 minutes
Avg Save/Hit: 296ms
Cache Usage: 18.5 GB / 32 GB
Evictions: 245 (last hour)
━━━━━━━━━━━━━━━━━━━━━━━━━━실제 서비스 예시
Anthropic Claude
Prompt Caching 기능:
- Cache Hit: 토큰 가격의 10%만 청구
- Cache Miss: 정상 가격 + 캐시 저장
- TTL: 5분
예시 비용:
입력 1000토큰, 100회 요청
캐시 없이:
1000 × 100 × $0.003 = $0.30
90% Hit Rate:
- First: 1000 × $0.003 = $0.003
- Hits (90): 1000 × 90 × $0.0003 = $0.027
- Misses (9): 1000 × 9 × $0.003 = $0.027
합계: $0.057 (81% 절감!)Trade-offs
높은 Hit Rate 추구:
✅ 빠른 응답
✅ 낮은 비용
✅ 높은 처리량
❌ 큰 메모리 사용
❌ 캐시 관리 복잡도
낮은 캐시 사용:
✅ 메모리 절약
✅ 간단한 구조
❌ 느린 응답
❌ 높은 계산 비용Cache Hit는 LLM 서비스의 성능과 비용 효율성을 극적으로 개선할 수 있는 핵심 지표입니다. 특히 반복적인 패턴이 있는 워크로드에서는 80-90%의 Hit Rate를 달성하여 엄청난 이득을 볼 수 있습니다!
Story Engineer