DeepSeek V4 Pro (0813): Passback de Thinking e Matriz de 3 APIs

Este artigo reúne as observações de uso e as armadilhas do deepseek-v4-pro-0813. No AIHubMix, o modelo está disponível pelas APIs Chat Completions, Responses e Messages compatível com Claude. Veja também: documentação oficial da API do DeepSeek.

As conclusões "Verificado" e as respostas de exemplo de cada seção vêm de chamadas reais feitas em 13/08/2026 pelas APIs do AIHubMix (Chat Completions / Responses / Messages). Os itens de especificação não marcados como "Verificado" vêm da documentação oficial do DeepSeek.

1. Posicionamento do Modelo e Especificações Resumidas

O V4 Pro é o nível topo de linha da geração V4 do DeepSeek (o leve deepseek-v4-flash é seu irmão). A linha de lançamento remonta ao DeepSeek-V4 Preview, em 24/04/2026, e 0813 é o rótulo de VERSÃO DO MODELO atribuído pelo DeepSeek à build atual. Além das especificações brutas, quatro pontos o diferenciam:

• Um modelo de fronteira esparso: 1,6T de parâmetros totais / 49B ativados (uma arquitetura MoE, ou mistura de especialistas, em que cada passagem de inferência ativa apenas um subconjunto de redes especialistas: os parâmetros totais determinam a capacidade de conhecimento, e os parâmetros ativados determinam o custo de computação por chamada). O model card lista a atenção híbrida CSA+HCA, mHC e o otimizador Muon.
• Pesos abertos sob MIT: o deepseek-ai/DeepSeek-V4-Pro é publicado no HuggingFace sob a licença MIT (uma das licenças de código aberto mais permissivas, que permite uso comercial e redistribuição de código fechado) e pode ser hospedado por conta própria. A licença MIT é incomum para um modelo desse porte. As notas de self-hosting do model card também sugerem uma janela de contexto de ≥384K tokens ao rodar no Think Max (o nível de thinking mais alto). Trata-se de orientação de implantação para self-hosting, e não de uma especificação da API hospedada.
• Suporte a múltiplos protocolos é nativo, não tradução de terceiros: o próprio DeepSeek oferece uma API Chat no formato OpenAI, um endpoint compatível com Anthropic (/anthropic, que mapeia claude-opus* para este modelo) e a API Responses (o DeepSeek descreve suporte nativo ao formato, com adaptações para o Codex). Ele também oferece completação FIM (fill-in-the-middle) como recurso Beta em um endpoint separado, que não faz parte das três APIs do AIHubMix.
• Uma diferença de ~120× entre o preço de cache hit e cache miss: o mecanismo de preço publicado pelo DeepSeek é cache hit de US$ 0,003625/M contra cache miss de US$ 0,435/M (saída de US$ 0,87/M), e o cache é automático, sem nenhum parâmetro a configurar. Em cargas de trabalho que reutilizam prefixos longos (prompts de sistema, documentos extensos), essa diferença domina a conta. O preço de varejo real é o que a página do modelo mostra.

Verificado: exceder max_tokens é rejeitado pela validação, em vez de ser truncado silenciosamente. Enviar max_tokens=9999999 retorna HTTP 400, e o corpo do erro indica o campo e informa o limite 393216.

# max_tokens=9999999 -> HTTP 400
"...max_tokens... 393216"

❗ Imagens não geram erro, mas são descartadas: a redação oficial para a API Responses é "Image and file inputs are not supported (input_image parts do not cause an error, but are replaced with a placeholder text)". Ou seja, uma parte input_image não faz a requisição falhar, mas é substituída por um texto de placeholder. No Chat Completions, o content da mensagem do usuário aceita apenas string, e no Messages os blocos type="image" são marcados como Not Supported. Ao montar um roteamento multimodal, nunca trate "nenhum erro" como prova de que o modelo de fato viu a imagem.

2. Como Desligar o Thinking? Três APIs, Três Formatos de Campo

