AI API의 캐시 요금은 왜 이렇게 쌀까

요즘 LLM API 가격표에는 거의 다 '캐시된 입력' 줄이 따로 있습니다. 값은 일반 입력보다 훨씬 쌉니다. Claude Opus 5.5는 입력이 100만 토큰당 $4인데 캐시 읽기는 $0.20입니다. Claude Fable 5.1은 $10 대 $0.25입니다.

Claude Opus 5.5, 입력 토큰 100만 개 가격

일반 입력 $4.00

캐시에서 읽기 $0.20

이걸 '캐시 입력'과 '캐시 출력'으로 나눠 읽는 경우가 있습니다. 하지만 출력은 캐시되지 않습니다. 출력 토큰은 매번 모델이 새로 만들어 냅니다. Anthropic 문서도 캐시를 쓰든 안 쓰든 응답은 똑같다고 적고 있습니다. 캐시되는 건 프롬프트를 읽는 작업입니다.

따로 켜야 할까?

대부분은 따로 켜지 않아도 이미 쓰고 있습니다. OpenAI는 지원하는 모델이면 기본으로 캐시합니다. Gemini도 2.5 이후 모델은 암묵적 캐시가 기본으로 켜져 있습니다. DeepSeek은 코드를 고칠 필요 없이 알아서 캐시합니다.

Anthropic API만 다릅니다. 요청에 cache_control이 있어야 캐시합니다. 자동 모드를 쓰면 요청 맨 위에 필드 하나만 넣어도 마지막 블록까지 알아서 캐시할 수 있습니다. 블록마다 직접 지정해도 됩니다. Claude Code를 쓴다면 이 설정도 신경 쓸 필요가 없습니다. 기본으로 캐시를 켜 두기 때문입니다. 끄려면 오히려 DISABLE_PROMPT_CACHING을 설정해야 합니다. Gemini에는 사용자가 직접 만들어 두는 명시적 캐시도 있습니다. 이쪽은 시간당 보관료가 붙습니다.

캐시에 저장하는 단계가 따로 있는 것도 아닙니다. 어떤 앞부분을 처음 보낸 요청이 그 부분을 계산하면서 결과를 캐시에 남깁니다. 가격표의 '캐시 쓰기'가 바로 이 첫 요청입니다. Anthropic은 이 요청에 일반 입력의 1.25배(5분 보관) 또는 2배(1시간 보관)를 매깁니다. OpenAI도 GPT-5.6부터는 1.25배입니다. 이전 OpenAI 모델과 DeepSeek은 쓰기에 돈을 더 받지 않습니다.

캐시에 저장되는 것

트랜스포머는 요청을 두 단계로 처리합니다. 먼저 프리필(prefill) 단계에서 프롬프트 전체를 한 번에 읽습니다. 이때 토큰마다, 층마다 뒤따르는 토큰이 참조할 키(key)와 값(value) 벡터를 계산합니다. 다음 디코드(decode) 단계에서는 이 벡터를 바탕으로 답을 한 토큰씩 써 나갑니다. 긴 프롬프트의 시간과 비용은 대부분 프리필에서 나옵니다. 10만 토큰짜리 프롬프트라면 답의 첫 글자가 나오기 전에 10만 토큰 분량의 계산을 끝내야 합니다.

이 키와 값 벡터, 이른바 KV 캐시는 앞쪽 토큰에만 영향을 받습니다. 다음 요청이 똑같은 토큰으로 시작한다면 지난번 벡터를 그대로 가져와 그 부분의 프리필을 건너뛸 수 있습니다. 모든 회사가 첫 토큰부터 이어지는 앞부분(prefix)을 캐시하는 이유가 여기에 있습니다. 시스템 프롬프트 맨 위의 타임스탬프처럼 앞쪽 한 바이트만 달라져도 그 뒤가 전부 캐시 미스가 되는 이유도 같습니다.

효과는 응답 속도에서도 드러납니다. DeepSeek은 2024년 디스크 캐시를 도입했습니다. 그러면서 128K 토큰짜리 프롬프트의 첫 토큰이 캐시 적중 시 13초에서 약 0.5초로 빨라졌다고 밝혔습니다.

할인 폭이 이렇게 큰 이유

프리필을 건너뛰면 긴 프롬프트에 드는 계산 대부분이 사라집니다. 회사들은 그 절감분의 대부분을 가격에 반영합니다. 대신 저장 비용은 피할 수 없습니다. KV 벡터는 크기가 큽니다. 가장 빠른 보관 장소는 데이터센터에서 가장 귀한 자원인 GPU 메모리입니다. 이 비용은 세 군데에서 드러납니다.

