LLM 프롬프트 캐싱 완벽 가이드 2026: 입력 비용 50-90% 절감

대규모 언어 모델로 챗봇, RAG 앱, AI agent를 운영한다면 프롬프트 캐싱은 품질 저하 없이 입력 비용을 50–90% 줄이고 첫 token 생성 시간(time-to-first-token)을 3–10배 단축하는 가장 효과적인 최적화 방법이다. 별도로 덧붙이는 기법이 아니라 Transformer attention의 정의에서 직접 도출되는 특성이다. 이 원리를 이해하면 TTL, 제공업체별 차이, 프롬프트 구조까지 나머지 요소도 명확해진다.

TL;DR

• 프롬프트 캐싱은 품질 저하 없이 입력 비용을 50-90% 줄이고 첫 token 생성 시간을 3-10배 단축한다.
• 2026-05-25 측정 결과, Claude의 cache_control marker는 입력 비용을 88-89% 줄였다. GPT-5.4-mini auto-cache는 TTFT를 3.6s에서 0.73s로 단축했고, DeepSeek-v4-flash의 disk-backed cache는 74% 할인을 제공했다.
• TTL이 짧은 이유는 KV state가 매우 크기 때문이다. 70B급 모델에서 32K-token context를 처리할 때 약 10 GB를 차지한다.
• DeepSeek의 캐시 단위는 일반적인 최소 단위인 1,024 token이 아니라 64 token이다. 따라서 prefix 일부만 일치해도 할인을 받을 수 있다.

이 페이지는 이론부터 프로덕션 의사결정 matrix, 실제 프롬프트가 조립되는 framework 계층까지 다루는 5부작의 목차다. 이미 알고 있는 내용에 따라 필요한 부분부터 읽으면 된다.

어디서 시작할까

각 글은 독립적으로 읽을 수 있다. 순서대로 읽으면 내용이 중복되지 않으면서 전체 구조를 파악할 수 있도록 구성했다.

1부 — LLM 프롬프트 캐싱의 동작 원리

LLM 프롬프트 캐싱의 동작 원리: KV Cache와 TTL 설명 →

아키텍처를 다루는 글이다. 하나의 식으로 self-attention을 살펴보고, 고정된 prefix의 K 및 V vector를 수학적으로 재사용할 수 있는 이유를 설명한다. memory와 compute의 tradeoff가 모든 개발자가 설계 시 고려해야 하는 TTL 동작으로 어떻게 이어지는지도 보여준다.

핵심 내용:

• 프롬프트 캐싱은 위에 덧붙이는 최적화가 아니라 causal-masked attention의 직접적인 결과다. 위치 i의 K/V는 token 1…i의 deterministic function이므로 prefix가 같으면 K/V도 bit 단위까지 같다.
• 캐싱으로 절약하는 부분은 prefill(compute-bound, O(N²))이다. decode(memory-bandwidth-bound, token당 O(N))는 이미 모든 inference engine에서 최적화하고 있다.
• KV cache는 매우 크기 때문에 TTL이 필요하다(70B 모델에서 32K context를 처리할 때 약 10 GB). 5분은 GPU memory pressure를 감당할 수 있는 시간대다. 수 시간에서 수 일까지 유지하려면 disk-backed cache가 필요하며, DeepSeek의 MLA architecture가 이에 해당한다.
• 캐싱은 비용(cache hit 시 입력 비용 50–90% 절감)과 latency(5–10K-token 프롬프트의 TTFT를 3–10배 단축, 100K+에서는 그 이상)를 모두 개선한다.

2부 — 제공업체별 LLM 프롬프트 캐싱 비교

프롬프트 캐싱 비교: Claude, GPT-5, Gemini, DeepSeek, Qwen (2026) →

구매 결정을 위한 가이드다. 5개 제공업체는 프롬프트 캐싱을 서로 다른 방식으로 제공한다. Claude는 명시적 marker, GPT-5와 DeepSeek-v4는 완전 자동, Gemini와 Qwen은 implicit+explicit hybrid 방식이며, DeepSeek의 MLA는 architecture 수준에서 disk backing을 지원한다. 기능별 비교와 함께 workload에 맞춰 평가할 수 있는 5개 항목의 평가 framework를 제공한다.

