Como testar o DeepSeek V4.1 Flash contra o modelo que você já usa antes de trocar

Fala aí, beleza? A DeepSeek soltou o V4.1 Flash e a timeline já decidiu por você: uns dizem que mata o modelo topo de linha, outros dizem que é hype

Só que trocar de modelo por causa de benchmark dos outros não é decisão, é aposta

O lançamento oficial foi em 10 de setembro de 2026, com o anúncio "Introducing DeepSeek-V4.1-Flash: smarter, faster, more efficient" publicado no site e na documentação da API

E tem um detalhe que deixa isso urgente: a partir das 04:00 UTC de 14 de setembro de 2026, todas as requisições para deepseek-v4-pro passam a ser roteadas para o V4.1-Flash e cobradas no preço do V4.1-Flash, até o V4.1-Pro sair

Ou seja, tem gente que vai "trocar de modelo" sem nem clicar em nada haha

Então bora fazer o que quase ninguém faz antes de migrar: montar uma bateria caseira de 20 a 50 casos reais do SEU projeto e decidir por evidência, não por print de gráfico

O que você precisa antes de rodar o teste

Nada de PC da Nasa aqui, a lista é curta:

• Conta na DeepSeek, uma chave de API e algum crédito na conta (pode ser pouco, é só pra rodar a bateria)
• O SDK oficial da OpenAI instalado, porque a API da DeepSeek é compatível com o formato da OpenAI: você só aponta a base_url para https://api.deepseek.com
• O nome do modelo atual na API: deepseek-flash
• Acesso ao modelo que você já usa hoje, com a mesma facilidade de chamar por script
• Uma planilha ou um CSV pra registrar resultado, custo, latência e horário de cada caso

A planilha é o item mais importante da lista, por incrível que pareça 🙂

Sem ela, o teste vira "achei que respondeu melhor", e achismo não decide migração

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 116 aulas
• 4 projetos
• 9h 23min

Conhecer formação

Dois avisos que evitam dor de cabeça na hora de configurar

Os modelos legados deepseek-chat e deepseek-reasoner foram totalmente aposentados e ficaram inacessíveis depois de 24 de julho de 2026, então tutorial antigo que usa esses nomes vai quebrar na sua mão

E os nomes deepseek-v4-flash e deepseek-v4-flash-vision-exp foram aposentados também, com roteamento temporário para o V4.1-Flash por compatibilidade

Tome cuidado com isso na hora de anotar na planilha: se você chamou um nome antigo, o que respondeu foi o V4.1-Flash, e não o modelo que está escrito no seu script

Do outro lado da comparação, garanta que você sabe exatamente qual modelo está no seu setup atual: se for Claude, vale conferir qual versão do Sonnet você usa antes de anotar qualquer resultado

Se o seu concorrente interno for o Google, a mesma lógica vale pra saber onde usar o Gemini 3.7 Flash e por qual canal você está batendo nele

Que outras portas existem? Duas

O V4.1 Flash também está disponível via OpenRouter, pra quem prefere centralizar as chamadas em um lugar só

E os pesos foram publicados no Hugging Face sob licença MIT, pra quem quiser rodar local

É um Mixture-of-Experts multimodal com 552 bilhões de parâmetros no backbone e contexto de até 1 milhão de tokens, então "rodar local" aqui não é next, next e finish, combinado? 😀

Passo a passo para montar sua bateria de avaliação

O objetivo não é medir inteligência abstrata, é medir se o modelo resolve o que VOCÊ pede, no seu código, no seu domínio

1. Garimpe de 20 a 50 casos reais do seu histórico. Vá no seu backlog, nas issues fechadas, nos prompts que você já rodou mês passado, e separe tarefas que você já sabe como deveriam terminar. Caso real é aquele que tem gabarito, porque você já viveu o resultado. O erro comum deste passo: escolher só os casos fáceis, aqueles que qualquer modelo acerta. Bateria fácil dá empate técnico e empate técnico não decide nada

2. Escreva o critério de acerto de cada caso ANTES de rodar. Critério bom é binário: compila, passa no teste X, o JSON contém o campo user_id, a função devolve o mesmo resultado do gabarito. O erro comum deste passo: julgar no olho depois que a resposta chegou. Aí você já viu a saída bonita e seu cérebro inventa um critério que ela cumpre

3. Congele o prompt e os parâmetros para os dois modelos. Mesmo texto, mesma temperatura, mesmo formato de saída pedido. O erro comum deste passo: melhorar o prompt no meio da rodada. Você acaba comparando prompt A no modelo antigo com prompt B no modelo novo, e a conclusão vai pro lixo

