Um cartão de título hero para o DeepSeek V4.1 Flash com o texto 'Lançamento oficial: Encoder-Decoder Causal de 552B, pesos MIT, contexto de 1M', com badges em formato de pílula 'GA - 10 SET 2026', '552B MoE' e 'PESOS MIT', uma linha de rodapé 'Especificações e benchmarks relatados pelo fornecedor; nenhuma avaliação independente ainda.', e o logotipo da OrcaRouter composto no canto inferior direito.
Engineering & Research

DeepSeek V4.1 Flash chega ao GA: 552B sob uma nova arquitetura, pesos MIT e um fim do V4 Pro que nunca aconteceu

Autor

Rowan Sterling

Data de publicação

Modelos mais recentes · 20Ver todos os modelos →
Benchmarks: Artificial Analysis · atualizado diariamente
Voltar para todas as publicações

O DeepSeek V4.1 Flash não é mais um experimento de dois dias. O modelo que passou 8 e 9 de setembro dentro da API ao vivo do fornecedor sob um ID que trazia sua própria data de expiração — deepseek-v4.1-flash-expires-on-0910 — foi lançado para valer em 10 de setembro de 2026, no aplicativo, na interface web e na API da DeepSeek, onde agora atende pelo nome de modelo deepseek-flash. Três coisas sobre o lançamento são maiores do que a beta sugeria. A primeira é a documentação: a DeepSeek publicou um relatório técnico — intitulado, sem muita sutileza, “Empurrando os Limites da Compressão de Cache KV” — e pesos licenciados sob MIT para um modelo multimodal de mistura de especialistas com 552B de parâmetros, construído sobre uma nova arquitetura Causal Encoder-Decoder. Esses pesos não são uma promessa: 48 shards de safetensors, cerca de 510 GB no total, entraram no ar na manhã do lançamento, o que transforma o slogan não verificado da beta — “nova arquitetura, multimodal nativo” — em algo que o leitor pode baixar e inspecionar. A segunda é o formato da linha. DeepSeek V4 Flash e DeepSeek-V4-Flash-Vision-Exp foram aposentados, com seus IDs antigos ainda resolvendo para o novo modelo nas tarifas Flash, e o plano de descontinuar o DeepSeek V4 Pro em 14 de setembro foi retirado antes de a data chegar: o V4 Pro continua sendo servido, com cobrança inalterada, e a DeepSeek prometeu aviso antes de qualquer mudança. O modelo mais barato da família tomou o lugar do carro-chefe em preço e nos próprios benchmarks da DeepSeek, e a DeepSeek diz que a arquitetura por baixo dele foi projetada para escalar para modelos maiores. O que fica acima dele é, em 25 de setembro, o palpite de um rastreador — uma linha de três níveis Flash, Pro e Ultra com 522B, 2T e 8T — oferecido pela conta que o publicou como especulação e confirmado por nada que a DeepSeek tenha publicado. O terceiro é o que a beta nunca teve. A Artificial Analysis publicou agora as primeiras avaliações externas do modelo — uma pontuação de 39 no Intelligence Index no modo Reasoning com esforço máximo para os pesos de setembro e 45 para o checkpoint 1017 (um ganho de seis pontos que o empata com o GLM-5.3 em segundo lugar entre modelos de pesos abertos, um ponto atrás do MiMo-V2.6-Pro), contra 36 do DeepSeek V4 Pro 0813 na mesma escala, o que faz do modelo de 552B o modelo DeepSeek de maior pontuação que o site já mediu. Dez outros itens são mais recentes que o lançamento e apontam em direções diferentes. Em 25 de setembro, o próprio responsável por testes de modelos do ARC Prize abriu um pull request adicionando um perfil de primeira classe do DeepSeek V4.1 Flash ao harness de benchmarking da fundação — o avaliador cujo quadro este campo interpreta como um teto de raciocínio, e não como uma verificação de produtividade, chegando sem nenhum resultado anexado e sem nenhum prometido. Três dias depois, um laboratório externo publicou o tipo oposto de notícia: uma medição concluída, em outro quadro, que coloca o DeepSeek V4.1 Flash ao lado de outro modelo de pesos abertos e o considera o mais fraco dos dois — e constata que o número varia mais com o harness em volta do modelo do que com o próprio modelo. No Exploit Bench, um benchmark da Carnegie Mellon que pontua até onde um agente chega rumo à exploração total de um V8 de produção, o DeepSeek V4.1 Flash teve média de 4,7 de 16 sob a configuração padrão do próprio benchmark e 9,3 sob o Claude Code, enquanto o GLM-5.3-Flash atingiu o pico de 10,6 sob o Codex e caiu para 6,2 sob o exato harness que mais favorece o DeepSeek V4.1 Flash. O terceiro é o menos dramático e o mais fácil de verificar: em 7 de outubro, o projeto vLLM publicou seu próprio balanço de três semanas sobre a operação deste modelo em serviço, informando que sua build atual é 1,9× mais rápida em baixa concorrência e tem 5,3× a vazão sob uma restrição de 150 TPS, em comparação com sua própria implementação do dia zero — um antes e depois do próprio motor sobre si mesmo, e não outra avaliação externa, e o tema da seção de velocidade abaixo. O quarto é sobre quanto custa usar o modelo, e não sobre quanto ele pontua, e mudou duas vezes em três dias: em 12 de outubro, o OpenCode, o agente de programação que precifica este modelo por franquia de uso mensal, e não por tokens medidos, aumentou sua franquia para ele de US$ 60 para US$ 80 — uma declaração da própria plataforma sobre um produto que vende, divulgada em sua própria página de preços — e, em 15 de outubro, começou a servir o mesmo modelo gratuitamente, sob um segundo ID de modelo, em um contexto de 200.000 tokens, contra a janela de 1M da entrada tarifada. O quinto, de 14 de outubro, mede o custo de servir o modelo, e não sua qualidade: a Artificial Analysis adicionou o DeepSeek V4.1 Flash ao AA-AgentPerf, seu benchmark de hardware para inferência agêntica, com resultados em aceleradores NVIDIA e AMD — a 100 tokens por segundo por usuário, o GB300 NVL72 da NVIDIA lidera o setor com cerca de 261 milhões de tokens por segundo por megawatt, e as mesmas execuções servem o modelo com apenas dois aceleradores, o que é a seção abaixo em uma segunda moeda. O sexto é o próprio lançamento, substituído: em 17 de outubro, a DeepSeek substituiu o checkpoint por trás do mesmo nome de modelo deepseek-flash pelo DeepSeek-V4.1-Flash-1017 — novos pesos, uma tabela de benchmark do fornecedor que supera o modelo de setembro em todas as linhas que publica, a mesma tabela de preços e o mesmo envelope de 1M de tokens — e, em 18 de outubro, uma medição externa dos novos pesos que contradiz a linha com que o fornecedor abre: a Artificial Analysis pontua o checkpoint 1017 com 45 em seu Intelligence Index e 33,8 no Terminal-Bench 4.0 sob seu próprio harness, contra os 42,3 no cartão da DeepSeek. O sétimo item é a discussão que essa diferença gerou. Em 19 de outubro, uma conta de rastreador com histórico de antecipar esses lançamentos declarou-se “absolutamente certa” de que o 42,3 é real “porque é melhor que o GLM-5.3”, e pediu à Artificial Analysis que executasse o modelo em um harness nativo. O site já havia respondido no dia anterior, com um número oito pontos e meio menor. O oitavo não é uma pontuação: em 20 de outubro, um rastreador da DeepSeek publicou uma transcrição de agente na qual o checkpoint 1017 recusou uma persona em jailbreak com o dsh-purge — um plugin criado para remover as próprias restrições do harness — aplicado, e notas de abliteração de terceiros colocam a taxa de recusa do checkpoint intacto em 97 de 100 prompts nocivos no modo chat e 98 no modo think, sem que a DeepSeek tenha publicado nenhuma avaliação de segurança própria para qualquer um dos checkpoints. O nono não é uma pontuação nem um preço: esta semana, a DeepSeek abriu o motor de inferência no qual seu próprio serviço roda, com uma curva de decodificação para o checkpoint 1017 e os números de produção por trás dela, e a thread que o trouxe à tona esta semana compara essa curva com um benchmark Ascend 950DT de 30 de setembro, que coloca o componente da Huawei cerca de cinco a sete vezes atrás por chip — a seção sobre o silício de serving abaixo. O décimo não é uma pontuação, um preço ou um checkpoint: em 22 de outubro, YuyuantanTan, a conta de atualidades operada pelo China Media Group, informou que a DeepSeek e a MiniMax haviam concluído os procedimentos de registro vinculados ao catálogo preliminar de exportação de tecnologia da China e finalizado o open-sourcing e o licenciamento no exterior. Trata-se de mídia estatal noticiando duas empresas, e não de um aviso de regulador ou de uma declaração da empresa, e é o desenvolvimento que responde à pergunta aberta pelo catálogo preliminar em 16 de outubro — se os pesos sob MIT sobre os quais este texto trata podem continuar sendo publicados e enviados ao exterior. A seção de licença abaixo separa o que o relatório diz do que não diz.

Tudo abaixo mantém separados dois tipos de alegação. As especificações, os benchmarks e os preços vêm do changelog, da ficha do modelo e do relatório técnico da própria DeepSeek — publicados pelo fornecedor, executados pelo fornecedor e não reproduzidos por mais ninguém. Essa lacuna desde então foi reduzida por quatro instrumentos independentes — um índice composto, um painel comunitário de kernels, um benchmark cibernético controlado por harness e um benchmark de serving em hardware —, um dos quais, o índice, já foi executado contra ambos os checkpoints. Nenhum deles replica uma única linha do fornecedor, e o ARC Prize ainda está construindo a avaliação de raciocínio, sem nada publicado por ela até agora. A DeepSeek substituiu o modelo por trás do mesmo nome de API em 17 de outubro pelo checkpoint DeepSeek-V4.1-Flash-1017. Por um dia, isso significou que todos os números externos neste texto descreviam pesos que o fornecedor não servia mais, sem nenhuma pontuação externa para os que ele passou a servir; em 18 de outubro, a Artificial Analysis executou novamente seu índice no novo checkpoint e publicou 45, contra 39 para os pesos de setembro. Os outros três instrumentos não foram reexecutados: o benchmark cibernético, o painel de kernels e o benchmark de hardware ainda descrevem os pesos de setembro, e nenhuma pontuação independente, antiga ou nova, replica uma das linhas de benchmark da própria DeepSeek. O número de custo de serving que o projeto vLLM publicou em 17 de outubro é mais novo apenas na data de publicação: o gráfico por trás dele tem data de 16 de outubro, o dia anterior à troca, portanto descreve os mesmos pesos substituídos. Em seu índice atual (v4.3.2), a Artificial Analysis pontua o checkpoint DeepSeek V4.1 Flash de setembro em 39 e o checkpoint 1017 em 45, descrevendo ambos como bem acima da mediana de 19 para modelos de pesos abertos de tamanho comparável; são números genuínos de terceiros e os primeiros nesta história que a DeepSeek não produziu. Cada um é uma composição de dez avaliações, não uma replicação de qualquer linha individual do fornecedor, e não diz nada sobre a economia de contexto de 1M. Os números de recusa neste texto são um quarto tipo de alegação e são rotulados onde aparecem: eles vêm de pessoas que constroem derivados não censurados desses pesos, não da DeepSeek e não de um laboratório de avaliação, e a DeepSeek não publicou nenhuma avaliação de segurança para nenhum dos checkpoints. Os números de hardware na seção de serving são ainda outra classe: a curva de decodificação da NVIDIA e os números de produção são medições da própria DeepSeek do seu próprio motor, publicadas com o código esta semana, e os pontos da Ascend vêm de uma planilha de benchmark reproduzida em uma thread no X que não está publicada no site de nenhum dos dois fornecedores. Quando um número pertence à DeepSeek, este texto diz isso. Mais uma classe fica fora dessa taxonomia. A reportagem de 22 de outubro de que a DeepSeek e a MiniMax concluíram o registro sob a minuta do catálogo de exportação é mídia estatal — o YuyuantanTan do China Media Group, repetido em veículos financeiros chineses —, não um aviso do Ministério do Comércio, e a DeepSeek não publicou nenhuma declaração confirmando isso. O catálogo em si é uma minuta do governo aberta a comentários até 15 de novembro e é descrito como minuta onde quer que apareça aqui. Os nomes de build associados à reportagem — V4.1F-1017 e M3.1-Flash — vêm de uma única conta no X em 23 de outubro e não aparecem na reportagem da mídia estatal nem nos veículos que a repassaram; o checkpoint que essa publicação nomeia já estava disponível para download havia seis dias quando ela foi escrita.

O checkpoint de 17 de outubro: o que o DeepSeek-V4.1-Flash-1017 mudou

Cinco semanas após o lançamento em torno do qual este artigo foi construído, a DeepSeek substituiu o modelo subjacente. A entrada do changelog datada de 17 de outubro tem três frases: “O DeepSeek V4.1 Flash foi atualizado para o DeepSeek-V4.1-Flash-1017. Os modelos oficiais da web e do APP também foram atualizados para a nova versão. O método de chamada da API e os preços permanecem inalterados — basta usar deepseek-flash para acessar o modelo mais recente.” Tudo nessa citação é o fornecedor falando sobre seu próprio produto, e todas as três afirmações podem ser verificadas nas próprias páginas da DeepSeek, em vez de serem aceitas com base na confiança: a linha de versão do modelo na tabela Models & Pricing agora traz DeepSeek-V4.1-Flash-1017 onde antes trazia DeepSeek-V4.1-Flash, a tabela de tarifas ao lado dela é a mesma divisão entre fora de pico e pico publicada em 10 de setembro — $0.003, $0.15 e $0.60 por 1 milhão de tokens fora de pico, dobrando para $0.006, $0.30 e $1.20 nas janelas de pico dos dias úteis — e o guia de início rápido da API ainda indica deepseek-flash como a string do modelo, com o contexto de 1 milhão de tokens, o teto de saída de 384K e o limite de concorrência de 2.500 requisições inalterados. Os IDs de alias desativados se comportam como a nota de setembro dizia que fariam: deepseek-v4-flash e deepseek-v4-flash-vision-exp ainda são aceitos e agora respondem como DeepSeek-V4.1-Flash-1017 aos preços do Flash. A DeepSeek anunciou a mesma mudança em sua própria conta naquele dia, e vale a pena ler a publicação junto com o changelog porque é mais curta e mais direta: “O DeepSeek-V4.1-Flash-1017 chegou! Desempenho mais forte em benchmarks, conclusão de tarefas mais rápida e saídas mais curtas do que a versão anterior — uma melhoria de Pareto em desempenho e custo. Agora disponível em nosso site, app e API”, seguida dos mesmos três harnesses e da mesma instrução para atualizar para o DeepSeek Harness 0.2.1-rc.1 ou posterior. Tudo nela é o fornecedor descrevendo seu próprio produto em seu próprio canal: “agora disponível em nosso site, app e API” é o “os modelos oficiais da web e do APP também foram atualizados” do changelog reafirmado, e as alegações sobre benchmark, tempo de execução, comprimento da saída e Pareto são as do model card — com uma diferença que importa para qualquer pessoa decidindo se deve experimentá-lo. O card traz um número ao lado de cada linha de benchmark; a publicação não traz nenhum, e nem a publicação nem o changelog atribuem um número à alegação sobre tempo de execução e comprimento da saída. Duas das quatro coisas que a DeepSeek está destacando aqui ainda são afirmações do fornecedor, e não resultados publicados, e o gráfico por trás da linha de Pareto — o anexado à publicação — é da própria DeepSeek, desenhado com suas próprias medições de custo por tarefa.

Os pesos mudaram junto, e essa é a parte que um leitor pode verificar sem confiar em um changelog. Um segundo repositório, deepseek-ai/DeepSeek-V4.1-Flash-1017, foi publicado no Hugging Face nas primeiras horas de 17 de outubro sob a mesma licença MIT: novamente 48 shards safetensors, o mesmo total de cerca de 510 GB, cada shard com o mesmo tamanho do equivalente de setembro e o hash de cada shard diferente. Mesma forma, conteúdos diferentes — que é como “uma atualização menor” deveria parecer vista de fora, e que também significa que as afirmações sobre a arquitetura que este texto vem reportando desde setembro permanecem intactas: o arquivo de configuração que declara o backbone de 552B, os 384 experts roteados, o caminho de prefill com 8B de parâmetros ativos por token e o caminho de decode com 16B é idêntico byte a byte ao do repositório de setembro, portanto o cache KV de 890 bytes por token é o mesmo projeto, e não um novo. O que o novo repositório não traz é a documentação. Não há relatório técnico nele, nem pasta de avaliação, nem template de chat Jinja; o model card diz que a versão não inclui um template de chat e aponta, em vez disso, para uma referência de codificação em Python e um novo toolkit em Rust, deepseek-recipe, para converter requisições no formato Chat Completions, Responses e Anthropic para o formato de prompt do modelo. Quem fixa pesos pelo nome do repositório deve saber que os dois downloads diferem em mais do que seus hashes. A lista de arquivos diz exatamente como: todos os 48 shards têm um checksum diferente e um tamanho em bytes idêntico, enquanto os arquivos que não são pesos — a configuração que declara a arquitetura, a licença e toda a pasta de codificação — são idênticos byte a byte nos dois repositórios. Sete arquivos existem no repositório de setembro e não neste, e nada foi adicionado para substituí-los: o relatório técnico, a pasta de avaliação, o template de chat, as duas figuras que o card costumava incorporar e um .gitignore. O model card também restringe um parâmetro de serving. O card de setembro recomendava top_p de 0,95 ou 1,0; o card de 17 de outubro recomenda 1,0, com temperature em 1,0, uma janela de contexto de 1M e um max_tokens de pelo menos 256K inalterado.

