오픈 웨이트 LLM 캐싱: 왜 제공업체 선택에 따라 복불복이 되는가

폐쇄형 모델의 프롬프트 캐싱은 하나의 문서화된 계약으로 보면 된다. Claude는 cache_control 중단점을 제공하고, OpenAI와 Gemini는 일정 token 수를 넘으면 자동으로 캐싱한다. 할인율도 공개돼 있고 안정적이다. 문서 한 페이지만 읽으면 끝이다.

오픈 웨이트에서는 이 전제가 깨진다. 같은 Qwen이나 Llama 체크포인트를 수십 개 호스트가 제공하며, 캐싱은 모델의 속성이 아니라 모델이 실행되는 환경의 속성이다. 실제 차이가 얼마나 큰지 실측 요청 하나로 살펴보자. 멀티 제공업체 router를 통해 같은 Qwen 모델에 동일한 약 4.7K-token prompt를 6번 보냈고, upstream은 고정하지 않았다.

모델도, router도, prompt도 같았지만 비용은 $0.0141에서 $0.000286까지 49배 차이가 났다. router가 어느 upstream을 선택했는지, 그리고 그 upstream에 해당 prefix가 warm 상태였는지만으로 생긴 차이다.

요약

• 오픈 웨이트 모델의 프롬프트 캐싱은 모델 기능이 아니라 라우팅 결과다. 추론 엔진에서 무료로 자동 구현되며, 그 위의 각 레이어가 캐시를 유지하거나 깨뜨린다.
• 5개 레이어 중 캐싱을 제공하는 곳은 하나고, 깨뜨릴 수 있는 곳은 셋이다. 모델(캐시 가능성을 결정하지만 캐시를 제공하지 않음) → 추론 엔진(무료 캐싱) → 컴퓨팅 호스트(일관성 없이 상품화) → gateway(멀티 클러스터 라우팅) → router(서로 캐시를 공유하지 않는 여러 업체로 분산).
• 실측 결과다. router가 분산한 동일 요청은 선택된 upstream에 따라 비용이 49배까지 벌어졌다. 같은 모델에서도 한 호스트는 59.6% 할인, 다른 호스트는 0% 할인이었다. 공개된 캐시 할인율은 모델에 따라 **0%에서 약 98%**까지 차이 난다.
• 대응 방법도 명확하다. 반복되는 prefix가 같은 warm cache에 도달하도록 경로를 고정해야 한다. 실제 hit에서도 cached_tokens가 0으로 표시되는 경우가 많으므로, 이 필드가 아니라 비용 차이로 검증하라. latency는 비용과 별도로 판단해야 한다. 비용 할인이 약 0%여도 warm prefill은 2–10배 빠르다.

실시간 수치는 2026-06-14에 멀티 제공업체 router와 자체 gateway를 대상으로 측정했다. 약 4.7K-token의 고정된 영어 prompt와 작은 max_tokens를 사용해 순차 실행했다. 공개 가격은 같은 날 제공업체의 1차 문서로 확인한 뒤 반대 관점에서도 교차 검증했다. 환경이 달라도 적용하기 쉬운 값은 절대 비용이 아니라 비율(할인율, latency 변화)이다. 실제 비용은 사용처, prompt, 부하에 따라 달라진다. 인용하기 전에 직접 재현하라.

실제로 접하게 될 캐시 유형

스택을 살펴보기 전에 용어부터 정리하자. 오픈 웨이트 호스트에서는 서로 다른 4가지 형태의 캐시를 볼 수 있으며, 과금 방식도 각각 다르다.

1. 자동 prefix 캐싱(marker 없음). 가장 일반적인 방식이다. 서버가 prompt prefix를 hash하고, 이전 요청과 일치하면 KV 상태를 재사용한 뒤 자동으로 할인을 적용한다. cache_control도 코드 변경도 필요 없고, 비활성화할 수 없는 경우도 많다. DeepSeek, Zhipu GLM을 비롯한 대부분의 오픈 웨이트 호스트가 이 방식을 쓴다. 쓰기는 무료다. 캐시 수명은 VRAM의 수 분부터 disk까지 다양하며, DeepSeek는 prefix를 “몇 시간에서 며칠” 동안 유지한다.

