Cache de LLMs Open-Weight: Por Que o Seu É uma Roleta de Provedores

Com um modelo fechado, o cache de prompt é um contrato documentado. O Claude tem breakpoints cache_control; OpenAI e Gemini fazem cache automaticamente acima de um limite de tokens; os descontos são publicados e estáveis. Você lê uma página e está pronto.

Os pesos abertos quebram essa premissa. O mesmo checkpoint Qwen ou Llama é servido por dezenas de hosts, e cache não é uma propriedade do modelo — é uma propriedade de onde o modelo roda. Para mostrar o quanto isso importa, aqui está uma requisição medida — um prompt idêntico de ~4.7K tokens enviado ao mesmo modelo Qwen através de um roteador multi-provedor seis vezes, sem upstream fixado:

Mesmo modelo, mesmo roteador, mesmo prompt: a conta variou de $0.0141 a $0.000286 — uma diferença de 49× — puramente em função de qual upstream o roteador escolheu e se esse upstream tinha o prefixo aquecido.

Resumo

• O cache de prompt para modelos open-weight é um resultado de roteamento, não uma funcionalidade do modelo. Ele é implementado — gratuito e automático — no motor de inferência, e então preservado ou destruído por cada camada acima dele.
• Cinco camadas: uma fornece o cache, três podem quebrá-lo. O modelo (define a cacheabilidade, não serve cache) → o motor de inferência (cache, gratuito) → o host de computação (o transforma em produto, de forma desigual) → o gateway (roteamento multi-cluster) → o roteador (distribui entre fornecedores com caches disjuntos).
• Medido. Uma requisição idêntica, dispersa por um roteador, custou 49× mais em uma escolha do que em outra; em um modelo, um host entregou 59,6% de desconto e outro 0%; os descontos de cache publicados variam de 0% a ~98% entre os modelos.
• O que fazer. Fixe sua rota para que prefixos repetidos atinjam o mesmo cache quente; audite pelo delta de custo, não pelo campo cached_tokens (que frequentemente lê 0 em um hit real); avalie a latência separadamente — prefills quentes rodam de 2 a 10× mais rápido mesmo com ~0% de desconto no custo.

Os valores ao vivo foram medidos em 2026-06-14 contra um roteador multi-provedor e nosso próprio gateway, com um prompt fixo em inglês de ~4.7K tokens, max_tokens pequeno, execuções sequenciais. Os preços documentados foram verificados nas documentações primárias dos provedores no mesmo dia e validados de forma adversarial. As proporções (percentual de desconto, variação de latência) são a parte portável; os valores absolutos em dólares dependem do ambiente, do seu prompt e da carga. Reproduza antes de citar.

Os tipos de cache que você vai encontrar de verdade

Antes da pilha, o vocabulário. Entre os hosts de modelos open-weight, existem quatro formatos distintos de cache, e cada um cobra de forma diferente.

1. Cache de prefixo automático (sem marcadores). O padrão dominante. O servidor faz o hash do prefixo do seu prompt, reutiliza o estado KV se ele corresponder a uma requisição anterior e aplica o desconto por conta própria — sem cache_control, sem mudança de código, muitas vezes impossível de desativar. DeepSeek, Zhipu GLM e a maioria dos hosts open-weight fazem isso. As escritas são gratuitas; o cache vive desde a VRAM (minutos) até o disco (o DeepSeek mantém prefixos “de algumas horas a alguns dias”).

2. Cache com ponto de interrupção explícito (cache_control). O formato da Anthropic, que alguns hosts open-weight também oferecem. O Model Studio da Alibaba aceita "cache_control": {"type": "ephemeral"} em um bloco de mensagem do Qwen; algumas plataformas de serving expõem um marcador equivalente. Você define o limite, paga um adicional de escrita e recebe em troca um desconto de leitura mais profundo.

3. Objetos de cache alugados (com taxa de armazenamento). O que merece atenção. A família legada moonshot-v1 da Moonshot exige que você faça POST /v1/caching para criar um cache e então cobra uma taxa de escrita, uma taxa de armazenamento por token por minuto e uma taxa de acerto por chamada. O cache explícito do Gemini da Google segue a mesma ideia — custo de entrada mais armazenamento a aproximadamente $1,00–$4,50 por 1M de tokens por hora. O cache é um recurso que você aluga e precisa gerenciar para liberar.

