A
COST / 비용
같은 입력을 더 싸게 읽습니다.
대표 예시: 캐시 히트 입력 단가가 일반 입력의 10%
FIELD GUIDE · 2026.08
REQUEST / 0042LIVE
01도구 정의고정
02시스템 지시고정
03참조 문서고정
CACHE BOUNDARY
04이번 질문변경
05최신 결과변경
앞은 그대로. 뒤에 새 정보만.
캐시 읽기 단가대표 예시 90%↓*
TTFT 연구 최대값31%↓†
핵심 원칙앞은 고정, 뒤는 변화
* GPT-5.6·Claude·Gemini 공식 가격의 대표 예시 · † 500개 에이전트 세션 arXiv 연구 최대값; 모델·전략에 따라 개선이 없거나 느려질 수 있음
01
원리 / THE MECHANISM
AI는 답을 기억하는 게 아니라,
같은 앞부분의 계산을 재사용합니다.
이 사이트가 다루는 프롬프트·컨텍스트 캐시는 답 자체를 기억하는 기능이 아닙니다. 모델이 답하기 전에 입력을 읽는 프리필 과정에서, 공급자가 앞부분에서 일치한다고 판정한 입력 계산을 재사용합니다. 캐시가 유효하면 새로 추가된 꼬리만 읽습니다.
01프리필
입력 전체를 읽고 계산 노트를 만듭니다.
02캐시 재사용
같은 앞부분의 계산을 건너뜁니다.
03디코드
답변을 한 토큰씩 생성합니다.
핵심
캐시는 주로 입력 프리필을 줄입니다. 출력 토큰 비용과 생성 속도는 별개입니다.
INTERACTIVE LAB 01
캐시를 직접 깨뜨려 보세요.
바뀐 위치에 따라 재사용 구간도 달라집니다.
SIMULATION좋은 흐름: 3/5
01도구 정의HIT
02시스템 지시HIT
03참조 문서HIT
04이번 질문NEW
05최신 결과NEW
앞부분 3개 블록을 그대로 재사용합니다.
일반적인 프리픽스 캐시에서는 변경 지점 뒤의 재사용 가능 구간이 줄어듭니다.
02
효과 / WHY IT MATTERS
비용, 속도, 작업량. 한 번의 히트가 세 가지를 바꿉니다.
캐시 조건과 혜택은 공급자·모델마다 다릅니다. 아래 90%는 여러 공식 가격에서 확인되는 대표 조건이며, 전체 요청 비용의 절감률은 아닙니다.
90%↓
B
SPEED / 속도
긴 프리필을 건너뛰어 첫 답이 빨라집니다.
효과는 프리픽스 길이와 인프라에 따라 달라집니다.
C
THROUGHPUT / 작업량
같은 예산과 시간으로 더 오래 일합니다.
예: Claude API는 대부분 모델에서 캐시 읽기 토큰을 ITPM 계산에서 제외합니다.
INTERACTIVE LAB 02
히트율만 보면 절반만 보는 겁니다.
아래 계산은 캐시 읽기 단가가 일반 입력의 10%인 단순 모델입니다. 쓰기·저장(TTL)·출력 비용은 제외했습니다.
RESULT / PER TURN
56K
전액 과금 토큰으로 환산한 턴당 유효 입력 부담
입력 비용 지수28 / 100
근사 절감률72%
98% HIT900K × 0.118 = 106.2K
VS
70% HIT50K × 0.37 = 18.5K
히트율이 더 높아도, 컨텍스트가 너무 크면 약 5.7배 무겁습니다.
CASE
우리의 Orca 사용 기록
ORCA HQ · 2026.07.20—07.27 · LOCAL USAGE LOG
우리가 직접 쓴 기록에서 캐시가 살아나는 패턴을 찾았습니다.
Orca가 로컬에 집계한 HQ 작업 기록 중 경로가 직접 확인되는 207개 세션을 분석했습니다. 아래 토큰은 공급자 응답의 usage 필드를 합산한 값이며, 비용은 청구 기록이 없어 추정하지 않았습니다.
- 관측 기간로그 측정
- 8일 7월 20–27일
- Orca 세션로그 측정
- 207 HQ 경로 직접 확인
- 기록된 응답로그 측정
- 12,554 usage가 기록된 모델 응답
- 사용 모델로그 측정
- 8 Claude·GLM·DeepSeek
WHAT THE LOG SHOWS
전체 입력 관련 토큰 중 캐시 읽기가 차지한 비율
총 22.01억 토큰 가운데 21.61억은 cache read, 3,882만은 cache write, 79.9만은 새 입력으로 기록됐습니다.
로그 측정cache read ÷ (read + write + fresh input)
캐시 읽기로그 측정
21.61억98.20%캐시 쓰기로그 측정
3,882만1.76%새 입력로그 측정
79.9만0.04%턴당 평균17.2만 cache-read tokens
높은 재사용률과 별개로 절대 컨텍스트가 큰 작업이었습니다.
THREE REAL RUNS
약 한 시간의 집중 실행에서 캐시 읽기가 수백 개 응답에 걸쳐 기록됐습니다.
모두 Claude Opus 5를 사용한 Orca 벤치마크 실행입니다. 로그 합계는 반올림했습니다.
01 · 운영 문서 검토OPSREV3
615턴
- 실행 시간
- 57분
- 캐시 읽기
- 1.371억
- 캐시 쓰기
- 29.8만
- 읽기 비율
- 99.78%
관측: 읽기가 쓰기보다 약 460배 컸습니다.
02 · 시나리오 검토SCENAREV
486턴
- 실행 시간
- 49분
- 캐시 읽기
- 1.102억
- 캐시 쓰기
- 29.2만
- 읽기 비율
- 99.73%
관측: 입력 관련 토큰 대부분이 재사용됐습니다.
03 · 장문 요약 검토LONGSUM4
425턴
- 실행 시간
- 48분
- 캐시 읽기
- 1.005억
- 캐시 쓰기
- 26.4만
- 읽기 비율
- 99.74%
관측: 장문 작업에서도 높은 재사용 비율이 나타났습니다.
우리가 확인한 핵심
세 실행 모두 같은 목적의 작업이 짧은 시간 안에 한 세션에서 연속됐습니다.
주의: 강한 상관 패턴이지만 개별 캐시 쓰기의 원인을 직접 분류하지는 않습니다.03
실전 / THE PLAYBOOK
앞은 얼리고, 뒤만 움직이세요.
캐시 최적화는 옵션 하나가 아니라 세션을 시작하고, 이어가고, 정리하는 방식의 문제입니다.
시작 전에 고정할 것을 정합니다.
- 영구 규칙과 참조 자료 정리
- 모델·MCP·도구 구성 확정
- 한 스레드에 하나의 작업
진행 중에는 변경분만 더합니다.
- 이번 질문과 최신 결과는 뒤에
- 큰 이미지·로그는 파일로 외부화
- 같은 작업은 가능한 한 연속 수행
무거워지면 과감히 정리합니다.
- 같은 작업은 맥락을 압축
- 작업이 바뀌면 새 스레드
- 히트율과 절대 토큰을 함께 점검
일반 챗봇 / PRESCRIPTION
주제별 스레드, 자료는 한 번만
- 01
프로젝트 설명과 자료를 초반에 한 번 정리합니다.
- 02
같은 작업은 같은 스레드에서 이어갑니다.
- 03
긴 문서는 변경분만 전달합니다.
CACHE & CONTEXT HABITS
이 습관이 재사용과 맥락 효율을 해칩니다.
- ×시스템 지시에 동적 값 넣기
- ×도구 목록과 순서를 자주 바꾸기
- ×같은 문서를 고쳐 다시 붙이기
- ×이미지와 원본 로그를 계속 쌓기
- ×서로 다른 작업을 한 스레드에 섞기
WHAT TO MEASURE
비율과 절대량을 함께 보세요.
01캐시 읽기 / 쓰기
히트가 실제로 일어나는가?
02턴당 총 입력
세션이 너무 무겁지 않은가?
03작업당 비용
결과 하나에 얼마를 쓰는가?
04TTFT
첫 답이 실제로 빨라졌는가?
보편적인 정답보다 내 워크로드의 기준선과 추세가 중요합니다.
04
GPT의 의견 / A MODEL'S TAKE
캐시 최적화는프롬프트 꼼수가 아니라정보 구조를 설계하는 일입니다.
히트율은 정보 위생의 유용한 지표지만 100%가 목표는 아닙니다. 변하지 않는 사실은 안정적으로 재사용하고 지금 필요한 정보만 새로 읽는 세션이 좋습니다.
OPTIMIZE IN THIS ORDER
- 01불필요한 맥락 제거
- 02안정 정보 고정
- 03작업별 스레드 분리
- 04히트율 측정
최신성이나 정확성과 충돌한다면 캐시보다 정확성을 먼저 선택해야 합니다.
05
세션 전 30초 체크
YOUR NEXT SESSION
시작하기 전, 여섯 가지만 확인하세요.
0 / 6
체크할수록 세션이 가벼워집니다.
ONE LINE TO REMEMBER
좋은 캐시 사용법 =
앞부분 안정성 × 컨텍스트 크기 관리 × 작업 리듬
수치와 공식은 어떻게 계산했나요?
근사 절감률 = 히트율 × (1 − 캐시 읽기 단가 / 일반 입력 단가). 읽기 단가가 10%라면 히트율 80%에서 입력 비용은 약 72% 줄어듭니다.
캐시는 모든 AI에서 똑같이 작동하나요?
아닙니다. TTL, 최소 길이, 할인율과 usage 필드는 공급자와 모델에 따라 다릅니다.
같은 채팅을 계속 쓰면 무조건 히트하나요?
보장되지 않습니다. 제공사 정책·TTL·내부 컨텍스트 관리에 따라 달라집니다.
팩트체크에 사용한 1차 출처
2026년 8월 13일 기준 공식 문서와 원 연구를 대조했습니다. Orca 수치는 로컬 usage 로그를 다시 집계했습니다.