Prompt caching em LLMs: quando o contexto fixo compensa

Prompt caching reduz o custo por requisição quando a maior parte do seu prompt é fixa e se repete entre chamadas. Não é heurística, é aritmética: se você manda 4 mil tokens de contexto fixo e 500 tokens de pergunta em cada requisição, está pagando pelos mesmos 4 mil tokens do zero toda vez. Com cache ativo, você paga uma fração disso a partir da segunda chamada.

A técnica existe há um tempo mas ainda é subutilizada, principalmente porque exige reorganizar o prompt e entender como o cache funciona antes de ativar. Esse texto cobre exatamente isso.

Por que o mesmo contexto custa tokens toda vez

LLMs não têm memória entre chamadas de API. Cada requisição começa do zero, independente de você ter enviado exatamente o mesmo system prompt 500 vezes antes. O modelo lê, processa e cobra os tokens de entrada como se fosse a primeira vez.

Isso não é bug, é arquitetura. Stateless por design. Mas quando o volume sobe, essa propriedade se transforma em custo visível e previsível.

O que é prompt caching

Prompt caching é uma funcionalidade de provedores de LLM que permite marcar blocos do prompt para armazenamento no servidor. Na primeira requisição, o provedor processa o bloco e guarda o estado intermediário. Nas requisições seguintes que incluem o mesmo bloco, ele reutiliza o estado armazenado em vez de reprocessar.

O resultado prático: tokens que vieram do cache custam significativamente menos do que tokens processados normalmente. Na Anthropic, tokens de cache hit custam 10% do valor dos tokens de entrada comuns. A documentação oficial de prompt caching da Anthropic detalha os valores e as condições de uso por modelo.

O cache tem tempo de vida (TTL). Depois que expira, o bloco é processado e armazenado de novo na próxima requisição. O TTL varia por provedor e por plano, mas costuma ficar entre 5 e 60 minutos.

Quando prompt caching compensa de verdade

O critério de decisão é a proporção de tokens fixos vs. variáveis na sua requisição típica.

Compensa quando você tem:

• System prompt longo e estável (instruções do produto, regras de negócio, persona do assistente)
• Contexto de documentos que não muda entre usuários (manual, FAQ, termos de uso)
• Exemplos few-shot extensos que se repetem em toda chamada
• Histórico de conversa longo que você reenvia a cada turno

Não compensa quando o prompt é majoritariamente variável, quando o volume é baixo (o cache expira antes da próxima chamada), ou quando os intervalos entre requisições são maiores que o TTL.

Um sistema com 50 requisições por dia e intervalos irregulares vai ter hit rate baixo e pouca redução de custo. Um sistema de chat com 500 usuários simultâneos e system prompt de 3 mil tokens tem retorno imediato.

Se você ainda não tem clareza sobre o quanto custa seu sistema hoje, o post sobre como estimar e controlar o custo de LLMs em produção cobre o breakdown de tokens que você precisa fazer antes de qualquer otimização.

Como organizar o prompt para maximizar o cache

O cache funciona como prefixo. O provedor armazena os primeiros N tokens como unidade cacheada. Se qualquer coisa mudar antes do bloco que você quer cachear, o cache quebra.

A ordem ideal dentro do prompt é:

• Primeiro: system prompt completo (instruções, regras, persona)
• Segundo: contexto fixo (documentos, exemplos, base de conhecimento estática)
• Terceiro: histórico de conversa, do mais antigo para o mais recente
• Por último: a mensagem atual do usuário

Essa estrutura garante que o prefixo fixo seja sempre idêntico entre requisições. Qualquer variação só acontece ao final, preservando o bloco cacheável.

Detalhe importante: você precisa sinalizar explicitamente onde o cache deve terminar. A forma varia por provedor, mas a lógica é a mesma: você marca o fim do bloco cacheável dentro da estrutura da requisição. Sem essa marcação, o cache não é ativado mesmo que o prompt esteja organizado corretamente.

O que medir para saber se o prompt caching está funcionando

Aqui é onde a maioria das implementações para de acompanhar, e é exatamente onde você não deveria parar.

As três métricas que importam, por requisição:

Cache hit rate: percentual dos tokens de entrada que veio do cache. Abaixo de 60% em produção é sinal de que o prompt está variando mais do que deveria, ou que o TTL está expirando entre as chamadas.

Custo por requisição antes e depois: compare o custo médio de uma semana antes de ativar o cache com uma semana depois, no mesmo volume. Não confie só na projeção, meça o gasto real.

Time-to-first-token: o cache reduz o processamento do prefixo, então você deveria ver queda nessa métrica específica. Se a latência total não mudou, o gargalo está em outro lugar, não no processamento do contexto. O post sobre latência de LLM em produção: onde medir e como otimizar cobre como separar as partes da latência para identificar isso.