4. Reutilização de KV self-hosted (gratuito). Execute os pesos você mesmo e o motor de inferência faz o cache de forma gratuita e automática. Sem taxa de escrita, sem taxa de leitura, sem aluguel de armazenamento — um acerto simplesmente pula o prefill.

O Qwen no Model Studio oferece ambos os modos — automático e explícito — com uma troca real: o implícito cobra um acerto a 20% do input com escritas gratuitas; o explícito cobra um acerto a 10% do input, mas cobra 125% na escrita e limita a entrada a um TTL de 5 minutos. Desconto mais profundo, mas você paga para popular e paga novamente cada vez que expira.

Onde o cache vive na pilha

Esta é a ideia central. O cache de prompt para modelos open-weight é resolvido em exatamente uma camada e ameaçado em cada camada acima dela. Percorra a pilha a partir dos pesos para cima e, em cada camada, pergunte: esta camada fornece cache, ou apenas o repassa — e pode quebrar o que a camada abaixo 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: cacheabilidade, não um cache

Esta é a camada em que a maioria das pessoas acha que o cache reside — “DeepSeek tem cache” — por isso é a primeira sobre a qual precisamos ser precisos. Um checkpoint é um conjunto de pesos; ele executa a mesma atenção independentemente de um cache KV existir ou não. Ele não inclui cache, desconto, TTL nem marcador cache_control — esses são recursos da camada de serviço. Nesse sentido estrito, os pesos não fornecem nenhum produto de cache.

Mas os pesos não são neutros, e o DeepSeek é o exemplo perfeito do porquê. A arquitetura de atenção do modelo decide o tamanho do cache KV e, portanto, o quão barato o cache pode ser:

• A Multi-head Latent Attention (MLA) do DeepSeek comprime o cache KV em um latente de baixo rank — para aproximadamente 4–14% de um cache multi-head padrão. Essa compressão é exatamente o que permite que a API do DeepSeek persista prefixos em disco e precifique uma leitura de cache a ~2% do input. A arquitetura é o habilitador; o cache em disco é um produto construído sobre ela.
• A Grouped-Query Attention (GQA) — usada por Llama, Qwen, Mistral e DeepSeek — compartilha heads KV para reduzir o cache pelo fator de grupo (≈8× no Llama-3).

Portanto, a contribuição da Camada 1 é cacheabilidade, não um cache: a arquitetura define o teto de quão barato cada camada acima pode tornar o cache, mas os pesos nunca servem um token em cache por si mesmos. E “DeepSeek tem cache” silenciosamente funde duas coisas diferentes com o mesmo nome — os pesos (esta camada, que fornece a MLA) e a API e stack de serviço do DeepSeek (Camadas 2–3, que fornecem o cache em disco, o desconto e os campos de uso). Baixe os pesos abertos e execute-os você mesmo: você mantém o cache KV pequeno da MLA, mas o produto de cache em disco permanece nos servidores do DeepSeek — você herda qualquer Camada 2 que implantar em seu lugar. Portanto, a conclusão operacional ainda se aplica: pare de perguntar se um modelo faz cache e comece a perguntar onde ele é servido — apenas não confunda isso com a arquitetura não importar. Ela define o teto; o caminho define o que você realmente obtém.

Camada 2 — O motor de inferência: onde o cache é construído, e gratuito

Uma camada acima, o cache não está apenas presente — está resolvido e é gratuito. Motores de inferência modernos fazem cache de prefixos automaticamente:

• vLLM — Automatic Prefix Caching: faz hash de cada bloco KV, reutiliza qualquer bloco cujo hash de prefixo já tenha visto, com evicção por LRU. Ativado por padrão na V1.
• SGLang — RadixAttention: armazena o cache KV em uma árvore radix para que qualquer prefixo compartilhado seja reutilizado, com escalonamento ciente do cache.
• TensorRT-LLM — reutilização de blocos (enable_block_reuse, ativado por padrão), com offload opcional de blocos KV para a memória do host.