2. 명시적 중단점 캐싱(cache_control). Anthropic이 사용하는 방식이며 일부 오픈 웨이트 호스트도 제공한다. Alibaba Model Studio에서는 Qwen message block에 "cache_control": {"type": "ephemeral"}을 지정할 수 있다. 일부 serving 플랫폼도 같은 역할의 marker를 제공한다. 경계를 직접 표시하고 쓰기 추가 요금을 내는 대신, 읽을 때 더 큰 할인을 받는다.

3. 임대형 캐시 객체(storage 요금 부과). 특히 주의해야 할 방식이다. Moonshot의 기존 moonshot-v1 제품군은 POST /v1/caching으로 캐시를 생성해야 한다. 이후 쓰기 요금, token당 분 단위 storage 요금, 호출별 hit 요금이 청구된다. Google의 명시적 Gemini 캐싱도 같은 개념이다. input 비용에 더해 1M-tokens당 시간당 약 $1.00–$4.50의 storage 비용이 든다. 캐시는 임대하는 리소스이므로 직접 garbage collection해야 한다.

4. 자체 호스팅 KV 재사용(무료). 직접 웨이트를 실행하면 추론 엔진이 자동으로 무료 캐싱한다. 쓰기 요금, 읽기 요금, storage 임대료가 모두 없다. hit가 발생하면 prefill만 생략한다.

Model Studio의 Qwen은 자동 모드와 명시적 모드를 모두 제공하며, 두 방식의 장단점이 뚜렷하다. 암묵적 모드의 hit 비용은 **input의 20%**이고 쓰기는 무료다. 명시적 모드는 hit 비용이 **input의 10%**지만 쓰기 시 125%의 요금을 부과하며, 항목의 TTL은 5분으로 제한된다. 할인율은 더 높지만 캐시를 채울 때 비용이 들고, 만료될 때마다 다시 비용을 내야 한다.

캐싱은 스택의 어디에 있는가

핵심은 간단하다. 오픈 웨이트의 프롬프트 캐싱은 정확히 한 레이어에서 해결돼 있고, 그 위의 모든 레이어에서 위험해진다. 웨이트부터 위쪽으로 스택을 따라가며 각 레이어가 캐싱을 제공하는지, 아니면 단순히 전달하는지 확인해야 한다. 아래 레이어에서 이미 처리한 캐싱을 깨뜨릴 수 있는지도 봐야 한다.

  request
     |
     v
  +--------------------------------------------------+
  | L5  router             scatters across vendors   |  can break it
  | L4  gateway            multi-cluster routing     |  can break it
  | L3  compute host       uneven delivery           |  can break it
  |==================================================|
  | L2  inference engine   CACHING LIVES HERE, free  |  <-- the cache is born here
  |==================================================|
  | L1  model              cacheability: MLA / GQA   |  sets the ceiling
  +--------------------------------------------------+

  A cache hit is born at L2 and must survive L3-L5 routing to reach you;
  every layer above L2 is a chance to land where your prefix isn't.

레이어 1 — 모델: 캐시가 아니라 캐시 가능성

대부분은 캐싱이 이 레이어에 있다고 생각한다. “DeepSeek는 캐싱을 지원한다”는 식이다. 그래서 가장 먼저 정확히 구분해야 한다. 체크포인트는 웨이트 묶음이다. KV cache가 있든 없든 같은 attention을 실행한다. 캐시, 할인, TTL, cache_control marker는 체크포인트에 포함되지 않는다. 모두 serving 레이어의 기능이다. 엄밀히 말해 웨이트는 캐싱 상품을 제공하지 않는다.

그렇다고 웨이트가 아무 영향도 주지 않는 것은 아니다. DeepSeek가 이를 잘 보여준다. 모델의 attention 아키텍처는 KV cache 크기를 결정하며, 결과적으로 캐싱 비용을 얼마나 낮출 수 있는지 결정한다.