4. Monte o script de execução salvando a saída crua em arquivo. Instale o SDK e aponte a base_url:

pip3 install openai

import json, time, pathlib
from openai import OpenAI

client = OpenAI(
    api_key="SUA_CHAVE_DEEPSEEK",
    base_url="https://api.deepseek.com",
)

casos = [json.loads(l) for l in open("casos.jsonl", encoding="utf-8")]
pathlib.Path("saidas").mkdir(exist_ok=True)

for caso in casos:
    inicio = time.time()
    resp = client.chat.completions.create(
        model="deepseek-flash",
        messages=[{"role": "user", "content": caso["prompt"]}],
        temperature=0,
    )
    registro = {
        "id": caso["id"],
        "modelo": "deepseek-flash",
        "latencia_s": round(time.time() - inicio, 2),
        "usage": resp.usage.model_dump(),
        "saida": resp.choices[0].message.content,
    }
    with open(f"saidas/{caso['id']}-deepseek-flash.json", "w", encoding="utf-8") as f:
        json.dump(registro, f, ensure_ascii=False, indent=2)

O erro comum deste passo: não salvar a resposta crua e guardar só o seu veredito na planilha. Quando alguém questionar o resultado (e vai questionar), você precisa do texto original pra reabrir o caso

5. Rode o mesmo script no seu modelo atual trocando só base_url e model. Nada de reescrever a lógica, nada de mudar o parser de saída. O erro comum deste passo: comparar rodadas de dias diferentes, cada uma com uma versão de modelo, um humor de servidor e um prompt levemente ajustado

6. Meça custo e latência por caso e anote o horário UTC da rodada. A tabela oficial fora de pico é essa:

Em yuan, os valores oficiais fora de pico são RMB 0,02 na entrada com cache hit, RMB 1 na entrada sem cache e RMB 4 na saída

Os preços em horário de pico são o dobro dos preços fora de pico, e o pico vai das 01:00 às 04:00 e das 06:00 às 10:00 UTC, de segunda a sexta

Essa tabela entrou em vigor às 04:00 UTC de 10 de setembro de 2026

O erro comum deste passo: rodar o DeepSeek fora de pico, rodar o concorrente em outro momento e comparar as duas contas como se fossem a mesma régua

7. Considere o cache de contexto na hora de ler a conta. O Context Caching on Disk é ligado por padrão para todos os usuários e não exige mudança de código nem de interface, e a cobrança é por cache hit real. A unidade mínima é de 64 tokens: conteúdo menor que isso não é cacheado, e o serviço funciona em regime de melhor esforço, sem garantia de 100% de acerto. O erro comum deste passo: montar a projeção de custo mensal usando o preço de cache hit como se ele valesse pra toda entrada. Não vale

8. Conte acertos, empates e erros e defina o corte de decisão antes de olhar o placar. Escreva na planilha, antes da apuração, algo como: "só migro se o novo empatar ou ganhar na grande maioria dos casos e custar menos por caso resolvido". O erro comum deste passo: olhar o resultado primeiro e escolher o corte depois, que é o jeito clássico de provar o que você já queria acreditar

9. Repita os casos que empataram. Saída de modelo varia entre execuções, então empate com uma rodada só é chute com cara de dado. Rode o empate de novo, no mesmo horário, e veja se o padrão se mantém

Usa Claude Code? A DeepSeek mantém uma página própria de integração na documentação oficial, e a configuração é por variável de ambiente:

export ANTHROPIC_BASE_URL=https://api.deepseek.com/anthropic
export ANTHROPIC_AUTH_TOKEN=SUA_CHAVE_DEEPSEEK
export ANTHROPIC_MODEL=deepseek-flash

No Windows, a mesma ideia em PowerShell, com as três variáveis:

$env:ANTHROPIC_BASE_URL="https://api.deepseek.com/anthropic"
$env:ANTHROPIC_AUTH_TOKEN="SUA_CHAVE_DEEPSEEK"
$env:ANTHROPIC_MODEL="deepseek-flash"

E não para no Claude Code: a seção de integrações da documentação tem página pra Codex, OpenCode, GitHub Copilot e Deep Code também

O que aconteceu quando rodei isso no meu projeto

Aqui entra a parte que eu vivi de verdade, e ela serve pra uma coisa só: mostrar como se registra custo por tarefa sem se enganar

