본문으로 건너뛰기

Semantic Caching 전략

이 문서는 LLM 추론 파이프라인에서 게이트웨이 레벨 의미 기반 캐싱(Semantic Caching) 의 설계 원칙과 운영 고려사항을 다룹니다.

구현 가이드: 도구 비교 표, Gateway별 통합 패턴, 설정 예시, 배포 스니펫은 추론 게이트웨이 구성 가이드 — Semantic Caching 구현 옵션을 참조하세요.

1. 개요​

왜 Semantic Cache가 필요한가​

대규모 LLM 서비스에서 사용자 질의는 표현만 다르고 의미가 같은 경우가 매우 많습니다. 문자열 단위로 정확히 일치하는 전통적 캐시(HTTP cache, Redis key-value)로는 이러한 중복을 제거할 수 없습니다. Semantic Cache는 임베딩 기반 유사도로 의미가 유사한 요청을 탐지하여 이전 응답을 재사용함으로써 다음 3가지 문제를 동시에 개선합니다.

  • 토큰 비용 감소: 캐시 HIT 시 LLM 호출을 건너뛰어 API 비용·GPU 시간을 절약
  • 지연시간 단축: 생성 지연(수백 ms ~ 수 초) 대신 벡터 조회(수 ms)로 응답
  • GPU 용량 확보: 자체 호스팅 vLLM/llm-d 환경에서 처리량(throughput)을 유효 확대

예상 절감률 (임계값별)​

절감률은 사용자 질의의 반복성, 도메인(FAQ/고객 지원/코드 생성), 프롬프트 구조 에 따라 크게 달라지므로 아래 수치는 공개된 구현체 문서·벤더 블로그에서 관측되는 일반적 범위입니다. 각 조직은 점진적 롤아웃 과 A/B 평가로 실제 효과를 검증해야 합니다.

유사도 임계값운영 정책관측되는 절감률 범위특징
0.95 (엄격)거의 동일한 질의만 캐시약 10-15%오답 위험 매우 낮음, 엄격한 품질 요구 서비스
0.85 (균형)의미 동일·표현 차이 허용약 30-40%일반 LLM 챗/어시스턴트 권장 기본값
0.70 (공격적)관련 주제까지 묶음약 50-60%FAQ/정적 KB 등 반복률 매우 높은 워크로드 한정

출처 참고: Redis — Building an LLM semantic cache, Portkey Semantic Cache 문서, Helicone Caching 문서, GPTCache README.

절감률 수치는 반드시 검증

위 숫자는 공개 자료 기반의 대략적 범위 입니다. 모든 도메인에서 동일한 HIT 률이 나오지 않습니다. 대시보드(§6)로 자사 워크로드의 실제 HIT 률·false-positive 률 을 측정한 후 임계값을 확정하세요.

2. 캐시 계층 구분​

LLM 추론 파이프라인에는 3가지 서로 다른 캐시 계층 이 존재합니다. 각각 동작 위치·저장 단위·비용 영향이 달라서, Semantic Cache는 다른 2계층을 대체하지 않고 보완 합니다.

3계층 캐시 흐름도​

계층별 비교 표​

항목KV Cache (vLLM PagedAttention)Prompt Cache (Anthropic/OpenAI managed)Semantic Cache (Gateway 레벨)
동작 위치추론 엔진 내부 (GPU HBM)모델 프로바이더 측Gateway (Bifrost/LiteLLM/Portkey) 앞단
저장 단위토큰 단위 KV 블록명시적 cache_control 마커 구간전체 응답 객체 (텍스트/JSON)
매칭 방식접두사(prefix) 완전 일치프로바이더 내부 해시 기반 완전 일치임베딩 코사인 유사도
주 목적TTFT·throughput 개선반복 시스템 프롬프트 비용 절감중복 LLM 호출 자체를 제거
비용 영향GPU 시간 절감 (자체 호스팅)입력 토큰 단가 할인 (관리형)API 호출 자체를 건너뜀
실패 시 영향성능 저하만캐시 미적용 시 일반 단가응답 품질에 직접 영향 (오답 리스크)
관련 문서vLLM 모델 서빙프로바이더 공식 문서본 문서
세 계층은 독립적으로 조합 가능

Semantic Cache HIT → 즉시 응답 (LLM 호출 생략). MISS 시 프로바이더 호출 → Prompt Cache가 시스템 프롬프트 입력 비용 절감 → 추론 엔진 내부 KV Cache가 생성 속도 개선. 세 계층은 서로 직교(orthogonal) 하므로 동시에 활성화하는 것이 일반적입니다.

