
에이전트 워크플로의 캐시 유지(Cache Keepalive) 비용이 8배나 과다하게 발생하는 이유 (v2: 인터벌 프런티어)
요약
에이전트 워크플로에서 프롬프트 캐시 유지를 위한 핑(ping) 간격이 관습적인 30초보다 훨씬 긴 약 4분이 적절함을 실험적으로 증명합니다. 제공업체별 캐시 만료 시점과 비용 효율성을 분석하여 최적의 캐시 유지 전략을 제시합니다.
핵심 포인트
- 30초 간격의 캐시 유지는 실제 필요보다 8배의 비용을 초과 발생시킴
- 최적의 캐시 유지 간격은 약 4분이며, 이는 제공업체별 정책에 따라 다름
- Anthropic과 OpenAI는 캐시 유지 시 비용 절감 효과가 뚜렷함
- DeepSeek과 Gemini는 캐시 유지 시 비용 절감 없이 지연 시간만 개선됨
- 일시 중단 시간이 캐시 수명보다 길면 캐시 재사용이 불가능함
캐시 유지(Cache Keepalive)는 모든 에이전트 빌더가 동의하는 단 하나의 최적화 방법이지만, 거의 모든 사람이 잘못된 설정으로 이를 실행하고 있습니다.
관습적으로는 30초마다 핑(ping)을 보냅니다. 하지만 그 관습은 필요 이상으로 8배 더 많은 비용을 발생시킵니다. 저는 자체적인 타이밍을 증명할 수 있는 하네스(harness)를 사용하여 Anthropic, OpenAI, Gemini, 그리고 DeepSeek 전반에 걸친 유지(keepalive) 경제성을 측정했으며, 그 결과는 저의 믿음 중 몇 가지를 재정립하게 했습니다. 적절한 간격(interval)은 30초가 아니라 약 4분입니다. 캐시 유지가 비용을 절감할 수 있는지 여부는 제공업체(provider)와 에이전트가 일시 중단되는 시간에 따라 달라지며, 두 가지 모두에 대한 명확한 규칙이 있습니다. 즉, 일시 중단 시간이 제공업체의 제거 시점(eviction point)보다는 길지만, 손익분기점(break-even horizon)보다는 짧을 때만 캐시를 따뜻하게(warm) 유지하십시오. 이 창(window) 안에서는 캐시 유지가 이득이 됩니다. Anthropic과 OpenAI에서는 실제로 돈을 아껴줍니다. DeepSeek과 Gemini에서는 오직 지연 시간(latency)만을 구매할 뿐입니다. 이 창을 벗어나면 순전한 낭비입니다.
캐시를 잡아먹는 일시 중단
제공업체의 프롬프트 캐시(prompt caches)는 API에서 가장 좋은 거래 중 하나입니다. 서버가 잠시 전에 처리한 접두사(prefix)를 보내면, 입력 가격의 약 10분의 1만 지불하고 대부분의 프리필(prefill) 지연 시간을 건너뛸 수 있습니다. 하지만 캐시는 몇 분 안에 만료되며, 에이전트 워크로드(agentic workloads)는 이를 사용하는 데 있어 최악의 사용자입니다. 에이전트는 생각하고, 행동하고, 기다립니다. 요청을 보내고, 빌드나 테스트 스위트를 실행하거나, 인간의 승인을 기다리며 10분 동안 머물다가, 그제서야 (이제는 커져 버린) 대화 접두사를 재사용할 수 있었던 후속 요청을 보냅니다. 일시 중단 시간이 캐시의 수명보다 깁니다. 후속 요청은 전체 가격과 전체 지연 시간을 지불해야 하며, 에이전트 규모에서는 이것이 실제 비용 항목이 됩니다.
그에 대한 방어책은 잘 알려져 있습니다. 일시 중단(pause) 시간 동안 타이머를 설정하여 정확히 동일한 접두사(prefix)를 다시 전송하는 것입니다. 매 읽기(read) 작업이 TTL(Time To Live)을 갱신합니다. Aider는 2024년에 이를 배포했고, Anthropic의 문서에서도 이를 권장하며, 커뮤니티 게시글들은 Anthropic의 비용 메커니즘을 분석하고 심지어 이론적으로 4분 간격의 인터벌(interval)을 산출해내기도 했습니다. 결과적으로 이러한 민간 전승(folklore)은 정답의 일부를 담고 있었습니다. 하지만 그들에게 부족했던 것은 측정(measurement)이었습니다. 위에서 언급한 모든 내용은 관행과 산술적 계산입니다. 아래의 모든 내용은 측정된 결과입니다: 4개의 제공업체(provider), 최대 40분에 달하는 유휴 간격(idle gaps), 최대 15분의 핑 인터벌(ping intervals), 3번의 독립적인 실행, 그리고 모든 호출에 대한 타임스탬프 기록을 포함합니다.
이 프로젝트가 시작된 배경에 공로를 돌리자면, Bellevue의 AgentSys 컨퍼런스 회의실에서 Haiying Shen과 Simon Peter가 코딩 에이전트를 위한 KV-캐시(KV-cache) 관리 연구인 CacheWise를 발표하는 것을 보았을 때입니다. 그들의 트레이스 분석(trace analysis)은 서빙(serving) 측면에서 위에서 언급한 문제를 정확히 보여줍니다. 즉, 에이전트 세션은 거대한 접두사(prefix)를 재사용하며, 단순한 제거(eviction) 방식은 이를 망가뜨린다는 것입니다. 그들의 질문은 서버가 에이전트를 위해 캐시를 어떻게 관리해야 하는가였지만, 저의 질문은 클라이언트가 스스로 이를 위해 무엇을 할 수 있는가로 바뀌었습니다. 캐시 유지(keepalive)는 클라이언트의 해답이며, 이 연구는 그 영감에 대한 저의 감사의 표시입니다.
각 캐시가 실제로 소멸하는 지점
캐시 유지(keepalive)를 할 가치가 있는지 알기 위해서는, 먼저 캐시가 스스로 소멸했을 때가 언제인지를 알아야 합니다. 그래서 저는 캐시 유지를 하지 않은 상태로 유휴 접두사(idle prefixes)를 방치하고, 최대 40분 동안의 웜 레이트(warm rate)를 측정했습니다.

