캐시 히트 진단은 요청이 더 저렴했다는 것을 증명하나요?

아니요. 선택한 baseline과 비교해 캐시 미스가 감지되지 않았다는 뜻입니다. 절감을 주장하기 전에 실제 cached tokens와 요금이 매겨지는 토큰 범주를 확인하세요.

OpenAI 청구서 뒤의 캐시 미스 찾기

Q: 모든 캐시 미스를 없애야 하나요?

아니요. 모델 전환, 서비스 티어 변경, 컨텍스트 압축은 의도된 변경일 수 있습니다. 되돌리기 전에 품질, 지연 시간, 성공한 작업당 비용을 비교하세요.

업데이트 September 26, 2026 · 최초 게시 September 26, 2026

핵심 답변: 프롬프트 캐시 대시보드는 재사용이 줄었다는 사실을 알려 줄 수 있지만, 어떤 요청 변경이 원인인지, 그리고 그 비용이 얼마인지는 스스로 말해 주지 못합니다. OpenAI의 2026년 9월 8일 릴리스에서 Prompt Cache Diagnostics가 GPT-5.6 이상 지원 모델의 Responses API에 일반 제공되었습니다. FinOps 관점에서 유용한...

프롬프트 캐시 대시보드는 재사용이 줄었다는 사실을 알려 줄 수 있지만, 어떤 요청 변경이 원인인지, 그리고 그 비용이 얼마인지는 스스로 말해 주지 못합니다. OpenAI의 2026년 9월 8일 릴리스에서 Prompt Cache Diagnostics가 GPT-5.6 이상 지원 모델의 Responses API에 일반 제공되었습니다. FinOps 관점에서 유용한 일은 캐시 토큰 감소를 짧고 반복 가능한 조사로 바꾸는 것입니다.

재사용에 실패한 요청 비교하기

재사용될 것으로 예상했던 프리픽스를 가진 최근 완료 응답의 ID를 저장하세요. 같은 조직에서 이어지는 비슷한 Responses API 요청에 prompt_cache_options.comparison_response_id를 그 ID로 설정합니다. 그다음 새 응답의 prompt_cache_diagnostics와 usage.input_tokens_details.cached_tokens를 함께 읽으세요. 비교 옵션은 진단을 요청할 뿐, 이전 대화를 불러오거나 캐시 동작을 바꾸지 않습니다. OpenAI의 진단 가이드에 동작하는 요청 예시가 있습니다.

const next = await client.responses.create({
  model: model,
  instructions: stableInstructions,
  input: nextInput,
  tools: stableTools,
  prompt_cache_options: { comparison_response_id: baseline.id }
});
console.log(next.prompt_cache_diagnostics);
console.log(next.usage.input_tokens_details.cached_tokens);

이 스니펫은 baseline이 최근 완료된 응답이고 나머지 변수는 자체 요청 데이터라고 가정합니다. 캐시될 만큼 충분히 긴 안정된 프리픽스를 유지하세요. OpenAI는 GPT-5.6 이상에 대해 최소 1,024 토큰을 문서화합니다. 작거나 전혀 다른 프롬프트는 의미 있는 캐시 미스 테스트가 되지 않습니다.

지표가 아니라 원인을 고치세요

cache_miss 결과는 모델 변경, 서비스 티어, 도구 정의나 순서, 캐시 키, 응답 형식, 추론 강도, 상세도, 또는 압축된 컨텍스트를 가리킬 수 있습니다. 예를 들어 무해해 보이는 도구 스키마 이름 변경도 재사용 가능한 프리픽스를 무효화할 수 있습니다. 요청 설정과 가장 앞쪽 프롬프트 바이트를 비교하고, 변경이 우연이었던 곳에서는 안정성을 회복한 뒤 같은 baseline으로 비교를 다시 실행하세요. OpenAI는 찾아낸 첫 번째 원인을 보고하므로, 첫 수정 후에 다른 원인이 나타날 수도 있습니다.