적용 시점 비교​

  • 프로토타입/단일 모델: KV Cache(자동) + Prompt Cache(프로바이더 지원 시) 만으로 충분
  • 멀티테넌트/멀티 프로바이더: Gateway 레벨 Semantic Cache 추가 — 동일 질의가 여러 사용자에서 반복되는 패턴을 흡수
  • FAQ/챗봇/고정 KB: Semantic Cache 임계값을 낮춰(0.80~0.85) 적극 재사용
  • 코드 생성/IDE 에이전트: Semantic Cache 보수적 적용(0.95) 또는 비활성 — 유사 질의라도 파일 컨텍스트가 달라 재사용 위험이 큼

3. 유사도 임계값 설계​

임계값별 트레이드오프​

임계값 선택 기준​

임계값적합 워크로드부적합 워크로드비고
0.95 이상코드 생성, 법률·의료 어시스턴트, 금융 자문(광범위하게 적용 가능)표현 차이가 거의 없는 동일 질의만 HIT
0.85-0.94 (권장)일반 챗봇, 고객 지원, 문서 요약, 제품 Q&A코드 생성(컨텍스트 민감)의미 동일·표현 차이 허용. 대부분 서비스의 기본값
0.75-0.84FAQ, 정적 KB, 사내 문서 검색 결과 설명대화형 추론, 다중 턴거짓 긍정 증가 — 응답 검증 레이어 필요
0.70 이하거의 사용 안 함 — 대량 FAQ 한정모든 범용 서비스무관한 질의끼리 묶일 위험

임계값 설정 시 고려 요소​

  1. 사용자 허용 오차: 고객 지원처럼 "가장 가까운 답"으로 충분하면 낮게, 코드·계산이면 높게
  2. 도메인 어휘 다양성: 용어 동의어가 많은 도메인(의료/법률)은 임베딩이 의미를 잘 묶어 낮춰도 안전한 경향
  3. 임베딩 모델 품질: 강력한 임베딩(예: text-embedding-3-large, bge-m3)일수록 임계값을 낮춰도 안전성 유지
  4. 대화 컨텍스트: 멀티 턴 대화는 이전 턴을 해시 키에 포함해야 함(§5 참조)
  5. 언어·로케일: 다국어 서비스는 언어별 namespace를 분리하여 교차 오염 방지
임계값은 고정값이 아니라 관측 기반 튜닝 대상

초기에는 0.90 으로 보수적으로 시작하고, Langfuse/Grafana 대시보드에서 HIT 률, user dissatisfaction 지표(👎, regenerate 클릭 등) 를 모니터링하며 0.05 씩 조정하는 것이 안전합니다.

4. 구현 고려사항​

Semantic Cache를 구현할 때는 다음 요소를 고려하여 솔루션을 선택합니다.

주요 고려 요소​

  1. 기존 인프라 재사용 가능성: Redis/Milvus 등 벡터 DB가 이미 있다면 추가 백엔드 없이 구현 가능
  2. 게이트웨이 통합 필요성: 라우팅·가드레일과 캐시를 통합 관리할지, 독립 레이어로 분리할지
  3. 관리형 vs 셀프호스트: 운영 부담·규정 준수·비용 트레이드오프
  4. 관측성 요구사항: 캐시 HIT/MISS 추적, false-positive 모니터링 수준
  5. 벡터 검색 엔진 선호도: Redis/Milvus/FAISS/Qdrant 등 조직의 표준 스택

구현 패턴​

패턴 A: Gateway 일체형 — 라우팅·캐시·관측성을 단일 제품에서 (예: Portkey, Helicone)

  • 장점: 통합 구성, 빠른 배포
  • 단점: 벤더 락인, 고급 기능은 관리형 플랜 의존

패턴 B: 모듈형 — 게이트웨이(Bifrost/LiteLLM) + 독립 캐시 레이어(RedisVL, GPTCache)

  • 장점: 각 레이어 독립 교체 가능, 오픈소스 우선
  • 단점: 통합 복잡도 증가

패턴 C: 관리형 — Redis Enterprise LangCache, Portkey SaaS

  • 장점: 운영 부담 최소, 규정 준수 인증 포함
  • 단점: 비용, 리전 제약

구체적인 도구별 비교 표, 설정 예시, 배포 스니펫은 Inference Gateway 구성 가이드 — Semantic Caching 구현 옵션을 참조하세요.

5. 캐시 키 설계와 멀티테넌시​

