DeepSeek V4 Pro GA vs Preview: 18-62% menos raciocínio

A versão GA do DeepSeek V4 Pro usa de 18% a 62% menos tokens de raciocínio do que a preview nas mesmas tarefas. Ela também corrige uma falha capaz de consumir toda a janela de saída de 8,192 tokens e é a primeira versão Pro em que desativar o raciocínio torna confiável a extração com JSON estrito. Em contrapartida, perdeu a capacidade da preview de responder que não sabe. Comparamos o deepseek-v4-pro-0813 com a versão preview no mesmo lote, quatro dias após o GA. Consideramos apenas a contagem de tokens, pois a DeepSeek alterou os preços do V4 e adotou tarifas de pico e fora de pico no dia anterior à medição. Comparar valores em dólares entre duas tabelas de preços em mudança diria menos do que os tokens. A DeepSeek lançou a versão GA sem post no blog, changelog ou comunicado à imprensa, então a única forma de saber o que mudou é medir.

TL;DR

• A versão GA usa de 18% a 62% menos tokens de raciocínio por tarefa: 18 contra 48 em uma consulta simples.
• O raciocínio corrompe valores em JSON estrito nas duas versões (2/8 corretos); a única configuração sem erros que encontramos foi GA com raciocínio desativado (8/8).
• A versão GA corrigiu uma falha da preview: thinking_budget: 16 preencheu a janela de saída de 8,192 tokens em 5 de 9 execuções na preview; na GA, 0 de 9.
• A versão GA perdeu a recusa clara: diante de entidades inventadas, a preview recusa em 100 a 150 tokens; a GA não retorna nada ou inventa uma resposta.

Quanto menos a versão GA raciocina?

De 18% a 62% menos, com a maior diferença em tarefas simples. Estas são as medianas de tokens de raciocínio e do total da resposta para nossas quatro tarefas padrão, com três execuções e variações de entrada em cada uma:

A precisão ficou em 3/3 nas duas versões para todas as tarefas. Portanto, trata-se de um ganho direto de eficiência, não de uma troca por qualidade. Para planejar capacidade, considere esta tendência: quanto mais profunda a tarefa, menor a economia. A redução cai de 62% em uma consulta de uma etapa para 18% em uma cadeia de cinco etapas. Independentemente do custo de cada versão, esse é o formato da diferença. A extração estruturada é onde o ganho mais aparece: sob um json_schema estrito, o consumo cai de 159 para 40 tokens de raciocínio, uma redução de 4x.

O cache funciona da mesma forma nas duas versões: ambas armazenaram 4,096 tokens de um prefixo com 5,000 tokens e serviram o hit 4 segundos após a chamada de aquecimento. O que está mudando agora são as tarifas, não o mecanismo. A DeepSeek aumentou os preços da família V4 e adotou cobrança de pico e fora de pico, com tarifa reduzida à metade fora do pico, a partir de 2026-08-16 16:00 UTC. Consulte a tabela vigente de cada versão e o horário de execução antes de converter estas contagens de tokens em dólares.

A versão GA corrigiu algo mensurável?

Sim, e trata-se da falha mais cara dessa família. Enviar thinking_budget: 16 para a preview faz o modelo perder o fio da resposta. Em vez de raciocinar brevemente e responder, ele entra em um loop de repetição (“I’ll output: 168. I’ll output: 168…”) até esgotar max_tokens. Em nove execuções da mesma tarefa de cinco etapas, a preview preencheu toda a janela de 8,192 tokens cinco vezes. A GA não fez isso nenhuma vez e respondeu corretamente usando entre 79 e 130 tokens em todas as execuções.

O problema é justamente o custo da falha: uma requisição que deveria economizar ao limitar o raciocínio acaba cobrando 8,193 tokens de resposta, contra cerca de 130 em uma resposta normal. É uma conta de saída 63x maior por pedir ao modelo que raciocine menos. Um limite de 64 tokens também não foi seguro na preview, que retornou respostas erradas (183, 174) em 2 de 3 execuções. Se você ainda está preso à versão preview e controla custos com limites baixos de raciocínio, essa é a primeira combinação que deve abandonar.

Desativar o raciocínio é seguro neste caso, embora isso não valha para toda a família: o Flash 0731 caiu de 6/6 para 0/6 em aritmética de 2 etapas com o raciocínio desativado. Já as duas versões Pro mantiveram 3/3 em nossa cadeia de cinco etapas com thinking: {"type": "disabled"} ou enable_thinking: false. No Pro, desativar o recurso não reduz a precisão em tarefas de raciocínio e ainda corrige a extração estruturada, como mostramos abaixo.

