Cache de prompts em LLM #1: como funcionam o cache KV e o TTL

Resumo — O cache de prompts em LLM não é uma otimização acoplada; ele decorre de como a arquitetura Transformer realmente computa a atenção. Assim que você entende por que os vetores Chave/Valor de um prefixo estável são matematicamente reutilizáveis, a verdadeira surpresa passa a ser o benefício duplo: redução drástica de custo (50–90 %) e redução drástica do tempo até o primeiro token (5–20×). Este artigo — a primeira parte de uma série de quatro partes — cobre a razão arquitetônica para a existência do cache, o equilíbrio memória-versus-computação que determina se um cache compensa e o comportamento do TTL que todo desenvolvedor precisa entender. A Parte 2 aprofunda nas implementações específicas de cada provedor.

Série: Parte 1 de 4 — Princípios do cache · Próximo: Parte 2 — Comparação e avaliação de provedores · Parte 3 — Tutorial com código funcional · Parte 4 — O melhor LLM por caso de uso

Por que a fatura de tokens do seu app de IA cresce mais rápido que seus usuários

Se você está lançando um chatbot, um app RAG ou um agente de IA, provavelmente bateu na mesma parede: sua fatura dobra enquanto seu uso não. Abra o log de requisições e você encontrará o mesmo prompt de sistema de vários milhares de tokens, as mesmas descrições de ferramentas, os mesmos trechos da base de conhecimento — reenviados a cada chamada.

Esse é o problema econômico central da inferência em LLM: o modelo não tem estado. Cada requisição reprocessa todo o contexto do zero. Um prompt de sistema de 8K tokens chamado 1.000 vezes equivale a 8 milhões de tokens de trabalho repetido. Você paga por cada um deles — e seus usuários esperam por cada um deles.

O cache de prompts resolve isso. Mas, ao contrário da maioria dos truques de desempenho, ele não é adicionado à arquitetura — é uma consequência natural de como a atenção do Transformer é definida. Assim que você percebe isso, o resto do artigo (preços, TTL, diferenças entre provedores) se alinha de forma limpa.

1. Por que os LLMs sequer têm um cache: um passeio pela inferência do Transformer

Esta seção é a parte que quase todos os tutoriais de “cache de prompts” pulam. É a parte que explica por que o cache existe em primeiro lugar — e por que os descontos que os provedores oferecem não são números de marketing arbitrários, mas refletem uma economia de GPU real.

1.1 A autoatenção em uma única equação

Um Transformer apenas decodificador (a família à qual pertencem GPT-4, Claude, Gemini, DeepSeek e Qwen) processa tokens aplicando repetidamente a autoatenção. Para uma sequência de N tokens, a saída de atenção para cada token i é:

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

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

Duas propriedades dessa equação importam enormemente para o cache:

Propriedade 1 — Mascaramento causal. Durante a geração, o token i só pode atender aos tokens nas posições ≤ i. A matriz de atenção é triangular inferior: os vetores K e V dos tokens iniciais 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 computados a partir dos embeddings de entrada das posições 1…i por meio de 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 desses tokens. Nada sobre a posição i+1 pode alterar K_i ou V_i.

A implicação é imediata: se duas requisições compartilham um prefixo idêntico de comprimento 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. Todo o resto é engenharia.

1.2 As duas fases da inferência

A inferência moderna em LLM ocorre em duas fases distintas que consomem o tempo de GPU de maneiras muito diferentes. Essa divisão está documentada minuciosamente em Efficiently Scaling Transformer Inference (Pope et al., 2022).

Fase de preenchimento (prefill). O modelo ingere o prompt completo de uma só vez. Para cada camada, ele computa Q, K, V para cada token de entrada e executa a autoatenção. O prefill é limitado por computação: ele satura as unidades de multiplicação de matrizes da GPU. O custo escala como O(N²) em relação ao comprimento do prompt, por causa da matriz de atenção.

