Prompt Caching: como reduzir custos e latência em aplicações de IA

O que é prompt caching?

Prompt caching é uma técnica que reutiliza o processamento de partes idênticas ou previamente marcadas da entrada enviada a um modelo de linguagem.

Em uma primeira solicitação, o provedor processa o conteúdo cacheável e cria uma entrada temporária.

Nas solicitações seguintes, se o prefixo corresponder às regras do cache, o modelo reaproveita esse trabalho e processa apenas a parte nova.

Isso é especialmente útil porque aplicações reais costumam repetir blocos extensos: instruções de sistema, políticas, exemplos, definições de ferramentas, esquemas de saída e documentos de referência.

A pergunta ou os dados do usuário ocupam apenas o final do prompt.

Para compreender por que a entrada possui custo, vale revisar como tokens afetam contexto, preço e limites dos modelos.

Prompt caching não é cache de resposta

Um cache convencional de aplicação pode guardar a resposta final associada a uma chave.

Se a mesma consulta chegar novamente, o sistema devolve o resultado armazenado sem chamar o modelo.

Prompt caching funciona em outro nível. Ele reutiliza o processamento da entrada, mas o modelo ainda gera uma nova saída para a parte variável.

A resposta pode mudar conforme a nova pergunta, o estado da conversa, os parâmetros de geração e o comportamento probabilístico do modelo.

Estratégia	O que reutiliza	Quando faz sentido
Prompt caching	Processamento de um prefixo da entrada	Contextos longos e repetidos com saídas novas
Cache de resposta	Resposta final completa	Perguntas iguais com resultado estável
Cache semântico	Respostas para consultas consideradas semelhantes	Casos controlados em que similaridade é suficiente

Essa diferença evita um erro comum: esperar que prompt caching elimine a inferência. Ele reduz trabalho de entrada, mas a geração da saída continua consumindo tempo e tokens.

Como o prompt caching funciona

Durante a inferência, o modelo precisa transformar os tokens de entrada em representações que alimentam suas camadas de atenção. Essa etapa inicial costuma ser chamada de prefill.

Quanto maior o contexto, maior tende a ser o trabalho antes do primeiro token da resposta.

O cache conserva estados intermediários associados a um trecho já processado.

Quando uma nova solicitação começa com o mesmo conteúdo elegível, o sistema retoma o processamento a partir desse ponto em vez de reconstruir todo o prefixo.

Prefixo estável e processamento inicial

Prefixo é a sequência que aparece no começo da entrada. Em geral, uma boa organização coloca primeiro o que é compartilhado por muitas requisições e deixa informações específicas para o final.

1. Instruções de sistema estáveis.
2. Definições de ferramentas e esquemas.
3. Políticas, documentos e exemplos reutilizáveis.
4. Histórico que permanece igual entre solicitações relacionadas.
5. Dados variáveis e pergunta atual do usuário.

Se um identificador, horário ou dado personalizado for colocado antes do conteúdo estável, cada usuário poderá produzir um prefixo diferente.

O cache continuará existindo, mas será pouco reutilizado.

Cache hit e cache miss

Ocorre um cache hit quando a plataforma encontra uma entrada compatível e consegue reutilizar tokens processados.

Um cache miss acontece quando não existe correspondência, a entrada expirou, o modelo mudou ou o prefixo deixou de ser idêntico.

A documentação de prompt caching da OpenAI, por exemplo, recomenda manter instruções, ferramentas, esquemas e contexto compartilhado no começo, com conteúdo específico no final.

Imagens e ferramentas também precisam permanecer iguais e na mesma ordem para que o prefixo corresponda.

Cache automático e cache explícito

No cache automático, o provedor identifica prefixos elegíveis e administra a entrada sem exigir que a aplicação crie um objeto de cache. Ainda assim, a estrutura do prompt influencia a taxa de acerto.

No modo explícito, o desenvolvedor marca pontos de cache ou cria uma referência reutilizável.

Isso oferece controle sobre o trecho, a duração e a organização, mas também exige administrar validade, compatibilidade e possíveis custos de escrita ou armazenamento.

Não existe um modo universalmente melhor. Cache automático reduz trabalho operacional e pode atender tráfego previsível.

Cache explícito ajuda quando o contexto precisa permanecer disponível por uma janela definida ou quando a aplicação deseja separar grandes blocos reutilizáveis.

O que pode ser colocado em cache

O suporte exato varia por modelo e provedor, mas alguns elementos aparecem com frequência entre as implementações:

• Instruções longas de sistema ou desenvolvedor.
• Definições de ferramentas, funções e esquemas JSON.
• Exemplos usados para orientar formato ou estilo.
• Documentos extensos consultados por várias perguntas.
• Imagens, áudio ou arquivos quando o modelo e a API permitirem.
• Partes estáveis do histórico de uma conversa longa.

O cache não corrige um contexto mal selecionado. Repetir milhares de tokens irrelevantes pode ficar mais barato, mas continua prejudicando precisão e aumentando complexidade.

A engenharia de contexto ajuda a decidir o que realmente deve entrar no prompt.

