O KV cache

01 · Conceito

Conceito

Suponha que você sirva o Qwen3.8-27B e um usuário abra uma conversa que cresce em direção ao contexto nativo de 262.144 tokens do modelo. Os pesos são um custo fixo. O que não é fixo é a memória que essa conversa mantém refém enquanto está ativa — e, para dimensioná-la, você precisa saber exatamente o que é o KV cache e, para este modelo, quais camadas de fato mantêm um.

Um modelo decoder-only gera um token, anexa e repete. Uma implementação ingênua rodaria a rede inteira de novo sobre a sequência crescente a cada passo, refazendo trabalho idêntico sobre o prefixo. O KV cache armazena os estados de attention de que os tokens futuros precisam, transformando computação repetida em memória reutilizável. Numa camada de attention, cada token produz projeções de query, key e value. Durante o decode causal, apenas a posição mais nova precisa de uma saída nova: sua query dá attention às keys em cache e mistura os values em cache, enquanto as queries passadas nunca mais são necessárias. Então o cache retém keys e values passados, e o token novo computa apenas seus próprios $q_t$, $k_t$ e $v_t$. Para um head,

onde as matrizes em cache crescem à medida que $k_t$ e $v_t$ são anexados. Isso é uma consequência da attention causal exata, não uma aproximação dela. Ignorando overhead do allocator, o modelo de memória é

com o fator dois para keys mais values, $L$ camadas com cache, $T$ posições, $H_{kv}$ KV heads, $D$ head dimension e $B$ bytes por elemento.

Agora substitua os números do Qwen3.8-27B — com cuidado, porque existe um desvio clássico aqui. A config diz 64 camadas, 4 KV heads, head dimension 256, bf16. Por token por camada: $4 \times 256 \times 2 \times 2\ \text{B} = 4096\ \text{B} = 4\ \text{KiB}$. Multiplique por 64 camadas e você obtém 256 KiB por token, e em contexto completo $256\ \text{KiB} \times 262{,}144 = 64\ \text{GiB}$ para uma única sequência — o que, ao lado de 54 GB de pesos em bf16, encheria até a borda um acelerador de 192 GB com dois usuários e o estouraria com três. Essa estimativa está errada, e errada de um jeito instrutivo: ela supõe que toda camada é uma camada de attention.

A lição 4.16 mostrou que apenas 16 das 64 camadas são full attention; as outras 48 são camadas de Gated DeltaNet, que mantêm um estado recorrente de tamanho fixo e não fazem cache de nada por token. A derivação correta:

A suposição errada quadruplicou a resposta. Dezesseis gibibytes ainda é enorme — cerca de um quinto de uma placa de 80 GB para uma conversa — mas é o número real, e todo plano de capacidade das tracks 8 e 9 se apoia nele.

As 48 camadas de DeltaNet são o contraponto. A implementação de referência do Transformers mantém o estado matricial recorrente em float32: 48 value heads × 128 × 128 × 4 bytes = 3 MiB por camada, ou 144 MiB nas 48, sem contar um estado de convolução curta muito menor. Esse valor é constante no comprimento da sequência. O token um e o token 262.144 custam a mesma memória matricial. Outros runtimes podem escolher outro dtype para o estado, então confira a alocação realizada; a barganha arquitetural é o formato fixo, não um número universal de bytes.

Mesmo dentro das camadas com cache, as 4 KV heads já são uma economia: o modelo pede que 24 query heads compartilhem 4 K/V heads (grouped-query attention), encolhendo $H_{kv}$ e, portanto, o tamanho do cache e a banda do decode. A lição 7.6 compara essa escolha com MQA e MLA numericamente. Formatos de cache quantizados encolhem $B$; sliding windows encolhem o $T$ efetivo ao preço do esquecimento.

Dimensionar é só metade da engenharia. O decode lê um histórico longo para produzir pouca computação nova, então mover dados de K/V pode dominar; os kernels precisam de layouts amigáveis enquanto as sequências crescem de forma imprevisível. Reservar antecipadamente os 16 GiB máximos de cada requisição seria ruinoso; a alocação paginada distribui blocos de tamanho fixo sob demanda no lugar disso (lição 7.8). O prefix caching compartilha blocos entre requisições que começam com exatamente a mesma sequência de tokens, como um system prompt comum — seguro somente sob o mesmo modelo, adapter e tratamento posicional, e nunca através de fronteiras de autorização.

Uma última correção à intuição: o cache não torna o decode de tempo constante em contexto. A reprojeção do prefixo desaparece, mas cada nova query nas 16 camadas de attention ainda lê e dá attention a tudo o que foi retido. O modelo durável é uma transcrição — computação já realizada vira memória, poupando aritmética ao preço de responsabilidades crescentes de banda, capacidade, ciclo de vida e privacidade — mantida, neste modelo, por apenas um quarto das camadas.