🤖 LLM 검증완료

Prefix Caching Analysis

Prefix Caching / Prompt Caching 심층 분석

공통 프리픽스 KV 재사용 · 블록·해시 매칭 · RadixAttention vs APC · 프로바이더 Prompt Caching · 멀티턴·RAG

프리픽스 캐싱(prefix caching, prompt caching)은 여러 요청이 공유하는 앞부분(프리픽스)의 KV 캐시를 한 번만 계산해 재사용함으로써, 같은 prefill 연산이 반복되는 것을 막는 기법입니다. KV 캐시가 프리픽스에만 의존한다는 성질을 이용해 공통부의 prefill을 통째로 건너뛰므로, 출력을 바꾸지 않으면서(무손실) TTFT와 비용을 크게 줄입니다. 멀티턴 대화·RAG·few-shot·에이전트처럼 공통 프리픽스가 큰 워크로드를 떠받치는 실무 표준이며, 거의 모든 추론 엔진(vLLM·SGLang)과 프로바이더(OpenAI·Anthropic 등)가 채택하고 있습니다.

실무 관점에서 중요한 점은 이 기법이 "좋은 프롬프트 작성법"과 직접 연결된다는 것입니다. 재사용 가능한 시스템 프롬프트, 툴 정의, few-shot 예시, 장문 문서를 프롬프트 앞쪽에 고정하고, 사용자별 가변 입력은 뒤로 밀수록 히트율이 올라갑니다. 반대로 중간에 대화 이력을 잘라내거나, 툴 스키마나 이미지 입력이 바뀌거나, 프리픽스 앞부분이 조금이라도 달라지면 캐시가 깨지므로 라우팅 정책과 프롬프트 레이아웃까지 함께 설계해야 합니다. 본 문서는 핵심 아이디어 → 매칭 메커니즘(블록·해시) → 두 구현(RadixAttention·APC) → 사용 사례·프로바이더 API → 축출·메모리 계층·한계의 순서로 분석합니다.

1. 핵심 아이디어 — 공통 프리픽스의 KV를 재사용

여러 요청이 같은 앞부분으로 시작하는 경우는 흔합니다. 시스템 프롬프트, few-shot 예시, RAG로 붙인 문서, 멀티턴 대화의 이력이 그렇습니다. 순진하게는 매 요청마다 이 공통부를 처음부터 prefill하지만, 그것은 같은 계산의 반복입니다.

그림 1. 공통 프리픽스를 한 번만 계산해 캐시하고 재사용하는 구조

왜 재사용이 가능하고, 왜 '거의 공짜'인가

KV 캐시는 그 토큰까지의 앞부분(프리픽스)에만 의존합니다. 따라서 같은 프리픽스면 KV가 정확히 동일하고, 한 번 계산해 저장하면 같은 프리픽스로 시작하는 다른 요청이 그대로 재사용할 수 있습니다.
prefill을 공략 — 공통부의 prefill(계산집약 단계)을 통째로 건너뛰므로 TTFT가 크게 줄고 GPU 연산이 절약됩니다.
무손실 — 캐시된 KV는 재계산한 것과 수학적으로 동일하므로 출력이 바뀌지 않습니다. 그래서 '거의 공짜 점심(almost free lunch)'으로 불립니다.
특히 멀티턴 — 매 턴마다 전체 대화를 다시 prefill하지 않고 이전 턴들의 KV를 재사용합니다. 다만 프리픽스가 정확히 일치해야 하며, 한 토큰만 달라도 그 지점부터 캐시 미스가 됩니다.

이 기법은 KV 절감 기법(양자화·MLA·GQA)과는 다른 축입니다. 양자화·MLA가 'KV를 작게' 만든다면, 프리픽스 캐싱은 'KV를 다시 만들지 않게' 합니다. 그래서 둘은 직교적으로 함께 쓸 수 있습니다.

2. 매칭 메커니즘 — 블록 단위 + 해시

프리픽스 캐싱은 PagedAttention의 블록 추상화 위에서 자연스럽게 동작합니다. KV를 고정 토큰 수의 블록으로 쪼개고, 각 블록을 '그 블록까지의 프리픽스'를 반영한 해시로 식별합니다.

그림 2. 블록별 해시 체인과 접두 일치(prefix match) 기반 재사용

블록 해시와 매칭 (vLLM APC 개념)

매칭의 핵심

해시가 내용과 위치(앞 블록들)를 모두 반영하므로, 같은 해시면 같은 KV 블록임이 보장됩니다. 논리 블록을 해시 테이블을 거쳐 물리 블록에 매핑하고, 같은 해시는 같은 물리 블록을 가리켜 공유합니다.
접두 일치(prefix match) — 앞에서부터 해시가 같은 블록까지만 재사용하고, 처음 달라지는 블록부터 재계산합니다. 프리픽스 전체가 같지 않아도 일치하는 앞부분까지는 재사용됩니다(부분 매칭).
정확 일치 필수 — 토큰 시퀀스가 같아야 하고 위치도 같아야 합니다(어텐션·RoPE가 위치에 의존). 블록 크기(예: 16토큰) 단위로 매칭되므로, 블록 중간에서 갈리면 그 블록은 재계산됩니다.

