A IA que apagou a própria memória para ficar mais rápida

Uma decisão que parece errada

Imagine um assistente que, a cada pergunta nova, rasga as anotações que fez nos últimos minutos e refaz a conta mental do zero. Parece desperdício de tempo e energia. Mas foi exatamente essa a escolha da DeepSeek no V4.1-Flash, o modelo aberto lançado em 10 de setembro de 2026 — e é provavelmente o motivo pelo qual ele ficou até oito vezes mais leve para rodar.

A pista está no título do relatório técnico, que não fala de inteligência: "Pushing the Limits of KV Cache Compression" — empurrando os limites da compressão do cache KV. O gargalo que a DeepSeek atacou não é o raciocínio do modelo. É a memória que ele precisa carregar enquanto conversa.

O que é o cache KV — e por que ele é o verdadeiro gargalo

Todo modelo de linguagem trabalha em duas fases. No prefill, ele lê o prompt inteiro de uma vez e monta uma espécie de ata — o cache KV — com as chaves e valores de cada palavra processada. No decode, ele gera a resposta uma palavra por vez, e cada palavra nova se apoia nessa ata.

A conta é impiedosa. Se cada token custa C bytes de cache, uma conversa de 500 mil tokens ocupa 500.000 × C bytes antes de contar os pesos do modelo, as ativações e o lote de usuários simultâneos. Num data center, a memória HBM das GPUs é o recurso mais escasso que existe — é ela que decide quantas sessões de agente cabem em cada máquina.

Aqui está o ponto que quase ninguém percebe: para um agente que lê um repositório de código, executa ferramentas e acumula 200 mil tokens de histórico, a memória estoura antes do processamento. Não é a inteligência do modelo que limita o uso — é a contabilidade.

Como o V4.1-Flash derrubou o cache para 890 bytes por token

A geração anterior, o V4-Flash, já era considerada leve. O V4.1-Flash chega a 890 bytes por token de cache global, quatro vezes menos que a geração anterior e nada menos que 437 vezes menos que o DeepSeek-V1, de 2024.

Não foi um truque único. Foram quatro decisões treinadas dentro do modelo desde o começo:

• Arquitetura encoder-decoder causal (CED): as 40 camadas foram cortadas em duas metades — 20 de encoder e 20 de decoder. Na leitura do prompt, só a primeira metade liga: 8 bilhões de parâmetros ativos em vez de 16 bilhões. Os analistas juniores leem as milhares de páginas e escrevem o resumo executivo; os diretores leem apenas o resumo.
• CSA2 (Compressed Sparse Attention 2): cada camada de atenção opera em um de três modos — Full (cria o cache e o índice), Reindex (reaproveita o cache, mas escreve um índice novo) e Reuse (não escreve nada: pega cache e índice prontos). Apenas quatro das quarenta camadas guardam cache global. Uma camada em modo Reuse roda com 15 kernels no prefill e 11 no decode.
• Cache em FP4: o cache principal passou a ser guardado em 4 bits, com uma escala de 8 bits a cada 16 canais. Metade do tamanho do FP8 e um quarto do FP16 — com o ruído da compressão absorvido durante o treino, não aplicado depois.
• SWA Bounded Replay: a peça mais contraintuitiva de todas — e a que dá título a este post.

A memória que a IA apagou de propósito

Existe um tipo de atenção chamada janela deslizante (SWA, sliding window attention). Ela faz o modelo olhar apenas para as palavras mais recentes em vez do texto inteiro. Essas anotações locais são baratas de calcular, mas caras de guardar: em conversas de vários turnos, a DeepSeek descobriu que o cache SWA ocupava quase metade do espaço reservado para cache persistente em SSD.

O problema é o padrão de uso. O cache global tem reuso de cauda longa — vale guardá-lo por 72 horas ou mais. Já o cache SWA vive dentro de uma janela de minutos: é útil enquanto a sessão está ativa e morre no instante em que o turno termina.

A saída natural seria apagar essas anotações e refazer o cálculo quando precisasse. Aplicada ingenuamente, porém, essa ideia é proibitiva: recuperar exatamente o estado SWA exigiria reprocessar L × n_win tokens — as 40 camadas vezes as 128 posições da janela. O próprio relatório do V4 já tinha tentado essa rota, com o nome de "Zero SWA Caching", e o custo se provou inviável em produção.

O V4.1-Flash trocou o "exato" pelo "suficientemente bom". Em vez de reprocessar 40 × 128 tokens, o SWA Bounded Replay reprocessa apenas os últimos 128. Em vez de voltar quarenta páginas do caderno para reconstruir a linha de raciocínio, o modelo relê somente o último parágrafo — e, segundo os experimentos do relatório, com degradação de qualidade praticamente imperceptível.

Com isso, o cache SWA saiu do armazenamento persistente e foi para um pool de memória distribuída na DRAM dos servidores, ocupando 10% da memória principal de cada máquina, com vida útil de minutos. O cache global ficou onde importa, com garantia de pelo menos 72 horas. Resultado: a pegada de cache persistente caiu para cerca de um oitavo da geração anterior.