Semantic Cache는 게이트웨이 앞단 에 위치하여 LLM 호출 자체를 건너뛰기 때문에, 캐시 키 설계와 namespace 분리가 응답 품질·보안·멀티테넌시에 직접적인 영향을 줍니다.

캐시 키 구성 요소​

가장 단순한 키는 embedding(user_query) 하나지만, 실제 서비스에서는 다음 요소를 반드시 함께 키에 포함해야 합니다.

필수 포함 요소:

  • model_id: 모델 종류·버전 교차 오염 방지 (예: glm-5 ≠ qwen3-4b)
  • system_prompt_hash: 시스템 프롬프트가 다르면 완전히 다른 답
  • tenant_id | user_id: 멀티테넌트/사용자별 격리
  • language | locale: 언어 교차 오염 방지
  • tool_set_hash: 에이전트의 사용 가능 도구 집합
  • embedding(user_query): 의미적 유사도 매칭 대상

멀티테넌트 namespace 전략​

계층namespace 패턴 예시격리 목적
조직 / 테넌트cache:{tenantId}:*데이터 격리, 감사 경계
사용자cache:{tenantId}:{userId}:*개인정보 포함 질의의 사용자 간 누수 방지
언어cache:{tenantId}:ko:* / :en:*다국어 서비스에서 교차 오염 방지
도메인cache:{tenantId}:support:* / :billing:*컨텍스트가 다른 도메인 간 재사용 차단
모델 버전cache:{...}:glm-5:v2026-03:*모델 업그레이드 시 일괄 invalidation 가능

비-결정성(non-determinism) 처리​

temperature > 0, top_p < 1, 또는 도구 호출이 포함된 요청은 매번 다른 응답이 나오므로 단순 재사용 시 사용자 경험 저하가 발생할 수 있습니다.

권장 정책:

  • 스트리밍·에이전트형 요청은 기본 캐시 비활성
  • 확실히 재현 가능한 엔드포인트(예: /summarize, /classify)에만 선택적 허용
  • temperature=0 요청만 캐시하는 라우팅 규칙 권장

구체적인 Gateway별(kgateway, LiteLLM, Bifrost) 통합 패턴, 설정 예시, 코드 스니펫은 Inference Gateway 구성 가이드 — Semantic Caching 구현 옵션을 참조하세요.

6. 관측성 (Langfuse 연동)​

Semantic Cache는 사용자에게 직접 영향 을 주는 레이어이므로 관측성 없이는 운영이 불가능합니다. Langfuse 또는 동급 관측 스택으로 다음을 반드시 수집하세요.

Langfuse Trace 태그​

각 요청 trace에 다음 속성을 attach 합니다 (Langfuse Python/TypeScript SDK 모두 metadata 또는 tags 로 지원).

  • cache_hit: true / false
  • similarity_score: 0.92 (HIT일 때, 매칭된 최고 유사도)
  • cache_source: redis-semantic / portkey / helicone 등
  • cache_namespace: {tenant}:{lang}:{domain} (PII 포함 금지)
  • cache_ttl_remaining_s: 남은 TTL (디버그용)
  • cache_eviction_reason: MISS 원인 (below_threshold, namespace_miss, ttl_expired)

대시보드 권장 패널​

Langfuse의 커스텀 대시보드 또는 Prometheus + Grafana로 다음을 시각화합니다.

패널쿼리/메트릭목표값
HIT 률 전체count(cache_hit=true) / count(*)15-40% (서비스 특성별)
HIT 률 (namespace별)group by cache_namespace테넌트 편차 모니터링
similarity_score 분포histogram of similarity_score on HIT임계값 근처 bin 과도 주의
False-positive 프록시👎 피드백 / regenerate 클릭률 (cache_hit=true 조건)베이스라인 대비 상승 없을 것
절감 토큰 합계sum(tokens_saved) on HIT비용 리포트
캐시 스토어 크기Redis DBSIZE, 메모리 사용량TTL·eviction 정책 점검

알림 규칙​

알림조건심각도
HIT 률 급락HIT 률이 이전 24h 평균의 50% 미만Warning — 임베딩/Redis 장애 가능
HIT 률 비정상 상승HIT 률이 70% 초과 + false-positive 프록시 동반 상승Critical — 임계값 오설정 의심
similarity_score 편중임계값 ±0.02 내 HIT 비율 > 40%Warning — 경계선 매칭 과다
Redis latencyP99 > 20msWarning — 캐시가 병목

Langfuse OTel 연동 참조​

Bifrost/LiteLLM의 OTel 전송 설정은 기존 LLMOps Observability 및 추론 게이트웨이 구성 가이드 문서를 따릅니다. 캐시 관련 태그는 애플리케이션/게이트웨이 플러그인 레이어에서 span attribute로 추가합니다.

