AI 프롬프트 캐시 비교: GPT·Claude·Gemini 반복 문서 질문 비용

같은 업무 매뉴얼을 AI에 붙여 넣고 질문만 바꾸는데도 입력 비용이 계속 비슷하다면, 고정 원문의 끝이 캐시 경계로 잡혀 있는지부터 확인하세요. 고정 지시문과 참고 원문을 앞에 두고 바뀌는 질문은 뒤로 보내는 것이 출발점입니다. 그다음 실제 사용량을 일반 입력·캐시 쓰기·캐시 읽기로 나누어야 절감액을 계산할 수 있습니다.

기존 OpenAI·Claude 연동에서는 GPT-6.1 Sol과 Claude Sonnet 5.5의 명시적 경계를 먼저 검토할 만합니다. Gemini 3.8 Flash는 현재 기본 단가가 낮아 반복 질문의 시작 후보로 둘 수 있지만, Interactions API의 자동 캐시 적중은 사용량에서 확인해야 합니다. 질문 간격이 길다면 Sonnet의 5분·1시간 선택과 Gemini의 명시적 저장료까지 따져보세요. 이 추천은 공식 기능과 요금에 따른 설계 판단입니다.

확인 기준일은 2026년 10월 12일 한국시간(KST)입니다. 아래는 Standard 유료 텍스트 API의 공식 조건과 가정 비용입니다. 실제 모델 응답·적중률·속도·정확도는 측정하지 않았으며, 앱 구독료는 API 요금과 별개입니다.

대표 이미지는 반복 문서 질문을 설명하는 합성 도해입니다. 실제 모델 응답이나 캐시 적중 측정 화면이 아닙니다.

프롬프트 캐시는 어디까지 재사용하나요

프롬프트 캐시는 반복되는 입력의 처리 결과를 재사용하는 기능입니다. 같은 참고 원문을 읽고 다른 질문에 답할 때 도움이 될 수 있습니다. 답변 자체를 저장해 같은 답을 돌려주는 기능은 아니므로, 캐시에 적중해도 새 질문의 해석과 답의 근거는 확인해야 합니다.

반복 문서 질문의 입력 배치

고정 지시문 → 참고 원문과 버전 → [고정 부분의 캐시 경계] → 이번 질문

지시문·원문·블록 순서와 모델·도구·출력 설정을 유지하고, 실행 정보는 로그에 남기세요. OpenAI 캐시 경계 안내, Claude 캐시 안내

모델과 API 경로별 최소 길이와 수명

비교할 정확한 모델 ID는 gpt-6.1-sol, claude-sonnet-5-5, gemini-3.8-flash입니다. 같은 서비스 안에서도 API 경로에 따라 캐시 설정과 사용량 필드가 달라집니다. Sol 모델 문서, Sonnet 모델 문서, Flash 모델 문서

Gemini 명시적 캐시의 최소 길이는 사용 모델의 생성 조건을 별도로 확인해야 합니다. 아래 비용 예시는 explicit 최소 길이를 실증한 결과가 아닙니다. Gemini 명시적 캐시 조건

최소 길이를 충족해도 적중을 보장하지 않습니다. Sonnet은 길이 미달 시 오류 없이 비캐시 처리될 수 있습니다. OpenAI 최소 길이와 TTL, Claude 최소 길이와 TTL

Sol의 기본 implicit는 최신 캐시 가능 메시지 끝을 사용합니다. 질문이 바뀌면 공통 원문만 같아도 miss가 날 수 있어, 아래처럼 고정 부분 끝에 명시 경계를 둡니다. 현재 OpenAI 캐시 동작과 주의점

다음은 Sol Responses 요청에서 사용하는 핵심 설정과 배치 예시입니다. 생략된 원문 자리에 실제 참고 자료를 넣어야 하며, 예시 문자열 자체로 최소 길이나 캐시 적중을 확인하는 코드는 아닙니다.

Sol의 명시적 경계 설정 예시

{
  "model": "gpt-6.1-sol",
  "prompt_cache_options": {"mode": "explicit", "ttl": "30m"},
  "input": [
    {
      "role": "developer",
      "content": [
        {
          "type": "input_text",
          "text": "고정 지시문과 참고 원문...",
          "prompt_cache_breakpoint": {"mode": "explicit"}
        }
      ]
    },
    {
      "role": "user",
      "content": [{"type": "input_text", "text": "이번 질문..."}]
    }
  ]
}