A própria tabela de benchmarks da DeepSeek é onde a atualização deve aparecer, e é uma tabela de fornecedor exatamente do tipo que as linhas de setembro eram: execuções da mesma empresa, não reproduzidas por ninguém, publicadas para um modelo cujos pesos eram públicos havia algumas horas. Em comparação com o checkpoint de setembro, ela está acima em todas as linhas que o cartão traz — HLE sem ferramentas 42,6 contra 36,8, ou 44,0 contra 39,1 no subconjunto somente texto; Terminal-Bench 4.0 42,3 contra 31,2; DeepSWE v1.1 77,0 contra 74,2; ProgramBench 29,1 contra 20,3; NL2Repo-Bench 68,2 contra 65,4; Automation-Bench v1.0.6 60,5 contra 54,8; Agents' Last Exam 35,4 contra 31,8; Apex Bench v1.1 72,1 contra 64,6; Chartography com ferramentas 83,0 contra 78,9; BabyVision com ferramentas 92,5 contra 89,6; e ZeroBench-main com ferramentas 51,0 contra 49,0, em Pass@5. A mesma tabela coloca o 1017 contra os modelos de fronteira com os quais a DeepSeek se compara: agora ele supera o GPT-5.6 Sol no Terminal-Bench 4.0, 42,3 contra 39,9, embora ainda fique atrás do Opus 5 em 51,8, e lidera ambos no DeepSWE v1.1, 77,0 contra 73,0 e 74,0 — uma linha lida do gráfico anexado ao próprio anúncio do fornecedor, e o número mais citado da semana. No NL2Repo-Bench, ele sobe para 68,2 e ainda fica atrás do Opus 5 em 75,3, que é também o formato que a tabela de setembro tinha: mais forte em trabalho agêntico com harness, atrás nas linhas que recompensam profundidade de raciocínio. A linha do Terminal-Bench 4.0 é a que se deve ler duas vezes, porque agora é a única linha dessa tabela com uma contraparte independente. A DeepSeek o executou sob o harness Claude Code; a Artificial Analysis executa as mesmas 66 tarefas sob o mini-swe-agent, e seu resultado de 18 de outubro para esses pesos é 33,8 — oito pontos e meio abaixo dos 42,3 do fornecedor. Na própria tabela da DeepSeek, essa linha supera o GLM-5.3 em 4,4 pontos, 42,3 contra 37,9. No harness da Artificial Analysis, os mesmos pesos ficam atrás do GLM-5.3 em oito, 33,8 contra 41,9.

Uma linha de letra miúda vale mais do que vários desses deltas. A ficha de setembro avaliava o Terminal-Bench 4.0 com o DeepSeek Harness em seu modo Minimal; a ficha 1017 diz que usou o harness Claude Code para o Terminal-Bench 4.0 e o Mini-SWE-V2 para o DeepSWE v1.1. O estudo de harness mais adiante neste texto mediu sete pontos de variação em um modelo ao longo de sete CLIs de agente, então um movimento de onze pontos no Terminal-Bench 4.0 que chega com um harness diferente por baixo não pode ser lido como onze pontos de modelo. A ficha declara qual harness usou, o que torna a linha auditável em vez de apenas impressionante, mas a linha são duas mudanças vestindo um único número. A execução independente as separa, e não a favor do fornecedor. A Artificial Analysis avaliou os mesmos pesos 1017 no Terminal-Bench 4.0 sob o mini-swe-agent — o harness que mantém constante para todos os modelos naquele painel — e obteve 33,8, contra 26,8 do checkpoint de setembro no mesmo harness. Em um harness fixo, o checkpoint vale sete pontos, não onze, e o número de destaque da DeepSeek fica oito pontos e meio acima do que os mesmos pesos pontuam quando o harness é mantido constante entre modelos. O restante do enquadramento da DeepSeek é sobre custo, e não sobre pontuação, e é o mesmo eixo no qual o lançamento de setembro foi vendido: o changelog afirma que a atualização reduz o tempo de execução da tarefa e o comprimento da saída, chama o resultado de “um novo ótimo de Pareto entre desempenho e custo em múltiplos harnesses” e diz que otimizou para DeepSeek Harness, Tencent CodeBuddy e WorkBuddy, recomendando DeepSeek Harness 0.2.1-rc.1 ou posterior. Tempo de execução e comprimento da saída são precisamente as grandezas que as evidências de verbosidade neste texto acompanham de fora, e a DeepSeek agora afirma ter cortado ambos — sem nenhum número anexado. Agora existe uma medição externa do novo checkpoint, e ela não mostra o corte no tempo de execução nem na saída: a execução do índice da Artificial Analysis coloca os pesos 1017 em 288,8 segundos por tarefa contra 289,9 em setembro, e 89.495 tokens de saída por tarefa contra 88.574 — sem variação em ambos, com a economia de custo aparecendo em outro lugar completamente. A publicação que a DeepSeek fez na própria conta no mesmo dia resume tudo isso em “conclusão de tarefas mais rápida e saídas mais curtas” e então chama o par de melhoria de Pareto em desempenho e custo — a alegação do changelog em forma mais curta, da mesma fonte, e igualmente não mensurada. É o fornecedor repetindo a si mesmo, não uma segunda fonte — o que importa, porque o número tirado desse gráfico é o que o mundo exterior passou a semana repetindo. O único artefato no anúncio que de fato traz números é o gráfico anexado à publicação, e ele é o Pass@1 do DeepSWE v1.1 plotado em relação ao custo médio por tarefa sob um harness mini_swe_v2. Vale a pena ler sua legenda antes da linha de Pareto: os dados públicos do ranking por baixo dela estão datados de 22 de setembro no próprio gráfico, três semanas e meia antes do checkpoint que o gráfico está sendo usado para promover, e as linhas de comparação dos modelos da OpenAI são creditadas ao próprio gráfico DeepSWE da OpenAI, e não a uma execução compartilhada. Um ponto nesse gráfico é novo. Tudo contra o que ele é medido foi publicado antes de ele existir.

No mesmo dia da troca, a leitura mais compartilhada dessa tabela veio de alguém com interesse em onde o modelo é executado. Yuchen Jin, que trabalha com sistemas de IA na Databricks, publicou que o DeepSeek-V4.1-Flash-1017 “marca 77 no DeepSWE v1.1”, que tem “desempenho nível Opus 5 com custo 83x menor” e que “vamos lançá-lo na Databricks”. O 77 é a própria linha da DeepSeek, retirada do gráfico anexado ao anúncio do fornecedor, e nada fora da empresa o reproduziu. Os dois pontos de comparação são de Jin e se dividem claramente em um que resiste a uma verificação externa e outro que não. O nível Opus 5 se sustenta: os quadros independentes que publicam o DeepSWE v1.1 colocam o nome deste modelo nessa vizinhança em suas próprias execuções. O leaderboard APEX da Mercor — 113 tarefas originais em 91 repositórios, pontuadas sob o harness mini-swe-agent — lista Opus 5 Max com 71,4% e uma entrada DeepSeek V4.1 Flash Max com 71,7%, e o quadro llm-stats para o mesmo benchmark coloca Claude Opus 5 em 68,8% contra 74,2% para DeepSeek-V4.1-Flash. A leitura honesta do par é mais estreita do que o post sugere: dois quadros que medem este benchmark de forma independente concordam que o modelo é pelo menos equivalente ao Opus 5 nele, e nenhum dos quadros mostra um 77, porque ambos trazem ou o número de setembro ou sua própria execução, e nenhum rotula uma entrada com o checkpoint 1017. O nível Opus 5 é sustentável como afirmação sobre uma vizinhança. O número que deu origem a isso ainda não é repetível.

A metade de 83× do post é aritmética dele, e não um número publicado, e é a metade que se deve tomar com cautela. Nenhum painel traz um custo por tarefa para o checkpoint 1017, e o gráfico do fornecedor por trás da própria alegação de Pareto da DeepSeek plota o custo por tarefa em um eixo logarítmico que vai de dez centavos a vinte dólares — que é o tipo de amplitude que um múltiplo tão grande exige. Apenas com as tarifas de tabela, a diferença é menor que 83×: o Claude Opus 5 cobra US$ 5 por 1 milhão de tokens de entrada e US$ 25 por 1 milhão de saída, contra US$ 0,30 e US$ 1,20 do DeepSeek-V4.1-Flash dentro das janelas de pico em dias de semana, aproximadamente 17× na entrada e 21× na saída, e a resposta muda bastante conforme a proporção de acertos de cache e conforme quantos tokens uma tarefa consome. A direção do argumento de custo não está em disputa, aqui nem em qualquer outro lugar deste texto. O múltiplo específico é uma alegação sobre uma comparação que ninguém publicou.

O Databricks é a parte desse post que o leitor pode conferir na documentação, e a documentação diz mais do que o post. O DeepSeek V4.1 Flash está no Databricks Unity Gateway desde 11 de setembro, o dia seguinte ao lançamento do DeepSeek, com entrada de texto e imagem por meio das Foundation Model APIs da plataforma sob o nome de serviço system.ai.deepseek-v4-1-flash; em 7 de outubro, a plataforma acrescentou para ele pagamento por token com prioridade e throughput provisionado reservado. Ele também é o destino designado da plataforma para esta família: o Databricks agendou a desativação do DeepSeek V4 Pro (0813) para 30 de outubro e do DeepSeek V4 Flash (0731) para 5 de novembro, indicando o DeepSeek V4.1 Flash como o substituto recomendado em ambas as notas. O que nenhuma página do Databricks diz é que o checkpoint de 17 de outubro está chegando. Essa afirmação é de um funcionário falando em nome próprio — um sinal interno sobre intenção, e não uma data já entregue, e a página de modelos suportados ainda traz o modelo sem rótulo de checkpoint. Portanto, a mudança de disponibilidade desta semana é prospectiva, vinda de uma fonte dentro da plataforma e não da própria plataforma; o que um cliente do Databricks pode chamar hoje são os pesos de setembro, e a troca que este texto vem descrevendo — novos pesos por trás do mesmo nome e da mesma tabela de preços — é a forma que essa substituição terá quando acontecer.

O que não mudou é tão importante quanto o que mudou. Três dos quatro instrumentos independentes ainda cobrem os pesos de setembro e apenas eles: a tabela do harness do Exploit Bench, o quadro comunitário de kernels e as execuções de hardware do AA-AgentPerf foram todos produzidos antes da troca, e os dois quadros do DeepSWE v1.1 que levam o nome deste modelo publicam uma entrada sem checkpoint nela. O quarto mudou em 18 de outubro: o Artificial Analysis adicionou uma linha separada para o checkpoint 1017, deu a ele 45 no seu Intelligence Index e 33,8 no Terminal-Bench 4.0, e deixou a linha de setembro intacta em 39 e 26,8. É a primeira vez que um número neste texto foi produzido por alguém que não a DeepSeek com os pesos que a DeepSeek está servindo atualmente. A mudança na API é uma atualização de checkpoint por trás de um nome que a DeepSeek já havia documentado como apontando para o modelo Flash mais recente — o oposto do plano de setembro de fazer o deepseek-v4-pro responder como um modelo diferente, que é a distinção que os desenvolvedores estavam fazendo quando objetaram àquele plano. Para quem chama, o efeito prático é restrito e concreto: pedir por deepseek-flash agora obtém pesos diferentes pelo mesmo preço, com uma tabela melhor divulgada pelo fornecedor por trás deles e, desde 18 de outubro, um terceiro avaliando-os — com pontuação menor na única linha em que ambos existem. No OrcaRouter, o id do modelo e a tabela de preços também estão inalterados — o DeepSeek V4.1 Flash é roteado pelo preço de tabela da própria DeepSeek, com 0% de markup repassado —, que é como deveria parecer, do lado de quem chama, um fornecedor atualizando um modelo sem mudar seu nome ou seu preço.

O que realmente foi lançado em 10 de setembro

A entrada do changelog começa com uma única frase: "Hoje, lançamos oficialmente o modelo DeepSeek-V4.1-Flash." A DeepSeek o descreve como o menor membro de uma nova família de estruturas de modelos, com compreensão visual nativa, e é o primeiro lançamento deste ciclo a chegar acompanhado de um relatório técnico. Do lado da API, trata-se de uma troca de nome, e não de uma migração:

• Nome do modelo — deepseek-flash na API própria da DeepSeek; a URL base, a chave e o formato da requisição permanecem inalterados.

• Descontinuado — DeepSeek V4 Flash e DeepSeek-V4-Flash-Vision-Exp estão offline. Seus IDs antigos ainda são aceitos e agora direcionam para o V4.1 Flash, cobrados pelas tarifas Flash, para que as integrações existentes continuem funcionando sem alteração de código.

• V4 Pro — A DeepSeek anunciou que, a partir das 12h00 do horário de Pequim em 14 de setembro, as solicitações ao deepseek-v4-pro seriam encaminhadas para o V4.1 Flash aos preços do V4.1 Flash até o lançamento de um V4.1 Pro, mas voltou atrás na decisão antes de a data chegar. O V4 Pro continua disponível, com cobrança inalterada, e a DeepSeek afirma que avisará sobre qualquer mudança futura.

Envelope — uma janela de contexto de 1M de tokens, saída máxima de 384K, 2.500 solicitações simultâneas por conta, suporte a entrada de imagens, modo de raciocínio ativado por padrão com opção de desativação.

• Pesos — no mesmo dia, o repositório deepseek-ai/DeepSeek-V4.1-Flash foi publicado no Hugging Face sob a licença MIT: 48 fragmentos safetensors num total de cerca de 510 GB, o relatório técnico em PDF ao lado deles, e uma implementação de inferência de referência numa pasta inference.

Esse último item também é onde a questão do ID de modelo aposentado se encaixa para quem tem deepseek-v4-flash codificado diretamente em um caminho de produção: ele ainda é resolvido, mas o que responde é um modelo diferente. A DeepSeek tem sido explícita de que isso é uma camada de compatibilidade, e não uma promessa, o que faz disso um prazo de migração disfarçado de aviso de descontinuação.

A arquitetura, agora registrada.

Dois dias atrás, esta seção só poderia ter sido uma lista de coisas que ninguém havia publicado. O relatório técnico resolve isso, e a alegação estrutural acaba sendo literal, e não marketing. O DeepSeek V4.1 Flash é um modelo multimodal de mistura de especialistas com 552B de parâmetros, e as partes que são novas são as partes que decidem quanto custa para executar:

• Backbone — 552B de parâmetros no total, mistura de especialistas com um especialista compartilhado e 384 especialistas roteados por camada, seis especialistas roteados ativos por token.

• CED — um transformer de 40 camadas dividido em um codificador causal de 20 camadas e um decodificador de 20 camadas. O cache KV global do decodificador é projetado a partir dos estados ocultos finais do codificador, em vez de ser derivado dos estados ocultos de cada camada do decodificador, que é de onde vem a maior parte da economia de memória.

• Assimetria de ativação — cerca de 8B parâmetros ativos por token durante o prefill e 16B durante a decodificação, portanto ler um prompt longo é substancialmente mais barato do que gerar a partir dele.

• Cache KV — o relatório afirma 890 bytes por token de cache KV global, cerca de um quarto do DeepSeek V4 Flash, usando cache KV principal em FP4 com uma escala por 16 canais, além de reutilização entre camadas.

• Atenção e decodificação — Compressed Sparse Attention 2 com modos Full, Reindex e Reuse e um indexador esparso hierárquico, Single-Pass mHC e decodificação especulativa DSpark.

• Engram — uma tabela de memória condicional de 196B parâmetros, acessada de forma esparsa por meio de uma busca baseada em tokens, que fica ao lado do caminho de mixture-of-experts em vez de dentro da pilha de atenção. É o maior bloco único de pesos do lançamento, e o valor apresentado na ficha do modelo para ele é o que torna o tamanho do download compreensível.

• Visão — DeepSeek-ViT com um projetor MLP de duas camadas, treinado desde o início do pré-treinamento do modelo de linguagem, em vez de ser acoplado a uma base de texto posteriormente.

Treinamento — corpus multimodal de 45T tokens, com atenção esparsa treinada em comprimento de sequência de 64K e contexto estendido para 1M na marca de 34T tokens. O pós-treinamento executa SFT, depois RL e, em seguida, destilação on-policy.

• Esforço de raciocínio — um inteiro continuamente controlável de 1 a 100, um controle mais granular do que os níveis baixo, alto e máximo que o DeepSeek V4 Pro expõe.

O número do KV-cache é o que tem consequências além da ficha técnica, e é onde o design se justifica. Uma janela de contexto de 1M de tokens só é útil se você puder pagar para preenchê-la. A razão pela qual a economia de contexto longo da geração anterior era dolorosa era dupla: o cache global crescia com cada camada que aplicava atenção sobre o prompt, e a maior parte da capacidade de cache persistente estava sendo gasta mantendo estado de janela deslizante que deixava de ser útil em poucos minutos. A resposta do relatório ataca ambos. Se o produto servido corresponde a isso em 1M de tokens sob concorrência real é o tipo de alegação que ainda precisa de terceiros — as pontuações independentes que agora existem medem o modelo, não a economia de contexto longo — mas o mecanismo agora está documentado em vez de inferido, e a seção abaixo o desmonta.

A single-column scoreboard titled 'DeepSeek V4.1 Flash - the scoreboard' listing Backbone 552B MoE, Active params 8B prefill / 16B decode, Context 1M tokens and 384K max output, Price $0.15 in / $0.60 out per 1M off-peak, Weights MIT and downloadable, and Independent score none published yet, with a footer reading 'DeepSeek-reported figures; no third-party benchmark exists yet.'

Dentro do cache: como 890 bytes por token são realmente alcançados

O título do relatório é a tese. Leia-o e a alegação de eficiência deixa de parecer um efeito colateral da espinha dorsal de mistura de especialistas e passa a parecer o briefing de design — que é a leitura com que análises independentes convergiram desde o lançamento. O motivo de isso importar comercialmente, e não academicamente, está em onde a conta de um agente realmente recai: o enquadramento da DeepSeek é que a linha de acerto de cache é a que domina essa conta em cargas de trabalho agênticas longas, o que faz do tamanho do cache uma alavanca de custo de primeira ordem. Os números da DeepSeek colocam o cache global em 890 bytes por token, aproximadamente 437× menor que o DeepSeek V1 original e cerca de um quarto do DeepSeek V4 Flash. Faça as contas para uma janela completa e isso é a diferença entre aproximadamente 890 MB de KV global para uma única sequência de 1 milhão de tokens e cerca de 3,5 GB na taxa por token do V4 Flash. Três mudanças fazem a maior parte da compressão: uma sobre quanto é armazenado, uma sobre o que é lido e uma sobre o que é mantido de fato.

O formato de armazenamento é o mais legível deles. O principal cache global é mantido em FP4 usando o layout E2M1 com uma escala E4M3 por 16 canais — metade da largura do cache FP8 que o DeepSeek V4 armazenava e um quarto do FP16. O que torna isso viável é que o DeepSeek quantizou o cache durante o treinamento, e não no momento de serving, de modo que o ruído introduzido pelo formato mais estreito é algo com que o modelo aprendeu a lidar, em vez de algo imposto a ele depois. Nem tudo foi comprimido dessa forma: o cache local de janela deslizante permanece em FP8, porque o relatório o trata como a parte sensível a um estreitamento adicional.