Projetos como o LMCache estendem isso ainda mais — fazendo offload do KV para CPU/disco e compartilhando-o entre instâncias, o que é a semente para resolver o problema de roteamento que abordaremos em seguida. O ponto: se você faz self-host, está pronto. O cache é automático, não custa nada além das GPUs que você já executa, faz evicção por LRU e você o possui — um hit simplesmente pula o prefill, reduzindo o TTFT e aumentando o throughput. Não há campo de cobrança cached_tokens porque nada é cobrado; o benefício aparece nas suas próprias métricas de latência. Para um modelo fechado você aluga o cache; para um aberto você pode possuí-lo integralmente. O problema é o inverso do mundo hospedado: o cache é efêmero (VRAM, LRU), portanto sobrevive apenas enquanto o prefixo permanece quente — o que é precisamente o que as camadas acima devem preservar.

Camada 3 — O host de computação: produtizando de forma desigual

Hosts de inferência comerciais encapsulam a Camada 2 e executam frotas de réplicas. Eles herdam o cache automático gratuito — a questão é se o implementam bem, e a resposta é mista em dois eixos.

Primeiro, exposição e preço variam enormemente. Entre os principais hosts de modelos open-weight: um aplica um desconto fixo de 50% no input em cache e permite que tokens em cache ignorem os limites de taxa; outro aplica 50% de desconto por padrão no modo serverless; um terceiro precifica o input em cache por modelo (por exemplo, um tier Qwen com ~80% de desconto) e expõe uma dica de cache-key para melhorar a afinidade; um quarto mantém o cache sempre ativo e sem possibilidade de desativação em endpoints dedicados. Mesmo motor subjacente, quatro filosofias de precificação.

Segundo — e este é o primeiro ponto onde o cache falha — o problema de múltiplas réplicas. Seu prefixo aquecido vive na VRAM da única réplica que atendeu a requisição fria. O próprio balanceador de carga do host pode enviar sua próxima requisição para uma réplica diferente com cache frio. Observamos exatamente isso: fixando o mesmo modelo Qwen em um upstream por vez e executando o ciclo frio→quente:

O Provedor A realizou o cache corretamente e o reportou. O Provedor B — que anuncia um preço de leitura de cache para este modelo — retornou nenhum desconto em uma chamada fria e duas chamadas quentes em nosso teste. Seja por questões de elegibilidade, distribuição entre réplicas ou um tempo de aquecimento superior a duas requisições, o resultado medido neste caminho foi zero. A capacidade está resolvida na Camada 2; se você de fato a recebe é um detalhe de execução da Camada 3, e ele varia por host.

Camada 4 — O gateway: o problema multi-cluster

Um gateway fica na frente de um ou mais upstreams e multiplica o problema de réplicas em um problema de cluster. Se ele distribui requisições entre clusters ou provedores em round-robin sem afinidade de cache, o cache aquecido torna-se estruturalmente inalcançável — cada requisição cai em algum lugar onde o prefixo não está. Um gateway com consciência de cache deve rotear por hash de prefixo, para que prefixos idênticos fiquem no mesmo upstream, da mesma forma que a Camada 2 os mantém nos mesmos blocos KV.

Executamos uma bateria cold→warm em modelos open-weight em um gateway de terceiros, lendo o cost por requisição diretamente:

O DeepSeek-V4 atingiu 97–99% (afinidade funcionando de ponta a ponta); qwen3.5-plus e qwen3-max retornaram ~0% na chamada quente, apesar de constarem com preço de leitura de cache no catálogo. Duas outras lições de gateway estão escondidas nesta tabela:

• O campo de uso mente; o custo não. cached_tokens retornou 0 em todas as chamadas aqui, incluindo as quedas de custo de 99%. Muitos gateways compatíveis com OpenAI não preenchem o campo de tokens em cache para upstreams que fazem cache automaticamente. Audite pelo delta de cost entre uma chamada fria e uma quente, não pelo campo de tokens — a mesma lição de auditar as alegações de cache de um gateway.
• A latência melhora mesmo quando o custo não melhora. Toda chamada quente foi 2–10× mais rápida — qwen3.5-flash passou de 10,2s→1,0s — incluindo as com ~0% de desconto. Um acerto pula o prefill independentemente de como o host o precifica, então o cache pode compensar no TTFT em um gateway que não te dá nada na fatura.

Um gateway que não preserva afinidade te entrega um cache que você não consegue alcançar; um que não expõe o custo de cache te entrega um que você não consegue verificar.

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