Fase de decodificação (decode). O modelo produz um token de saída por vez, de forma autorregressiva. No passo t, apenas o Q do novo token é computado; ele atende às K/V de todos os tokens anteriores. O decode é limitado pela largura de banda de memória — a maior parte do tempo é gasta lendo as K/V da memória da GPU, não multiplicando. O custo escala como O(N) por token (linear em relação ao comprimento de contexto atual).

Para uma carga típica de chatbot (prompt de sistema de 8K tokens + consulta de usuário de 100 tokens + resposta de 300 tokens), o prefill domina o tempo de relógio e o custo em dólares em uma proporção de aproximadamente 4:1. É exatamente isso que o cache economiza.

Detalhamento por chamada (prompt 8K, 300 tokens de saída, modelo da classe Claude):

  ████████████████████████████████░░░░░░░░  Prefill: ~80 % da computação
  ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░████████  Decode:  ~20 % da computação

1.3 O cache KV: guardar o trabalho de prefill para o decode

O “cache KV” referia-se originalmente a uma otimização dentro da própria requisição. Durante a decodificação, cada token recém-gerado precisa atender às K e V de cada token anterior. Recalculá-las a cada passo transformaria um decode O(N) em um decode O(N²). Por isso, todo motor de inferência armazena as K e V do prefill na memória da GPU e as reutiliza durante toda a fase de decode. Isso é universal — todo LLM comercial faz isso. É o que torna a geração viável, de modo geral.

O que os provedores expõem como “cache de prompts” é a generalização seguinte: manter o cache KV após o fim da requisição e reutilizá-lo para a próxima requisição que compartilhe o mesmo prefixo.

1.4 O equilíbrio memória–computação (por que os TTLs existem)

Então, por que cada provedor simplesmente não armazena tudo em cache para sempre? Porque o cache KV é enorme.

Para um modelo com L camadas Transformer, H cabeças de atenção, D dimensão de cabeça e B bytes por valor (tipicamente 2 para fp16), o tamanho do cache KV para N tokens é:

Tamanho do cache KV  =  2 × L × H × D × B × N
                        ↑   ↑   ↑   ↑   ↑   ↑
                       K&V camadas cabeças cabeça bytes tokens

Para um modelo da classe 70B com 80 camadas, 8 cabeças KV (após a atenção por consultas agrupadas), 128 de dimensão de cabeça e pesos fp16, isso dá cerca de 320 KB por token. Um contexto de 32K tokens = ~10 GB de cache KV, só para uma requisição. Uma GPU H100 moderna tem 80 GB; você consegue acomodar no máximo um punhado dessas simultaneamente.

Essa é a restrição central que PagedAttention (Kwon et al., 2023, o artigo por trás do vLLM) foi projetado para resolver no nível de lote (batch) — e a mesma restrição é o que limita o cache de prompts no nível entre requisições:

Assim, o TTL do cache de um provedor é essencialmente uma política de despejo de memória: em algum momento a GPU precisa dessa memória para as cargas ativas de outros usuários, e o prefixo em cache é despejado. 5 minutos para caches residentes em HBM; até 1 hora para caches paginados para a DRAM; horas para caches armazenados em disco.