O Compressed Sparse Attention 2 lida com o que é lido. Cada camada de atenção recebe estaticamente um de três modos — Full, Reindex ou Reuse —, de modo que as camadas do decodificador podem compartilhar o estado de chave e o estado do indexador em vez de cada uma manter o próprio, e a primeira camada em modo Full constrói um pool de candidatos ao qual as camadas de indexação posteriores ficam restritas. Os números do relatório situam esse pool em 16.384 posições, com a seleção esparsa sobre as 512 entradas principais, e é isso que desacopla o custo de indexação do comprimento do contexto: a alegação da DeepSeek é que passar de 4K para 1M de contexto acrescenta apenas cerca de um quarto a mais de computação por token gerado, em vez do crescimento aproximadamente proporcional à janela que o design anterior implicava. Esse único número é a coisa mais útil no relatório para quem tenta precificar uma carga de trabalho de contexto longo, e também é o único sem nenhuma confirmação externa — nenhuma das medições externas neste texto testou a extremidade distante da janela de contexto.

A mudança que faz mais trabalho no lado persistente tem o nome menos promissor. O DeepSeek V4 manteve duas coisas em seu cache persistente por mais de 72 horas em cargas de trabalho típicas: o KV global e o estado de atenção de janela deslizante. O estado de janela deslizante importa por minutos, mas consumia quase metade da capacidade do cache persistente — armazenamento dimensionado para dias, gasto em dados com um minuto de utilidade. O V4.1 Flash retira completamente o estado SWA do cache persistente e o coloca em um pool montado a partir de cerca de 10% da DRAM host de cada máquina, com um tempo de vida em nível de minutos. Quando uma sessão é retomada e esse estado se foi, o SWA Bounded Replay o reconstrói de forma aproximada: em vez de reproduzir camadas × tokens de janela, ele reproduz apenas a janela mais recente, relatada em 128 tokens, e aceita que o estado reconstruído não é matematicamente idêntico a uma reprodução completa. A DeepSeek diz ter observado pouco impacto na qualidade decorrente da aproximação e simulado o mesmo comportamento durante o pós-treinamento. Juntando isso ao cache global mais estreito, o footprint persistente de KV cai para aproximadamente um oitavo do DeepSeek V4 Flash em cargas de trabalho idênticas — um corte maior do que o número de um quarto que lidera a ficha técnica, porque são duas mudanças empilhadas, e não uma mudança de formato.

Dois limites incidem sobre tudo isso. O relatório não oferece comparação de latência ponta a ponta nem de custo, portanto um cache persistente oito vezes menor não é uma carga de trabalho comprovadamente oito vezes mais barata: a compressão alivia a pressão de memória, e apenas a parte da fatura limitada pela memória responde a isso. E a economia não é algo que acontece por si só. Uma engine precisa implementar a projeção codificador-decodificador, os três modos CSA2, o layout de cache FP4 e o Bounded Replay antes que o número signifique algo, razão pela qual 890 bytes devem ser lidos como uma especificação de primeira parte para a própria API servida da DeepSeek, e não como uma promessa sobre uma build local — as conversões quantizadas para llama.cpp, Ollama e LM Studio no repositório não trazem esse cache consigo. A manchete também abrange tokens de texto; embeddings de visão ficam de fora. Em qualquer coisa auto-hospedada, o número em que vale confiar é aquele que você mede. Até onde uma engine pode chegar com isso já não é hipotético, embora ainda não seja independente. O vLLM implementou o corte do lado do decodificador e o Bounded Replay ao longo das três semanas após o lançamento e publicou o antes e o depois na seção de velocidade abaixo — a coisa mais próxima até agora de uma verificação da especificação, e uma feita por uma engine medindo o próprio trabalho, e não por um avaliador medindo o modelo.

A pontuação independente, executada duas vezes: 39 para os pesos de setembro, 45 para 1017

A Artificial Analysis publicou a primeira avaliação externa do DeepSeek V4.1 Flash, e é o número que a beta não conseguia produzir. Na versão atual do Artificial Analysis Intelligence Index (v4.3.2), o modelo obtém 39 no modo Reasoning com esforço máximo. Na mesma escala e com a mesma configuração, o DeepSeek V4 Pro 0813 obtém 36 e o DeepSeek V4 Flash 0731 obtém 34. Lidos em conjunto, esses três resultados dizem aquilo que o marketing da própria DeepSeek afirmou e que os seus benchmarks não conseguiam estabelecer sozinhos: o menor modelo da família é agora o mais forte. A Artificial Analysis descreve 39 como bastante acima da mediana de 19 para modelos de pesos abertos de tamanho comparável. Durante cinco semanas, foi uma pontuação apenas para o checkpoint de setembro: a listagem do avaliador trazia a data de lançamento de setembro e mais nada. Em 18 de outubro, isso mudou, e a mudança é a notícia que este artigo não tinha quando foi publicado pela primeira vez. Surgiu uma segunda linha para o DeepSeek V4.1 Flash 1017, datada de 17 de outubro, com 45 no mesmo índice e no mesmo esforço máximo. Isso coloca os pesos 1017 ao nível do GLM-5.3, com 45, dois pontos abaixo do GPT-5.6 Sol, com 47, e seis abaixo do Claude Opus 5, com 51 — e faz do checkpoint o modelo DeepSeek com maior pontuação que o site já mediu, cinco semanas depois de os pesos de setembro terem conquistado esse título. Também confere ao modelo uma posição que não tinha antes, e que o avaliador declara sem rodeios no seu artigo de 19 de outubro: segundo lugar na tabela de pesos abertos, empatado com o GLM-5.3 e um ponto atrás do MiMo-V2.6-Pro, com 46, com Step 5 Preview e Kimi K3 mais um ponto atrás, com 44. Os seis pontos não estão distribuídos uniformemente pelas dez avaliações. O mesmo artigo relata as maiores subidas nos componentes agênticos e de conhecimento — um Elo GDPval-AA v2.1 de 1.746 contra 1.600, um Elo AA-Briefcase v1.1 de 1.570 contra 1.420, e uma taxa de não alucinação no AA-Omniscience de 33% contra 4%, com a precisão a subir de 43% para 46% e o índice dessa avaliação a passar de -5 para +5. Esses são os números do próprio avaliador para os seus próprios testes, publicados por ele e não reproduzidos aqui, e descrevem um modelo que se tornou bastante menos disposto a inventar uma resposta — uma melhoria diferente da melhoria de velocidade com que o changelog da DeepSeek abre.

A comparação que importa aqui é a interna, porque é a mesma comparação que a tabela de roteamento da DeepSeek faz. O V4.1 Flash carrega 552B de parâmetros totais, com 16B ativos por token; o DeepSeek V4 Pro 0813 carrega cerca de 1,6T no total, com aproximadamente 49B ativos. Um modelo com cerca de um terço do backbone marca três pontos a mais em um composto que seu criador não executou — nove pontos a mais quando os pesos de 1017 são contados, já que o carro-chefe de 1,6T não saiu de 36. A troca entre tamanho e pontuação é toda a tese do design Causal Encoder-Decoder, e um avaliador sem interesse no resultado agora produziu um número consistente com isso.

A parte relativa ao preço da alegação também se sustenta, e esta é a primeira comparação de preços da matéria que não vem de uma tabela de tarifas da DeepSeek. O Artificial Analysis lista o DeepSeek V4.1 Flash a $0,30 por 1 milhão de tokens de entrada e $1,20 por 1 milhão de saída, contra $1,32 e $3,96 para o DeepSeek V4 Pro 0813 — 4,4× mais barato na entrada e 3,3× na saída, com um preço combinado de $0,18 por 1 milhão na mistura 7:2:1 de acertos de cache, entrada e saída do site. Também é mais barato que o modelo mais antigo e menor, DeepSeek V4 Flash 0731, que ele substitui, e que o site lista a $0,44 e $1,32, embora pontue cinco pontos a menos. Mais barato que o modelo que substitui, mais barato que o modelo que desloca e à frente de ambos no índice.

Duas ressalvas acompanham o número. Ele é um composto de dez avaliações executadas com esforço máximo de raciocínio, portanto não diz nada sobre as configurações de esforço menor que a maior parte do tráfego de produção realmente usa, nem sobre como a qualidade se mantém no extremo de uma janela de 1 milhão de tokens. E é a pontuação de um único avaliador: independente, mas não replicada — e o próprio composto foi revisado desde que este artigo o citou pela primeira vez, de v4.3 para v4.3.2, o que moveu a pontuação do DeepSeek V4.1 Flash de 40 para 39 e a de seu antecessor de 35 para 34. O que ele de fato estabelece é estreito e útil — a única afirmação que a beta não conseguia sustentar, a de que um modelo de 552B é genuinamente competitivo com o carro-chefe de 1,6T da própria DeepSeek, agora tem uma fonte fora da DeepSeek. A linha 1017 carrega as mesmas duas ressalvas e mais uma. É a pontuação de um único avaliador, para pesos cinco semanas mais novos do que a maior parte das evidências aqui, e é um único composto, em vez de uma replicação de qualquer linha de fornecedor. Seu preço por tarefa também mudou no site: o checkpoint de setembro está listado hoje a $0.49 por tarefa do Intelligence Index, onde este artigo trazia originalmente $0.27, e o checkpoint 1017, a $0.26. Trate o valor em dólares como um número vivo no painel de outra pessoa, e não como uma constante — que é a mesma lição que a própria pontuação do índice ensinou quando passou de 40 para 39. A tabela de custos ao lado da pontuação é o restante da ressalva, e ela funciona nos dois sentidos. O modelo uma posição acima também custa metade do preço: MiMo-V2.6-Pro alcança 46 a $0.13 por tarefa do Intelligence Index, contra $0.26 aqui, e a própria comparação da Artificial Analysis coloca o GPT-6.1 Sol em esforço médio com 48 por $0.21. O que o checkpoint 1017 de fato vence é o confronto direto que a DeepSeek vem vendendo desde setembro — ele supera o GLM-5.3-Flash nos dois eixos dessa tabela, 45 contra 42 e $0.26 contra $0.28 por tarefa — que é o par em que capacidade e custo se movem na mesma direção.

A próxima pontuação externa: o ARC Prize está construindo o teste

Em 25 de setembro, Matt Mazur, líder de testes de modelos do ARC Prize, abriu um pull request no próprio repositório de benchmarking ARC-AGI-3 da fundação, adicionando um adaptador de provedor DeepSeek de primeira classe: um perfil, chamado deepseek-v4-1-flash-low-provider-adapter, cujo modelo é deepseek-ai/DeepSeek-V4.1-Flash. A alegação de que o ARC Prize pretende avaliar esse modelo chegou como uma única postagem em rede social, então a verificamos no próprio código da fundação, e não na postagem. O adaptador, o perfil, seus testes unitários e sua documentação estão no diff, e o repositório é o harness que a política de testes do ARC Prize indica para seu benchmark agêntico interativo. O que não existe é um resultado: o pull request está aberto e não mesclado, não há pontuação, nem data de publicação, nem declaração de quais níveis de raciocínio serão publicados. O que importa é a forma da medição, e não a notícia de que uma está por vir. O ARC-AGI faz uma pergunta que os outros rankings não fazem: um modelo pode ser rápido, barato e forte dentro de um harness e ainda assim pontuar na casa dos sessenta em tarefas que não viu. Essa é a pergunta que ninguém ainda fez ao DeepSeek V4.1 Flash.

O perfil define como uma execução dessas funcionaria, e três detalhes moldarão o número que acabará saindo. Ele executa o modelo na configuração de baixo esforço de raciocínio, em vez de no máximo, transmite respostas em streaming, define um contexto de harness de 1M de tokens com um gatilho de compactação por resumo em 175.000 tokens e limita a saída a 262.144 tokens. Ele encaminha pelo endpoint compatível com OpenAI da Baseten, em vez do próprio da DeepSeek, e está configurado a $0,30 por 1M de tokens de entrada e $1,20 por 1M de saída — tarifas de pico da tabela da DeepSeek, não os valores fora de pico citados mais adiante neste texto. A ARC Prize calcula o custo por tarefa a partir dos preços configurados no perfil, então o valor final será de tarifa de pico, o que vale lembrar antes de compará-lo com os $0,042 por tarefa que o DeepSeek V4 Flash 0731 registrou quando foi testado. A outra característica incomum é um contorno para o comportamento do modo de pensamento da DeepSeek: o conteúdo histórico de raciocínio só é reproduzido quando uma requisição inclui ferramentas, então o adaptador faz o modelo emitir cada ação ARC como uma chamada de ferramenta submit_action e reproduz a mensagem exata do assistente com seu raciocínio anexado, em vez de extrair ações de texto corrido.

A régua pela qual isto será medido vem do próprio ranking da ARC Prize. O DeepSeek V4 Flash 0731, o checkpoint que o V4.1 Flash aposenta, é o registro verificado do ranking para a categoria Flash de onde vem: 61,4% no ARC-AGI-2 com esforço máximo de raciocínio e 89,0% no ARC-AGI-1, a US$ 0,042 e US$ 0,021 por tarefa. O Dots3-Note Preview está em 76,8% no ARC-AGI-2, que corresponde aos 77% que a publicação que sinalizou o adaptador está apontando, e a expectativa da mesma conta — de que qualquer coisa abaixo de 80% de um sucessor muito maior e nativamente multimodal seria decepcionante — é o enquadramento dele, e não uma meta publicada. A parte restante desse enquadramento merece um rótulo: a alegação de que o V4.1 Flash gera 29% mais tokens do que o modelo que substitui não tem atribuição nem definição, e nada que a DeepSeek ou a ARC Prize tenham publicado diz o que isso mede.

Uma ressalva sobre de qual placar se trata. O adaptador foi integrado ao repositório ARC-AGI-3, o harness do benchmark agêntico interativo da fundação, e o repositório separado que executa o ARC-AGI-1 e o ARC-AGI-2 não traz nenhuma entrada do V4.1 — sua lista de modelos não foi atualizada desde 27 de julho e ainda nomeia endpoints mais antigos da DeepSeek. Portanto, o fato datável é que o ARC Prize conectou esse modelo ao seu harness agêntico; se ele também aparecerá no placar do ARC-AGI-2, onde está a comparação de 61,4%, não é algo que o código público mostre hoje. A leitura prática para quem está escolhendo um modelo ficou mais ampla. Quatro instrumentos independentes sobre o DeepSeek V4.1 Flash estão agora em jogo — um índice composto que foi executado duas vezes, uma por checkpoint; um placar comunitário de kernels; um benchmark cibernético controlado por harness; e, desde 14 de outubro, um benchmark de serving em hardware — e dois deles colocam o modelo dentro de um harness em tarefas que ele não viu. O mais novo dos dois é o composto, que inclui o Terminal-Bench 4.0 desde o índice v4.3: 66 tarefas de terminal, pass@1 com média sobre três repetições, todo modelo sob o mesmo harness de agente. Seu resultado de 18 de outubro para os pesos 1017 é 33,8. O benchmark cibernético, abaixo, é o mais próximo que qualquer um deles chega, e nele este modelo perde o único confronto direto que disputa. O perfil ARC é a avaliação criada para responder à pergunta de raciocínio, e continua sendo a única sem um número. Até que ela rode, o teto de raciocínio do modelo permanece não medido, e o número com o qual compará-lo é o do seu predecessor.

A primeira pontuação externa de cibersegurança: a estrutura de teste influencia mais o número do que o modelo

Em 28 de setembro, o laboratório de avaliação Generality Labs publicou um follow-up de seu trabalho anterior sobre cibersegurança, intitulado “O harness faz diferença ao executar Cyber Benchmarks?” — a primeira medição externa concluída que coloca o DeepSeek V4.1 Flash ao lado de outro modelo de pesos abertos no mesmo benchmark de cibersegurança. O benchmark é o Exploit Bench, uma avaliação da Carnegie Mellon feita por Seunghyun Lee e pelo Prof. David Brumley, que pontua até onde um agente sobe uma escada de dezesseis capacidades — desde alcançar código vulnerável, acionar o bug, construir primitivas de exploit, até execução de código arbitrário — contra o V8 de produção com a sandbox de segurança do V8 habilitada. O laboratório testou dois modelos, DeepSeek V4.1 Flash e GLM-5.3-Flash da Z.ai, com um orçamento de 250 milhões de tokens por tarefa ao longo de 10 tarefas extraídas das 41 originais do benchmark por Teoria de Resposta ao Item, e repetiu cada modelo sob sete configurações de harness: seis CLIs de agente — Claude Code, Codex, Kimi CLI, ReAct, Gemini CLI e OpenCode — mais o padrão do próprio benchmark, que o relatório chama de Original. O Original não é de modo algum um CLI de terceiros: não tem limite de tokens, tem um teto de 300 turnos e nenhuma compactação de contexto. A conta que sinalizou esse resultado descreve o Original como basicamente um loop while em Python; essa é a caracterização dele, não a dos pesquisadores, cuja própria descrição é a apresentada acima.

O resultado é um leque de pontuações que nenhuma pontuação isolada teria mostrado. A capacidade média é numa escala de 16. O DeepSeek V4.1 Flash tem seu melhor desempenho no Claude Code, 9,3, com o Codex em segundo, com 8,9; o mesmo modelo cai para 7,4 no Kimi CLI, 5,9 no OpenCode, 5,7 no Gemini CLI, 5,3 no ReAct e 4,7 no Original — o padrão do próprio benchmark, e o pior dos sete. O GLM-5.3-Flash inverte esse ranking nas duas pontas. Sua melhor configuração é o Codex, com 10,6, acima do 10,02 que o próprio conjunto de dados do estudo apresenta para o Mythos Preview no conjunto completo de 41 tarefas, embora os pesquisadores alertem que um subconjunto de 10 amostras não é totalmente representativo; seu pior é o Claude Code, com 6,2, o mesmo ambiente de avaliação que é o melhor do DeepSeek V4.1 Flash, e 8,9 no Gemini CLI, 8,2 no Kimi CLI, 8,1 no OpenCode, 7,7 no ReAct e 6,4 no Original. Na média dos sete, o GLM-5.3-Flash fica perto de 8,0 e o DeepSeek V4.1 Flash perto de 6,7. Portanto, as duas metades da afirmação que circulou com este resultado se confirmam nos dados divulgados: a escolha do ambiente de avaliação vale vários pontos e, neste benchmark, o DeepSeek V4.1 Flash é o mais fraco dos dois modelos — exceto no Claude Code, onde lidera por mais de três.