이 곡선에서는 두 가지 사실이 도출되며, 두 가지 모두 중요합니다.
첫째: 문서화된 TTL (Time To Live)은 정확히 신뢰할 수 있는 수치이며, 그 이상은 기대할 수 없습니다. 문서화된 TTL 이전에는 아무것도 제거(evict)되지 않지만, TTL이 지난 후에도 유지가 보장되지는 않습니다. Anthropic의 캐시는 광고된 5분 TTL에 맞춰 유예 기간(grace period) 없이 5분에서 6분 사이에 급격히 떨어집니다. DeepSeek은 10분이면 사라집니다. OpenAI는 실제로 문서화된 510분보다 더 오래 지속되며, 20분에도 여전히 절반 정도의 웜 레이트(warm rate)를 유지하다가 30분이 되면 완전히 콜드(cold) 상태가 됩니다. 이는 즐거운 보너스이지만, 제공업체별 특성일 뿐 계획의 근거로 삼을 수는 없습니다. Google은 웜(warm)이나 콜드(cold) 상태로 수렴하지 않고, 모든 간격에서 3383%의 히트 레이트(hit rate)를 맴도는데, 이는 유지 곡선(retention curve)이라기보다 라우팅 복권(routing lottery)에 가깝습니다. 따라서 기본적으로 가정할 수 있는 유지 윈도우(retention window)는 사용 중인 플릿(fleet) 내에서 가장 짧은 문서화된 TTL에서 마진을 뺀 값입니다. 그보다 낮은 구간에서의 웜 상태는 제가 측정한 모든 곳에서 유지되었습니다. 그보다 높은 구간에서의 웜 상태는 운에 달려 있습니다.
둘째, 그리고 이 부분은 저의 이전 결론을 수정하게 만들었습니다: OpenAI는 지속력이 좋은 것이 아니라, 느린 것입니다. 제가 처음 10분 동안만 측정했을 때, OpenAI는 마치 캐시가 전혀 제거되지 않는 것처럼 보였습니다. 하지만 실제로 제거됩니다. 단지 제가 충분히 오래 기다리지 않았을 뿐입니다. 이 차이가 캐시 유지(keepalive)가 비용을 지불할 가치가 있는지를 결정하는 핵심이 됩니다.
캐시 유지(keepalive) 자체는 어디서나 작동하며, 이 부분은 의문의 여지가 없었습니다. 베이스라인(baseline)이 떨어지는 곳이라면 어디든, 캐시 유지(keepalive)는 동일한 프리픽스(prefix)를 웜(warm) 상태로 유지합니다.

