O KV cache

1

Conceito

Um modelo decoder-only gera um token, anexa-o ao contexto e repete. Uma implementação ingênua executaria o Transformer inteiro sobre a sequência crescente a cada etapa. Quase todo trabalho nas posições antigas seria idêntico. O KV cache guarda os estados de attention necessários no futuro, transformando esse cálculo repetido do prefixo em memória reutilizável.

Numa camada de attention, cada token produz projeções de query, key e value. Durante decode causal, apenas a posição nova precisa de uma saída. Sua query atende às keys de todas as posições anteriores permitidas e usa os pesos para misturar os values. Queries antigas não são mais necessárias: já produziram suas saídas. Assim, o cache preserva keys e values, enquanto o token novo calcula $q_t$, $k_t$ e $v_t$.

Para uma head, a operação lembra

e as matrizes em cache crescem ao anexar $k_t$ e $v_t$. Isso ocorre em toda camada armazenada. O cache é consequência de attention causal exata, não uma aproximação.

Ignorando overhead do allocator, um modelo intuitivo de memória é

em que o fator dois representa keys e values, $L$ é a quantidade de camadas, $T$ as posições, $H_{kv}$ as KV heads, $D$ a dimensão e $B$ bytes por elemento. Multiplique de novo pelas sequências ativas. Isso explica por que long context esgota memória sem alterar os pesos.

Multi-head attention usa K/V separados por head. Multi-query e grouped-query attention compartilham K/V entre query heads, reduzindo $H_{kv}$, tráfego e capacidade. Cache quantizado reduz $B$, com trocas de accuracy e suporte de kernel. Sliding windows ou eviction reduzem $T$, mas posições antigas deixam de participar da attention comum.

O layout afeta desempenho. Decode lê um histórico longo para criar pouco cálculo novo, então mover K/V pode dominar. Tensores precisam de uma disposição eficiente para kernels, enquanto o servidor aloca sequências que crescem sem previsão. Reservar o máximo desperdiça memória; mover buffers contíguos gera cópias e fragmentação. Alocação paginada resolve esse problema de ownership.

Prefix caching compartilha blocos computados quando requisições começam pela mesma sequência de tokens, por exemplo um system prompt. Compartilhamento seguro exige mesmo modelo, adapter, tratamento posicional e tokens. Textos iguais podem tokenizar de outro modo. Cache keys nunca devem atravessar fronteiras de autorização quando estado ou timing revelam contexto privado.

Beam search e speculative decoding complicam ownership. Candidatas compartilham prefixo, ramificam e descartam caminhos. Block tables com copy-on-write evitam cópias. Cancelamento deve reduzir referências exatamente uma vez. Um leak remove capacidade; reutilização precoce mistura estados de requisições diferentes.

O cache não torna decode constante no comprimento. A projeção do prefixo desaparece, mas a nova query ainda lê os estados retidos, a menos que a arquitetura use janela limitada ou outro mecanismo. O modelo mental é uma transcrição: cálculo já feito vira memória, economizando aritmética ao custo de bandwidth, capacidade, ciclo de vida e privacidade.