DeepSeek-V4.1 Flash comprime cache KV para 890 bytes por token

Contexto e tese do artigo

O texto é uma análise técnica detalhada do relatório técnico do DeepSeek-V4.1 Flash, publicado no blog zartbot. O autor relata que, ao lançamento, imaginou tratar-se de uma simples iteração de pós-treinamento, mas o desempenho observado - cerca de 420 tokens por segundo - e a decisão de retirar de operação os modelos DeepSeek-V4 Pro indicaram uma mudança mais profunda. Para o autor, o modelo seria mais apropriadamente chamado de DeepSeek-V5 Flash.

A tese central, alinhada ao título do próprio relatório, é que o objetivo do modelo é levar a compressão do cache KV (KVCache) ao extremo. A motivação declarada é que fluxos de agentes de longo horizonte (long-horizon agents) fazem o contexto crescer cada vez mais, e chamadas frequentes de ferramentas geram pressão pesada de computação de prefill. O armazenamento do KVCache em memória HBM e SSDs externos se torna um gargalo que limita a escalabilidade dos serviços.

Arquitetura geral

O DeepSeek-V4.1 Flash é um modelo multimodal mixture-of-experts com 552B de parâmetros, contexto de até 1 milhão de tokens e 40 camadas (20 de Encoder, 20 de Decoder). Durante o prefill, ativa cerca de 8B de parâmetros por token; durante o decode, 16B - o que o autor destaca como especialmente vantajoso para cenários de agentes dominados por entrada.

O conjunto de otimizações combina quatro frentes: a arquitetura CED, o mecanismo de atenção CSA2, memória condicional via Engram e decodificação especulativa via DSpark, além de quantização FP4 do KVCache. O resultado alegado é que, mantendo a qualidade das tarefas, o modelo ocupa cerca de 1/4 do armazenamento de KVCache em execução e 1/8 do armazenamento persistente do DeepSeek-V4-Flash, com crescimento de apenas cerca de 890 bytes por token no cache global principal e no Indexer.

CED: Encoder-Decoder causal

Inspirado na arquitetura YOCO, o CED divide o modelo em duas metades de 20 camadas. O Decoder não gera seu próprio KV global por camada: ele projeta o KV global a partir dos estados ocultos finais do Encoder (camada 20). Assim, a maior parte de um prompt longo só precisa atravessar as primeiras 20 camadas, reduzindo a complexidade do prefill e cortando a computação total aproximadamente pela metade.

Um problema adicional é o replay do SWA local: posições históricas que param no Encoder não têm o KV local das camadas profundas do Decoder. Como o campo receptivo efetivo do SWA é muito menor que o teórico - o autor cita o trabalho PowerAttention, que estima que a informação decai pouco após cerca de 6 camadas - o modelo adota o Bounded Replay, recalculando o SWA apenas das últimas posições e aceitando uma reconstrução aproximada, controlada por avaliação de qualidade e adaptação de pós-treinamento.

CSA2: compressão em três dimensões

O CSA2 estende a evolução anterior da DeepSeek (MLA na dimensão de canal, CSA/HCA na dimensão de sequência) para a dimensão de camada. Ele combina três eixos multiplicativos: compartilhamento de um vetor latente de 512 dimensões entre cabeças; compressão de 2 posições adjacentes em 1 entrada no Encoder (compressão 2:1, com o Decoder mantendo granularidade por posição); e reuso de cache entre camadas, com apenas 3 cópias de cache do Encoder e 1 do Decoder na rede inteira.

O reuso entre camadas ocorre em três modos: Full (calcula KV, Indexer e novos índices Top-K), Reindex (reusa o KV principal e recalcula os índices) e Reuse (reusa KV e índices, alterando apenas as queries). O autor interpreta blocos de 1 camada Full + 5 de Reuse como uma forma de Transformer recursivo que itera modificando Q.

Componentes complementares e conclusão

O Engram injeta memória condicional endereçável por n-gramas (ordens até 4, tabelas com cerca de 384 milhões de linhas) nas camadas 1 e 14, com controle de contexto pela janela local. O DSpark usa três blocos rascunho SWA-128 com MoE menor para decodificação especulativa. O ramo visual usa ViT de 32 camadas com downsample que reduz os tokens de imagem a 1/9, com limite de 1024 tokens por imagem, e balanceamento de carga do MoE com viés por modalidade.

A conclusão do autor é que, somadas arquitetura, precisão do cache e estratégia de implantação, essas escolhas fazem o custo computacional do modelo crescer quase linearmente até 1M de tokens, com overhead muito inferior ao das gerações anteriores - reforçando sua leitura de que o avanço é de magnitude de versão maior, não de simples refinamento.