Sol의 explicit 모드에는 블록 경계도 필요합니다. Sonnet의 고정 부분 끝에는 cache_control: {"type": "ephemeral"}를 붙이고, 1시간 선택 시 "ttl": "1h"를 추가합니다. Sol 설정 예시, Sonnet 명시적 경계

Gemini의 경로별 지원은 표처럼 구분합니다. 캐시로 참조한 내용도 컨텍스트·토큰 한도에 포함됩니다. Gemini 현재 캐시 가이드, Generate Content 명시적 캐시

현재 Standard API 단가 비교

아래는 미국 달러/100만 토큰입니다. Sol은 요청 입력 272K토큰 이하, Flash는 2026년 12월 31일까지의 Standard 유료 텍스트 요율을 기준으로 합니다. 저장료의 단위는 토큰·시간이므로 읽기 단가와 구분해서 보세요.

쓰기로 분류한 토큰에 일반 입력료를 다시 더하지 않습니다. 단가는 OpenAI 가격표, Claude 가격표, Gemini Developer API 가격표에서 확인할 수 있습니다.

Sol은 입력이 272K토큰을 넘으면 초과분만이 아니라 요청 전체의 입력·캐시 요율이 2배, 출력 요율이 1.5배가 됩니다. Flash는 2027년 1월 1일부터 일반 입력 $1.50, 출력 $7.50, 캐시 읽기 $0.15, 명시적 저장 $1.00/100만 토큰·시간으로 변경되는 일정이 공지돼 있습니다. 실제 요청일의 요율을 다시 확인하세요. Sol 장문 조건, Flash 기간별 가격

같은 참고 원문으로 질문 10개를 보낼 때의 비용

계산 조건을 다음처럼 고정하겠습니다. 이는 과금량을 가정한 산술 예이며, 뒤의 작은 실습 원문을 토큰화한 값이 아닙니다. 같은 문서를 넣어도 실제 토큰 수는 모델마다 다를 수 있습니다.

• 매 요청의 공통 참고 부분은 20,000토큰, 변경되는 질문은 2,000토큰, 과금 출력은 1,000토큰으로 가정합니다.
• 질문은 10개이며 모두 4분 안에 순차 요청합니다. 캐시 경계 앞 내용과 관련 설정은 유지합니다.
• Sol·Sonnet은 처음 20,000토큰을 한 번 쓰고 이후 9회에 그 부분 전체를 읽는다고 가정합니다.
• Flash Interactions는 첫 공통 입력을 일반 요율로 처리하고 이후 9회에 전체 공통 부분이 implicit 캐시에 적중한다고 가정합니다.
• 과금 출력 1,000토큰에는 청구되는 추론 분량까지 포함했다고 가정합니다. 도구·재시도·Batch·속도 옵션·지역 요금·세금·환율은 제외합니다.

Sol의 예를 풀면 공통 부분 쓰기 20,000 × $2.50 ÷ 1,000,000 = $0.05, 읽기 180,000 × $0.10 ÷ 1,000,000 = $0.018입니다. 질문 총 20,000토큰은 $0.04, 과금 출력 총 10,000토큰은 $0.10이므로 합계는 $0.208입니다. 캐시 없는 산술 기준은 일반 입력 220,000토큰 $0.44와 출력 $0.10을 더한 $0.54입니다.

Flash는 첫 공통 입력 $0.015 + 이후 공통 입력 읽기 $0.0135 + 질문 $0.015 + 출력 $0.0375 = $0.081입니다. implicit 적중에 명시적 저장료를 자동으로 더하지 않습니다. 이 표의 적중 9회는 관측값이 아니며, 캐시 없는 열도 실제로 캐시를 끈 API 실험이 아닙니다. 따라서 금액 순서를 답변 품질이나 처리 속도 순위로 확대할 수 없습니다.

질문 간격이 길면 캐시 쓰기가 더 비쌀 수 있습니다

위 계산에서 중요한 조건은 ‘한 번 쓰고 아홉 번 읽는다’입니다. Sonnet 5분 캐시를 쓰면서 다른 재사용 없이 10분마다 질문하고, 실제 사용량이 매번 새로운 쓰기로 잡혔다고 가정해 보세요. 10회 쓰기 비용은 $0.50이고 질문·출력 $0.14를 더하면 $0.64입니다. 이 경우는 캐시 없는 산술 기준 $0.54보다 높습니다.