O V4 Pro faz thinking por padrão: não envie parâmetro algum e a resposta virá com o conteúdo de thinking. Para desligá-lo, cada uma das três APIs usa um formato de campo diferente.

Chat Completions

Use o objeto thinking no nível superior.

from openai import OpenAI

client = OpenAI(
    base_url="https://aihubmix.com/v1",
    api_key="<AIHUBMIX_API_KEY>",
)

completion = client.chat.completions.create(
    model="deepseek-v4-pro-0813",
    messages=[{"role": "user", "content": "What is 2 + 2?"}],
    extra_body={"thinking": {"type": "disabled"}},
)

# Thinking on  (default): message.reasoning_content present, reasoning_tokens = 43
# Thinking off (disabled): reasoning_content absent, reasoning_tokens absent

Verificado: com thinking.type="disabled", message.reasoning_content e usage.completion_tokens_details.reasoning_tokens desaparecem juntos, o que confirma que a alternância surtiu efeito.

Responses

Não há chave separada no Responses; desligar o thinking significa definir o nível como none.

response = client.responses.create(
    model="deepseek-v4-pro-0813",
    input="What is 2 + 2?",
    reasoning={"effort": "none"},
)

# effort="none": usage.output_tokens_details.reasoning_tokens = 0
#                output[0] is the message item directly (no reasoning item)
# effort unset : output always starts with a reasoning item

Verificado: reasoning.effort="none" é observavelmente diferente do nível padrão (os tokens de thinking caem para zero e o item de saída reasoning desaparece), o que confirma que surtiu efeito.

Messages

Mesmo nome e mesmo formato do Chat Completions: o objeto thinking no nível superior.

from anthropic import Anthropic

client = Anthropic(
    api_key="<AIHUBMIX_API_KEY>",
    base_url="https://aihubmix.com",
)

response = client.messages.create(
    model="deepseek-v4-pro-0813",
    max_tokens=1024,
    messages=[{"role": "user", "content": "What is 2 + 2?"}],
    extra_body={"thinking": {"type": "disabled"}},
)

# Thinking on  (default): content = [thinking block, text block]
# Thinking off (disabled): content = [text block]

Verificado: uma vez desativado, o bloco thinking desaparece por completo e resta apenas o bloco text.

Sobre os níveis de thinking: low e max retornaram 200 no Chat Completions durante os testes (high é o padrão e se aplica quando o campo é omitido), mas as contagens de tokens de thinking não mostram diferença monotônica entre níveis para a mesma pergunta (pergunta fácil: low=43 / max=27; pergunta difícil: low=114 / max=92). Além disso, nada é ecoado na resposta: os níveis são aceitos, mas nenhum sinal distintivo é observável na resposta. No Responses, só o nível none (thinking desligado) pode ser confirmado pelo lado da resposta.

3. Por Que uma Conversa com Vários Turnos Retorna 400 de Repente? O Histórico de Thinking Deve Ser Devolvido Integralmente

Esta é a armadilha mais comum com este modelo: no modo thinking, uma conversa com vários turnos precisa devolver integralmente o conteúdo de thinking do turno anterior, ou a requisição é rejeitada. Não é degradação nem queda de qualidade, mas um HTTP 400 puro.

As três APIs carregam o mesmo conteúdo de thinking sob nomes de campo diferentes:

Verificado (condições de disparo): essa validação dispara de forma consistente em requisições com vários turnos que carregam tools (o modelo emite uma chamada de ferramenta e o resultado dela é enviado de volta). Em requisições simples com vários turnos, sem ferramentas, em que o modelo responde diretamente, a validação não disparou nesta rodada de testes e a requisição retornou 200. Em outras palavras, a orquestração de ferramentas (cargas de agentes / function calling) é onde você tem mais chance de esbarrar nesse erro, então trate o conteúdo de thinking como parte do estado da conversa que você persiste e reenvia.

Chat Completions