핵심 내용:

• 기본 가격끼리 비교하지 말고 hit rate를 반영한 실효 비용을 비교해야 한다(계산식은 §4.1 참조). 실시간 LLM 가격 비교와 비용 계산기를 사용하면 workload별 비용을 구체적으로 확인할 수 있다.
• Claude는 단일 호출 기준 할인율이 가장 높지만(약 90%), cache_control marker를 명시적으로 지정해야 한다.
• DeepSeek-v4는 대규모 disk-backed cache를 제공하는 유일한 제공업체다. 캐시 단위가 1,024 token이 아니라 64 token이므로 prefix가 일부만 일치해도 할인을 받을 수 있다.
• Gemini의 explicit cache에는 시간당 storage fee가 부과된다. 손익분기점은 호출 빈도에 따라 달라진다.
• hit rate를 동일하게 놓고 보면 제공업체를 실질적으로 구분하는 5가지 항목은 API 사용성, hit rate 예측 가능성, TTL 적합성, cache miss 시 latency, migration 비용이다.

3부 — 실행 가능한 Python 튜토리얼

Python에서 LLM 프롬프트 캐싱 구현하기: 실행 가능한 코드 튜토리얼 →

직접 구현하는 방법을 다루는 글이다. 하나의 gateway에 OpenAI SDK와 Anthropic SDK를 연결해 사용한다. 2026-05-25에 Claude 전체 제품군(haiku-4-5부터 opus-4-7까지), GPT-5.x, Gemini 2.5, DeepSeek-v4, Qwen3를 대상으로 측정한 결과도 제공한다.

핵심 내용:

• cache_control marker를 사용하는 Claude: haiku/sonnet/opus 4-x 전체에서 일관되게 88–89%의 비용 절감을 측정했다. Anthropic SDK에 base_url="https://synthorai.io/"을 설정해 사용한다.
• GPT-5.4-mini auto-cache: 7K-token 프롬프트에서 TTFT가 3.6 s에서 0.73 s로 줄어 5배 개선됐다. system token의 cache hit rate는 93%였다.
• Gemini 2.5-flash implicit: streaming usage를 수집했을 때 cache hit 시 비용이 88% 절감됐다.
• DeepSeek-v4-flash: 74% 할인되며 disk-backed 방식이라 수 시간 동안 사용하지 않아도 캐시가 유지된다.
• TTL을 고려한 패턴: cron을 위한 keep-alive heartbeat, prefix 안정성 규칙, 호출별 logging 항목.

4부 — Use Case별 최적 모델

Chat, RAG, Agent에 가장 적합한 LLM: 2026 모델 및 비용 의사결정 Matrix →

의사결정을 위한 글이다. workload마다 비용과 latency에 영향을 주는 요소가 다르다. Chat은 기본적으로 캐싱에 유리하고, RAG는 prefix 안정성을 확보하기 어렵다. Agent에서는 누적 prefix를 일관되게 관리해야 한다. 이 글에서는 workload 형태별 권장 모델과 예상 비용을 제공한다.

핵심 내용:

• 챗봇: auto-cache를 지원하는 모델이라면 무엇이든 사용할 수 있다. session 특성상 자연스럽게 cache hit가 발생한다. 비용과 품질을 기준으로 선택하면 된다. gpt-5.4-nano가 가장 저렴하고, gpt-5.4-mini의 캐싱된 TTFT가 가장 빠르다. claude-haiku-4-5는 비용이 조금 더 들지만 instruction-following 성능이 가장 좋다.
• RAG: 검색한 document의 순서가 바뀌면 프롬프트 중간의 cache hit가 사라진다. 해결책은 세 가지다. reference를 뒤로 보내거나, chunk 순서를 deterministic하게 유지하거나, Claude의 여러 cache_control breakpoint를 사용한다.
• Agent: tool call과 결과는 append-only여야 하며 각 step에서 byte 단위까지 같아야 한다. claude-sonnet-4-5에 cache_control marker 4개를 사용하면 누적 prefix에 가장 큰 할인을 받을 수 있다. gpt-5.4-mini는 코드 변경 없이 50%를 절감한다.
• TTL 선택: Chat은 5분, human-in-the-loop step이 있는 agent는 1시간, 간헐적인 batch 작업은 disk-backed cache가 적합하다.