이 글이 정말로 다루고자 하는 질문은 캐시 유지(keepalive)가 작동하느냐가 아닙니다. 그것을 위해 비용을 지불할 가치가 있느냐이며, 이는 전적으로 위에서 언급한 유지 곡선(retention curve) 상의 어느 지점에 위치하느냐에 달려 있습니다.
인터벌(Interval)이 게임의 전부입니다
다음은 캐시 유지(keepalive)의 전체 경제학이며, 이는 확정된 산술적 계산입니다:
핑(ping) 한 번은 매 인터벌 $\tau$마다 읽기 가격(read price, 입력가의 $\approx$10%)을 소모합니다. 접두사(prefix)를 유지하는 비용은 $\tau$당 $0.1\times$입니다. 재-프리필(re-prefill) 비용은 1회당 100%가 발생합니다 (캐시 쓰기 비용을 청구하는 Anthropic의 경우 125%). 따라서 시간당 지출은 $1/\tau$에 따라 감소하며, 인터벌은 안전성 외에는 아무것도 제공하지 않습니다. 최적의 인터벌은 제공업체의 유지 시간(retention)보다 안전하게 낮은 가장 큰 값입니다. Anthropic의 5분 TTL(Time To Live) 기준으로는 약 4분입니다. (이 점을 유념하세요. 마지막 섹션에서 "안전하게 낮은" 것이 어떤 가치를 지니는지, 그리고 그 선을 넘었을 때 어떤 일이 발생하는지 보여드립니다.) 손익분기점(Break-even)은 유휴 상태 $\approx \tau(w/r - 1)$입니다: Anthropic 가격 기준 약 46분, OpenAI 및 DeepSeek은 36분, Google은 12분입니다 (Google의 캐시된 읽기 비용은 $0.1\times$가 아닌 $0.25\times$입니다). 이 시간을 넘어서면 핑을 중단하십시오. 캐시가 만료되게 두고 재-프리필 비용을 지불하는 것이 낫습니다.
마지막 규칙은 반드시 내재화해야 할 규칙이며, 보험의 관점에서 다음과 같이 정리할 수 있습니다. 모든 핑은 단 한 번의 사고(claim), 즉 재-프리필을 피하기 위해 지불하는 보험료(premium)입니다. Anthropic에서 보험료는 입력 가격의 $0.1\times$이고 사고 비용은 $1.25\times$이므로, 사고 비용은 보험료의 약 12배 가치가 있습니다. 4분마다 보험료를 한 번씩 지불한다면, 약 11번의 지불 이후부터는 보험료 총액이 사고 비용을 초과하게 됩니다. 즉, 46분의 중단이 그 경계선입니다.
구체적으로, 100k 토큰의 Anthropic 접두사(표시 가격 기준 입력가 약 $0.30)를 예로 들면: 핑 한 번에 $0.03이 들고, 콜드 재-프리필(cold re-prefill)에는 $0.38이 듭니다.
10분 중단: 핑 두 번에 $0.06이 들며, $0.38을 아낄 수 있습니다. 캐시를 따뜻하게(warm) 유지하십시오. 6배 이득입니다. 46분 중단: 핑 11번에 $0.33이 들며, 이는 $0.38의 재-프리필 비용과 비슷합니다. 거의 본전입니다. 이것이 경계선입니다. 1시간 중단: $0.38의 재-프리필을 피하기 위해 핑 15번에 $0.45를 씁니다. 핑을 중단하십시오. 캐시가 차갑게(cold) 식도록 내버려 두고, 다시 돌아왔을 때 재-프리필 비용을 지불하십시오.
이 공식은 자신의 가격과 인터벌을 대입했을 때 본인만의 경계선이 어디인지 알려줍니다. 핵심은 경계선이 존재하며, 사람들이 생각하는 것보다 더 가깝다는 것입니다. 그리고 그 선을 넘었을 때 절제된 행동은, 결코 청구할 일도 없는 보험 정책에 보험료를 계속 지불하지 않는 것입니다.
모두가 복제하는 '30초 관행'은 약 6분의 손익분기점(break-even)을 가집니다. 이것이 바로 4개 제공업체 모두에서 10분의 간격이 발생할 때 손실이 발생하는 이유입니다. 저는 4분 단위의 실험군(arm)도 실행해 보았습니다. 핑(ping)은 +240.1초와 +480.1초에 발사되었고(0.1초 드리프트), 24개 샘플 중 23개를 따뜻한 상태(warm)로 유지했으며, 동일한 유지 성능 대비 30초 실험군보다 7.8배 적은 비용이 들었습니다. 이 관행은 신중한 것이 아닙니다. 그저 비싼 것뿐입니다.
| 600초 유휴(idle), 100k 프리픽스(prefix) | 그대로 방치 | 30초 캐시 유지(Keepalive) | 240초 캐시 유지(Keepalive) |
|---|---|---|---|
| Anthropic Sonnet 4.5 | $0.667 (cold) | $0.867 (손실 발생) | $0.414 (38% 절감) |
| ... | |||
| 마지막 열을 보십시오. 10분의 일시 중단 시 Anthropic과 DeepSeek만이 데이터가 축출(evict)되었으므로, 오직 그들만이 보험을 들 대상이 있으며, 그 경우에도 30초 관행은 손실을 봅니다. 이것이 제가 처음 게시했던 내용입니다. 10분 시점에서는 Anthropic만이 실제로 비용을 절감했습니다. 하지만 그것은 10분이라는 시간에 대한 사실이지, 제공업체에 대한 사실은 아니었습니다. OpenAI와 Gemini는 10분 시점에서도 여전히 따뜻한(warm) 상태였으므로, 당연히 그들을 따뜻하게 유지하는 것은 아무런 이득이 없었습니다. 흥미로운 질문은 그들이 축출된 이후에 어떤 일이 벌어지는가입니다. |
측정된 유료 구간 (The paying band)
그래서 저는 30분 일시 중단 시점에서 다시 실험을 진행했습니다. 유지 곡선(retention curve)에 따르면 Gemini를 제외한 모든 제공업체가 완전히 차가운(cold) 상태가 됩니다. 이제 이들 모두에서 피해야 할 재-프리필(re-prefill)이 발생합니다. 동일한 4분 캐시 유지, 동일한 100k 프리픽스를 적용했습니다.
| 1800초 유휴(idle), 100k 프리픽스(prefix) | 그대로 방치 | 240초 캐시 유지(Keepalive) | 판결 |
|---|---|---|---|
| Anthropic Sonnet 4.5 | $0.333 (cold, 2.9s TTFT) | $0.214 | 1.56배 절감 |
| ... | |||
| 결과가 나왔습니다. OpenAI가 실제로 축출(evict)되면, 그들의 캐시 유지 또한 비용을 절감해 줍니다. 캐시 유지는 결코 Anthropic 전용 기술이 아니었습니다. 일시 중단 시간이 축출에 도달할 만큼 충분히 길고, 손익분기점 아래로 유지될 만큼 충분히 짧다면 어떤 제공업체에서도 비용을 아껴줍니다. 각 제공업체에는 이 법칙이 적용되는 구간(band)이 있습니다. Anthropic은 약 5분에서 46분 사이이며, OpenAI는 약 30분부터 자체 최적 간격(다음 섹션 참조)을 통해 한 시간 이상까지 이어집니다. 이 구간을 벗어나면, 어느 쪽이든 아무런 이득 없이 프리미엄(비용)만 지불하게 됩니다. |
DeepSeek는 정직한 예외입니다. DeepSeek는 캐시를 제거(evict)하긴 하지만, 콜드 리프리필(cold re-prefill) 비용이 2센트이므로, 어떤 타이밍을 선택하더라도 핑(ping) 비용이 방지하려는 제거 비용보다 더 많이 듭니다. DeepSeek의 유지(keepalive)는 오직 지연 시간(latency)을 위한 전략입니다. 첫 토큰까지의 시간이 5.4초에서 2.0초로 단축됩니다. Gemini는 더 최악입니다. Gemini는 신뢰할 수 있게 캐시를 제거하지 않으며(그 히트율(hit rate)은 유지 곡선(retention curve)이 아닌 라우팅 복권(routing lottery)에 가깝습니다), 캐시된 읽기(cached reads) 비용이 0.1배가 아닌 0.25배이므로, 캐시를 따뜻하게 유지(keep warm)하는 것이 비용 측면에서 이득이 되는 일시 중단(pause) 길이는 존재하지 않습니다. 이 두 모델의 경우, 비용이 아닌 속도를 구매하려는 경우에만 캐시를 유지하십시오.
TTL을 넘어서면, 핑은 독이 된다
한 가지 질문이 남았으며, 이는 예리한 독자라면 다음에 던질 질문입니다. 만약 간격(interval)이 길어질수록 유지(keepalive) 비용이 감소한다면, 왜 4분에서 멈춰야 할까요? 그래서 저는 실험을 계속했습니다. 동일한 30분 일시 중단, 동일한 접두사(prefix), 그리고 4분, 8분, 15분의 핑 간격을 적용했습니다.