# Multi-turn: pass the previous assistant message back verbatim, including reasoning_content
messages = [
    {"role": "user", "content": "What is 1 + 1? Remember the result."},
    {
        "role": "assistant",
        "content": "2",
        "reasoning_content": "<reasoning_content from the previous response>",
    },
    {"role": "user", "content": "Add 1 to the result."},
]

# Dropping reasoning_content -> HTTP 400 invalid_request_error

Verificado: uma mensagem histórica do assistente sem reasoning_content retorna 400; ao incluí-lo de volta, a mesma requisição retorna 200 e continua corretamente.

Responses

# Multi-turn: input = previous input + response.output (reasoning item included) + new message
input = previous_input + response.output + [
    {"role": "user", "content": "Add 1 to the result."}
]

# Filtering out the type="reasoning" item -> HTTP 400

Verificado: basta reinserir response.output exatamente como veio. Filtrar os itens de saída por type == "message" ao montar o histórico descarta o item reasoning e dispara o 400. Esta é a forma mais comum de cair nessa armadilha.

Messages

# Multi-turn: pass response.content back verbatim as the assistant message
messages = [
    {"role": "user", "content": "What's the weather in Paris?"},
    {"role": "assistant", "content": response.content},   # thinking + tool_use blocks
    {"role": "user", "content": [tool_result_block]},
]

# Stripping the thinking block -> HTTP 400

Verificado: remover o bloco thinking do array de conteúdo retorna 400 (com error.type igual a invalid_request_error).

4. Chamada de Ferramentas

Cada API declara ferramentas no formato do seu próprio protocolo; os formatos não são intercambiáveis.

Chat Completions

Formato aninhado (um objeto function envolvendo name / parameters). Um tool_choice com função nomeada força a chamada.

completion = client.chat.completions.create(
    model="deepseek-v4-pro-0813",
    messages=[{"role": "user", "content": "What's the weather in Paris?"}],
    tools=[{
        "type": "function",
        "function": {
            "name": "get_weather",
            "description": "Get weather for a city",
            "parameters": {"type": "object", "properties": {"city": {"type": "string"}}, "required": ["city"]},
        },
    }],
    tool_choice={"type": "function", "function": {"name": "get_weather"}},
)

# Observed: finish_reason "tool_calls", tool_calls[0].function.arguments = {"city": "Paris"}

❗ Verificado: tool_choice: "required" não pode ser usado com o thinking ativado. Ele retorna 400 com Thinking mode does not support this tool_choice; desativar o thinking (thinking.type="disabled") faz a mesma requisição retornar 200. Quando você precisar de semântica de "deve chamar uma ferramenta", use um tool_choice com função nomeada (como acima, que funciona com o thinking ativado), ou desligue o thinking primeiro e então use required.

Responses

Formato plano (type / name / parameters no mesmo nível).

response = client.responses.create(
    model="deepseek-v4-pro-0813",
    input="What's the weather in Paris?",
    tools=[{
        "type": "function",
        "name": "get_weather",
        "description": "Get weather for a city",
        "parameters": {"type": "object", "properties": {"city": {"type": "string"}}, "required": ["city"]},
    }],
)

# Observed output items: ["reasoning", "function_call"]; arguments = {"city": "Paris"}

Verificado: copiar o formato aninhado do Chat Completions (function: {...}) para o Responses retorna 400. Use o formato plano. tool_choice: "required" está sujeito à mesma restrição de modo thinking que no Chat.

Messages

Formato nativo da Anthropic (input_schema), com tool_choice: {"type": "any"} para forçar uma chamada.

response = client.messages.create(
    model="deepseek-v4-pro-0813",
    max_tokens=1024,
    tools=[{
        "name": "get_weather",
        "description": "Get weather for a city",
        "input_schema": {"type": "object", "properties": {"city": {"type": "string"}}, "required": ["city"]},
    }],
    tool_choice={"type": "any"},
    messages=[{"role": "user", "content": "What's the weather in Paris?"}],
)

