Os pesos do modelo são fixos; o que cresce enquanto o modelo escreve é o KV cache — a memória de trabalho da geração. Ela guarda os estados de atenção (chave e valor) de cada token já visto, para o modelo não recomputar todo o passado a cada novo token. Esta lição mostra de onde vêm esses bytes, por que ela estoura a RAM no contexto longo, e o truque de atenção esparsa comprimida que faz o DeepSeek-V4 caber 1M de tokens onde um modelo normal não caberia.
Quando o modelo gera o próximo token, a atenção precisa olhar para todos os tokens anteriores. Sem cache, ele recomputaria as projeções de chave (key) e valor (value) de toda a história a cada passo — trabalho quadrático e desperdiçado. O KV cache resolve isso guardando esses estados de atenção dos tokens passados, para que cada novo token só calcule o seu próprio K e V e leia o resto da memória.
O KV cache é a memória de trabalho do modelo durante a geração. Ele guarda os estados de atenção de chave/valor dos tokens anteriores para que o modelo não recompute a história a cada token.— Ahmad Osman, "LLMs 101 (2026)"
O custo é previsível. A regra de bolso do Ahmad: 0,5 MiB por token num KV em FP16. Isso escala linearmente com o comprimento do contexto — e é exatamente aí que mora o problema.
A linha vermelha (atenção densa) cresce reto e sai do gráfico antes de 256K. A laranja (atenção esparsa comprimida do DS4) dobra e estabiliza perto de 26 GiB mesmo em 1M de tokens.
O tamanho do KV não é mágica — é uma multiplicação. tokens × camadas × kv_heads × head_dim × precisão × 2 (o ×2 é porque guardamos K e V). Daí a regra de bolso: em FP16, isso dá ≈ 0,5 MiB por token. Multiplique pelo contexto: 4K ≈ 2 GiB, 32K ≈ 16 GiB. Cada alavanca da fórmula — menos kv_heads, menos precisão, menos linhas guardadas — é uma forma de cortar essa conta.
A primeira alavanca da fórmula é a precisão. Reduzir os bytes por número no cache derruba a memória direto. Mas, ao contrário de quantizar pesos, o KV é numericamente sensível — ele é a memória ativa da geração, e estragá-lo degrada a coerência na hora. O Ahmad dá os patamares práticos:
| Precisão do KV | Status | Leitura prática |
|---|---|---|
| FP16 / BF16 | Baseline limpo | Sem perda. É a referência da regra dos 0,5 MiB/token. |
| FP8 / INT8 | Piso prático | Metade da memória, qualidade aceitável. É até onde o usuário casual deve ir. |
| Sub-8-bit (KIVI, KVQuant) | Território de pesquisa | Pesado, com métodos dedicados. Não é um botão casual de ligar. |
FP16/BF16 é a baseline limpa; FP8/INT8 é o piso prático; abaixo de 8 bits é território de pesquisa (KIVI, KVQuant) — não um botão casual.— Ahmad Osman, "LLMs 101 (2026)"
A fórmula tem um termo kv_heads. Quanto menos cabeças de KV, menor o cache — e essa é exatamente a ideia por trás das variantes de atenção. O modelo pode ter muitas cabeças de query mas compartilhar poucas cabeças de key/value.
Da esquerda para a direita, menos cabeças de KV: MHA (uma KV por query, cara em contexto longo), GQA (cabeças de query em grupos compartilhando uma KV cada), MQA (uma única KV para todas as queries, a mais eficiente em memória).
Quantizar e usar GQA cortam o KV por uma constante. Mas a curva ainda é linear no número de tokens — e em 1M de tokens nenhuma constante salva. O DeepSeek-V4 ataca o termo que importa de verdade: quantas linhas de KV cada camada guarda. A técnica é a Compressed Sparse Attention (CSA), e ela funciona por camada.
Cada camada mantém uma janela deslizante crua (raw) com os 128 tokens mais recentes — atenção densa e exata onde ela mais importa, no passado imediato. Tudo que é mais antigo que isso vira linhas comprimidas (compressed), e o quanto se comprime depende do tipo da camada.
A janela crua dá precisão no passado imediato; o indexador (64 cabeças, head-dim 128) faz uma busca esparsa no histórico comprimido e devolve só as 512 linhas mais relevantes — em vez de atender a milhões de tokens, a camada atende a centenas.
A CSA não é uniforme. O DS4 tem 43 camadas, e o tipo de cada uma alterna num padrão fixo. As duas primeiras camadas são cruas e simples; depois, camadas pares e ímpares se especializam — uma agressiva no detalhe, outra agressiva na compressão.
| Camada | Tipo CSA | Ratio de compressão | Indexador? |
|---|---|---|---|
| 0 e 1 | Só janela crua | — | Não |
| Pares a partir de 2 (2, 4, 6 …) | Comprimida + busca | ratio-4 (1 linha por 4 tokens) | Sim — seleciona até 512 linhas |
| Ímpares a partir de 3 (3, 5, 7 …) | Comprimida agressiva | ratio-128 (1 linha por 128 tokens) | Não |
43 camadas · janela crua de 128 tokens · indexador com 64 cabeças · head-dim do indexador 128 · top-k do indexador 512. Camadas pares ≥2 usam ratio-4 com indexador; ímpares ≥3 usam ratio-128 sem indexador.
Junte tudo e a conta fecha onde a atenção densa nunca fecharia. Segundo o README do DS4 (antirez), o KV de um contexto completo de 1M de tokens ocupa ≈ 26 GB de memória — e o indexador comprimido sozinho responde por ≈ 22 GB disso. É a curva laranja do primeiro diagrama, agora em números fechados.
Os 81 GB de pesos mais os ~26 GB de KV (dos quais ~22 GB são o indexador) somam ~107 GB — cabe nos 128 GB, mas raspando a folga que a Lição 08 vai exigir.
Um contexto completo de 1M de tokens consome cerca de 26 GB de memória; só o indexador comprimido responde por ~22 GB. Com 128 GB rodando os 81 GB de pesos q2, um contexto de 100–300k é a escolha mais sábia.— antirez, README do DeepSeek-V4 (DS4)
O KV cache é a peça que transforma "quantos tokens cabem" numa conta de RAM concreta. Três alavancas o controlam, em ordem de impacto:
É por isso que o DeepSeek-V4 cabe 1M de tokens em ~26 GB onde um modelo denso precisaria de muito mais e simplesmente não caberia. A próxima lição mostra como esse modelo concreto roda no seu Mac.