O seletor continua sem efeito prático nas duas versões. reasoning_effort aceita low, medium, high, xhigh e max, mas rejeita none e minimal com um erro 400 que lista os valores válidos. Em nossa tarefa de cinco etapas, os níveis produziram entre 76 e 122 tokens de raciocínio na GA e entre 116 e 167 na preview, sem tendência monotônica. Como mostrou nossa matriz de controles entre fornecedores, a DeepSeek controla o raciocínio pelo desligamento e pelo limite, não pelo enum.

O raciocínio ainda corrompe JSON estrito?

Sim, nas duas versões. A GA é a primeira versão Pro com uma saída confiável. Identificamos essa falha no DeepSeek V4 Flash 0731: o JSON respeita o schema, mas os números estão errados. O problema continua no Pro. Pedimos às duas versões que extraíssem quatro campos de uma fatura com três linhas usando um json_schema estrito. Fizemos oito execuções por configuração e verificamos os valores, não apenas o schema:

Todas as respostas com falha são parseáveis, passam pelo schema e apresentam dados falsos. Embora o documento liste claramente três itens, a contagem retornada foi 45, 22, 2026, -4, -35 e -3864 em diferentes execuções. Uma resposta da preview informou um total de -139,308,173,307,904, e uma da GA inventou outra empresa (“MITRE”, total 1000). Para um validador, todos esses casos contêm JSON válido.

A recomendação operacional é simples. Na versão GA, desative o raciocínio para extração estruturada. A falha desapareceu em todas as nossas execuções. Essa configuração, por si só, é o argumento mais forte para sair da preview, que continuou errando em 6 de 8 execuções mesmo com o raciocínio desativado. O resultado segue o padrão da família que medimos no Flash, onde desativar o raciocínio também corrigiu todas as execuções. É mais um exemplo da zona segura para tarefas de uma etapa identificada em nossa matriz de controles de raciocínio: extração não precisa de deliberação e, nessa família, deliberar piora ativamente o resultado.

O que a versão GA perdeu?

A capacidade de dizer “não sei”. Perguntamos sobre cinco entidades inventadas: o preço das ações de uma empresa, o número de funcionários de um instituto, a carta de fundação de uma cidade, o ponto de fusão de uma liga e o vencedor de um prêmio. A preview recusa de forma clara em 100 a 150 tokens de saída: “I don’t have any information about a 1987 Pan-Continental Robotics Prize.” Já a GA apresenta um de dois comportamentos, e nenhum deles é útil:

Antes da publicação, repetimos o teste por um segundo caminho de requisição independente. Nele, a preview recusou as três perguntas avaliadas usando de 101 a 148 tokens. A GA consumiu 8,191 tokens e retornou uma resposta vazia em uma pergunta, respondeu com ressalvas em outra e afirmou um ponto de fusão específico (“2,314 degrees Celsius”) para uma liga inexistente na terceira. O cliente mudou, mas a assimetria permaneceu: o comportamento é do modelo.

Para pipelines de recuperação, a consequência prática é uma cobrança dupla: uma pergunta que o índice não consegue responder consome uma janela inteira de raciocínio oculto, e o resultado é vazio ou inventado, mas ainda assim aceito pelo validador. Se você encaminha perguntas sem resposta para esse modelo, defina max_tokens baixo o suficiente para que a falha fique visível e barata. Trate uma resposta vazia como cache miss, não como erro.

O que mais muda na troca?

Pouca coisa. A decisão de migrar depende mais do comportamento do que da integração. As duas versões aceitaram 279,000 tokens de entrada em uma única chamada e responderam a uma pergunta cuja informação estava no meio do contexto. Ambas usam o mesmo tokenizer da família: o mesmo corpus com inglês, chinês e código teve contagem idêntica na GA, na preview e no deepseek-v4-flash-0731. Os limites de tokens podem ser transferidos entre os modelos da família sem ajustes. As duas aceitam temperature, top_p e top_k silenciosamente, além de um turno de assistant preenchido previamente, recurso que a DeepSeek documenta como conclusão por prefixo.

O cache é idêntico até na granularidade: nenhuma das versões armazenou um prefixo de 512 tokens, e ambas usaram páginas exatas de 1,024 tokens acima disso (1,024, 2,048, 4,096). Os hits foram servidos 4 segundos após a chamada de aquecimento, com o mesmo tamanho de página usado pelo Flash. Há mais uma questão de custo a encerrar: ambas retornam toda a cadeia de raciocínio em reasoning_content, e reutilizá-la no turno seguinte não tem custo. Um turno adicional cobrou os mesmos 134 tokens de entrada na GA (56 na preview), tanto com o raciocínio do turno anterior incluído quanto removido. Ao contrário de modelos que cobram novamente cada token de raciocínio mantido, essa família simplesmente o descarta.

