Skip to main content
Grok에서 에이전트, 긴 시스템 prompt 또는 멀티턴 대화를 실행할 때 프롬프트 캐싱은 입력의 캐시된 부분에 대해 0.25×(75% 절감)만 과금되며, 캐싱이 완전히 자동이므로 코드 변경은 필요하지 않습니다. 기대치를 미리 설정해 두십시오. xAI는 캐시 항목이 메모리 압박을 받거나, 재시작이 발생하거나, 요청이 다른 서버에 도착할 때 제거될 수 있다고 명시하고 있으므로 히트가 보장되지는 않습니다. 캐시 할인은 있으면 좋은 수준으로 받아들이고, 캐시 미적용 가격 기준으로 예산을 잡으십시오. 이 페이지는 xAI의 공식 문서(docs.x.ai/developers/advanced-api-usage/prompt-caching)를 따르며, 2026-08-19에 APIYI 게이트웨이에서 grok-4.6에 대한 실측 테스트(124건의 호출, 백엔드 과금 기록과 행 단위로 대조)를 바탕으로 작성되었습니다.

한 문장으로

요청의 앞부분(접두사) 이 최근 요청과 바이트 단위로 완전히 일치할 때마다, 상위 시스템은 중복 작업을 건너뜁니다. 일치한 부분은 **0.25×**로 과금됩니다. 매개변수도 없고, 마커도 없습니다. 다른 두 방식과의 차이점은 다음과 같습니다.
  • Claude와 비교하면: cache_control 마커가 없습니다. 조건이 충족되면 그냥 그렇게 동작합니다
  • OpenAI와 비교하면: 설정 방식은 똑같이 자동이고 작성도 똑같이 자유롭지만, Grok에는 prompt_cache_key-스타일의 라우팅 제어가 없습니다

굳이 따질 이유 — 배수를 보시면 됩니다

모델의 원본 입력 token 가격을 **1×**로 두면: 손익분기점: 두 번째 요청입니다. 상각할 쓰기 요금이 없으므로, 접두부가 처음 재사용되는 순간부터 절감되는 금액은 전부 순이익입니다. grok-4.6에 대한 달러 기준 금액입니다(1M tokens당, 두 컨텍스트 구간 모두): 다른 Grok 모델의 구간 경계와 캐시 읽기 요율은 Grok 개요의 단계별 가격 표에 있습니다.

적합한 경우

  • 하나의 긴 시스템 prompt와 도구 정의를 계속해서 반복 호출하는 경우(에이전트, 지원 봇)
  • 하나의 문서를 대상으로 한 일괄 작업(한 계약서에 대해 50개 질문)
  • 안정적인 문서 청크가 prompt 앞부분에 위치하는 RAG
  • 멀티턴 대화 — 다만 Grok에서는 이를 구현하는 두 가지 방식이 매우 다르게 동작하므로(아래 참고) 주의해야 합니다

부적합한 경우

  • 매번 맨 처음 문자부터 서로 다른 요청
  • 천 token 범위보다 작은 prompt — 테스트에서는 이런 요청을 반복 호출해도 재사용 가능한 캐시가 전혀 생성되지 않았습니다

양쪽 엔드포인트, 스트리밍과 비스트리밍 모두 대조 완료

/v1/chat/completions/v1/responses, 각각 스트리밍과 비스트리밍: 2026-08-19에 백엔드 과금 기록과 대조하여 네 가지 조합 모두를 정산했으며, 캐시된 부분은 모든 경우에 캐시 요율로 과금되었습니다.
게이트웨이에는 클라이언트 측 적응이 필요하지 않습니다. 캐시 동작은 업스트림으로 그대로 전달되며, cached_tokens는 원문 그대로 되돌려지고, 백엔드 과금 내역에는 캐시된 부분이 별도의 “cache read” 항목으로 표시됩니다.

적중 조건

적중은 128 tokens 단위로 내림됩니다

두 차례의 테스트가 일치합니다. 8802-token 접두사는 8704 (= 68 × 128)에 적중했고, 더 이른 차례의 2735-token 접두사는 2688 (= 21 × 128)에 적중했습니다. 따라서 cached_tokens는 보통 안정적인 접두사보다 약간 더 작습니다 — 이는 예상되는 현상입니다.

추가만 허용: 편집 기록은 이를 깨뜨립니다

같은 접두사를 연속으로 보냈을 때, 한 번의 호출만 변경한 경우입니다: 실무적으로 이는 다음을 의미합니다. 안정적인 콘텐츠를 먼저 두고, 변동적인 콘텐츠를 마지막에 두어야 합니다.

최소 실행 예제

서로 다른 질문과 함께 같은 긴 접두사를 두 번 보내십시오. 첫 번째는 캐시에 기록하고, 두 번째는 캐시 적중이 발생합니다.
예상 출력:
두 번째 호출에서는 cached가 system prompt 길이에 거의 도달하며(128로 내림), 해당 부분은 0.25×로 과금됩니다.
/v1/responses 엔드포인트는 자동으로 동일하게 작동하며, 필드는 usage.input_tokens_details.cached_tokens입니다. 해당 엔드포인트에서는 긴 대화가 추가 이점을 얻습니다 — 아래의 「긴 대화는 responses 체인에 속합니다」를 참조하십시오.

적중과 미스를 구분하기 — 사용량 필드를 읽는 방법

읽는 방법: 작은 값은 적중이 아닙니다

