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

TL;DR — O cache de prompts em LLMs não é uma otimização acrescentada à arquitetura; ele decorre diretamente da forma como a arquitetura Transformer calcula a atenção. Quando entendemos por que os vetores Key/Value de um prefixo estável podem ser reutilizados matematicamente, fica claro o benefício duplo: uma redução drástica de custos (50–90%) e do tempo até o primeiro token (5–20×). Este artigo, a Parte 1 de uma série de cinco, explica por que o cache existe do ponto de vista da arquitetura, a relação entre memória e processamento que determina se ele compensa e o comportamento do TTL que todo desenvolvedor precisa conhecer. A Parte 2 analisa as implementações específicas de cada provedor.

Série: Parte 1 de 5 — Princípios de cache · Próximo: Parte 2 — Comparação e avaliação de provedores · Parte 3 — Tutorial com código funcional · Parte 4 — Melhor LLM por caso de uso · Parte 5 — Integração com LangChain · Versão em uma página: guia completo de cache de prompts

Por que a conta de tokens da sua aplicação de IA cresce mais rápido que a base de usuários

Se você mantém um chatbot, uma aplicação RAG ou um agente de IA em produção, provavelmente já esbarrou no mesmo problema: a fatura dobra, mas o uso não. Ao abrir o log de requisições, você encontra o mesmo system prompt com milhares de tokens, as mesmas descrições de ferramentas e os mesmos trechos da base de conhecimento sendo reenviados em todas as chamadas.

Esse é o principal problema econômico da inferência em LLMs: o modelo não mantém estado. Cada requisição reprocessa todo o contexto do zero. Um system prompt de 8K tokens chamado 1.000 vezes representa 8 milhões de tokens de trabalho repetido. Você paga por todos eles, e seus usuários esperam pelo processamento de todos eles.

O cache de prompts resolve esse problema. Ao contrário da maioria das otimizações de desempenho, ele não é algo adicionado à arquitetura, mas uma consequência natural da definição de atenção dos Transformers. Entendido esse ponto, o restante do artigo — preços, TTL e diferenças entre provedores — passa a fazer sentido.

1. Por que LLMs têm cache: passo a passo da inferência em um Transformer

Quase todos os tutoriais sobre cache de prompts pulam esta parte. É justamente ela que explica por que o cache existe e por que os descontos oferecidos pelos provedores não são números arbitrários de marketing, mas refletem custos reais de GPU.

1.1 Self-attention em uma equação

Um Transformer somente com decoder — família à qual pertencem GPT-4, Claude, Gemini, DeepSeek e Qwen — processa tokens aplicando self-attention repetidamente. Para uma sequência de N tokens, a saída da atenção para cada token i é:

Attention(Q, K, V) = softmax( Q · Kᵀ / √d ) · V

Q, K e V são matrizes com formato [N × d], derivadas dos embeddings de entrada por três projeções lineares aprendidas, uma por camada e por head. A definição original vem de Attention Is All You Need (Vaswani et al., 2017).

Duas propriedades dessa equação são fundamentais para o cache:

Propriedade 1 — Máscara causal. Durante a geração, o token i só pode aplicar atenção aos tokens nas posições ≤ i. A matriz de atenção é triangular inferior: os vetores K e V dos primeiros tokens são usados por todos os tokens posteriores, mas os tokens posteriores nunca os modificam.

Propriedade 2 — K e V dependem apenas do prefixo. Como são calculados a partir dos embeddings de entrada das posições 1…i por matrizes de pesos fixas, os vetores K e V na posição i são uma função determinística dos tokens nas posições 1…i, e somente deles. Nada na posição i+1 pode alterar K_i ou V_i.

A consequência é direta: se duas requisições compartilham um prefixo idêntico de tamanho P, as primeiras P linhas de K e V são idênticas bit a bit.

Essa é toda a base teórica do cache de prompts. O restante é engenharia.

1.2 As duas fases da inferência

A inferência em LLMs modernos ocorre em duas fases distintas, com perfis de consumo de GPU muito diferentes. Essa divisão é descrita em detalhes em Efficiently Scaling Transformer Inference (Pope et al., 2022).

Fase de prefill. O modelo recebe o prompt completo de uma só vez. Em cada camada, calcula Q, K e V para todos os tokens de entrada e executa self-attention. O prefill é limitado por processamento: ele satura as unidades de multiplicação de matrizes da GPU. O custo cresce como O(N²) em relação ao tamanho do prompt por causa da matriz de atenção.

