요약: OpenAI Prompt Caching은 긴 시스템 프롬프트, 도구 정의, 예시, 반복 컨텍스트를 매번 새로 처리하지 않도록 해 비용과 지연 시간을 낮춘다. 효과를 보려면 '정적 내용은 앞에, 변하는 내용은 뒤에'라는 단순한 규칙을 코드 구조에 반영해야 한다.
LLM API 비용은 출력 토큰만이 아니라 입력 토큰에서도 크게 발생한다. 특히 에이전트형 앱은 시스템 프롬프트, 정책 문서, 도구 스키마, few-shot 예시, 이전 요약을 매 요청마다 보낸다. 사용자 질문은 짧은데 앞에 붙는 공통 컨텍스트가 수천 토큰이면, 실제 비용 대부분은 반복 입력에서 나온다.
OpenAI 문서에 따르면 Prompt Caching은 반복되는 prompt prefix를 자동으로 캐시해 입력 비용과 latency를 줄인다. 공식 문서는 Prompt Caching이 최대 80% latency 감소, 최대 90% input token 비용 감소를 만들 수 있다고 설명한다. 최근 모델에서는 자동으로 동작하며, 1,024토큰 이상 프롬프트에서 캐시 가능성이 생긴다.
하지만 자동 기능이라고 해서 아무렇게나 써도 되는 것은 아니다. 캐시는 정확한 prefix match가 중요하다. 같은 문서를 보내도 앞부분에 사용자별 시간, 요청 ID, 임의 순서의 JSON이 섞이면 캐시가 깨진다. 개발자가 프롬프트 구조를 설계해야 실제 절감이 나온다.
OpenAI 설명에 따르면 요청은 초기 prefix hash를 기반으로 라우팅되고, 같은 prefix가 최근 처리된 서버에 있으면 캐시가 hit된다. prompt_cache_key를 제공하면 공통 prefix를 공유하는 요청의 라우팅 안정성을 높일 수 있다. 단, 같은 prefix와 key 조합 요청이 너무 높게 몰리면 일부가 다른 서버로 overflow되어 hit rate가 떨어질 수 있다. 문서에서는 약 15 requests per minute 수준을 언급한다.
캐시 대상은 메시지 배열, 이미지, 도구 정의, structured output schema 등을 포함할 수 있다. 핵심은 prefix다. 모델에게 항상 들어가는 정책, 역할, 예시, 도구 목록, 출력 스키마는 앞에 둔다. 매번 바뀌는 사용자 입력, 현재 시간, 계정 상태, 검색 결과, 요청별 데이터는 뒤에 둔다.
이 규칙은 단순하지만 코드베이스에서는 자주 깨진다. 미들웨어가 request id를 system prompt 앞에 붙이거나, tools 배열 순서가 매번 달라지거나, JSON serializer가 키 순서를 보장하지 않으면 캐시 효율이 떨어진다.
가장 먼저 프롬프트 빌더를 두 영역으로 나누자. staticPrefix에는 제품 정책, 역할 설명, 출력 포맷, 예시, 도구 정의를 둔다. dynamicContext에는 사용자 입력, 현재 세션 정보, 검색 결과, DB 조회 결과를 둔다. 두 영역이 코드상으로 분리되어야 리뷰와 테스트가 가능하다.
예시 구조는 다음과 같다.
[static prefix]
- assistant 역할
- 금지 액션과 승인 규칙
- 응답 형식
- 도구 사용 정책
- few-shot examples
- structured output schema
[dynamic suffix]
- user id에서 비식별화한 상태
- 이번 요청의 입력
- 최근 검색 결과
- 현재 작업 로그
중요한 것은 정적 prefix가 정말 정적이어야 한다는 점이다. 날짜, locale, plan, feature flag처럼 바뀌는 값은 뒤로 빼야 한다. 도구 스키마도 매 요청마다 생성하지 말고 안정된 순서로 직렬화한다. 배열 정렬, JSON key 정렬, 불필요한 공백 제거를 적용하면 캐시 hit rate가 올라간다.
Prompt Caching은 입력이 길고 반복될수록 효과가 크다. 예를 들어 사내 코드 리뷰 에이전트가 6,000토큰의 공통 정책과 예시, 1,000토큰의 PR별 diff 요약을 보낸다고 하자. 캐시가 없다면 매 요청 7,000토큰을 입력으로 처리한다. 캐시 hit가 높으면 6,000토큰 대부분이 cached input 단가로 처리되고, 새로 처리하는 것은 1,000토큰에 가까워진다.
OpenAI 가격표 기준으로 GPT-5.5는 input $5.00/1M tokens, cached input $0.50/1M tokens이다. 같은 6,000토큰 prefix가 캐시 hit되면 해당 부분 입력 단가가 10분의 1로 내려간다. GPT-5.4도 input $2.50, cached input $0.25로 같은 비율이다. 물론 실제 비용은 모델, 처리 모드, 출력 토큰, tool call에 따라 달라진다.
효과가 작은 경우도 있다. 프롬프트가 1,024토큰보다 짧거나, 매 요청 앞부분이 크게 달라지거나, 요청 빈도가 낮아 캐시가 자주 식으면 절감이 제한된다. 즉 Prompt Caching은 모든 API 호출의 마법 버튼이 아니라, 반복 prefix가 긴 워크로드에 특히 유리한 최적화다.
최적화는 로그 없이는 감으로 흐른다. OpenAI 응답 usage에는 cached token 정보를 확인할 수 있는 필드가 제공된다. 요청별 prompt_tokens, cached_tokens, total latency, model, prompt_cache_key, static prefix hash를 함께 기록하자. 그러면 어떤 기능에서 hit rate가 낮은지 바로 찾을 수 있다.
대시보드에는 최소한 다음 지표가 필요하다. 캐시 hit token 비율, 요청당 입력 비용, p50/p95 latency, prefix hash별 요청 수, overflow가 의심되는 high-QPS key, 모델별 cached input 비중이다. 변경 배포 후 이 지표가 갑자기 떨어지면 프롬프트 빌더가 캐시를 깨뜨렸을 가능성이 높다.
테스트도 넣을 수 있다. 같은 입력을 두 번 만들었을 때 static prefix 문자열이 완전히 같은지 snapshot test로 검증한다. tools 배열 순서와 JSON schema 직렬화 결과도 테스트한다. 프롬프트 최적화는 모델 프롬프트만의 일이 아니라 일반적인 소프트웨어 회귀 테스트 대상이다.
OpenAI 문서는 prompt cache가 조직 간 공유되지 않으며, Extended Prompt Caching에서는 key/value tensor가 최대 24시간까지 유지될 수 있다고 설명한다. 원문 텍스트 자체가 디스크에 저장되는 방식은 아니지만, Zero Data Retention과 데이터 레지던시 요구가 있는 조직은 retention policy와 regional inference 조건을 확인해야 한다.
개발팀은 민감정보를 static prefix에 넣지 않는 편이 안전하다. 고객별 정보, 내부 사고 로그, 개인 식별자는 동적 suffix로 넣고 최소화한다. 캐시가 비용을 줄인다고 해서 모든 문서를 앞에 고정해 붙이면 안 된다. 캐시에 유리한 구조와 데이터 최소화 원칙을 함께 지켜야 한다.
prompt_cache_key는 같은 prefix 그룹에 일관되게 사용하되 과도하게 한 key에 몰지 않는다.출처: OpenAI API Docs, Prompt caching; OpenAI API Pricing.