• DeepSeek의 **Multi-head Latent Attention (MLA)**은 KV cache를 low-rank latent로 압축해 표준 multi-head cache의 약 4–14% 수준으로 줄인다. 이 압축 덕분에 DeepSeek API는 prefix를 disk에 유지하고 캐시 읽기 비용을 input의 약 2%로 책정할 수 있다. 아키텍처는 이를 가능하게 하는 기반이고, disk cache는 그 위에 구축된 상품이다.
• Llama, Qwen, Mistral, DeepSeek가 사용하는 **Grouped-Query Attention (GQA)**은 KV head를 공유해 cache를 group factor만큼 줄인다. Llama-3에서는 약 8배다.

레이어 1이 제공하는 것은 캐시가 아니라 캐시 가능성이다. 아키텍처는 상위 레이어가 캐싱 비용을 얼마나 낮출 수 있는지 한계를 정하지만, 웨이트 자체는 캐시된 token을 제공하지 않는다. “DeepSeek는 캐싱을 지원한다”는 표현은 같은 이름으로 불리는 서로 다른 두 가지를 은근히 합쳐 놓는다. 하나는 이 레이어의 웨이트이며 MLA를 제공한다. 다른 하나는 레이어 2–3의 DeepSeek API와 serving stack이며 disk cache, 할인, usage 필드를 제공한다. 오픈 웨이트를 내려받아 직접 실행하면 MLA의 작은 KV cache는 그대로 쓸 수 있다. 하지만 disk-cache 상품은 DeepSeek 서버에 남는다. 대신 직접 배포한 레이어 2의 특성을 따르게 된다. 운영 관점의 결론은 그대로다. 모델이 캐싱하는지를 묻지 말고 어디에서 serving되는지를 물어야 한다. 그렇다고 아키텍처가 중요하지 않다는 뜻은 아니다. 아키텍처가 한계를 정하고, 요청 경로가 실제 결과를 정한다.

레이어 2 — 추론 엔진: 캐싱이 무료로 구현되는 곳

한 레이어 위에서는 캐싱이 단순히 존재하는 수준이 아니다. 이미 무료로 해결돼 있다. 최신 추론 엔진은 prefix를 자동으로 캐싱한다.

• vLLM — Automatic Prefix Caching: 각 KV block을 hash하고, 이전에 본 prefix hash와 일치하는 block을 재사용하며, LRU 방식으로 제거한다. V1에서는 기본 활성화돼 있다.
• SGLang — RadixAttention: KV cache를 radix tree에 저장해 공유 prefix를 모두 재사용하고, cache-aware scheduling을 적용한다.
• TensorRT-LLM — block 재사용(enable_block_reuse, 기본 활성화)을 지원하며, KV block을 host memory로 offload할 수도 있다.

LMCache 같은 프로젝트는 여기서 더 나아간다. KV를 CPU나 disk로 offload하고 여러 instance가 공유하게 한다. 앞으로 다룰 라우팅 문제를 해결하기 위한 출발점이다. 직접 호스팅한다면 여기서 끝이다. 캐싱은 자동이며 이미 운영 중인 GPU 외에는 추가 비용이 없다. LRU 방식으로 제거되고, 캐시의 소유권도 직접 가진다. hit가 발생하면 prefill을 생략하므로 TTFT가 줄고 throughput이 높아진다. 과금하지 않으므로 cached_tokens billing 필드도 없다. 효과는 자체 latency metric에서 확인할 수 있다. 폐쇄형 모델에서는 캐싱을 빌리지만, 오픈 모델에서는 직접 소유할 수 있다. 대신 호스팅 환경과 정반대의 제약이 있다. 캐시는 일시적이며 VRAM과 LRU에 의존한다. prefix가 hot 상태로 유지되는 동안에만 살아남는다. 바로 이 상태를 상위 레이어에서 보존해야 한다.

레이어 3 — 컴퓨팅 호스트: 일관성 없는 상품화

상용 추론 호스트는 레이어 2를 감싸고 여러 replica로 구성된 fleet을 운영한다. 무료 자동 캐싱을 그대로 물려받지만, 이를 얼마나 잘 구현하는지는 별개다. 두 측면 모두 결과가 제각각이다.