# Observed: content contains a tool_use block, name = get_weather, input = {"city": "Paris"}

❗ A chamada paralela de ferramentas não pode ser desativada, por decisão de design do próprio DeepSeek: a página oficial de compatibilidade com Anthropic afirma, na linha de tool_choice, que disable_parallel_tool_use is ignored, e a página do Responses diz o mesmo em parallel_tool_calls | Ignored (parallel tool calling is always enabled). Os testes confirmam: perguntar sobre duas cidades ao mesmo tempo com disable_parallel_tool_use: true ainda retorna dois blocos tool_use. Se você precisa de execução serial, processe apenas a primeira chamada ou enfileire as chamadas do lado do cliente.

Contagem de ferramentas e custo de contexto: enviar 200 definições de função em uma única requisição ainda retornou 200 com uma resposta normal e não acionou nenhuma validação de quantidade (observado neste caminho; contagens maiores não foram testadas). Porém, prompt_tokens dessa requisição chegou a 6.105 — as definições de ferramentas entram no contexto por completo e são cobradas. Quando há muitas ferramentas, reduza o conjunto de ferramentas por cenário em vez de declarar todas incondicionalmente.

5. Saída estruturada

Chat Completions

response_format oferece suporte ao modo JSON.

completion = client.chat.completions.create(
    model="deepseek-v4-pro-0813",
    messages=[{"role": "user", "content": "Return {\"a\": 1} as JSON."}],
    response_format={"type": "json_object"},
)

# Observed response content: {"a":1}

Verificado: a saída é JSON válido.

Responses

Declare um JSON Schema por meio de text.format, com suporte ao modo strict.

response = client.responses.create(
    model="deepseek-v4-pro-0813",
    input="Return the number 1 under key a.",
    text={
        "format": {
            "type": "json_schema",
            "name": "extract",
            "strict": True,
            "schema": {"type": "object", "properties": {"a": {"type": "integer"}}, "required": ["a"]},
        }
    },
)

# Observed output text: {"a":1}

Verificado: a saída está em conformidade estrita com o schema fornecido.

Messages

O protocolo Messages (Anthropic) não tem equivalente a response_format / text.format. A solução alternativa usual é transportar o schema em uma ferramenta — declare uma ferramenta cujo input_schema seja o schema desejado, defina tool_choice: {"type": "any"} e leia o resultado estruturado a partir do input do bloco tool_use. Esta rodada de testes não verificou especificamente esse padrão; quando forem necessárias garantias rígidas de schema, prefira Chat Completions ou Responses.

6. Como ativar o cache de contexto? Não é preciso, ele é automático

O cache de contexto (prefixos idênticos são reutilizados, e a parte em cache é cobrada a uma taxa menor) está ativado por padrão e não exige parâmetros. Uma segunda requisição com o mesmo prefixo longo reporta o acerto em usage, sob um nome de campo que varia conforme a API. Para detalhes de cache e preços atuais, veja a página do modelo; para a estratégia de cache entre modelos e técnicas de taxa de acerto, veja as práticas de cache de prompt.

Chat Completions

# usage of the second call with an identical long prefix
"prompt_tokens_details": {"cached_tokens": 640}   # first call: 0

Verificado: duas chamadas consecutivas com o mesmo prefixo longo no mesmo canal fizeram cached_tokens passar de 0 para 640.

Responses

# usage of the second call with identical long instructions
"input_tokens_details": {"cached_tokens": 896}    # first call: 0

Messages

# usage of a call whose long system prefix was already warmed
"cache_read_input_tokens": 896

Verificado: o prefixo acima foi aquecido por uma requisição Responses com conteúdo idêntico, e a primeira chamada Messages obteve 896 de acerto imediatamente — consistente com o cache sendo indexado pelo prefixo de conteúdo e compartilhado entre as superfícies de protocolo.

7. logprobs: Chat retorna dois canais

logprobs (probabilidades logarítmicas — o detalhe de confiança por token candidato do modelo) volta em formatos diferentes nas duas APIs, e o código de parsing precisa tratá-las separadamente.