3. 두 가지 구현 방식

프리픽스 캐싱을 구현하는 대표적 방식은 두 가지입니다. SGLang의 RadixAttention은 토큰 단위 radix tree를, vLLM의 Automatic Prefix Caching(APC)은 블록 단위 해시 테이블을 씁니다.

그림 3. RadixAttention(토큰 단위 트리)과 hash 블록 캐싱(vLLM APC)

항목	RadixAttention (SGLang)	APC (vLLM)
기본 단위	토큰 시퀀스 경로	고정 크기 KV 블록
핵심 자료구조	radix tree	해시 테이블 + 물리 블록 매핑
장점	세밀한 prefix 검색, 분기 워크로드에 유리	단순하고 PagedAttention과 결합이 쉬움
주의점	트리 유지·축출 정책이 복잡해질 수 있음	블록 경계에서 갈리면 해당 블록 전체를 재계산
잘 맞는 상황	멀티턴, 에이전트, 구조화된 분기 추론	일반 서빙, 대규모 배치, 블록 관리 자동화

RadixAttention (SGLang)

KV 캐시를 토큰 시퀀스의 radix tree에 보관해, 빠른 프리픽스 검색·삽입·축출을 지원합니다. 생성이 끝나도 KV를 버리지 않고 트리에 유지합니다.
공유 프리픽스는 트리의 공유 경로가 되고, 갈라지는 지점에서 새 가지가 생깁니다. fork 프리미티브로 분기되는 동적 트리(에이전트·다단계 추론)에 특히 적합하며, 멀티턴 시나리오에서 vLLM 대비 10~20% 향상이 보고됩니다.

Hash 블록 캐싱 (vLLM APC)

각 블록을 해시로 식별해 해시 테이블로 공유하며, OS 페이지 캐시처럼 관리합니다. 참조 카운트가 0인 블록만 LRU로 축출하면 RadixAttention과 사실상 같은 효과를 냅니다.
둘의 차이는 입자도입니다 — radix tree는 토큰 단위(유연), hash는 블록 단위(단순·구현 용이)입니다.

공통점 — 두 방식 모두 LRU 축출과 cache-aware 스케줄링(같은 프리픽스를 가진 요청을 함께 배치)으로 hit율과 메모리 효율을 높인다. 또 PagedAttention·연속 배칭·텐서 병렬과 호환되며, 캐시 미스가 나도 추가 오버헤드가 거의 없어 항상 켜둘 수 있다.

4. 사용 사례와 프로바이더 Prompt Caching

그림 4. 사용 사례, 프롬프트 구조, 프로바이더별 효과

어디서 쓰이나

공통 프리픽스가 큰 워크로드에서 효과적입니다. 멀티턴 대화(이전 턴 KV 재사용), RAG(검색 문서 프리픽스), few-shot·시스템 프롬프트(공통 지시·예시), 에이전트(공통 툴 정의·컨텍스트)가 대표적입니다.

프로바이더 Prompt Caching API

OpenAI·Anthropic 등은 이 기법을 API로 제품화했습니다. 핵심 패턴은 변하지 않는 정적 콘텐츠(시스템 프롬프트·툴 정의·문서)를 프롬프트 맨 앞에 두고 가변 부분(사용자 질문)을 뒤에 두는 것입니다. 그러면 앞쪽 정적 프리픽스가 매번 캐시 히트합니다. Anthropic은 cache_control로 자동/명시적 캐싱을 제어하고 기본 5분 TTL과 1시간 TTL 옵션을 제공하며, OpenAI는 1024토큰 이상에서 자동 캐싱되고 prompt_cache_key와 retention 정책으로 라우팅과 보존 시간을 보완할 수 있습니다.

프로바이더	동작 방식	최소 조건/보존	실무 포인트
OpenAI	exact prefix match 기반 자동 캐싱	1024토큰 이상, 기본 in-memory 5~10분, 일부 모델은 최대 24시간 retention	정적 콘텐츠를 앞에 두고 `prompt_cache_key`로 동일 prefix 요청을 같은 캐시 군집으로 유도
Anthropic	`cache_control` 기반 자동 또는 명시적 breakpoint 캐싱	모델별 최소 토큰 수, 기본 5분 TTL, 선택적 1시간 TTL	고정 prefix 끝 지점에 breakpoint를 두고, 대화가 길어질 때는 lookback window와 block 수를 고려

주의할 점은 정확 일치입니다 — 프리픽스가 한 토큰이라도 다르면 그 지점부터 미스이며, 이미지·툴 스키마도 동일해야 합니다. 또 같은 프리픽스 요청을 캐시 보유 서버로 보내는 sticky 라우팅이 맞아야 캐시가 쓸모 있고, 멀티턴에서 대화 이력을 자르거나(truncation) 중간을 수정하면 프리픽스가 깨져 hit율이 급락합니다.

5. 장단점

