Cache em LLMs de pesos abertos: depende da roleta dos provedores

Com um modelo fechado, o cache de prompts segue um único contrato documentado. Claude tem pontos de interrupção com cache_control; OpenAI e Gemini armazenam automaticamente em cache acima de um limite mínimo de tokens; os descontos são publicados e estáveis. Basta ler uma página.

Com pesos abertos, essa premissa deixa de valer. O mesmo checkpoint de Qwen ou Llama é oferecido por dezenas de hosts, e o cache não é uma propriedade do modelo, mas do ambiente em que ele roda. Para mostrar o impacto disso, medimos uma mesma requisição: um prompt idêntico de cerca de 4.7K tokens enviado seis vezes ao mesmo modelo Qwen por um router multiprovedor, sem fixar o upstream:

Mesmo modelo, mesmo router, mesmo prompt: o custo variou de $0.0141 a $0.000286 — uma diferença de 49× — apenas por causa do upstream escolhido pelo router e da presença ou não daquele prefixo no cache do upstream.

Resumo

• Em modelos com pesos abertos, o cache de prompts é resultado do roteamento, não uma funcionalidade do modelo. Ele é implementado de forma gratuita e automática no mecanismo de inferência. Cada camada acima pode preservá-lo ou inutilizá-lo.
• São cinco camadas: uma fornece o cache e três podem quebrá-lo. O modelo (determina a capacidade de cache, mas não oferece cache) → o mecanismo de inferência (cache gratuito) → o host de computação (transforma-o em produto, de forma irregular) → o gateway (roteamento entre vários clusters) → o router (distribui entre fornecedores com caches independentes).
• Medições. Uma requisição idêntica, distribuída por um router, custou 49× mais em uma escolha do que em outra; para um mesmo modelo, um host ofereceu 59.6% de desconto e outro 0%; os descontos publicados para cache variam de 0% a ~98% entre modelos.
• O que fazer. Fixe a rota para que prefixos repetidos cheguem ao mesmo cache aquecido; audite pela diferença de custo, não pelo campo cached_tokens, que muitas vezes continua em 0 mesmo quando há hit; avalie a latência separadamente — prefills aquecidos são 2–10× mais rápidos mesmo com desconto de custo próximo de 0%.

Os dados ao vivo foram medidos em 2026-06-14 usando um router multiprovedor e nosso próprio gateway, com um prompt fixo em inglês de cerca de 4.7K tokens, max_tokens pequeno e execuções sequenciais. Os preços documentados foram conferidos na documentação primária dos provedores no mesmo dia e submetidos a uma verificação cruzada adversarial. As proporções (percentual de desconto e variação de latência) são a parte que pode ser generalizada; os valores absolutos em dólares dependem da plataforma, do prompt e da carga. Reproduza os testes antes de citar os números.

Os tipos de cache que você encontrará na prática

Antes de analisar a stack, precisamos alinhar o vocabulário. Entre os hosts de modelos com pesos abertos, há quatro formatos distintos de cache, cada um com uma forma de cobrança.

1. Cache automático de prefixos (sem marcadores). É o padrão dominante. O servidor calcula o hash do prefixo do prompt, reutiliza o estado KV se houver uma requisição anterior correspondente e aplica o desconto automaticamente — sem cache_control, sem alteração no código e, muitas vezes, sem opção de desativar. DeepSeek, Zhipu GLM e a maioria dos hosts de modelos com pesos abertos funcionam assim. As gravações são gratuitas; o cache pode permanecer desde alguns minutos na VRAM até períodos maiores em disco — a DeepSeek mantém prefixos por “algumas horas a alguns dias”.

2. Cache com ponto de interrupção explícito (cache_control). É o modelo usado pela Anthropic, também oferecido por alguns hosts de modelos com pesos abertos. O Model Studio da Alibaba aceita "cache_control": {"type": "ephemeral"} em um bloco de mensagem Qwen; algumas plataformas de serving expõem um marcador equivalente. Você indica o limite, paga uma sobretaxa de gravação e recebe, em troca, um desconto maior nas leituras.

3. Objetos de cache alugados (com taxa de armazenamento). Este exige atenção. A família legada moonshot-v1 da Moonshot obriga você a chamar POST /v1/caching para criar um cache e cobra uma taxa de gravação, uma taxa de armazenamento por token por minuto e uma taxa por chamada com hit. O cache explícito do Gemini, do Google, segue a mesma ideia — custo de entrada mais armazenamento, por volta de $1.00–$4.50 por 1M-tokens por hora. O cache é um recurso alugado, e você precisa fazer sua coleta de lixo.