첫째, 노출 방식과 가격 차이가 매우 크다. 주요 오픈 웨이트 호스트를 보면 한 곳은 캐시된 input에 일률적으로 50% 할인을 적용하고, 캐시된 token을 rate limit 계산에서 제외한다. 다른 곳은 serverless에서 기본 50% 할인을 적용한다. 또 다른 곳은 모델별로 캐시된 input 가격을 다르게 책정하고, 예를 들어 Qwen 등급에는 약 80% 할인을 적용한다. affinity를 높이기 위한 cache-key hint도 노출한다. 네 번째 호스트는 dedicated endpoint에서 캐싱을 항상 활성화하지만 이를 공개하지 않는다. 기반 엔진은 같은데 가격 정책은 네 가지다.

둘째, 캐싱이 처음으로 깨지는 지점인 멀티 replica 문제가 있다. warm prefix는 cold 요청을 처리한 특정 replica의 VRAM에 있다. 호스트 내부 load balancer가 다음 요청을 cold cache 상태인 다른 replica로 보낼 수 있다. 실제 측정에서도 그대로 나타났다. 동일한 Qwen 모델을 upstream별로 고정하고 cold→warm 요청을 실행했다.

Provider A는 정상적으로 캐싱했고 결과도 보고했다. Provider B는 이 모델의 캐시 읽기 가격을 홍보하고 있지만, 테스트한 cold 호출 1번과 warm 호출 2번에서 할인이 전혀 적용되지 않았다. eligibility 문제인지, 여러 replica로 분산됐기 때문인지, 두 요청보다 긴 warm-up이 필요한지는 알 수 없다. 이 경로에서 실측한 결과는 0이었다. 캐싱 기능 자체는 레이어 2에서 해결돼 있다. 실제로 혜택을 받을 수 있는지는 레이어 3의 구현에 달려 있으며 호스트마다 다르다.

레이어 4 — Gateway: 멀티 클러스터 문제

Gateway는 하나 이상의 upstream 앞에 위치하며, replica 문제를 클러스터 문제로 키운다. cache affinity 없이 여러 클러스터나 제공업체로 요청을 round-robin하면 warm cache에는 구조적으로 접근할 수 없다. 요청할 때마다 해당 prefix가 없는 곳에 도착하기 때문이다. Cache-aware gateway는 prefix hash를 기준으로 라우팅해 동일한 prefix가 같은 upstream에 계속 전달되도록 해야 한다. 이는 레이어 2가 동일한 KV block에 요청을 붙이는 방식과 같다. LiteLLM처럼 직접 운영하는 소프트웨어든 hosted service든 원칙은 같다. 운영상의 장단점은 LiteLLM과 관리형 gateway 비교에 정리돼 있다.

서드파티 gateway에서 오픈 웨이트 모델을 대상으로 cold→warm 테스트를 실행하고, 요청별 cost를 직접 확인했다.

DeepSeek-V4는 97–99%의 할인율을 기록했다. affinity가 전체 경로에서 제대로 동작한 것이다. 반면 qwen3.5-plus와 qwen3-max는 catalog에 캐시 읽기 가격이 있는데도 warm 호출에서 할인율이 약 0%였다. 이 표에서는 gateway에 관한 교훈을 두 가지 더 확인할 수 있다.

• Usage 필드는 거짓말할 수 있지만 비용은 그렇지 않다. 99%의 비용 감소가 발생한 요청까지 포함해 여기서는 모든 호출의 cached_tokens가 0이었다. OpenAI 호환 gateway 중에는 자동 캐싱하는 upstream의 캐시 token 필드를 채우지 않는 경우가 많다. token 필드가 아니라 cold 호출과 warm 호출의 cost 차이로 검증해야 한다. gateway의 캐시 지원 주장을 검증할 때도 같은 원칙이 적용된다.
• 비용이 줄지 않아도 latency는 개선된다. 모든 warm 호출이 2–10배 빨랐다. 할인율이 약 0%인 요청을 포함해 qwen3.5-flash는 10.2s→1.0s로 줄었다. 호스트가 어떤 가격을 적용하든 hit가 발생하면 prefill을 생략한다. 따라서 청구 비용을 전혀 할인해 주지 않는 gateway에서도 캐싱으로 TTFT를 개선할 수 있다.