Fase de decode. O modelo produz um token de saída por vez, de forma autorregressiva. Na etapa t, somente o Q do novo token é calculado; ele aplica atenção sobre os K/V de todos os tokens anteriores. O decode é limitado pela largura de banda da memória: a maior parte do tempo é gasta lendo K/V da memória da GPU, não fazendo multiplicações. O custo por token cresce como O(N), linearmente com o tamanho atual do contexto.

Em uma carga típica de chatbot — system prompt de 8K tokens, consulta do usuário com 100 tokens e resposta de 300 tokens — o prefill responde por cerca de quatro vezes mais tempo total e custo que o decode. É essa parte que o cache elimina.

Per call breakdown (8K prompt, 300 output tokens, Claude-class model):

  ████████████████████████████████░░░░░░░░  Prefill: ~80% of compute
  ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░████████  Decode:  ~20% of compute

1.3 KV cache: preservando o trabalho de prefill para o decode

Originalmente, o termo “KV cache” se referia a uma otimização dentro da própria requisição. Durante o decode, cada novo token gerado precisa aplicar atenção aos K e V de todos os tokens anteriores. Recalculá-los a cada etapa transformaria um decode O(N) em O(N²). Por isso, todos os mecanismos de inferência armazenam na memória da GPU os K e V produzidos no prefill e os reutilizam durante toda a fase de decode. Essa prática é universal: todo LLM comercial faz isso. Sem ela, a geração seria inviável.

O que os provedores disponibilizam como “cache de prompts” é a generalização seguinte: manter o KV cache depois que a requisição termina e reutilizá-lo na próxima requisição que compartilhe o mesmo prefixo.

1.4 A relação entre memória e processamento: por que TTLs existem

Por que os provedores não armazenam tudo para sempre? Porque o KV cache é enorme.

Para um modelo com L camadas transformer, H attention heads, head dimension D e B bytes por valor, normalmente 2 para fp16, o tamanho do KV cache para N tokens é:

KV cache size  =  2 × L × H × D × B × N
                  ↑   ↑   ↑   ↑   ↑   ↑
                  K&V layers heads head bytes tokens

Em um modelo da classe 70B com 80 camadas, 8 KV heads após grouped-query attention, head dimension de 128 e pesos fp16, isso representa aproximadamente 320 KB por token. Um contexto de 32K tokens ocupa ~10 GB de KV cache somente para uma requisição. Uma GPU H100 moderna tem 80 GB, portanto só comporta alguns desses contextos simultaneamente.

Essa é a principal restrição que o PagedAttention (Kwon et al., 2023, artigo que deu origem ao vLLM) busca resolver no nível de batch. A mesma restrição limita o cache de prompts entre requisições:

O TTL de cache de um provedor é, na prática, uma política de remoção da memória: em algum momento, a GPU precisa desse espaço para cargas ativas de outros usuários, e o prefixo armazenado é removido. 5 minutos para caches residentes em HBM; até 1 hora para caches paginados para DRAM; horas para caches persistidos em disco.

A solução do DeepSeek. O DeepSeek-V2 introduziu o Multi-head Latent Attention (MLA), que comprime o KV cache em aproximadamente 4× quando comparado ao grouped-query attention padrão (DeepSeek-AI, 2024). Essa compressão permite persistir o KV cache em disco, em vez de HBM. Com isso, o provedor consegue oferecer uma unidade mínima de cache muito menor — 64 tokens, contra 1.024 nos caches residentes em HBM — e TTLs efetivos muito mais longos.

É também por isso que o cache entre requisições exige prefixos idênticos token por token. O índice do cache é um hash dos IDs dos tokens. Qualquer diferença, até mesmo um único caractere que altere a tokenização, produz K e V diferentes daquele ponto em diante. Não existe correspondência aproximada nessa camada. Quem faz isso é o cache semântico, que usa outro mecanismo no gateway.

1.5 Duas camadas de cache

┌──────────────────────────────────────────────────────────────┐
│  Layer 1: Per-request KV cache (always on, every provider)    │
│  → keeps decode O(N) instead of O(N²)                        │
│  → you don't pay attention to it; the provider just does it  │
└──────────────────────────────────────────────────────────────┘
                              ↓