4. Reutilização de KV com self-hosting (gratuita). Ao executar os pesos por conta própria, o mecanismo de inferência faz cache de forma automática e gratuita. Não há taxa de gravação, preço de leitura nem aluguel de armazenamento — um hit apenas elimina o prefill.

No Model Studio, Qwen oferece os dois modos, automático e explícito, com uma diferença concreta: no modo implícito, um hit custa 20% do valor da entrada, sem custo de gravação; no modo explícito, custa 10% do valor da entrada, mas a gravação é cobrada a 125%, e a entrada fica limitada a um TTL de 5 minutos. O desconto é maior, mas você paga para preencher o cache e volta a pagar sempre que ele expira.

Onde o cache fica na stack

A ideia central é esta: em modelos com pesos abertos, o cache de prompts é resolvido em exatamente uma camada e colocado em risco em todas as camadas acima dela. Percorra a stack dos pesos para cima e, em cada camada, pergunte: ela fornece o cache ou apenas o encaminha? E ela pode quebrar o que a camada inferior já fez?

  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.

Camada 1 — O modelo: capacidade de cache, não um cache

Muita gente acredita que o cache fica nesta camada — “DeepSeek tem cache” — então é aqui que precisamos ser precisos. Um checkpoint é um conjunto de pesos; ele executa o mesmo mecanismo de atenção, exista ou não um cache KV. Ele não inclui cache, desconto, TTL nem marcador cache_control — tudo isso pertence à camada de serving. Em sentido estrito, os pesos não fornecem nenhum produto de cache.

Os pesos, porém, não são neutros, e DeepSeek é o melhor exemplo. A arquitetura de atenção do modelo determina o tamanho do cache KV e, portanto, o menor custo que o cache pode alcançar:

• O Multi-head Latent Attention (MLA) da DeepSeek comprime o cache KV em um espaço latente de baixo rank — para cerca de 4–14% do tamanho de um cache multi-head convencional. É justamente essa compressão que permite à API da DeepSeek persistir prefixos em disco e cobrar uma leitura de cache a cerca de 2% do preço da entrada. A arquitetura é o facilitador; o cache em disco é um produto construído sobre ela.
• O Grouped-Query Attention (GQA) — usado por Llama, Qwen, Mistral e DeepSeek — compartilha heads KV para reduzir o cache pelo fator de agrupamento (≈8× no Llama-3).

A contribuição da Camada 1 é, portanto, a capacidade de cache, não o cache em si: a arquitetura determina até onde as camadas superiores conseguem reduzir o custo, mas os pesos nunca servem um token em cache por conta própria. A frase “DeepSeek tem cache” combina silenciosamente duas coisas diferentes sob o mesmo nome — os pesos (esta camada, que oferece MLA) e a API e stack de serving da DeepSeek (Camadas 2–3, que oferecem cache em disco, desconto e campos de uso). Se você baixar os pesos abertos e executá-los por conta própria, continuará com o cache KV reduzido pelo MLA, mas o produto de cache em disco permanecerá nos servidores da DeepSeek — em seu lugar, você terá a Camada 2 que implantar. A recomendação operacional continua a mesma: em vez de perguntar se um modelo faz cache, pergunte onde ele é servido. Isso não significa que a arquitetura seja irrelevante. Ela define o limite; o caminho da requisição define o que você realmente recebe.

Camada 2 — O mecanismo de inferência: onde o cache é implementado e gratuito

Uma camada acima, o cache não está apenas disponível — o problema já foi resolvido, gratuitamente. Mecanismos de inferência modernos armazenam prefixos em cache automaticamente:

• vLLM — Automatic Prefix Caching: calcula o hash de cada bloco KV, reutiliza qualquer bloco cujo hash de prefixo já tenha aparecido e remove entradas por LRU. Vem ativado por padrão na V1.
• SGLang — RadixAttention: armazena o cache KV em uma radix tree para reutilizar qualquer prefixo compartilhado, com agendamento ciente do cache.
• TensorRT-LLM — reutilização de blocos (enable_block_reuse, ativada por padrão), com opção de descarregar blocos KV para a memória do host.

Projetos como LMCache vão além, descarregando o KV para CPU ou disco e compartilhando-o entre instâncias. Esse é o começo de uma solução para o problema de roteamento que veremos a seguir. O ponto é simples: com self-hosting, o cache já está resolvido. Ele é automático, não custa nada além das GPUs que você já mantém, usa LRU para remoção e fica sob seu controle — um hit apenas elimina o prefill, reduzindo o TTFT e aumentando o throughput. Não existe campo de cobrança cached_tokens, porque nada é faturado; o ganho aparece nas suas próprias métricas de latência. Em um modelo fechado, você aluga o cache; em um modelo aberto, pode ser dono dele. A ressalva é o inverso do ambiente hospedado: o cache é efêmero (VRAM, LRU), então só sobrevive enquanto o prefixo continua aquecido — exatamente o que as camadas superiores precisam preservar.

