프롬프트 캐시 손익분기 계산기

캐시는 무조건 이득이 아닙니다. 읽기는 싸지만 쓰기가 더 비쌉니다. 재사용이 적으면 안 거는 편이 낫습니다.

계산해보기

손익분기는 재사용 횟수로 정해집니다

프롬프트 길이나 모델과 관계없이, 손익분기점은 재사용 횟수 하나로 결정됩니다. 배수가 모든 모델에서 동일하기 때문입니다.

재사용 0회, 즉 저장만 하고 안 읽으면 5분 캐시는 25%, 1시간 캐시는 100% 더 냅니다. 캐시를 걸어두고 트래픽이 안 오는 시간대가 있다면 그만큼 손해입니다.

재사용 간격에 따라 골라야 합니다

5분 캐시가 더 싸지만, 5분 안에 다시 안 오면 만료됩니다. 만료되면 다음 요청은 다시 쓰기(1.25배)로 시작합니다. 쓰기만 반복하는 최악의 패턴이 됩니다.

길이가 짧으면 캐시가 아예 안 걸립니다

덜 알려진 함정입니다. 프롬프트가 일정 길이 미만이면 cache_control을 넣어도 캐시가 걸리지 않습니다. 더 나쁜 건 에러가 나지 않는다는 점입니다. 그냥 조용히 캐시 없이 처리됩니다.

기준이 모델마다 다르고, 세대가 올라간다고 낮아지지도 않습니다.

캐시가 깨지는 흔한 원인

캐시는 앞부분이 완전히 같아야 맞습니다. 1바이트라도 다르면 그 뒤 전체가 무효가 됩니다. 아래는 실무에서 가장 많이 걸리는 것들입니다.

• 시스템 프롬프트에 현재 시각 — datetime.now()를 넣으면 매 요청마다 달라집니다
• 사용자 ID·등급을 앞부분에 — 사용자끼리 캐시를 공유할 수 없게 됩니다
• 정렬 없는 JSON 직렬화 — 키 순서가 바뀌면 다른 문자열입니다
• 도구(tools) 목록 변경 — 도구는 가장 앞에 들어가서, 바뀌면 전부 무효가 됩니다
• 모델 교체 — 캐시는 모델별로 따로 저장됩니다

고치는 방향은 하나입니다. 변하지 않는 것을 앞에, 매번 달라지는 것을 뒤에. 날짜나 사용자 정보는 시스템 프롬프트가 아니라 메시지 뒤쪽으로 옮기세요.

배치와 함께 쓰면 할인이 겹칩니다

프롬프트 캐시 할인과 Batch API 할인은 중복 적용됩니다. 다만 배치에서는 요청이 순서 없이 처리되어 캐시 적중이 보장되지 않고, 공식 문서 기준 실제 적중률은 30~98%로 갈립니다.