Prompt Caching na prática: como reduzir custos de LLMs em até 90%

O que é prompt caching e por que sua equipe provavelmente está usando errado

O prompt caching é a alavanca de redução de custo mais poderosa que a maioria das equipes de produção tem configurada — mas da qual não estão realmente se beneficiando. Um caso documentado da ProjectDiscovery ilustra o problema: um agente de inteligência de segurança enviava as mesmas 4.000 tokens de instruções de sistema, definições de ferramentas e framework de análise em cada requisição, seguidas pelos dados específicos da ameaça a avaliar — e ainda assim mantinha uma taxa de acerto de cache de apenas 7%.

Uma única mudança estrutural — mover um identificador dinâmico do meio do prompt para o final — elevou a taxa de acerto para 74% e reduziu a conta mensal de inferência em 59%.

Os três tipos de cache que você precisa conhecer

“Caching” significa três coisas diferentes no contexto de inferência de LLMs. Confundi-las leva a esforços de otimização mal direcionados:

1. KV Cache — automático, dentro de uma única requisição. Armazena estados de atenção key-value para cada token de entrada durante a decodificação. Está sempre ativo, não requer configuração e acelera a geração dentro de uma requisição. Você não o controla; beneficia-se dele automaticamente.

2. Prompt Cache (Prefix Cache) — entre requisições, controlado por você. Quando múltiplas requisições compartilham os mesmos tokens iniciais (system prompt, few-shot examples, documentos de referência), o modelo reutiliza os estados KV já computados em vez de recalculá-los a cada chamada. Este é o cache que este artigo aborda.

3. Cache Semântico — camada de aplicação, sistema separado. Armazena pares completos de input-output e os recupera quando uma nova consulta é semanticamente similar a uma anterior, usando similaridade de embeddings. Complementa o prefix cache, não o substitui.

A economia do caching: break-even após apenas 1 hit

Os números justificam a otimização. Na Anthropic (Claude), uma escrita de cache custa 1,25× a taxa base de input (TTL de 5 minutos) e uma leitura de cache custa 0,10× — um desconto de 90%. Com Claude Sonnet 4.6 a US$ 3,00 por milhão de tokens de input, você paga US$ 3,75 para gravar a entrada em cache e US$ 0,30 cada vez que a lê.

Se um prefixo em cache for lido 10 vezes antes de expirar, o custo total é US$ 3,75 + US$ 0,30 × 10 = US$ 6,75 — contra US$ 3,00 × 11 = US$ 33,00 sem caching. Uma redução de 80% com um volume modesto de hits.

O ponto de equilíbrio é calculado com a fórmula h* = (w − 1) / (1 − r), onde w é o multiplicador de escrita e r é o de leitura. Com as taxas do tier de 5 minutos da Anthropic (w = 1,25, r = 0,10), temos h* ≈ 0,28 — ou seja, basta 1 cache hit para que o caching compense. Todo hit adicional é economia pura.

No OpenAI, o desconto de cached-input varia por geração de modelo: historicamente 50% na família GPT-4o, migrando para 90% nos modelos mais recentes. Verifique a taxa do seu modelo específico.

O erro que reduz sua taxa de acerto para um dígito

O erro cometido pela equipe da ProjectDiscovery — e pela maioria das equipes na primeira implementação — é posicionar um campo dinâmico no meio do prefixo cacheável.

O prefix cache exige conteúdo idêntico byte a byte a partir do primeiro token. Qualquer alteração — um caractere, um campo que varia entre requisições — redefine a fronteira do cache naquele ponto. Se um session_id, um timestamp ou uma configuração por usuário aparece no meio de um template que é 90% idêntico, o cache só cobre os tokens até a primeira diferença. Tudo depois é recalculado do zero em cada requisição.

Exemplo prático (Anthropic-style):