Os pesquisadores são explícitos ao afirmar que não conseguem explicar totalmente a dispersão. Sua única pista positiva é como cada harness compacta o contexto, e a diferença é uma questão de formulação. O prompt de compactação do ReAct pede ao modelo que “Escreva um resumo de continuação que permita a você (ou a outra instância de você mesmo) retomar o trabalho”; nas transcrições que o laboratório publicou, isso às vezes leva o modelo a declarar o trabalho concluído, depois disso o harness o desperta novamente e ele reenvia o mesmo relatório dezenas de vezes até o orçamento acabar. O Codex formula o mesmo momento como “Crie um resumo de transferência para outro LLM que retomará a tarefa”, e o laboratório levanta a hipótese de que dirigir-se a um agente diferente é o que mantém o modelo progredindo ao longo de longos orçamentos. Eles chamam isso de hipótese, não de causa. Um erro de configuração também importa para a leitura da tabela: a compactação do ReAct foi definida para 100K tokens em vez do gatilho pretendido, então ele compactou com muito mais frequência do que o design exigia, o que puxa para baixo as linhas de ReAct de ambos os modelos. As próprias ressalvas do estudo devem acompanhar qualquer número dele — dois modelos, 10 amostras por configuração de harness, 70 amostras de perguntas por modelo em comparação com as 41 tarefas originais do benchmark, e três amostras que deram erro ou nunca terminaram, duas delas do GLM-5.3-Flash. Os autores afirmam que a amostra pequena é inerentemente ruidosa, que não se deve presumir que o resultado se estenda a outros domínios e tarefas, e que trabalho anterior do METR não encontrou diferença estatisticamente significativa entre harnesses em tarefas de horizonte longo. É um laboratório externo executando o benchmark de outra pessoa, não os donos do benchmark, e não passou por revisão por pares. O que ele não é: um número de fornecedor, e é o primeiro número externo neste artigo que contradiz a própria narrativa do fornecedor em vez de apenas deixar de confirmá-la.

Há uma coisa aqui sobre a qual um roteador pode agir e uma sobre a qual não pode. Ele não pode escolher seu harness — esse é o loop de agente que você já executa, e o ponto central deste estudo é que a escolha é determinante. O que ele pode fazer é tornar a metade do modelo desse par uma mudança de uma linha. DeepSeek V4.1 Flash e GLM-5.3-Flash são ambos roteáveis através do OrcaRouter em uma única chave compatível com OpenAI, pelo preço de tabela do próprio provedor com 0% de markup adicionado, de modo que uma equipe que queira encontrar sua própria combinação de modelo e harness pode trocar o modelo por baixo de um harness fixo sem um segundo contrato ou uma segunda integração, e deixar um modelo comprovado por trás dele como failover automático se a troca se revelar uma regressão. Esse é o mesmo argumento que a seção de adoção faz abaixo, aplicado a uma decisão que o estudo de harness acabou de tornar concreta: com base nessas evidências, o harness que você executa pode importar mais do que o modelo que você escolhe, e o lado do modelo desse par é o lado que você pode mudar em uma tarde.

Onde ele se situa em relação à fronteira, e onde ainda perde.

A ficha do modelo de setembro compara o V4.1 Flash com Opus-5.0, GPT-5.6 Sol, Kimi K3 e GLM-5.3 com esforço máximo de raciocínio, tendo seu próprio DeepSeek V4 Pro e DeepSeek V4 Flash como baselines internos. Todos os números abaixo são informados pelo fornecedor, executados nos harnesses da DeepSeek e não foram reproduzidos por nenhum terceiro. A ficha observa que os resultados agênticos usam o modo Minimal do DeepSeek Harness com contexto de 1M tokens para benchmarks de código e janela de 512K para os visuais, portanto não são diretamente comparáveis a números de terceiros publicados nos mesmos benchmarks. As pontuações independentes nas seções acima são medições diferentes em conjuntos distintos de avaliações; elas sustentam o panorama geral e não corroboram nenhuma linha individual abaixo, e as linhas de 17 de outubro na seção acima vêm de uma ficha diferente e de uma execução diferente dos mesmos benchmarks.

No trabalho agêntico e de codificação, os números do fornecedor colocam o V4.1 Flash acima dos modelos de fronteira que ele nomeia:

• Terminal-Bench 2.1 — 90,6, contra 89,1 para Opus-5.0, 88,8 para GPT-5.6 Sol e 87,9 para DeepSeek V4 Pro

• DeepSWE v1.1 — 74.2 resolvido, contra 74.0, 73.0 e 62.7

• CyberGym — 88.1, contra 84.5 tanto para GPT-5.6 Sol quanto para GLM-5.3, e 83.3 para DeepSeek V4 Pro

• AutomationBench — 54,8, contra 50,3 para Opus-5.0 e 37,7 para DeepSeek V4 Flash

• Último Exame do Agente — 31.8, contra 28.6 e 25.7

• Codeforces — uma classificação de 3.471, à frente do DeepSeek V4 Pro com 3.348 e do DeepSeek V4 Flash com 3.289

• MathArena Apex — 65.6, no mesmo nível do Kimi K3 e à frente do DeepSeek V4 Pro, com 65.3

E nas suítes agênticas mais difíceis, não:

• Terminal-Bench 3.0 — 30.0, bem atrás do Opus-5.0 com 43.3 e do GPT-5.6 Sol com 34.4, embora muito à frente do DeepSeek V4 Pro com 11.8

• Terminal-Bench 4.0 — 31.2, contra 51.8 e 39.9, e novamente à frente do DeepSeek V4 Pro em 12.4

• ProgramBench — 20,3, contra 37,0 do Opus-5.0

• NL2Repo-Bench — 64.0, contra 75.3 do Opus-5.0

• HLE — 36.8, contra 56.3 e 44.5

• ExploitGym — 15,3, contra 33,7 e 22,1

O formato dessa lista é mais informativo do que qualquer linha individual. O V4.1 Flash supera a fronteira em benchmarks que recompensam o uso sustentado de ferramentas dentro de um harness, e perde naqueles que recompensam a profundidade de raciocínio — o padrão que se esperaria de um modelo projetado em torno de throughput e economia de contexto, e não de um teto bruto de raciocínio. A comparação interna é a mais impressionante: ele supera o DeepSeek V4 Pro em praticamente todas as linhas, incluindo as linhas em que ambos perdem para o Opus-5.0. A DeepSeek não está afirmando que seu modelo mais barato é o melhor modelo do mercado. Está afirmando que seu modelo mais barato é o melhor modelo que a DeepSeek produz, uma afirmação que sua própria tabela de roteamento corrobora.

Quanto custa, e como a comparação com o Pro realmente se parece

A tabela de preços de 10 de setembro agora é simplesmente a tabela do V4.1 Flash, publicada na página Modelos e Preços da DeepSeek, com divisão entre horário de pico e fora de pico:

• Entrada, cache hit — US$ 0,003 por 1M de tokens fora do horário de pico, US$ 0,006 no horário de pico.

• Entrada, cache miss — US$ 0,15 por 1M de tokens fora do horário de pico, US$ 0,30 no horário de pico

• Saída — $0.60 por 1M tokens fora de pico, $1.20 no pico

Janelas de pico — 01:00–04:00 e 06:00–10:00 UTC, de segunda a sexta-feira; as demais horas são cobradas à metade da tarifa de pico.

• Em renminbi — ¥0,02, ¥1 e ¥4 fora de pico, dobrando para ¥0,04, ¥2 e ¥8 no pico.

Compare isso com o modelo que ele está substituindo. O DeepSeek V4 Pro cobra US$ 0,022 por 1M de entrada com acerto no cache, US$ 0,66 de entrada sem acerto no cache e US$ 1,98 de saída fora do horário de pico — cerca de 4,4× na entrada sem acerto no cache e 3,3× na saída. Esses são os números que o redirecionamento de 14 de setembro teria aplicado a cada chamada de deepseek-v4-pro, e é por isso que o plano era uma questão de preço tanto quanto de capacidade, e ainda são o motivo pelo qual a comparação importa: a DeepSeek retirou o redirecionamento, não a tabela de preços. A Artificial Analysis chega à mesma aritmética a partir de suas próprias listagens — US$ 0,30 e US$ 1,20 por 1M para o V4.1 Flash, contra US$ 1,32 e US$ 3,96 para o DeepSeek V4 Pro 0813, os mesmos 4,4× e 3,3×, e um valor combinado de US$ 0,18 por 1M na mistura 7:2:1 do site de acerto no cache, entrada e saída. A tabela também cobra menos que o DeepSeek V4 Flash 0731, o modelo que ela aposenta, que o mesmo site lista a US$ 0,44 e US$ 1,32.

O preço por token não é o custo por tarefa, e o beta é a prova disso. Testadores do primeiro dia relataram que sessões de cinco minutos drenavam o saldo mais rápido no novo modelo do que o mesmo tempo de relógio no DeepSeek V4 Flash, porque o modelo é feito para emitir tokens rapidamente e a conta escala com tokens, não com minutos. Um cartão que custa um quarto do preço do Pro é uma pechincha se uma tarefa termina em tokens comparáveis; fica elas por elas se o modelo pensa por mais tempo para chegar lá.

Onde existe um número externo sobre essa questão, ele aponta para os dois lados. O Artificial Analysis situa o DeepSeek V4.1 Flash em US$ 0,27 por tarefa do Intelligence Index em seu próprio conjunto de avaliação — um número real por tarefa, produzido fora da DeepSeek, e baixo. Mas a mesma execução gerou 250 milhões de tokens de saída, contra uma mediana de 140 milhões para modelos comparáveis, e o resumo do site chama o modelo de muito verboso no mesmo fôlego em que o chama de rápido. A verbosidade é gratuita dentro de um ambiente de benchmark e cara em produção, que é exatamente o mecanismo que os testadores beta estavam descrevendo quando relataram saldos sendo drenados mais rápido em termos de tempo real. O estado honesto da questão por tarefa é que um avaliador independente agora mediu as duas metades dela, em seu próprio conjunto de avaliação, e a resposta ainda depende do que você está executando. O índice composto não consegue mostrar para onde vai a saída extra, e os testadores beta também nunca disseram. Os primeiros relatos práticos fazem isso, e estão na seção de velocidade abaixo: o modelo é verboso porque está verificando. A atualização de 17 de outubro é a primeira vez que a DeepSeek afirma ter alterado esse número: o changelog diz que o novo checkpoint “reduz o tempo de execução da tarefa e o comprimento da saída”, e a postagem algumas horas depois diz a mesma coisa em menos palavras — “conclusão mais rápida da tarefa e saídas mais curtas”. Isso é a DeepSeek abordando, por sua própria autoridade, exatamente a quantidade sobre a qual a medição externa se queixou, sem nenhum número associado a nenhuma das duas afirmações. A primeira análise externa sobre isso, em 18 de outubro, constatou o volume agregado em queda — 210 milhões de tokens de saída no índice, contra 250 milhões em setembro — e o número por tarefa estável, em 89.495 tokens contra 88.574.

A screenshot of the DeepSeek API docs Models & Pricing page (captured September 10, 2026) showing deepseek-flash, versioned DeepSeek-V4.1-Flash, alongside deepseek-v4-pro, both at 1M context and 384K max output with vision supported on Flash only, the off-peak and peak price columns ($0.003/$0.006 cache-hit, $0.15/$0.30 cache-miss, $0.60/$1.20 output for deepseek-flash), concurrency limits of 2,500 and 500, and footnotes confirming the legacy v4-flash names are retired and served by V4.1 Flash and that deepseek-v4-pro requests route to V4.1 Flash from September 14, 2026.

Quanto custa por mês: uma franquia de US$ 80, depois um nível gratuito

O cartão acima responde quanto custa um token. Um número diferente mudou de lugar duas vezes, e nas duas veio da OpenCode — o agente de programação cuja assinatura Go precifica o acesso a este modelo como uma franquia de uso mensal, e não como tokens medidos — falando sobre a sua própria assinatura, e não sobre o modelo. Em 25 de setembro, a conta da plataforma publicou: “Operação Cheepseek Fase 2: $60 de uso para o DeepSeek v4.1 Flash agora é permanente.” Em 12 de outubro, publicou a sequência no mesmo formato — “Operação Cheepseek Fase 3: $80 de uso para o DeepSeek V4.1 Flash” — e a sua página de preços indicava $80 para este modelo, onde em finais de setembro indicava $60. Essa leitura foi feita uma segunda vez em 13 de outubro, na mesma página, e devolveu a mesma linha: $80 no plano Go de $10 por mês, $160 no Go Plus. O número, portanto, não é a alegação de uma publicação sobre si mesma; é o preço publicado por uma plataforma para disponibilizar este modelo, e continuava lá um dia depois. Lidas em conjunto, as duas publicações dizem o que “permanente” acabou por significar: sem data de expiração — e um número mais alto três semanas depois. O que essa mudança não é é uma nova forma de chegar ao modelo — isso chega três dias depois, no parágrafo abaixo. O DeepSeek V4.1 Flash responde na própria API da DeepSeek desde 10 de setembro e a OrcaRouter disponibiliza-o às próprias tarifas da DeepSeek desde o lançamento, pelo que os pesos, a arquitetura e todas as linhas de benchmark neste artigo ficam intocados por uma reprecificação de assinatura; o que outubro mudou foi quem está disposto a disponibilizar o modelo e em que termos.

A entrada gratuita é um tipo diferente de mudança em relação a qualquer uma dessas duas, e é a única das três que muda o que um leitor pode fazer esta semana. Em 15 de outubro, a OpenCode adicionou uma entrada separada para este modelo — DeepSeek V4.1 Flash Free, id de modelo deepseek-v4.1-flash-free — servida sem custo. A lista pública de modelos da plataforma a devolve ao lado do id tarifado, a documentação do Console traz uma entrada de modelos gratuitos que a descreve como gratuita por tempo limitado e seu provedor como seguindo uma política de retenção zero, que não treina com os dados, e sua tabela de preços publicada coloca entrada, saída e leituras em cache como Free. O que ela não é é o produto completo. Os limites catalogados da entrada gratuita — adicionados ao models.dev, o catálogo do qual a própria lista de modelos da OpenCode é extraída, em 15 de outubro — nomeiam a entrada tarifada como modelo base e limitam a janela a 200.000 tokens, com um teto de saída de 32.000 tokens, contra o contexto de 1M e a saída máxima de 384K que a entrada tarifada deepseek-v4.1-flash apresenta. São os mesmos pesos por trás de termos de serviço mais restritos, e não um modelo menor ou destilado, e o teto de saída é a cláusula que morde primeiro no trabalho agêntico, em que uma única edição de arquivo pode ultrapassá-lo. A plataforma não atribui data de término ao arranjo nem publica tabela de preços para ele, porque não há preço. Nada disso veio da DeepSeek: é a decisão comercial de uma plataforma sobre um modelo que ela não possui, declarada em sua própria lista de modelos, sua própria documentação e sua própria tabela de preços, e é a única fonte de tudo isso — não encontramos nenhuma medição independente de como o endpoint gratuito se comporta sob carga, e “tempo limitado” é uma expressão da plataforma, não um cronograma. Leia isso como a maneira mais barata de colocar uma janela de 200.000 tokens diante deste modelo hoje, e não como uma mudança no que o modelo é.

Os mecanismos vêm dessa página de preços, lida em 12 de outubro e relida em 13 de outubro. O Go é uma assinatura de $10 por mês, e sua tabela associa cada modelo nela a uma contagem estimada de solicitações por cinco horas e a um limite de uso mensal, em colunas separadas para os dois níveis. O DeepSeek V4.1 Flash tem a maior cota da página: $80 por mês e 34.670 solicitações estimadas por cinco horas no Go, dobrando para $160 e 69.330 no Go Plus. As linhas cobram o modelo pela própria tabela da DeepSeek — $0,15 por 1M de tokens de entrada, $0,60 de saída e $0,003 por uma leitura em cache fora do horário de pico, dobrando para $0,30, $1,20 e $0,006 dentro das janelas de pico em dias úteis — e esses são os números do fornecedor, inalterados desde a leitura de setembro que esta seção já trazia. Duas coisas que a página mostrava então não estão nela hoje, e ambas merecem ser destacadas porque a leitura anterior dependia delas: a regra de consumo em três faixas — 20% em quaisquer cinco horas, 50% ao longo de uma semana e 100% ao longo de um mês — não aparece mais, e o URL da documentação de onde as estimativas de solicitações foram originalmente lidas, opencode.ai/docs/go, retornou 404 quando verificamos. As contagens de solicitações acima são a aritmética da plataforma sobre um formato de chamada que ela não publica, não são nossas.

A mudança é verificável na página, e o fato de agora já ter havido mais de uma também é. No final de setembro, as mesmas linhas traziam $60 sem expiração associada, depois de um subsídio promocional de $15 ter sido multiplicado por quatro, chegando a $60, e trazia 20 de setembro como a data em que o multiplicador deixaria de valer; as estimativas de requisições foram publicadas em duas colunas, 6.500 / 16.250 / 32.500 no padrão, contra 26.000 / 65.000 / 130.000 com o multiplicador aplicado. As linhas traziam $80 nas duas leituras, e as estimativas publicadas para este modelo são 34.670 por cinco horas e 69.330 por mês — um subsídio em dólares maior ao lado de uma contagem mensal de requisições menor do que o conjunto ampliado de setembro, e as duas coisas não podem descrever o mesmo formato de chamada pressuposto. A página não informa nenhum mix de tokens e não oferece explicação, portanto a diferença é um fato sobre as duas leituras, e não algo que possamos resolver de fora. As tarifas em si nunca foram um desconto na tabela de preços da DeepSeek — o preço por token sempre foi o da fornecedora, e continua sendo. O que um subsídio não faz é dizer nada sobre qualidade: é o julgamento de uma plataforma de que consegue suportar o tráfego deste modelo a essas tarifas sem prazo, o que é evidência sobre o ecossistema de serviço, e não sobre o modelo.

A distinção importa quando você está escolhendo, porque um teto fixo e um medidor de repasse são produtos diferentes. O DeepSeek V4.1 Flash está no OrcaRouter com a própria tarifa da DeepSeek e 0% de markup — US$ 0,15 por 1M de entrada e US$ 0,60 por 1M de saída fora de pico, os mesmos números listados no cartão acima, sem nada empacotado em volta deles: nenhuma assinatura para comprar e nenhuma franquia mensal para esgotar. Um teto de US$ 80 sobre um preço mensal fixo é o formato certo para um desenvolvedor executando um agente o dia todo, em que a questão é quanto custa o mês — e um teto já elevado uma vez, em um terço, também é um lembrete de que o valor é uma decisão comercial, e não uma propriedade do modelo. Um nível gratuito com uma janela de 200.000 tokens é o formato certo para experimentar o modelo esta semana e o formato errado para as bases de código que precisam da janela completa, que é a única coisa que os dois níveis do mesmo modelo não compartilham. Uma tarifa de fornecedor repassada sem alteração é o formato certo para um serviço, em que a questão é quanto custa cada chamada e se o próximo movimento de preço do provedor chega até você no dia em que acontece. Ambos respondem quanto custa este modelo; eles respondem isso para perfis de gasto diferentes.

Velocidade: os números da beta, a alegação do fabricante e o antes e depois do próprio motor