┌──────────────────────────────────────────────────────────────┐
│  Layer 2: Cross-request Prompt Cache (the money-and-time      │
│           saver this series is about)                         │
│  → reuses prefill K/V across requests with matching prefixes  │
│  → exposed as: explicit / fully automatic / hybrid           │
│  → bounded by TTL (memory-eviction-driven)                   │
└──────────────────────────────────────────────────────────────┘

O restante da série — e quase tudo que você ajustará como desenvolvedor — está na Camada 2.

2. Os dois ganhos: custo E latência

A maioria dos artigos apresenta o cache como uma otimização de custos. Isso não mostra todo o impacto. Em muitos casos, a redução de latência é o motivo mais importante para equipes de produção adotarem cache, principalmente em chats voltados ao usuário.

2.1 O cálculo de custos

As páginas de preços trazem os números principais, mas raramente os aplicam a uma carga realista. Considere um bot de suporte ao cliente com um system prompt de 8.000 tokens, 100K consultas por dia e mensagens de usuário com 200 tokens. Usando claude-sonnet-4-5 e os preços de 2026 publicados pela Anthropic — entrada em cache a 10% do valor e acréscimo de 125% na gravação do cache:

Sem cache

• Entrada por chamada: 8.200 tokens × tarifa-base de entrada
• Custo por chamada, medido em uma única execução: ~$0.022
• Custo mensal: 100K × 30 × $0.022 = ~$66,000

Com cache de prompts

• Gravação inicial do cache: 8.000 tokens × acréscimo de 125%, irrelevante diante do volume mensal
• Chamadas seguintes: 8.000 tokens × 10% da tarifa-base + 200 tokens × tarifa-base + saída
• Custo efetivo por chamada: ~$0.003
• Custo mensal: ~$9,000

Economia de ~86%. Esse valor resulta da aplicação do desconto publicado pela Anthropic a um perfil realista de entrada. O artigo seguinte, a Parte 3 — Tutorial, apresenta medições reais para os demais provedores.

2.2 A redução de latência, muitas vezes o principal benefício

O prefill não é apenas caro. Em prompts com mais de algumas centenas de tokens, ele é o maior componente do tempo até o primeiro token. Em um cache hit, quase todo esse trabalho é ignorado.

Medições de TTFT com streaming no gateway público da Synthorai em 2026-05-25, usando um system prompt estável de ~7.300 tokens:

Uma única execução, em ambiente single-tenant. A redução do TTFT é mais visível em prompts longos, acima de 5K tokens. Em prompts curtos, o prefill representa uma parcela pequena demais para dominar a latência. Nas medições com Claude, o maior ganho foi de custo, com redução de ~88–89% no valor da entrada lida do cache. Segundo os números publicados pela Anthropic, em prompts de 100K tokens ou mais, a redução de TTFT aumenta consideravelmente.

Em interfaces de chat, os usuários começam a perceber conscientemente o atraso quando o TTFT ultrapassa cerca de 1 s ou o primeiro texto útil demora ~2 s. Sem cache, um prompt RAG de 10K tokens fica claramente acima desse limite. Com cache, a mesma carga parece instantânea.

Em loops de agentes com 15 etapas ou mais, a economia é boa, cerca de 50%, mas é a redução de latência que torna o produto viável: 15 etapas × 5s de prefill = 75 s de espera por tarefa → com cache, 15 × 0.5s = 7.5 s.

2.3 Por que isso afeta a estratégia do produto

Um erro comum é tratar cache como uma “otimização de custos da equipe de operações”, acrescentada depois do lançamento. Como ele também reduz a latência, o cache faz parte da experiência do usuário:

• Um chatbot com TTFT abaixo de 1 s parece responsivo; a 3 s, parece estar com defeito.
• Um produto RAG em que recuperação e prefill levam 4 s perde para o mesmo produto quando esse tempo cai para 1 s.
• Um agente que conclui uma tarefa em 20 s ganha de outro que leva 90 s.

A estratégia de cache deve ser definida junto com o modelo e a estrutura do prompt, não três sprints depois do lançamento.

3. Atualidade do cache, TTL e modelo operacional

O TTL é um dos temas mais perguntados e menos explicados no cache de prompts. Há dois pontos fundamentais:

3.1 Atualidade tem dois significados — não os confunda

Atualidade do cache ≠ atualidade da resposta. Dois conceitos distintos costumam ser tratados como se fossem um só:

As respostas geradas com cache não ficam “desatualizadas” em termos de qualidade do modelo. Elas são matematicamente idênticas às geradas sem cache. Porém, se você incluir “o horário atual é 14:32:05” no system prompt e depender de cache hits, esse “horário atual” continuará sendo 14:32:05 até o TTL expirar, e o modelo passará a informar aos usuários um horário errado com toda a confiança.

3.2 Comportamento do TTL entre provedores

O padrão de 5 minutos não é arbitrário. Ele corresponde aproximadamente ao período tolerável de pressão sobre a memória da GPU em modelos populares durante picos de carga. Como calculamos em §1.4, o KV cache de um único contexto grande pode ocupar dezenas de GB; os provedores não conseguem mantê-lo indefinidamente.

3.3 Como projetar considerando o TTL

Três padrões que funcionam em produção:

Padrão A — Mantenha as sessões aquecidas. Em chats, o ritmo natural das requisições, com segundos ou minutos entre as mensagens, mantém o cache ativo. Não se preocupe com o TTL; apenas não coloque dados dinâmicos no prefixo.

Padrão B — Heartbeat para processamento em batch. Em jobs de batch que duram horas, envie uma requisição mínima a cada TTL/2 para manter o cache aquecido. O custo é praticamente zero, apenas alguns tokens de entrada, e isso evita uma sequência de remoções do cache.

Padrão C — Use provedores com TTL longo para armazenamento frio. Se você tem um documento de 50K tokens consultado esporadicamente, por exemplo uma vez por hora durante uma semana, os caches explícitos do Gemini, com TTL de 24 horas, ou os caches em disco do DeepSeek terão desempenho melhor que alternativas com TTL curto, apesar da tarifa de armazenamento.

4. Princípios universais que todo desenvolvedor deve conhecer

Os provedores expõem cache de cinco formas bem diferentes: marcadores explícitos, operação totalmente automática, abordagem híbrida, persistência arquitetural em disco ou ausência total do recurso. O próximo artigo é dedicado a essa comparação, a Parte 2 — Comparação e avaliação de provedores. Mas quatro princípios valem para qualquer provedor e decorrem diretamente da arquitetura que acabamos de analisar:

4.1 O cache funciona por prefixo — a ordem importa

Como K/V na posição i depende dos tokens nas posições 1…i, os provedores só conseguem encontrar correspondência para um prefixo contíguo a partir do token 0. Altere um único caractere na posição 0 e todo o prefixo será invalidado. Conteúdo estável vem primeiro; conteúdo volátil, por último. Isso não é uma heurística, mas uma consequência direta da estrutura causal da self-attention (§1.1).

4.2 O cache armazena K/V, não respostas

Um cache hit não devolve uma resposta gerada anteriormente. Ele recupera os vetores K e V calculados antes, que o modelo usa para gerar uma nova resposta à pergunta atual. Portanto:

• A qualidade da saída é idêntica à de uma chamada sem cache (§1.1).
• A saída continua não determinística pelos motivos habituais — temperature, top-p etc. continuam valendo.
• Respostas geradas com cache nunca ficam “desatualizadas” em termos de qualidade do modelo — somente o conteúdo do prompt, como horários e preços, pode ficar desatualizado. Consulte novamente §3.1.

4.3 Gravar no cache é um investimento, não uma operação gratuita

Nos provedores que cobram um valor adicional pela gravação — Anthropic 125%, Gemini explícito 125% — a primeira chamada com um novo prefixo custa mais do que custaria sem cache. O ponto de equilíbrio chega rápido, normalmente após um único hit. Porém, se o prefixo “estável” mudar a cada requisição, você pagará repetidamente pelas gravações sem obter retorno. Fique atento ao ordenar documentos recuperados por relevância: esse é o antipadrão clássico.

4.4 As APIs de cache não são portáveis entre provedores

cache_control (Anthropic) ≠ cached_content (Gemini) ≠ cache_id (Qwen). Se a aplicação precisa operar com vários provedores, você terá de manter três integrações ou colocar um Token Gateway na frente para unificá-las. A Parte 2 aborda esse tema em detalhes.

5. Cache de prompts é dinheiro de graça?

Quase. Ele compensa quando:

• Seus prompts têm um prefixo estável — system prompt, base de conhecimento, schemas de ferramentas
• Suas chamadas são frequentes ou relacionadas — mesma sessão, cargas em batch, execuções de agentes em andamento
• Você consegue estruturar os prompts com o conteúdo estável no início