• 짧은 수명. Anthropic은 기본적으로 5분 동안 캐시를 보관합니다. 읽을 때마다 타이머는 무료로 다시 맞춥니다. OpenAI의 예전 모델은 메모리 캐시를 5~10분 동안 쓰지 않으면 지웠습니다.
• 쓰기 할증. 앞에서 본 1.25배와 2배가 이 보관 비용입니다. 그래서 한 번만 보낼 프롬프트라면 캐시를 켜는 쪽이 오히려 비쌉니다.
• 더 싼 저장소. OpenAI의 24시간 보관 옵션은 메모리가 부족하면 텐서를 GPU 로컬 저장소로 옮깁니다. DeepSeek은 캐시를 분산 디스크 배열에 둡니다. 이게 가능한 이유로는 KV 캐시 크기를 줄이는 자사의 MLA 구조를 꼽습니다. Google은 명시적 캐시에 시간당 보관료를 받습니다. Gemini 3.1 Pro Preview 기준으로 100만 토큰당 시간당 $4.50입니다.

캐시가 어디에 있느냐도 중요합니다. OpenAI는 캐시를 개별 머신에 둡니다. 라우팅할 때는 요청 앞부분 토큰의 해시를 참고합니다. 그래서 앞부분이 같은 요청은 캐시가 있는 머신으로 갈 가능성이 큽니다. GPT-5.6 이전 모델에서는 같은 앞부분으로 분당 15건이 넘게 들어오면 요청이 다른 머신으로 넘칠 수 있습니다. 그만큼 적중률이 떨어집니다.

회사별 숫자

짧은 프롬프트는 아예 캐시되지 않습니다. 최소 길이는 최신 Claude 모델이 512토큰입니다(Opus 4.6과 Haiku 4.5는 4,096토큰). OpenAI GPT-5.6 이후는 1,024토큰을, Gemini는 2,048~4,096토큰을 요구합니다. DeepSeek은 64토큰 단위로 저장합니다.

Claude Opus 5.5로 계산해 보겠습니다. 10만 토큰짜리 문서에 5분 안에 질문을 10번 던진다고 해 봅시다. 캐시 없이는 10 × 10만 토큰 × 100만 토큰당 $4로 $4.00입니다. 캐시를 쓰면 첫 질문이 문서를 캐시에 쓰면서 1.25배인 $0.50이 듭니다. 나머지 아홉 번은 캐시에서 읽으므로 모두 합쳐 $0.18입니다. 합계는 $0.68로 약 83% 쌉니다. 5분짜리 캐시라면 두 번만 보내도 본전입니다.

10만 토큰 문서 하나에 질문 10번

캐시 없이 $4.00

캐시 사용 $0.68

캐시를 더 잘 맞추려면

캐시는 첫 토큰부터 똑같아야 맞습니다. 그래서 프롬프트에 무엇을 어떤 순서로 넣느냐에 따라 요금이 달라집니다. OpenAI, Anthropic, Google 문서의 조언도 같습니다. 바뀌지 않는 내용은 앞에, 바뀌는 내용은 뒤에 두라는 것입니다.

같은 문서로 두 번째 질문을 보낼 때

시각을 맨 앞에시각시스템 프롬프트문서질문

시각을 맨 뒤에시스템 프롬프트문서질문시각

캐시에서 읽음처음부터 계산

• 매번 똑같은 내용을 앞에 둡니다. 도구 정의, 시스템 프롬프트, 참고 문서, 예시가 여기에 해당합니다.
• 현재 시각, 사용자 이름, 요청마다 달라지는 정보는 맨 뒤나 마지막 사용자 메시지로 옮깁니다. 시스템 프롬프트 첫 줄에 시각이 있으면 그 뒤가 매번 전부 새로 계산됩니다.
• 순서를 고정합니다. 내용이 같아도 순서가 다르면 다른 프롬프트입니다. 도구 목록이나 JSON 키 순서가 요청마다 바뀌지 않게 해야 합니다.
• Anthropic은 도구, 시스템 프롬프트, 메시지 순서로 캐시합니다. 도구 정의를 하나만 고쳐도 그 뒤의 시스템 프롬프트와 메시지 캐시까지 무효가 됩니다. 웹 검색 같은 설정을 켜고 끄거나 thinking 설정을 바꿔도 캐시 일부가 무효가 됩니다.
• Anthropic에서 cache_control을 직접 붙인다면 바뀌지 않는 마지막 블록에 붙입니다. 시각이 든 블록에 붙이면 요청마다 쓰기 요금만 내고 읽기는 한 번도 일어나지 않습니다. Anthropic 문서가 흔한 실수로 꼽는 경우입니다. 자동 모드는 마지막 블록까지 캐시합니다. 그래서 그 블록이 매번 바뀌면 같은 문제가 생깁니다. 이럴 때는 위치를 직접 지정하는 편이 낫습니다.