Affinity를 유지하지 않는 gateway는 접근할 수 없는 캐시를 제공한다. 캐시 비용을 노출하지 않는 gateway는 검증할 수 없는 캐시를 제공한다.

레이어 5 — Router: 여러 제공업체로 무작위 분산

가장 위에서는 멀티 제공업체 router가 하나의 모델 ID를 서로 다른 회사의 클러스터에 load balancing한다. 각 클러스터의 캐시는 완전히 분리돼 있다. 이제 한 제공업체 내부의 affinity가 완벽해도 소용없다. 첫 번째 호출은 한 업체로, 두 번째 호출은 다른 업체로 가면 공유 캐시가 없으므로 hit가 발생할 수 없다. 이것이 글 첫머리에서 본 분산 현상이다. 레이어 4의 문제가 더 커져 여러 클러스터뿐 아니라 서로 캐시 상태와 가격이 다른 여러 업체로 분산된다. 가장 비싼 선택지는 가장 저렴한 upstream의 기본 요금보다 20배 비쌌다. 우연히 같은 제공업체로 라우팅이 유지된 뒤에야 캐시가 작동했다.

해결하려면 무작위성을 없애야 한다. 라우팅을 결정론적으로 만들어 반복되는 prefix가 같은 warm cache에 도달하게 해야 한다.

# Pin the upstream; otherwise load-balancing scatters you across disjoint caches.
# (field names follow a common multi-provider router's API)
import requests

requests.post(f"{ROUTER_BASE}/chat/completions",
  headers={"Authorization": f"Bearer {API_KEY}"},
  json={
    "model": "qwen/qwen3.5-35b-a3b",
    "messages": messages,
    "usage": {"include": True},              # return cost + cached_tokens
    "provider": {                            # the part that makes caching work
        "order": ["<your-chosen-upstream>"],
        "allow_fallbacks": False,
    },
  })

다행히 이 router는 cached_tokens와 요청별 cost를 모두 보고했다. hit에서는 4,224가 표시됐다. 0을 반환했던 레이어 4 gateway보다 낫다. 하지만 라우팅을 제한하는 것은 사용자의 몫이다. 캐싱은 가격 기능처럼 포장된 라우팅 문제다. 레이어 2의 캐시는 무료지만 레이어 3, 4, 5는 캐시로부터 멀어지도록 라우팅하는 세 가지 단계적 경로다.

할인 폭은 얼마나 큰가? 모델과 사용처마다 제각각이다

라우팅이 제대로 맞았을 때 얼마나 절약할 수 있을까? 폐쇄형 모델의 캐시 읽기 할인율은 대체로 90% 근처다. 오픈 웨이트는 같은 업체의 제품군 안에서도 공개된 캐시 읽기 가격이 생색내기 수준부터 거의 전액 할인까지 다양하다. 아래는 각 업체가 직접 공개한 가격이다.

DeepSeek의 자동 disk cache가 가장 높은 할인율을 제공한다. deepseek-v4-flash의 캐시된 input 읽기 가격은 $0.14/M인 miss에 비해 $0.0028/M으로, 1:50 비율이다. 레이어 4 테스트에서도 97.9%로 재현됐다. 동일한 오픈 웨이트를 제공하는 서드파티 호스트는 캐시된 input 가격을 독립적으로 책정한다. 어떤 곳은 약 50%를 일괄 적용하고, 다른 곳은 모델에 따라 약 50%에서 90%까지 다르게 적용한다. 할인율은 모델만이 아니라 어느 호스트에 도착하는지에 따라 결정된다. 기능 이름은 같지만 할인율은 48%p까지 벌어진다.

할인율은 사용처의 속성이므로, 같은 모델도 제공되는 곳에 따라 캐시 비용 구조가 달라진다. deepseek-v4-pro를 네 가지 경로로 비교하면 다음과 같다.

“DeepSeek-V4-Pro는 캐싱을 지원한다”는 말은 사실이지만 운영에는 거의 쓸모가 없다. 실제로 물어야 할 것은 “어디에서 캐싱을 지원하고, 요율은 얼마며, 어떤 방식으로 보고하는가”다.

