DeepSeek atualiza V4.1-Flash e salta em testes de código

Esta matéria é uma atualização. Em 10 de setembro de 2026 cobrimos o lançamento do DeepSeek V4.1-Flash, que abriu os pesos e cortou o cache KV em quatro vezes. O que mudou agora é um novo checkpoint do mesmo modelo.

A DeepSeek publicou em 17 de outubro de 2026, no Hugging Face, o checkpoint DeepSeek-V4.1-Flash-1017. O cartão do modelo o descreve como uma “atualização menor” do V4.1-Flash — e, ao mesmo tempo, afirma trazer melhorias substanciais em raciocínio, programação, tarefas agênticas e testes visuais. A licença segue MIT, cobrindo repositório e pesos.

Essa tensão entre o rótulo modesto e os ganhos declarados é o ponto que merece exame. Os números publicados pela própria empresa mostram saltos que não combinam com a expressão “atualização menor” — especialmente em testes de execução de tarefas de programação.

O que mudou, segundo os números

A tabela abaixo reúne os resultados divulgados no cartão do modelo, comparando o novo checkpoint com a versão de setembro:

Os maiores avanços aparecem no Terminal-Bench 4.0 (de 31,2 para 42,3) e no ProgramBench (de 20,3 para 29,1) — ambos testes de tarefas longas, em que o modelo precisa encadear muitos passos sem se perder. São justamente as avaliações em que modelos abertos costumavam ficar mais atrás.

O cartão também afirma que o modelo reduz o tempo de execução das tarefas e o tamanho das respostas, o que diminui o custo por tarefa. Essa é uma métrica relevante na prática: em uso agêntico, boa parte do gasto vem de respostas longas e de passos desnecessários, não do preço por token.

Uma ressalva importante sobre esses números

Todos os resultados acima são autodeclarados, divulgados pela empresa no cartão do modelo, sem verificação independente até o momento. A comparação do cartão inclui K3, GLM-5.3, GPT-5.6 Sol e Opus 5 — e vale registrar que, na própria tabela publicada pela DeepSeek, o Opus 5 aparece à frente na maioria das linhas. Publicar uma comparação em que não se lidera é um sinal de transparência, mas não substitui avaliação de terceiros.

Há ainda uma lacuna de documentação: o cartão não explica o que foi alterado. Não há descrição de mudança de arquitetura, de dados ou de procedimento de treinamento, nem registro de alterações. O relatório técnico vinculado cobre o V4.1-Flash original, não este checkpoint. Sabe-se que os resultados melhoraram; não se sabe por quê.

A base que não mudou

Como não há alteração de arquitetura declarada, vale recapitular o que sustenta o modelo, descrito no lançamento de setembro:

• Mistura de especialistas (MoE) com 1 especialista compartilhado e 384 roteados por camada, dos quais apenas 6 ficam ativos por token.
• Ativação esparsa — cerca de 8 bilhões de parâmetros ativos na fase de preenchimento e 16 bilhões na decodificação, embora o modelo tenha 552 bilhões de parâmetros de base (763 bilhões no total, conforme a listagem do Hugging Face).
• Arquitetura codificador-decodificador causal de 40 camadas, 20 em cada metade, com esquema próprio de atenção esparsa e compressão do cache KV em FP4.
• Janela de contexto de 1 milhão de tokens e entrada multimodal, com codificador visual próprio.

É esse desenho que explica o apelo do modelo: o custo computacional por token corresponde a uma fração pequena do tamanho total, o que torna viável rodá-lo com infraestrutura bem menor do que a contagem de parâmetros sugeriria.

O que considerar antes de adotar

Do lado favorável, a combinação de licença MIT, pesos abertos e ganhos concretos em tarefas de programação torna o checkpoint atraente para quem monta agentes de código em infraestrutura própria — cenário em que não enviar dados para uma API externa costuma ser requisito, não preferência.

As limitações práticas, porém, são concretas e aparecem no próprio cartão:

• Não há modelo de conversa em Jinja. A formatação dos prompts depende de uma implementação de referência em Python ou do conjunto de ferramentas deepseek-recipe. Quem espera encaixar o modelo num fluxo existente sem ajuste vai encontrar atrito.
• Os requisitos de execução são altos. A recomendação inclui janela de 1 milhão de tokens e limite de saída de pelo menos 256 mil tokens — o que, mesmo com ativação esparsa, exige memória considerável para o cache.
• A amostragem recomendada é específica (temperatura 1,0 e top_p 1,0), e desvios podem não reproduzir os resultados divulgados.
• O cartão não traz seção de limitações nem discussão de riscos, lacuna que persiste desde a versão de setembro.

Vale também dimensionar a adoção com os dados públicos do repositório: o checkpoint de outubro registrava cerca de 17,9 mil downloads e 1,6 mil marcações de interesse, contra aproximadamente 1,37 milhão de downloads e 4,7 mil marcações do V4.1-Flash de setembro. A diferença é esperada — o checkpoint tem dois dias de vida —, mas serve de lembrete de que a base instalada ainda está na versão anterior.

Por que isso importa além do ranking

O ponto estratégico não está em nenhuma linha isolada da tabela. Está no intervalo: cinco semanas separam o lançamento de setembro deste checkpoint, com ganho de mais de dez pontos em um teste de execução de tarefas. Modelos de pesos abertos deixaram de acompanhar a fronteira a cada ciclo anual e passaram a iterar em escala de semanas.

Para quem decide arquitetura, isso muda o cálculo. Escolher um modelo aberto deixa de significar aceitar um atraso estrutural de desempenho e passa a significar assumir um custo de manutenção — acompanhar checkpoints, revalidar prompts e refazer avaliações com mais frequência. O risco migra de qualidade para esforço operacional.

Conclusão

O DeepSeek V4.1-Flash-1017 é uma atualização incremental no nome e substancial nos números declarados, sobretudo em tarefas longas de programação. Mantém licença MIT, pesos abertos e a arquitetura esparsa que torna o modelo executável fora de grandes provedores.

As duas ressalvas devem andar junto com qualquer decisão: os resultados são autodeclarados e não há explicação do que mudou. Para uso em produção, o caminho prudente é reproduzir internamente os testes que importam para o caso de uso, em vez de adotar a tabela como dada. O que vale observar nas próximas semanas é se avaliações independentes confirmam o salto no Terminal-Bench e se a DeepSeek publica um relatório técnico cobrindo especificamente este checkpoint.

Fontes e referências

• Hugging Face — Cartão do modelo DeepSeek-V4.1-Flash-1017
• Hugging Face — Cartão do modelo DeepSeek-V4.1-Flash, versão de setembro
• Hugging Face — Repositório oficial da DeepSeek
• Plugged Ninja — DeepSeek V4.1-Flash abre pesos e corta o cache KV em 4 vezes