Como organizar o prompt para aumentar cache hits

A regra prática é estável primeiro, variável depois. Ela precisa ser aplicada ao conteúdo e também à serialização que chega à API.

• Mantenha instruções compartilhadas antes de dados do usuário.
• Use uma ordem determinística para ferramentas e propriedades de esquemas.
• Não insira datas, identificadores aleatórios ou metadados dinâmicos no começo.
• Versione políticas e prompts; só altere o prefixo quando houver mudança real.
• Agrupe requisições que compartilham o mesmo contexto quando a API aceitar uma chave de cache.
• Evite reformatar documentos idênticos a cada chamada.

Imagine um assistente jurídico que recebe uma política interna com vinte mil tokens e perguntas de poucas centenas.

A política, as instruções e o esquema de resposta formam o prefixo. A dúvida, o identificador do caso e os documentos específicos entram depois.

Quando prompt caching reduz custos e latência

O ganho tende a crescer quando o prefixo é longo, estável e reutilizado muitas vezes durante a vida útil do cache.

• Assistentes com políticas extensas: as mesmas regras orientam milhares de atendimentos.
• Agentes com muitas ferramentas: definições e esquemas permanecem iguais entre tarefas.
• Análise repetida de documentos: usuários fazem diversas perguntas sobre o mesmo arquivo ou conjunto de dados.
• Conversas longas: grande parte do histórico é preservada e novas mensagens são acrescentadas no final.
• Assistentes de código: instruções e trechos estáveis do projeto são reutilizados em várias solicitações.
• Processamento em escala: muitas entradas diferentes compartilham o mesmo conjunto de regras e exemplos.

O impacto na experiência costuma aparecer no tempo até o primeiro token. Prompt caching não acelera necessariamente a geração de cada token da resposta; ele reduz o trabalho necessário antes de começar a produzi-la.

Para a percepção do usuário, essa diferença pode complementar o streaming de respostas de IA, que exibe a saída progressivamente.

Quando o cache não compensa

Cache é uma otimização baseada em reutilização. Sem repetição suficiente, a aplicação pode pagar pela escrita ou manutenção de uma entrada que quase nunca será lida.

• Prompts abaixo do tamanho mínimo exigido pelo modelo.
• Solicitações únicas ou tráfego muito esporádico.
• Conteúdo personalizado colocado no início de cada entrada.
• Documentos que mudam em quase todas as chamadas.
• Alteração frequente de modelos, ferramentas ou esquemas.
• Restrições de retenção incompatíveis com o mecanismo oferecido.

Também pode haver uma otimização mais simples. Se o contexto é grande porque a aplicação envia tudo indiscriminadamente, selecionar apenas trechos relevantes ou resumir o histórico pode gerar mais economia do que armazenar um prefixo excessivo.

Como calcular o ponto de equilíbrio

O cálculo precisa comparar o custo do prefixo sem cache com o custo de escrevê-lo e lê-lo novamente. Use os valores reais do modelo escolhido, porque preços, mínimos e regras variam.

Considere:

• U: custo de processar o prefixo sem cache.
• W: custo de escrever o prefixo no cache.
• R: custo de ler o prefixo do cache.
• N: quantidade total de usos durante a validade.

Sem cache, o prefixo custa aproximadamente N × U. Com cache, custa W + (N − 1) × R. A otimização compensa quando a segunda expressão é menor.

Não limite a análise ao preço. Compare também tempo até o primeiro token, taxa de acerto, uso de entrada, expiração e custo operacional.

Uma economia teórica pode desaparecer se metade das solicitações produzir cache miss por diferenças no prefixo.

Diferenças entre provedores

As plataformas usam o mesmo princípio geral, mas diferem em ativação, pontos de cache, duração, cobrança, métricas e modelos compatíveis.

Plataforma	Abordagem documentada	Ponto de atenção
OpenAI	Cache automático em solicitações elegíveis e controles explícitos em famílias compatíveis	Correspondência exata do prefixo, modelo e limites aplicáveis
Anthropic	Cache automático ou marcações explícitas de conteúdo	Validade, tamanho mínimo e custo de escrita e leitura
Gemini API	Cache implícito e, em APIs compatíveis, objetos de cache explícito	API utilizada, TTL e custo de armazenamento
Amazon Bedrock	Checkpoints de cache em modelos e operações compatíveis	Campos permitidos, mínimos e suporte do modelo

A documentação da Anthropic descreve prefixos reutilizáveis e pontos explícitos. O guia de context caching do Gemini diferencia mecanismos implícitos e explícitos.

Já o Amazon Bedrock trabalha com checkpoints em modelos suportados.

Consulte novamente essas páginas antes de implementar. Uma regra correta hoje pode mudar com novos modelos, APIs ou políticas comerciais.

Segurança, privacidade e retenção

Um prefixo cacheável pode conter documentos internos, histórico, instruções ou dados pessoais.

Antes de ativar a otimização, confirme como o provedor isola o cache, por quanto tempo mantém o conteúdo e quais compromissos de retenção se aplicam ao plano utilizado.

