O quê

KV Cache (Key-Value Cache) é a estrutura de dados que torna inferência autoregressive de Transformers viável em produção. Sem ela, gerar um token novo exigiria reprocessar toda a sequência anterior desde o início. Com ela, cada nova predição reusa o trabalho já feito, custando apenas o forward de um único token.

KV cache não é uma técnica explícita inventada por um paper — é a otimização natural que cai do desenho do Transformer autoregressive. Mas sua importância prática para custo, latência e escala de LLMs é difícil de exagerar. Em 2025, otimizar KV cache (PagedAttention, GQA, MLA, MQA) é uma das frentes mais ativas de pesquisa em sistemas de IA.

Em Magik LLM Gathering, KV cache é tratada como Technique · Inference · Uncommon — a primitiva que preserva memória sequencial sem recomputar.

Como funciona

Por que precisa existir

Em geração autoregressive, cada token novo t depende de todos os tokens anteriores 1..t-1. Naive: pra gerar token 1000, você roda forward em [1..999], pega último output. Pra gerar 1001, roda em [1..1000]. Total: O(N²) processamento para gerar N tokens.

Insight: a maior parte desse trabalho é redundante. Quando você processa [1..999], computa as projeções K e V de cada token. Quando processa [1..1000], recomputa K e V de [1..999] de novo. Isso é o que o cache evita.

A operação cached

Pra cada camada de attention, durante geração:

1. Receba token novo t (apenas 1 token).
2. Computa Q, K, V só para t.
3. Concatena K_t e V_t com cache de K_ e V_ (que está armazenado em memória).
4. Computa attention(Q_t, K_{1..t}, V_{1..t}) — Q de tamanho 1, K e V de tamanho t.
5. Output do attention vai pra FFN, depois pra próxima camada.
6. Guarda K_t e V_t no cache pra próxima iteração.

Resultado: cada token novo custa O(t) compute em vez de O(t²). Para sequência de 10000 tokens, fala-se de 10000× menos compute.

O custo

O preço pago é memória. Para cada camada × cada token × cada cabeça, você armazena K e V (cada um um vetor de head_dim floats). Total memória:

mem = 2 × num_layers × num_heads × head_dim × seq_len × batch_size × bytes_per_float

Para Llama 70B (80 layers, 64 heads, 128 head_dim, fp16): cada token de contexto custa ~2.6 MB por requisição. 100k tokens = 260 GB só de KV cache. Mais que a memória dos pesos do próprio modelo (140 GB em fp16).

Esta explosão de memória é o motivo principal pelo qual long-context é caro e por que dispositivos de consumidor não rodam modelos grandes em context >32k.

Otimizações modernas

• Multi-Query Attention (MQA): compartilha K e V entre todas as cabeças. KV cache cai por fator num_heads (~10-128×). Performance ligeiramente pior.
• Grouped-Query Attention (GQA): meio-termo, compartilha K/V entre grupos de cabeças. Llama 3, Mistral usam.
• Multi-Head Latent Attention (MLA) (DeepSeek-V2): comprime K/V em representação latente menor. Cache muito menor com mínima perda de qualidade.
• PagedAttention (vLLM, 2023): aloca KV cache em “páginas” de tamanho fixo em vez de blocos contíguos. Reduz fragmentação, permite serving múltiplas requisições eficientemente. Inspirado em virtual memory de SOs.
• Cache eviction: pra contexto muito longo, descartar tokens antigos do cache (sliding window, attention sinks). Trade-off entre context length e qualidade.
• Quantization de KV: armazenar cache em int4/int8 em vez de fp16. 2-4× menos memória, ligeira perda de qualidade.

Por que importa

KV cache é a infraestrutura invisível que torna LLMs servíveis economicamente:

• Sem KV cache, ChatGPT custaria 100×+ por chamada. Cada chamada teria que reprocessar prompt inteiro. Não seria viável a $0.01/1k tokens.
• Long context só existe por causa do cache + suas otimizações. Claude 200k e Gemini 1M dependem de gestão eficiente de KV cache.
• Prompt caching (Anthropic, OpenAI) é literalmente disk caching do KV cache. Cobra menos pra reusar prefixos. Economia de 90%+ em pipelines com prompts fixos.
• Throughput de serving inteiro depende disso: vLLM, TGI, TensorRT-LLM — todos competem por melhor KV cache management.

A engenharia de KV cache eficiente vale literalmente bilhões de dólares em economia de compute para Anthropic/OpenAI/Google/Meta combined.

Pegadinhas

• Memória dominante: na maioria dos workloads de inferência, KV cache > modelo em memória. Otimizar quantization e PagedAttention é mais impactante que comprimir pesos.
• Sharing entre batch é não-trivial: prompts diferentes têm KV cache diferente. Algumas otimizações (prefix sharing) tentam reusar quando prompts compartilham início.
• Cache invalidation em streaming: se prompt muda no meio (insert, delete), cache fica inválido a partir daquele ponto. Stream editors precisam de cache management complexo.
• Não funciona em prefill paralelo: a geração token-a-token usa cache; mas o prefill (processar prompt inicial) processa tudo em paralelo sem cache. Prefill é compute-bound; geração é memory-bound. Otimizações são distintas.
• Não confundir com prompt cache: KV cache é por-request em memória GPU. Prompt cache (Anthropic, OpenAI feature) é persistência em disco entre requests pra prefixos comuns. Mesma ideia, escalas diferentes.
• Hardware impacta: GPUs com mais HBM (H100 80GB, B100 192GB) servem context longer. GPUs consumer (4090 24GB) batem teto cedo.

Estado em 2026

Em 2026, gerenciar KV cache é provavelmente a frente mais quente de sistemas de inferência. PagedAttention (vLLM) virou padrão da indústria, e a guerra de serving (vLLM, SGLang, TensorRT-LLM) gira em torno de quão bem cada engine compartilha e reutiliza cache. Prefix caching automático (reuso de prefixos comuns entre requisições) e disaggregated prefill/decode — separar a fase compute-bound da memory-bound em GPUs diferentes — são as grandes otimizações arquiteturais do biênio.

Do lado do modelo, reduzir o tamanho do cache deixou de ser opcional. GQA é praticamente universal; Multi-head Latent Attention (DeepSeek-V2/V3) comprime KV num latente e foi um dos motivos do custo baixíssimo do DeepSeek; quantização de KV para int8/fp8/int4 é rotina. A explosão de memória em contextos de 1M tokens é o que ainda impede long-context barato — o cache, não os pesos, é o teto.

Os trade-offs de 2026: cada técnica de compressão de KV troca um pouco de qualidade (recall em contexto longo) por muita memória. Prompt caching persistente (Anthropic, OpenAI, Google) levou o conceito de KV cache ao nível de produto, cobrando ~10% por hits. E o hardware segue ditando o limite: a HBM por GPU (H100 80GB, H200 141GB, B200 192GB) define quanto contexto cabe — KV cache é, em essência, um problema de largura de banda e capacidade de memória.

Tratamento de carta — proposta

Em Magik LLM Gathering, KV cache aparece como Technique · Inference · Uncommon: ao entrar, escolha um Model em jogo — todas as Techniques que ele executou nesta partida ainda contam pra ele (efeitos cumulativos persistem). Custo: ele não pode ser movido até o fim do turno. Mecânica espelha a essência: você ganha continuidade de memória em troca de imobilidade.

É a carta de decks que constroem efeitos cumulativos numa única peça forte ao longo da partida.

Veja também

• Attention (mechanism) — mecanismo que KV cache otimiza
• Transformer — arquitetura onde KV cache existe
• Prompt Caching — extensão persistente do KV cache
• Context Window — limite que o KV cache management define