O cache de prompts está reduzindo os custos de inferência de IA em até 90 por cento, e a maioria das equipes não está usando corretamente

A maioria das equipes que pagam pelo acesso à API de modelos de linguagem grandes (LLM) está deixando de 50 a 90 por cento de economia potencial na mesa, embora o mecanismo para capturá-la exista em produção há mais de um ano. O cache de prompts permite que um provedor de API reutilize o processamento já feito para as partes invariáveis de uma requisição — instruções do sistema, definições de ferramentas (tools), documentos de referência longos — em vez de reprocessá-las a cada chamada.

O problema não é que o cache de prompts não funcione. É que a maioria das equipes de engenharia estrutura seus prompts de uma forma que anula esse benefício antes mesmo de ele começar a ajudar, e então concluem que o recurso "não fez diferença" para o caso de uso delas.

Como o cache realmente funciona

Quando um modelo transformer processa um prompt, ele calcula pares chave-valor (KV) para cada token de entrada — as representações internas que o modelo usa para prever o próximo token. Esse cálculo é a parte cara da inferência, e escala com o comprimento da entrada. O cache de prompts armazena esses pares KV nos servidores do provedor após uma primeira requisição, indexados exatamente ao mesmo prefixo de tokens que os produziu.

Em uma requisição subsequente, se o novo prompt compartilha esse mesmo prefixo, o provedor pula o recálculo dos pares KV para a parte compartilhada e processa apenas os novos tokens adicionados ao final. A implementação da Anthropic, por exemplo, cobra aproximadamente 10 por cento da tarifa base de tokens de entrada para leituras de cache e cerca de 25 por cento a mais que a tarifa base pela escrita inicial no cache — uma troca que se paga rapidamente para qualquer prefixo reutilizado mais de duas vezes. O cache automático de prompts da OpenAI aplica um desconto de 50 por cento em tokens de entrada armazenados em cache sem custo de escrita separado, e o cache de contexto do Google nos modelos Gemini funciona de forma semelhante, com um objeto de cache explícito que você cria e referencia.

De onde vem a economia real

A economia não é teórica. Um agente de atendimento ao cliente que inclui um prompt de sistema de 3.000 tokens, um trecho de base de conhecimento de produto de 5.000 tokens e um conjunto de definições de ferramentas de 2.000 tokens em cada chamada paga por 10.000 tokens de entrada antes mesmo de a pergunta real do usuário — talvez 50 tokens — entrar em cena. Em uma aplicação de alto volume processando dezenas de milhares de requisições por dia, essa sobrecarga ofusca amplamente o custo marginal da própria consulta.

Com o cache configurado corretamente, esse prefixo de 10.000 tokens é calculado uma vez e depois lido do cache em cada chamada subsequente dentro da janela de tempo de vida do cache (TTL, tipicamente 5 minutos no nível padrão da Anthropic, extensível a uma hora em alguns provedores). O efeito prático para um pipeline RAG com uma grande janela de contexto recuperado, ou um agente com um esquema extenso de chamadas de ferramentas, é uma redução de 60 a 80 por cento no custo efetivo de entrada — sem qualquer mudança na qualidade do modelo, no comportamento de saída, ou em qualquer latência perceptível ao usuário. A latência, na verdade, melhora ligeiramente, já que tokens em cache pulam completamente o forward pass.

O erro que mata a taxa de acerto do cache

O cache de prompts só funciona em correspondências exatas de prefixo. Se um único token mudar em qualquer ponto antes do limite em cache, toda a entrada de cache falha (miss) e o provedor recalcula do zero. É aqui que a maioria das implementações sabota a si mesma silenciosamente.

O padrão de falha mais comum: colocar conteúdo dinâmico — um timestamp, um ID de sessão, uma lista de documentos recuperados em ordem aleatória — perto do início do prompt, antes das instruções estáticas do sistema e das definições de ferramentas. Cada requisição então tem um prefixo único, e o cache nunca tem chance de acumular acertos. A correção é mecânica, mas exige disciplina: estruturar cada prompt para que o conteúdo estático venha primeiro (instruções do sistema, exemplos few-shot, esquemas de ferramentas, documentos de referência estáveis) e o conteúdo variável por último (a mensagem real do usuário, a data atual se necessário, o estado específico da sessão).

Um segundo erro comum é a personalização excessiva do prompt. Equipes que injetam preferências específicas do usuário ou detalhes de conta diretamente no prompt do sistema — em vez de passá-los como um bloco separado e claramente delimitado após o prefixo cacheável — destroem sua própria taxa de acerto de cache por uma melhoria marginal de qualidade que muitas vezes nem é mensurável. Se os dados de personalização mudam por usuário ou por sessão, eles devem ficar depois do limite do cache, não entrelaçados nas instruções compartilhadas.

O contexto recuperado é o caso mais difícil

Aplicações RAG enfrentam uma tensão arquitetônica genuína: todo o propósito da recuperação é trazer documentos diferentes para consultas diferentes, o que por definição quebra a correspondência de prefixo no próprio conteúdo recuperado. A correção de maior impacto aqui não é armazenar em cache os trechos recuperados — é armazenar em cache tudo ao redor deles. Mantenha o prompt do sistema, as instruções de recuperação e a especificação do formato de saída em um prefixo estável, e trate os documentos recuperados como o sufixo variável. Equipes que operam grandes bibliotecas de ferramentas podem obter um ganho adicional armazenando em cache o bloco de definições de ferramentas separadamente do conteúdo recuperado, já que os esquemas de ferramentas raramente mudam dentro de uma sessão mesmo quando a consulta muda.

Medindo corretamente

Os painéis dos provedores tipicamente reportam contagens de tokens de leitura e escrita de cache separadamente dos tokens de entrada padrão, o que facilita calcular a taxa de acerto real: leituras de cache divididas pelo total de tokens elegíveis a prefixo. As equipes devem rastrear esse número explicitamente em vez de inferir a economia a partir da fatura total, já que uma taxa de acerto baixa pode se esconder atrás de uma fatura aparentemente razoável se o volume de requisições também estiver flutuando.

Conclusões práticas

Audite primeiro a estrutura do seu prompt: o conteúdo estático (instruções do sistema, esquemas de ferramentas, documentos de referência) deve vir antes de qualquer conteúdo variável por requisição, sem exceções.
Não personalize dentro do prefixo cacheável — injete dados específicos do usuário como um bloco claramente separado após as instruções compartilhadas.
Em pipelines RAG, armazene em cache o arcabouço estável ao redor do conteúdo recuperado, não o conteúdo recuperado em si.
Rastreie a taxa de acerto do cache como uma métrica explícita, não como algo inferido do gasto total.
Verifique a janela TTL do seu provedor e os padrões de tráfego — lacunas de tráfego mais longas que a janela TTL forçarão uma nova escrita de cache independentemente da estrutura do prompt.