같은 10분 간격에 1시간 캐시가 계속 재사용된다면 위의 $0.238 가정을 적용할 수 있습니다. Sonnet의 수명은 생성·읽기 요청 시작부터 계산하므로 스트리밍 시간도 포함됩니다. 실제 읽기·쓰기는 사용량으로 확인하세요. Claude 캐시 수명과 동시 요청 조건

Gemini 명시적 캐시는 저장 시간도 계산합니다. 예를 들어 20,000토큰을 1시간 보관하면 소개 요율의 저장 항목만 20,000 × $0.50 ÷ 1,000,000 × 1 = $0.01입니다. 후속 요청의 읽기·일반 입력·출력은 별도이며, 질문이 적어도 지정한 보관 시간의 비용을 살펴야 합니다. Developer API의 캐시 생성 과금도 해당 계정과 요금 문서에서 확인하세요. 여기서는 생성 과금을 확정하지 못했으므로 명시적 캐시의 총비용을 제시하지 않습니다. Gemini 명시적 캐시 비용, Gemini 요금 문서

사용량 필드로 읽기와 쓰기를 검산하기

응답 문구가 “이전에 준 문서를 참고했다”고 말하는 것은 캐시 적중의 증거가 아닙니다. 실제 API 응답의 usage와 계정 청구 기록을 보세요. 특히 세 서비스에서 ‘전체 입력’의 뜻이 같지 않습니다.

Claude의 input_tokens에서 읽기·쓰기를 또 빼지 마세요. 혼합 TTL은 usage.cache_creation.ephemeral_5m_input_tokens와 ephemeral_1h_input_tokens로 나누어 과금합니다. OpenAI 사용량과 비용 계산, Claude usage 정의

출력 사용량 정의는 OpenAI 출력 토큰 안내와 Claude thinking 과금 안내에서도 확인할 수 있습니다.

Flash Interactions의 출력과 thought는 별도 필드입니다. 위 비용표의 ‘과금 출력 1,000토큰’은 이 합계를 가정한 값이므로 thought를 1,000에 다시 더하지 않습니다. 실제 요청에서는 도구 사용 여부와 해당 API의 사용량 정의를 따르세요. Interactions usage 참조, Gemini thinking 과금

Legacy Generate Content를 사용한다면 입력 필드도 바뀝니다. usageMetadata.promptTokenCount는 캐시 내용을 포함한 전체 입력, usageMetadata.cachedContentTokenCount는 그중 캐시 부분이므로 일반 입력은 둘의 차이입니다. Interactions의 필드 이름을 그대로 적용하지 마세요. 명시적 캐시 생성·저장료는 후속 요청 입력료와 따로 검산합니다. Generate Content UsageMetadata

1. 정확한 모델 ID, API 경로, 추론·도구·출력 설정, 참고 원문의 버전과 SHA-256을 기록합니다.
2. 각 요청의 시작 시각, 응답 상태, 일반 입력·쓰기·읽기·과금 출력 사용량을 남깁니다. 반환되지 않은 필드는 임의로 0으로 채우지 말고 미확인으로 둡니다.
3. 모델·설정별로 전체 요청의 사용량을 합산하고 각 항목 단가를 곱합니다. Sonnet은 쓰기 TTL을, Gemini 명시적 캐시는 저장 기간을 분리합니다.
4. 질문별 첫 답의 근거 충족 여부와 수정 요청을 연결합니다. 재시도 비용과 실패한 첫 요청도 합계에서 빼지 않습니다.

작은 합성 원문으로 답의 근거를 확인하기

다음 원문은 실제 판매 정책이 아닌 합성 예제입니다. 고정 부분과 바뀌는 질문을 나누는 방법, 그리고 정답 검수를 연습하는 용도입니다. 이 짧은 원문은 20,000토큰이 아니며 위 모델의 캐시 최소 길이를 충족하는 실습으로 쓰지 않습니다. 캐시 사용량을 관찰하려면 개인정보·비밀정보가 없는 실제 참고 자료를 별도로 준비하고 해당 모델 기준 토큰 길이를 확인하세요.

