As 3 Camadas de Cache para LLMs

Você está pagando mais do que precisa. Provavelmente muito mais.

A maioria dos times que coloca um agente ou pipeline de LLM em produção conhece, na melhor das hipóteses, uma das três camadas de cache disponíveis. Alguns sabem que existe "prompt caching" e ativam no Anthropic. Outros já ouviram falar de semantic cache mas nunca implementaram. E poucos entenderam o que é KV cache e por que ele muda o jogo.

O problema é que as três camadas são complementares, não concorrentes. Cada uma ataca um vetor diferente de custo e latência. Ignorar qualquer uma delas é deixar dinheiro — e milissegundos — na mesa.

Neste post, vou destrinchar cada camada com dados reais, explicar quando cada uma vale a pena, e mostrar como empilhá-las corretamente.

Camada 1: KV Cache — A Base que o Dev Não Controla (mas Precisa Entender)

O KV Cache (Key-Value Cache) é a fundação. Ele opera na infraestrutura do servidor, não na sua aplicação. O que ele armazena são os tensores de atenção — as matrizes de key e value computadas durante o prefill de cada token do prompt — para que requests futuras que compartilhem o mesmo prefixo não precisem recomputar tudo do zero.

Na prática: você manda o mesmo system prompt longo em 1.000 requests consecutivas. Sem KV cache, o servidor recomputa esse prefixo 1.000 vezes. Com KV cache e um hit rate saudável, ele computa uma vez e serve as outras 999 do cache.

Os números são expressivos. Um hit rate de 90% de KV cache reduz o TTFT (Time to First Token) de vários segundos para menos de 200ms em sistemas bem configurados, e corta o custo de compute em 80-90% no lado do servidor.

O Caso ProjectDiscovery

O exemplo mais concreto que encontrei nos últimos meses foi o da ProjectDiscovery. Eles saíram de 7% para 84% de KV cache hit rate fazendo uma mudança aparentemente simples: pararam de colocar a memória dinâmica do agente (o estado que muda a cada step) dentro do system prompt, e começaram a colocá-la no final da mensagem do usuário.

O motivo é a estrutura do prefill: o KV cache funciona melhor quando o prefixo estável (system prompt, ferramentas, contexto estático) fica no começo e o conteúdo dinâmico fica no final. Quando você mistura os dois, o cache invalida com frequência.

Resultado da mudança: corte de 59% nos custos e 9,8 bilhões de tokens servidos do cache em produção.

A Manus AI resume bem: "Se eu tivesse que escolher uma única métrica, o KV-cache hit rate é a mais importante para um agente em produção."

SGLang vs vLLM

Para quem roda LLMs open source em self-hosted, a escolha do serving framework impacta diretamente o hit rate. SGLang geralmente atinge hit rates maiores em workloads complexos — multi-call, tree-of-thought, agentes com muitos steps — porque seu agendamento de requests considera explicitamente a localidade do prefixo. vLLM é mais simples de operar e entrega bons resultados para chat padrão. Se você está construindo um agente com raciocínio em múltiplas etapas, SGLang provavelmente vai se pagar.

O que você controla aqui

Pouca coisa diretamente, mas a estrutura do seu prompt importa muito:

Estático antes, dinâmico depois. System prompt completo, lista de ferramentas, instruções permanentes: tudo no começo. Histórico de conversa, contexto da task atual, inputs do usuário: tudo no final.
Não mude o que não precisa mudar. Se você injeta timestamps, UUIDs ou valores aleatórios no system prompt, você está destruindo o hit rate ativamente.
Monitore o hit rate. LangSmith e a maioria dos providers expõem essa métrica. Se está abaixo de 50%, tem algo estruturalmente errado no seu prompt.

Camada 2: Prompt Caching — O Desconto no Input que Você Precisa Ativar

