프롬프트 캐싱 비용 계산, TTL 고르는 법과 API·vLLM 비교

LLM API 청구서를 열어 보면 입력 토큰이 출력보다 몇 배 많은 경우가 흔해요. 시스템 프롬프트, 도구 정의, 붙여 넣은 문서가 매 요청 다시 들어가기 때문이에요. 결론부터 말하면 공통 앞부분이 512~1,024토큰 이상이고 같은 앞부분이 5분(OpenAI 는 30분) 안에 두 번 이상 오면 프롬프트 캐싱은 켜는 게 맞아요. 간격이 그보다 길면 TTL 을 늘리되, 요청이 세 번 이상 모일 때만 이득이에요.

이 글은 캐싱의 내부 원리 대신, 실제로 켤 때 정해야 하는 것만 다뤄요. 어느 방식(Claude 명시형, OpenAI 자동형, 직접 띄운 vLLM·SGLang)을 쓸지, TTL 을 몇 분으로 할지, 얼마나 아끼는지를 2026년 10월 27일 공식 가격표로 직접 계산했어요.

프롬프트 캐싱 방식 네 가지 — 무엇을 직접 정해야 하나

캐싱이 붙는 위치에 따라 개발자가 손댈 수 있는 것이 달라요.

마지막 줄은 성격이 달라요. 프롬프트 캐싱은 입력 계산만 건너뛰고 답은 매번 새로 만들어요. 같은 질문에 같은 답을 돌려줘도 될 때만 응답 캐시를 따로 두세요.

Claude 프롬프트 캐싱 문서에 따르면 캐시는 tools → system → messages 순서로 쌓이고, 중단점에서 뒤로 최대 20블록까지 앞선 요청이 써 둔 항목을 찾아요. OpenAI 프롬프트 캐싱 안내는 GPT-5.6 이후 모델이 1,024토큰부터 캐시하고 기본 수명이 30분이라고 적어요. 그 이전 모델은 쓰기 요금이 없고 prompt_cache_retention 으로 in_memory(보통 5~10분)나 24h 를 고르는 방식이라, 쓰는 모델 세대부터 확인해야 해요.

2026년 10월 캐시 단가 — Claude·OpenAI 가격표 비교

Claude 가격표와 OpenAI 가격표의 표준 요금(100만 토큰당 달러)을 옮겼어요.

두 회사 모두 짧은 TTL 쓰기는 1.25배로 같아요. 차이는 TTL 길이예요. Claude 는 5분, OpenAI 는 30분이 기본이라 요청 간격이 5~30분인 서비스는 OpenAI 쪽이 별도 설정 없이 더 많이 적중해요. Claude Haiku 5.5 는 프롬프트가 10만 토큰을 넘으면 캐시 읽기를 포함한 모든 단가가 5배 구간으로 올라가요. 캐시로 읽은 토큰도 프롬프트 길이에 들어간다는 점을 놓치기 쉬워요.

손익분기 계산 — 몇 번 써야 캐시가 이득인가

같은 앞부분 P 토큰을 TTL 안에 N번 보낸다고 해요. 캐시가 없으면 N × P × 정가, 캐시를 쓰면 P × 정가 × (쓰기배수 + (N−1) × 읽기배수) 예요. 둘을 같게 놓으면 손익분기는 N > (쓰기배수 − 읽기배수) ÷ (1 − 읽기배수) 예요.

• 5분·30분 TTL, 읽기 0.05배: (1.25 − 0.05) ÷ 0.95 = 1.26 → 두 번째 요청부터 이득
• Claude 1시간 TTL, 읽기 0.05배: (2 − 0.05) ÷ 0.95 = 2.05 → 세 번째부터
• OpenAI 12시간 TTL, 읽기 0.05배: (2.5 − 0.05) ÷ 0.95 = 2.58 → 세 번째부터

아래는 캐시 없이 보낸 비용을 100으로 놓은 상대 비용이에요. 100 아래로 내려가는 지점이 손익분기예요.

읽기 배수가 0.1배인 Haiku 5.5·gpt-6-luna 는 10회 기준 17%가 아니라 21.5%라서 절감 폭이 조금 작아요. Fable 5.1(0.025배)은 반대로 14.75%까지 내려가요.

문서 질의응답 봇 예시 — 월 비용을 직접 계산하면