No topo, um roteador multi-provedor faz balanceamento de carga de um único ID de modelo entre clusters de empresas diferentes — cada um com um cache separado. Agora nem mesmo uma afinidade perfeita dentro de um provedor consegue te salvar: se a chamada 1 vai para um fornecedor e a chamada 2 para outro, não há cache compartilhado para ser aproveitado. Esse é o espalhamento mencionado no início deste post, e ele se soma à Camada 4 — não apenas múltiplos clusters, mas múltiplos fornecedores com estado de cache disjunto e preços disjuntos (a escolha mais cara cobrada a 20× a taxa base do upstream mais barato). O cache só entrou em ação quando o roteamento por acaso ficou preso a um único provedor.

A solução é eliminar a aleatoriedade — tornar o roteamento determinístico para que prefixos repetidos sempre caiam no 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,
    },
  })

Para seu crédito, o roteador de fato reportou cached_tokens (4.224 no acerto) e um cost por requisição, então você pode verificar ambos — melhor do que o gateway da Camada 4 que retornava 0. Mas o roteamento é seu para restringir. Cache é um problema de roteamento disfarçado de funcionalidade de precificação: o cache é gratuito na Camada 2, e as Camadas 3, 4 e 5 são três formas escalantes de se rotear para longe dele.

Qual é a profundidade do desconto? Varia muito

Quando o roteamento de fato se alinha, quanto você economiza? Para modelos fechados, o desconto na leitura de cache se concentra perto de 90%. Para pesos abertos, o preço publicado de leitura de cache varia de um gesto simbólico a quase total, mesmo dentro do lineup de um único fornecedor. Taxas publicadas de primeira parte:

O cache em disco automático da DeepSeek é o mais profundo do mercado — deepseek-v4-flash lê input em cache a $0,0028/M contra $0,14/M no miss, uma proporção de 1:50, que nosso teste da Camada 4 reproduziu a 97,9%. Hosts de terceiros desses mesmos pesos abertos precificam o input em cache de forma independente — alguns aplicam um flat de ~50%, outros variam por modelo de ~50% a ~90% — portanto o desconto que você obtém é função de qual host você cai, não apenas do modelo. Mesmo nome de funcionalidade, uma diferença de 48 pontos percentuais.

Como o desconto é uma propriedade do venue, um mesmo modelo carrega economias de cache diferentes em cada lugar onde é servido. deepseek-v4-pro, de quatro formas:

“DeepSeek-V4-Pro suporta cache” é verdade e quase inútil; a pergunta operacional é “suporta cache onde, a qual taxa, reportado como.”

Uma lista de verificação para decisão

• ✅ O modelo define o teto, não o cache (Camada 1). Sua arquitetura de atenção (MLA, GQA) decide o quão barato o cache pode ser, mas nunca serve um token em cache — portanto, ainda pergunte onde ele é servido e o que a stack desse host faz.
• ✅ Auto-hospedagem? Você já tem de graça (Camada 2). Confirme que o prefix caching automático está ativado (está por padrão no vLLM/SGLang) e monitore sua taxa de acerto de prefixo.
• ✅ Em um host de computação, verifique a entrega, não a coluna de preços (Camada 3). Um preço de leitura de cache é uma afirmação; meça o delta de custo frio→quente. Use uma dica de afinidade de cache-key onde o host oferecer uma.
• ✅ Através de um gateway, exija roteamento com afinidade de cache e relatório de custos (Camada 4). Se prefixos idênticos não ficarem fixos em um único upstream, ou se cost não cair em uma chamada quente, o cache é inacessível ou inverificável.
• ✅ Em um roteador, fixe o upstream (Camada 5). Restrinja o roteamento (por exemplo, um campo de ordem de provedor com fallbacks desativados), ou você perderá acertos por balanceamento de carga entre caches disjuntos — e arriscará um upstream 20–50× mais caro.
• ✅ Avalie a latência separadamente do custo. Prefills quentes são 2–10× mais rápidos mesmo quando o desconto em dinheiro é ~0.
• ✅ Fique atento a tipos de cache com taxa de armazenamento. Caches alugados (Moonshot moonshot-v1, Gemini explícito) cobram por token-tempo para um cache ocioso; caches de prefixo automáticos não cobram.

Conclusão

