Cache de prompts em LLMs: guia completo de 2026 (reduza o custo de entrada em 50–90%)

Se você mantém um chatbot, uma aplicação RAG ou um agente de IA conectado a um modelo de linguagem de grande porte, o cache de prompts é a otimização que permite recuperar 50–90% do custo de entrada e reduzir em 3–10× o tempo até o primeiro token, sem perda de qualidade. Não é um truque adicionado por cima da arquitetura. É uma consequência direta da definição de attention nos Transformers. Depois de entender esse mecanismo, o restante da stack, como TTLs, diferenças entre provedores e estrutura dos prompts, fica muito mais claro.

TL;DR

• O cache de prompts reduz o custo de entrada em 50-90% e o tempo até o primeiro token em 3-10x, sem perda de qualidade.
• Medições feitas em 2026-05-25: os marcadores cache_control do Claude reduziram o custo de entrada em 88-89%; o cache automático do GPT-5.4-mini baixou o TTFT de 3.6s para 0.73s; o DeepSeek-v4-flash ofereceu 74% de desconto com um cache persistido em disco.
• Os TTLs são curtos porque o estado KV ocupa muita memória: cerca de 10 GB para um contexto de 32K tokens em um modelo da classe de 70B.
• O DeepSeek usa granularidade de 64 tokens no cache, contra o limite mínimo usual de 1,024 tokens. Assim, correspondências parciais de prefixo também recebem desconto.

Esta página é o índice de uma série em cinco partes. Ela começa pela teoria, avança até uma matriz de decisão para produção e termina na camada de framework, onde os prompts são efetivamente montados. Escolha por onde começar de acordo com o que você já conhece.

Por onde começar

Cada parte pode ser lida de forma independente, mas a ordem foi pensada para construir o raciocínio sem repetir conteúdo.

Parte 1 — Como funciona o cache de prompts em LLMs

Como funciona o cache de prompts em LLMs: KV cache e TTL em detalhes →

Este é o artigo sobre arquitetura. Ele resume self-attention em uma única equação, explica por que os vetores K e V de um prefixo estável podem ser reutilizados matematicamente e mostra como a troca entre memória e capacidade computacional leva ao comportamento dos TTLs que todo desenvolvedor precisa considerar no projeto.

Principais conclusões:

• O cache de prompts não é uma otimização adicionada por cima do modelo. Ele decorre diretamente de attention com máscara causal. K/V na posição i é uma função determinística dos tokens 1…i; portanto, prefixos idênticos produzem K/V idênticos bit a bit.
• O cache evita o prefill, que é limitado por capacidade computacional e tem complexidade O(N²). O decode, limitado pela largura de banda da memória e com custo O(N) por token, já é otimizado por todos os mecanismos de inferência.
• Os TTLs existem porque o KV cache é enorme: cerca de 10 GB para um contexto de 32K em um modelo de 70B. O prazo de 5 minutos reflete a pressão sobre a memória da GPU. Períodos de horas ou dias só são viáveis com caches persistidos em disco, como na arquitetura MLA do DeepSeek.
• O cache reduz tanto o custo (50–90% de desconto na entrada quando há cache hit) quanto a latência (o TTFT cai 3–10× em prompts de 5–10K tokens e muito mais acima de 100K).

Parte 2 — Comparação do cache de prompts em LLMs entre provedores

Comparativo de cache de prompts: Claude, GPT-5, Gemini, DeepSeek e Qwen (2026) →

Este é o guia de compra. Cinco provedores implementam o cache de prompts de formas bem diferentes: marcadores explícitos no Claude, operação totalmente automática no GPT-5 e DeepSeek-v4, modelo híbrido implícito e explícito no Gemini e Qwen, ou persistência arquitetural em disco no MLA do DeepSeek. O artigo traz uma comparação recurso por recurso e um framework de avaliação com 5 dimensões para pontuar cada opção conforme a sua carga de trabalho.

Principais conclusões:

• Não compare os preços-base. Compare o custo efetivo ponderado pela taxa de cache hit, usando a fórmula da seção §4.1. A comparação atualizada de preços de LLMs e a calculadora de custos aplicam esse cálculo à sua carga de trabalho.
• O Claude oferece o maior desconto em uma única chamada, cerca de 90%, mas exige marcadores cache_control explícitos.
• O DeepSeek-v4 é o único provedor com caches em disco em grande escala. Correspondências parciais de prefixo recebem desconto porque a granularidade é de 64 tokens, não de 1,024.
• O cache explícito do Gemini cobra armazenamento por hora. O ponto de equilíbrio depende da frequência das chamadas.
• Depois de controlar a taxa de cache hit, os provedores se diferenciam de fato em cinco dimensões: ergonomia da API, previsibilidade da taxa de acerto, adequação do TTL, latência em caso de miss e custo de migração.

Parte 3 — Tutorial prático em Python

Cache de prompts em LLMs com Python: tutorial prático com código →

Este é o artigo prático. Ele usa um SDK da OpenAI e outro da Anthropic com um único gateway e apresenta medições feitas em 2026-05-25 para toda a família Claude, de haiku-4-5 a opus-4-7, além de GPT-5.x, Gemini 2.5, DeepSeek-v4 e Qwen3.

Principais conclusões:

• Claude com marcadores cache_control: as medições mostraram redução de custo de 88–89% de forma consistente em haiku/sonnet/opus 4-x. Use o SDK da Anthropic com base_url="https://synthorai.io/".
• Cache automático do GPT-5.4-mini: melhora de 5× no TTFT, de 3.6 s para 0.73 s em um prompt de 7K tokens, com 93% de cache hit nos tokens de sistema.
• Cache implícito do Gemini 2.5-flash: redução de custo de 88% nos cache hits quando os dados de uso do streaming são capturados.
• DeepSeek-v4-flash: desconto de 74%, com persistência em disco; o cache sobrevive a períodos de inatividade de várias horas.
• Padrões que consideram o TTL: heartbeat de keep-alive para cron, regras para manter o prefixo estável e dados que devem ser registrados em cada chamada.

Parte 4 — Melhor modelo por caso de uso

Melhor LLM para chat, RAG e agentes: matriz de decisão de modelo e custo para 2026 →

Este é o artigo para tomada de decisão. Cada tipo de carga aciona os fatores de custo e latência de maneira diferente. Chats se beneficiam naturalmente do cache; aplicações RAG enfrentam o problema da estabilidade do prefixo; agentes dependem de uma composição disciplinada do prefixo cumulativo. O artigo recomenda modelos conforme o formato da carga e inclui estimativas de custo.

Principais conclusões:

• Chatbots: qualquer modelo com cache automático funciona, pois as sessões geram hits naturalmente. Escolha com base em custo e qualidade. gpt-5.4-nano é o mais barato, gpt-5.4-mini tem o TTFT em cache mais rápido e claude-haiku-4-5 segue melhor as instruções por um custo adicional moderado.
• RAG: reordenar os documentos recuperados impede cache hits no meio do prompt. Há três soluções: mover as referências para o final, ordenar os chunks de forma determinística ou usar vários pontos de interrupção com cache_control no Claude.
• Agentes: chamadas de tools e seus resultados precisam ser apenas acrescentados, além de permanecer idênticos byte a byte entre as etapas. claude-sonnet-4-5 com 4 marcadores cache_control oferece o maior desconto para prefixos cumulativos; gpt-5.4-mini funciona sem alterações no código e economiza 50%.
• Adequação do TTL: 5 min para chat, 1 hora para agentes com etapas de validação humana e persistência em disco para processamento em lote esporádico.

Parte 5 — Integração com LangChain

Cache de prompts no LangChain: configurações que realmente acertam o cache →

Este é o artigo sobre frameworks. As Partes 1–4 pressupõem que você controla os bytes do prompt. O LangChain monta esses bytes por você, e a sintaxe mais conveniente desativa silenciosamente o cache do Claude. As medições foram feitas com langchain-core 1.4.8 e um prefixo de sistema marcado.

Principais conclusões:

• O template de tupla de strings ("system", "...") não aceita cache_control: as medições não mostraram nenhuma atividade de cache em chamadas idênticas. A correção é usar um SystemMessage com blocos de conteúdo.
• A ordem do prompt determina a taxa de cache hit. Colocar o contexto recuperado pelo RAG antes das regras estáticas fez com que todas as chamadas gerassem uma escrita fria. Com o custo adicional de escrita do Claude, isso custa mais do que não usar cache.
• Um marcador no bloco de sistema também abrange as tools vinculadas. bind_tools produz uma serialização estável byte a byte, e um marcador em um dicionário de tool no formato da Anthropic é repassado sem alterações.
• Agentes com múltiplos turnos: mova o marcador para a mensagem mais recente. Em cada turno, o prefixo anterior inteiro é lido novamente, mas apenas o delta é escrito. Resultado medido: 1,864 tokens lidos e 15 gravados.
• Em modelos com cache automático, como GPT, GLM e DeepSeek, uma ordem incorreta falha silenciosamente: não há custo adicional nem erro, apenas um desconto que nunca aparece. Monitore os campos de uso.

Como ler esta série

• Engenheiro começando no tema: leia na ordem. A arquitetura da Parte 1 facilita imediatamente o entendimento das Partes 2–4.
• PM ou arquiteto escolhendo um fornecedor: vá direto para as Partes 2 e 4. Consulte a Parte 1 se alguém da equipe perguntar por que o TTL existe.
• Engenheiro com uma carga específica para colocar em produção hoje: comece pela Parte 4 e encontre sua linha na matriz. Depois, use o código exato da Parte 3.
• Quem já usa LangChain: vá direto para a Parte 5. Os padrões com SDKs puros da Parte 3 continuam válidos, mas os problemas com templates de string, posição de variáveis e nomes dos campos de uso são específicos do framework.
• Quem está otimizando uma aplicação existente: use o benchmark entre provedores da seção §6 da Parte 3. Reproduzi-lo com seu próprio prompt leva um dia, não uma migração de várias semanas.

Números usados nesta série

As medições das Partes 1–4 foram coletadas em 2026-05-25, e as medições do LangChain na Parte 5, em 2026-07-04, usando o gateway da Synthorai (https://synthorai.io/v1 para compatibilidade com OpenAI e https://synthorai.io/ para a API nativa da Anthropic), em ambiente single-tenant, com uma única execução sequencial e sem carga concorrente. Os resultados variam conforme a região, o horário e a carga de outros tenants. Use-os como ponto de partida e repita os testes com seu próprio tráfego antes de citá-los.

As tabelas de preços e o comportamento dos TTLs refletem a documentação pública dos fornecedores em 2026-05. Os provedores atualizam esses dados a cada poucos meses. O raciocínio arquitetural da Parte 1 permanece estável; os números comparativos das Partes 2 e 3 mudam com o tempo.

← Voltar ao blog