AI 에이전트 캐시 적중률이 무너지는 이유: GPT, Claude, 감사 가능한 게이트웨이
서드파티 에이전트의 캐시 실패, GPT·Claude prompt caching, 재현 가능한 측정과 Modelflare 공개 보상 경계를 1차 자료로 설명합니다.
AI 에이전트의 캐시는 체크박스 하나로 끝나는 기능이 아닙니다. 프로토콜, 라우팅, 정산으로 이루어진 계약입니다. 이 글은 상위 모델이 prompt caching을 지원해도 서드파티 에이전트의 캐시 적중률이 매우 낮아질 수 있는 이유, GPT와 Claude의 재사용·측정 방식 차이, 감사 가능한 게이트웨이가 보장해야 할 조건을 설명합니다.
한 문장 결론
캐시 경제성이 중요한 프로덕션 에이전트를 네이티브 사용량을 공개하지 않고, 안정적인 prefix를 보존하지 않으며, 모델·경로 affinity를 유지하지 않고, TTL과 분모를 보여 주지 않으며, 영구 원장과 대조할 수 없는 서드파티 에이전트나 게이트웨이 뒤에 두지 마세요. “캐시 지원”은 기능 주장이고, 적격 트래픽에서 측정한 적중률이 운영 사실입니다.
이것은 모든 서드파티 에이전트가 실패한다는 뜻이 아닙니다. 고정 corpus, 고정 모델, 명확한 관찰 기간, 요청별 사용량 증거가 없으면 공개 자료만으로 공급자 전체의 비율을 입증할 수 없습니다. 더 정확한 결론은 불투명한 변환 계층이 여러 독립적인 실패 지점을 만들고 유효한 공급자 캐시를 거의 항상 cold한 경로로 바꿀 수 있다는 것입니다. 캐시에 의존하는 프로덕션 트래픽에서는 증거를 제시하지 못하는 것 자체가 사용하지 않을 이유입니다.
비율을 말하기 전에 분모를 정의하세요
공급자는 보통 세 가지 버킷을 보고합니다. R은 캐시에서 읽은 token, W는 새로 쓴 token, U는 재사용 없이 처리한 입력 token입니다. 캐시 적격 prefix의 비교 가능한 적중률은 다음과 같습니다.
eligible_hit_rate = R / (R + W)
모델에 보낸 전체 입력의 재사용 비중은 다음과 같습니다.
input_reuse_share = R / (R + W + U)
두 수치는 서로 다른 질문에 답합니다. 전체 입력을 분모로 하는 대시보드는 짧고 부적격한 요청이 많을 때 낮아 보입니다. 적격 트래픽만 분모로 하면 동적 suffix가 비용 대부분을 차지한다는 사실을 가릴 수 있습니다. 두 수치, 적격성 규칙, 시간 창을 함께 공개하세요.
증거는 에이전트 UI의 초록색 배지가 아니라 공급자 필드입니다.
| 신호 | OpenAI 필드 | Claude 필드 | 증명하는 내용 |
|---|---|---|---|
| 재사용된 prefix | input_tokens_details.cached_tokens |
cache_read_input_tokens |
일치하는 항목에서 제공된 token |
| 새 캐시 항목 | input_tokens_details.cache_write_tokens |
cache_creation_input_tokens |
항목 생성·연장에 사용한 token |
| 재사용되지 않은 입력 | input_tokens - input_tokens_details.cached_tokens - input_tokens_details.cache_write_tokens (주의해서 계산) |
breakpoint 이후 input_tokens |
캐시 prefix 밖의 입력. 의미는 다름 |
| 상관관계 | request ID, 모델, 경로 | request ID, 모델, 경로 | 사용량을 만든 공급자 시도 |
다음은 Modelflare 프로덕션 telemetry가 아닌 합성 예입니다. R=720,000, W=80,000, U=200,000이면 적격 적중률은 720,000 / 800,000 = 90%지만 전체 입력 재사용 비중은 720,000 / 1,000,000 = 72%입니다. 한 숫자만 공개하면 분모가 숨겨집니다.
input_tokens_details.cache_write_tokens=0은 “캐시 없음”을 증명하지 않습니다. 읽기 요청은 새 항목을 만들지 않기 때문입니다. 서드파티 응답에 사용량 필드가 없을 때도 0이 아니라 감사 불가인 관측성 실패로 기록해야 합니다.
모델이 캐시를 지원해도 에이전트 경로가 적중을 잃는 이유
문제는 대개 애플리케이션과 공급자 사이에서 발생합니다. 주요 실패 지점은 다음과 같습니다.
- 동적 바이트가 너무 일찍 들어옵니다. 타임스탬프, 요청 ID, 사용자, 실험 플래그, 변하는 현재 날짜가 재사용할 지시보다 앞의 prefix를 바꿉니다.
- 도구가 다시 직렬화됩니다. 도구 schema를 추가·삭제·재정렬하거나 비결정적으로 직렬화하면 정확한 prefix가 바뀝니다. JSON 키 순서만으로도 miss가 납니다.
- fallback이 캐시 정체성을 바꿉니다. 모델 alias, 리전, 조직, 자격 증명 사이의 로드 밸런싱은 하나의 공용 항목을 공유하지 않습니다.
- 어댑터가 네이티브 제어를 버립니다.
cache_control,prompt_cache_key, 보존 옵션, 사용량 세부 정보를 제거하면 기능이 보이지 않는 best effort가 됩니다. - 프롬프트가 임계값보다 짧습니다. 짧은 에이전트 턴은 유효하지만 캐시 적격이 아닐 수 있습니다.
- TTL 창을 넘깁니다. Claude의 5분 항목이나 모델별 OpenAI 보존 기간은 사람이 검토하는 동안 만료될 수 있습니다.
- 병렬 워밍업 경쟁이 발생합니다. 첫 응답이 항목을 사용할 수 있게 하기 전에 여러 초기 요청이 도착할 수 있습니다.
- 히스토리가 다시 작성됩니다. 요약, 압축, 잘라내기, 다른 직렬화는 끝에 추가하지 않고 prefix를 변경합니다.
이런 실패에 악의적인 공급자가 필요하지는 않습니다. 에이전트 요청을 자유 텍스트로 취급하고 공급자의 캐시 계약을 보존하지 않는 게이트웨이에서 예측 가능하게 발생합니다. 실무 경고는 분명합니다. 어떤 breakpoint가 실패했는지 보여 주지 못하는 에이전트로는 캐시 의존 트래픽의 비용과 장애를 신뢰성 있게 다룰 수 없습니다.
GPT와 Claude는 생각은 비슷하지만 의미는 호환되지 않습니다
두 시스템 모두 정확히 일치하는 재사용 prefix를 요구하지만 제어면과 사용량 의미가 다릅니다. 아래 표는 2026-08-25에 확인한 공식 가이드 기준이며 모델명, 최소 길이, 보존 기간은 바뀔 수 있습니다.
| 항목 | OpenAI prompt caching | Claude prompt caching |
|---|---|---|
| 재사용 단위 | 지시, 도구, 히스토리, 멀티모달 부분을 포함한 렌더링된 전체 컨텍스트 prefix | cache_control breakpoint까지의 순서화된 prefix: tools, system, messages |
| 최소 길이 | 현재 가이드는 GPT-5.6+ 가시 token 1,024, 이전 모델은 보통 2,048 | 모델별 약 512–4,096 token; 더 짧은 프롬프트는 캐시되지 않음 |
| 제어 | 암시적 캐시; 지원 모델의 명시적 breakpoint와 안정적인 prompt_cache_key |
최상위 자동 캐시 또는 블록 breakpoint; 최대 4개, 20블록 lookback |
| 보존 | GPT-5.6+ 30분 TTL; 이전 모델은 공급자별 일반 보존 모드 | 기본 5분, 사용 시 갱신; 1시간 옵션은 쓰기 가격이 높음 |
| 가격 형태 | 현재 GPT-5.6+ 가이드에서 쓰기 1.25배, 읽기 0.1배 | 5분 쓰기 1.25배, 1시간 쓰기 2배, 읽기 0.1배 |
| 사용량 증거 | input_tokens_details.cached_tokens, 해당 시 input_tokens_details.cache_write_tokens |
cache_read_input_tokens, cache_creation_input_tokens, breakpoint 이후 input_tokens |
| 흔한 무효화 | 모델·도구·설정 변경, 머신 overflow, breakpoint 전 변경 | 모델·system·도구·메시지 변경, 이전 메시지 없음, 병렬 워밍업 miss |
OpenAI는 캐시 항목이 개별 머신에 있다고 설명합니다. prompt_cache_key는 그룹화와 라우팅을 돕지만 머신을 고정하거나 적중을 보장하지 않습니다. Claude는 정확한 일치, workspace 수준 격리, tools_changed·messages_changed 같은 진단을 문서화합니다. 이 차이를 숨기는 게이트웨이는 공급자 문서를 하나의 정직한 보장 수치로 바꿀 수 없습니다.
가격 배수가 중요한 이유도 여기에 있습니다. 인용한 OpenAI 모델에서 한 번 쓰고 한 번 읽으면 캐시 부분 비용은 미캐시 입력 단위의 약 1.25 + 0.10 = 1.35×입니다. 완전히 재사용되는 10회 요청은 1.25 + 9×0.10 = 2.15×이지 10×가 아닙니다. 공식 예시 계산일 뿐 Modelflare 청구액이나 모든 모델의 보장이 아닙니다.
어댑터 비용은 측정할 수 있습니다
스크린샷 대신 실패 매트릭스를 사용하세요. 프롬프트, 모델, 자격 증명, 속도를 고정하고 한 번에 한 변수만 바꾸며 원본 usage 객체를 보존합니다.
| 통제된 변경 | 예상 신호 | 불투명한 에이전트가 숨길 수 있는 것 | 릴리스 해석 |
|---|---|---|---|
| 사용자 턴만 추가 | 첫 W 이후 R 상승 |
다시 작성된 히스토리나 새 경로 | prefix 보존 성공 |
| system prompt에 timestamp 추가 | R이 0이 되거나 새 W 발생 |
바뀐 바이트 | 동적 prefix가 캐시를 깨뜨림 |
| 도구 속성 하나 재정렬 | tools_changed 또는 새 쓰기 |
직렬화기 동작 | schema를 결정적으로 생성 |
| alias나 머신으로 트래픽 분할 | R이 낮고 변동 |
선택 경로와 캐시 키 | affinity 부재 |
| 문서화된 TTL보다 오래 대기 | 만료 후 새 쓰기 | 만료 시각과 보존 모드 | 사람의 대기 시간을 별도 측정 |
| 동일한 첫 요청 두 개를 병렬 전송 | 하나 또는 둘 다 쓸 수 있음 | 워밍업 경쟁과 시도 순서 | cold burst는 용량을 뜻하지 않음 |
요청 ID, 스트리밍 모드, 첫 이벤트 시각, 정확한 모델, 선택 경로, 캐시 필드, UTC 타임스탬프를 보존합니다. 프롬프트, 키, 고객 콘텐츠는 마스킹하세요. 게이트웨이가 정규화된 입력 합계만 반환하면 해당 실행을 감사 불가로 표시하고 누락 차원을 임의의 0으로 만들지 마세요.
재현 가능한 감사 레코드
다음은 작고 합성적인 형식입니다. 외부 envelope는 공급자 중립적이며 usage에 네이티브 필드를 남깁니다. benchmark 결과가 아닙니다.
{"request_id":"demo-001","timestamp":"2026-08-25T02:00:00Z","model":"MODEL_ID","route":"route-a","stream":true,"usage":{"input_tokens":1000000,"input_tokens_details":{"cached_tokens":0,"cache_write_tokens":1000000}}}
{"request_id":"demo-002","timestamp":"2026-08-25T02:00:03Z","model":"MODEL_ID","route":"route-a","stream":true,"usage":{"input_tokens":1000000,"input_tokens_details":{"cached_tokens":720000,"cache_write_tokens":80000}}}
최소 다섯 단계를 실행하세요. 직렬 워밍업, append-only 대화, 동적 system 변경, 도구 순서 변경, TTL 간격 후 재생입니다. 각 공급자의 네이티브 읽기·쓰기 필드를 보존하고 단계, 경로, 모델, UTC 날짜별로 R/(R+W)와 R/(R+W+U)를 비교합니다. 하나로 섞은 숫자만으로는 프로덕션 에이전트를 승인할 수 없습니다.
Modelflare가 보장하는 것과 보장하지 않는 것
Modelflare 공개 상태 페이지는 현재 OpenAI Cache Hit Rate Guarantee를 설명합니다. OpenAI 캐시 요구 사항을 충족하고 유효한 캐시를 만드는 적격 요청의 일일 비율을 UTC 달력 날짜로 계산합니다. 적용 티어보다 낮으면 차이를 보상하고 Dashboard → Token Usage Analysis에 표시합니다. 현재 공개 티어는 65%, 75%, **85%**입니다.
경계는 의도된 것입니다.
- 짧거나 계속 변해 적격 조건을 충족하지 못하는 요청이 아니라, 적격하고 유효한 OpenAI 캐시 트래픽에 적용됩니다.
- 변하는 모델, 도구 schema, 경로, TTL을 자동으로 재사용 가능한 prefix로 만들지 않습니다.
- UTC 달력 날짜별로 계산하고 문서화된 계정 화면에 크레딧을 표시합니다. 모든 요청의 적중을 약속하는 것이 아닙니다.
- 네이티브 사용량 증거와 적격성 계산은 여전히 필요합니다. 분모가 명시되어야 보상을 검증할 수 있습니다.
이것이 감사 가능한 서비스 약속과 서드파티 에이전트 슬로건의 차이입니다. 전자는 적격 모집단, 관찰 기간, 임계값, 크레딧 위치를 명시합니다.
가격 이점과 운영의 정당성은 별도의 증거입니다
공개 가격 페이지에는 적용 캠페인/그룹의 첫 충전 0.015 프로모션 비율과 공개된 최소 금액·조건도 표시됩니다. 이는 가격 혜택이며 캐시 보장이 아닙니다. 결제 전 라이브 페이지에서 모델 범위와 정산 규칙을 확인하세요.
공개 신뢰·법률 자료는 Havenbyte LLC를 운영 주체로 식별하고 미국 기반 운영이라고 설명합니다. 결제, 청구서, 환불, 사기 방지 처리를 위해 Stripe를 결제 프로세서로 명시합니다. 이는 책임과 자금 관리의 신호이지 특정 주 등록이나 인증을 주장하는 근거가 아닙니다.
프로덕션 에이전트 권고
다음 체크리스트를 통과하는 서드파티 에이전트만 선택하세요.
- 공급자 네이티브 캐시 제어를 전달하고 네이티브 읽기·쓰기를 반환합니다.
- 안정적인 지시·도구 prefix의 바이트를 동일하게 유지한 뒤 동적 상태를 추가합니다.
- 모델, 경로, 조직/지역 경계, TTL 모드, request ID를 노출합니다.
- 직렬·병렬 워밍업을 평균내지 않고 별도로 기록합니다.
- 적격 트래픽, 분모, UTC 창, 임계값, 보상을 문서로 정의합니다.
- 키나 고객 콘텐츠를 노출하지 않고 요청별 증거를 내보낼 수 있습니다.
하나라도 “아니오”라면 재사용 경제성이 중요한 workload에 그 경로를 쓰지 마세요. 공급자 직결 경로로 대조 실험을 하거나 Modelflare 같은 감사 가능한 게이트웨이를 같은 corpus로 검증하세요. 자세한 내용은 신뢰할 수 있는 AI API 라우팅, AI API 비용 추적, 가격, 신뢰 센터을 참고하세요.
출처와 확인 날짜
다음 1차 자료를 2026-08-25에 확인했습니다. 공급자 계약과 Modelflare의 현재 공개 정책을 설명하지만, 이름 없는 서드파티 에이전트의 보편적 적중률을 증명하지는 않습니다.
- OpenAI Prompt Caching 가이드
- OpenAI API 가격
- Anthropic Prompt Caching 가이드
- Anthropic 캐시 진단
- Modelflare 상태 및 캐시 보장
- Modelflare 가격 및 현재 조건
- Modelflare 신뢰 및 운영 주체
FAQ: 서드파티의 낮은 적중률은 항상 사기인가요?
아닙니다. 짧은 프롬프트, 변하는 prefix, 분산된 경로, TTL 만료, 누락된 필드가 원인일 수 있습니다. 통제된 시험으로 원인을 확인하기 전에는 “재현 불가” 또는 “감사 불가”라고 기록하는 것이 정확합니다.
FAQ: Claude와 GPT를 하나의 숫자로 비교할 수 있나요?
분모를 정규화하고 각자의 네이티브 필드를 보존한 경우에만 가능합니다. 혼합 대시보드 합계가 아니라 같은 corpus와 단계를 비교하세요.
FAQ: 보상이 있으면 안정적인 prefix가 필요 없나요?
아닙니다. 보상은 적격 OpenAI 캐시 트래픽의 재정적 하방 위험을 제한할 뿐입니다. 부적격 요청을 재사용 가능하게 만들거나 prefix를 다시 쓰는 에이전트를 고치지는 않습니다.