O Prompt Caching é diferente do KV cache em um ponto fundamental: enquanto o KV cache é infraestrutura de servidor (transparente para você), o Prompt Caching é um recurso de API que você precisa ativar explicitamente — e que aparece na sua fatura.

O mecanismo: quando o provider detecta (ou você sinaliza) que um prefixo de prompt foi processado recentemente, ele reutiliza o estado computado do modelo para aquele prefixo em vez de processar tudo de novo. Você paga menos pelos tokens de input que vieram do cache.

Quanto menos você paga

Os preços variam por provider:

Anthropic: 0,1x no custo de input para tokens cacheados (90% de desconto). Você define breakpoints explícitos com cache_control. O cache tem TTL de 5 minutos por padrão, configurável.
OpenAI: 0,5x automático via longest-prefix caching. Sem configuração, funciona por padrão para prompts acima de 1.024 tokens. O sistema detecta o prefixo mais longo compartilhado entre requests.
Gemini: 0,1x a 0,25x dependendo do modelo, com custo adicional de storage por hora. Tem implicit caching — o provider decide quando e o quê cachear.

A diferença de abordagem importa. A Anthropic te dá controle cirúrgico (você escolhe exatamente onde o checkpoint fica no prompt). A OpenAI automatiza mas você perde visibilidade. O Gemini é um meio-termo com custo de storage que pode virar surpresa na fatura.

Números reais em eval suite

O LangChain rodou um eval suite real com Deep Agents e mediu a redução de custo de input com caching ativo:

claude-haiku-4-5: redução de 77% nos custos de input
gpt-5.4-mini: redução de 80%
gemini-3.5-flash: redução de 49%

A variação do Gemini é parcialmente explicada pelo custo de storage do cache, que reduz o benefício líquido.

Técnicas avançadas

Cache prewarm (Anthropic): você pode fazer uma request de "aquecimento" antes das requests reais chegarem — especialmente útil em sistemas com horários de pico previsíveis ou quando você acabou de atualizar um system prompt longo e quer garantir que o cache está quente antes dos usuários chegarem.

Routing Key (OpenAI, Fireworks e outros): quando você escala horizontalmente com múltiplos servidores, requests com o mesmo prefixo podem cair em servidores diferentes, destruindo o hit rate. O routing key garante que requests com o mesmo prefixo sejam roteadas para o mesmo servidor, mantendo o cache coerente.

Onde colocar os breakpoints (Anthropic): o mais eficiente é colocar breakpoints no final do system prompt completo, no final da lista de ferramentas (que muda pouco), e opcionalmente no fim de documentos grandes injetados como contexto. Não coloque breakpoints antes de conteúdo dinâmico — você vai desperdiçar o checkpoint.

Camada 3: Semantic Cache — Quando Vale Evitar a Chamada Inteira

As duas camadas anteriores reduzem o custo de uma chamada ao LLM. A Semantic Cache vai além: ela evita que a chamada aconteça.

O funcionamento: quando o usuário faz uma query, você converte ela em um embedding e compara com embeddings de queries anteriores armazenadas. Se a similaridade semântica está acima de um threshold configurado, você retorna a resposta cacheada — sem tocar no LLM.

A diferença crucial: enquanto o prompt caching reduz o custo de input, o semantic cache elimina toda a chamada — input e output. Para workloads onde o output é caro (respostas longas, raciocínio detalhado), isso é muito mais impactante.

Quando faz sentido

Redis semantic caching em workloads de alta repetição reporta até 73% de redução de custo. Mas essa métrica só aparece em contextos específicos: FAQs, suporte ao cliente com variações da mesma pergunta, assistentes de produto com perguntas recorrentes.

Para agentes autônomos executando tasks únicas, o benefício é marginal — a maioria das queries não vai ter match semântico suficiente.

As desvantagens que ninguém menciona com clareza

O semantic cache tem três problemas reais que preciso nomear:

Respostas desatualizadas. Se o estado do sistema mudou desde a query original, você vai retornar uma resposta incorreta. Em agentes que operam sobre dados mutáveis (bancos de dados, APIs, estado do filesystem), isso é um bug silencioso grave.

Calibração do threshold é difícil. Threshold alto demais: muito cache miss, você perdeu o benefício. Threshold baixo demais: você retorna respostas semanticamente similares mas contextualmente erradas. Encontrar o ponto certo exige experimentação e varia por domínio.

Latência de embedding. Cada query precisa gerar um embedding antes de consultar o cache. Em queries simples e rápidas, a latência de embedding pode ser maior que a economia gerada.

Implementações populares

GPTCache: biblioteca Python que se integra como middleware entre sua aplicação e a API do LLM. Suporta múltiplos backends de vetores.
Redis Vector Cache: parte do Redis Stack, especialmente adequado se você já usa Redis como cache de aplicação e quer adicionar a camada semântica sem outro serviço.
LangChain Semantic Cache: integração nativa no ecosystem LangChain, fácil de configurar se você já usa o framework.

Como Empilhar as Três Camadas Corretamente

As economias das três camadas não são multiplicativas — cada uma age sobre uma fatia diferente do custo total. A forma de pensar é:

Custo total = custo de input + custo de output + custo de compute do servidor

KV Cache reduz o custo de compute do servidor (transparente para você, mas impacta TTFT e, indiretamente, throughput disponível)
Prompt Caching reduz o custo de input (até 90% dos tokens de input cacheados)
Semantic Cache elimina input + output inteiros (mas só para queries com match suficiente)

A sequência prática:

1. Estrutura o prompt para maximizar KV cache hit rate. Antes de qualquer outra otimização, garanta que estático vem antes de dinâmico. Monitore o hit rate. Isso não custa nada e resolve o maior vetor de desperdício na maioria dos sistemas.

2. Ative Prompt Caching explicitamente. No Anthropic, adicione cache_control no final do system prompt e na lista de ferramentas. Na OpenAI, acontece automaticamente para prompts acima de 1.024 tokens, mas considere adicionar routing key se você escala horizontalmente. No Gemini, verifique se o implicit caching está gerando savings reais na fatura — o custo de storage pode reduzir o benefício.

3. Implemente Semantic Cache apenas onde faz sentido. Workloads com alta repetição de queries, onde respostas desatualizadas não são um problema (ou onde você consegue controlar o TTL do cache semântico), são os candidatos certos. Para agentes com tasks únicas, pule essa camada.

Métricas para monitorar:

Hit rate por camada (LangSmith exibe isso de forma granular)
TTFT — indicador direto da saúde do KV cache
Custo por trajectory (em agentes com múltiplos steps)
Cache invalidation rate — se está alto, você tem conteúdo dinâmico onde não deveria

Times que implementam as três camadas corretamente reportam custos 10x menores que times que não usam nenhuma. O número parece exagerado, mas quando você soma KV hit rate alto + 77-80% de desconto no input via prompt caching + eliminação de queries repetidas no semantic cache, o multiplicador é real em workloads de produção com volume significativo.

Conclusão

Cache de LLM não é um único problema com uma única solução. São três problemas distintos — custo de compute no servidor, custo de tokens de input, e custo de chamadas repetidas — que exigem três abordagens distintas.

O ponto de partida mais barato e de maior impacto é estruturar o prompt corretamente para maximizar o KV cache hit rate. Não custa nada e resolve uma fração enorme do desperdício. Depois você ativa prompt caching e começa a ver descontos reais na fatura. E aí, dependendo do perfil de uso da sua aplicação, avalia se semantic cache faz sentido ou não.

A ordem importa. Não vá implementar semantic cache antes de ter o KV hit rate monitorado — você está otimizando a camada errada.

Fontes:

As 3 Camadas de Cache para LLMs: Prompt Cache, Semantic Cache e KV Cache