DeepSeek-V4.1-Flash reduz o KV cache na HBM para 890 bytes por token, contra 3514

A DeepSeek apresentou o V4.1-Flash, um modelo MoE multimodal com contexto de 1M de tokens. O tronco principal tem 552B parâmetros, e outros 196B ficam nas tabelas de memória Engram. O principal resultado diz respeito à operação: o KV cache global na HBM foi comprimido para 890 bytes por token, enquanto o DeepSeek-V4-Flash anterior ocupava 3514 bytes. O cache de longo prazo em SSD caiu para cerca de um oitavo do volume anterior. Para sessões de agentes de um milhão de tokens, isso elimina o principal gargalo: a memória do cache deixa de determinar quantas sessões um servidor aguenta.

Uma publicação no canal do Telegram gonzo_ML aponta para um artigo com cerca de 500 autores (arXiv 2609.19969), uma resenha no Substack e os pesos no Hugging Face. O código não está em acesso aberto; o cartão do modelo indica N/A.

Três mecanismos de economia de memória

O primeiro mecanismo é um esquema causal codificador-decodificador, o CED. O modelo foge do decoder-only habitual: no prefill, quando lê um prompt longo, ficam ativos 8B parâmetros, e na geração da resposta, 16B. O autor da resenha observa que esse parece ser o único dos grandes modelos abertos com essa arquitetura. Os análogos mais próximos são o encoder-decoder T5Gemma e o esquema decodificador-decodificador YOCO.

O segundo mecanismo é a atenção CSA2. Ela reutiliza o cache em formato FP4 entre camadas, então cada camada não precisa guardar a própria cópia. É aqui que vem a maior parte da compressão até 890 bytes por token.

O terceiro mecanismo é o recálculo limitado da janela deslizante, o SWA Bounded Replay. O cache local da janela deslizante deixa de ser gravado em disco e, quando necessário, é restaurado por recálculo em um trecho limitado. Isso tira parte da carga do SSD e explica por que o volume do cache em disco caiu cerca de oito vezes.

Benchmarks: paridade com o Opus-5 em tarefas de agentes

No DeepSWE v1.1 (conjunto de tarefas de correção de bugs em repositórios reais), o V4.1-Flash resolve 74,2% das tarefas. O V4-Flash tem 54,4%, e o Opus-5, 74,0%. No Terminal-Bench 2.1 (tarefas de agente na linha de comando), o modelo chega a 90,6% de Pass@1, ou seja, resolve a tarefa na primeira tentativa. O V4-Flash faz 82,7% aqui, e o Opus-5, 89,1%.

Assim, a atualização não só barateou a inferência como elevou a qualidade em programação e cenários de terminal. O ganho no DeepSWE é de cerca de 20 pontos percentuais sobre a antecessora. Para desenvolvedores que montam ciclos longos de agentes, é um argumento relevante a favor de um modelo aberto.

O que não está no artigo

Há também limitações. O trabalho não traz ablações por componente, então não está claro quanto CED, CSA2 e o recálculo da janela contribuem, cada um, para a economia de memória e para a qualidade. Também não há curvas de qualidade de recuperação para o contexto de 1M de tokens. Os 890 bytes por token declarados mostram o custo de armazenamento, mas não provam que o modelo encontra com confiabilidade o trecho certo em todo o comprimento.

Em tarefas científicas difíceis, o resultado é nitidamente mais modesto. No Terminal-Bench 4.0, o V4.1-Flash marca 31,2%, e o Opus-5, 51,8%. A paridade com o sistema fechado se confirma no Terminal-Bench 2.1 e no DeepSWE v1.1, mas não no mais difícil dos benchmarks listados.

A conclusão prática para quem hospeda modelos por conta própria: segundo o artigo, com contexto de um milhão de tokens o limite passa a ser o processamento, não a HBM nem o SSD para o cache. Isso muda o cálculo de custo das sessões longas de agentes. Mas, enquanto não saírem o código, as ablações e medições independentes de contexto longo, os números continuam sendo declarações dos autores. Os pesos podem ser baixados e testados em tarefas próprias.