Cache de prompts em LLM: o guia completo de 2026
Conteúdo
Se você coloca em produção um chatbot, uma aplicação RAG ou um agente de IA contra um grande modelo de linguagem, o cache de prompts é a única otimização que devolve de 50 a 90% do custo de entrada e de 3 a 10× no tempo até o primeiro token sem nenhum custo de qualidade. Não é um truque acoplado por cima — ele decorre diretamente de como a atenção dos Transformers é definida. Uma vez que você entende isso, o restante da pilha (TTLs, diferenças entre provedores, estrutura do prompt) se alinha com clareza.
Esta página é o índice de uma série em quatro partes que o leva da teoria a uma matriz de decisão para produção. Escolha por onde entrar de acordo com o que você já sabe.
Por onde começar
| Se você quer… | Comece em |
|---|---|
| Entender por que o cache existe e o que de fato é o cache KV | Parte 1 — Como funcionam o cache KV e o TTL |
| Escolher um provedor e saber o que diferencia cada um | Parte 2 — Comparar Claude, GPT, Gemini, DeepSeek |
| Copiar e colar Python funcional e medir seus próprios números | Parte 3 — Tutorial funcional em Python |
| Combinar uma carga de chatbot / RAG / agente ao modelo certo | Parte 4 — O melhor modelo para chat, RAG e agentes |
Cada parte é autônoma, mas foram escritas de modo que lê-las em ordem constrói o panorama sem redundância.
Parte 1 — Como funciona o cache de prompts em LLM
Cache de prompts em LLM #1: como funcionam o cache KV e o TTL →
O artigo de arquitetura. Percorre a autoatenção como uma única equação, explica por que os vetores K e V de um prefixo estável são matematicamente reutilizáveis e mostra como o trade-off entre memória e computação produz o comportamento do TTL em torno do qual todo desenvolvedor precisa projetar.
Pontos principais:
- O cache de prompts não é uma otimização colocada por cima — é uma consequência direta da atenção com máscara causal. O K/V na posição
ié uma função determinística dos tokens1…i, de modo que prefixos idênticos geram K/V idênticos bit a bit. - O prefill (limitado por computação, O(N²)) é o que o cache economiza; o decode (limitado pela largura de banda de memória, O(N) por token) é o que todo motor de inferência já otimiza.
- Os TTLs existem porque o cache KV é enorme (~10 GB para um contexto de 32K em um modelo de 70B). 5 minutos é o horizonte de pressão de memória da GPU; de horas a dias só é possível com caches apoiados em disco (a arquitetura MLA da DeepSeek).
- O cache vence tanto em custo (50 a 90% de desconto sobre a entrada nos acertos de cache) quanto em latência (o TTFT cai de 3 a 10× para prompts na faixa de 5 a 10K tokens, e muito mais para acima de 100K).
Parte 2 — Comparar o cache de prompts em LLM entre provedores
Cache de prompts em LLM #2: comparar Claude, GPT, Gemini, DeepSeek →
O guia de compra. Cinco provedores expõem o cache de prompts em cinco formatos bem distintos — marcadores explícitos (Claude), totalmente automático (GPT-5, DeepSeek-v4), híbrido implícito+explícito (Gemini, Qwen) ou apoio arquitetônico em disco (a MLA da DeepSeek). O artigo oferece uma comparação recurso a recurso mais um framework de avaliação de 5 dimensões para pontuá-los para sua carga de trabalho específica.
Pontos principais:
- Não compare os preços base — compare o custo efetivo ponderado pela sua taxa de acertos (fórmula na §4.1).
- O Claude tem o desconto mais profundo em uma única chamada (~90%), mas exige marcadores
cache_controlexplícitos. - O DeepSeek-v4 é o único provedor com caches apoiados em disco em escala; correspondências parciais de prefixo recebem descontos porque a granularidade é de 64 tokens em vez de 1.024.
- O cache explícito do Gemini cobra taxas de armazenamento por hora — o ponto de equilíbrio depende da frequência das chamadas.
- A ergonomia da API, a previsibilidade da taxa de acertos, a adequação do TTL, a latência em caso de falha e o custo de migração são as cinco dimensões que de fato distinguem os provedores quando se controla a taxa de acertos.
Parte 3 — Tutorial funcional em Python
Cache de prompts em LLM #3: tutorial funcional em Python →
O artigo prático. Um SDK da OpenAI + um SDK da Anthropic contra um único gateway, com números medidos em 2026-05-25 em toda a família Claude (de haiku-4-5 a opus-4-7), GPT-5.x, Gemini 2.5, DeepSeek-v4 e Qwen3.
Pontos principais:
- Claude com marcadores
cache_control: redução de custo de 88 a 89% medida de forma uniforme em haiku/sonnet/opus 4-x. Use o SDK da Anthropic combase_url="https://synthorai.io/". - Cache automático do GPT-5.4-mini: melhoria de 5× no TTFT (3,6 s → 0,73 s em um prompt de 7K tokens), 93% de taxa de acertos de cache nos tokens de sistema.
- Gemini 2.5-flash implícito: redução de custo de 88% nos acertos de cache quando o uso em streaming é capturado.
- DeepSeek-v4-flash: 74% de desconto, apoiado em disco (o cache sobrevive a ociosidades de horas).
- Padrões cientes do TTL: heartbeat keep-alive para cron, regras de estabilidade do prefixo, o que registrar a cada chamada.
Parte 4 — O melhor modelo por caso de uso
Cache de prompts em LLM #4: o melhor modelo para chat, RAG e agentes →
O artigo de decisão. Cargas de trabalho diferentes acionam as alavancas de custo/latência de formas diferentes — o chat é naturalmente favorável ao cache, o RAG luta contra o problema da estabilidade do prefixo, os agentes dependem da disciplina do prefixo cumulativo. O artigo dá uma recomendação de modelo por formato de carga com estimativas de custo.
Pontos principais:
- Chatbots: qualquer modelo com cache automático funciona; as sessões acertam o cache naturalmente. Escolha por custo/qualidade.
gpt-5.4-nanoé o mais barato,gpt-5.4-minitem o TTFT em cache mais rápido,claude-haiku-4-5oferece o melhor cumprimento de instruções com um acréscimo modesto. - RAG: a reordenação dos documentos recuperados destrói os acertos de cache no meio do prompt. Três correções — empurrar as referências para o fim, ordem determinística dos chunks ou os pontos de quebra múltiplos
cache_controldo Claude. - Agentes: chamadas de ferramentas e seus resultados devem ser apenas anexados (append-only) e idênticos bit a bit de um passo para o outro.
claude-sonnet-4-5com 4 marcadorescache_controloferece o desconto de prefixo cumulativo mais forte;gpt-5.4-minifunciona sem mudanças de código com 50% de economia. - Ajuste do TTL: 5 min para chat, 1 hora para agentes com etapas com intervenção humana, apoio em disco para lotes esporádicos.
Como ler isto
- Engenheiro novo no assunto: leia em ordem. A arquitetura da Parte 1 faz as Partes 2 a 4 se encaixarem instantaneamente.
- PM ou arquiteto fazendo seleção de fornecedor: pule para a Parte 2 + a Parte 4. Recorra à Parte 1 se um colega perguntar “mas por que o TTL existe”.
- Engenheiro com uma carga específica para entregar hoje: a Parte 4 primeiro (encontre sua linha na matriz), depois a Parte 3 para o código exato.
- Qualquer um otimizando um app existente: o benchmark entre provedores da Parte 3 §6 — reproduza-o com seu próprio prompt; é um trabalho de um dia, não uma migração de várias semanas.
Os números desta série
Todos os números medidos foram capturados em 2026-05-25 contra o gateway Synthorai (https://synthorai.io/v1 para compatibilidade com OpenAI, https://synthorai.io/ para Anthropic nativo), single-tenant, em uma única execução sequencial, sem carga concorrente. Seus números vão variar conforme região, horário do dia e carga de inquilinos concorrentes — trate-os como ponto de partida e reproduza-os com seu próprio tráfego antes de citá-los.
As tabelas de preços e o comportamento do TTL refletem a documentação pública dos fornecedores em 2026-05. Os fornecedores as atualizam a cada poucos meses; o raciocínio arquitetônico (Parte 1) é estável, os números comparativos (Partes 2 e 3) sofrem desvio.