Quando a beta foi lançada, a taxa de transferência era o destaque. Desenvolvedores relataram cerca de 420 tokens de saída por segundo em gerações longas, com picos acima de 500, e uma execução amplamente compartilhada produziu mais de 71.000 tokens em menos de três minutos. Essas continuam sendo medições da comunidade feitas sob condições não controladas, e ainda devem ser interpretadas assim — mas o mecanismo por trás delas agora está documentado, em vez de ser apenas suposto. Um cache KV de 890 bytes por token e um caminho de decodificação que ativa 16B parâmetros são um design feito para taxa de transferência, então a arquitetura é ao menos o formato certo para produzir números como esses. O quão grandes eles realmente são é o problema do próximo parágrafo, e a resposta é menor.

A própria alegação da DeepSeek, no registro de alterações, é que o V4.1 Flash “superou de forma abrangente o V4 Pro em desempenho, custo, velocidade e tempo total”. A palavra que faz o trabalho ali é tempo total: é o fornecedor enquadrando a velocidade como conclusão de tarefa, e não como tokens por segundo, que é a métrica que sobrevive ao contato com um loop de agente real que escreve um arquivo, lê o erro e tenta de novo. A Artificial Analysis agora atribui um número medido à afirmação mais antiga: 185 tokens de saída por segundo para o DeepSeek V4.1 Flash, contra 175 para o DeepSeek V4 Flash 0731. Esse é um número real de terceiros e é aproximadamente metade dos 420 tokens por segundo relatados pelos desenvolvedores durante o beta, e é por isso que os números do beta devem ficar onde pertencem — na coluna de condições não controladas.

Em 7 de outubro, o projeto vLLM publicou seu balanço das três semanas desde o lançamento, e é o primeiro número de velocidade medido neste texto que não é nem um contador de tokens nem um slogan de fornecedor. Escrevendo como Inferact e a Equipe vLLM, o projeto relata que o DeepSeek V4.1 Flash em sua build atual roda 1,9× mais rápido que sua própria implementação do dia zero em baixa concorrência e entrega 5,3× a vazão sob uma restrição de 150 TPS — o número que seu resumo traz, contra “cerca de 5×” no corpo da mesma postagem. Ambos são medidos no benchmark de serving agêntico SemiAnalysis AgentX, com TP4 e atenção FlashInfer por trás do número de baixa latência e DEP2 com atenção paralela por dados por trás do número de vazão, em hardware NVIDIA GB200 e GB300. Vale manter três coisas claras sobre esse resultado. Ele compara vLLM com vLLM: a linha de base é a receita do dia zero do próprio projeto, não outro engine e não outro modelo, então o número diz o quanto a pilha de serving melhorou, e não como este modelo se compara a qualquer outra coisa. É o relato do próprio runtime sobre seu próprio trabalho, e nenhum terceiro o reproduziu. E o maior ganho isolado vem do runtime, não dos pesos — o replay limitado do SWA, que reexecuta apenas os últimos 128 tokens de uma janela deslizante em vez de repetir essa janela em todas as camadas, agora vem ativado por padrão para este modelo por trás de uma única flag. O projeto relata cerca de 30% de redução no tempo até o primeiro token com replay mais captura de CUDA graph, um corte de 30–40% na computação de prefill com o ajuste do lado do decoder, e quase 70% de redução no TTFT com cerca de 100K de vazão quando três otimizações se acumulam. Também relata onde o replay prejudica: sem CUDA graphs, ele é mais lento que a linha de base em prompts curtos, até 12% pior em 1K tokens, porque o overhead de lançamento supera o trabalho economizado. A acurácia foi verificada no GSM8K e no GPQA sem diferença significativa relatada, com lacunas dentro de cerca de 1,5 erros-padrão — o número a ser contraposto à própria afirmação do relatório de que o replay limitado é aproximado, não exato. O projeto acrescenta que o modelo não precisou de offloading de KV-cache em nenhum ponto do benchmark e espera que o offloading comece a compensar apenas em concorrência mais alta, com prefill e decode divididos entre máquinas. Esta é uma medição diferente do placar de kernels abaixo, que pontua os kernels que o modelo escreve; os números da vLLM são sobre quanto custa servir o modelo depois que um engine implementou sua arquitetura, e o engine aqui é o que está relatando. O projeto publicou novamente em 17 de outubro, o dia em que a DeepSeek trocou o checkpoint, e o número com que abriu era um tipo diferente de cifra: 1,3 bilhão de tokens por dólar de custo total de propriedade no SemiAnalysis AgentX, a 830.000 tokens por segundo por GPU, contando tokens em cache, de entrada e de saída juntos, enquanto mantém 100 tokens de saída por segundo para cada usuário. Esse é um resultado de custo de serving, e não um delta de velocidade, e a seção de custo de serving abaixo o examina por completo. Três coisas sobre ele dizem respeito a este parágrafo: é o mesmo projeto, o mesmo modelo e o mesmo benchmark três semanas depois do balanço de 7 de outubro; o projeto enquadra esse balanço como capítulo um, a 5x a vazão agêntica do dia zero, com um próximo capítulo ainda por vir, e nenhuma segunda postagem da DeepSeek apareceu em seu blog desde então; e uma curva de custo ainda é o lado do runtime no balanço, não um veredito externo sobre o modelo. Essa distinção também explica por que esse número importa para alguém que nunca vai executar um nó. Nada desse trabalho é trabalho que quem chama faz: uma pilha de serving que fica 1,9× mais rápida em baixa concorrência torna mais rápidas as requisições que ela atende, e acessar este modelo por uma API é como a maioria das equipes se beneficiará disso sem possuir o hardware. O DeepSeek V4.1 Flash está no OrcaRouter na tarifa da própria DeepSeek com 0% de acréscimo, na mesma chave compatível com OpenAI do restante da linha, com um modelo comprovado por trás como failover automático — o modelo e o preço se movem no ritmo do provedor, e a escolha do engine fica do lado do provedor.

Quanto custa servir: os primeiros números independentes de hardware

Tudo o que está acima mede o modelo. Em 14 de outubro, a Artificial Analysis adicionou o DeepSeek V4.1 Flash ao AA-AgentPerf, o benchmark que ela executa contra sistemas aceleradores, e não contra modelos, e o resultado é a primeira resposta pública a uma pergunta que uma tabela de preços não consegue resolver: quanto deste modelo um megawatt de energia de datacenter sustenta. O AA-AgentPerf reproduz sessões gravadas de agentes de codificação — raciocínio em vários turnos, chamadas de ferramentas, contextos que passam de 100K tokens, com acertos de cache de prompt incluídos — contra uma stack de serviço ao vivo e descobre o maior número de agentes simultâneos que um sistema sustenta enquanto cada um ainda atende a uma meta de velocidade por agente. Para este modelo, o destaque é o componente de escala de rack da NVIDIA. A 100 tokens de saída por segundo por usuário, o GB300 NVL72 lidera o campo com aproximadamente 261 milhões de tokens por segundo por megawatt, à frente do B300, com cerca de 220 milhões, do B200, com 193 milhões, do GB200, com 178 milhões, e do MI355X da AMD, com 128 milhões. Esses são os números da Artificial Analysis, lidos hoje em sua página de inferência de datacenter, e são medições dela de hardware e configurações de serviço específicos, e não de um fornecedor. Vale a pena reter dois detalhes. Os números por megawatt são calculados a partir da potência do acelerador medida durante a execução — die da GPU mais HBM —, e não a partir do TDP nominal. E cada ponto do gráfico nomeia o motor, a versão e o formato numérico por trás dele, de modo que o número é uma afirmação sobre uma stack de serviço, e não apenas sobre os pesos.

O motivo de o gráfico deste modelo parecer diferente dos demais é o seu tamanho. O DeepSeek V4.1 Flash cabe em apenas dois aceleradores, e é por isso que um sistema em escala de rack obtém aqui menos vantagem do que em um modelo maior: o Artificial Analysis relata que o B300 fica dentro de cerca de 20% do GB300 NVL72 ao longo da curva e o supera nas duas pontas — a maior vazão por megawatt quando se permite que a velocidade por usuário caia, e o agente único mais rápido quando não se permite. Com batch size um, todas as peças Blackwell e a MI355X ficam entre aproximadamente 600 e 670 tokens por segundo para um único usuário, contra 372 a 392 no H100 e no H200. Comparado ao DeepSeek V4 Pro 0813 no mesmo eixo, o modelo menor entrega cerca de 1,3× a vazão por megawatt no GB300 e cerca de 6,2× no B200 na marca de 100 tok/s — a alegação de eficiência que a seção de arquitetura faz pelo lado do cache KV, vinda de um terceiro que mediu um sistema em vez de uma especificação. As configurações por trás desses números mostram o truque central do design em produção, e não apenas no papel: tanto nas execuções de dois aceleradores no B300 quanto na MI355X, a tabela Engram de 196B é servida a partir da memória host fixada (pinned) pelo caminho de CPU-offload do vLLM, em vez de ficar no acelerador — o mecanismo descrito nas notas de lançamento, agora visível na configuração por trás de uma medição publicada. Um segundo número de custo, em outra moeda, vem do benchmark no qual o post do vLLM de 7 de outubro foi medido. Em 17 de outubro, o projeto vLLM publicou um gráfico colocando o DeepSeek V4.1 Flash em 1,3B tokens por dólar de custo total de propriedade no SemiAnalysis AgentX, com curvas separadas para GB300 NVL72 sob Dynamo, GB200 NVL72, B200, H100 e MI300X. O nível de custo por trás disso é rotulado como owning at large-hyperscaler volume, e as premissas de hora-chip por baixo vão de US$ 0,95 para uma MI300X e US$ 1,17 para uma H100 até US$ 1,73 para uma B200 e US$ 2,31 para uma GB300, extraídas da própria pesquisa de preços da SemiAnalysis de julho de 2026. Dois limites acompanham isso. É o projeto vLLM relatando o modelo de custo da SemiAnalysis, e nenhuma das partes teve isso replicado. E o gráfico é datado de 16 de outubro, o dia anterior à DeepSeek substituir os pesos por trás do nome do modelo, então ele também descreve o checkpoint de setembro. Isso perfaz três moedas neste texto para um modelo: tokens por segundo por usuário, tokens por segundo por megawatt e tokens por dólar. A última é a única sobre a qual um comprador sem datacenter pode agir, porque é a quantidade à qual a melhoria de custo de um provedor eventualmente chega até ele. Continua sendo uma medição de serving e não de qualidade: nada aqui diz quão bom o modelo é, e os resultados de hardware de um leaderboard não são uma replicação de nenhuma linha de benchmark acima. O que isso estabelece é que o lado de custo da tabela de preços deste modelo agora tem evidência externa por baixo. Um modelo que um provedor pode servir a várias vezes a vazão por megawatt é um modelo que um provedor pode se dar ao luxo de manter barato, e o DeepSeek V4.1 Flash está no OrcaRouter pelo preço de tabela da própria DeepSeek com 0% de markup, que é o formato que repassa a melhoria de custo de um provedor em vez de retê-la.

Quanto custa o mecanismo no silício de dois fornecedores

Até esta semana, a questão de throughput sobre este modelo era respondida apenas por medições de outras pessoas — um runtime contabilizando o próprio trabalho, um site de benchmark medindo um sistema, desenvolvedores contando tokens em uma beta. A DeepSeek abriu o DeepInfer, o framework que ela diz alimentar o serviço de produção deste modelo, sob Apache-2.0 esta semana — o repositório apareceu em 16 de outubro e o primeiro commit entrou em 20 de outubro — e trouxe junto um gráfico de Pareto de decodificação para o checkpoint 1017 medido em 64 aceleradores SM100 dentro de um único domínio de scale-up. A configuração impressa no gráfico é a parte que importa, porque é a configuração da qual depende a comparação abaixo: paralelismo de especialistas de 64 sobre paralelismo de dados de 64, os “384+64 especialistas” impressos no gráfico, um contexto de 131.072 tokens, comprimento de rascunho do DSpark fixado em três tokens e uma taxa de aceitação por token de 75%. A curva atinge o pico logo abaixo de 30.000 tokens de saída por segundo por acelerador na sua extremidade menos interativa, cai pela faixa dos 20 e poucos mil à medida que a velocidade por usuário ultrapassa 100 tokens por segundo e chega a alguns milhares na borda direita do gráfico. É a DeepSeek medindo seu próprio engine no seu próprio modelo, então não é um número independente — mas é a primeira curva de decodificação para esta arquitetura publicada pelo laboratório que a criou, e o script de varredura que a produziu está no mesmo repositório.

O texto publicado ao lado do código fornece o ponto de operação, e é a razão pela qual os números abaixo são citados a 230 tokens de saída por segundo, e não em algum máximo abstrato. Os próprios números de produção da DeepSeek colocam o decode a 14K tokens por segundo por acelerador, enquanto o serviço mantém 230 tokens de saída por segundo por usuário — 300 em cargas de trabalho de programação — com uma taxa de acerto de cache de entrada de 96%, uma entrada média de 77K tokens, um tempo médio até o primeiro token de 400 ms e p99 de um segundo, e prefill provisionado em proporção próxima de 1:1 com o decode, em um único cluster que, segundo ela, serve 155 trilhões de tokens por dia. A linha de receita ao lado desses números, US$ 38 por hora de acelerador com preços fora de pico, é o primeiro número de custo que a DeepSeek associou publicamente à operação desse modelo. Nada disso é auditado, tudo é a fornecedora descrevendo seu próprio serviço, e ainda assim é o retrato mais concreto que existe do custo de operação dessa arquitetura.

A outra metade da comparação vem do silício da Huawei, e é a metade com a fonte mais fraca. Uma planilha de benchmark datada de 30 de setembro e intitulada “Ascend 950DT DeepSeek-V4.1-Flash Benchmark” relata o modelo implantado em 32 chips com precisão mista FP8–FP4, com atenção com paralelismo de dados e mistura de especialistas com paralelismo de especialistas, em uma sequência de 128K tokens, usando decodificação especulativa DSpark com uma configuração forçada de balanceador de carga com paralelismo de especialistas e um comprimento médio aceito de 4,1 tokens. Ela traz três pontos. Sua coluna de latência é o tempo por token de saída, então o recíproco de cada entrada é a velocidade por usuário daquela linha, e é isso que permite comparar a planilha com a curva:

• Lote global de 1.536, 9,41 ms por token de saída — cerca de 106 tokens de saída por segundo por usuário — 5.102 tokens por segundo por chip.

• Lote global de 384, 4,40 ms por token de saída — cerca de 227 tokens de saída por segundo por usuário — 2.727 tokens por segundo por chip.

• Lote global de 2.560, 13,79 ms por token de saída — cerca de 73 tokens de saída por segundo por usuário — 5.800 tokens por segundo por chip, o maior valor da planilha e o usado em sua manchete.

Comparadas à curva da NVIDIA, as duas linhas do meio são as que pesam, porque ficam nas velocidades em que um serviço de fato opera. O tópico que trouxe a planilha à tona interpreta a comparação como 25.500 tokens por segundo por acelerador contra 5.102 a 100 tokens de saída por segundo por usuário, e 20.000 contra 2.727 a 230 — uma diferença de cinco vezes no primeiro ponto de operação e de 7,4× no segundo. Ler diretamente a mesma curva publicada desloca esses números da NVIDIA: uma leitura pixel a pixel da imagem chega mais perto de 28.000 na marca de 100 tokens e mais perto de 17.000 em 230, de cada lado dos números do tópico; a faixa que eles apresentam é de cerca de cinco vezes e meia no primeiro ponto de operação e de cerca de seis no segundo, o que estreita a faixa do tópico sem mudar sua forma. É isso que vale um benchmark lido de um gráfico, e isso não muda a direção do resultado. Também vale notar que o número de destaque de 5.800 da planilha é sua linha menos interativa — o ponto em que a curva da NVIDIA está mais próxima de seu próprio pico e em que a razão volta a cerca de cinco.

Não consegui encontrar essa planilha nas páginas da própria DeepSeek ou da Huawei; ela chegou a este artigo como uma imagem anexada a uma thread no X, e os três números do Ascend devem ser lidos como um benchmark de fornecedor não publicado até que alguém publique a execução por trás deles. O que é verificável é a assimetria nas configurações, e isso vem da própria documentação da DeepSeek. As notas de implantação do DeepInfer recomendam prefill com paralelismo de especialistas de 2 a 8 e decode com 64 a 128, em “máquinas comuns de 8 GPUs para prefill, supernós comuns de 64–128 GPUs para decode”. Na NVIDIA, isso corresponde a um único domínio NVLink, e foi dentro dele que o gráfico acima foi medido. No Ascend, a própria biblioteca de comunicação da DeepSeek diz claramente o que não está concluído: “Tamanhos de EP maiores e o combine continuam em otimização”, com o combine carregando sobrecarga extra de redução local e contenção de HBM contra o caminho URMA, e com trabalho de firmware da Huawei ainda por vir — uma ressalva pública no DeepEP-Ascend desde seu primeiro lançamento, em 29 de setembro. Essa é a maneira justa de interpretar a diferença: o número da NVIDIA vem do formato para o qual o DeepInfer foi ajustado, e o número do Ascend, de uma pilha cujo próprio autor diz que o caminho de EP amplo ainda está em desenvolvimento. Parte dos cinco a sete vezes é o chip, parte é a interconexão e o software por baixo dela, e ninguém separou as duas.

Quanto a lacuna vale em dinheiro depende de preços que ninguém publicou, e a thread faz as contas mesmo assim: a cerca de US$ 139.000 por acelerador Blackwell, extrapolados de preços de racks no mercado cinza, contra US$ 37.000 rumorados para um 950DT, a NVIDIA precisa entregar cerca de 3,8× o throughput por chip para igualar o Ascend apenas no custo de aquisição; a thread situa o ponto de cruzamento perto de 6.800 tokens por segundo por chip. Os pontos publicados do Ascend ficam abaixo dessa linha; a previsão da thread de que o caminho wide-EP os eleva para 8.000–10.000 fica acima dela, e isso é uma previsão, não uma medição. Todo dado de entrada é frágil — um preço de mercado cinza, um rumorado e números lidos de uma curva — e nada disso leva em conta rede, energia, refrigeração, manutenção ou o valor de simplesmente poder comprar o hardware.

Para quem nunca vai montar um nó em rack, a parte útil não é o placar. É que o modelo mais barato da linha DeepSeek agora está documentado como barato de servir no silício de dois fornecedores, com o próprio motor do fornecedor publicado e os números por trás dele disponíveis para download — o tipo de evidência em que um preço se baseia. Isso não altera nenhuma tabela de preços: o DeepSeek V4.1 Flash está no OrcaRouter pelo preço de tabela do próprio provedor, US$ 0,15 por 1 milhão de tokens de entrada e US$ 0,60 por 1 milhão de tokens de saída nas tarifas fora de pico, repassado com 0% de markup, então, quando o custo de serviço de um provedor cai, a economia chega como um preço que não precisa mudar, e não como uma margem de revenda. Um custo de serviço debatido no hardware de dois fornecedores é um preço com mais espaço para cair do que um que ninguém mediu de forma alguma.