Se você usa Langfuse para rastreamento, esses campos aparecem nos metadados de uso da resposta da API. Sem rastreamento por requisição, você está estimando no escuro. O post sobre rastreamento de LLMs com Langfuse em Docker cobre como configurar isso do zero.

Prompt caching, contexto longo e RAG: qual problema cada um resolve

As três técnicas lidam com "mais informação para o modelo", mas resolvem problemas diferentes.

Contexto longo é sobre incluir documentos extensos em uma única requisição. RAG é sobre recuperar dinamicamente só o trecho relevante de uma base grande. Prompt caching é sobre reutilizar o processamento de um bloco fixo em múltiplas requisições.

Quando a base de conhecimento muda por usuário ou por consulta, RAG faz mais sentido, como discute o post sobre quando montar um pipeline de RAG na prática. Quando você tem um conjunto fixo de instruções ou documentos que vai em toda requisição, prompt caching reduz custo sem mudar a lógica de recuperação.

As técnicas coexistem bem. Um sistema com RAG ainda pode usar cache no system prompt e nos exemplos few-shot. A parte recuperada pelo RAG (o trecho variável) vai no final do prompt, preservando o prefixo cacheável intacto.

O que acontece quando você ignora prompt caching em produção

O sistema continua funcionando. A fatura continua chegando. Sem alerta, sem aviso.

O problema com custo de tokens é que ele escala silenciosamente. Uma aplicação com 5 mil requisições por mês e 4 mil tokens fixos por chamada está processando 20 milhões de tokens de contexto repetido. Com cache ativo e hit rate de 80%, isso cai para 4 milhões de tokens processados do zero. Em modelos de custo mais alto, a diferença mensal é material.

Spoiler: a maioria das pessoas só descobre isso quando vai revisar a fatura depois de escalar. Não é o momento ideal para perceber.

Perguntas frequentes sobre prompt caching

Todos os modelos suportam prompt caching?

Não. Cada provedor define quais modelos têm suporte. Na Anthropic, está disponível para Claude 3 Haiku, Claude 3.5 Sonnet, Claude 3 Opus e versões mais recentes. Verifique a documentação do seu provedor antes de reorganizar o pipeline, porque ativar cache em um modelo sem suporte não gera erro, simplesmente não funciona.

O cache é compartilhado entre os usuários da minha aplicação?

Não diretamente. O cache é vinculado à sua chave de API e ao bloco específico de texto. Se dois usuários diferentes recebem o mesmo system prompt, você reutiliza o mesmo cache. Contas distintas não compartilham cache entre si.

O cache pode retornar respostas incorretas?

Não. O cache armazena o estado de processamento do prompt, não a resposta em si. O modelo ainda gera a resposta normalmente a cada requisição. O que muda é apenas a eficiência do processamento do contexto fixo.

Quanto tempo o cache fica disponível?

Varia por provedor. Anthropic tem TTL padrão de 5 minutos. Se o intervalo entre requisições for maior que isso, o cache expira e você paga o processamento completo novamente. Sistemas de baixo volume ou uso esporádico têm retorno menor exatamente por esse motivo.

Como confirmar que o cache está sendo usado de fato?

A resposta da API inclui campos separando tokens lidos do cache e tokens criados em cache por requisição. Se você não está logando esses campos por chamada, não tem visibilidade real do hit rate. Configure seu sistema de rastreamento para capturar esses valores antes de afirmar que o cache está ativo e funcionando.

Prompt caching compensa, mas só quando você mede antes de concluir

A primeira coisa a fazer não é ativar o cache. É analisar o breakdown de tokens nas suas requisições típicas e calcular a proporção de tokens fixos vs. variáveis.

Se os tokens fixos representam menos de 50%, o impacto vai ser marginal. Se representam 70% ou mais, você tem um caso de otimização com retorno mensurável em dias, não meses.

O passo seguinte é reorganizar o prompt para que o prefixo fixo venha antes de qualquer variável, marcar o bloco cacheável na estrutura da requisição e monitorar o cache hit rate nas primeiras semanas. A diferença no custo por requisição vai aparecer nos metadados da API antes mesmo de chegar na fatura.

Próximos passos:

• Calcule a proporção de tokens fixos vs. variáveis em uma amostra das suas últimas requisições, esse é o sinal mais claro de que prompt caching vai ajudar
• Configure rastreamento por requisição para capturar o cache hit rate antes de tirar qualquer conclusão sobre a eficiência do cache
• Se o hit rate ficar abaixo de 60% nas primeiras semanas, revise a ordem dos blocos no prompt e verifique se o TTL está sendo respeitado pelo volume e ritmo de requisições do seu sistema