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. Esta lição é interativa: arraste o contexto de 1k a 1M de tokens e veja a memória de um modelo normal estourar enquanto a do DeepSeek comprimido achata em ~26 GB. No fim você sabe, de cabeça, de onde vêm esses bytes e qual truque salva o contexto longo.
Esta lição destila a parte de KV cache desse artigo + o MODEL_CARD/README do DeepSeek-V4 (antirez). Todos os números têm fonte (rodapé). Por que importa pra missão: o KV cache decide quantos tokens de contexto o cérebro local do Alembic aguenta antes de estourar a RAM.
Objetivos desta lição
Explicar por que o KV cache existe e o que ele guarda — com a analogia da mesa de trabalho.
Calcular de cabeça o KV de um contexto pela fórmula tokens × camadas × kv_heads × head_dim × bytes × 2.
Comparar as três alavancas de corte — precisão, cabeças (MHA/GQA/MQA) e linhas guardadas (CSA) — por tipo de economia.
Justificar por que o DeepSeek-V4 cabe 1M de tokens em ~26 GB onde um modelo denso estouraria.
0→0,5 MiB
por token · KV em FP16 (regra de bolso)
0
camadas · DeepSeek-V4 (padrão CSA)
~0 GB
KV do DS4 num contexto de 1M de tokens
0
top-k de linhas que o indexador pesca
01 · O que o KV cache realmente é
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. Um contexto pequeno é barato; um contexto de um milhão de tokens, num modelo denso, vira dezenas (ou centenas) de gigabytes só de cache.
A fórmula dos bytes
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: 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. As seções seguintes atacam cada uma dessas alavancas, em ordem de impacto.
Antes da matemática, fixe a intuição. Escolha a explicação que prefere — a simples (analogia) ou a técnica (mecanismo):
A mesa de trabalho do escritor. Imagine um escritor que, a cada nova frase, precisa lembrar tudo o que já escreveu. Sem caderno, ele releria o texto inteiro antes de cada palavra — exaustivo e cada vez mais lento. O KV cache é o caderno de anotações: cada token já escrito deixa uma nota pronta (sua "chave" e seu "valor"), e o token seguinte só consulta as notas em vez de reler o livro. O preço: o caderno engorda a cada token — e num livro de 1M de palavras vira uma pilha enorme.
O mecanismo. Em self-attention, cada token projeta um vetor Q (query), um K (key) e um V (value). A saída de um token é uma soma dos V de todos os tokens anteriores, ponderada por Q·Kᵀ. Sem cache, recomputar K e V de toda a história a cada passo é O(n²). O KV cache guarda os K/V já calculados: o passo de cada token novo cai para O(n) de leitura — ao custo de armazenar 2 × n × camadas × kv_heads × head_dim números.
01b · Crescer-por-token — onde nasce o problema
A palavra-chave da fórmula é tokens: tudo o mais é constante do modelo, mas o número de tokens cresce enquanto o modelo escreve. Cada token novo acrescenta uma fatia fixa ao cache, em todas as camadas de uma vez. O diagrama mostra essa pilha subindo token a token (FP16, regra dos 0,5 MiB/token):
KV ACUMULADO · cada token adiciona ~0,5 MiB em FP16 (o cache só cresce)
Cada coluna é o cache total depois daquele token. A inclinação é constante (0,5 MiB/token em FP16): é por isso que a conta vira "GB por contexto" e não "GB por modelo".
Adivinhe antes de revelar
Um modelo denso em FP16 gasta ~0,5 MiB de KV por token. Você abre um contexto de 32 000 tokens. Antes de calcular: quanto de KV isso ocupa?
32 000 × 0,5 MiB = 16 000 MiB ≈ 16 GiB — só de cache, antes de um único byte de pesos. Em 4K seriam ~2 GiB; em 1M de tokens, ~488 GiB (impossível em 128 GB). Foi essa explosão que motivou todas as alavancas das próximas seções.
Pré-fill vs decode (por que o cache nasce grande e depois cresce devagar): ao receber o prompt, o modelo calcula o KV de todos os tokens de entrada de uma vez (o pré-fill) — o cache já nasce do tamanho do prompt. Depois, na geração (o decode), cada token novo acrescenta só a sua fatia. Por isso um prompt longo já consome muito KV antes mesmo da primeira palavra de resposta.
02 · A calculadora ao vivo — normal vs DeepSeek comprimido
Arraste o contexto de 1k a 1M de tokens. As duas barras recalculam ao vivo: o modelo normal cresce reto (0,5 MiB/token) e estoura os 128 GB; o DeepSeek comprimido achata perto de 26 GB graças à atenção esparsa que você vai ver na seção 05. É a mesma ideia da calculadora de memória da Lição 02, agora aplicada ao cache em vez dos pesos.
Repare o que acontece ao passar de ~256K: a barra vermelha cruza o teto e fica vermelha (estourou), enquanto a laranja mal se move — ela tende a um platô. Essa é a diferença entre uma curva linear e uma curva que dobra e estabiliza. Guarde a imagem: as três próximas seções explicam por que a laranja achata.
02b · A curva contexto → VRAM (lado a lado)
As barras dão um instante; a curva dá a história inteira. Aqui as mesmas duas funções estão plotadas em todo o eixo de contexto, de 0 a 1M de tokens. A diferença de forma é o conceito central da lição — comparativo nº 1:
KV vs CONTEXTO · denso (reta que estoura) vs CSA do DS4 (curva que achata) — eixo Y: GB de KV
Mesma pergunta ("quanto de KV?"), duas formas de resposta: a reta densa cruza o teto bem antes de 1M; a curva da CSA achata muito abaixo dele. Trocar uma curva linear por uma sub-linear é a essência do que o DS4 faz — e o porquê vem nas seções 03–05.
03 · Quantizar o KV — até onde dá
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 (assunto da Lição 04), 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)"
Por que o KV é mais frágil que os pesos: os pesos são lidos; o KV é a história ativa. Um erro de quantização no cache se propaga por toda a sequência seguinte. Por isso o piso seguro é 8 bits — e ir mais fundo exige algoritmos como KIVI/KVQuant, não um simples flag. A precisão corta o cache por uma constante (pela metade, num passo de 16→8 bits), mas não muda a forma linear da curva.
03b · A conta dos bytes, passo a passo
De onde sai a "regra dos 0,5 MiB/token"? Não é mágica — é a fórmula da seção 01 com números concretos. Vamos derivar para um modelo-exemplo (32 camadas, 8 cabeças de KV, head-dim 128, FP16) e depois você refaz com FP8:
A MULTIPLICAÇÃO, TERMO A TERMO · 1 token, 1 modelo-exemplo (FP16)
Exemplo resolvido · KV de um contexto de 8K tokens (FP16)
1
Bytes por token. 32 camadas × 8 kv_heads × 128 head_dim × 2 bytes (FP16) × 2 (K e V) = 131 072 bytes ≈ 0,5 MiB. É a regra de bolso.
2
Multiplique pelo contexto. 8 192 tokens × 0,5 MiB = 4 096 MiB = 4 GiB de KV.
3
Some aos pesos. Esses 4 GiB ficam além dos GB dos pesos do modelo — é a memória de trabalho, não o modelo em si.
4
Agora você tenta → refaça o passo 1 trocando FP16 (2 bytes) por FP8 (1 byte). Quanto dá por token, e quanto fica o KV de 8K? (Confira na predição abaixo.)
Confira o "agora você tenta"
Trocando FP16→FP8 no exemplo de 8K tokens:
FP8 = 1 byte: 32 × 8 × 128 × 1 × 2 = 65 536 bytes ≈ 0,25 MiB/token. Em 8K: 8 192 × 0,25 MiB = 2 GiB — exatamente metade dos 4 GiB do FP16. A precisão corta o KV por uma constante (½ aqui), mas a forma da curva continua linear no contexto.
04 · A outra alavanca — tipos de atenção
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. Clique para comparar os três tipos e ver o cache encolher:
MHA (multi-head attention): atenção completa, uma KV por cabeça de query. Mais capacidade de representação, mas o KV cache é o maior dos três — o termo kv_heads da fórmula está no máximo.
GQA (grouped-query attention): cabeças de query agrupadas, cada grupo com a sua KV. Corta o cache por uma constante mantendo quase toda a qualidade — é o meio-termo adotado pela maioria dos modelos modernos.
MQA (multi-query attention): uma única cabeça de KV compartilhada por todas as queries. Mínimo absoluto de memória de cache — o termo kv_heads vai a 1 — ao custo de alguma capacidade de representação.
Da esquerda para a direita o cache encolhe, mas todos cortam o KV apenas por uma constante. A curva ainda é linear no número de tokens — e em 1M nenhuma constante salva. Para isso, é preciso atacar quantas linhas cada camada guarda. É o que o DeepSeek faz a seguir.
04b · MHA vs GQA vs MQA, lado a lado
As abas mostraram cada tipo isolado. Agora os três juntos, na mesma escala, para a economia ficar visível e não só dita — comparativo nº 2. As barras inferiores são o tamanho relativo do KV (4 cabeças → 2 → 1):
TRÊS ATENÇÕES, MESMA ESCALA · acima = nº de cabeças de KV · abaixo = KV cache relativo
Tipo
Cabeças de KV
KV cache
Capacidade
Quem usa
MHA
= cabeças de query (ex.: 4)
Maior (100%)
Máxima
Modelos antigos / pesquisa
GQA
Poucos grupos (ex.: 2)
Médio (~50%)
Quase total
Maioria dos modelos modernos
MQA
1 só
Mínimo (~25%)
Boa, com perda
Onde a memória aperta
A leitura: GQA é o ponto-doce — corta o cache pela metade com perda de qualidade quase nula, por isso virou padrão. Mas note o eixo: todos os três só mudam a constante (100% → 50% → 25%). Nenhum muda a inclinação em relação ao contexto. Para dobrar a curva, falta a última alavanca — as linhas guardadas por camada.
05a · Como escolher a alavanca (fluxograma)
Antes do mecanismo do DeepSeek, um mapa de decisão. Diante de "meu KV não cabe", qual alavanca puxar primeiro? Este fluxograma encadeia as três em ordem de impacto crescente:
FLUXOGRAMA · "o KV não cabe" → qual alavanca puxar
Ordem de impacto: precisão e cabeças cortam por constante; só a atenção esparsa muda a inclinação. Se nem ela bastar, a saída final é cortar o contexto — a recomendação prática do antirez (100–300k).
05 · O salto do DeepSeek-V4 — atenção esparsa comprimida
Quantizar e usar GQA/MQA cortam o KV por uma constante. Mas a curva ainda é linear no número de tokens. 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, e o quanto se comprime depende do tipo da camada. Um indexador dedicado então pesca, do histórico comprimido, só as poucas linhas que importam para o token atual.
Em forma de processo, o que cada token faz numa camada par (≥2) é uma decisão simples — densa pro recente, busca esparsa pro antigo:
FLUXOGRAMA · o caminho de UM token numa camada CSA par (≥2)
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.
O insight central: contexto longo não exige olhar tudo o tempo todo. Quase todo token só depende do passado imediato (a janela crua) mais alguns trechos distantes específicos (o que o indexador pesca). A CSA codifica essa intuição direto na arquitetura — e é isso que dobra a curva linear em platô.
06 · O padrão das 43 camadas
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. A faixa abaixo é construída em JS, camada por camada, e acende uma a uma:
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
Constantes fixas da CSA (do MODEL_CARD do DS4)
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.
07 · O resultado — 1M de contexto em ~26 GB
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 da seção 02, agora em números fechados e à escala:
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)
A escolha prática: 1M de tokens é possível, não confortável. Rodar o q2 (81 GB) e ainda reservar ~26 GB para o KV de 1M deixa o sistema sem margem — e a Lição 02 já mostrou por que nunca encher a RAM até a borda. Por isso a recomendação do antirez é mirar 100–300k de contexto: fração do KV, folga preservada, e ainda muito além do que um modelo denso entregaria.
Fechando o raciocínio: 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 — precisão (FP16→FP8, corta por constante), cabeças de KV (MQA/GQA, corta por constante) e linhas guardadas por camada (a CSA do DS4, que ataca o termo linear e dobra a curva de "estoura" para "achata"). É por isso que o DeepSeek-V4 cabe 1M de tokens em ~26 GB onde um modelo denso simplesmente não caberia. A próxima lição mostra como esse modelo concreto roda no seu Mac.
07b · Discador: contexto + precisão do KV → GB
Junte as duas primeiras alavancas num só painel. Arraste o contexto e escolha a precisão do KV; o valor em GB e a curva são recalculados ao vivo para um modelo denso (a linha tracejada guarda a referência FP16 para você ver a economia da quantização). É a versão "com botões" da curva da seção 02b.
O que o painel ensina: mudar a precisão abaixa a curva (FP8 = metade do FP16; INT4 = um quarto) — mas ela continua subindo em reta. Nenhuma escolha de precisão a faz achatar. Só a CSA (seções 05–07) muda a forma — e é por isso que ela, não a quantização, é o que viabiliza 1M de tokens. [uncertain: INT4 no KV é ilustrativo do efeito da constante; na prática é território de pesquisa (KIVI/KVQuant), não um flag casual — ver seção 03.]
Fixe os conceitos (flashcards)
Clique pra virar. Tente lembrar a resposta antes de virar — recuperação ativa fixa mais que reler.
FP16/BF16 = baseline limpa; FP8/INT8 = piso prático (metade da memória). Sub-8-bit (KIVI/KVQuant) = pesquisa, não botão casual.
Atenção
MHA, GQA e MQA — o que muda no cache?
clique pra virar ↻
Resposta
Menos cabeças de KV = menos cache (4→2→1). GQA é o ponto-doce. Mas os três só cortam por constante — a curva segue linear.
CSA
Como o DS4 cabe 1M de tokens em ~26 GB?
clique pra virar ↻
Resposta
Atenção esparsa comprimida: janela crua de 128 recentes + indexador top-512 no histórico comprimido. Ataca as linhas por camada e dobra a curva (sub-linear). Indexador ≈ 22 dos 26 GB.
Revisão cumulativa — recupere de memória
Antes de clicar: tente responder de cabeça. Recuperar da memória (não reler) é o que fixa de verdade. As opções têm o mesmo tamanho de propósito — sem pista pela forma.
1. Por que o KV cache existe — qual problema ele resolve na geração?
Correto: b. O KV cache guarda K/V dos tokens passados, então cada token novo só calcula o próprio K/V e lê o resto — troca recomputo O(n²) por leitura O(n). a confunde com quantização de pesos (Lição 02/04); c é carregamento de disco→RAM, outra coisa; d descreve quantização de KV, que é uma alavanca sobre o cache, não a razão dele existir. Custo: ~0,5 MiB/token em FP16.
2. Na CSA do DeepSeek-V4, o que dá a uma camada PAR (≥2) contexto longo sem guardar tudo?
Correto: c. A camada par ≥2 combina janela crua de 128 (densa, recente) + linhas ratio-4 + indexador top-512 (busca esparsa). a troca o mecanismo certo (esparsidade) por precisão — outra alavanca; b é o oposto (MHA densa aumenta o cache); d destruiria o contexto longo — a CSA comprime o passado, não o descarta. As ímpares ≥3 vão a ratio-128 sem indexador.
3. Por que quantizar o KV ou usar GQA não basta para 1M de tokens, mas a CSA basta?
Correto: a. Esse é o fio condutor da lição: constante vs forma. FP8 e GQA dividem o cache por um fator fixo, mas em 1M nenhuma constante salva — a reta ainda estoura. A CSA muda a inclinação. b é falso: sub-8-bit é território de pesquisa (seção 03); c é falso: GQA reduz, não elimina, o cache; d confunde KV com pesos — a CSA não toca nos pesos.
💬 Travou em algo? Eu sou seu professor neste curso — pergunte. "Por que o indexador come ~22 dos 26 GB?", "FP8 no KV vale a pena no meu caso?", "Como meço o KV do meu modelo na prática?". É só dizer.