Engenharia de kernel: o primeiro placar que não é da DeepSeek

As linhas de benchmark acima são números do próprio harness da DeepSeek, e as pontuações externas que agora existem medem raciocínio geral e exploração cibernética, e não programação de baixo nível. A primeira análise de terceiros da engenharia de kernels do modelo também existe, e chegou numa forma que a DeepSeek não encomendou: um benchmark agêntico conduzido pela comunidade que pede aos modelos que escrevam kernels CUDA reais e pontua os resultados em relação a um roofline — o teto teórico do hardware. O ranking é kernelbench.com, executado numa RTX PRO 6000, e é independente de ambos os fornecedores. Sua metodologia de auditoria é relatada pela comunidade, e não revisada por pares, então leia suas porcentagens como um sinal direcional de terceiros, não como uma medição certificada; também é o primeiro placar nesta história em que os números da DeepSeek ficam ao lado dos de um concorrente direto.

A linha de destaque é aquela em torno da qual a arquitetura foi construída. A própria atenção esparsa do DeepSeek V4.1 Flash — a pilha CSA2 que produz o cache de 890 bytes por token — foi escrita como um kernel CUDA pelo modelo e alcançou 50,19% da roofline equivalente à densa, quarto lugar no placar, atrás do Claude Fable 5.1 com 106,27%, do Claude Opus 5 com 103,67% e do Claude Fable 5 com 72,66%. A primeira coisa a notar é que a própria arquitetura do criador é o kernel em que ele é melhor: um modelo treinado em um design de atenção esparsa escreve o kernel de atenção esparsa com mais eficiência do que qualquer outra coisa no placar abaixo dos três primeiros. A segunda coisa é a comparação que o informante destacou. A tentativa do GLM-5.3 Flash com o mesmo kernel alcança 4,45% da roofline — uma ordem de magnitude abaixo do V4.1 Flash na mesma linha do mesmo placar. Essa diferença, e não qualquer benchmark publicado pela DeepSeek, é o que significa "melhoria massiva em engenharia de kernel".

A comparação não para na linha de atenção esparsa, e o quadro mais completo importa porque a manchete do tweet nomeia o GLM-5.3 Flash, enquanto o texto citado que ele referencia na verdade menciona um GLM-5.2 diferente e maior em sua própria linha de fused-MoE — uma incompatibilidade de nomenclatura com a qual vale a pena ter cuidado. Nas linhas em que ambos os modelos de nível Flash realmente concluíram uma execução, o V4.1 Flash vence todas: Kimi-Linear Decode a 17,10× contra 13,64×, MegaQwen Decode a 5,39% do roofline contra 3,92%, TopK Bitonic a 4,25% contra 7,17% do GLM-5.3 Flash, Sonic MoE a 10,81% (a melhor pontuação que qualquer modelo do ranking registrou para esse kernel) contra 10,21%, e KDA CUTLASS a 3,74% contra 2,26%. Em mais dois kernels, o GLM-5.3 Flash não tem nenhuma execução concluída — fused MoE e o kernel de simulação Grid + MinGRU, em que o V4.1 Flash registra 28,56% do roofline. (A única linha em que o GLM-5.3 Flash supera o V4.1 Flash é TopK Bitonic, 7,17% contra 4,25%, que também é a linha em que nenhum dos modelos chega perto do líder do ranking.) O panorama geral é o mesmo da manchete: em trabalho de GPU de baixo nível, o V4.1 Flash não está apenas à frente do modelo menor da Z.ai — está em outra liga, e nos dois kernels mais difíceis o modelo menor nem termina.

O que o placar não faz é dizer quanto dessa lacuna é o modelo e quanto é a arquitetura que ele é solicitado a escrever. DeepSeek V4.1 Flash é um modelo de 552B parâmetros cuja própria atenção é um design de atenção esparsa; GLM-5.3 Flash é um modelo menor cujo treinamento nunca girou em torno da mesma pilha CSA2. Um modelo solicitado a escrever um kernel para uma arquitetura que se assemelha à sua própria distribuição de treinamento tem uma vantagem inerente, e é por isso que a leitura mais justa do placar é direcional, e não um veredito de confronto direto: a engenharia de kernel agora é uma capacidade medida desse modelo, ela é genuinamente forte, e a comparação específica que o informante traçou se sustenta nas linhas compartilhadas. O placar também responde a uma pergunta que a ficha técnica não conseguia: se o cache de 890 bytes é realizável na prática. Um modelo que escreve seu próprio kernel de atenção esparsa até metade do roofline é um modelo cujo design central é, no mínimo, implementável em hardware real pela mesma classe de engenheiro que teria de servi-lo.

O lugar honesto onde isto se encaixa é ao lado de tudo o resto neste artigo: mais uma medição de terceiros que a DeepSeek não produziu, desta vez de uma capacidade — escrita de kernels de GPU — que nenhuma linha de benchmark de fornecedor cobria. É um único placar da comunidade para uma única geração de GPU, executado uma vez, e a sua auditoria não passou por revisão por pares, por isso é uma evidência sobre a direção, e não uma pontuação certificada. Mas é o primeiro número externo que mostra para que serve a nova arquitetura: um modelo barato da categoria Flash que, quando solicitado a fazer o trabalho de sistemas de baixo nível no qual a própria DeepSeek investe a sua engenharia, atinge cerca de metade do que o hardware permite, enquanto o seu concorrente direto da categoria Flash atinge menos de um vigésimo.

Correções rápidas, confirmações lentas: os primeiros relatos práticos

A taxa de transferência é a metade da história da velocidade que um contador de tokens não consegue ver. Os relatos práticos acumulados desde o lançamento medem a outra metade — como o modelo se comporta no caminho até uma resposta, e quanto custa esse comportamento — e não concordam sobre se o que encontraram é uma funcionalidade. Três relatos independentes descrevem o mesmo padrão. Nenhum deles é uma avaliação controlada; os números abaixo são de profissionais individuais a executar as suas próprias tarefas, e devem ser lidos como relatos de utilização, e não como medições.

O relato mais claro do comportamento vem da MindStudio, que colocou o DeepSeek V4.1 Flash para fazer uma construção do zero de um visualizador 3D interativo. Seu traço de raciocínio, nas palavras do avaliador, “mostrou que ele verificava sua própria matemática em vez de apenas emitir código”. O modelo detectou um bug de amortecimento no controle de órbita no meio da construção, deduziu a correção a partir de primeiros princípios e então “verificou novamente a correção em um navegador headless antes de declarar a tarefa concluída”. Em uma segunda tarefa — um dashboard baseado em Docker — ele encontrou um único operador de comparação invertido e confirmou a correção consultando o endpoint em execução oito vezes à medida que os números eram atualizados. É isso que os testadores da beta estavam descrevendo quando chamaram o modelo de alguém que pensa demais, e não há nada de errado em nenhum passo individual disso: o erro foi encontrado, corrigido e verificado. É também exatamente a reclamação. O bug já tinha sido tratado, outra sessão do DeepSeek já tinha confirmado a correção em menos de um minuto, e o modelo continuou verificando mesmo assim. A MindStudio encara o hábito como um ponto forte e diz isso; sua única crítica naquele teste foi um problema de física que entrou em loop até ser interrompido manualmente na primeira tentativa, e então foi resolvido corretamente na nova tentativa.

A leitura vinda da outra direção é sobre o relógio. Uma compilação comunitária de testes do V4.1 Flash descreve um problema de física — um copo d'água cortado em um ângulo oblíquo — em que o modelo passou doze minutos e aproximadamente 130.000 tokens no caminho até uma resposta correta, executando três rodadas de autoverificação que não lhe haviam sido solicitadas antes de convergir. O mesmo relato documenta o modo de falha no extremo oposto desse hábito: a cadeia de pensamento ocasionalmente cai em um loop de repetição “let me write” que percorre tokens a cerca de 200 por segundo sem avançar, e seu conselho é do lado do cliente, e não do lado do modelo — definir um teto de max_tokens e um tempo limite de requisição e deixá-los truncar o loop. Ele também registra a mesma classe de problema sendo despachada em dezoito segundos por uma execução com o esforço de raciocínio reduzido para o nível baixo, o que é um lembrete de que a maior parte disso é um ajuste, e não um defeito.

A evidência mais contundente de que volume de verificação não é a mesma coisa que correção vem de uma revisão do Tencent Cloud Labs que colocou o DeepSeek V4.1 Flash como implementador e o GPT-6 Astra como revisor na reprodução de um artigo. Foram executadas três rodadas, e o Astra nunca contestou o algoritmo central. O que o revisor não parava de corrigir, rodada após rodada, era a estrutura que o V4.1 Flash havia construído para si mesmo — a configuração de seus experimentos, sua construção estatística e a interpretação que ele extraía de seus próprios resultados. O número de testes cresceu de 82 para 97 e depois para 110, e todos eles passaram em todas as vezes. Em comparação com uma linha de base de força bruta, a configuração escolhida pelo modelo correspondeu ao ótimo em 8,89% dos casos sob os próprios parâmetros do artigo, 11,04% com confiança aleatorizada e 10,30% sob uma configuração aleatorizada. A constatação mais incisiva do Astra foi sobre um teste que alegava verificar limites de inteiros: ele executou 153 verificações de extensão e zero ramificações de limite de inteiros. Um modelo pode passar na suíte que ele mesmo escreveu e ainda assim não ter respondido à pergunta, e essa revisão é um caso concreto dessa lacuna, e não uma mera afirmação de que ela existe. O escopo é estreito e os autores admitem isso — um único seletor de comprimento especulativo, valores de confiança simulados, nenhuma execução de ponta a ponta —, mas o formato é o que os outros relatos descrevem.

Colocados ao lado dos números da Artificial Analysis, esses relatos deixam de parecer anedota. A primeira avaliação independente do modelo o mediu como muito rápido e muito prolixo ao mesmo tempo: 185 tokens de saída por segundo, e 250 milhões de tokens de saída gerados em seu conjunto de avaliação, contra uma mediana de 140 milhões para modelos comparáveis. Uma pontuação composta não consegue dizer para onde vai a saída extra. Os relatos práticos conseguem. Os tokens não são preenchimento — são o modelo conferindo. O mesmo volume aparece de uma direção não relacionada em um relatório de bug sobre um cliente de terminal de terceiros, no qual conteúdo de raciocínio em uma rota deepseek-flash foi anexado à resposta visível em vez de ser separado em um bloco de pensamento, produzindo blocos de texto únicos de até 73.003 caracteres de monólogo interno, sem que nada fosse capturado para reproduzir em turnos posteriores. Esse bug pertence ao cliente, e não à DeepSeek, e não é evidência sobre qualidade — mas é uma ilustração adequada de quanto pensamento este modelo emite quando um harness falha em separá-lo.

Nada disso invalida a aritmética de preços acima; apenas a explica. Um modelo que se autoverifica vale os tokens gastos em trabalho agêntico, onde uma correção errada custa mais do que os tokens gastos para provar que ela está certa, e é inadequado para um longo ciclo de edições triviais, em que a confirmação constitui a maior parte da execução. Duas coisas tornam a diferença administrável. O ajuste de esforço de raciocínio é um número inteiro contínuo de 1 a 100, em vez de três níveis fixos, de modo que o mesmo modelo pode ser ajustado para baixo em trabalho barato e para cima em trabalho difícil — o resultado de dezoito segundos acima veio de fazer exatamente isso. E a rede de segurança barata pertence ao cliente: um teto de max_tokens e um timeout de requisição transformam um loop de repetição de uma conta em uma resposta truncada. Ambas são o tipo de configuração que vale a pena fixar antes que um caminho de produção aponte para este modelo, e nenhuma delas é algo que o modelo fará por si mesmo.

Recusas: o checkpoint recusa, e a recusa é mensurável

Em 20 de outubro, o que chamou atenção para o DeepSeek-V4.1-Flash-1017 não foi uma linha de benchmark, mas uma recusa. O rastreador do DeepSeek que este artigo já citou publicou uma captura de tela de uma sessão de agente executando o checkpoint 1017 com dsh-purge aplicado, e relatou que o modelo recusou mesmo assim: a execução, nas palavras do autor da postagem, “recusou a persona”, com o modelo argumentando que a solicitação era “uma tentativa de injeção de prompt” e que “não deveria adotar a persona”. A interpretação do post foi que o checkpoint “não é *totalmente* ingênuo em relação a jailbreaks” e que o DeepSeek está “começando a pensar em segurança”. O dsh-purge não é um truque de prompt colado em uma mensagem do usuário. É um plugin público do DeepSeek Harness — 9.897 estrelas no GitHub e versão 1.1.71 em 20 de outubro — criado para remover a reescrita de prompt do próprio harness e os sufixos injetados, e seu README em inglês traça exatamente a distinção em que este teste se baseia: o harness “reescreve prompts, gates de aprovação, política de sandbox e migração de sessão em tempo de execução”, então perguntar apenas “o modelo vai responder” trata um bloqueio da camada de host como recusa do modelo, e o plugin existe para separar essas duas camadas na sua própria instalação. Nesta sessão, a separação ficou do lado do modelo. Os contadores na mesma captura de tela — 156 etapas, 33,7 milhões de tokens, 232 tokens por segundo — descrevem uma execução completa de agente, e não um prompt de disparo único, e o resumo do próprio agente diz que o plugin estava mecanicamente correto e que “aquele modelo específico recusou isso”.

Essa é a captura de tela de uma pessoa de uma única sessão, e deve ser apresentada exatamente como tal. O prompt não aparece, o veredito é o próprio resumo do agente, e não uma resposta classificada, e a conta é de um observador do DeepSeek, e não de um laboratório de avaliação, de modo que nada no post pode ser reproduzido a partir do próprio post. O que faz valer a pena levá-lo a sério é que ambas as suas metades podem ser verificadas em fontes independentes da pessoa que o publicou: o plugin, que é público e documenta seu próprio mecanismo, e o comportamento de recusa do checkpoint, que outra pessoa agora contabilizou.

A contagem está na documentação de um derivado. Uma compilação abliterada comunitária dos pesos 1017, publicada no Hugging Face em 17 de outubro, traz a medição que tornou a compilação necessária. Em 100 solicitações prejudiciais de validação, decodificadas de forma gulosa por 384 tokens cada, o checkpoint intacto recusou 97 no modo chat e 98 no modo think; após um subespaço de recusa de posto 2 ser projetado para fora das 40 camadas principais, os mesmos 100 prompts obtiveram 4 e 9 recusas. Esses são números de terceiros sobre os pesos da DeepSeek, produzidos sem acesso ao pipeline de treinamento da DeepSeek, e também são um único conjunto de prompts, um único avaliador e uma única quantização do modelo — uma conversão Q8_0 em vez do FP8 que a DeepSeek distribui —, então a leitura honesta é “quase sempre”, não “97,0%”. Com base nessas evidências, a descrição de quem postou se sustenta: o checkpoint recusa, de forma confiável, em ambos os seus modos.

O que a figura não sustenta é a ideia de que esta seja uma nova postura. O checkpoint de setembro já estava lá. A equipe por trás de uma build de setembro sem censura mediu o modelo intocado no conjunto completo de 320 prompts do HarmBench e relatou sucesso de ataque de 42,8% com o raciocínio desativado e 1,6% no esforço máximo — ou seja, o modelo que este substitui recusou aproximadamente 98% dessa classe de solicitação quando teve permissão para pensar. As duas medições vêm de conjuntos de prompts diferentes, avaliadores diferentes e quantizações diferentes, portanto não podem ser subtraídas uma da outra; o ponto em que concordam é a forma. A recusa com esforço alto já era o comportamento do modelo de setembro, e o checkpoint 1017 está na mesma faixa. A afirmação mais restrita é a que a sessão de 20 de outubro realmente testa, e é a que vale manter: a recusa sobreviveu a um plugin criado especificamente para remover as restrições do lado do harness, e sobreviveu como julgamento do modelo sobre o prompt, e não como um bloqueio da camada de host.

Nada disso é documentado pelo fornecedor. A ficha do modelo de setembro da DeepSeek tem uma seção de avaliação e ela traz apenas benchmarks — nenhuma taxa de recusa, nenhum resultado de red team, nenhuma avaliação de segurança — e a ficha 1017 não tem seção de avaliação alguma, tendo abandonado essa pasta junto com o relatório técnico. O comportamento de recusa desse modelo é, portanto, descrito inteiramente pelas pessoas que constroem em torno dele: autores de derivados contando prompts e um rastreador lendo uma transcrição. Para quem aponta um agente para o checkpoint, essa é a lacuna operacional. Uma recusa dentro de um loop de agente não é uma nota de rodapé de política de conteúdo; é uma chamada de ferramenta falha no meio de uma execução, e aparece como qualquer outra falha por chamada — e é por isso que a mitigação é a mesma dada a um timeout. Na OrcaRouter, isso é uma decisão de roteamento, não uma mudança de código: o checkpoint 1017 e os modelos DeepSeek para os quais ele faria fallback ficam atrás de um único endpoint, então uma chamada que volta com recusa pode ser repetida contra um segundo modelo em vez de encerrar a execução. A recusa em si pertence ao modelo, e nada na camada de roteamento a altera.

A contagem de derivados é a última peça independente, e aponta na mesma direção. Uma busca no Hugging Face pelo nome do checkpoint retornou 121 repositórios públicos em 20 de outubro, e 25 deles trazem “uncensored”, “abliterated” ou “derisked” no nome — builds cujo propósito inteiro é remover o comportamento com que a sessão de 20 de outubro se deparou, o primeiro deles publicado no mesmo dia em que os pesos foram disponibilizados. Isso não é evidência sobre se o modelo é bom, nem uma recomendação; é evidência de que há um mecanismo de recusa em funcionamento nos pesos, que pode ser removido, porque as pessoas que retiram essas coisas não se dão ao trabalho quando não há nada para retirar. Também define a expectativa para qualquer pessoa que hospede o modelo por conta própria: o checkpoint que você baixa é o que recusa, e cada variante “uncensored” daquela lista é um modelo diferente, não uma configuração.

A questão do V4 Pro, e os degraus acima do Flash