Chat Completions

completion = client.chat.completions.create(
    model="deepseek-v4-pro-0813",
    messages=[{"role": "user", "content": "Say hi."}],
    logprobs=True,
    top_logprobs=2,
)

# Observed: choices[0].logprobs contains TWO arrays
#   logprobs.content[]            -> tokens of the final answer
#   logprobs.reasoning_content[]  -> tokens of the thinking text

❗ Verificado: Chat retorna probabilidades logarítmicas tanto para content quanto para reasoning_content. Código que lê apenas logprobs.content, conforme o formato de resposta padrão da OpenAI, não gera erro, mas ignora silenciosamente o canal de raciocínio; se o seu código assume um único array em logprobs, adicione antes uma verificação de formato.

Responses

response = client.responses.create(
    model="deepseek-v4-pro-0813",
    input="Say hi.",
    top_logprobs=3,
)

# Observed: logprobs only on the final message item
#   output[-1].content[0].logprobs[] with logprob + top_logprobs details

Verificado: Responses anexa logprobs somente ao item de texto final — nenhum formato de dois canais como o visto em Chat.

Messages

O protocolo Messages (Anthropic) não tem campo equivalente. Para detalhes de probabilidade no nível de token, use Chat Completions ou Responses.

8. Quais APIs podem pesquisar na web?

A pesquisa na web aqui é uma ferramenta do lado do servidor (a recuperação é executada no servidor; o cliente nunca emite a requisição em si), e ela de fato é executada nas APIs Responses e Messages nos testes.

Responses

response = client.responses.create(
    model="deepseek-v4-pro-0813",
    input="What is the latest stable version of Python?",
    tools=[{"type": "web_search"}],
)

# Observed output item sequence:
# ["reasoning", "web_search_call", "reasoning", "message"]

Verificado: um item web_search_call aparece na sequência de saída, o que significa que o servidor realmente executou uma recuperação.

Messages

response = client.messages.create(
    model="deepseek-v4-pro-0813",
    max_tokens=1024,
    tools=[{"type": "web_search_20250305", "name": "web_search"}],
    messages=[{"role": "user", "content": "What is the latest stable version of Python?"}],
)

# Observed content block sequence:
# ["thinking", "server_tool_use", "web_search_tool_result", "thinking", "text"]
# usage.server_tool_use.web_search_requests = 1

Verificado: usage.server_tool_use.web_search_requests conta 1 — a requisição de recuperação de fato ocorreu e foi contabilizada.

Chat Completions

A pesquisa na web não pode ser acionada em Chat. A referência oficial da API Chat da DeepSeek não contém nenhum campo de ferramenta de pesquisa em todo o schema da requisição (essa ausência foi constatada percorrendo a lista de campos um a um; a DeepSeek não fez nenhuma declaração explícita negando suporte). A API com declaração oficial explícita de suporte à pesquisa do lado do servidor é Responses (web_search), e a página oficial de compatibilidade com Messages também lista os blocos de conteúdo relacionados à pesquisa.

# Three control groups, same question requiring live information, all HTTP 200:
# A no search field       -> "cannot retrieve", annotations = null
# B web_search_options    -> "cannot retrieve", annotations = null, usage identical to A
# C enable_search         -> "cannot retrieve", annotations = null, usage identical to A

Verificado: enviar web_search_options ou enable_search não gera erro, mas também não recupera nada — a resposta não traz annotations (a lista de citações anexada à resposta quando a pesquisa na web é executada), e o uso corresponde ao grupo de controle campo por campo. Para acesso à web, use a API Responses ou Messages.

9. Notas de uso: o design da DeepSeek vs. desvios no nosso caminho

Tudo abaixo retorna HTTP 200 mas se comporta de forma contraintuitiva. As causas diferem, e também o que fazer a respeito, por isso são listadas separadamente: o primeiro grupo é como a DeepSeek projetou o modelo, e trocar de provedor não o mudará; o segundo grupo é o comportamento atual no caminho do AIHubMix, em que estamos trabalhando.