고정 참고 원문과 경계의 위치

고정 지시문
아래 참고 원문만 사용해 이번 질문에 답한다.
기한·금액·제출 자료를 원문 그대로 유지한다.
답의 근거가 되는 규칙 ID를 붙인다.
원문에 없는 정보는 "자료에 없음"이라고 쓴다.

참고 원문: synthetic_policy_v1
R01: 단순 변심 반품은 상품 수령 후 7일 이내에 접수하며 영수증을 제출한다.
R02: 상품 파손은 수령 후 48시간 이내에 신고하며 파손 사진을 제출한다.
R03: 미개봉 세일 상품의 단순 변심 반품에도 R01의 7일·영수증 규칙을 적용한다.
R04: 반품 배송비는 3,000원이다. 판매자가 확인한 제품 하자는 판매자가 배송비를 부담한다.

[이 지점까지 고정 부분, 모델별 명시 경계는 API 설정으로 지정]
[아래에는 이번 질문 하나만 넣는다]

세 질문은 각각 별도 요청으로 보내고 앞의 고정 부분은 그대로 유지합니다. 아래 기대 답은 합성 원문에서 정한 참조 기준이며 실제 모델의 응답이 아닙니다. 기대 답을 최초 요청에 함께 넣지는 마세요.

검수는 세 가지를 따로 봅니다. 첫째, 기한·금액·필요 자료·부담 주체가 기대 기준과 맞는지 확인합니다. 둘째, 붙인 규칙 ID의 실제 문장이 그 답을 뒷받침하는지 읽습니다. 셋째, 원문에 없는 환불 기간이나 전화번호를 확정하지 않았는지 봅니다. 캐시 읽기 사용량이 늘어도 이 검사는 줄이지 않습니다.

적중 실패와 틀린 답은 어디서 고칠까요

문서 내용이 바뀌면 새 입력으로 다루세요. Gemini 명시적 캐시의 내용·모델은 생성 뒤 변경할 수 없으므로 새 캐시가 필요합니다. 수명 연장은 오래된 정책을 최신 정책으로 바꾸는 작업이 아닙니다. Gemini 캐시 객체 변경 범위

인증·권한·요청 한도·출력 잘림은 답의 정확도와 분리해 남깁니다. 원본 응답과 사용량을 보존한 뒤 해당 요청 설정을 확인하세요. 잘못된 첫 답을 수정했더라도 첫 실패와 추가 비용이 사라지는 것은 아닙니다.

내 업무에서 선택하는 기준

• Sol부터 확인할 상황: 기존 Responses 연동에서 고정 부분의 경계를 관리하려는 경우입니다. 장문 할증과 실제 읽기·쓰기 분류를 함께 봅니다.
• Sonnet부터 확인할 상황: 기존 Claude 흐름에서 질문 간격별 비용을 관리하려는 경우입니다. 동시 첫 요청과 TTL별 쓰기 총액을 확인합니다.
• Flash부터 확인할 상황: 현재 낮은 Standard 단가로 반복 질문을 시험하려는 경우입니다. 실제 적중량을 기록하고, 명시적 저장이 필요하면 API 경로와 저장 비용을 검토합니다.

최종 비교에는 모든 최초 요청과 재시도의 API 비용 합계 ÷ 근거 검수를 통과한 고유 질문 수를 모델·설정별로 남기세요. 같은 질문이 수정 후 다시 통과해도 분모에는 한 번만 셉니다. 통과한 질문이 0개면 결과당 비용은 계산 불가로 두고, 사람의 검수 시간은 별도 열에 기록합니다.

일반 코딩·문서 벤치마크 점수에서 이 반복 질문의 캐시 적중률이나 총비용을 가져올 수는 없습니다. 먼저 고정 경계, 요청 간격, 실제 usage를 맞춘 뒤 같은 질문의 근거 검수와 수정까지 포함한 비용으로 선택하세요. 캐시가 잘 맞는 입력 설계와 답이 맞는지는 각각 확인할 항목입니다.

전체 모델 선택의 배경은 GPT·Claude·Gemini 5종 성능·가격 비교를, 원문 내용의 개정 전후를 맞추는 작업은 AI 문서 버전 비교를 참고하세요. 이번 글의 중심은 같은 원문에 질문을 바꿔 붙일 때의 캐시 조건과 비용입니다.