예시 가정이에요. 사내 매뉴얼을 붙인 Q&A 봇이 요청마다 앞부분 20,000토큰(도구 2,000 + 시스템 1,000 + 문서 17,000), 질문 200토큰, 답 500토큰을 쓰고, 하루 3,000건 × 22일 = 월 66,000건이에요. 업무 시간에 1분에 5건 넘게 들어오니 캐시는 대부분 따뜻하게 유지돼요. 그래도 서버 분산·문서 갱신 때문에 쓰기가 섞이므로 적중률을 95%와 80% 두 가지로 놓았어요.

Sonnet 5.5 로 풀어 보면, 캐시가 없으면 요청당 입력 20,200토큰 × 2달러 + 출력 500토큰 × 10달러 = 0.0454달러, 월 2,996달러예요. 적중 95%면 앞부분 2만 토큰의 평균 단가가 0.95 × 0.10 + 0.05 × 2.50 = 0.22달러로 떨어져 요청당 0.0098달러, 월 647달러가 돼요.

눈여겨볼 점은 캐시를 켠 뒤의 비용 구성이에요. Sonnet 5.5 기준 출력비 330달러가 그대로 남아서, 캐시를 켜면 전체의 51%가 출력이에요. 여기서 더 줄이려면 답 길이나 모델 선택을 봐야 하고, 캐싱을 더 만지는 효과는 작아요.

TTL 고르기 — 요청 간격이 비용을 뒤집는 경우

TTL 은 마지막으로 쓰거나 읽은 시점부터 다시 세요. 읽을 때마다 무료로 연장되니, 간격이 TTL 보다 짧게 계속 오면 짧은 TTL 로 충분해요. 문제는 간격이 TTL 보다 긴 경우예요.

예시 가정: 앞부분 2만 토큰, 20분마다 한 번, 8시간 동안 24번 오는 사내 보고서 도우미.

5분 TTL 은 매번 만료돼서 24번 모두 1.25배 쓰기 요금을 내고, 캐시가 없을 때(96센트)보다 비싼 120센트가 돼요. 1시간 TTL 로 바꾸면 첫 쓰기 8센트 + 읽기 23번 4.6센트로 12.6센트, 87% 줄어요. OpenAI 는 기본 30분이 20분 간격을 덮어서 설정 없이 9.6센트예요.

정리하면 이렇게 골라요.

Claude 에서 한 요청에 두 TTL 을 섞을 때는 1시간 항목이 5분 항목보다 앞에 와야 해요. 시스템 프롬프트는 1시간, 늘어나는 대화는 5분으로 두는 구성이 이 규칙에 맞아요.

대화형 서비스는 지연이 얼마나 줄어드나

API 회사들은 캐시 적중 시 첫 토큰까지 시간(TTFT)이 줄어든다고만 적고, 몇 밀리초인지는 공개하지 않아요. 그래서 시간 대신 매 턴 새로 읽어야 하는 토큰 수로 비교했어요. 시스템 프롬프트 3,000토큰에 턴마다 질문 150 + 답 350토큰이 쌓이는 20턴 대화예요.

캐시가 없으면 대화가 길어질수록 누적 계산량이 제곱에 가깝게 늘어요. 캐시가 매번 맞으면 각 턴은 직전 답과 새 질문 500토큰만 읽으면 돼서, 20턴 누적 기준 92%를 건너뛰어요. 긴 입력의 앞부분 처리(prefill)가 첫 토큰 지연의 대부분이라 체감도 이 방향으로 움직여요.

다만 vLLM 접두사 캐싱 기능 문서가 적듯 캐싱은 답을 한 토큰씩 만드는 시간은 줄이지 못해요. 답이 길어서 생성 시간이 대부분인 서비스는 캐시를 켜도 전체 응답 시간은 크게 안 변해요.

직접 서빙 — vLLM 과 SGLang 중 무엇을 볼까

모델을 직접 띄우면 캐시 요금이 없어요. 대신 비용이 GPU 메모리와 라우팅으로 옮겨 가요.