의사결정 체크리스트

• ✅ 모델은 캐시가 아니라 한계를 정한다(레이어 1). MLA, GQA 같은 attention 아키텍처가 캐싱 비용을 얼마나 낮출 수 있는지 결정하지만, 모델 자체는 캐시된 token을 제공하지 않는다. 따라서 어디에서 serving되는지, 해당 호스트의 stack이 어떻게 동작하는지 확인해야 한다.
• ✅ 자체 호스팅 중이라면 이미 무료 캐싱을 쓰고 있다(레이어 2). 자동 prefix 캐싱이 활성화돼 있는지 확인하고 prefix hit rate를 모니터링하라. vLLM과 SGLang에서는 기본 활성화돼 있다.
• ✅ 컴퓨팅 호스트에서는 가격표가 아니라 실제 제공 여부를 확인하라(레이어 3). 캐시 읽기 가격은 주장에 불과하다. cold→warm 비용 차이를 측정해야 한다. 호스트가 cache-key affinity hint를 제공하면 사용하라.
• ✅ Gateway를 통한다면 cache-affinity 라우팅과 비용 보고를 요구하라(레이어 4). 동일한 prefix가 하나의 upstream에 유지되지 않거나 warm 호출에서 cost가 줄지 않으면, 캐시에 접근할 수 없거나 검증할 수 없는 상태다.
• ✅ Router에서는 upstream을 고정하라(레이어 5). 제공업체 순서를 지정하고 fallback을 끄는 식으로 라우팅을 제한해야 한다. 그렇지 않으면 서로 캐시를 공유하지 않는 곳으로 load balancing돼 hit를 잃고, 20–50배 비싼 upstream에 도달할 수도 있다.
• ✅ Latency는 비용과 별도로 평가하라. 비용 할인율이 약 0%여도 warm prefill은 2–10배 빠르다.
• ✅ Storage 요금을 부과하는 캐시 유형에 주의하라. 임대형 캐시(Moonshot moonshot-v1, Gemini 명시적 모드)는 사용하지 않는 캐시에도 token과 시간 기준으로 요금을 부과한다. 자동 prefix cache에는 storage 요금이 없다.

결론

폐쇄형 모델에서 “캐싱을 지원하는가?”에는 답이 하나뿐이다. 오픈 웨이트의 캐싱 기능은 수년 전에 추론 엔진 레이어에서 이미 해결됐다. vLLM과 SGLang은 모든 prefix를 무료로 자동 캐싱한다. 그 위의 모든 레이어는 hit를 유지하거나 캐시가 없는 곳으로 요청을 흩뜨리는 plumbing이다. 컴퓨팅 호스트의 replica balancer, gateway의 클러스터 라우팅, router의 제공업체 간 무작위 분산이 여기에 해당한다. 모델 아키텍처는 캐싱 비용을 얼마나 낮출 수 있는지 한계를 정한다. MLA와 GQA는 실제로 모델 레벨에서 이점을 제공한다. 하지만 실제 혜택을 결정하는 것은 요청 경로다. 캐시 동작을 라우팅 속성으로 다뤄야 한다. 실제 사용할 경로에서 비용을 측정하고, warming한 캐시에 다시 도달하도록 경로를 고정하라. 할인율이 아무리 높아도 두 번째 요청이 첫 번째 요청이 지나가지 않은 곳에 도착하면 아무 의미가 없다.

KV cache가 왜 필요하고 TTL이 어떻게 동작하는지 알아보려면 KV Cache와 TTL의 동작 원리부터 읽어보라. Gateway의 캐시 지원 주장을 검증하려면 LLM Gateway의 캐시 보고를 믿을 수 있는가?를 참고하라.

FAQ

오픈 웨이트 모델은 프롬프트 캐싱을 지원하는가? 웨이트는 캐싱 비용을 얼마나 낮출 수 있는지 결정한다. MLA와 GQA 같은 attention 아키텍처가 KV cache를 줄이기 때문이다. 하지만 캐시 자체와 할인, API는 serving stack에서 제공한다. 캐싱은 추론 엔진(vLLM, SGLang, TensorRT-LLM)에 구현되고 컴퓨팅 호스트가 이를 물려받으며, gateway와 router가 전달하거나 흩뜨린다. 같은 체크포인트를 3개 호스트에 배포해도 무료 자동 캐싱, 캐싱 없음, 명시적 캐싱 전용이라는 서로 다른 결과가 나올 수 있다.

