Prompt caching은 LLM 요청에서 반복되는 긴 prompt prefix를 재사용해 비용과 지연시간을 줄이는 기능입니다. 같은 system prompt, 긴 지침, tool schema, 예시가 매번 앞부분에 반복된다면 효과를 기대할 수 있습니다.
하지만 prompt caching은 마법 같은 할인 기능이 아닙니다. 핵심 조건은 같은 내용이 prompt 앞부분에 정확히 반복되어야 한다는 것입니다. 매 요청마다 앞부분이 조금씩 바뀌면 cache hit가 나기 어렵습니다.
Prompt caching이 효과적인 구조
효과가 큰 구조는 정적 내용이 앞에 있고, 사용자별로 바뀌는 내용이 뒤에 있는 구조입니다. 예를 들어 agent 시스템 지침, 도구 설명, 출력 형식, 긴 예시는 앞에 두고, 현재 사용자 질문이나 검색 결과는 뒤에 둡니다.
캐시되기 쉬운 앞부분
- system instructions
- tool schemas
- output format rules
- stable examples
매번 바뀌는 뒷부분
- user question
- retrieved documents
- current task state효과가 작은 경우
- prompt가 짧아 캐시 대상이 되기 어렵다
- 앞부분에 시간, 사용자 이름, 요청별 metadata가 섞인다
- tool schema가 매 요청마다 다른 순서로 들어간다
- 검색 결과를 prompt 앞쪽에 넣어 prefix가 매번 바뀐다
- 요청량이 낮아 같은 prefix가 반복될 기회가 적다
Agent에서 특히 중요한 이유
에이전트는 일반 챗봇보다 반복되는 prompt 구성요소가 많습니다. tool description, guardrail, output schema, workflow 지침이 매번 들어가기 때문입니다. 이 부분을 안정적인 prefix로 유지하면 비용 관리에 도움이 됩니다.
반대로 tool 목록을 요청마다 동적으로 재정렬하거나, 현재 task state를 system prompt 앞에 끼워 넣으면 캐시 효과가 떨어질 수 있습니다.
cache hit을 높이는 배치 기준
- 항상 같은 system prompt를 먼저 둔다
- tool schema 순서를 안정적으로 유지한다
- 예시와 정책 문구를 앞쪽에 고정한다
- 사용자별 동적 정보는 뒤쪽으로 보낸다
- 응답 usage에서 cached token 지표를 확인한다
- 비용뿐 아니라 latency도 함께 비교한다
비용 계산에서 조심할 점
Prompt caching은 입력 토큰 일부가 캐시된 입력으로 처리될 때 비용을 줄일 수 있습니다. 다만 모델군, API, 시점에 따라 캐시 쓰기와 읽기 과금 방식이 달라질 수 있으므로 최신 공식 문서를 기준으로 확인해야 합니다.
그래서 글이나 설계 문서에서는 ‘항상 몇 퍼센트 절감된다’고 쓰면 위험합니다. 실제 서비스에서는 usage 로그에서 cached_tokens와 전체 input token을 함께 봐야 합니다.
간단한 점검 예시
# 의사 코드: 실제 응답 필드는 사용하는 API와 SDK 버전에 맞춰 확인한다.
usage = response.usage
input_tokens = usage.input_tokens
cached_tokens = usage.input_tokens_details.cached_tokens
cache_ratio = cached_tokens / input_tokens if input_tokens else 0
print(cache_ratio)정리
Prompt caching은 반복되는 긴 prefix가 있을 때 비용과 지연시간을 줄이는 운영 기술입니다. 정적 지침은 앞에, 동적 context는 뒤에 두는 구성이 기본입니다.
최신 과금과 동작 조건은 OpenAI Prompt caching 문서를 기준으로 확인해야 합니다. 비용 구조 자체는 ChatGPT API 비용 계산 글과 함께 보면 이해가 쉽습니다.