• vLLM: enable_prefix_caching=True 로 켜요. vLLM 접두사 캐싱 설계 문서에 따르면 다 쓴 KV 블록은 바로 지우지 않고 빈 블록 목록에 남겨 두었다가, 새 블록이 필요할 때 가장 오래 안 쓴 것부터 내줘요. 캐시 때문에 메모리를 따로 떼어 두는 게 아니라 남는 KV 공간을 재활용하는 구조라, 동시 요청이 많아 KV 공간이 빠듯하면 캐시가 먼저 밀려나요. KV 용량을 잡는 법은 vLLM KV 캐시 용량 계산 글을 참고하세요.
• SGLang: LMSYS 의 SGLang 소개 글에 따르면 RadixAttention 이 요청 사이 KV 를 트리에 보관하고, LRU 퇴출에 캐시를 고려한 스케줄링을 더해 적중률을 높여요. SGLang 논문은 기존 시스템보다 처리량이 최대 6.4배 높았다고 보고하는데, 런타임 전체 최적화의 결과라 캐싱만의 몫으로 읽으면 안 돼요.

공통 시스템 프롬프트에 질문만 바뀌는 구조라면 이미 쓰는 엔진에서 켜기만 하면 돼요. 퓨샷 예시나 에이전트 단계처럼 앞부분이 나무 모양으로 갈라지는 요청이 많다면 SGLang 의 트리 방식이 유리할 수 있으니 자기 트래픽으로 재 보세요.

엔진보다 더 큰 변수는 복제본 수예요. KV 캐시는 각 GPU 메모리에 있어서, 서버가 4대인데 요청을 무작위로 나누면 같은 앞부분이 네 군데에서 따로 쓰여요. 앞부분 해시나 대화 ID 를 기준으로 같은 서버에 보내는 라우팅을 두어야 해요. 여러 고객사가 한 서버를 쓴다면 vLLM 의 cache_salt 로 신뢰 그룹을 나누세요. 응답 시간 차이로 다른 고객의 입력을 추측하는 공격을 막는 기능이고, 점검 항목은 KV 캐시 격리 점검표 글에 정리돼 있어요. 해시 함수는 기본값 sha256 을 유지하고, 더 빠른 xxhash 는 멀티테넌트 환경이라면 충돌 위험을 따져 본 뒤에만 바꾸는 것이 문서의 권고예요.

캐시 적중률이 낮을 때 흔한 원인

• 최소 길이 미달. Claude 최신 모델은 512토큰, OpenAI GPT-5.6 이후는 1,024토큰 미만이면 조용히 캐시하지 않아요. 짧은 시스템 프롬프트에 캐시를 달아도 아무 변화가 없는 이유예요.
• 앞부분에 섞인 변동 값. 날짜·시각, 사용자 이름, 요청 ID, A/B 실험 문구가 문서보다 앞에 있으면 그 뒤가 전부 새로 계산돼요. 변하는 값은 마지막 중단점 뒤로 옮겨요.
• 도구 목록이 요청마다 다름. Claude 문서에 따르면 도구 이름·설명·파라미터가 바뀌면 도구·시스템·대화 캐시가 모두 무효예요. 사용자 권한별로 도구를 넣고 빼면 권한 조합 수만큼 캐시가 갈라져요. 도구는 고정해 두고 권한은 실행 단계에서 막는 편이 캐시에 유리해요.
• 설정값이 중간에 바뀜. Claude 에서는 tool_choice, output_config.effort, thinking 설정이 바뀌어도 대화 부분 캐시가 깨져요. 요청마다 effort 를 바꾸는 라우터라면 이 비용을 계산에 넣어요.
• 대화가 길어져 중단점이 밀림. Claude 는 중단점에서 20블록까지만 거슬러 찾아요. 한 턴에 블록이 20개 넘게 붙는 에이전트는 시스템 프롬프트 끝에 고정 중단점을 하나 더 두세요.
• 직렬화가 매번 다름. JSON 키 순서나 공백이 달라지면 같은 내용도 다른 토큰이에요. 적중이 안 되는 두 요청의 원문을 저장해 텍스트 비교 도구나 JSON 비교 도구로 diff 하면 어느 줄에서 갈라졌는지 바로 보여요.

도입 체크리스트

켜기 전

• 요청 로그에서 공통 앞부분 길이와 같은 앞부분이 다시 오는 간격 분포를 뽑았다.
• 앞부분이 모델별 최소 길이(512·1,024토큰)를 넘는다.
• 프롬프트 조립 순서를 도구 → 시스템 → 고정 문서 → 대화 → 새 입력으로 정리했다.
• 날짜·사용자 정보·요청 ID 를 마지막 중단점 뒤로 옮겼다.
• 위의 손익분기 식으로 TTL 별 예상 비용을 계산했다.