간격은 제공업체 자체의 유지(retention) 기간에 의해 제한되며, 차트는 그 경계선의 양면을 보여줍니다.
OpenAI의 캐시는 8분의 간격을 버텨내므로, 8분 간격의 핑은 비용을 다시 절반으로 줄입니다: 재프리필(re-prefill) 비용인 $0.104 대비 $0.042로, 4분 간격의 핑이 제공하는 것의 두 배인 2.45배의 절감 효과를 보입니다. OpenAI의 진정한 최적 간격은 4분이 아니라 약 8분입니다.
8분 간격의 핑을 사용하는 Anthropic은 재앙이며, 그 이유는 중요합니다. Anthropic의 캐시는 5분 만에 소멸하므로, 8분마다 보내는 모든 핑은 소멸된 캐시에 도달하여 전체 쓰기 가격으로 재프리필을 수행하게 됩니다. 세 번의 핑, 세 번의 전체 프리필이 발생하며, 타이밍이 우연히 맞지 않는 한 여전히 캐시를 따뜻하게 유지하는 데 실패합니다. 청구 금액은 $1.334로, 아예 핑을 보내지 않았을 때보다 4배나 높습니다. TTL을 넘어서는 간격은 단순히 낭비되는 것이 아닙니다. 모든 핑은 피하고자 했던 바로 그 페널티를 정확히 지불하게 됩니다.
15분 간격의 핑에서 살아남을 수 있는 곳은 아무도 없으며, 8분 간격의 DeepSeek는 동전 던지기 수준입니다(DeepSeek의 캐시는 약 9분 전후로 소멸합니다). 따라서 정교화된 규칙은 다음과 같습니다: 경제적인 간격은 제공업체별로 측정된 자체 유지(retention) 기간에서 마진을 뺀 값이며, 이는 제공업체마다 다릅니다. Anthropic은 4분, OpenAI는 8분입니다. 하나의 전역 핑 간격을 사용하는 멀티 제공업체 에이전트는 OpenAI에서 과다 지불을 하거나, Anthropic에서 돈을 태워버리고 있는 것입니다.
확정된 사실과 나의 믿음
확정된 사실: 위의 산술적 계산, 측정된 유지 곡선(retention curves), 측정된 7.8배의 차이, 손익분기점(break-even horizons), 그리고 독성 있는 가장자리(toxic edge)를 가진 인터벌 프런티어(interval frontier). 이들은 하네스(harness)를 통해 공개된 데이터를 통해 직접 확인할 수 있는 것들입니다.
믿음: 모든 사람이 이 조언을 따를 때 벌어질 일들. 캐시 계층(cache tier)의 방출 정책(eviction policy)은 예상 재사용률에 따라 순위를 매깁니다. 하지만 캐시 유지(keepalive)는 최신성(recency)을 인위적으로 만들어내며, 이로 인해 모든 클라이언트가 한 번씩 핑(ping)을 보내게 되면 LRU(Least Recently Used)는 더 이상 순위를 매길 대상이 남지 않게 되고, 결국 해당 계층은 모두에게 성능 저하를 일으킵니다. 현재의 체류(residency) 비용은 토큰 시간당(per token-hour) 보유 비용이 아니라 읽기(read)당 비용으로 책정되어 있습니다. 따라서 각 운영자의 합리적인 임대료 지불은 다른 모든 테넌트(tenant)에게 가격이 책정되지 않은 비용을 전가하게 됩니다. 나의 예측은 다음과 같습니다: 캐시 유지(keepalive)의 도입은 제공업체들이 체류(residency) 비용을 직접 계량화하도록 강제할 것입니다. Google의 명시적인 캐시(cache)는 이미 토큰 시간당 비용을 청구하고 있으며, 쓰기 비용의 2배를 부과하는 Anthropic의 1시간 계층(tier)도 같은 방향으로 나아가는 단계입니다. 차익 거래(arbitrage)는 실재하며, 이는 만료일이 있습니다.
정책
AI 자동 생성 콘텐츠
본 콘텐츠는 Lobste.rs AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기