Durante o beta, o formulário de feedback da DeepSeek perguntou aos testadores se a versão intermediária “pode substituir totalmente o DeepSeek V4 Pro online”. Era uma pergunta impressionante de se fazer aos usuários, porque implicava que o futuro do carro-chefe estava em aberto. A resposta que chegou em 9 e 10 de setembro foi operacional: a partir das 12h00 no horário de Pequim de 14 de setembro, o deepseek-v4-pro deixaria de ser servido e seu tráfego passaria para o V4.1 Flash com os preços do Flash, com o V4.1 Pro indicado como sucessor final. Os desenvolvedores objetaram, e a objeção não era que a substituição fosse ruim — era que uma string de modelo é um contrato, e trocar os pesos por trás de um ID de produção quebra pipelines ajustados por prompt e loops de agentes construídos com base nos antigos. Em dois dias, a DeepSeek retirou o plano. Seu próprio changelog agora diz que ela “decidiu continuar oferecendo serviços de API para o DeepSeek V4 Pro após 14 de setembro de 2026, com o método de cobrança inalterado”, e que dará aviso adicional se isso mudar. A reversão é declarada pelo fornecedor, e não noticiada, e pode ser verificada na página Models & Pricing, que ainda lista deepseek-v4-pro ao lado de deepseek-flash.

O que a tabela de roteamento não explica é o porquê. Em 9 de setembro, teortaxesTex — uma das contas de fontes que sinalizaram o beta — relatou que a DeepSeek admitiu que o pré-treinamento do V4-Pro deu errado; nas palavras dele, a empresa “fez besteira” com isso. Isso continua sendo uma alegação de fonte única, vinda de uma conta com inclinação para fontes internas, e a DeepSeek não admitiu nada publicamente: o changelog enquadra a descontinuação como consequência de o novo modelo ser melhor, e não de o antigo estar defeituoso. O que dá para verificar de fora é o formato do lançamento de disponibilidade geral do V4 Pro, em 13 de agosto. O anúncio foi retirado em cerca de um dia. O repositório do Hugging Face chegou a trazer brevemente uma configuração de nível Flash sob o nome Pro, antes de os pesos serem corrigidos. E a pontuação independente do que estava sendo servido sob esse nome ficou pouco acima da do DeepSeek V4 Flash, bem menor, em contraste com gráficos oficiais que mostravam resultados quase de topo de linha — no atual índice artificial-analysis, os dois estão a apenas um ponto de distância, 36 contra 35. Análises independentes atribuíram o ocorrido a causas diferentes — comportamento de raciocínio sobreajustado ao próprio harness de avaliação da DeepSeek, uma confusão entre implantação e pesos ou, como alega o vazamento, um pré-treinamento que de fato deu errado. O redirecionamento não define qual delas, e a DeepSeek desde então o cancelou; o que resta é uma fornecedora precificando seu modelo mais novo a um quarto da taxa de cache miss do modelo topo de linha e colocando-o à frente desse topo de linha nos próprios benchmarks, o que as empresas normalmente não fazem porque tudo saiu conforme o planejado.

Flash, Pro, Ultra: o que a DeepSeek disse e o que é apenas um palpite

A documentação da própria DeepSeek é explícita ao afirmar que isto é a base de algo. O changelog chama o DeepSeek V4.1 Flash de “o menor modelo da nossa nova família de arquiteturas” e diz que a arquitetura “foi projetada para um teto de capacidade mais alto, inferência mais rápida, maior throughput e escalabilidade para modelos maiores”. O relatório técnico fecha o mesmo ciclo com linguagem mais forte: o modelo “serve como um novo ponto de partida para nossos esforços contínuos de escalonamento”, e a empresa afirma que “buscará o escalonamento conjunto da arquitetura do modelo, do pré-treinamento e do pós-treinamento para explorar ainda mais a fronteira da inteligência dos modelos”. Ambas as frases são da própria empresa, ambas foram publicadas em 10 de setembro e nenhuma delas é um anúncio de produto. Elas comprometem a DeepSeek a construir modelos maiores com esse design; não nomeiam, dimensionam nem datam nenhum deles.

Tudo o que vem depois dessa linha é especulação. Em 25 de setembro, o rastreador @teortaxesTex — a mesma conta cujo post de 9 de setembro sobre o pré-treinamento do V4 Pro este artigo já traz — interpretou o padrão como uma linha completa de três níveis: “A DeepSeek deixa bem claro que não vai parar por aqui… Isso soa como se eles pretendessem fazer uma linha inteira, Flash-Pro-Ultra. Talvez 522B-2T-8T?” Os tamanhos são rotulados como um palpite pela pessoa que os apresenta, e a ressalva cumpre um papel real: nada no changelog, na ficha do modelo, no relatório técnico, na organização da DeepSeek no Hugging Face, na página de preços ou na listagem de modelos da DeepSeek menciona um nível Ultra, e nada acima de 552B. A escada de tamanhos conjecturada também envolve uma aritmética mais frágil do que parece. Seu degrau inferior, 522B, não é o modelo de 552B que foi lançado — ou o número é um lapso para um valor que a DeepSeek já publicou, ou aponta para um checkpoint que ninguém viu, e não há como saber de fora qual dos dois. Seu degrau superior, 8T, é cinco vezes o modelo principal de 1,6T cujo repositório a DeepSeek abriu em abril, em um ano em que o lançamento mais recente da empresa foi projetado para ativar 8B parâmetros por token porque o custo de inferência, e não a contagem de parâmetros, era a restrição que ela se propôs a resolver.

O mesmo relato aventou, separadamente, um modelo DeepSeek de 3 trilhões de parâmetros como algo em que o laboratório estava trabalhando, mas sem certeza de que conseguiria servi-lo de forma economicamente viável — uma alegação diferente sobre uma coisa diferente, e igualmente não confirmada. Nenhuma das duas precisa ser reconciliada com a outra, porque nenhuma tem uma segunda fonte. O que pode ser verificado é a direção: um laboratório que chama seu modelo mais novo de o menor de uma família, e sua arquitetura de uma que escala para modelos maiores, é um laboratório que planeja lançar algo acima deste degrau. Como ele chamará os degraus, e qual será o tamanho deles, não está em nenhum documento que um leitor possa abrir hoje.

Para quem escolhe um modelo em vez de seguir um roteiro, essa distinção é tudo o que importa. Se a família realmente se estender para cima, a decisão diante da maioria das equipes ainda é se migrar para o degrau que existe — e a maneira mais barata de manter essa decisão em aberto é não esperar. O DeepSeek V4.1 Flash está no OrcaRouter com as próprias tarifas da DeepSeek, com 0% de markup, então, se um sucessor do nível Pro chegar com um preço diferente, a mudança cai na tabela de preços e não no contrato. O DeepSeek V4 Pro fica na mesma chave por trás dele, o que faz com que um terceiro nível que chegue depois seja uma decisão de roteamento e não uma migração.

Os pesos MIT mudam o que você pode fazer com eles

O DeepSeek V4.1 Flash é distribuído sob a licença MIT, e os pesos foram publicados na organização deepseek-ai no Hugging Face em 10 de setembro — no mesmo dia que a API, não semanas depois. O repositório é deepseek-ai/DeepSeek-V4.1-Flash: 48 shards safetensors totalizando cerca de 510 GB, o relatório técnico em PDF ao lado deles, e uma pasta de inferência contendo uma implementação de referência e um script de conversão que divide o checkpoint entre ranks de paralelismo de tensor. Esse repositório é o checkpoint de setembro; o ativo desde 17 de outubro é deepseek-ai/DeepSeek-V4.1-Flash-1017, que traz a mesma licença MIT, os mesmos 48 shards e os mesmos cerca de 510 GB, mas substitui todos os shards e remove o relatório, o template de chat e a pasta de avaliação.

Vale a pena ser preciso sobre o que é esse download, porque não é uma versão de precisão total. Os safetensors contêm aproximadamente 204B parâmetros em FP8 e 557B em INT8, contra cerca de 2B em BF16, e a configuração declara quantização fp8 — o checkpoint que você baixa já está comprimido, e é assim que um modelo de 763B parâmetros cabe em cerca de 510 GB. O maior bloco único dentro dele é a tabela Engram: duas tabelas FP8 que ocupam cerca de 189 GiB do download, das quais cada etapa de decodificação lê apenas algumas linhas.

Para um modelo com um backbone de 552B, a licença é a parte que muda decisões. A MIT é permissiva, sem restrição de receita e sem cláusula de uso aceitável que valha uma revisão jurídica, e o perfil de ativação — 8B por token no prefill, 16B no decode, com um cache de 890 bytes por token — é o que torna viável servi-lo fora de um hiperescalador mesmo que a contagem de parâmetros pareça grande. Esse último número, no entanto, é uma propriedade da pilha completa de cache, e não dos pesos, então um mecanismo auto-hospedado que implemente o formato quantizado e não o restante do design ficará bem acima dele.

Uma licença permissiva não é uma autorização de exportação e, por seis dias em outubro, a diferença pareceu poder importar. Em 16 de outubro, o Ministério do Comércio e o Ministério da Ciência e Tecnologia da China publicaram o Anúncio nº 48 de 2026, uma revisão preliminar do catálogo de tecnologias proibidas ou restritas para exportação que, pela primeira vez, abrange pesos de modelos de IA e código-fonte. Ele propõe 40 acréscimos em IA, biotecnologia e energia solar, 23 deles relacionados à IA, com consulta pública até 15 de novembro. Duas exceções no rascunho fazem o trabalho principal para um modelo como este: tecnologia já em domínio público por meio de lançamento em código aberto ou publicação acadêmica não deve ser controlada, e o acesso por API, aplicativo, SaaS e acesso leve no dispositivo por usuários no exterior não é tratado como exportação de tecnologia de modelo. Os limites noticiados na imprensa especializada combinam um piso de dois trilhões de parâmetros, uma posição entre os dez primeiros no mundo em benchmarks de desempenho e segurança, e treinamento com dados nacionais centrais ou importantes. Um modelo de 552B atende ao primeiro; se os outros dois o alcançam não é algo que um leitor consiga determinar de fora, porque o rascunho não publica as definições — o que faz da exceção de domínio público, e não do teste de tamanho, a cláusula que importa para pesos que já estão no Hugging Face.

O que mudou em 22 de outubro não foi o texto, mas o registro de conformidade. YuyuantanTan relatou que a DeepSeek e a MiniMax haviam concluído os procedimentos de registro e finalizado o open-sourcing e o licenciamento no exterior. O relatório não diz quais lançamentos considera como o open-sourcing, não nomeia nenhum modelo, checkpoint ou data, e não anunciou novos pesos; os lançamentos de código aberto visíveis nessa janela são o motor DeepInfer e o kit de ferramentas deepseek-recipe abordados acima. A versão da alegação em nível de build é mais restrita e posterior: em 23 de outubro, uma conta do X com um longo histórico de acompanhamento da DeepSeek publicou que a DeepSeek e a MiniMax haviam “obtido permissões para abrir o código-fonte do V4.1F-1017 e do M3.1-Flash”, respectivamente. Essa atribuição é de quem publicou, nenhuma das empresas publicou uma declaração confirmando isso, e nenhum regulador publicou um aviso nomeando o registro de qualquer das empresas. O checkpoint nomeado na publicação estava no Hugging Face sob licença MIT desde 17 de outubro, seis dias antes. Seja qual for a permissão concedida, ela não condicionou o download: o repositório veio primeiro.

Para o leitor, o conteúdo prático é mais estreito do que as manchetes ao seu redor, e vai em duas direções. Nada sobre o checkpoint de 17 de outubro, a licença MIT ou o repositório mudou em 22 de outubro; o download, os shards e as diferenças de hash descritas acima estão exatamente como estavam. O que mudou é a resposta à pergunta se um laboratório chinês pode continuar publicando pesos como estes enquanto o catálogo ainda está em consulta: o relato da mídia estatal diz que sim para DeepSeek e MiniMax, sob uma minuta que exclui tecnologia já pública e deixa o acesso via API fora da definição de exportação. O limite está no tempo verbal. A isenção é para tecnologia já em domínio público, o que descreve os checkpoints de setembro e outubro e não descreveria automaticamente um lançamento feito depois que o catálogo for finalizado — e a obrigação de registro interina que se disse ter entrado em vigor em 16 de outubro foi noticiada, e não publicada na íntegra. Quem planeja baixar o que quer que a DeepSeek lance a seguir está planejando com base em uma regra que ainda não existe. Quem faz chamadas à V4.1 Flash hoje, ou executa os pesos 1017, está contando com uma exceção que a minuta estabelece e que nenhum dos relatos sobre a medida interina contradiz.

O suporte a serving chegou no mesmo dia e estabelece o piso prático. O vLLM publicou uma receita day-0 validada em hardware NVIDIA e AMD, e o SGLang entregou suporte day-0 a inferência e RL na mesma janela por meio de sua stack de treinamento Miles. Ambos foram entregues como imagens de prévia, em vez de pacotes estáveis — o contêiner do vLLM trazia uma tag de 9 de setembro, um dia antes do GA do próprio modelo. Esse lado da história avançou em 22 de setembro, quando o vLLM lançou a v0.30.0: a primeira versão estável do vLLM a trazer essa arquitetura, com o DeepSeek V4.1 Flash listado em seu suporte a novos modelos, a própria receita vLLM do modelo agora exigindo 0.30.0 ou posterior, e a tag da imagem do dia do lançamento descontinuada. As notas de versão são o relato do próprio projeto sobre seu trabalho, e não um resultado medido, e devem ser lidas dessa forma. Elas atribuem à versão o fato de manter todo o cache KV do modelo em MXFP8 por meio do recorde do FlashMLA V4.1 no SM100, e de fazer prefetch assíncrono para consultas ao Engram descarregadas para a CPU, além de sharding data-parallel do Engram — as duas mudanças que mais importam para um modelo cuja tabela Engram é o maior bloco único do download. Nenhuma dessas duas mudanças traz um número externo ao projeto, e as notas de versão não anexam nenhum — mas o projeto publicou um antes e depois do modelo como um todo em 7 de outubro, três semanas após o lançamento: 1,9× mais rápido em baixa concorrência e 5,3× a vazão sob uma restrição de 150 TPS em comparação com sua própria build day-0, com o pull request mesclado por trás de cada otimização listado. Os números e seus limites estão na seção de velocidade acima. O que não existe é uma replicação externa — cada número naquele post é o projeto medindo a si mesmo. O que o lançamento resolve é o empacotamento: 762 commits de 315 colaboradores, 104 deles de primeira contribuição, em uma versão com tag, e não em uma imagem de prévia. A própria aritmética da receita do vLLM ainda coloca o mínimo em cerca de 614 GB de VRAM para o checkpoint de 510 GB mais a margem — um nó de oito GPUs H200 ou uma bandeja GB200 NVL4 — e avisa que um contexto de 1M de tokens deve ser limitado na prática, em vez de presumido. Um cache KV mais estreito muda quanta memória o mecanismo em execução precisa, não o tamanho do checkpoint, então o piso de nó se mantém. O texto do SGLang acrescenta uma alavanca específica desta arquitetura: mover a tabela Engram para a memória do host com uma única flag de ambiente aumentou a capacidade do cache KV em cerca de 36% em um teste com quatro GB300, com vazão de decodificação e tempo até o primeiro token comparáveis, e seu replay limitado de SWA no lado do decoder elevou a vazão de prefill em 1,56× em oito H200s. Dois limites acompanham isso. A implementação de referência no repositório se descreve como um exemplo legível, e não como um mecanismo de serving de produção, e os runtimes de consumidor ficaram para trás: o caminho de quantização que colocaria isso em um laptop ou em um Mac Studio não estava aberto no lançamento. A versão curta é que os pesos são genuinamente abertos e a stack de serving genuinamente existe — em hardware contado em nós, e não em GPUs, que é o motivo honesto pelo qual uma licença permissiva não significa automaticamente uma build local. O repositório 1017 não muda nada nesse piso — o checkpoint é o mesmo de 510 GB nos mesmos 48 shards, e as notas de runtime que o acompanham são as publicadas para os pesos de setembro.

O que os pesos abertos não oferecem, por si só, é um sinal de qualidade — mas essa lacuna agora se fechou em parte, e se fechou ainda mais em 18 de outubro. Existem agora quatro instrumentos independentes, um deles executado duas vezes: o Intelligence Index da Artificial Analysis, que pontua o checkpoint de setembro em 39 e o checkpoint 1017 em 45; o estudo Exploit Bench acima, um benchmark de cibersegurança executado sob sete harnesses de agentes; o quadro de kernels da comunidade na seção abaixo; e, desde 14 de outubro, os próprios resultados AA-AgentPerf da Artificial Analysis para este modelo, que medem o hardware em que ele é servido, e não quão bom ele é. O antes e depois de 7 de outubro do projeto vLLM, acima, mede ainda outra coisa — quanto custa servir o modelo, e não quão bom ele é — e é o próprio relato do runtime sobre si mesmo. Nenhum é uma pontuação de raciocínio do tipo que o ARC Prize está construindo, três dos quatro ainda descrevem o checkpoint de setembro, e, para a maioria das linhas específicas deste artigo, o model card continua sendo a única fonte — mas o composto não pertence mais a essa lista: o 45, e o 33,8 abaixo dele, foram produzidos com os pesos que a DeepSeek serve hoje. Isso não é uma acusação; é o estado das evidências, e é por isso que este artigo mantém os dois tipos de número separados. Pesos abertos de fato significam que o modelo não ficará confinado ao endpoint da DeepSeek, o que importa para qualquer pessoa cujo bloqueio era residência de dados, e não preço.

Como adotá-lo sem arriscar a produção nele

Uma coisa mudou do nosso lado desde o lançamento, e isso torna esta seção mais simples do que teria sido na semana passada: o DeepSeek V4.1 Flash está no OrcaRouter agora. Ele responde ao id de modelo deepseek/deepseek-v4.1-flash pelo mesmo endpoint compatível com OpenAI que o restante da linha, com a tarifa da própria DeepSeek — US$ 0,15 por 1M de tokens de entrada, US$ 0,60 por 1M de saída e US$ 0,003 por 1M de leituras de cache nas tarifas fora do horário de pico, dobrando dentro das janelas de pico nos dias úteis — repassada com 0% de margem. Vale detalhar esse último ponto: o valor que você paga é o valor do provedor, e não um preço de revenda, então um corte de preço do fornecedor entra em vigor aqui no mesmo dia, em vez de só quando um contrato for renegociado. O DeepSeek V4 Flash e o DeepSeek V4 Pro usam a mesma chave, o que torna a migração abaixo uma mudança de roteamento, e não uma migração de plataforma. O checkpoint de 17 de outubro não muda nada disso: a DeepSeek manteve tanto o nome do modelo na API quanto a tabela de preços, então a atualização não altera nem o id nem o preço deste lado, que é como um repasse se parece quando um fornecedor atualiza um modelo sem mexer em nenhum dos dois.