켠 뒤

• Claude 는 cache_read_input_tokens·cache_creation_input_tokens, OpenAI 는 usage.input_tokens_details.cached_tokens 를 로그에 남긴다.
• 적중률 = 캐시 읽기 토큰 ÷ 전체 입력 토큰을 대시보드에 띄우고, 배포 전후로 비교한다.
• 쓰기 토큰이 읽기 토큰보다 많은 경로가 있으면 TTL 이나 중단점 위치를 다시 본다.
• 도구·시스템 프롬프트를 바꾸는 배포 직후에는 한동안 쓰기가 몰린다는 것을 비용 예측에 넣는다.

직접 서빙이라면

• 접두사 캐싱 옵션이 켜졌는지 시작 로그로 확인했다.
• 복제본이 둘 이상이면 접두사·세션 기준 라우팅을 둔다.
• 고객사가 여럿이면 cache_salt 로 그룹을 나눴다.

토큰 수 자체를 어림하려면 한국어 LLM 토큰 비용 글의 1,000자당 토큰 표를 같이 보면 편해요.

자주 묻는 질문

프롬프트 캐싱을 켜면 답변 품질이 달라지나요?

달라지지 않아요. 앞부분을 읽은 중간 결과만 재사용하고 답은 매번 새로 생성해요. vLLM 설계 문서도 캐싱이 모델 출력을 바꾸지 않는다고 적어요. 같은 질문에 답이 달라지는 건 샘플링 때문이고 캐싱과는 무관해요.

Claude 에서 5분과 1시간 TTL 중 무엇이 기본으로 좋나요?

같은 앞부분이 5분 안에 계속 다시 오면 5분이 맞아요. 읽을 때마다 무료로 연장되니 1시간을 고를 이유가 없어요. 간격이 5분을 넘고 1시간 안에 세 번 이상 온다면 1시간이 싸요. 20분 간격 예시에서 5분 TTL 은 캐시 없을 때보다 25% 비쌌어요.

캐시가 걸렸는지 어떻게 확인하나요?

Claude 는 cache_read_input_tokens, OpenAI 는 cached_tokens 를 봐요. 두 번째 요청에서도 0이면 최소 길이 미달이거나 앞부분이 매번 바뀌는 거예요.

OpenAI 는 자동인데 따로 할 일이 있나요?

GPT-5.6 이후 모델은 기본 30분 TTL 로 알아서 캐시하지만, 앞부분을 고정하는 일은 똑같이 개발자 몫이에요. 하루 몇 번만 쓰는 긴 참고 자료는 12시간 TTL 을, 바뀌는 내용이 앞에 끼어 쓰기 요금만 나가는 경로는 명시 중단점으로 범위를 좁히는 것을 검토하세요.

직접 띄운 vLLM 에서도 캐싱이 비용을 줄이나요?

요금은 없지만 같은 GPU 로 더 많은 요청을 처리해 결국 GPU 대수를 줄여요. 공통 앞부분이 길고 답이 짧을수록 효과가 커요. 복제본이 여럿이면 라우팅부터 손보세요.

정리

• 손익분기는 단순해요. 짧은 TTL(쓰기 1.25배)은 두 번째, 긴 TTL(쓰기 2~2.5배)은 세 번째 요청부터 이득이에요.
• 2만 토큰 앞부분을 쓰는 봇은 적중률 95%에서 전체 비용이 약 78% 줄고, 그 뒤로는 출력비가 절반을 넘어요.
• TTL 은 요청 간격으로 고르고, 간격보다 짧은 TTL 은 캐시가 없을 때보다 비싸질 수 있어요.
• 직접 서빙은 엔진보다 라우팅과 테넌트 분리가 적중률과 안전을 정해요.
• 켠 뒤에는 사용량 필드로 적중률을 재고, 깨지면 두 요청을 텍스트 비교로 맞대어 보세요.

더 깊이 읽기

이 글은 실무에서 판단할 때 필요한 것 위주로 정리했어요. 같은 주제의 내부 동작 원리는 devboi 기술 블로그의 프롬프트 캐싱 원리 — KV 캐시 접두사 재사용과 vLLM·SGLang에서 도식과 코드로 단계별로 풀었어요.