5부 — LangChain 통합

LangChain 프롬프트 캐싱: 실제로 캐시 Hit가 발생하는 구성 →

Framework 계층을 다루는 글이다. 1–4부에서는 프롬프트 byte를 직접 제어한다고 가정했다. LangChain은 프롬프트를 대신 조립하며, 가장 편리한 문법을 사용하면 아무 경고 없이 Claude 캐시가 비활성화된다. marker를 추가한 system prefix로 langchain-core 1.4.8에서 측정했다.

핵심 내용:

• ("system", "...") string-tuple template에는 cache_control을 넣을 수 없다. 동일한 호출에서도 캐시 활동이 전혀 발생하지 않았다. content block을 포함한 SystemMessage를 사용하면 해결된다.
• 프롬프트 순서가 hit rate를 좌우한다. 고정 규칙 앞에 검색한 RAG context를 배치하면 모든 호출에서 cold write가 발생했다. Claude는 write premium을 부과하므로 이 방식은 캐싱을 전혀 사용하지 않는 것보다 비용이 더 든다.
• system block에 marker를 지정하면 bound tool도 함께 포함된다. bind_tools는 byte가 변하지 않도록 serialize하며, Anthropic 형식의 tool dict에 넣은 marker는 그대로 전달된다.
• Multi-turn agent에서는 marker를 가장 최근 message로 옮긴다. 그러면 매 turn마다 이전 prefix 전체를 다시 읽고 변경분만 write한다(측정값: read 1,864, write 15).
• 자동 캐시 모델(GPT, GLM, DeepSeek)에서는 순서가 잘못돼도 조용히 실패한다. premium도 error도 없고, 받아야 할 할인만 적용되지 않는다. usage field를 모니터링해야 한다.

읽는 순서

• 처음 접하는 엔지니어: 순서대로 읽는다. 1부의 아키텍처를 이해하면 2–4부의 내용이 바로 연결된다.
• 제공업체를 선정하는 PM 또는 architect: 2부와 4부부터 읽는다. 팀원이 “TTL은 왜 필요한가”라고 물으면 1부를 참고한다.
• 오늘 특정 workload를 출시해야 하는 엔지니어: 4부의 matrix에서 해당 항목을 먼저 찾고, 3부에서 정확한 코드를 확인한다.
• 이미 LangChain을 사용 중인 경우: 바로 5부를 읽는다. 3부의 raw SDK 패턴도 적용할 수 있지만 string template, variable 위치, usage field 이름 같은 문제는 framework에 따라 다르다.
• 기존 앱을 최적화하려는 경우: 3부 §6의 제공업체 간 benchmark를 자체 프롬프트로 재현한다. 여러 주가 걸리는 migration이 아니라 하루면 할 수 있는 작업이다.

이 시리즈의 측정값

1–4부의 수치는 2026-05-25, 5부의 LangChain 수치는 2026-07-04에 측정했다. Synthorai gateway(OpenAI 호환은 https://synthorai.io/v1, Anthropic native는 https://synthorai.io/)에서 single-tenant로 동시 부하 없이 한 번씩 순차 실행했다. region, 시간대, 다른 tenant의 부하에 따라 결과는 달라질 수 있다. 이 수치는 출발점으로만 사용하고 외부에 인용하기 전 자체 traffic으로 재현해야 한다.

가격표와 TTL 동작은 2026-05 기준 각 제공업체의 공개 문서를 반영했다. 제공업체는 몇 달마다 이를 변경한다. 아키텍처 원리(1부)는 그대로지만 비교 수치(2부와 3부)는 달라질 수 있다.

← 블로그로 돌아가기