LLM 서빙 캐싱 ⑩ — 캐시 vs 파인튜닝 vs 프롬프트 압축: 프리픽스를 안 보내는 선택

5K 토큰짜리 시스템 프롬프트에 few-shot 예시 스무 개를 넣고 있다면, 이 시리즈의 암묵적 답은 "캐시해라"였다. CTO의 대안은 둘 더 있다. 그 프롬프트를 파인튜닝으로 모델에 구워 넣어 아예 안 보내거나, 압축해서 짧게 보내거나. 이 글은 2026년 8월 가격으로 세 선택의 100만 요청당 비용을 계산하고, 파인튜닝이 진짜 이기는 조건과 자체 서빙에서 LoRA 어댑터가 프리픽스 캐시를 쪼개는 함정을 다룬다.

"캐시하지 말고 없애라"는 유혹과 1.5배 프리미엄

OpenAI의 파인튜닝 모델 추론은 베이스의 1.5배다: ft:gpt-4.1 입력 $3/캐시 $0.75/출력 $12(베이스 $2/$0.50/$8), 학습 $25/M토큰. GPT-5 계열은 파인튜닝이 불가하고 SFT/DPO는 4.1 계열, RFT는 o4-mini뿐이다. Anthropic은 1st-party 파인튜닝이 없고 Bedrock의 Claude 3 Haiku만 가능한데 커스텀 모델은 Provisioned Throughput 필수(시간당 고정비, 단가는 영업 문의). Gemini API의 파인튜닝은 2025-05 종료됐고 Vertex 전용이다. 세 벤더 모두 "캐시가 기본, 튜닝은 엔터프라이즈 옵션"으로 정렬됐고, Anthropic 문서는 아예 "예시 1~2개 대신 20개 이상을 넣고 캐시하라"고 쓴다.

100만 요청 시뮬레이션

가정: 정적 프리픽스 8,000 + 동적 입력 500 + 출력 300 토큰. 파인튜닝 후 프리픽스 −85%(잔여 1,200), 학습 22.5M 토큰.