Antes de qualquer teste eu criei a chave de API e coloquei 2 dólares de crédito na conta, justamente pra testar sem compromisso

Deixei a página de usage aberta em paralelo o tempo todo, acompanhando quanto cada execução consumia

O teste foi um prompt único de projeto completo: um SaaS gerador de slogans, com stack padrão (Next, Tailwind, SQLite), autenticação, esquema de tabelas definido, lista de páginas e regras de negócio e de segurança

Li e aprovei o plano antes de deixar o agente executar, e acompanhei tempo de execução e consumo de tokens durante a criação, em vez de olhar só o resultado final

O prompt entregou quatro páginas: landing page, registro, login e dashboard

Depois de pronto eu não parei no código: subi a aplicação, criei conta, fiz login, caí na dashboard e gerei slogans de verdade, cinco por requisição, pra conferir se o fluxo inteiro funcionava

Veredito honesto: não é o projeto mais bonito do mundo, mas está funcional de ponta a ponta

E a conta? A execução que criou o projeto completo (landing page, autenticação, dashboard, integração com banco e com IA) ficou em aproximadamente 11 a 12 centavos de dólar

Só que essa leitura estava distorcida por dois motivos, e eu avisei isso no vídeo: já havia uma execução de teste anterior contabilizada na usage, que custou 3 centavos, e a própria aplicação gerada consome a MESMA chave de API quando gera slogans

Sacou por que a planilha importa? Se eu tivesse olhado só o total da usage, teria colocado no post um número que mistura três coisas diferentes

É exatamente esse o erro que a sua bateria precisa evitar: o valor absoluto da rodada importa muito menos que o custo por caso resolvido

Um modelo que custa metade e erra o dobro sai mais caro, porque você paga de novo no retrabalho

Veja a bateria rodando no vídeo

No vídeo abaixo eu mostro a configuração do backend, a execução real acontecendo e o custo aparecendo na página de usage enquanto o projeto é construído

Que tipos de caso colocar na sua bateria

Se todos os seus 30 casos forem "cria um CRUD", você mediu uma coisa só

Cubra as categorias que representam o seu uso real, cada uma com o critério de acerto correspondente:

• Geração de código do zero: critério de acerto = roda sem erro e passa nos testes que você já tinha
• Refatoração de arquivo existente: critério = comportamento idêntico ao anterior, com os testes verdes e sem sumir função nenhuma
• Leitura de contexto longo: o V4.1 Flash suporta contexto de até 1 milhão de tokens, então joga um arquivo grande de verdade e pede um dado que só existe no meio dele. Critério = achou o dado certo
• Tarefas com imagem: o modelo é multimodal nativo, processa imagem e texto na arquitetura base e responde em texto. Critério = extraiu do print exatamente o que você pediu
• Extração de dados estruturados: critério = JSON válido, com todos os campos obrigatórios preenchidos
• Tarefas repetitivas de alto volume: aquelas onde o mesmo prefixo de prompt se repete e o cache de contexto pesa na conta. Critério = acerto estável ao longo de N execuções, com custo por item dentro do seu limite

E uma coisa precisa ficar clara: a afirmação de que o V4.1-Flash superou o V4-Pro em desempenho, custo, velocidade e tempo total de execução, em testes internos e externos, é do próprio fabricante

Não é crítica, é só o que é: alegação de quem vende

Sua bateria existe justamente pra confirmar ou derrubar isso no seu caso, com os seus arquivos, na sua língua, no seu domínio 🙂

Conclusão

A decisão de trocar de modelo tem que sair da sua planilha, não do anúncio de ninguém, nem do meu post, nem do gráfico que viralizou ontem

O método é sempre o mesmo: 20 a 50 casos reais, critério de acerto escrito antes, prompt congelado, mesma janela de horário, saída crua salva e custo por caso resolvido anotado

Próximo passo concreto pra hoje: separa os primeiros 20 casos e roda a primeira comparação fora do horário de pico, antes de 14 de setembro de 2026, quando as requisições para deepseek-v4-pro passam a ser roteadas para o V4.1-Flash e cobradas no preço dele

Depois dessa data a sua base de comparação muda, e é bem melhor ter o "antes" registrado do que tentar reconstruir de memória

Começa pequeno, com 20 casos que você entende bem, e vai ampliando a bateria conforme o projeto cresce

Daqui a três meses, quando sair o próximo modelo que promete matar todos os outros, você já vai ter o teste pronto pra rodar em uma tarde

até o próximo post!