Vale uma reflexão sobre o que isso significa como princípio de engenharia: refazer uma conta em microssegundos, dentro da GPU, saiu mais barato do que ir até o SSD buscar a nota salva e voltar.

Uma curva que não deveria existir

O gráfico abaixo é o mais provocativo do relatório. Ele mostra os FLOPs gastos por token gerado conforme o contexto cresce — de 4 mil a 1 milhão de tokens, algo como 700 mil palavras, mais do que a maioria dos códigos-fonte de empresas inteiras.

Na conta tradicional, mais contexto significa mais trabalho por palavra. Aqui, a curva fica praticamente plana: o custo de energia e de computação por palavra gerada quase não muda, mesmo com o contexto mil vezes maior. É a diferença entre carregar a enciclopédia a cada passo e consultar a enciclopédia quando precisar.

Por trás disso estão dois componentes que valem a pena conhecer. Primeiro, o Hierarchical Sparse Indexer: no decoder, a primeira camada em modo Full monta uma lista curta de candidatos e todas as camadas seguintes são proibidas de procurar fora dela. Como o modelo foi treinado para acertar essa lista, a busca deixa de crescer com o tamanho do texto — o custo de indexar fica limitado independentemente do contexto.

Segundo, o Engram: um módulo de memória condicional com 196 bilhões de parâmetros dedicados a fatos estáticos — datas, nomes, fórmulas — que ficam na memória comum do servidor, fora da GPU, e são buscados sob demanda. É a diferença entre obrigar o advogado a decorar o código civil inteiro e deixar um assistente buscar o artigo exato na hora. O backbone do modelo tem 552 bilhões de parâmetros; os dois módulos de Engram somam 196 bilhões só de consulta.

Há ainda o DSpark, um decodificador especulativo com três blocos de atenção que escreve vários tokens por passo, e o Single-Pass mHC, que reorganiza operações para rodarem simultaneamente e corta pela metade o tráfego de memória de ativação dentro da GPU.

Os números em contexto

Traduzindo: uma janela de 1 milhão de tokens passa a ocupar cerca de 890 MB de cache global por sequência. Na taxa anterior, a mesma conversa precisaria de aproximadamente 3,5 GB — muitas vezes a diferença entre caber em um nó de GPU ou precisar de dois.

Do laboratório para o seu bolso

O modelo foi pré-treinado em 45 trilhões de tokens multimodais, com a atenção esparsa treinada a 64 mil tokens e só depois estendida a 1 milhão. E aqui está o dado que interessa a quem paga a conta: a DeepSeek cortou o preço de entrada com cache-hit para US$ 0,003 por milhão de tokens fora do horário de pico — uma queda de cerca de 60%.

Não é coincidência. Cache menor significa que a própria DeepSeek gasta menos para manter prefixos na memória da GPU, e parte da economia chega à tabela de preços. Quando uma empresa consegue servir 40 sessões de agente por máquina em vez de 10, o custo unitário desaba sem que ninguém tenha comprado uma GPU a mais.

A leitura geopolítica também é curiosa. A DeepSeek não venceu por ter mais hardware — venceu por gastar menos hardware. Enquanto parte da indústria americana compra poder computacional a preços historicamente altos, a aposta foi de engenharia de software: mudar o que precisa ser guardado.

Um detalhe importante antes de comemorar

Toda essa compressão depende de uma condição prática: o motor de inferência que você usa precisa implementar a pilha de cache completa do V4.1 — o layout FP4 exato, o compartilhamento entre camadas, os caminhos de replay. Se o seu servidor só carrega os pesos e mantém o cache tradicional, a economia simplesmente não aparece. É a diferença entre comprar um carro econômico e comprar um carro econômico que só economiza com o combustível certo.

O que isso muda no Brasil

Para quem constrói com IA por aqui, a mensagem é direta: o custo de manter um agente rodando por horas — lendo contratos, monitorando processos, acompanhando sistemas — sempre foi dominado pela memória, não pela inteligência. Quando a memória cai oito vezes, a fronteira do que é economicamente viável se move.

Tarefas que hoje ninguém automatiza porque "o custo de contexto é alto demais" passam a caber no orçamento de uma pequena empresa: acompanhar um processo judicial por semanas, revisar centenas de páginas de edital, manter um atendente que lembra de toda a conversa do cliente. A pergunta deixa de ser "o modelo é inteligente o bastante?" e passa a ser "quanto custa manter esse histórico vivo?".

O V4.1-Flash é aberto: os pesos e o relatório técnico estão no Hugging Face, e o paper completo na arXiv. A lição central, porém, vale para qualquer time — inclusive para os que nunca vão treinar um modelo. Antes de comprar mais capacidade, vale perguntar o que pode ser esquecido.

É contraintuitivo, mas os números sustentam: apagar de propósito deixou a IA mais rápida.