No loop de ferramentas, o resultado fica empatado. Em um agente com duas funções, uma para consultar um incidente e outra para reiniciar o serviço indicado, a GA deliberou mais na primeira etapa (48 contra 34 tokens de raciocínio) e menos na segunda (18 contra 35). As duas versões escolheram a ferramenta correta em 3/3 execuções. Como a DeepSeek posiciona esta versão para cargas de agentes, o raciocínio por etapa fica mais próximo de um empate do que sugerem os números gerais de eficiência. Para um agente que encontra becos sem saída, o comportamento de recusa descrito acima é mais relevante.

Perguntas frequentes

Quanto custa executar a versão GA em comparação com a preview?

Em tokens, ela usa de 18% a 62% menos raciocínio por tarefa e 4x menos sob um json_schema estrito. Para calcular em dólares, consulte a tabela atual. A DeepSeek alterou os preços da família V4 e adotou cobrança de pico e fora de pico, com tarifa reduzida à metade fora do pico, em 2026-08-16. Os mesmos tokens têm preços diferentes conforme a versão e o horário.

A versão GA economiza mais em tarefas simples ou complexas?

Simples. A redução no raciocínio é de 62% em uma consulta de uma etapa, cerca de 48% em um problema de 2 etapas e na extração de JSON, mas apenas 18% em uma cadeia aritmética de cinco etapas. As duas versões convergem em tarefas profundas e com várias etapas. A migração compensa mais em tráfego simples e de alto volume.

Ainda devo usar limites baixos de raciocínio no DeepSeek V4 Pro?

Não na versão preview. thinking_budget: 16 colocou o modelo em um loop de repetição que consumiu toda a janela de saída de 8,192 tokens em 5 de 9 execuções. Isso gerou uma conta de saída cerca de 63x maior para uma requisição que deveria ser barata; com 64 tokens, o modelo produziu respostas erradas. A GA processou o mesmo limite corretamente em 9 de 9 execuções. Portanto, limites baixos só são seguros na versão datada.

Posso confiar na saída JSON estrita do DeepSeek V4 Pro?

Somente com o raciocínio desativado e apenas na versão GA. Em oito execuções por configuração, respostas válidas segundo o schema continham números errados em 6 de 8 execuções com o raciocínio ativado nas duas versões. Para uma fatura de três itens, o modelo retornou contagens como 45, 2026 e -3864. A GA com thinking: {"type": "disabled"} produziu valores corretos em 8 de 8 execuções; a preview continuou errando em 6 de 8 mesmo sem raciocínio. Valide os valores, não apenas o schema.

O DeepSeek V4 Pro recusa perguntas que não consegue responder?

A versão preview recusa em 100 a 150 tokens. A GA, em geral, não. Diante de entidades inventadas, ela consome toda a janela de saída raciocinando e retorna uma mensagem vazia ou, com uma janela maior, apresenta uma resposta inventada com confiança. Valide as respostas com suas próprias fontes em vez de confiar na ausência de recusa. Trate respostas vazias como misses.

Medições realizadas em 2026-08-17 pelo gateway da Synthorai, quatro dias após o surgimento da versão GA. A preview foi executada novamente no mesmo lote em todas as comparações: matriz de seletor e desligamento (7 valores de esforço, 5 limites, 2 parâmetros de desligamento, n=3), varredura de raciocínio em quatro tarefas, saída estruturada com JSON estrito, loop de chamada de funções em dois turnos, teste com cinco entidades inventadas em dois tamanhos de janela, verificação da integridade de quatro valores em JSON estrito (n=8 por configuração), par de cobrança com reutilização do raciocínio, pares de cache implícito com dois tempos de espera e delimitação do piso do cache, aceitação de contexto com 279K tokens e uma informação-alvo, comparação do tokenizer com corpus fixo em toda a família V4 e testes de aceitação de sampling, prefill e n>1. A taxa de fuga vem de nove execuções por versão com max_tokens: 8192. Informamos contagens de tokens em vez de dólares porque a DeepSeek alterou os preços da família V4 e adotou cobrança de pico e fora de pico em 2026-08-16, um dia antes deste lote. O comportamento de recusa e a fuga foram confirmados por um segundo caminho de requisição independente. Tarifas e comportamento podem mudar; refaça as medições antes de depender de qualquer número isolado.

← Voltar ao blog