같은 모델인데 왜 호출에 따라 비용이 49배나 차이 났는가? 멀티 제공업체 router에서 upstream을 고정하지 않은 요청은 기본 가격과 캐시 상태가 서로 다른 여러 업체의 클러스터로 load balancing된다. 한 호출은 비싼 제공업체에 cold 상태로 도착했고, 다른 호출은 저렴한 제공업체에 warm 상태로 도착했다. Upstream을 고정해 제공업체 순서를 제한하고 fallback을 끄면 두 요소를 모두 제어할 수 있다.

자체 호스팅하면 캐싱 비용을 따로 내야 하는가? 아니다. vLLM, SGLang, TensorRT-LLM의 자동 prefix 캐싱은 기본 활성화돼 있고 무료다. hit가 발생하면 prefill만 생략한다. 이미 운영하는 GPU 비용만 내면 되며 캐시는 직접 소유한다. VRAM이 필요해지면 LRU 방식으로 제거된다.

API에는 cached_tokens: 0이라고 나오는데 비용은 줄었다. 캐싱이 동작한 것인가? 동작했을 가능성이 높다. 자동 캐싱하는 upstream의 cached_tokens를 채우지 않는 gateway가 많다. cost 필드를 기준으로 판단하라. Cold 호출과 동일한 warm 호출 사이에 비용이 크게 줄었다면 cache hit가 발생한 것이다.

캐시 할인율이 가장 높은 오픈 웨이트 모델은 무엇인가? DeepSeek의 자동 disk cache다. deepseek-v4-flash의 캐시된 input 가격은 캐시 미적용 시 $0.14/M인 데 비해 약 $0.0028/M으로, 할인율은 약 98%다. Cold→warm 테스트에서도 V4 제품군 전체에서 97.9–99.2%로 재현됐다. 서드파티 호스트 중에는 일률적으로 약 50%만 적용하는 곳이 많다.

Storage 요금을 부과하는 캐시에는 어떤 문제가 있는가? Moonshot의 moonshot-v1 명시적 캐시와 Gemini의 명시적 캐시는 캐시를 유지하는 동안 token과 시간 기준으로 요금을 부과한다. Gemini는 1M-tokens당 시간당 약 $1–4.50이다. 사용하지 않는 캐시를 삭제하지 않으면 계속 과금된다. 자동 prefix cache에는 storage 요금이 없다.

검증: 실시간 비용과 latency 수치는 2026-06-14에 멀티 제공업체 router와 자체 gateway를 대상으로 측정했다. 약 4.7K-token의 고정 prompt, 작은 max_tokens, 순차적인 cold→warm 실행을 사용했으며, 반환된 요청별 cost로 할인율을 계산했다. 공개 가격과 캐시 동작 방식은 같은 날 제공업체의 1차 문서에서 확인하고 반대 관점에서도 교차 검증했다. 일부 업체의 수치, 특히 Moonshot의 명시적 캐시 요금은 자주 바뀌므로 인용하기 전에 현재 값을 확인하라. 실제 수치는 제공업체, prompt, 지역, 부하에 따라 달라진다.

출처

• DeepSeek — 가격
• DeepSeek — KV cache / Context Caching 가이드
• DeepSeek-V3 기술 보고서 — MLA(KV-cache 압축)
• GQA: 일반화된 Multi-Query Transformer 모델 학습(Ainslie 외)
• Alibaba Cloud Model Studio — context cache와 가격
• Moonshot AI — Context Caching
• Zhipu / Z.AI — 가격과 캐싱
• vLLM — Automatic Prefix Caching
• SGLang — RadixAttention / cache
• LMCache — KV cache offloading과 공유
• Google — Gemini context caching

모든 자료는 2026-06-14에 확인했다. 재무 조언이 아니다. 가격에 의존하기 전에 현재 요금을 확인하라.

← 블로그로 돌아가기