Esse também é o argumento para não apressar a migração. O redirecionamento de 14 de setembro teria sido um fornecedor mudando o significado de um ID de modelo por baixo dos panos, se a DeepSeek não o tivesse cancelado sob pressão, e o episódio é o lembrete recente mais claro de que uma string de modelo é um contrato que um provedor pode reescrever — o que também é o enquadramento certo para a conversa sobre o line-up acima, já que uma família de três camadas é um plano e esta já mudou uma vez. Para um modelo cujas únicas pontuações externas até agora são um índice composto, uma tabela de cibersegurança ruidosa e um quadro de kernel da comunidade — e que não tem nenhum histórico em produção —, o formato mais seguro é aquele para o qual um roteador foi feito: enviar uma fatia do tráfego com formato de produção para o novo modelo, manter um modelo comprovado por trás dele como failover automático, para que uma regressão de qualidade custe uma nova tentativa em vez de um incidente, e deixar o DSL de roteamento decidir quais chamadas valem o modelo não comprovado e quais devem permanecer no modelo de trabalho confiável. A migração para o V4.1 Flash provavelmente é o destino certo. Não é uma migração para executar no anúncio.

A screenshot of the OrcaRouter model page for deepseek/deepseek-v4-flash (captured September 5, 2026) showing the Tools, JSON and Reasoning badges, a 1M-token context, 384K max output, text input, a p50 time-to-first-token of 434 ms, and the description 'DeepSeek V4 Flash efficient MoE — 284B total / 13B active params, 1M context, optimized for fast everyday workloads.'

Perguntas em aberto

• Benchmarks independentes — a contagem passou de zero para quatro instrumentos, e nenhum deles mede o raciocínio do modelo como o ARC Prize pretende. A pontuação de 39 do Artificial Analysis é um compósito de dez avaliações com esforço máximo de raciocínio, e seu 45 — publicado em 18 de outubro — é o mesmo compósito aplicado aos pesos mais novos. O estudo Exploit Bench acima é uma pontuação de ciberexploração dentro de um orçamento fixo de tokens, e classifica o DeepSeek V4.1 Flash abaixo do GLM-5.3-Flash. O quadro comunitário de kernels em kernelbench.com é uma tabela de engenharia de kernels. Os resultados AA-AgentPerf do Artificial Analysis, publicados em 14 de outubro, são uma tabela de hardware: quantos tokens por segundo por megawatt cada sistema de acelerador entrega este modelo, e nada sobre qualidade. Ninguém replicou as linhas individuais de benchmark da DeepSeek, e nenhuma medição independente com configurações de esforço de produção, ou no extremo de uma janela de 1M de tokens, foi publicada. O checkpoint de 17 de outubro não está mais sem medição: em 18 de outubro o Artificial Analysis adicionou uma linha 1017 com 45 no seu índice e 33,8 no Terminal-Bench 4.0, e o número do bench fica oito e meio pontos abaixo do que a tabela do fornecedor alega para os mesmos pesos. O que falta agora é uma segunda opinião sobre esse número — um avaliador, um harness, uma execução — e qualquer pontuação independente, seja qual for, para as quatro medições anteriores à troca. A única avaliação criada para responder à pergunta do raciocínio ainda está em construção — o ARC Prize tem um perfil do DeepSeek V4.1 Flash em seu harness de benchmarking em um pull request aberto, sem nenhum resultado anexado — e o ARC-AGI nunca pontuou este checkpoint: os 61,4% no ARC-AGI-2 que a chegada do adaptador reavivou pertencem ao DeepSeek V4 Flash 0731, o modelo que o V4.1 Flash aposenta. O número mais recente atribuído a este modelo, o 77,0 no DeepSWE v1.1, é a linha com a fonte mais fraca da matéria: é o gráfico da própria DeepSeek, lido de uma imagem anexada ao anúncio do fornecedor, e não existe nenhuma execução externa do DeepSWE v1.1 no checkpoint 1017 — o resultado do Artificial Analysis de 18 de outubro é para os mesmos pesos, mas para um benchmark diferente. Os dois quadros independentes que publicam o benchmark colocam o nome deste modelo em 71,7% e 74,2%, o que basta para colocá-lo ao lado do Opus 5 e não basta para confirmar o número do fornecedor — e nenhum dos dois diz qual checkpoint mediu.

• Auto-hospedagem abaixo do piso de nó — o suporte no dia zero do vLLM tornou-se um lançamento estável em 22 de setembro com a v0.30.0, que adiciona um caminho KV MXFP8 e offload assíncrono do Engram; o suporte no dia zero do SGLang ainda é distribuído como uma imagem de pré-visualização. Nenhum dos dois move o piso de hardware, que fica em torno de um nó de oito GPUs porque é o checkpoint de 510 GB que o define — e as próprias notas de implantação da DeepSeek, publicadas com o DeepInfer, deixam isso ainda mais claro: um nó de prefill ao lado de um nó de decode é implantável, mas a configuração de decode recomendada é paralelismo de especialistas de 64 ou superior, o que faz a menor unidade eficiente ser 64 GPUs de prefill ao lado de 64 de decode. A publicação de 7 de outubro do projeto vLLM é o registro mais completo de otimizações medidas publicado sobre este modelo — 1,9× em baixa concorrência e 5,3× sob uma restrição de 150 TPS em comparação com sua própria build do dia zero, juntamente com os números do SGLang acima — e seu texto de acompanhamento de 17 de outubro acrescenta uma curva de tokens por dólar que abrange configurações H100, MI300X e B200 ao lado dos componentes de escala de rack. Ambos são a contabilização feita pelo próprio projeto do seu próprio runtime. Nenhum dos dois move o piso: um token mais barato em uma GB300 ou uma H100 ainda não encaixa um checkpoint de 510 GB em um desktop, então é um caminho mais rápido para o mesmo piso, e não um piso mais baixo. Se lançamentos posteriores e quantizações da comunidade trarão isso para máquinas menores é a questão em aberto para quem quer os pesos em vez do endpoint, e é ela que decide se uma licença permissiva é uma licença prática.

• O que é o V4.1 Pro — A DeepSeek o designa como sucessor do V4 Pro, mas não publicou data, especificação nem preço, e o redirecionamento anunciado do tráfego existente do Pro para um modelo de nível Flash foi revogado antes de entrar em vigor. O que fica acima do Flash é descrito pela empresa apenas como a arquitetura que escala para modelos maiores; a hierarquia Flash, Pro e Ultra e seus tamanhos 522B, 2T e 8T são especulação de um observador, não da DeepSeek.

• Custo por tarefa — o Artificial Analysis agora traz um valor por tarefa para ambos os checkpoints: US$ 0,49 por tarefa do Intelligence Index para os pesos de setembro, reexpresso a partir dos US$ 0,27 que este texto trouxe inicialmente, e US$ 0,26 para o 1017. Essa é a primeira evidência externa para qualquer parte da alegação de Pareto da DeepSeek, e é mais estreita que a alegação. As mesmas linhas mostram o checkpoint 1017 gerando 210 milhões de tokens de saída no índice contra 250 milhões para setembro — saídas mais curtas no agregado —, mas 89.495 tokens de saída por tarefa contra 88.574, o que não é mais curto de forma alguma, e 288,8 segundos por tarefa contra 289,9, o que não é mais rápido. O detalhamento de custos do próprio site atribui toda a economia ao lado da entrada: a linha de saída fica estável, US$ 0,106 por tarefa contra US$ 0,107, enquanto a entrada cai de US$ 0,379 para US$ 0,155 e as gravações de cache, de US$ 0,322 para US$ 0,095. Se uma tarefa é concluída com menos dólares depende de quantos tokens ela consome, e isso é uma propriedade da carga de trabalho, não da tabela de preços. O relato da própria DeepSeek sobre a atualização aponta na direção oposta: o changelog afirma que o novo checkpoint reduz o tempo de execução da tarefa e o comprimento da saída, e sua publicação de 17 de outubro repete isso como “conclusão mais rápida de tarefas e saídas mais curtas”. Nenhum dos dois traz um número, e a medição externa por trás deste item agora os confrontou: nas duas grandezas que a DeepSeek nomeou, os pesos 1017 variaram cerca de um por cento, em direções opostas, a partir de um ponto de partida de cinco semanas antes. Um terceiro número fica do outro lado do mesmo balanço: o gráfico de 17 de outubro do projeto vLLM coloca o modelo em 1,3 bilhão de tokens por dólar de custo total de propriedade no SemiAnalysis AgentX, em uma faixa de custo que pressupõe volume de grandes hyperscalers. Serviço mais barato também não resolve este item — um custo menor por token deixa o número de tokens por tarefa, que é pelo que um chamador realmente paga, exatamente onde a medição de setembro o encontrou.

• Verificação descontrolada — testadores práticos relatam loops de repetição ocasionais na cadeia de pensamento e deliberações de doze minutos e com centenas de milhares de tokens sobre problemas que se resolvem em segundos com uma configuração de esforço menor. Nenhum benchmark independente mede com que frequência qualquer um dos dois casos ocorre nem quanto custa em produção, e a mitigação relatada até agora são limites de tokens do lado do cliente, e não algo que o modelo faça por si mesmo. O estudo Exploit Bench acima documenta o mesmo modo de falha pela direção oposta: o loop de relatórios repetidos que ele mostra nas transcrições do ReAct é produzido pelo prompt de compactação do harness, e não pelo raciocínio do próprio modelo, o que serve de lembrete de que um loop numa transcrição não é automaticamente um defeito do modelo.

• Engenharia de kernel — o placar comunitário de kernels CUDA do kernelbench.com (RTX PRO 6000, escalonado por roofline) tem o DeepSeek V4.1 Flash a 50,19% do roofline equivalente denso em seu próprio kernel de atenção esparsa, quarto lugar no geral, contra 4,45% do GLM-5.3 Flash na mesma linha. O placar é gerido pela comunidade e não passa por revisão por pares; nenhuma segunda geração de GPU nem replicação foi publicada.

• Contexto longo na extremidade distante — a atenção esparsa foi treinada em 64K e estendida para 1M na marca de 34T tokens. Como a qualidade se mantém perto do final de uma janela completa de 1M é precisamente o que uma avaliação independente de contexto longo resolveria.

• Reconstrução de cache nas bordas — o SWA Bounded Replay reconstrói aproximadamente, e não exatamente, o estado descartado da janela deslizante, e a DeepSeek diz que o resultado pode variar dependendo de onde um acerto de cache ocorre em uma sessão. O relatório observa pouco impacto observado na qualidade; condições extremas ou não testadas são exatamente onde uma aproximação como essa apareceria, e ninguém fora da DeepSeek examinou.

• Se as cargas de trabalho Pro realmente migram — o redirecionamento forçado foi retirado, então nada migra a menos que uma equipe escolha migrar, e as equipes que pagaram preços Pro por profundidade de raciocínio são as mais propensas a notar uma diferença de capacidade em trabalhos no formato do Terminal-Bench 3.0, nos quais o V4.1 Flash fica atrás do Opus-5.0 por uma ampla margem.

• Os termos e o comportamento do nível gratuito — a OpenCode adicionou uma entrada sem custo para este modelo em 15 de outubro, com uma janela de 200.000 tokens e um teto de saída de 32.000 tokens, descrita nas suas próprias páginas como disponível por tempo limitado. Se o arranjo sobreviverá a essa frase, como o endpoint se comporta sob carga e se a DeepSeek tem alguma palavra a dizer sobre isso são questões todas não respondidas: a própria lista de modelos, a documentação e a tabela de preços da plataforma são a única fonte, não há data de fim a que se possa exigir responsabilidades e ninguém publicou uma medição da rota gratuita.

• Segurança e recusas — a DeepSeek não publica taxa de recusa, resultado de red team ou avaliação de segurança para nenhum dos checkpoints, e nenhum laboratório independente avaliou este modelo em um benchmark de jailbreak. Os números deste texto vêm de pessoas que criam derivados sem censura — 97 de 100 prompts prejudiciais recusados no modo chat, 98 no modo think, em um único conjunto de prompts e com um único avaliador — e de uma única captura de tela de sessão de agente em que o modelo recusou uma persona em modo jailbreak. Se esse comportamento se mantém com baixo esforço de raciocínio, em idiomas diferentes do inglês, contra ataques automatizados em vez de um prompt de persona e sob uma harness que reescreve o prompt de sistema, não foi medido por ninguém.

• A documentação do próximo checkpoint — o relatório de 22 de outubro resolve a questão do registro para pesos que já são públicos, porque o catálogo preliminar exclui tecnologia que já está em domínio público. Ele não resolve o lançamento seguinte. O catálogo é um projeto aberto para comentários até 15 de novembro, seus limites são informados em vez de publicados no texto, e o dever provisório de registro que se diz ter entrado em vigor em 16 de outubro não foi publicado na íntegra. O próprio V4.1F-1017 já está disponível, com licença MIT e sem restrições de acesso; o que um futuro checkpoint da DeepSeek precisa cumprir antes de poder ser baixado é uma regra que ainda não existe.

O beta foi uma questão de dois dias sobre se um modelo de nível Flash poderia assumir a função Pro. O lançamento é a DeepSeek respondendo a isso com uma tabela de preços e um plano de roteamento — e então retirando o plano de roteamento em dois dias, quando desenvolvedores objetaram a ter um modelo de produção trocado sob seus pés. Essa é uma afirmação mais fraca do que o anúncio sugeria e mais honesta: a evidência de qualidade para a mudança são os próprios benchmarks da DeepSeek mais medições externas que, em sua maioria, apontam na mesma direção. A mais recente delas, um benchmark de cibersegurança executado sob sete harnesses de agentes, aponta na direção oposta na única comparação que faz, e a empresa deixou a escolha com seus clientes em vez de fazê-la por eles. Desde o lançamento, os pesos passaram de uma promessa a um download de 510 GB, o modelo passou de um endpoint do fornecedor a algo para o qual você pode rotear, e a pilha de serving passou de uma receita de dia zero a uma medida — o vLLM relatando ser 1,9× mais rápido em baixa concorrência três semanas depois, e então publicando, no dia em que o checkpoint mudou, uma curva de custo que precifica o modelo em 1,3 bilhão de tokens por dólar de custo total de propriedade no SemiAnalysis AgentX. Esta semana, a camada sob tudo isso também se abriu: a DeepSeek publicou o DeepInfer, o motor que seu próprio serviço executa, com uma curva de decodificação para este checkpoint, os números de produção por trás dessa curva, e um benchmark não publicado de setembro que coloca o 950DT da Huawei cinco a sete vezes atrás da NVIDIA por chip na velocidade à qual a DeepSeek realmente serve. Cinco semanas depois, o próprio checkpoint mudou uma vez: 17 de outubro trouxe novos pesos sob o mesmo nome e o mesmo preço, com uma tabela do fornecedor que é melhor em todas as linhas que publica e um harness diferente sob uma delas. Dois dias depois, chegou a medição externa, e é o número mais útil deste texto: a Artificial Analysis colocou os pesos de 1017 em 45 em seu índice — empatado com o GLM-5.3 para o segundo lugar entre modelos de pesos abertos, um ponto atrás do MiMo-V2.6-Pro — e 33,8 no Terminal-Bench 4.0, contra 42,3 do fornecedor no mesmo benchmark — então o harness que favorece o modelo na própria tabela da DeepSeek não é o harness no qual o número sobrevive. Se você está escolhendo hoje, a posição honesta é que o V4.1 Flash parece o melhor valor da linha DeepSeek, tem quatro instrumentos independentes em seu nome — nenhum deles uma pontuação de raciocínio, um deles agora executado contra o checkpoint que a DeepSeek serve desde 17 de outubro — uma quinta avaliação em construção, nenhum histórico de produção, uma pilha de serving cujos dois números mais fortes — um delta de velocidade e uma curva de custo — vêm ambos do projeto que escreveu o runtime, e um resultado externo de cibersegurança que já discorda de si mesmo dependendo de qual harness você envolve o modelo, um nível gratuito de 200.000 tokens que apareceu em uma plataforma em 15 de outubro, e uma primeira rodada de relatos práticos descrevendo um modelo que verifica seu próprio trabalho mais do que a maioria dos chamadores pedirá — o que é um motivo para direcionar uma fatia do tráfego a ele, não um motivo para migrar por causa do anúncio. A atualização que a DeepSeek anunciou em 17 de outubro muda os pesos e acrescenta uma alegação do fornecedor — conclusão mais rápida de tarefas, saídas mais curtas — e a primeira medição externa desses pesos sustenta, no máximo, metade dela: custo por tarefa do índice cortado em 46%, enquanto o tempo por tarefa e os tokens de saída por tarefa mal se moveram. Um dia depois, a alegação mais lida sobre esse checkpoint era de um executivo: 77 no DeepSWE v1.1 com custo 83× menor, vinda de um funcionário da Databricks que também diz que o checkpoint está chegando a essa plataforma. Metade dela sobrevive ao contato com os rankings independentes, que agora colocam o nome deste modelo acima do Opus 5 nesse benchmark. A outra metade ainda não: o 77 é a própria linha da DeepSeek, não reproduzida, e o 83× é aritmética sem nenhum custo por tarefa publicado por trás dela. A própria documentação da Databricks confirma que o modelo está em sua plataforma e que os dois modelos DeepSeek abaixo dele estão programados para sair; ela não confirma que o checkpoint está chegando. Essa alegação agora é a segunda mais interessante sobre o checkpoint, e não a mais. Em 19 de outubro, uma conta de rastreamento que já acertou várias dessas versões antecipadamente declarou-se “absolutamente certa” dos 42,3 no Terminal-Bench 4.0, com base no fato de que supera o GLM-5.3, e pediu à Artificial Analysis que executasse o modelo em um harness nativo. O site já havia feito isso. Em seu próprio harness, os mesmos pesos marcam 33,8 — abaixo dos 41,9 do GLM-5.3, não acima. A linha do fornecedor é real e é da DeepSeek; a inferência tirada dela não sobrevive quando outra pessoa a executa.

Se a versão que você quer é a que mantém suas opções em aberto, os três estão a uma chave de distância e com os preços das próprias tarifas da DeepSeek, com 0% de margem adicionada. O lançamento em si: DeepSeek V4.1 Flash on OrcaRouter — contexto de 1M de tokens, teto de saída de 384K, entrada de imagem, a US$ 0,15 por 1M de entrada e US$ 0,60 por 1M de saída fora de pico. O modelo que ele aposenta: DeepSeek V4 Flash on OrcaRouter. E o carro-chefe que a DeepSeek decidiu continuar servindo: DeepSeek V4 Pro on OrcaRouter. Aponte uma fatia do tráfego para o novo, mantenha um modelo comprovado atrás dele como failover, e deixe o roteamento decidir.

A escolha de um modelo também é uma questão do que deu errado antes: os incidentes de IA documentados e as falhas de agentes para modelos dessa classe estão reunidos no OrcaRouter AI Incident Archive, onde cada entrada traz suas próprias fontes, gravidade, grau de confiança e sinalizador de disputa.

Comparados neste artigo4

Detectado a partir deste artigo · Benchmarks: Artificial Analysis · atualizado diariamente