Neste artigo
- O que é prompt caching para LLMs e por que importa
- Quando prompt caching faz diferença de verdade
- Caching exato vs caching semântico: qual escolher
- Como pensar a implementação sem virar engenheiro de infra
- O que medir para saber se o prompt caching funcionou
- Quando prompt caching não resolve
- Dúvidas comuns sobre prompt caching para LLMs
- Conclusão e próximo passo
A fatura do LLM chegou mais alta do que no mês passado. Alguém no time sugere trocar para um modelo mais barato. O CTO encaminha uma tabela comparativa. E você está prestes a repetir o mesmo ciclo: migrar, ajustar prompts, testar saídas, descobrir que o modelo mais barato quebra fluxos específicos, migrar de volta ou aceitar qualidade pior.
O problema, na maioria dos casos que vi, não é qual modelo você está usando. É que você está pagando o custo de processamento completo para o mesmo conteúdo em cada requisição. Instruções de sistema com 2000 tokens, reprocessadas milhares de vezes por dia. Documentos de contexto que não mudam entre chamadas. Histórico de conversa enviado por inteiro a cada turno.
Trabalho com LLMs em produção num produto B2B e esse padrão aparece em praticamente toda revisão de arquitetura que faço. A conta sobe, o primeiro instinto é trocar o modelo, e a resposta que realmente funciona é menos glamorosa: parar de processar a mesma coisa repetidamente.
Este artigo explica o que é prompt caching para LLMs, quando faz diferença de verdade, como escolher entre as duas abordagens principais e, o ponto que mais importa, como medir se funcionou. Porque ‘habilitei o caching’ não é métrica.
O que é prompt caching para LLMs e por que importa
Prompt caching é uma estratégia que permite que partes de um prompt, especificamente as partes que se repetem em muitas requisições, sejam processadas uma vez e reutilizadas. Em vez de a API processar 3000 tokens a cada chamada, ela processa 500 tokens novos e reutiliza os 2500 que já foram computados.
Os principais provedores já implementaram isso em nível de infraestrutura. Mas saber que a funcionalidade existe e saber quando ela gera ROI real são coisas distintas. Muitos times habilitam o caching sem definir o que ‘funcionou’ significa e ficam sem clareza sobre se o investimento valeu.
Quando prompt caching faz diferença de verdade
Nem todo sistema se beneficia. Três sinais indicam que o caching tem potencial real:
Sistema com contexto fixo e longo
Se o seu prompt de sistema tem mais de 1000 tokens de instruções, persona, regras ou exemplos, e esse conteúdo não muda entre requisições, você é candidato forte para caching. Cada chamada que reprocessa esse prompt do zero é custo desnecessário.
Muitas requisições com prefixo compartilhado
Sistemas de análise de documentos, chatbots com base de conhecimento extensa, agentes que sempre partem do mesmo estado. Quando muitas requisições compartilham o mesmo começo, fazer cache desse começo pode reduzir custo de forma significativa. O ganho é proporcional à razão entre contexto repetido e conteúdo novo.
Custo por requisição subindo sem aumento proporcional de complexidade
Se você está processando mais requisições de complexidade similar, mas o custo médio por requisição está aumentando, vale verificar se o prompt cresceu ao longo do tempo, talvez por instruções acumuladas ou contexto adicionado, sem ganho correspondente.
Caching exato vs caching semântico: qual escolher
São duas abordagens diferentes e a escolha importa.
Caching exato
Funciona comparando sequências de tokens idênticas. Se o começo do prompt é exatamente igual ao de uma chamada anterior, aquela parte é reutilizada. Isso é o que provedores como a Anthropic oferecem nativamente na API. Vantagem: previsível e confiável. Limitação: qualquer alteração no prompt, mesmo um caractere, invalida o cache para aquele prefixo.
Caching semântico
Funciona de forma diferente: armazena não os tokens em si, mas o significado de perguntas e respostas anteriores. Quando uma nova pergunta chega semanticamente similar a uma armazenada, a resposta em cache é retornada. Mais flexível, mas exige uma camada de banco de dados vetorial e a aceitação de que duas respostas ‘similares’ podem não ser idênticas. O risco aqui é sutil: a resposta cacheada foi gerada num contexto levemente diferente e pode estar ligeiramente errada no novo.
Por onde começar
Comece pelo caching exato. É mais simples, tem suporte nativo, não exige infraestrutura adicional e o ganho é mensurável imediatamente. O caching semântico faz sentido quando a mesma pergunta tem genuinamente a mesma resposta independente do contexto e quando você já esgotou os ganhos do caching exato.
Como pensar a implementação sem virar engenheiro de infra
A decisão de implementar prompt caching é arquitetural, não necessariamente técnica. Antes de pedir para alguém implementar qualquer coisa, responda três perguntas:
- Qual parte do meu prompt é fixa e qual varia por requisição?
- Qual percentual do total de tokens está na parte fixa?
- Com que frequência recebo requisições que compartilham essa parte fixa?
Se a parte fixa representa menos de 30% do total de tokens por requisição, o ganho será modesto. Se representa 70% ou mais, o potencial é significativo. Essas não são perguntas de implementação. São perguntas que você responde olhando para a estrutura do seu prompt e o volume de requisições.
A conversa com quem vai implementar é: ‘quero fazer cache desse prefixo específico. Qual é a condição de invalidação e como vamos acompanhar a taxa de acerto?’
O que medir para saber se o prompt caching funcionou
‘Habilitei o caching’ não é métrica. Essas são:
- Taxa de acerto do cache (cache hit rate): percentual das requisições que efetivamente reutilizaram o cache. Abaixo de 40% significa que algo está quebrando o cache mais do que o esperado.
- Custo por requisição antes e depois: não o custo total, que pode estar subindo por volume, mas o custo médio por requisição individual.
- Latência: prefixos cacheados reduzem o tempo de processamento. Se o tempo médio de resposta não caiu, vale verificar se o caching está sendo aplicado de fato.
- Distribuição de cache miss: quando o cache não está sendo acionado, é sempre pelo mesmo motivo? Um prompt com miss frequente muitas vezes indica problema estrutural, talvez o prefixo esteja sendo modificado sem intenção.
Se não conseguir medir tudo isso agora, comece pelo custo por requisição. É o número que deixa o argumento de negócio claro.
Quando prompt caching não resolve
Isso precisa ser dito claramente, porque já vi times investirem em caching esperando reduzir a conta pela metade e encontrarem ganhos modestos.
Caching não ajuda quando:
- Cada requisição tem um prompt substancialmente diferente do anterior.
- O prompt de sistema é curto, abaixo de 500 tokens, então a razão entre conteúdo cacheável e total é baixa.
- O volume de requisições é pequeno, então mesmo com 100% de hit rate a economia absoluta é irrelevante.
- O time muda o prompt de sistema com frequência, o que invalida o cache e mantém a taxa de acerto baixa.
Nesses casos, o caminho certo costuma ser roteamento de modelos: usar um modelo menor para tarefas simples e reservar o maior para as genuinamente complexas. O princípio é o mesmo: mede primeiro, depois decide onde o problema realmente está.
Dúvidas comuns sobre prompt caching para LLMs
Caching funciona com qualquer provedor de LLM?
Não. Os principais provedores já têm suporte nativo, mas os detalhes de implementação, tamanhos mínimos de tokens e precificação para cache hits variam. Consulte a documentação específica do seu provedor antes de assumir que o comportamento será idêntico.
O cache fica ativo indefinidamente?
Não. Existe um TTL (tempo de vida) que varia por provedor. Quando o cache expira, a próxima requisição reprocessa o prefixo inteiro. Isso importa para o planejamento: se as suas requisições ficam espaçadas no tempo, o cache pode expirar entre chamadas e o ganho desaparece.
Caching afeta a qualidade das respostas?
Para caching exato: não, porque o modelo processa os mesmos tokens de antes. Para caching semântico: potencialmente sim, se a resposta cacheada foi gerada num contexto levemente diferente. Esse é o principal risco a monitorar quando você usa caching semântico.
Vale a pena para sistemas de baixo volume?
Raramente. O caching brilha quando há muitas requisições compartilhando o mesmo prefixo. Para um sistema que gera 50 requisições por dia, a economia absoluta em reais provavelmente será menor do que o custo de tempo de implementar e monitorar a camada de caching. Vale ter uma base de comparação de custo e latência de LLMs antes de qualquer mudança.
Conclusão e próximo passo
Prompt caching para LLMs é uma daquelas otimizações que parece simples mas exige clareza antes da implementação. O ganho é real quando as condições são as certas. O erro mais comum que vejo é tratar o caching como configuração padrão em vez de decisão arquitetural com critério mensurável.
Se você quer avaliar se o seu sistema se beneficiaria, o próximo passo é:
- Mapear qual percentual do seu prompt médio é fixo versus variável
- Verificar o volume de requisições e com que frequência a parte fixa se repete
- Definir a métrica que vai usar para declarar sucesso antes de implementar qualquer coisa
Sem essa base, você vai habilitar o caching, olhar para o custo total subindo por causa do volume crescente e concluir que não funcionou, quando na verdade nunca teve como saber. Se quiser ir além, o tema de janela de contexto de LLMs cobre como estruturar o prompt para aproveitar melhor cada token antes mesmo de pensar em caching.