// ❌ QUEBRADO — session_id dentro do bloco cacheado
{
  "system": [{
    "type": "text",
    "text": "Session 4f9a-2c1e. Você é um agente de suporte. [...600 linhas...]",
    "cache_control": {"type": "ephemeral"}
  }],
  "messages": [{"role": "user", "content": "Como troco minha senha?"}]
}
// Resultado: 0% de cache hit

// ✅ CORRIGIDO — session_id movido para o user turn
{
  "system": [{
    "type": "text",
    "text": "Você é um agente de suporte. [...600 linhas...]",
    "cache_control": {"type": "ephemeral"}
  }],
  "messages": [{"role": "user", "content": "Session 4f9a-2c1e. Como troco minha senha?"}]
}
// Resultado: ~99% de cache hit

Quatro passos para levar sua taxa de acerto de 7% a 74%

Passo 1: Identifique seu prefixo estável

Mapeie a estrutura do seu prompt:

Passo 2: Mova todo conteúdo dinâmico para o final

Reestruture para que o prefixo estável venha primeiro, sem interrupções:

[System instructions — totalmente estático]
[Tool definitions — totalmente estático]
[Few-shot examples — totalmente estático]
[Contexto RAG — template estável, conteúdo variável]
[Query do usuário — dinâmico]
[Metadados de sessão — dinâmico, no final]

Passo 3: Monitore a taxa de acerto como métrica de primeira classe

A taxa de cache hit pertence ao seu dashboard de operações LLM ao lado de latência e custo. É um indicador avançado: uma queda frequentemente precede um pico de custo e revela regressões na estrutura do prompt antes que apareçam na fatura.

Passo 4: Alinhe o TTL do cache ao seu intervalo de tráfego

A Anthropic oferece TTLs de 5 minutos ou 1 hora. Um deployment com requisições a cada 10 minutos nunca atingirá o tier de 5 minutos — escolha o TTL baseado no intervalo p50 das suas requisições, não no pico de burst.

Cache-aware routing: 35% menos TTFT no Vertex AI

O impacto do caching na latência é tão relevante quanto na economia. A equipe do Vertex AI (Google) documentou que o roteamento inteligente — enviar requisições com prefixos compartilhados para o mesmo servidor que já tem o prefixo em cache — dobrou a taxa de acerto de 35% para 70%, reduzindo o TTFT (time to first token) em 35% em workloads de coding agents e a latência P95 em 52% em workloads de chat.

Cache semântico: eliminando inferência para consultas repetidas

Para workloads com alta repetição de consultas — suporte ao cliente, chatbots de FAQ, busca em base de conhecimento — o cache semântico complementa o prefix cache eliminando completamente a inferência para consultas comuns. O padrão:

1. Compute um embedding da consulta recebida
2. Verifique o vector store por consultas similares (≥95% similaridade de cosseno)
3. Se houver match, retorne a resposta cacheada imediatamente — sem chamada ao modelo
4. Se não houver match, execute a inferência e armazene o resultado

Para um chatbot de suporte onde 40% das perguntas são variações de “como troco minha senha”, o cache semântico pode eliminar quase metade das chamadas de inferência.

Checklist antes de implantar

• ✅ Nenhum campo dinâmico (timestamps, session IDs, user IDs) está embutido dentro do prefixo estável
• ✅ Documentos RAG seguem o template estável mas aparecem após o prefixo fixo
• ✅ Taxa de cache hit é registrada e monitorada com alertas
• ✅ TTL do cache corresponde ao intervalo de tráfego real
• ✅ Prefixo atende ao comprimento mínimo cacheável do seu modelo específico (ex: 4.096 tokens para Claude Haiku 4.5)
• ✅ Estrutura do prompt está sob controle de versão — mudanças acidentais invalidam o cache silenciosamente

Feito corretamente, as três camadas juntas (KV cache + prefix cache + cache semântico) servem 60-80% do custo e latência de inferência a partir do cache. E o prefix cache, que depende exclusivamente da estrutura do prompt, é onde estão a maioria dos ganhos — e dos erros.