변경이 의도적이었다면 억지로 히트를 만들지 마세요. 다른 모델은 캐시 재사용을 잃더라도 전체 작업 비용을 낮출 수 있고, 압축은 이후 컨텍스트를 줄일 수 있습니다. 캐시 히트율만 따로 보지 말고 요청과 작업 전체를 판단하세요. 만료된 baseline이나 unavailable 결과는 결론이 없는 상태일 뿐, 캐싱이 실패했다는 증거가 아닙니다.

발견 사항을 금액으로 바꾸기

cache_missed_tokens는 비교 응답 대비 잃어버린 재사용 가능 토큰을 추정한 값입니다. 청구된 토큰 수가 아닙니다. cache_hit 결과도 달러 기준 절감을 입증하지 않습니다. 실제 입력 비용을 구하려면 응답마다 input_tokens, cached_tokens, cache_write_tokens의 합계를 모은 뒤, 해당 모델과 처리 티어의 현재 요율을 적용하세요. GPT-5.6 이상에 대해 OpenAI의 프롬프트 캐싱 가이드는 캐시 읽기가 캐시되지 않은 입력 요율의 0.1배, 캐시 쓰기가 1.25배라고 명시합니다.

ordinary = input_tokens - cached_tokens - cache_write_tokens
weighted_input = ordinary + 0.1 * cached_tokens + 1.25 * cache_write_tokens
input_cost = weighted_input * input_price_per_million / 1_000_000

이 토큰 범주들은 서로 배타적입니다. 쓰기 요율로 이미 계산된 토큰에 캐시 쓰기 할증을 다시 더하지 마세요. 이 공식은 입력만 다루므로, 성공한 작업당 비용을 계산할 때는 출력, 도구, 재시도, 기타 요금도 포함하세요. 이 글에 하드코딩된 가격이 아니라 공급자의 현재 가격표를 사용하세요.

유용한 주간 점검

비교 가능한 트래픽을 워크로드, 모델, 서비스 티어별로 묶고, 캐시 토큰 비율과 완료된 작업당 입력 비용을 차트로 보세요.
갑작스러운 회귀를 샘플링해 최근 baseline과 비교하고, 진단 사유와 담당 코드 변경을 기록하세요.
우연한 프리픽스 또는 설정 드리프트를 고치세요. 작업 전체의 경제성이 좋아진다면 의도된 품질이나 라우팅 변경은 유지하세요.
대표적인 프로덕션 트래픽으로 결과를 검증하고, 관측된 절감액을 청구서와 대조하세요.

진단 자체에는 추가 기능 요금이 없지만, 추가 테스트 요청은 일반 요금으로 청구됩니다. 얻는 이득은 보기 좋은 적중률 그래프가 아닙니다. 특정 워크로드의 입력 비용이 왜 바뀌었는지, 그리고 제안된 수정이 실제로 청구액을 낮췄는지에 대한 설득력 있는 설명입니다.

팀이 자주 묻는 질문

캐시 히트 진단이 요청이 더 저렴했다는 증거인가요?

아니요. 선택한 baseline 대비 미스가 감지되지 않았다는 뜻일 뿐입니다. 절감을 주장하기 전에 실제 cached_tokens와 요금이 매겨지는 토큰 범주를 확인하세요.

진단으로 임의의 두 OpenAI 요청을 비교할 수 있나요?

아니요. 같은 조직의 최근 완료 baseline을 사용하고, 지원되는 GPT-5.6 이상 Responses API 모델에서만 이 흐름을 기대하세요. 비교 기록은 만료될 수 있습니다.

모든 캐시 미스를 없애야 하나요?

아니요. 모델 전환, 다른 서비스 티어, 압축된 컨텍스트는 의도된 변경일 수 있습니다. 변경을 되돌리기 전에 품질, 지연 시간, 성공한 작업당 비용을 비교하세요.

이 내용을 현재 스택에 적용하고 싶으신가요? 공급업체 청구서, 게이트웨이 로그, 주요 워크플로를 가져오시면 비용 요인과 절감 경로를 정리해드립니다. 무료 감사 예약 →

finopsllm.com으로 돌아가기