Camada 3 — O host de computação: transformando-o em produto, de forma irregular

Hosts comerciais de inferência encapsulam a Camada 2 e operam frotas de réplicas. Eles herdam o cache automático e gratuito — resta saber se o implementam bem. A resposta varia em dois aspectos.

Primeiro, a exposição e o preço variam muito. Entre os principais hosts de modelos com pesos abertos: um aplica 50% fixos sobre entradas em cache e não inclui os tokens em cache nos rate limits; outro oferece 50% de desconto por padrão no serverless; um terceiro define o preço de entrada em cache por modelo (por exemplo, uma faixa de Qwen com cerca de 80% de desconto) e expõe uma dica de cache key para melhorar a afinidade; um quarto mantém o cache sempre ativo, sem possibilidade de desativá-lo em endpoints dedicados. O mecanismo subjacente é o mesmo, mas há quatro políticas de preço distintas.

Segundo — e aqui o cache começa a quebrar — existe o problema das múltiplas réplicas. O prefixo aquecido permanece na VRAM da réplica que atendeu à requisição fria. O load balancer do host pode enviar a requisição seguinte para outra réplica, cujo cache está frio. Foi exatamente o que observamos ao fixar o mesmo modelo Qwen em um upstream por vez e executar uma sequência frio→aquecido:

O Provider A armazenou corretamente em cache e informou o resultado. O Provider B — que anuncia um preço de leitura em cache para esse modelo — não concedeu nenhum desconto em uma chamada fria e duas aquecidas durante nosso teste. A causa pode ser um critério de elegibilidade, a distribuição entre réplicas ou um aquecimento que exija mais de duas requisições; o resultado medido nesse caminho foi zero. A capacidade está resolvida na Camada 2, mas sua entrega depende da execução na Camada 3 e varia entre hosts.

Camada 4 — O gateway: o problema dos múltiplos clusters

Um gateway fica à frente de um ou mais upstreams e transforma o problema das réplicas em um problema de clusters. Se ele distribuir as requisições em round-robin entre clusters ou provedores sem afinidade de cache, o cache aquecido se torna estruturalmente inacessível — cada requisição chega a um lugar que não tem o prefixo. Um gateway ciente do cache precisa rotear pelo hash do prefixo para manter prefixos idênticos no mesmo upstream, assim como a Camada 2 os mantém nos mesmos blocos KV. Isso vale tanto para software operado por você, como LiteLLM, quanto para um serviço hospedado; os trade-offs operacionais estão detalhados em LiteLLM versus um gateway gerenciado.

Executamos uma bateria de testes frio→aquecido em modelos com pesos abertos por meio de um gateway de terceiros, lendo diretamente o cost de cada requisição:

DeepSeek-V4 alcançou 97–99% de desconto, indicando que a afinidade funcionou de ponta a ponta; qwen3.5-plus e qwen3-max ficaram em ~0% na chamada aquecida, apesar de o catálogo informar um preço de leitura em cache. A tabela também mostra outras duas características dos gateways:

• O campo de uso mente; o custo não. cached_tokens retornou 0 em todas as chamadas, inclusive naquelas com queda de 99% no custo. Muitos gateways compatíveis com OpenAI não preenchem o campo de tokens em cache para upstreams que fazem cache automaticamente. Audite pela diferença de cost entre uma chamada fria e outra aquecida idêntica, não pelo campo de tokens — a mesma recomendação usada para auditar as alegações de cache de um gateway.
• A latência melhora mesmo quando o custo não muda. Todas as chamadas aquecidas foram 2–10× mais rápidas — qwen3.5-flash passou de 10.2s→1.0s — inclusive as que tiveram desconto de ~0%. Um hit elimina o prefill independentemente da política de preços do host. Portanto, o cache pode melhorar o TTFT mesmo em um gateway que não reduz sua fatura.

Um gateway sem afinidade oferece um cache que você não consegue acessar; um gateway que não expõe o custo do cache oferece um cache que você não consegue verificar.

Camada 5 — O router: distribuição aleatória entre provedores