다른 사람이 같은 걸 물어본 걸까?

아닙니다. 캐시가 맞았다는 건 우리 조직이, Anthropic이라면 우리 워크스페이스가 최근에 같은 앞부분을 보냈다는 뜻입니다. Anthropic, OpenAI, DeepSeek 모두 조직이나 사용자끼리는 캐시를 공유하지 않는다고 문서에 적어 두었습니다. Anthropic은 "프롬프트가 똑같더라도" 공유하지 않는다고 덧붙입니다. 실제 적중은 대부분 자기 대화에서 나옵니다. 채팅은 턴마다 지난 대화를 통째로 다시 보냅니다. 그래서 매 요청이 바로 앞 요청으로 시작합니다.

이 보장이 늘 지켜졌던 건 아닙니다. 2025년 스탠퍼드 연구진(Gu 외, ICML 2025)은 상용 API들의 첫 토큰 응답 시간을 쟀습니다. '피해자' 역할로 프롬프트 하나를 보낸 뒤, 앞부분이 같은 프롬프트를 '공격자' 역할로 보냈습니다. 그리고 공격자 쪽 응답이 캐시되지 않은 기준보다 빨리 오는지 확인했습니다. 그 결과 일곱 곳이 사용자 전체에 캐시를 공유하고 있었습니다. OpenAI의 임베딩 모델도 그중 하나였습니다. 이 문제는 제보 후 고쳐졌습니다. 캐시를 공유하면 타이밍 사이드 채널이 됩니다. 남의 프롬프트 일부를 짐작했다면, 응답이 얼마나 빨리 오는지로 그 짐작이 맞는지 확인할 수 있습니다. 같은 측정으로 OpenAI 임베딩 모델이 디코더 전용 트랜스포머라는 사실도 드러났습니다. 그전까지 공개된 적 없는 정보였습니다.

조직 단위 격리에도 함정이 있습니다. 앱이 API 키 하나로 요청을 보낸다면 그 앱의 모든 사용자는 한 캐시를 함께 씁니다. 2026년에는 바로 이 관점에서 API 게이트웨이와 중계 서비스를 살펴본 연구들도 나왔습니다. 여러 고객을 공용 자격 증명 뒤에 묶는 서비스들입니다. 앱 안의 테넌트끼리 서로의 프롬프트를 조금도 알면 안 된다면, 회사가 캐시를 나누는 단위대로 테넌트를 나누는 게 좋습니다. 예를 들어 테넌트마다 Anthropic 워크스페이스를 따로 두는 식입니다. 아니면 테넌트 데이터를 캐시되는 앞부분에서 빼야 합니다.

그 밖에 알아 두면 좋은 것

• 캐시된 토큰도 OpenAI의 분당 토큰 한도에는 그대로 잡힙니다.
• Anthropic은 캐시 수명을 요청이 시작된 시점부터 잽니다. 생성에 4분이 걸렸다면 남은 시간은 1분뿐입니다. 5분짜리 캐시를 살리려면 다음 요청을 그 안에 시작해야 합니다.
• 읽을 때마다 타이머가 다시 맞춰집니다. 그래서 5분 안에 한 번씩 요청이 들어오면 5분짜리 캐시는 계속 살아 있습니다. 1시간짜리 옵션은 간격이 그보다 길 때만 이득입니다.
• 새 모델일수록 최소 길이가 줄어드는 것도 아닙니다. 3,000토큰짜리 프롬프트는 Claude Opus 5에서는 캐시됩니다. 하지만 Opus 4.6에서는 아무 경고 없이 캐시되지 않습니다.
• 캐시가 제대로 되는지는 사용량 필드로 확인합니다. Anthropic은 cache_read_input_tokens, OpenAI는 cached_tokens, DeepSeek은 prompt_cache_hit_tokens입니다. 같은 요청을 반복해도 0이라면 대개 프롬프트 앞쪽 어딘가가 매번 바뀌고 있다는 신호입니다.

참고: Anthropic 프롬프트 캐싱, OpenAI 프롬프트 캐싱, Gemini 컨텍스트 캐싱, Gemini 가격, DeepSeek 디스크 컨텍스트 캐싱, Claude Code 환경 변수, Gu 외, Auditing Prompt Caching in Language Model APIs.