Se cumprir essas três condições, normalmente verá uma redução de 50–90% nos gastos e um TTFT 3–20× mais rápido sem trocar de modelo.

A seguir: a Parte 2 — Comparação de cache entre provedores e framework de avaliação transforma a visão arquitetural acima em uma comparação detalhada entre Claude, OpenAI, Gemini, DeepSeek e Qwen, com critérios para escolher o provedor mais adequado à sua carga.

Início rápido: use o SDK da OpenAI com qualquer provedor

A Synthorai disponibiliza um endpoint compatível com a OpenAI. Basta apontar o SDK oficial openai para ele, e a troca entre modelos — Claude, GPT, Gemini, DeepSeek e Qwen — exige a alteração de uma única linha. O gateway converte cache_control para a sintaxe nativa de cache de cada provedor.

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["SYNTHORAI_KEY"],
    base_url="https://synthorai.io/v1",
)

resp = client.chat.completions.create(
    model="claude-sonnet-4-5",                       # swap freely
    max_tokens=256,
    messages=[
        {"role": "system", "content": "You are a helpful assistant."},
        {"role": "user",   "content": "Hello"},
    ],
)

print(resp.choices[0].message.content)
print(resp.usage.prompt_tokens_details)  # cached_tokens when upstream reports it
print(resp.usage.cost)                   # USD per call (gateway-computed)

A mesma chamada funciona com gpt-5.4-mini, gemini-2.5-pro, deepseek-v4-flash e qwen3-max; somente o campo model muda. O gateway devolve os metadados do cache hit no campo padrão da OpenAI prompt_tokens_details.cached_tokens, além de um campo cost em USD. Assim, você não precisa manter localmente uma matriz de preços por fornecedor.

Perguntas frequentes

Cache de prompts em LLMs é a mesma coisa que cache semântico? Não. O cache de prompts funciona por prefixo: ele reutiliza valores K/V quando há correspondência exata em nível de token no início do prompt. O cache semântico compara o significado por meio de embeddings e devolve uma resposta anterior. Ambos são úteis, e um bom Token Gateway os combina em camadas.

O cache de prompts altera a saída do modelo? Não. K e V são funções determinísticas dos tokens de entrada (§1.1). Os logits produzidos pelo modelo a partir de K/V armazenados são matematicamente idênticos aos gerados por K/V recém-calculados. O cache é uma otimização pura de eficiência, sem impacto na qualidade.

Por que o TTL do cache é tão curto? Não seria possível mantê-lo para sempre? O KV cache é enorme (§1.4: ~10 GB por contexto de 32K em um modelo 70B). A memória da GPU é o gargalo; os caches são removidos sempre que o servidor precisa desse espaço para cargas ativas. Caches persistidos em disco, como os do DeepSeek, podem durar horas, mas caches em memória normalmente não.

Qual é a diferença entre KV cache e cache de prompts? KV cache é a estrutura de dados em memória usada durante a inferência. “Cache de prompts” é a reutilização desse KV cache entre requisições. São a Camada 1 e a Camada 2 de §1.5.

Prompts armazenados em cache podem ficar desatualizados e prejudicar a qualidade? Do ponto de vista do modelo, não. Do ponto de vista do conteúdo, sim, caso o prompt contenha informações que mudam com o tempo. O cache armazena vetores K/V, não fatos sobre o mundo. Consulte §3.1.

Como medir a taxa de cache hit? Todos os provedores informam esse dado no objeto de uso da resposta: cache_read_input_tokens (Anthropic), cached_tokens (OpenAI), cached_content_token_count (Gemini) e prompt_cache_hit_tokens (DeepSeek). Registre esses campos no seu pipeline de logs.

Referências e fontes: Vaswani et al., “Attention Is All You Need” (NeurIPS 2017) · Pope et al., “Efficiently Scaling Transformer Inference” (2022) · Kwon et al., “Efficient Memory Management for LLM Serving with PagedAttention” (SOSP 2023, vLLM) · DeepSeek-AI, “DeepSeek-V2: A Strong, Economical, and Efficient MoE Language Model” (2024) — arquitetura MLA · Documentação de cache de prompts da Anthropic · Documentação de cache de prompts da OpenAI · Documentação de cache de contexto do Google Gemini · Guia de KV cache do DeepSeek · Cache de contexto do Alibaba Bailian

← Voltar ao blog