No topo da stack, um router multiprovedor distribui um único ID de modelo entre clusters de empresas diferentes, cada uma com um cache separado. Nesse cenário, nem mesmo a afinidade perfeita dentro de um provedor resolve o problema: se a chamada 1 for para um fornecedor e a chamada 2 para outro, não haverá cache compartilhado. É a dispersão mostrada no início deste artigo. Ela amplia o problema da Camada 4: não são apenas vários clusters, mas vários fornecedores com estados de cache e preços independentes — a opção mais cara cobrou 20× a tarifa-base do upstream mais barato. O cache só entrou em ação quando o roteamento permaneceu no mesmo provedor por acaso.

A solução é eliminar a aleatoriedade: torne o roteamento determinístico para que prefixos repetidos cheguem ao mesmo cache aquecido:

# 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,
    },
  })

O router informou corretamente cached_tokens (4,224 no hit) e o cost de cada requisição, permitindo verificar ambos — melhor que o gateway da Camada 4, que retornou 0. Mas cabe a você restringir o roteamento. Cache é um problema de roteamento disfarçado de funcionalidade de preços: ele é gratuito na Camada 2; as Camadas 3, 4 e 5 são três formas cada vez mais amplas de desviar as requisições dele.

Qual é o tamanho do desconto? Depende muito

Quando o roteamento funciona, quanto você economiza? Em modelos fechados, o desconto de leitura em cache costuma ficar perto de 90%. Para pesos abertos, os preços publicados variam de um desconto simbólico a uma redução quase total, inclusive dentro do portfólio de um único fornecedor. Tarifas oficiais publicadas:

O cache automático em disco da DeepSeek oferece o maior desconto do mercado — deepseek-v4-flash cobra $0.0028/M por entrada em cache contra $0.14/M em caso de miss, uma proporção de 1:50, reproduzida em nosso teste da Camada 4 com 97.9%. Hosts de terceiros que executam esses mesmos pesos abertos definem preços independentes para entradas em cache — alguns aplicam cerca de 50% fixos, outros variam por modelo entre ~50% e ~90%. O desconto depende do host que recebe a requisição, não apenas do modelo. A funcionalidade tem o mesmo nome, mas a diferença chega a 48 pontos percentuais.

Como o desconto pertence à plataforma, um mesmo modelo tem custos de cache diferentes em cada lugar onde é servido. Quatro formas de usar deepseek-v4-pro:

“DeepSeek-V4-Pro oferece cache” é uma afirmação verdadeira, mas quase inútil; a pergunta operacional é: “oferece cache onde, com qual tarifa e informado de que forma?”

Checklist de decisão

• ✅ O modelo define o limite, não o cache (Camada 1). A arquitetura de atenção (MLA, GQA) determina até onde o custo do cache pode cair, mas nunca serve um token em cache. Pergunte onde o modelo é servido e o que a stack desse host faz.
• ✅ Faz self-hosting? O cache já é gratuito (Camada 2). Confirme que o cache automático de prefixos está ativo — ele vem habilitado por padrão em vLLM/SGLang — e monitore sua taxa de hits por prefixo.
• ✅ Em um host de computação, verifique a entrega, não a coluna de preço (Camada 3). Um preço de leitura em cache é apenas uma promessa; meça a diferença de custo entre uma chamada fria e outra aquecida. Use uma dica de afinidade por cache key quando o host oferecer essa opção.
• ✅ Ao usar um gateway, exija roteamento com afinidade de cache e informação de custo (Camada 4). Se prefixos idênticos não forem mantidos no mesmo upstream, ou se o cost não cair em uma chamada aquecida, o cache estará inacessível ou não poderá ser verificado.
• ✅ Em um router, fixe o upstream (Camada 5). Restrinja o roteamento — por exemplo, com um campo de ordem de provedores e fallbacks desativados — ou você perderá hits devido ao balanceamento entre caches independentes, além de correr o risco de cair em um upstream 20–50× mais caro.
• ✅ Avalie a latência separadamente do custo. Prefills aquecidos são 2–10× mais rápidos mesmo quando o desconto financeiro é de ~0.
• ✅ Fique atento aos tipos de cache que cobram armazenamento. Caches alugados (Moonshot moonshot-v1, Gemini explícito) cobram por token e tempo enquanto o cache está ocioso; caches automáticos de prefixo não cobram armazenamento.

Conclusão

Para modelos fechados, “há cache?” tem uma única resposta. Em pesos abertos, essa capacidade foi resolvida há anos na camada do mecanismo de inferência — vLLM e SGLang armazenam todos os prefixos em cache, de forma automática e gratuita. Tudo acima dessa camada é infraestrutura que preserva o hit ou desvia as requisições dele: o balanceador de réplicas de um host de computação, o roteamento entre clusters de um gateway ou a distribuição aleatória de um router entre fornecedores. A arquitetura do modelo define o menor custo possível do cache — MLA e GQA trazem ganhos reais no nível do modelo —, mas o caminho da requisição determina o que você recebe na prática. Trate o comportamento do cache como uma propriedade do roteamento: meça o custo no caminho exato que será usado em produção, fixe a rota para acessar o mesmo cache que você aqueceu e lembre que nem o maior desconto do mercado tem valor se a segunda requisição chegar a um lugar que nunca recebeu a primeira.