• Não coloque senhas, tokens de acesso ou chaves de API no prompt.
• Remova dados pessoais que não sejam necessários para a tarefa.
• Separe contextos entre organizações, usuários ou níveis de permissão.
• Não use a mesma chave de agrupamento para dados que não podem se misturar.
• Valide requisitos contratuais, regulatórios e de residência de dados.
• Defina como invalidar contextos quando políticas ou permissões mudarem.

Cache não deve se transformar em justificativa para enviar mais informações do que o necessário. Segurança e economia começam pela minimização do contexto.

Como medir cache hit, custo e latência

Uma implementação só deve ser considerada bem-sucedida depois que os ganhos aparecem em dados de produção ou em um teste representativo.

• Tokens lidos do cache: mostra quanto do prefixo foi realmente reutilizado.
• Tokens escritos no cache: ajuda a identificar reconstruções frequentes.
• Taxa de cache hit: proporção de solicitações que obtiveram reaproveitamento.
• Tempo até o primeiro token: captura o impacto mais direto do prefill.
• Latência total: inclui também geração, rede e ferramentas.
• Custo médio por solicitação: compara antes e depois da mudança.
• Motivos de cache miss: modelo, expiração, ordem, conteúdo ou chave diferente.

Segmente métricas por modelo, versão do prompt, rota e tipo de tarefa. Uma média geral pode esconder um fluxo com excelente reaproveitamento e outro que reescreve o cache continuamente.

Para integrar esses sinais ao restante da aplicação, o conteúdo sobre OpenTelemetry explica como correlacionar traces, métricas e logs. Avaliações de qualidade também devem continuar: reduzir custo não pode degradar a tarefa, e evals em IA ajudam a comparar o comportamento antes e depois.

Checklist de implementação

1. Meça tokens, custo e latência atuais para criar uma linha de base.
2. Identifique o maior prefixo realmente compartilhado entre solicitações.
3. Coloque conteúdo estável antes de campos variáveis.
4. Confirme suporte, tamanho mínimo, TTL, preço e métricas do modelo.
5. Escolha cache automático ou explícito de acordo com o fluxo.
6. Remova dados e segredos desnecessários do conteúdo cacheável.
7. Teste cache hit, cache miss, expiração e mudança de versão.
8. Compare custo e tempo até o primeiro token em tráfego representativo.
9. Monitore qualidade, falhas e reconstruções depois da implantação.

Erros comuns em prompt caching

• Mudar o começo do prompt em toda solicitação: datas e identificadores dinâmicos quebram o prefixo compartilhado.
• Confundir cache hit com resposta em cache: a saída continua sendo gerada.
• Ignorar custo de escrita: poucas reutilizações podem não pagar a criação da entrada.
• Não observar tokens cacheados: ativar um recurso não significa que ele está funcionando.
• Enviar contexto irrelevante: cache mais barato não torna informação desnecessária útil.
• Acoplar o sistema a uma regra de provedor: mínimos, TTLs e campos podem mudar entre modelos.
• Esquecer invalidação: políticas antigas podem continuar reutilizadas até a expiração.

Perguntas frequentes

Prompt caching reduz a qualidade da resposta?

Não deveria. O cache reutiliza o processamento de conteúdo idêntico; ele não resume nem remove informações. Ainda assim, a aplicação deve testar resultados porque mudanças na organização do prompt podem afetar o modelo.

O modelo reutiliza a resposta anterior?

Não. Prompt caching reaproveita estados de processamento da entrada, mas o modelo gera uma nova resposta para a solicitação atual.

Prompts curtos podem usar cache?

Depende do provedor e do modelo. Muitas implementações exigem um tamanho mínimo de prefixo; abaixo desse limite, a métrica de tokens cacheados permanece zerada.

Alterar uma palavra invalida todo o cache?

A alteração impede a correspondência a partir do ponto modificado. Se ela acontece no início, grande parte do prefixo deixa de ser reutilizável; se ocorre no final, o trecho anterior ainda pode continuar compatível, conforme as regras da plataforma.

Prompt caching substitui uma janela de contexto menor?

Não. O conteúdo cacheado ainda faz parte da entrada lógica e conta para os limites definidos pelo modelo. O cache otimiza processamento e cobrança, mas não cria uma janela ilimitada.

Todo projeto de IA precisa de prompt caching?

Não. Projetos com prompts curtos, pouco tráfego ou conteúdo quase sempre diferente podem obter mais benefício simplificando o contexto, escolhendo outro modelo ou reduzindo a saída.

Conclusão

Prompt caching é uma otimização útil quando muitas solicitações compartilham um prefixo longo e estável.

Ele evita reprocessamento, pode reduzir custo de entrada e diminui o tempo necessário antes do início da resposta.

O resultado depende menos de simplesmente ativar o recurso e mais de organizar o contexto, preservar a ordem, medir tokens cacheados e comparar escrita com reutilização.

Comece por um fluxo de alto volume, crie uma linha de base e mantenha a solução apenas se custo, latência e qualidade melhorarem juntos.