Para modelos fechados, “ele faz cache?” tem uma única resposta. Para pesos abertos, a capacidade foi resolvida há anos na camada do motor de inferência — vLLM e SGLang fazem cache de todo prefixo, de graça, automaticamente. Tudo acima dessa camada é encanamento que ou preserva o acerto ou o dispersa: o balanceador de réplicas de um host de computação, o roteamento de cluster de um gateway, a distribuição aleatória de um roteador entre fornecedores. A arquitetura do modelo define o teto de quão barato o cache pode ser — MLA e GQA são ganhos reais no nível do modelo — mas o caminho que sua requisição percorre decide o que você realmente obtém. Trate o comportamento do cache como uma propriedade de roteamento — meça-o em termos de custo no caminho exato que você vai usar, fixe a rota para que o cache que você aqueceu seja o que você acerta, e lembre-se de que o maior desconto do mundo não vale nada se a segunda requisição cair em algum lugar que a primeira nunca tocou.

Para a mecânica de por que um KV cache existe e como os TTLs funcionam, comece com How KV Cache & TTL Work; para auditar as afirmações de cache de um gateway, veja Does Your LLM Gateway Lie About Cache?.

FAQ

Modelos de pesos abertos suportam cache de prompt? Os pesos definem o quão barato o cache pode ser — 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 camada de serviço. O cache é implementado no motor de inferência (vLLM, SGLang, TensorRT-LLM), herdado pelos hosts de computação e repassado (ou disperso) por gateways e roteadores. Implante o mesmo checkpoint em três hosts e você pode obter 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 roteador multi-provedor, uma requisição sem fixação de destino é balanceada entre clusters de diferentes fornecedores com preços base distintos e estado de cache disjunto. Uma chamada atingiu um provedor caro sem cache quente; outra atingiu um barato com cache quente. Fixe o upstream (restrinja a ordem dos provedores, desative fallbacks) para controlar ambos.

Se eu hospedar por conta própria, preciso pagar pelo cache? Não. O cache automático de prefixo no vLLM, SGLang e TensorRT-LLM está ativado por padrão e é gratuito — um acerto simplesmente ignora o prefill. Você paga apenas pelas GPUs que já executa, e o cache é seu, removido por LRU quando a VRAM é necessária.

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

Qual modelo de pesos abertos tem o maior desconto de cache? O cache automático em disco da DeepSeek: deepseek-v4-flash lê entrada em cache a ~$0,0028/M contra $0,14/M sem cache (~98% de desconto), reproduzido entre 97,9–99,2% em toda a linha V4 em nossos testes frio→quente. Muitos hosts de terceiros aplicam um desconto fixo de ~50%.

Há alguma pegadinha com caches que cobram taxa de armazenamento? Sim — o cache explícito moonshot-v1 da Moonshot e o cache explícito do Gemini cobram por token-tempo para manter o cache ativo (Gemini ~$1–4,50 / 1M tokens / hora). Um cache ocioso que você esqueceu de excluir continua gerando cobranças. Caches automáticos de prefixo não têm taxa de armazenamento.

Verificação: valores de custo/latência ao vivo medidos em 2026-06-14 contra um roteador multi-provedor e nosso próprio gateway, usando um prompt fixo de ~4,7K tokens, max_tokens pequeno, execuções sequenciais frio→quente; descontos calculados a partir do cost por requisição retornado. Preços documentados e mecânicas de cache verificados nos documentos primários dos provedores no mesmo dia e validados de forma adversarial; alguns valores de fornecedores (notadamente as taxas de cache explícito da Moonshot) mudam com frequência — confirme os valores atuais antes de citá-los. Seus números variarão conforme provedor, prompt, região e carga.

Fontes

• DeepSeek — Preços
• DeepSeek — Guia de cache KV / Context Caching
• Relatório Técnico DeepSeek-V3 — MLA (compressão de cache KV)
• GQA: Training Generalized Multi-Query Transformer Models (Ainslie et al.)
• Alibaba Cloud Model Studio — cache de contexto e preços
• Moonshot AI — Context Caching
• Zhipu / Z.AI — preços e cache
• vLLM — Automatic Prefix Caching
• SGLang — RadixAttention / cache
• LMCache — offloading e compartilhamento de cache KV
• Google — Gemini context caching

Todos verificados em 2026-06-14. Não constitui aconselhamento financeiro; verifique os preços atuais antes de utilizá-los como referência.

← Voltar ao blog