단순히 “0보다 큰지”만 확인하지 마십시오. cached_tokens를 안정적인 접두사 길이와 비교하십시오: 테스트에서는 콜드 상태의 첫 호출조차 때때로 100~200 수준의 값을 되돌려줍니다. 속지 마십시오 — 그렇다고 해서 접두사가 캐시되었다는 뜻은 아닙니다.

대조하기: 콘솔의 캐시 과금 세부 정보

단일 호출에 대한 백엔드 로그는 캐시 읽기 token 수와 그 요율 배수를 별도 행으로 나열하며, 이를 응답의 cached_tokens과 대조할 수 있습니다. 한 번의 호출이 정확히 어떻게 과금되었는지 알아야 할 때는 그것이 가장 신뢰할 수 있는 기준입니다. 3단계 자체 점검:
  1. 안정적인 접두사를 1000 token 이상으로 구성한 뒤 요청 2개를 연달아 보내십시오
  2. 두 번째 응답에는 cached_tokens가 수천 단위로 분명하게 보여야 합니다
  3. 백엔드 호출 로그에서 해당 요청에는 “캐시 읽기” 항목이 표시되고, 첫 번째보다 입력 비용이 눈에 띄게 낮아집니다

히트율 향상

안정적인 Prefix를 설계하십시오

  • 긴 지침, few-shot 예시, 도구 정의를 먼저 배치하고, 사용자 입력과 타임스탬프는 마지막에 둡니다
  • 도구 정의의 순서와 JSON 직렬화를 고정하십시오(직렬화기가 키를 섞지 않도록 하십시오)
  • 이미지 입력도 prefix 일치에 포함됩니다 — 하나를 재사용할 때는 base64 / URL과 매개변수를 동일하게 유지하십시오
  • 같은 prefix를 짧은 시간에 몰아서 재사용하십시오; 호출을 넓게 흩어 놓지 마십시오
방법론은 OpenAI의 것과 같습니다. 자세한 버전은 OpenAI prompt caching 가이드를 참조하십시오.

긴 대화는 Responses 체인에 두어야 합니다

이것은 Grok에서 쉽게 놓치는 차이입니다: 따라서 긴 대화와 다단계 에이전트에는 Responses API 체인을 선호하십시오:
엔드포인트 차이는 Grok 개요 페이지의 엔드포인트 개요에서 다룹니다.

x-grok-conv-id에 관하여

xAI의 모범 사례에서는 히트율을 높이기 위해 모든 요청에 x-grok-conv-id 헤더(UUID 또는 세션 ID)를 보내라고 권장합니다. APIYI에서 대칭 A/B를 수행했으며 — 헤더가 있는 여러 독립적인 prefix와 없는 여러 독립적인 prefix를 각각 여러 번 재사용했지만 — 두 그룹 사이에서 관찰 가능한 차이는 없었습니다. 보내도 해롭지는 않지만, 히트율은 기대하지 마십시오.

적중률과 예상할 점

캐시 적중은 보장되지 않습니다. xAI의 문서에서는 항목이 메모리 압박, 서비스 재시작, 또는 요청이 다른 서버로 라우팅되는 경우 손실될 수 있다고 명시합니다.테스트에서는 안정적인 접두사가 짧은 시간에 집중적으로 재사용될 때 대부분의 요청이 적중했지만, 실제 지터가 있으며 이는 업스트림에서 발생합니다 — 호출자 측에서는 이를 제어할 수 없습니다. 캐시 미적용 가격을 기준으로 예산을 잡고 적중은 보너스로 취급하십시오.
분명히 말씀드릴 점이 하나 더 있습니다: 캐싱의 가치는 속도가 아니라 비용입니다. 측정된 첫 토큰까지의 시간은 적중과 미적중 사이에서 불과 수백 밀리초 정도만 차이났습니다 — 캐싱이 긴 컨텍스트 요청을 빠르게 만들어줄 것이라고 기대하지 마십시오.

흔한 함정

다른 채널과의 간단한 비교

플랫폼 전체의 캐싱 지원에 대해서는 캐시 과금 FAQ를 참조하십시오.
이 페이지의 모든 수치는 grok-4.6 (2026-08-19)에서 측정되었습니다. xAI는 모든 Grok 언어 모델이 prefix 캐싱을 지원한다고 밝히고 있습니다. 저희는 다른 모델들은 하나씩 벤치마크하지 않았으므로, 블록 단위와 짧은 prompt 동작 같은 세부 사항은 자신의 워크로드에서 직접 확인하셔야 합니다.특정 prefix에 대해 보이는 과금이 여기 설명과 분명히 다르다면, 응답 헤더의 request-id를 첨부하여 지원팀에 문의하십시오.

요약

1. 완전 자동

마커가 없고 쓰기 요금도 없습니다. 조건을 충족하면 캐시되며, 두 번째 재사용은 순수한 절감입니다.

2. 추가만 허용

메시지 시작부터 바이트 단위로 일치 여부를 확인합니다. 편집 이력은 이를 무효화하며, 적중은 128 tokens 단위로 내림됩니다.

3. 긴 대화 이어가기

멀티턴 chat은 원래의 정적 접두사만 재사용하며, responses + previous_response_id는 턴마다 적중을 늘립니다.

4. 적중에 기대지 마십시오

적중은 보장되지 않습니다. 캐시 미적용 가격 기준으로 예산을 잡고, 할인은 보너스로 간주하십시오.

관련 링크