DeepSeek v4.1 Flash chega mais barato e supera o v4 Pro, segundo a empresa

A DeepSeek anunciou o lançamento do v4.1 Flash, marcado para 10 de setembro de 2026 (horário de Pequim). Segundo a própria empresa, o novo modelo "comprehensively surpassed V4 Pro across all key metrics, including performance, cost, speed, and task completion time", ou seja, ultrapassou o Pro anterior em todos os indicadores que importam para quem coloca um modelo em produção: desempenho, custo, velocidade e tempo de conclusão de tarefa.

A informação não veio de um post de blog nem de um paper. Como notou o usuário oefrha no thread do Hacker News, a origem é discreta: "Source is apparently a banner announcement on https://platform.deepseek.com/usage. Had me searching for a couple minutes...". Um banner no painel de uso da plataforma, não um comunicado formal.

O detalhe que chama atenção: o Pro vira Flash na fatura

O ponto mais incomum do anúncio é o que a DeepSeek fará entre o lançamento do Flash e a chegada do futuro v4.1 Pro. Segundo o comunicado:

In keeping with our commitment to user responsibility, following the official launch of V4.1 Flash and prior to the release of V4.1 Pro, all requests to the Pro model will be routed to V4.1 Flash and billed at Flash's price.

DeepSeek, via banner na plataforma

Na prática: quem chamar o endpoint do v4 Pro passa a ser atendido pelo v4.1 Flash e pagará o preço do Flash, que é mais barato. Para quem já tem código apontando para o Pro, isso significa modelo melhor e conta menor sem trocar uma linha de configuração, ainda que sem escolha de continuar no Pro antigo durante essa janela.

Esse gesto não passou despercebido. No thread, nicce reagiu ao trecho com ironia sobre os concorrentes americanos: "Wow. Imagine OpenAI/Google/Anthropic doing this! Nope." A comparação é a que o dev faz na hora de fechar orçamento: as grandes fornecedoras raramente rebaixam o preço de uma chamada automaticamente quando lançam algo melhor.

Os preços do Flash a partir de 10 de setembro

A DeepSeek também informou o ajuste na tabela da série Flash, válido a partir das 12h de Pequim de 10 de setembro de 2026. Os valores abaixo são para horário de baixa demanda (off-peak); em horário de pico, a empresa diz que os preços dobram.

A estrutura de cache importa para o bolso: chamadas repetidas que batem no cache de input custam US$ 0,003 por milhão de tokens, cinquenta vezes menos que um cache miss. Para aplicações com prompts de sistema longos e estáveis (agentes, RAG↳RAG6 conteúdosTécnica RAG com a biblioteca Langchain: tutorial para aplicar agoraData · jun 2024Como avaliar LLMs, RAG e Agentes de IA: Teoria e prática.AI · abr 2026RAG Não É Memória: O Problema Real dos Agentes de IAAI · mai 2026Ver tudo em AI → com contexto fixo, few-shot padronizado), a diferença entre reaproveitar o cache e não reaproveitar muda a ordem de grandeza da fatura mensal.

O modelo de preço variável por horário é outro ponto que exige atenção do lado de quem opera. Como o pico dobra o custo, cargas que podem ser agendadas (batch de embeddings, processamento assíncrono, jobs noturnos) ganham incentivo direto para rodar fora do horário de pico de Pequim, o que, para o Brasil, cai em janelas específicas do nosso dia por causa do fuso.

O que muda para quem constrói software no Brasil

O recorte prático é o custo de inferência. A escolha de modelo no Brasil raramente é sobre o topo absoluto de qualidade: é sobre a relação entre custo por token, latência e "bom o suficiente" para a tarefa. Um Flash que supera o Pro anterior por um preço menor mexe exatamente nessa conta, e pressiona a régua de preço que todos os fornecedores praticam.

A cadência é o que o mercado está observando. swiftcoder resumiu a expectativa da comunidade: "If they can keep up this cadence of Flash leap-frogging the previous Pro, we're in for a good time". Se cada geração Flash passa por cima do Pro anterior, o dev que padroniza no Flash tende a colher ganho de custo e capacidade a cada ciclo sem migração de código.

Mas há ressalvas que ainda estão em aberto, e vale registrá-las sem otimismo:

• A comunicação foi por banner, não por documentação. Sem paper ou changelog formal, as afirmações de superação "em todas as métricas" são declaração da empresa, não benchmark independente verificável.
• Acesso via API pode ser confuso no início. O usuário nickweb apontou, citando um post no X, que "the new model can be used if summoned via the API but the API won't list it", ou seja, o modelo funcionaria pela API mas não apareceria na listagem, o que complica automação e descoberta de modelos disponíveis.
• Pesos abertos não estão confirmados. No thread, tarruda torce para que "it will be open weights and have the same architecture and size as the current v4 flash vision, which is probably the best LLM that can be run on 128G devices". Para quem pensa em rodar localmente (privacidade, custo fixo, ausência de dependência de API), a disponibilidade de pesos abertos é o que decide se o modelo entra ou não na stack self-hosted, e isso ainda não foi anunciado.

Para times brasileiros que já usam DeepSeek pela API, a recomendação de leitura é direta: rodar o próprio teste comparativo entre o v4 Pro e o v4.1 Flash na tarefa real da aplicação, medindo qualidade de saída, latência e custo por chamada nos horários que a operação de fato usa. A própria empresa pede esse feedback no comunicado, dizendo para reportar qualquer problema encontrado no teste comparativo. Como sempre, número de benchmark do fornecedor é ponto de partida, não veredito.

Fonte: Hacker News