시나리오	$/100만 요청
(a) Sonnet 5, 캐시 없음	$20,000
(b) Sonnet 5, 캐시 히트 95% / 80% / 50%	$6,520 / $9,280 / $14,800
(b') gpt-4.1 베이스, 캐시 95%	$8,000
(c) ft:gpt-4.1, 짧은 프롬프트, 캐시 없음	$8,700 + 학습 $562
(c') ft:gpt-4.1 + 잔여 프리픽스 캐시 95%	$6,135 + $562
(c'') ft:gpt-4.1-mini (한 단계 작은 모델)	$2,320 + $112
(d) Sonnet 5 + LLMLingua-2 3배 압축(고유 문서)	$9,334 + 압축 GPU

읽을 점: 같은 티어에서는 캐시가 파인튜닝을 이긴다(b' $8,000 vs c $8,700) — 1.5배 프리미엄이 프리픽스 절감을 상쇄한다. 파인튜닝 모델에도 캐시를 걸어야(c') 역전되고 학습비 회수에 약 30만 요청이 든다. 캐시 손익분기 히트율은 5분 TTL 21.7%, 1시간 52.6%(④편). Bedrock PT 고정비 예시($40/시간)로 Sonnet 5 캐시 95%와 같아지려면 월 450만 요청이 필요하다.

파인튜닝이 진짜 이기는 세 가지 경우

• 모델 다운그레이드: 표의 c''가 3.4배 싸다. 이건 프리픽스 문제가 아니라 "작은 모델이 이 작업을 하는가"라는 품질 평가 문제다 — sLM 평가 시리즈의 베이스라인 사다리가 여기서 쓰인다. Bedrock Haiku 3 파인튜닝 사례: 모더레이션 정확도 81.5→99.6%, 쿼리당 토큰 −85%.
• 컨텍스트에 안 들어가는 데이터: Bertsch et al.은 수백~1,500 shot 구간에서 long-context ICL이 대부분 LoRA를 넘고(Clinic-150, 151라벨에서 ICL 1,500 shot ≈ 89%), 고정 예시 집합을 한 번 인코딩해 캐시해도 손실 ≤5점이라고 보고했다. Many-shot ICL(DeepMind)도 "파인튜닝과 비슷하되 추론 비용은 선형 증가" — 즉 캐시 없이는 성립하지 않고, 캐시가 있으면 파인튜닝이 필요 없는 구간이 넓다. 파인튜닝이 이기는 건 데이터가 컨텍스트를 넘을 때다.
• 최소 캐시 단위 미만: 프리픽스가 1,024(Sonnet 5)·4,096(Haiku 4.5) 토큰 미만이면 캐시 자체가 안 걸린다. "프롬프트 줄이기"가 캐시 자격을 없앨 수 있고, 그 구간에서는 짧은 프롬프트 + 파인튜닝이 합리적이다.

자체 서빙의 함정 — LoRA 어댑터는 프리픽스 캐시를 쪼갠다

vLLM의 블록 해시는 lora_name을 키에 포함하고(③편), SGLang의 RadixKey는 extra_key가 다르면 프리픽스 노드를 공유하지 않는다. 테넌트 100개를 어댑터로 나누면 공유 시스템 프롬프트의 캐시가 100조각이 된다. 계산 오버헤드 자체는 작다 — S-LoRA는 A100 한 장에 어댑터 2,000개, Punica는 토큰당 ≈2ms — 손실은 히트율과 KV 메모리 잠식에서 온다. 결정 매트릭스: 말투·규칙·예시 차이는 프롬프트(공유·캐시 가능), 출력 분포 변경·수천 라벨·컨텍스트를 넘는 지식은 어댑터(격리). 어댑터라도 --max-loras(GPU 상주)·--max-cpu-loras(CPU 대기)로 상위 트래픽만 상주시킨다.

압축의 자리, 그리고 한국어

LLMLingua-2는 3배 압축에서 MeetingBank QA 86.9 vs 87.8, GSM8K 손실 0, 5배에서 LongBench −11%. 캐시 읽기(정가 10%)가 압축(20~33%)보다 싸므로 압축은 캐시의 대체재가 아니라 보완재다 — 캐시가 못 잡는 고유 장문 문서(표의 d)에만 쓰고, 정적 프리픽스에 압축을 걸면 토큰이 바뀌어 캐시 키가 깨진다. 한국어 프리픽스는 1.3~2배 토큰(⑪편)이라 캐시 절감액도 파인튜닝 절감액도 커지고, 한국어 토크나이저 모델(A.X·EXAONE·Solar)이 제3의 길이다. 국내 벤더는 Upstage가 캐시 요율은 공개했지만 튜닝 단가는 비공개, CLOVA Studio는 튜닝 추론 프리미엄이 문서에 없다 — 계약 전 서면 확인 항목이다. LLMLingua-2의 한국어 성능은 미검증이고 조사(은/는/이/가) 삭제 리스크가 있으니 자체 평가가 먼저다. 마지막 글은 한국어 조건 전체와 결정 트리다.

— LLM 서빙 캐싱 시리즈 ⑩ / 다음 글: 한국어 맥락과 CTO 플레이북 (완결)

LLM 서빙 캐싱 ⑨ — 캐시 수명주기 운영: 워밍, 콜드 캐시, 오토스케일링

히트율은 설계 시점의 속성이 아니다. 파드가 늘어날 때, 모델을 교체할 때, 스팟 노드가 회수될 때, 트래픽이 TTL보다 뜸해질 때마다 무너진다. API 사용자에게는 "4분 30초마다 핑을 보내 5분 캐시를 살려둘까"가 곧 청구서 결정이고, 자체 서빙에서는 오토스케일링이 캐시 지역성을 깬다. 이 글은 캐시가 죽는 순간의 비용을 계산한다.

캐시는 쓰는 순간이 아니라 죽는 순간에 돈이 샌다

만료 모델이 벤더마다 다르다. Anthropic은 5분/1시간 TTL이고 읽힐 때마다 무료로 갱신되며 수명은 요청 시작 시점부터다. OpenAI(GPT-5.6+)는 마지막 사용 후 30분 슬라이딩, 구모델은 prompt_cache_retention: "24h"가 추가 요금 없이 제공된다 — 워머가 필요 없다. Gemini 명시적 캐시는 시간당 저장료(2.5 Pro $4.50, Flash·3.x $1.00 per M토큰·시간)가 붙는다. 만료 뒤 첫 요청은 쓰기 할증(×1.25 또는 ×2)을 다시 낸다.

keep-alive 손익분기 — Sonnet 5로 직접 계산

• 단가(프리픽스 1M 토큰당): 읽기 $0.20, 5분 쓰기 $2.50, 1시간 쓰기 $4.00. 5분 워머(max_tokens: 0, 공식 지원) 유지비 = 시간당 읽기 12회 = $2.40/시간. 미스 1회 추가 비용 = 쓰기 − 읽기 = $2.30. 1시간 캐시 프리미엄 = $1.50/쓰기.
• 결론 1: 5분 워머는 다음 요청이 ~57분 안에 확실할 때만 이득이고, 1시간 공백을 워머($2.40)로 메우는 것보다 1시간 TTL($1.50)이 싸다. 요청이 시간당 0.55건만 넘어도 1시간 TTL이 5분을 이긴다. 10분 간격 트래픽 예: 5분 캐시 $8.37/시간, 5분+워머 $1.46~2.40, 1시간 캐시 $0.06.
• 결론 2: 프롬프트 하나의 keep-alive는 동전 단위다(10K 프리픽스면 야간 15시간 유지 vs 재작성 차이 $0.01). 진짜 돈은 요청당 미스율 × 요청 수 — 팬아웃과 롤아웃 — 에서 샌다. 아침 프리워밍은 첫 사용자의 쓰기를 앞당길 뿐 비용 +0, TTFT만 이득.
• Gemini: 명시적 캐시는 시간당 히트 4건 이상일 때만 회수되고, 2.5 Pro 100K를 야간 15시간 유지하면 재생성의 54배 — 퇴근 시 삭제, 출근 시 재생성(expireTime).

팬아웃과 롤아웃 — 캐시가 한꺼번에 비는 두 순간

• 팬아웃: 캐시는 "첫 응답이 시작된 뒤"에 생긴다. 10K 프리픽스를 워커 50개가 동시에 콜드로 치면 50 × $0.025 = $1.25, 첫 요청의 first-byte를 기다린 뒤 49개를 보내면 $0.12 — 1/10이다.
• 스케일아웃: 라운드로빈이면 N→N+1 직후 클러스터 히트율 ≈ 기존 × N/(N+1)(4→5대면 즉시 −20%p). 사용자별 멀티턴이 대부분이면 옮겨진 대화마다 전체 prefill 1회 — "동기화된 재계산 폭풍"이고 롤링 업데이트는 이를 레플리카 수만큼 반복한다. llm-d의 sticky-until-saturated는 캐시 토큰 80% 이상 엔드포인트에 붙이되 미캐시 in-flight 토큰이 임계를 넘을 때만 새 레플리카를 열어 기존 히트율을 보존하고, P2P KV 풀은 48K 프리픽스 재계산 1,988ms를 235ms로 줄였다.
• 국내 사례: 토스증권(2026-08)은 배포 직후 프리픽스 캐시 히트율 0% — 설정 실수가 아니라 reasoning 모델 특성상 기본으로 꺼져 있었다. 켜니 20초 가까이 걸리던 TTFT가 1/10, 히트율 90%+. 같은 글의 다른 교훈: KV 사용률 1% 미만인데 처리량이 포화 → 동시성 한도만 올려 4배.
• 롤아웃 = 전체 무효화: 토크나이저·챗 템플릿·모델 버전이 바뀌면 L3 스토어의 KV까지 전부 무효(Claude 4.7+ 토크나이저도 토큰 ~30% 증가). 모델 업데이트는 업무시간 밖에, 카나리 1대를 readiness probe에서 핫 시스템 프롬프트 N개로 한 바퀴 데운 뒤 전환.

게이트웨이가 안 해주는 것, 스케일링 신호, 스팟

동일 요청이 동시에 N건 들어올 때의 in-flight 병합(singleflight)은 Cloudflare가 문서로 명시하듯 아무도 안 해준다("동시에 온 두 번째 요청은 첫 번째가 캐시되기 전일 수 있다") — LiteLLM·Portkey·Helicone·Kong 전부 응답 캐시일 뿐이다. temperature 0 + body 해시로 "동일"을 정의하고 앱에서 Go singleflight나 Redis SET NX로 직접 구현한다. 스케일링 신호는 GKE 권고대로 큐 깊이(3~5) > 배치 크기 > GPU 지표 — vllm:kv_cache_usage_perc는 메모리 압력이지 과부하가 아니다. KEDA 기본 cooldown 300초는 LLM 파드 기동보다 짧을 수 있으니 기동 시간 이상으로. 스팟은 GCP 최대 91% 할인이지만 통지 0~120초·유예 30초, AWS 2분이라 80GB의 KV를 내보낼 수 없다 — HiCache/LMCache의 L3 write-through가 전제이고, 스팟은 배치·오프피크 prefill 풀에, 실시간 디코드는 온디맨드에.

한국 시간대의 트래픽 셰이핑과 고정 GPU

KST 09~18시 형태의 트래픽이면: Anthropic 1시간 TTL 기본(점심 공백 통과, 아침 프리워밍 1회), OpenAI는 24h, Gemini는 09시 생성·18시 만료. DeepSeek의 피크(UTC 01~04·06~10시)는 정확히 KST 10~13시, 15~19시 — 한국 업무시간이라 오프피크 50%를 받으려면 비실시간 작업을 13~15시와 19시 이후로 옮긴다. Batch API는 시간대 무관 50%이고 Anthropic은 캐시 할인과 중첩된다(배치 내 히트율 30~98%, 1시간 TTL 권장). 그리고 ⑪편에서 다룰 KT·NCP 고정 할당 GPU는 scale-in이 없어 "항상 따뜻하지만 야간에 논다" — 여기서는 keep-alive 문제가 사라지는 대신 야간 15시간을 채우는 배치(임베딩 재생성·평가·요약 백로그)가 곧 절감이다. 다음 글은 프리픽스를 캐시하는 대신 아예 안 보내는 선택, 파인튜닝과의 손익 비교다.

— LLM 서빙 캐싱 시리즈 ⑨ / 다음 글: 캐시 vs 파인튜닝 vs 프롬프트 압축 — 프리픽스를 안 보내는 선택

LLM 서빙 캐싱 ⑧ — 도입 전에 재기: 로그 리플레이로 히트율 상한 추정

앞의 일곱 편에 나온 절감률 — 41~80%, 7%→84%, 히트율 25% — 은 전부 남의 트래픽 숫자다. CTO의 진짜 질문은 "우리 트래픽에서는 얼마나 나오나, 엔지니어 몇 주를 쓰기 전에 알 수 있나"다. 답은 있다. 프로덕션 로그를 리플레이해서 히트율의 상한을 재고, 벤치 도구로 타임스탬프까지 재현하고, API의 usage 필드로 실제 절감액을 검증하는 세 층이다. 이 글은 그 방법과 함정, 그리고 추정치와 실측치가 왜 벌어지는지를 다룬다.

상한(ceiling)은 예측이 아니다

무한 캐시를 가정하고 모든 요청을 prefix tree에 넣으면 "공유되는 토큰 비율"이 나온다. Preble의 측정은 도구 사용 85%, 임바디드 에이전트 97%, 프로그램 생성 97%, 장문 QA 91%. TraceLab(코딩 에이전트 4,265세션, 357,161스텝)은 사용자 프롬프트와 도구 결과만 "새 토큰"이라 전체 prefill의 약 81%가 원리상 캐시 가능하고, 실현 히트율은 95.7%였다. 반면 Mooncake(Kimi) 실트레이스는 무한 저장소여도 이론 상한이 ~50%, LRU 1K 블록에서 30%, 50K 블록에서야 50%였고 블록의 절반 이상은 두 번 다시 쓰이지 않았다. TraceLab에서 미스는 5분 유휴부터 시작해 1시간이면 거의 전부였고, 사람이 생각하는 동안의 공백이 비용의 12.8%였다. 상한과 실측을 벌리는 최대 변수는 TTL이다.

로그 분석 3종 — 프리픽스 상한, 정확일치 중복률, 근사중복률

토큰 가중 프리픽스 상한은 이렇게 잰다. 요청을 시간순으로 정렬하고, 실제로 보낸 그대로(tools+system+messages) 렌더링해 로컬 토크나이저로 토큰화하고, 스트림(테넌트·prompt_cache_key)별 radix trie에 넣되 노드마다 마지막 사용 시각을 기록한다. 새 요청은 블록 단위로 trie를 따라가다 (a) 자식이 없거나 (b) 마지막 사용이 TTL 밖이면 멈추고, 그때까지의 토큰 수가 히트다. 함정 둘: 부분 블록은 히트가 아니다(vLLM 16토큰, Mooncake 512토큰 단위로 내림 — vLLM의 오프라인 분석기 RFC가 실제 해시 체인을 그대로 재현한다), 그리고 API 최소 프리픽스(Claude 512~4,096, GPT-5.6+ 1,024) 미만이면 0이다 — OpenAI 쿡북의 예시로 900토큰 프롬프트는 절감 0, 1,100토큰은 히트 70%에서 −55%. TTL ∈ {5분, 30분, 1시간}, 블록 ∈ {16, 512}, 스트림 ∈ {테넌트, 키, 전역}으로 스윕하면 그 퍼짐이 곧 예상 오차다. 정확일치는 정규화 프롬프트의 SHA-256을 TTL 창 안에서 세고, 근사중복은 마지막 사용자 턴을 임베딩해 임계값 이상을 센다 — 단 뒤에서 보듯 이 마지막 숫자는 라벨 없이 믿으면 안 된다.

재현 테스트 — 타임스탬프까지 재생하기

• vllm bench serve: --dataset-name prefix_repetition(프리픽스·접미사 길이, 프리픽스 수), custom(내 JSONL), timed_trace(Mooncake 형식, --timed-trace-sec-multiplier 0.001로 원속도 재생), --request-rate·--burstiness(1 미만이면 버스트).
• SGLang bench_serving: generated-shared-prefix의 --gsp-group-distribution zipf가 "몇 테넌트가 트래픽을 지배"하는 현실을 모델링하고, --mooncake-workload conversation|agent는 한 줄 리플레이다.
• inference-perf(llm-d): OTel GenAI 스팬에서 에이전트 DAG를 복원해 기록된 대기 시간을 wait_ms로 보존한다 — 사람 공백을 재현하는 유일한 도구. NVIDIA GenAI-Perf는 세션 delay로 "사용자 멈춤 길이 vs TTL"을 스윕한다.
• 클러스터 단위 추정은 틀린다: llm-d에서 같은 코드 생성 워크로드가 동시성 20에서 48%로 정점을 찍고 레플리카 KV가 차면 무너졌지만, 150테넌트×6K 프리픽스 B2B는 90~95%를 유지했다. 레플리카·라우팅 키 단위로 추정할 것.

API 쪽 검증 — usage 필드와 캐시 진단

절감액 = Σ캐시 토큰 × (정가 − 읽기 단가) − Σ쓰기 토큰 × (쓰기 단가 − 정가). ProjectDiscovery의 방법이 표준이다: 실제 지출 vs "같은 볼륨을 전액으로 냈을 가상 비용"을 스트림별·주별로 — 집계는 오도한다(고정 스트림 84% vs 집계 69%). 작업 길이별 캐시율은 1스텝 35.5%, 20스텝 이상 74%, 1,225스텝 91.8%. 미스 원인은 Anthropic의 cache-diagnosis 베타가 system_changed | tools_changed | messages_changed와 cache_missed_input_tokens로 알려주고, OpenAI는 prompt_cache_key를 붙이는 것만으로 한 고객이 60%→87%가 됐다(키당 ~15 RPM 초과 시 콜드 레플리카). count_tokens는 무료(2,000~8,000 RPM)라 로그 토큰 가중치를 매기는 데 쓰면 된다.

시맨틱 캐시는 라벨 없이는 숫자를 믿지 말 것

2026년 8월 연구가 결정적이다: LMSYS-Chat·Quora·MOSS 각 10만 질의에서 임계값 0.90의 원시 히트율 50.7~57.0%가, Llama-3.1-8B 심판으로 "답을 대체해도 되는가"를 검사하자 1.6~2.2%로 줄었다. 임베딩 기반 추정은 10배 이상 부풀 수 있다(⑥편의 vCache가 보인 임계값 딜레마와 같은 이야기). 방어 가능한 프로토콜은 유사도 0.80~0.99 구간에서 5,000쌍 샘플, 라벨러 3명, 의도 클래스별 임계값(FAQ 0.94·지원 0.92·거래 0.97), 매주 히트의 1~5% 블라인드 감사 — 이 절차로 18%→67% 히트, 오탐 0.8%, −73%가 나왔다. 한국어는 KLUE-STS(≥4.0을 양성), KorSTS, PAWS-X ko(어휘는 겹치지만 뜻이 다른 적대적 음성 — 임베딩 캐시의 정확한 함정)로 시드를 만들고 자사 로그 쌍으로 교체한다. 평가 비용은 작다: vLLM 분석기는 CPU만, Mooncake 대화 리플레이(12K 요청, 1시간)는 GPU 한 대, 국내 SK 데보션의 부하테스트 글처럼 하루면 돌린다 — 비싼 줄은 라벨링뿐이다. 다음 글은 이렇게 얻은 히트율이 운영 중에 무너지는 순간들이다.

— LLM 서빙 캐싱 시리즈 ⑧ / 다음 글: 캐시 수명주기 운영 — 워밍, 콜드 캐시, 오토스케일링

LLM 서빙 캐싱 ⑦ — KV 압축·오프로딩·클러스터 공유: HBM 밖으로

②편에서 70B 모델의 128K 요청 하나가 KV 40GB, ③편에서 GPU 캐시 용량이 히트율을 막는 순간을 봤다. HBM은 비싸고 2026년에 더 비싸진다 — TrendForce는 3분기 서버 DRAM 계약가 +13~18%, HBM은 2027년 "수 배"를 예고했다. 그래서 KV 캐시를 (a) 작게 만들거나 (b) 싼 메모리로 옮기거나 (c) 클러스터 전체에서 공유하는 세 갈래가 서빙 비용의 다음 전선이다. 각각 언제 이득이고 언제 손해인지를 숫자로 본다.

작게 만들기: FP8은 공짜, 4비트는 계산서가 온다

• FP8 KV: vLLM 2026-04 재측정에서 --kv-cache-dtype fp8은 처리량 손실 0에 KV 2배, Qwen3.5-27B AIME25 99%·Llama-3.3-70B 128K MRCR 97~98% 회복. 단 손익분기는 H100 ~7K 토큰(B200 ~4K) 이상이고, Hopper FP8 누적 오차로 128K needle이 91%→13%로 무너진 버그가 있었다(two-level accumulation으로 89% 복구). 교훈: 장문 회귀 테스트 없이 켜지 말 것.
• 3~4비트: TurboQuant 비교에서 4비트는 추론 98% 회복이지만 처리량 BF16의 75~80%, 3비트는 AIME/GPQA −20점에 처리량 66~73%. 디퀀트 오버헤드가 메모리 절감을 되갚는다. 결론 "FP8 기본, 4비트는 극한 상황만". KIVI(2비트, 배치 4배)·KVQuant는 학계 상한선.
• 토큰 축출: H2O는 heavy hitter 20%만 남겨 처리량 최대 29배, StreamingLLM은 sink 토큰 + 슬라이딩 윈도우로 400만 토큰 스트리밍. 그런데 2025-12 비교 연구는 낮은 예산 축출이 추론 모델의 트레이스를 길게 만들어 절약분을 되갚는다고 보고했다. 출력 토큰이 늘면 청구서는 오른다.

싸게 옮기기: CPU DRAM → NVMe → 원격 스토어

• vLLM KV Offloading Connector(0.12): --kv_offloading_backend native --kv_offloading_size <GB>. H100/Llama-8B 단일 요청 TTFT 2~22배, 동시 요청 처리량 최대 9배(히트율 비례). "지연보다 처리량 이득이 훨씬 크다."
• SGLang HiCache: GPU(L1)→CPU(L2)→외부(L3: Mooncake·3FS·NIXL·파일). 최대 6배 처리량, TTFT −80%. Novita AI(Qwen3-Coder-480B, 8턴·25K+)에서 히트율 40%→80%, TTFT −56%; Ant Group(R1-671B)에서 TTFT −84%.
• LMCache/MI300X: DRAM 64GB만 붙여 TTFT 3.0배, 완료 요청 2.3배. 함정: PYTHONHASHSEED=0 없으면 히트율 0.
• 하드웨어 의존: TRT-LLM 호스트 오프로드 재사용 TTFT 14배(H100 x86) vs 28배(GH200). CPU-GPU 대역폭이 ROI를 좌우한다.
• 국내 벤치: 래블업×VAST(Mistral Medium 3.5 128B, 8×H100, 140K 토큰, vLLM+LMCache, GDS 100Gbps)는 첫 턴 +4초(22.3→26.3s), 이후 턴 22.0→6.6초(3.3배), 전체 1.96배. Backend.AI 한국어 해설의 조건표: 70B 이상·10K 토큰 이상·공유 프리픽스가 많으면 이득, 단일 턴 챗봇·TCP NFS면 손해.

클러스터에서 공유하기: Mooncake와 DeepSeek의 숫자

• Mooncake(Kimi): prefill/decode 분리 + 유휴 CPU·DRAM·SSD를 분산 KV 풀로. 실서비스에서 75% 더 많은 요청(FAST'25 버전 A800 115%), 수천 노드, 일 1,000억+ 토큰. vLLM×Mooncake 에이전트 벤치(SWE-bench 트레이스 610개, 중앙값 33턴, 재사용 프리픽스 94.2%)에서 로컬 캐시 히트율은 1.7%였는데 Mooncake Store로 92.2% — 처리량 3.8배, P50 TTFT 46배, 12→60 GPU 선형. 에이전트 워크로드는 로컬 프리픽스 캐시를 무력화한다(재사용은 94%인데 히트는 1.7%).
• DeepSeek 공개 손익: 평균 226.75 H800 노드, 일 비용 $87,072 vs 이론 매출 $562,027(마진 545%). 입력 608B 토큰 중 56.3%가 디스크 KV 히트. V4 캐시 히트는 미스의 3.3% — 히트율이 곧 단가다.
• 라우팅 먼저: ③편의 llm-d 라우팅만으로 P90 TTFT 57배. 오프로드 전에 "요청을 캐시가 있는 파드로". PD 분리는 이제 표준이고 DistServe 기준 KV 전송비는 지연의 0.1% 미만, NIXL이 RDMA부터 S3까지 백엔드화했다. ByteDance AIBrix는 L1 DRAM + L2 원격(RDMA)으로 P99 TTFT 384.6초→0.22초.

CTO 체크리스트: 우리 워크로드에 맞는 계층은

순서는 측정(프롬프트 길이·턴 수·프리픽스 공유율, ⑧편) → FP8 KV(7K 토큰 이상이면) → 프롬프트 정렬과 라우팅(③편) → CPU DRAM 오프로드(멀티턴·긴 문서·70B 이상) → 멀티노드면 공유 스토어. 운영 함정은 PYTHONHASHSEED, 프롬프트 앞의 타임스탬프, 멀티테넌트 cache_salt, 장문 회귀 테스트. 여기까지가 "캐시를 어떻게 쓰나"였다면, 다음 세 편은 "우리 트래픽에서 얼마나 남는지 도입 전에 어떻게 아나"다.

— LLM 서빙 캐싱 시리즈 ⑦ / 다음 글: 도입 전에 재기 — 로그 리플레이로 히트율 상한 추정

LLM 서빙 캐싱 ⑥ — 시맨틱 캐시: 현실 히트율과 오탐의 비용

앞의 세 편이 다룬 캐시는 전부 입력 쪽이었다. 출력 토큰 — 청구서의 30~60% — 을 줄이는 캐시는 하나뿐이다. 호출 자체를 없애는 응답 캐시. 정확일치 캐시는 공짜이고 오탐이 없지만 잡는 게 적고, 시맨틱 캐시는 더 많이 잡지만 틀린 답을 돌려줄 수 있다. 이 글은 벤더의 "히트율 95%"가 무슨 뜻인지, 국내에서 실제로 돌아간 숫자는 무엇인지, 오탐을 어떻게 다루는지를 정리한다.

같은 질문에 두 번 돈 내지 않기 — 정확일치 캐시부터

키는 정규화한 프롬프트 + 모델 + temperature + 도구 + 프롬프트 버전의 해시. MeanCache는 LLM 서비스 질의의 약 31%가 반복이라고 보고했고, 한 10만 건 샘플에서는 18%가 정확 중복, 47%가 유사, 35%가 신규였다. FAQ 봇이나 분류 작업(temperature 0)이라면 이것만으로 15~30%가 바로 빠진다. Helicone은 해시 키 + 버킷(temperature>0일 때 응답 여러 개 저장), Portkey의 simple 모드, Cloudflare AI Gateway가 이 계층이다.

시맨틱 캐시의 구조와 진짜 히트율

쿼리를 임베딩 → 벡터 검색 → 임계값 이상이면 저장된 응답 반환. 절감액 = 출력 토큰 비용 × 히트율, 임베딩 비용은 토큰당 LLM의 1/1,000이지만 매 요청 발생한다. 벤더가 말하는 "95%"는 히트의 정확도이지 히트 빈도가 아니다. 프로덕션 데이터의 현실 히트율은 FAQ·고객지원 40~60%, 분류 50~70%, 사내 KB 30~45%, 문서 RAG 15~25%, 자유 대화 10~20%, 코드·에이전트 5~15%. Portkey는 기업 RAG 반복률 약 20%(정확도 99%)라고 했다. 인프라는 월 $50~200 — 절감액의 5% 미만이지만, 히트율 10% 미만이거나 월 지출 $1~2K 미만이면 운영 비용이 절감을 넘는다.

당근 사례: 임계값 0.65, 히트 25%, 연 2.16억 원

국내 검증된 유일한 프로덕션 숫자는 당근 채팅팀의 2025년 기록이다. AI 메시지 추천의 LLM 비용이 연 8~9억 원. 발화 1,000건을 text-embedding-3-small로 임베딩해 PCA로 50차원으로 줄이고 DBSCAN으로 군집화하니 60% 이상이 노이즈, 13개 군집·약 260개 대표 문장이 남았다. 이 대표 문장만 캐시로 두고 인프로세스 벡터 스토어(chromem-go, 1,000벡터 ≈ 6MB, 검색 2ms)를 붙였다. 코사인 임계값 0.65에서 오프라인 히트 29.55%, 프로덕션 약 25% → 연 약 2.16억 원. 병목은 임베딩 API 호출(400~800ms)이었고, 맥락에 안 맞는 추천이 나와 메타데이터 필터링을 계획했다. 낮은 임계값이 통한 이유는 원시 이력이 아니라 큐레이션된 대표 문장을 캐시했기 때문이다 — SCALM도 같은 접근으로 GPTCache 대비 히트 +63%, 토큰 −77%.

"내일 날씨"와 "어제 날씨": 오탐을 다루는 다섯 가지 방법

임계값은 상수가 아니다. Portkey의 스윕에서 0.99 → 히트 23.5%/정확도 92.1%, 0.95 → 56.0%/92.6%, 0.90 → 74.5%/92.3%, 0.80 → 87.6%/91.8%. 한 금융 봇은 0.88에서 "계좌 해지"를 "결제 취소"에 매칭했고, 0.7로 내린 사례는 오탐 ~99%였다. 오탐이 조정 후에도 3~5%를 넘으면 임계값이 아니라 모델 문제다.

• 카테고리별 임계값: FAQ 0.94, 상품 0.88, 지원 0.92, 거래 0.97처럼 유형마다 다르게. 거래·가격·재고는 바이패스.
• 의도+슬롯 정규화 키: 2026년 연구에서 GPTCache의 캐시 키 일관성은 37.9%, SetFit 의도 분류기(2ms)로 {의도, 슬롯}을 키로 쓰면 91.1%. "내일/어제 서울 날씨"는 슬롯이 다르니 자연히 분리된다 — 의도 분류 시리즈와 이어지는 지점이다.
• 오류 예산 기반 임계값: vCache(ICLR 2026)는 캐시 항목마다 임계값을 온라인 학습해 정적 임계값 대비 히트 12.5배, 오류 26배 감소.
• 비동기 LLM 판정·캐시 전용 임베딩: Redis LangCache의 20M 파라미터 임베더는 "질문-질문 동치"만 학습했다. 평가는 KorSTS가 아니라 목표 히트율에서의 정밀도(P-CHR)로 — PR-AUC 1위 모델이 고정 임계값에서는 꼴찌일 수 있다.
• 스코프와 버전: 키에 사용자·테넌트·프롬프트 버전·임베딩 모델·KB 버전. 공유 시맨틱 캐시는 키 충돌 공격(적대적 접미사로 주입 성공 82%, 에이전트 도구 하이재킹 90.6%)의 대상이다.

한국어 임베딩은 bge-m3·KURE-v1(자체 호스팅, MTEB-ko 검색 0.52 vs OpenAI 3-large 0.45)·ko-sroberta·Upstage 중 어느 것도 캐시 동치를 학습한 모델은 없으니, 로그에서 뽑은 유사-비동치 쌍 100개 이상으로 직접 재야 한다. 시작 임계값은 0.92 + 여유 0.02, 응답 캐시는 0.98 이상, TTL은 휘발성 15~30분·FAQ 수일. 다음 글은 다시 서버 쪽으로 돌아가 KV 캐시를 HBM 밖으로 내보내는 이야기다.

— LLM 서빙 캐싱 시리즈 ⑥ / 다음 글: KV 압축·오프로딩·클러스터 공유 — HBM 밖으로

LLM 서빙 캐싱 ⑤ — 에이전트·멀티턴·RAG: 앱 계층의 캐시 다섯 층

에이전트의 청구서는 대화가 아니라 반복에서 나온다. 매 턴 같은 시스템 프롬프트, 같은 도구 정의, 같은 이력을 다시 보내고, RAG는 같은 문서를 다시 임베딩하고 다시 리랭킹한다. 이 글은 LLM "주변"의 캐시를 다룬다 — 멀티턴을 캐시 친화적으로 설계하는 규칙, RAG 파이프라인의 다섯 캐시 층, 게이트웨이 설정 한 줄, 그리고 캐시하면 안 되는 것.

에이전트 비용의 정체: 입력 100 : 출력 1

Manus는 "KV 캐시 히트율이 프로덕션 에이전트의 단일 최우선 지표"라고 썼다. 입력:출력이 100:1이니 캐시 읽기(정가의 10%)와 미스의 차이가 곧 10배다. PwC 연구팀의 실험(OpenAI·Anthropic·Google, DeepResearch 세션 500+건, 시스템 프롬프트 10K, 도구 호출 3~50회)에서 전략적 캐싱은 비용 −41~80%, TTFT −13~31%였다. 그런데 "무조건 전체 캐시"는 역효과였다 — 동적 도구 결과를 캐시 경계 안에 넣으면 매번 쓰기 할증만 낸다.

대화는 append-only로 — 히트율 7%가 74%가 된 한 줄

• ProjectDiscovery: 4K 시스템 프롬프트를 매번 보내는데 히트율 7%. 프롬프트 중간의 동적 식별자 하나를 끝으로 옮기자 74%, 월 비용 −59%. 이후 시스템 프롬프트 1시간 캐시·정적 도구 알파벳 정렬·마지막 도구 결과에 5분 슬라이딩 브레이크포인트로 84%까지.
• 규칙: 초 단위 타임스탬프 금지, JSON 직렬화는 결정적으로, 도구는 제거 대신 마스킹(allowed_tools), 이력은 append만. Anthropic은 최상위 cache_control 하나면 브레이크포인트가 자동 전진하고(20블록 룩백), OpenAI는 prompt_cache_key로 세션을 같은 레플리카에 붙인다.
• 요약(compaction)은 공짜가 아니다: 실측에서 전체 이력+캐시는 턴당 $0.11·회상 92%, 요약은 $0.24·회상 38%였다. 캐시 단가가 ≈$0.55/M 이하면 요약이 더 비싸다. 도구 출력 길이 제한만으로 −38%가 나왔고, Anthropic도 "tool result clearing"을 가장 안전한 경량 압축으로 권한다.

RAG 파이프라인의 다섯 캐시 층 — 돈은 어디에 있나

• 쿼리 임베딩 캐시 — 지연용이지 절감용이 아니다. 임베딩 단가는 $0.01~0.15/M(BGE-M3 $0.01, text-embedding-3-small $0.02)이라 월 1,000만 쿼리를 전부 캐시해도 ≈$6.
• 재인덱싱 콘텐츠 해시 — 변경 없는 청크를 다시 임베딩하지 않는 것. 10억 토큰 코퍼스 1회 = $130~150.
• 리랭커 캐시 — 가장 무거운 단계. Cohere Rerank $1~2.5/1K 검색이니 100만 검색 = $1,000~2,500. (query+chunks)→순서를 캐시.
• 검색 결과 캐시 — 유사도 0.85 이상 쿼리는 응답은 달라도 청크는 같다.
• 청크 KV 재사용(자체 서빙) — 프리픽스가 아닌 위치의 문서 KV를 재사용하는 연구가 실제 제품에 들어왔다. CacheBlend(LMCache)는 토큰 10~15%만 재계산해 TTFT 2.2~3.3배·처리량 2.8~5배, TurboRAG는 모델 수정 없이 TTFT 9.4배, Prompt Cache(Yale)는 GPU 8배·CPU 60배. 코퍼스가 고정적이면 인덱싱 시점에 KV까지 만들어 두는 것이 다음 단계다.

게이트웨이는 헤더 한 줄

LiteLLM은 cache_params: {type: redis, ttl: 600}(시맨틱은 redis-semantic + similarity_threshold), Cloudflare AI Gateway는 cf-aig-cache-ttl: 3600과 응답 cf-aig-cache-status: HIT, Helicone은 Helicone-Cache-Enabled + 사용자별 Helicone-Cache-Seed, Portkey는 {"cache":{"mode":"simple","max_age":60}}, Kong은 ai-semantic-cache 플러그인. 도구 결과 캐시는 idempotent이고 TTL 안에 노화하지 않고 부작용이 없을 때만 — TVCache는 키에 인자만이 아니라 상태 이력을 넣어 히트율 70%, 도구 실행 시간 6.9배 단축을 얻었다.

캐시하면 안 되는 것, 그리고 계측

개인화·테넌트 의존 응답(키에 tenant·permission·source version이 없으면 데이터 노출), 시간 민감 정보, 상태 의존 도구 결과, 고위험 응답(환각이 캐시되면 유사 질의 전부 오염), 그리고 임베딩 모델 교체 시 전량 무효화. 국내 실무 가이드의 표현을 빌리면 "자주 히트하는 시스템이 아니라 안전하게 미스하는 시스템". 계측은 cache_read_input_tokens/cached_tokens를 토큰 가중 히트율로 — Langfuse의 OTel 경로에서 캐시 토큰이 정가로 계산되는 버그(2026)가 있었으니 대시보드는 청구서와 대조할 것. 다음 글은 출력 비용까지 없애는 유일한 층, 시맨틱 캐시다.

— LLM 서빙 캐싱 시리즈 ⑤ / 다음 글: 시맨틱 캐시 — 현실 히트율과 오탐의 비용

LLM 서빙 캐싱 ④ — API 프롬프트 캐싱: 가격표, TTL, 손익분기

자체 GPU가 없어도 프리픽스 캐시의 이득은 받을 수 있다. API 제공사가 서버 쪽 KV 캐시를 재사용하고 그만큼 할인해 주는 것이 프롬프트 캐싱이다. 2026년 8월 기준으로 과금 모델은 세 갈래로 정리됐고, 손익분기는 계산할 수 있으며, 청구서를 20~30% 좌우하는 실수가 실제로 일어났다. 가격은 전부 공식 페이지에서 확인한 값이다.

세 가지 과금 모델

• 쓰기 할증형 — Anthropic·OpenAI(GPT-5.6+)·Bedrock. Anthropic은 5분 캐시 쓰기 ×1.25, 1시간 쓰기 ×2, 읽기 ×0.1. Sonnet 5는 입력 $2 / 5분 쓰기 $2.50 / 1시간 쓰기 $4 / 읽기 $0.20 / 출력 $10. 최소 캐시 길이는 모델별 512(Opus 5)·1,024(Sonnet 5)·4,096(Haiku 4.5) 토큰이며 미달이면 에러 없이 조용히 캐시되지 않는다. OpenAI는 2026-07-09 GPT-5.6부터 무료 자동 쓰기를 버리고 같은 ×1.25 / ×0.1 구조 + 명시적 브레이크포인트 + 30분 TTL로 전환했다(이전 모델은 쓰기 무료, 읽기 GPT-5.x ×0.1·4.1/o3 ×0.25, 최소 1,024~2,048).
• 저장료형 — Gemini. 암묵 캐싱은 2.5 이상 기본 활성이고 무료지만 보장이 없다. 명시 캐싱은 토큰 0.1배에 더해 시간당 저장료(3.7 Flash $0.50, 3.1 Pro $4.50 per M토큰·시간)가 붙는다. 100K 토큰 Pro 캐시를 놀려두면 하루 $10.80이 읽기 한 번 없이 나간다.
• 무료 디스크형 — DeepSeek. 2024년 8월 세계 최초의 디스크 KV 캐시. 64토큰 단위, 쓰기 무료, 수 시간~수 일 보존. V4-pro 미스 $1.32 / 히트 $0.044 — 히트가 미스의 3.3%다. 오프피크 50%까지 겹치면 정가의 1.7%.

국내 제공사는 Upstage만 캐시 단가를 공개했다(Solar Pro 4 $0.30 / 캐시 $0.06 / $1.20, Pro 3는 −90%). K-EXAONE은 FriendliAI에서 캐시 −80%, HyperCLOVA X는 캐시 항목이 없고 Kanana는 CBT 중이다. 자세한 건 ⑪편.

손익분기 계산기

• 몇 번 재사용해야 남는가: 5분 캐시는 쓰기 1.25 + 읽기 0.1 = 1.35 vs 정가 2.0 — 두 번째 요청부터 32.5% 절감. 1시간 캐시는 2 + 0.1 + 0.1 = 2.2 vs 3.0 — 세 번째부터. Anthropic 문서는 "5분 캐시는 read 1회, 1시간 캐시는 read 2회면 본전"으로 쓴다.
• 히트율 기준: 유효 단가 = H × 0.1 + (1 − H) × 1.25. 손익분기 히트율은 5분 약 22%, 1시간 약 53%. AWS의 표현은 "읽기가 토큰 흐름의 ~20%를 넘으면 순절감".
• 90% 할인 ≠ 90% 절감: 히트율 90%, 5분 캐시면 미스 10%가 ×1.25라 절감은 78.5%다. 1시간이면 71%. 그리고 ①편에서 본 대로 출력이 캐시되지 않으니 청구서 전체로는 다시 절반쯤.
• 할인 중첩: Anthropic Batch(50%) × 캐시 읽기 = 정가의 5%. Azure PTU는 읽기 100% 할인. Bedrock은 캐시 토큰이 ITPM 한도에 안 들어간다(1st-party OpenAI는 TPM에 산입).

TTL 하나가 청구액 20~30%를 좌우한다

Claude Code 사용자의 119,866건 로그 분석: 2026년 3월 초 클라이언트가 1시간→5분 TTL로 바뀌자 3월 청구가 25.9%, 넉 달간 $5,561 중 $949(17.1%)가 초과 지불됐다. Anthropic의 답은 "1회성 요청이 많으면 5분이 더 싸서 클라이언트가 자동 결정한다"였다. 다른 사례는 라이브러리 업데이트 후 일 $4~5→$13.86, 한 줄 수정으로 $4.52. 규칙: 요청 간격 5분 미만이면 5분, 5~60분이면 1시간, 1시간 이상이면 max_tokens 최소값으로 프리워밍하거나 포기(워밍 경제학은 ⑨편).

조용한 무효화 체크리스트

• 프리픽스 순서는 tools → system → messages. 도구 정의 한 글자만 바꿔도 전부 무효. Anthropic은 2026년 5월 mid-conversation role: "system", 7월 도구 변경 베타로 탈출구를 열었고, OpenAI는 allowed_tools로 정의는 고정한 채 제한한다.
• 브레이크포인트 앞의 타임스탬프·UUID, 비정렬 JSON, 이미지 detail 변경, thinking/effort 변경, 모델 스위치, web search·citations 토글.
• 동시 요청은 전부 쓰기다 — 첫 응답이 시작된 뒤에야 읽기가 가능하니 팬아웃은 첫 요청 완료 후. OpenAI/Azure는 prompt_cache_key당 약 15 RPM을 넘으면 콜드 레플리카로 흘러 미스가 는다.
• 고유 내용 뒤의 브레이크포인트는 순수 할증(쓰기만 발생). Anthropic 2026-02의 automatic caching은 최상위 cache_control 하나로 마지막 캐시 가능 블록을 자동 추적하고, 5월의 cache_miss_reason 진단 베타가 이유를 알려준다.

측정 필드는 Anthropic cache_read_input_tokens·cache_creation_input_tokens, OpenAI usage.prompt_tokens_details.cached_tokens, Gemini total_cached_tokens. 이 값을 스트림별로 로그에 남기지 않으면 절감은 증명되지 않는다. 다음 글은 에이전트와 RAG에서 이 캐시를 실제로 살리는 배치 규칙이다.

— LLM 서빙 캐싱 시리즈 ④ / 다음 글: 에이전트·멀티턴·RAG — 앱 계층의 캐시 다섯 층

LLM 서빙 캐싱 ③ — 프리픽스 캐싱: 히트율은 엔진이 아니라 프롬프트 배치가 결정한다

같은 시스템 프롬프트를 매 요청마다 다시 계산하고 있다면 GPU는 하루 종일 같은 숙제를 반복하는 셈이다. 프리픽스 캐싱은 앞부분이 같은 요청의 KV를 재사용해 prefill을 건너뛴다. 2026년 현재 vLLM·SGLang·TensorRT-LLM·llama.cpp 네 엔진 모두 기본 활성이라, 질문은 "켜까"가 아니라 "왜 우리 히트율은 낮은가"다. 이 글은 엔진의 메커니즘, 히트율을 결정하는 프롬프트 배치, 그리고 레플리카가 둘 이상일 때 캐시를 깨는 로드밸런서 문제를 다룬다.

네 엔진의 메커니즘 — 히트의 단위가 다르다

• vLLM Automatic Prefix Caching — 16토큰 블록마다 (부모 블록 해시, 토큰 ID, LoRA ID·멀티모달 해시·cache_salt)로 체인 해시를 만든다. 완전히 찬 블록만 캐시되므로 50토큰 프리픽스는 48토큰만 인정된다. LRU 축출, V1에서 기본 활성(--no-enable-prefix-caching으로 끔). 해시 알고리즘이 프로파일에 보이면 --prefix-caching-hash-algo xxhash.
• SGLang RadixAttention — 프롬프트와 생성 결과를 radix tree로 들고 페이지 크기 1토큰이라 짧은 프롬프트에서 손해가 없다. 대기열을 "가장 긴 매칭 프리픽스" 순으로 정렬하는 캐시 인지 스케줄링이 핵심이며, LMSYS 벤치에서 히트율 50~99%, 처리량 최대 5배. 축출 정책은 --radix-eviction-policy로 lru/lfu/priority 선택.
• TensorRT-LLM KV cache reuse — enable_block_reuse 기본 활성, 부분 블록 재사용, 0~100 우선순위 LRU(시스템 프롬프트 고정 가능, 히트율 ~20% 상승), host_cache_size로 축출 전 CPU 오프로드.
• llama.cpp — 슬롯 단위 cache_prompt. 슬롯보다 대화가 많으면 축출되고 --slot-save-path로 디스크 저장. 단일 서버·엣지 계층용.

단일 인스턴스 이득은 크지만 prefill/TTFT에만 걸린다. llm-d의 측정에서 Qwen3-32B 10K 토큰 프롬프트 TTFT는 4.3초→0.6초, 디코드는 그대로다. 국내 SqueezeBits 비교(Llama-3.1-8B, 공유 프리픽스 25%, 출력 1K)에서 처리량은 TRT-LLM +34.7%, vLLM 0.6.3 +13.3%였고, 공유 프리픽스가 전혀 없을 때 당시 vLLM은 −36.7%였다(V1에서 개선). 캐시는 "거의 공짜"지만 워크로드가 맞아야 한다.

히트율은 엔진이 아니라 프롬프트 배치가 결정한다 — 0.3% → 87%

Qwen2.5-32B를 H100 4노드에서 서빙한 사례가 교과서적이다. 1,847토큰 고정 시스템 프롬프트를 쓴 에이전트는 히트율 94%, TTFT 480→110ms, prefill 연산 −38%. 그런데 한 테넌트가 프롬프트 앞 200토큰에 타임스탬프·세션 UUID·도구 출력 해시를 넣자 히트율 0.3%로 떨어졌다 — 47번째 토큰에서 갈라지니 그 뒤 블록 전부가 미스다. 가변 필드를 끝으로 옮기자 87%, TTFT 510→145ms. "Don't Break the Cache"(에이전트 세션 500+건)도 같은 규칙으로 비용 −41~80%를 얻었다. 캐시를 조용히 깨는 것들:

• 요청마다 바뀌는 헤더 — Claude Code가 llama.cpp에 붙인 귀속 헤더 하나가 매 턴 수만 토큰을 재처리시켰다.
• JSON 키 순서 비결정성, 사용자별 도구 목록, 앞부분 컨텍스트 재정렬(뒤 전부 무효).
• 토크나이저·챗 템플릿 버전 변경(캐시의 정체성은 토큰 ID), 마지막 부분 블록, LoRA 전환, 이미지 해시 없는 멀티모달.
• 멀티테넌트에서 cache_salt 없이 공유하면 히트/미스 타이밍으로 다른 테넌트의 프리픽스를 추측하는 사이드채널(PrefixWall)이 생긴다. 공개 시스템 프롬프트만 공유하고 고객 데이터는 salt — 선택적 격리가 전면 격리보다 재사용을 70% 더 남긴다.

레플리카가 2대 이상이면 로드밸런서가 캐시를 깬다

• 1단계 세션 스티키: vLLM Router의 consistent hashing. 챗봇이면 이것으로 충분한 경우가 많다.
• 2단계 프리픽스 해시 라우팅: SGLang 라우터는 워커별 근사 radix tree로 매칭률 기준 라우팅. Llama-3.1-8B 8×A100에서 히트율 20%→75%, 처리량 82.7K→158.6K tok/s.
• 3단계 KV 이벤트 기반: llm-d의 정밀 스케줄링은 16×H100·150테넌트에서 P90 TTFT 0.54초 vs 랜덤 92.6초(170배), 처리량 2배. Baseten의 Dynamo KV 라우터는 50K 토큰 코딩 트래픽에서 히트율 89%, TTFT −50%, RPS +61%. GKE Inference Gateway는 평균 TTFT 2,625→188ms.

작은 클러스터의 현실적 기대치는 처리량이 아니라 꼬리 지연이다 — 4레플리카 멀티턴에서 히트율 62→90%, P95 TTFT 727→237ms, 처리량은 그대로였다. 프롬프트가 전부 고유하거나 200토큰 미만이면 라우팅 투자는 건너뛴다. 이번 주에 할 일: 프롬프트를 고정→few-shot→도구→사용자 데이터 순으로 정렬하고, vllm:prefix_cache_hits / vllm:prefix_cache_queries를 대시보드에 올리고, 세션 스티키부터 켠다. GPU 캐시 용량이 히트율을 막는 순간(HiCache 40→80%)의 이야기는 ⑦편에서.

— LLM 서빙 캐싱 시리즈 ③ / 다음 글: API 프롬프트 캐싱 — 가격표, TTL, 손익분기

LLM 서빙 캐싱 ② — KV 캐시와 메모리 경제학: GPU 한 장에 몇 명을 태우나

자체 서빙에서 GPU 메모리는 두 덩어리로 쓰인다. 모델 가중치와 KV 캐시. 가중치는 상수다 — 모델을 고르는 순간 정해진다. KV 캐시는 변수다 — 동시에 처리하는 토큰 수에 비례해 늘어나고, 이것이 배치 크기를, 배치 크기가 처리량을, 처리량이 토큰당 비용을 결정한다. 그래서 캐싱 시리즈의 두 번째 글은 캐시를 "재사용"하기 전에 캐시가 왜 비용의 변수인지부터 짚는다.

한 줄 공식과 우리 모델의 숫자

토큰 하나의 KV 캐시 크기는 2 × 레이어 수 × KV 헤드 수 × 헤드 차원 × 바이트다(bf16이면 2바이트). Raschka의 아키텍처 갤러리와 DeepSeek-V3 ISCA'25 논문의 표를 합치면 토큰당 bf16 기준으로 Llama-3.1-8B 128KiB, Qwen3-8B 144KiB, Qwen3-32B 256KiB, Llama-3-70B·Qwen2.5-72B 320KiB, Llama-3.1-405B 504KiB, 그리고 MLA를 쓰는 DeepSeek-V3는 68.6KiB다. 70B 모델에 128K 컨텍스트 요청 하나가 들어오면 KV만 40GiB — H100 한 장의 절반이다. vLLM 논문의 13B/A100-40GB 예시는 가중치 65%, KV 30%였고, 4비트로 양자화한 70B의 가중치(32.6GiB)가 4K 요청 32개의 KV(40GiB)보다 작다는 국내 계산 사례도 있다. 청구서의 단위는 요청 수가 아니라 동시 토큰 수다 — 500토큰 100건과 10,000토큰 5건은 같은 값이다.

아키텍처가 4~30배를 좌우한다

• MHA → GQA: GQA 논문대로 64개 Q 헤드에 KV 헤드 8개면 8배 절감. Llama-2-7B 512KiB → Llama-3-8B 128KiB가 이 차이다.
• GQA → MLA: DeepSeek-V2는 512차원 잠재 벡터만 캐시해 KV −93.3%, 최대 처리량 5.76배. 72B GQA 모델(327KB) 대비 4.7배 작다.
• 하이브리드·슬라이딩 윈도우: Qwen3-30B-A3B 96KB, Qwen3.5-35B-A3B 20KB, Nemotron-3-Nano 6KB/토큰. LG의 K-EXAONE 리포트는 48개 레이어 중 36개를 슬라이딩 윈도우로 두고 창을 4,096→128 토큰으로 줄인 이유를 "KV 캐시 사용량 최소화"라고 명시했다.

같은 품질 구간이라면 모델 선택 자체가 가장 큰 캐시 최적화다. 토큰당 KV가 4배 작으면 같은 GPU에 4배 많은 요청을 태운다.

PagedAttention — 낭비 60~80%를 0으로, 대신 커널은 느려진다

vLLM 이전 시스템은 요청마다 최대 길이만큼 연속 메모리를 예약해 실제 토큰 상태는 20.4~38.2%만 채� 다. PagedAttention은 16토큰 블록을 필요할 때 할당해 낭비를 없앴고 처리량이 2~4배(FasterTransformer 대비 최대 22배) 올랐다. 공짜는 아니다. vAttention(MS Research)은 페이지드 커널이 연속 메모리 커널보다 20~26% 느리다고 반박했다. SGLang은 페이지 크기 1토큰, TensorRT-LLM은 블록 단위(기본 128)로 서로 다른 지점에 선다. 블록 크기는 다음 편의 프리픽스 캐시 히트 단위이기도 하다.

KV 풀 → 배치 → tok/s → $/1M 토큰

• 동시성 상한: Llama-3.1-8B를 H100에 gpu-memory-utilization 0.9로 올리면 KV 풀 약 56GB ≈ 458K 토큰 ≈ 8K 요청 56개, 128K 요청은 3.5개. 70B bf16을 H100 2장에 올리면 KV에 4GB(~12K 토큰)밖에 안 남아 FP8 가중치나 4장, 아니면 H200이 필요하다.
• 배치가 비용 손잡이: 국내 스타트업 SqueezeBits의 벤치에서 Llama-3-8B/A100의 디코드 처리량은 배치 4→512에서 30~40배 늘었다. DeepMind 스케일링 북은 70B가 compute-bound가 되는 지점을 배치 ~240으로 본다.
• 비용 환산: $/1M 토큰 = ($/시간 ÷ (tok/s × 3,600)) × 10⁶. H100 $2.90/시간이면 100 tok/s는 $8.06/M, 1,000 tok/s는 $0.81/M, 3,000 tok/s는 $0.27/M. TRT-LLM 튜닝 가이드의 4×H100 Llama-3.3-70B는 설정만으로 1,564→2,474 tok/s(+58%), 즉 토큰당 비용 −37%였다.
• FP8 KV는 조건부 공짜: vLLM의 2026년 재측정에서 --kv-cache-dtype fp8은 바이트를 절반으로 줄이고 정확도 94~100% 회복이지만, 이득은 약 7K 토큰 이상에서만 나고 슬라이딩 윈도우 레이어에서는 0%다. 2024년 vLLM은 FP8 커널이 없어 이득이 ~0%였고 TRT-LLM만 +45%였다는 기록도 기억할 것.

실전 값은 vLLM gpu-memory-utilization 0.90, max-model-len은 실제 필요치로, max-num-batched-tokens는 지연 우선이면 2,048·처리량 우선이면 8,192 이상, 로그에 preemption이 보이면 풀이 모자란 것. 벤더 숫자는 다시 계산하자 — 한 2026년 블로그는 "$2.50/시간에 95 tok/s = $0.73/M"이라 썸지만 맞는 값은 $7.31/M이다. 다음 글은 이 KV를 요청 간에 재사용하는 프리픽스 캐싱이다.

— LLM 서빙 캐싱 시리즈 ② / 다음 글: 프리픽스 캐싱 — 엔진, 프롬프트 배치, 캐시 인지 라우팅

LLM 서빙 캐싱 ① — 입력 토큰이 원가다: 90% 할인이 청구서에서 50%가 되는 이유

LLM 청구서를 줄이는 방법은 크게 셋이다. 더 싼 모델로 바꾸거나, 호출 횟수를 줄이거나, 같은 계산을 두 번 하지 않는 것. 앞의 둘은 품질과 기능을 건드리지만 셋째는 그렇지 않다. 그래서 캐싱은 비용을 고민하는 CTO가 가장 먼저 손대야 할 손잡이다. 이 시리즈는 KV 캐시부터 프리픽스 캐시, API 프롬프트 캐싱, 시맨틱 캐시, 그리고 캐시를 도입하기 전에 우리 트래픽으로 절감액을 추정하는 방법까지, 전부 "돈이 얼마나 줄어드는가"의 관점으로 정리한다. 첫 회는 청구서의 구조와 캐시의 지도다.

청구서의 구조 — 입력은 부풀고 출력은 비싸다

• 입력이 출력보다 10배 이상 많다. OpenRouter의 100조 토큰 통계에서 평균 프롬프트는 6K 토큰, 완성은 400 토큰 안팎(약 15:1)이다. 에이전트는 더 극단적이어서 Manus는 입력:출력 ≈ 100:1이라고 밝혔고, 에이전트 트래픽은 2026년 2월 이후 다섯 달 만에 14배 늘었다. prefill(입력 처리)이 GPU 시간의 85~95%를 먹는 워크로드가 이미 표준이다.
• 출력 단가는 입력의 5~6배다. 2026년 8월 기준 Claude Sonnet 5는 입력 $2/출력 $10, GPT-5.6 Terra는 $2/$12, Gemini 3.1 Pro는 $2/$12(1M 토큰당). 토큰 수로는 입력이 지배하지만, 금액으로는 출력이 30~60%를 차지하는 구조가 여기서 나온다.
• 단가는 매년 2/3씩 떨어지는데 청구서는 오른다. State of FinOps 2026(응답 1,192명)에 따르면 AI 지출을 관리하는 조직이 2년 만에 31%→98%가 됐고, 73%가 AI 예산을 초과했으며 에이전트 프로젝트는 평균 2.4배 초과했다. 문제는 단가가 아니라 볼륨이고, 캐싱은 볼륨을 공격하는 기술이다.

캐시의 네 층 — 각각 다른 비용 항목을 줄인다

• ① KV 캐시(서빙 엔진 메모리) — 자체 서빙에서 GPU 한 장에 몇 명을 동시에 태울 수 있는지를 결정한다. 메모리가 곧 처리량이고 처리량이 곧 $/토큰이다. (②·⑦편)
• ② 프리픽스 캐시 / API 프롬프트 캐싱 — 같은 시스템 프롬프트·문서·대화 이력의 prefill을 다시 계산하지 않는다. 자체 서빙에서는 GPU 시간을, API에서는 과금 토큰을 줄인다(읽기 0.1배). (③·④편)
• ③ 앱 계층 캐시 — 임베딩, 검색 결과, 리랭커, 도구 호출 결과. LLM 주변의 반복 계산을 없앤다. (⑤편)
• ④ 응답 캐시(정확일치·시맨틱) — 호출 자체를 없앤다. 유일하게 출력 토큰 비용까지 줄이는 층이지만, 유일하게 틀린 답을 돌려줄 수 있는 층이기도 하다. (⑥편)

"90% 할인"이 청구서에서 50%가 되는 이유

API 프롬프트 캐싱의 읽기 단가는 정가의 10%다. 그런데 실제 청구서는 90%가 아니라 25~50% 줄어든다. youngju.dev의 산수가 정확하다: 입력 50K·출력 15K 요청에서 40K를 캐시로 돌려도 전체 절감은 28.8%다. 출력이 토큰의 23%인데 비용의 60%이기 때문이다. 하루 10만 건, 시스템 프롬프트 3K·동적 입력 500·출력 300 토큰인 고객지원 봇으로 계산하면 이렇다(Sonnet 5, 월 300만 건).

시나리오	월 비용	절감
A. 캐시 없음	$30,000	—
B. 프롬프트 캐싱 히트율 95%	$14,835	−50.5%
C. B + 시맨틱 캐시로 호출 30% 제거	$10,685	−64.4%
D. C + 비실시간 20%를 Batch API로	≈$9,700	−68%
참고. Llama-3.3-70B 자체 서빙, 8×H100 24시간	≈$16,700 + 운영	B보다 비쌈

읽을 점 세 가지. 첫째, 90% 할인이 50%가 되는 건 출력 30%가 API 계층에서는 캐시되지 않기 때문이다. 둘째, 출력까지 줄이는 건 시맨틱 캐시뿐인데 히트의 3~7%는 틀린 답일 수 있어 평가 게이트가 필요하다(⑥편). 셋째, 이 볼륨에서 70B 자체 서빙은 캐시 붙인 API보다 비싸다 — 자체 서빙의 캐시 효과는 할인 항목이 아니라 "GPU 수"로 나타난다(②·③편). 원화로는 A ≈ 4,200만 원, B ≈ 2,080만 원, C ≈ 1,500만 원/월이다.

이 시리즈의 지도

② KV 캐시와 메모리 경제학 → ③ 프리픽스 캐싱과 캐시 인지 라우팅 → ④ API 프롬프트 캐싱의 가격·TTL·손익분기 → ⑤ 에이전트·멀티턴·RAG의 앱 계층 캐시 → ⑥ 시맨틱 캐시의 현실 히트율 → ⑦ KV 압축·오프로딩·클러스터 공유 → ⑧ 도입 전에 로그로 히트율 상한 재기 → ⑨ 워밍·콜드 캐시·오토스케일링 운영 → ⑩ 캐시 vs 파인튜닝 vs 프롬프트 압축 → ⑪ 한국어 맥락과 CTO 플레이북. 모든 편에 실제 숫자와 실패담을 넣었다. 다음 글은 자체 서빙의 출발점, KV 캐시가 왜 GPU 비용의 변수인지부터다.

— LLM 서빙 캐싱 시리즈 ① / 다음 글: KV 캐시와 메모리 경제학 — GPU 한 장에 몇 명을 태우나