9.1 Pelo design da DeepSeek

9.2 Comportamento atual no caminho do AIHubMix

9.3 Não definido pela DeepSeek, então sem veredito em nenhum sentido

Enviar para reasoning_effort um valor fora do enum (por exemplo bogus_xyz) retorna 200 com uma resposta normal, sem erro e sem efeito observável. O fato é claro o suficiente: este caminho atualmente não valida o enum de reasoning_effort. O que não está claro é se ele deveria validar: a DeepSeek publica o enum válido, mas nunca declara se um nível ilegal deveria ser rejeitado, então não há base de comparação; por isso, isso não conta nem como comportamento oficial nem como defeito no nosso caminho. A abordagem segura do lado do cliente é validar o nível por conta própria e não contar com a API para detectá-lo.

10. Matriz de suporte capacidade × API

As células abaixo mostram a grafia do parâmetro / campo para cada API. Exceto onde marcado como redação explícita da DeepSeek, toda conclusão vem de chamadas reais feitas em 13/08/2026 contra as APIs de produção do AIHubMix.

Legenda: ✅ verificado funcionando · 🟡 aceito, mas não é possível confirmar que tem efeito · ❗ requer atenção (veja as notas acima) · ➖ não existe esse conceito nesta API

FAQ

Quais APIs o deepseek-v4-pro-0813 suporta no AIHubMix?
Chat Completions (/v1/chat/completions), Responses (/v1/responses) e a API Messages compatível com Claude (/v1/messages).

Por que uma conversa com várias rodadas retorna 400 de repente?
A causa mais comum é o histórico de raciocínio que não foi reenviado. No modo de raciocínio, o conteúdo de raciocínio da rodada anterior precisa ser reenviado literalmente: reasoning_content na mensagem do assistente para Chat, o item de saída type="reasoning" para Responses e o bloco de conteúdo thinking para Messages. Conversas com várias rodadas e ferramentas são onde isso mais causa problemas, pois muitos frameworks filtram os itens de saída por type == "message" ao montar o histórico, o que descarta o item de raciocínio.

É possível desativar o raciocínio?
Sim. Envie thinking: {"type": "disabled"} em Chat ou Messages, e reasoning: {"effort": "none"} em Responses. Quando desativado, tanto o conteúdo de raciocínio quanto os tokens de raciocínio desaparecem.

Os três níveis de reasoning_effort são diferentes?
low / high / max são todos aceitos (padrão high; medium e xhigh são mapeados para high por compatibilidade). Nos testes, a contagem de tokens de raciocínio para a mesma pergunta não mostra diferença monotônica entre os níveis e nada é devolvido, então a diferença não pode ser confirmada do lado de quem faz a chamada. Apenas o nível none em Responses (raciocínio desativado) produz uma diferença observável clara.

Por que tool_choice: "required" retorna 400?
Esse valor não é aceito com o raciocínio ativado (o corpo do erro diz Thinking mode does not support this tool_choice). Use um tool_choice com nome de função ({"type": "function", "function": {"name": "..."}}) para forçar uma chamada específica com o raciocínio ativado, ou desative o raciocínio primeiro e depois use required.

Como ativar o cache de contexto?
Você não precisa ativar: ele é automático. Coloque no início da requisição o conteúdo estável e imutável (prompts de sistema, trechos de conhecimento, definições de ferramentas), e o número de acertos é informado em usage: prompt_tokens_details.cached_tokens em Chat, input_tokens_details.cached_tokens em Responses e cache_read_input_tokens em Messages.

Para preços e status em tempo real, veja a página do modelo deepseek-v4-pro-0813; para mais modelos, visite a galeria de modelos.

Guias práticos relacionados: guia prático do Kimi K3 (novos parâmetros e uma matriz de suporte às três APIs) e mudanças no cache de prompts e na cobrança do GPT-5.6.