Para entender por que o cache KV existe e como os TTLs funcionam, comece por Como funcionam o cache KV e o TTL; para auditar as alegações de cache de um gateway, consulte Seu gateway de LLM mente sobre o cache?.

Perguntas frequentes

Modelos com pesos abertos oferecem cache de prompts? Os pesos determinam até onde o custo do cache pode cair — arquiteturas de atenção como MLA e GQA reduzem o cache KV —, mas o cache em si, o desconto e a API vêm da stack de serving. O cache é implementado no mecanismo de inferência (vLLM, SGLang, TensorRT-LLM), herdado pelos hosts de computação e encaminhado — ou dispersado — por gateways e routers. O mesmo checkpoint enviado a três hosts pode ter cache automático gratuito, nenhum cache ou apenas cache explícito.

Por que o mesmo modelo custou 49× mais em uma chamada do que em outra? Em um router multiprovedor, uma requisição sem upstream fixado é balanceada entre clusters de fornecedores diferentes, com preços-base e estados de cache independentes. Uma chamada chegou fria a um provedor caro; outra chegou aquecida a um barato. Fixe o upstream — restrinja a ordem dos provedores e desative fallbacks — para controlar os dois fatores.

Se eu fizer self-hosting, preciso pagar pelo cache? Não. O cache automático de prefixos em vLLM, SGLang e TensorRT-LLM vem ativado por padrão e é gratuito — um hit apenas elimina o prefill. Você paga somente pelas GPUs que já utiliza. O cache fica sob seu controle e é removido por LRU quando a VRAM é necessária.

A API mostra cached_tokens: 0, mas minha fatura caiu. O cache funcionou? Provavelmente. Muitos gateways não preenchem cached_tokens para upstreams que fazem cache automaticamente. Confie no campo cost: uma queda grande entre uma chamada fria e outra aquecida idêntica indica um hit no cache.

Qual modelo com pesos abertos oferece o maior desconto de cache? O cache automático em disco da DeepSeek: deepseek-v4-flash cobra cerca de $0.0028/M por entradas em cache contra $0.14/M sem cache, um desconto de ~98%, reproduzido em 97.9–99.2% na linha V4 durante nossos testes frio→aquecido. Muitos hosts de terceiros aplicam cerca de 50% fixos.

Qual é o problema dos caches que cobram armazenamento? O cache explícito do moonshot-v1, da Moonshot, e o cache explícito do Gemini cobram por token e tempo para manter o cache ativo — no Gemini, cerca de $1–4.50 / 1M-tokens / hora. Um cache ocioso que você esqueceu de excluir continua gerando cobrança. Caches automáticos de prefixos não têm taxa de armazenamento.

Verificação: os dados de custo e latência foram medidos ao vivo em 2026-06-14 usando um router multiprovedor e nosso próprio gateway, com um prompt fixo de cerca de 4.7K tokens, max_tokens pequeno e execuções sequenciais frio→aquecido; os descontos foram calculados com base no cost retornado para cada requisição. Os preços e mecanismos de cache documentados foram conferidos na documentação primária dos provedores no mesmo dia e submetidos a uma verificação cruzada adversarial; alguns valores de fornecedores — principalmente as taxas de cache explícito da Moonshot — mudam com frequência, portanto confirme os números atuais antes de citá-los. Seus resultados variam conforme o provedor, o prompt, a região e a carga.

Fontes

• DeepSeek — Preços
• DeepSeek — Guia de cache KV e cache de contexto
• Relatório técnico do DeepSeek-V3 — MLA (compressão do cache KV)
• GQA: treinamento de modelos Transformer com Multi-Query generalizado (Ainslie et al.)
• Alibaba Cloud Model Studio — cache de contexto e preços
• Moonshot AI — Cache de contexto
• Zhipu / Z.AI — Preços e cache
• vLLM — Cache automático de prefixos
• SGLang — RadixAttention e cache
• LMCache — Offload e compartilhamento de cache KV
• Google — Cache de contexto do Gemini

Tudo foi conferido em 2026-06-14. Isto não é aconselhamento financeiro; verifique os preços atuais antes de tomar decisões com base neles.

← Voltar ao blog