7. 실전 체크리스트​

보안 & 프라이버시​

  • PII 포함 프롬프트 캐시 금지 (Guardrails를 Semantic Cache 앞에 배치)
  • 프롬프트 인젝션 탐지 시 캐시 저장 금지
  • 크로스 테넌트 누수 방지 (namespace 설계를 단위 테스트로 강제)
  • 감사 로그 최소 90일 보존 (HIT/MISS, namespace, similarity_score)

운영 & 수명주기​

  • TTL: 정적 KB 7-30일 / 제품 정보 1-24h / 뉴스·시계열 비활성
  • 모델 버전 교체: 키에 버전 포함 (glm-5:v2026-03) → 자연 만료
  • 임베딩 모델 교체: 전량 재구축 필수
  • 장애 fallback: Redis 장애 시 fail-open (원본 rate limit 사전 확보)
  • 점진적 롤아웃: 신규 정책은 A/B로 검증

품질 가드레일​

  • 큰 응답·도구 호출 결과는 캐시 금지 또는 짧은 TTL
  • 사용자 👎 피드백 시 해당 entry 자동 eviction
  • 캐시 HIT 샘플을 주간 평가 (Ragas/LLM-judge)

배포 전 점검​

  • 캐시 키에 model_id, system_prompt_hash, tenant_id, language 포함
  • Guardrails가 캐시보다 앞단에 배치
  • Langfuse 트레이스에 cache_hit, similarity_score 기록
  • HIT 률 / false-positive 대시보드 구성
  • Redis 장애 시 fail-open 시나리오 검증

8. 도메인별 적용 패턴​

동일한 Semantic Cache 엔진이라도 도메인에 따라 키 구성·임계값·TTL 이 크게 다릅니다.

도메인임계값TTL특성
FAQ / 제품 Q&A0.80-0.8524-72h질의 반복적, 정답 고정적. 키: tenant+language+product_version
사내 KB0.85-0.901-7d권한별 격리 우선. 키: tenant+role_hash+language
고객 지원0.856-24hPII는 Guardrails에서 redact 후 임베딩. 키: tenant+intent+language
코드 생성/IDE0.97+ 또는 비활성30m-2h컨텍스트 의존성 높음. 리팩터링·디버깅은 비활성 권장

주의사항:

  • FAQ/제품 Q&A: 제품 버전 변경 시 product_version 키로 자연 무효화
  • 사내 KB: ACL 변경 시 해당 사용자 namespace flush 필수
  • 고객 지원: PII(이름, 주문번호) 반드시 Guardrails 경유
  • 코드 생성: 파일·리포 컨텍스트가 다르면 같은 질의라도 다른 답 필요

9. FAQ​

Q1. Semantic Cache와 RAG는 어떻게 다른가요?
RAG는 새 응답 생성을 위한 컨텍스트를 벡터 DB에서 가져오는 것, Semantic Cache는 기존 완성 응답을 재사용하는 것입니다. RAG는 LLM 호출 전에 입력 보강, Semantic Cache는 LLM 호출 자체를 회피합니다.

Q2. 스트리밍 응답도 캐시 가능한가요?
가능하지만 재조립·재현 복잡도가 높습니다. 초기엔 비스트리밍 엔드포인트부터 적용을 권장합니다.

Q3. 임베딩 모델 선택 기준은?
다국어면 bge-m3, text-embedding-3-large. 영어 전용이면 text-embedding-3-small. 모델 교체 시 전체 캐시 무효화 필수입니다.

Q4. temperature > 0 요청을 캐시하면 위험한 이유는?
사용자가 의도적으로 다양한 답을 원해 temperature를 높인 것인데 같은 답이 돌아오면 기대 위배입니다. 창의적 엔드포인트는 캐시 비활성이 기본입니다.

Q5. 캐시 HIT 률이 낮으면 어떻게 하나요?
namespace 과도 세분화 점검 → 임계값 0.05 낮춤 → 임베딩 모델 품질 평가 순서로 진행하세요. FAQ가 아니면 10-15% HIT 률도 정상입니다.

Q6. 캐시된 응답의 규정 준수 이슈는?
의료·금융·법률 도메인에서는 캐시 HIT도 감사 로그 기록 의무가 있을 수 있습니다. cache_hit=true 를 반드시 로깅하고 규제 보존 기간을 준수하세요.

10. 참고 자료​

공식 문서 & 레포지토리​

관련 문서​

연구 & 배경​