장점	단점
공통 프리픽스의 prefill을 줄여 TTFT와 비용을 낮춘다	프리픽스가 정확히 같아야 해서 작은 차이에도 히트가 깨진다
멀티턴·RAG·few-shot·에이전트에서 효과가 크다	공통 프리픽스가 짧으면 체감 이득이 작다
양자화·MLA·오프로딩과 직교적으로 결합할 수 있다	캐시 유지, 축출, sticky 라우팅 관리가 필요하다

6. 축출·메모리 계층과 한계

그림 5. 캐시 축출, 메모리 계층 확장, 다층 캐시, 그리고 한계

축출과 메모리 계층

축출 — GPU 캐시는 작으므로 LRU와 참조 카운트로 관리합니다. 쓰지 않는 블록(ref=0)은 보존할 이유가 없고, 오래된 블록부터 축출합니다. hot 프리픽스를 오래 유지하는 것이 hit율의 관건입니다.
메모리 계층 확장 — GPU에 다 담지 못하는 프리픽스 캐시는 CPU DRAM·CXL·NVMe로 내려 더 많이 보관할 수 있습니다. 이것이 앞서 본 KV 캐시 오프로딩과 결합되는 지점입니다(HotPrefix·LMCache 등이 GPU/CPU 간 프리픽스 승격·강등을 관리).
다층 캐시 — 실무에서는 시맨틱 캐시(응답 자체 재사용) → 프리픽스 캐시(KV 재사용) → 전체 추론의 계층을 둡니다. 위 단계에서 막을수록 절감이 큽니다(응답 캐시는 100%, 프리픽스 캐시는 부분, 미스면 0%).

한계

정확 일치 의존 — 한 토큰 차이·위치 변화에 취약해 일치하는 앞부분까지만 재사용됩니다.
공통 프리픽스 전제 — 고유한 프롬프트만 있으면 재사용할 게 없어 효과가 작습니다.
hit율 변동 — truncation·중간 수정이 hit율을 크게 떨어뜨릴 수 있습니다.
용량·라우팅 — GPU 캐시 용량 한계 때문에 축출·티어링·cache-aware 라우팅이 필요합니다.

7. 관련 기술

자료	핵심
SGLang: Efficient Execution of Structured Language Model Programs	RadixAttention과 structured generation 런타임
Anthropic Prompt Caching	`cache_control`, automatic caching, 5분 기본 TTL과 1시간 TTL
OpenAI Prompt Caching	1024토큰 이상 자동 캐싱, exact prefix match, `prompt_cache_key`
PagedAttention Analysis	블록 단위 KV 관리의 기반
KV Cache Quantization Analysis	KV를 작게 만들어 더 많이 담는 직교 기법
KV Cache Offloading Analysis	GPU 밖 티어로 KV를 내리는 오프로딩
Continuous Batching Analysis	cache-aware scheduling과 함께 쓰는 배치 축

8. 핵심 정리

프리픽스 캐싱은 공통 프리픽스의 KV를 한 번 계산해 재사용함으로써 중복 prefill을 제거하는 무손실 기법이다. KV가 프리픽스에만 의존하는 성질을 이용하며, PagedAttention 블록 위에서 블록 해시로 매칭한다. 구현은 RadixAttention(토큰 단위 radix tree)과 vLLM APC(블록 단위 해시)로 나뉘고 둘 다 LRU+cache-aware 스케줄링을 쓴다. 프로바이더 API(OpenAI 자동·Anthropic cache_control)는 정적 콘텐츠를 앞에 두면 캐시 히트로 비용을 크게 줄인다. KV 절감(양자화·MLA)과는 직교적이고, GPU에 못 담는 프리픽스 캐시는 CPU·CXL·NVMe로 내려 더 많이 재사용할 수 있다. 한계는 정확 일치 의존과 공통 프리픽스 전제이며, hit율 유지와 cache-aware 라우팅이 핵심이다.

메모리 시스템 관점(연구 확장) — 프리픽스 캐시는 '어떤 프리픽스 KV를 어느 티어(GPU/CPU/CXL/NVMe)에 얼마나 오래 둘지'라는 캐시·티어링 문제로, KV 오프로딩·신뢰성 설계와 동일한 축에 있다. hot 프리픽스를 상위 티어에 두고 콜드 프리픽스를 CXL로 내리는 정책, 그리고 티어별 비트 오류 특성에 맞춘 정밀도·ECC 결정이 자연스러운 확장이다.

주의 — 본문은 엔진·프로바이더 문서와 연구 자료(RadixAttention/SGLang arXiv 2312.07104, Anthropic prompt caching 문서, OpenAI prompt caching 문서, HotPrefix·LMCache 등)에 기반한다. 비용·지연·최소 토큰·TTL 같은 수치는 특정 프로바이더·모델·조건의 보고값으로, 프롬프트 구성·hit율·라우팅에 따라 달라진다. 프로바이더별 정책(최소 토큰·TTL·가격)은 수시로 바뀔 수 있으니 실제 적용 시 공식 문서를 확인해야 한다.

Ryotta's Basic