Capítulo 2 — O Desafio do KV Cache

Segundo post do passeio capítulo a capítulo pelo LLM Primer VI: Escalando Sistemas de IA. O capítulo que nomeia a estrutura de dados que devora a VRAM de todo sistema de serving antes mesmo que os pesos tenham chance.

Por que este capítulo existe

O loop autoregressivo do Capítulo 1 evita trabalho quadrático lembrando. A cada passo de decoding, o modelo precisa atender a todo token anterior, e fazer isso do zero significaria reexecutar o prefill inteiro a cada iteração — um multiplicador N vezes maior ao longo do comprimento de uma completude. O key-value cache é o workspace que salva essa aritmética. Ele armazena as projeções de K e V por token em cada camada, de modo que tokens posteriores só computem seus próprios K e V e leiam os anteriores de volta. O cache é a razão de o decoding se manter aproximadamente O(N) em vez de O(N²). É também, em todo sistema de produção que examinei, o maior consumidor único de VRAM. O Capítulo 2 percorre a fórmula que governa seu tamanho, as variantes arquiteturais que o encolhem e o problema de fragmentação que arruína a forma ingênua de alocá-lo.

Em uma linha: o KV cache troca aritmética por memória — e a memória escala com batch, comprimento de sequência, camadas, heads e dimensão de head, tudo ao mesmo tempo, e é por isso que clusters de serving ficam sem VRAM antes de ficarem sem qualquer outra coisa.

2.1 A fórmula que governa o tamanho do cache

A memória de KV para uma sequência é 2 × L × H_kv × D × S × bytes: dois tensores (K e V), L camadas, H_kv heads de chave/valor, dimensão de head D, comprimento de sequência S e bytes de precisão por elemento. Multiplique pelo batch para o número em nível de frota. Todo eixo é multiplicativo. O Llama-3-70B com L=80, H_kv=8 (GQA), D=128, em S=8.192 e BF16, mantém cerca de 40 GB de cache por sequência — antes do batch. Em batch 32, só o cache se aproxima de 1,3 TB, várias vezes o tamanho dos próprios pesos e várias vezes a VRAM de uma H100. O Llama-2-70B, o último grande modelo MHA, tem H_kv=64 em vez de 8, e seu cache é oito vezes maior para a mesma configuração. A fórmula não é curiosidade; é o número que determina quantos usuários simultâneos um chip consegue manter. Todo outro orçamento de memória na máquina — ativações, overhead do framework, buffers temporários — precisa caber ao redor dele.

2.2 MHA, GQA e MQA são escolhas de projeto sobre o tamanho do cache

O termo H_kv é o termo que arquiteturas modernas engenharam para baixo. Multi-head attention (MHA) usa uma head de K e V por head de query; o cache é gordo, a qualidade é a maior e cada head pode se especializar em sua noção do que atender. Multi-query attention (MQA) colapsa para uma única head de K e V compartilhada; o cache encolhe por um fator de H, mas as heads perdem especialização e há perda mensurável de qualidade em contextos mais longos. Grouped-query attention (GQA), introduzida em 2023 e hoje a escolha dominante em Llama-3, Mistral, Mixtral, Qwen e DeepSeek, particiona as heads de query em G grupos que compartilham K e V; um G típico igual a H/8 dá uma redução de cache de oito vezes, com custo de qualidade pequeno demais para as suítes de avaliação enxergarem de forma confiável. GQA não é de graça — reduz também a contagem de parâmetros da projeção de K/V, e esse orçamento é redistribuído em outros pontos do modelo — mas empiricamente a redistribuição raramente atrapalha. MLA (multi-latent attention, DeepSeek-V2) vai além com um cache latente de baixo rank; é a direção de pesquisa, mas os deployments de produção em 2026 são dominados por GQA.

2.3 A alocação ingênua desperdiça a maior parte do orçamento

A forma óbvia de alocar memória de KV — reservar uma laje contígua por sequência, dimensionada para o comprimento máximo possível — falha ao encontrar o tráfego real. A maioria das requisições termina bem antes do máximo; a cauda reservada é memória morta. No Llama-3-70B com limite de 32K, uma completude de 1.000 tokens desperdiça 31 lajes de KV cache. Em batch 32 com limite de 8K e comprimento médio de 800, cerca de 90 por cento do KV cache reservado permanece sem uso em qualquer instante. Pior: o layout é inflexível — uma nova chegada não pode aproveitar a cauda não usada de outra sequência, porque essa cauda já está comprometida. A concorrência colapsa para o que o orçamento de pior caso permitir, não para o que o tráfego médio suportaria. O problema é fragmentação interna — o mesmo modo de falha que os sistemas operacionais resolveram com paginação nos anos 60. O Capítulo 8 mostra como o PagedAttention traz essa solução para cá.

Vale a pena guardar: o KV cache — e não os pesos — é a razão de a concorrência de um cluster de serving estagnar. Qualquer técnica que o encolha (GQA, MLA, KV quantizado, sliding windows, paginação) compra concorrência na mesma taxa em que compra memória de volta.

O que o Capítulo 2 prepara

A fórmula do cache e seus eixos ressurgirão sempre que capítulos posteriores tiverem de raciocinar sobre quantos usuários cabem em uma GPU. O Capítulo 3 a utiliza para explicar por que a capacidade de VRAM importa mais do que os FLOPs ao escolher uma GPU de serving. O Capítulo 7 a utiliza para explicar por que o continuous batching é limitado pelo KV cache, não pelo modelo. O Capítulo 8 a utiliza para justificar PagedAttention, eviction H2O e prefix caching — três técnicas cujo propósito é fazer o cache se comportar mais como memória virtual paginada e menos como uma laje de bytes reservados. A fórmula é a gramática dos demais argumentos de memória do livro.

Próximo — Capítulo 3: GPUs de Data Center para IA Generativa. O silício que precisa segurar tanto os pesos quanto o KV cache, lido por mecanismo em vez de por ficha técnica.

Quer o panorama completo? O capítulo do livro inclui a derivação completa da fórmula do KV, o pseudocódigo para um passo de decoder com cache, um exemplo numérico trabalhado no Llama-3-70B em S=8.192 e batch 32, e o quadro "In Plain English" que compara MHA, GQA e MQA como estratégias de arquivo em armário. Veja o LLM Primer VI na Amazon →