O truque da DeepSeek. A DeepSeek-V2 introduziu a Multi-head Latent Attention (MLA), que comprime o cache KV em cerca de 4× em comparação com a atenção por consultas agrupadas padrão (DeepSeek-AI, 2024). Essa compressão é exatamente o que lhes permite persistir o cache KV em disco em vez de na HBM — o que, por sua vez, habilita uma unidade mínima de cache muito menor (64 tokens contra 1.024 para 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 a token. O cache é indexado por um hash dos identificadores de token, e qualquer divergência — nem que seja um único caractere que se tokenize de forma diferente — produz uma K e uma V diferentes a partir daquele ponto. Não há “correspondência aproximada” nesta camada (é isso que o cache semântico faz, mas é um mecanismo diferente dentro do gateway).

1.5 Duas camadas de cache

┌──────────────────────────────────────────────────────────────┐
│  Camada 1: cache KV por requisição (sempre ativo, todo provedor)│
│  → mantém o decode em O(N) em vez de O(N²)                  │
│  → você não se preocupa com ele; o provedor simplesmente faz │
└──────────────────────────────────────────────────────────────┘
                              ↓
┌──────────────────────────────────────────────────────────────┐
│  Camada 2: cache de prompts entre requisições (a economia    │
│           de dinheiro e tempo de que trata esta série)        │
│  → reutiliza as K/V do prefill entre requisições com prefixos correspondentes │
│  → exposto como: explícito / totalmente automático / híbrido │
│  → limitado pelo TTL (orientado pelo despejo de memória)    │
└──────────────────────────────────────────────────────────────┘

O resto da série — e a maior parte do que você ajustará como desenvolvedor — vive na Camada 2.

2. As duas vitórias: custo E latência

A maioria dos artigos enquadra o cache como uma otimização de custo. Isso o subestima. A vitória em latência costuma ser a razão maior pela qual as equipes de produção adotam o cache, especialmente para o chat voltado ao usuário.

2.1 A matemática do custo

As páginas de preços dão os números de destaque, mas raramente os mostram aplicados a uma carga realista. Pegue um bot de suporte ao cliente com um prompt de sistema de 8.000 tokens, 100K consultas/dia e mensagens de usuário de 200 tokens. Precificando-o em claude-sonnet-4-5 com as tarifas publicadas da Anthropic para 2026 (10 % para a entrada em cache, sobretaxa de 125 % na escrita do cache):

Sem cache

• Entrada por chamada: 8.200 tokens × tarifa de entrada base
• Custo por chamada (medido em chamada única): ~US$ 0,022
• Custo mensal: 100K × 30 × US$ 0,022 = ~US$ 66.000

Com cache de prompts

• Escrita única de cache: 8.000 tokens × sobretaxa de 125 % (desprezível frente ao volume mensal)
• Por chamada depois disso: 8.000 tokens × 10 % de base + 200 tokens × base + saída
• Custo efetivo por chamada: ~US$ 0,003
• Custo mensal: ~US$ 9.000

~86 % economizado. Esse número é o desconto publicado pela Anthropic aplicado a uma forma de entrada realista. O artigo a seguir (Parte 3 — Tutorial) mostra números reais medidos no restante dos provedores.

2.2 A vitória em latência (muitas vezes a história maior)

O prefill não é apenas caro — é o maior contribuinte individual para o tempo até o primeiro token para qualquer prompt com mais de algumas centenas de tokens. Os acertos de cache permitem pular quase todo ele.

TTFT de streaming medido contra o gateway público da Synthorai, 2026-05-25, prompt de sistema estável de ~7.300 tokens:

Execução única, único inquilino. A vitória em TTFT é mais visível em prompts longos (>5K tokens); para prompts curtos, a porção de prefill é pequena demais para dominar a latência. A maior vitória medida da Claude é o custo (~88–89 % de redução na entrada em leitura de cache) — para tamanhos de prompt na faixa de 100K+, a vitória em TTFT se acumula substancialmente, segundo os números publicados pela Anthropic.

Para interfaces de chat, o limiar acima do qual os usuários percebem conscientemente um atraso fica em torno de 1 s para o TTFT e ~2 s para o primeiro texto útil. Um prompt RAG de 10K tokens sem cache está firmemente acima dessa linha. Com cache, a mesma carga parece instantânea.

Para laços de agente com 15 ou mais passos, a história do custo é boa (50 % economizado), mas a história da latência é o que torna o produto realmente entregável: 15 passos × 5 s de prefill = 75 s de tempo morto por tarefa → com cache, 15 × 0,5 s = 7,5 s.

2.3 Por que isso importa para a estratégia de produto

Um erro comum é tratar o cache como “ops fazendo otimização de custo” — algo que você acopla depois do lançamento. Mas a vitória em latência significa que o cache também faz parte da superfície de UX:

• Um chatbot com TTFT abaixo de 1 s parece vivo; o mesmo bot a 3 s parece quebrado.
• Um produto RAG em que a recuperação+prefill leva 4 s perde para o mesmo produto em que leva 1 s.
• Um agente que conclui uma tarefa em 20 s vence um que leva 90 s.

Você deveria estar decidindo a estratégia de cache ao mesmo tempo em que decide seu modelo e a estrutura do seu prompt — não três sprints depois do lançamento.

3. Frescor do cache, TTL e o modelo operacional

A questão do TTL é uma das partes mais perguntadas e menos explicadas do cache de prompts. Duas coisas a entender:

3.1 Frescor tem dois significados — não os confunda

Frescor do cache ≠ frescor da resposta. Dois conceitos distintos costumam ser confundidos:

Em outras palavras: respostas em cache não estão “desatualizadas” em nenhum sentido de qualidade do modelo. Elas são matematicamente idênticas às não armazenadas em cache. Mas se você colocar “o horário atual é 14:32:05” no seu prompt de sistema e depender dos acertos de cache, seu “horário atual” permanece em 14:32:05 até a expiração do TTL e seu modelo mentirá com confiança aos usuários sobre isso.

3.2 Comportamento do TTL entre provedores

O padrão de 5 minutos não é arbitrário — corresponde aproximadamente ao horizonte de pressão de memória da GPU dos modelos populares em carga de pico. Como calculamos na §1.4, o cache KV de um contexto grande pode ser de dezenas de GB; os provedores não podem se dar ao luxo de mantê-los indefinidamente.

3.3 Projetar pensando no TTL

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

Padrão A — Manter as sessões aquecidas. Para o chat, a cadência natural de requisições (de segundos a minutos entre turnos) mantém o cache vivo por conta própria. Não se preocupe com o TTL; apenas não coloque dados dinâmicos no prefixo.

Padrão B — Batimento para o batch. Para trabalhos em lote que se estendem por horas, envie uma requisição mínima a cada TTL/2 para manter o cache aquecido. O custo é essencialmente nulo (alguns tokens de entrada) e previne tempestades de despejo de cache.

Padrão C — Usar provedores de TTL longo para armazenamento a frio. Se você tem um documento de 50K tokens consultado esporadicamente (p. ex., uma vez por hora durante uma semana), os caches explícitos do Gemini (TTL de 24 horas) ou os caches em disco da DeepSeek superarão as alternativas de TTL curto apesar da taxa de armazenamento.

4. Princípios universais que todo desenvolvedor deveria conhecer

Os provedores expõem o cache em cinco formas muito diferentes — marcadores explícitos, totalmente automático, híbrido, suporte arquitetônico em disco ou nenhum. Dedicamos o próximo artigo a essa comparação (Parte 2 — Comparação e avaliação de provedores). Mas quatro princípios se aplicam independentemente do provedor e decorrem diretamente da arquitetura que acabamos de percorrer:

4.1 O cache é baseado em prefixo — a ordem importa

Como as K/V na posição i dependem dos tokens nas posições 1…i, os provedores só conseguem corresponder a um prefixo contíguo começando no token 0. Mude um único caractere na posição 0 e todo o prefixo é invalidado. Conteúdo estável primeiro, conteúdo volátil por último. Isso não é uma heurística — é uma consequência direta da estrutura causal da autoatenção (§1.1).

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

Um acerto de cache não retorna uma resposta gerada anteriormente — ele retorna vetores K e V computados anteriormente, que o modelo então usa para gerar uma resposta nova à pergunta atual. Isso significa:

• A qualidade da saída é idêntica à de uma chamada sem cache (§1.1).
• A saída é não determinística das formas habituais — temperatura, top-p etc. ainda se aplicam.
• Respostas em cache nunca estão “desatualizadas” no sentido de qualidade do modelo — apenas o conteúdo do seu prompt (carimbos de tempo, preços) pode estar desatualizado. Reveja a §3.1.

4.3 Escritas de cache são investimentos, não gratuitas

Para os provedores que cobram uma sobretaxa de escrita (Anthropic 125 %, Gemini explícito 125 %), a primeira chamada com um novo prefixo custa mais do que não usar cache. O ponto de equilíbrio é rápido (geralmente um acerto), mas se o seu prefixo “estável” muda a cada requisição, você pagará custos de escrita repetidamente sem retorno. Fique atento a isso se ordenar os 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 sua aplicação precisa rodar com vários provedores, ou você mantém três integrações, ou coloca um Token Gateway na frente para unificá-las. A Parte 2 cobre isso em detalhe.

5. O cache de prompts é dinheiro de graça?

Quase. Ele compensa quando:

• Seus prompts têm um prefixo estável — prompt de sistema, base de conhecimento, esquemas de ferramentas
• Suas chamadas são frequentes ou conectadas — mesma sessão, cargas em lote, execuções de agente em andamento
• Você consegue estruturar os prompts para que o conteúdo estável fique no início

Atenda a esses três e você normalmente verá gastos 50–90 % menores e um TTFT 3–20× mais rápido sem trocar de modelo.

A seguir: a Parte 2 — Comparação de cache entre provedores e estrutura de avaliação pega o panorama arquitetônico acima e o transforma em uma comparação recurso por recurso de Claude, OpenAI, Gemini, DeepSeek e Qwen, com uma rubrica de avaliação para escolher o provedor certo para a sua carga.

Início rápido: use o SDK da OpenAI com todos os provedores

A Synthorai expõe um endpoint compatível com OpenAI — aponte o SDK oficial openai para ele e cada modelo (Claude, GPT, Gemini, DeepSeek, Qwen) vira uma troca de modelo de uma linha. O gateway traduz cache_control para a sintaxe de cache nativa 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 para gpt-5.4-mini, gemini-2.5-pro, deepseek-v4-flash, qwen3-max — apenas o campo model muda. O gateway retorna os metadados de acerto do cache de prompts no campo padrão da OpenAI prompt_tokens_details.cached_tokens, além de um campo cost em USD, de modo que você não precisa manter localmente uma matriz de preços por fornecedor.

Perguntas frequentes

O cache de prompts em LLM é o mesmo que cache semântico? Não. O cache de prompts é baseado em prefixo — ele reutiliza os valores K/V para uma correspondência exata em nível de token no início do prompt. O cache semântico corresponde no nível do significado (via embeddings) e retorna 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 que o modelo produz a partir de uma K/V em cache são matematicamente idênticos aos de uma K/V recomputada do zero. O cache é uma otimização de eficiência pura, sem impacto na qualidade.

Por que o TTL do cache é tão curto — eles não podem simplesmente mantê-lo para sempre? O cache KV é enorme (§1.4: ~10 GB por contexto de 32K para um modelo de 70B). A memória da GPU é o gargalo; os caches são despejados sempre que o servidor precisa dessa memória para cargas ativas. Caches armazenados em disco (DeepSeek) podem viver por horas, mas caches em memória normalmente não podem.

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

Prompts em cache alguma vez ficam desatualizados de um modo que degrade a qualidade? Não, da perspectiva do modelo. Sim, da perspectiva do seu conteúdo se o seu prompt codifica informações sensíveis ao tempo. O cache armazena vetores K/V, não fatos sobre o mundo. Veja a §3.1.

Como meço a taxa de acertos do cache? Cada provedor a retorna no objeto usage da resposta — cache_read_input_tokens (Anthropic), cached_tokens (OpenAI), cached_content_token_count (Gemini), prompt_cache_hit_tokens (DeepSeek). Acompanhe esses valores no seu pipeline de logging.

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) — MLA architecture · Anthropic Prompt Caching docs · OpenAI Prompt Caching docs · Google Gemini Context Caching docs · DeepSeek KV Cache guide · Alibaba Bailian Context Cache

← Voltar ao blog