DeepSeek V4 Pro (0813) : renvoi du contenu de réflexion et matrice à 3 API

Cet article présente les remarques d'usage et les pièges à éviter pour deepseek-v4-pro-0813. Sur AIHubMix, le modèle est disponible via les API Chat Completions, Responses et Messages compatible Claude. Voir aussi : documentation officielle de l'API DeepSeek.

Les conclusions « Vérifié » et les exemples de réponses de chaque section proviennent d'appels réels effectués le 2026-08-13 via les API AIHubMix (Chat Completions / Responses / Messages) ; les éléments de spécification non marqués « Vérifié » proviennent de la documentation officielle de DeepSeek.

1. Positionnement du modèle et spécifications en un coup d'œil

V4 Pro est le modèle haut de gamme de la génération V4 de DeepSeek (le modèle léger deepseek-v4-flash en est le frère). La lignée remonte à DeepSeek-V4 Preview, le 2026-04-24, et 0813 est l'étiquette de VERSION DU MODÈLE attribuée par DeepSeek à la build actuelle. Au-delà des spécifications brutes, quatre points le distinguent :

• Un modèle de pointe épars : 1.6T de paramètres au total / 49B activés (architecture MoE, ou mixture-of-experts : à chaque passe d'inférence, seul un sous-ensemble de réseaux experts est activé ; les paramètres totaux déterminent la capacité de connaissance, les paramètres activés déterminent le coût de calcul par appel). La fiche du modèle mentionne une attention hybride CSA+HCA, mHC et l'optimiseur Muon.
• Poids ouverts sous licence MIT : deepseek-ai/DeepSeek-V4-Pro est publié sur HuggingFace sous licence MIT (l'une des licences open source les plus permissives : usage commercial et redistribution en code fermé sont tous deux autorisés) et peut être auto-hébergé. La licence MIT est rare pour un modèle de cette taille. Les notes d'auto-hébergement de la fiche du modèle suggèrent également une fenêtre de contexte d'au moins 384K tokens lors d'une exécution en Think Max (le niveau de réflexion le plus élevé). Il s'agit de recommandations de déploiement pour l'auto-hébergement, et non d'une spécification de l'API hébergée.
• Le support multi-protocole est natif, et non une traduction tierce : DeepSeek propose lui-même une API Chat compatible OpenAI, un point de terminaison compatible Anthropic (/anthropic, qui associe claude-opus* à ce modèle) et l'API Responses (DeepSeek décrit un support natif du format, avec des adaptations pour Codex). Il propose également la complétion FIM (fill-in-the-middle) en bêta sur un point de terminaison distinct, qui ne fait pas partie des trois API AIHubMix.
• Un écart d'environ 120× entre le tarif avec cache hit et cache miss : le mécanisme de tarification publié par DeepSeek est de $0.003625/M en cache hit contre $0.435/M en cache miss (sortie à $0.87/M), et la mise en cache est automatique, sans paramètre à définir. Pour les charges de travail qui réutilisent de longs préfixes (prompts système, longs documents), cet écart domine la facture. Le tarif de détail réel est celui affiché sur la page du modèle.

Vérifié : dépasser max_tokens est rejeté par la validation plutôt que tronqué silencieusement. L'envoi de max_tokens=9999999 renvoie HTTP 400, et le corps de l'erreur nomme le champ et indique le plafond, 393216.

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

❗ Les images ne provoquent pas d'erreur, mais elles sont supprimées : la formulation officielle pour l'API Responses est « Les entrées image et fichier ne sont pas prises en charge (les parties input_image ne provoquent pas d'erreur, mais sont remplacées par un texte de substitution) ». Une partie input_image ne fait pas échouer la requête : elle est remplacée par un texte de substitution. Sur Chat Completions, le content du message utilisateur n'accepte qu'une chaîne, et sur Messages les blocs type="image" sont marqués non pris en charge. Lors de la mise en place d'un routage multimodal, ne considérez jamais « pas d'erreur » comme la preuve que le modèle a réellement vu l'image.

2. Comment désactiver la réflexion ? Trois API, trois formes de champs

V4 Pro réfléchit par défaut : n'envoyez aucun paramètre et la réponse contient le contenu de réflexion. La désactivation utilise une forme de champ différente sur chacune des trois API.

Chat Completions

Utilisez l'objet thinking de premier niveau.

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

Vérifié : avec thinking.type="disabled", message.reasoning_content et usage.completion_tokens_details.reasoning_tokens disparaissent ensemble, ce qui confirme que le commutateur a bien pris effet.

Responses

Il n'existe pas de commutateur séparé sur Responses ; désactiver la réflexion revient à définir le niveau sur 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

Vérifié : reasoning.effort="none" se distingue nettement du niveau par défaut (les tokens de réflexion tombent à zéro et l'élément de sortie reasoning disparaît), ce qui confirme que le réglage a pris effet.

Messages

Même nom et même forme que sur Chat Completions : l'objet thinking de premier niveau.

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]

Vérifié : une fois désactivé, le bloc thinking disparaît complètement et seul le bloc text subsiste.

Sur les niveaux de réflexion : low et max ont tous deux renvoyé 200 sur Chat Completions lors des tests (high est la valeur par défaut et s'applique lorsque le champ est omis), mais le nombre de tokens de réflexion ne montre aucune différence monotone entre les niveaux pour une même question (question facile : low=43 / max=27 ; question difficile : low=114 / max=92), et rien n'est renvoyé dans la réponse. Les niveaux sont acceptés, mais aucun signal distinctif n'est observable dans la réponse. Sur Responses, seul le niveau none (réflexion désactivée) peut être confirmé côté réponse.

3. Pourquoi une conversation multi-tours renvoie-t-elle soudainement 400 ? Le contenu de réflexion précédent doit être renvoyé tel quel

C'est le piège le plus fréquent avec ce modèle : en mode réflexion, une conversation multi-tours doit renvoyer tel quel le contenu de réflexion du tour précédent, faute de quoi la requête est rejetée. Pas de dégradation, pas de baisse de qualité : une erreur HTTP 400 franche.

Les trois API transportent le même contenu de réflexion sous des noms de champs différents :

Vérifié (conditions de déclenchement) : cette validation se déclenche systématiquement sur les requêtes multi-tours contenant des tools (le modèle émet un appel d'outil, puis le résultat de l'outil est renvoyé). Sur les requêtes multi-tours simples sans outils, où le modèle répond directement, la validation ne s'est pas déclenchée lors de ce cycle de tests et la requête a renvoyé 200. En d'autres termes, l'orchestration d'outils (charges de travail d'agents ou d'appels de fonctions) est le cas où vous êtes le plus susceptible de rencontrer le problème : considérez donc le contenu de réflexion comme une partie de l'état de la conversation que vous devez conserver et rejouer.

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

Vérifié : un message historique de l'assistant dépourvu de reasoning_content renvoie 400 ; l'ajout de ce champ fait renvoyer 200 à la requête identique, qui continue correctement.

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

Vérifié : il suffit de réinjecter response.output tel quel. Filtrer les éléments de sortie avec type == "message" lors de la construction de l'historique supprime l'élément reasoning et déclenche le 400 : c'est le moyen le plus courant de se faire piéger.

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

Vérifié : supprimer le bloc thinking du tableau de contenu renvoie 400 (avec error.type valant invalid_request_error).

4. Appel d'outils

Chaque API déclare les outils dans sa propre forme de protocole ; ces formes ne sont pas interchangeables.

Chat Completions

Forme imbriquée (un objet function englobant name / parameters). Un tool_choice désignant une fonction nommée force l'appel.

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"}

❗ Vérifié : tool_choice: "required" ne peut pas être utilisé lorsque la réflexion est activée : il renvoie 400 avec le message Thinking mode does not support this tool_choice ; désactiver la réflexion (thinking.type="disabled") fait renvoyer 200 à la requête identique. Lorsque vous avez besoin de la sémantique « doit appeler un outil », utilisez plutôt un tool_choice désignant une fonction nommée (comme ci-dessus, cela fonctionne avec la réflexion activée), ou désactivez d'abord la réflexion puis utilisez required.

Responses

Forme à plat (type / name / parameters au même niveau).

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"}

Vérifié : copier la forme imbriquée de Chat Completions (function: {...}) dans Responses renvoie 400 ; utilisez la forme à plat. tool_choice: "required" est soumis à la même restriction du mode réflexion que sur Chat.

Messages

Forme native d'Anthropic (input_schema), avec tool_choice: {"type": "any"} pour forcer un appel.

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"}

❗ Les appels d'outils en parallèle ne peuvent pas être désactivés, par conception de DeepSeek : la page officielle de compatibilité Anthropic indique, dans la ligne tool_choice, que disable_parallel_tool_use is ignored, et la page Responses indique de même parallel_tool_calls | Ignored (parallel tool calling is always enabled). Les tests le confirment : demander simultanément la météo de deux villes avec disable_parallel_tool_use: true renvoie toujours deux blocs tool_use. Si vous avez besoin d'une exécution séquentielle, prenez le premier appel ou mettez-les en file d'attente côté client.

Nombre d'outils et coût de contexte : l'envoi de 200 définitions de fonctions dans une seule requête a tout de même renvoyé 200 avec une réponse normale et n'a déclenché aucune validation du nombre (observé sur ce chemin ; des valeurs plus élevées n'ont pas été testées). Mais prompt_tokens pour cette requête a atteint 6,105 — les définitions d'outils entrent dans le contexte en totalité et sont facturées. Lorsque vous disposez de nombreux outils, limitez l'ensemble d'outils selon le scénario au lieu de déclarer tout sans condition.

5. Sortie structurée

Chat Completions

response_format prend en charge le mode 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}

Vérifié : la sortie est un JSON valide.

Responses

Déclarez un JSON Schema via text.format, le mode strict étant pris en charge.

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}

Vérifié : la sortie respecte strictement le schéma donné.

Messages

Le protocole Messages (Anthropic) n'a aucun équivalent de response_format / text.format. La solution de contournement habituelle consiste à transporter le schéma dans un outil : déclarez un outil dont input_schema est votre schéma cible, définissez tool_choice: {"type": "any"}, et lisez le résultat structuré dans l'input du bloc tool_use. Ce cycle de tests n'a pas spécifiquement vérifié ce schéma ; si vous avez besoin de garanties strictes sur le schéma, privilégiez Chat Completions ou Responses.

6. Comment activer le cache de contexte ? Vous n'avez rien à faire, il est automatique

Le cache de contexte (les préfixes identiques sont réutilisés, et la partie mise en cache est facturée à un tarif inférieur) est activé par défaut et ne nécessite aucun paramètre. Une seconde requête avec le même long préfixe signale le succès dans usage, sous un nom de champ qui varie selon l'API. Pour les détails du cache et les tarifs actuels, consultez la page du modèle ; pour la stratégie de cache inter-modèles et les techniques d'amélioration du taux de succès, consultez les pratiques de mise en cache des prompts.

Chat Completions

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

Vérifié : deux appels consécutifs avec le même long préfixe sur le même canal ont fait passer cached_tokens de 0 à 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

Vérifié : le préfixe ci-dessus a été préchauffé par une requête Responses au contenu identique, et le premier appel Messages a immédiatement obtenu 896 — ce qui est cohérent avec un cache indexé sur le préfixe de contenu et partagé entre les surfaces de protocole.

7. logprobs : Chat renvoie deux canaux

logprobs (log-probabilités : le détail de confiance du modèle pour chaque token candidat) est renvoyé sous des formes différentes par les deux API, et le code d'analyse doit les traiter séparément.

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

❗ Vérifié : Chat renvoie des log-probabilités pour content et reasoning_content. Le code qui ne lit que logprobs.content, selon la structure de réponse standard d'OpenAI, ne générera pas d'erreur mais ignorera silencieusement le canal de réflexion ; si votre code suppose un tableau unique sous logprobs, ajoutez d'abord une vérification de structure.

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

Vérifié : Responses n'attache les logprobs qu'au dernier élément texte, sans la structure à double canal observée sur Chat.

Messages

Le protocole Messages (Anthropic) n'a aucun champ équivalent. Pour le détail des probabilités au niveau des tokens, utilisez Chat Completions ou Responses.

8. Quelles API peuvent effectuer une recherche web ?

La recherche web est ici un outil côté serveur (la récupération s'exécute sur le serveur ; le client n'émet jamais la requête lui-même), et elle s'exécute réellement sur les API Responses et Messages lors des tests.

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"]

Vérifié : un élément web_search_call apparaît dans la séquence de sortie, ce qui signifie que le serveur a bien effectué une récupération.

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

Vérifié : usage.server_tool_use.web_search_requests vaut 1 — la requête de récupération a bien eu lieu et a été comptabilisée.

Chat Completions

La recherche web ne peut pas être déclenchée sur Chat. La référence officielle de l'API Chat de DeepSeek ne contient aucun champ d'outil de recherche dans le schéma de requête (cette absence a été établie en parcourant la liste des champs un par un ; DeepSeek n'a fait aucune déclaration explicite niant la prise en charge). L'API dont la prise en charge officielle de la recherche côté serveur est explicitement documentée est Responses (web_search), et la page officielle de compatibilité Messages liste également les blocs de contenu liés à la recherche.

# 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

Vérifié : l'envoi de web_search_options ou enable_search ne déclenche pas d'erreur, mais ne récupère rien non plus — la réponse ne contient pas de annotations (la liste de citations jointe à une réponse lorsque la recherche web s'exécute), et l'usage correspond au groupe témoin champ par champ. Pour l'accès au web, utilisez plutôt l'API Responses ou Messages.

9. Notes d'utilisation : conception de DeepSeek et écarts sur notre chemin

Tout ce qui suit renvoie HTTP 200 tout en se comportant de manière contre-intuitive. Les causes diffèrent, de même que ce qu'il faut faire à leur sujet ; elles sont donc listées séparément : le premier groupe correspond à la conception du modèle par DeepSeek, et changer de fournisseur ne la modifiera pas ; le second groupe correspond au comportement actuel sur le chemin AIHubMix, sur lequel nous travaillons.

9.1 Selon la conception de DeepSeek

9.2 Comportement actuel sur le chemin AIHubMix

9.3 Non défini par DeepSeek, donc aucun verdict dans un sens ou dans l'autre

L'envoi d'une valeur hors de l'énumération de reasoning_effort (par ex. bogus_xyz) renvoie 200 avec une réponse normale, sans erreur ni effet observable. Le fait est assez clair : ce chemin ne valide actuellement pas l'énumération de reasoning_effort. Ce qui reste flou, c'est s'il devrait le faire : DeepSeek publie l'énumération légale mais n'indique jamais si un niveau illégal devrait être rejeté, il n'existe donc aucune référence pour trancher, ce qui signifie que cela ne constitue ni un comportement officiel ni un défaut sur notre chemin. L'approche côté client la plus sûre consiste à valider vous-même le niveau et à ne pas compter sur l'API pour le détecter.

10. Matrice de prise en charge capacité × API

Les cellules ci-dessous donnent l'orthographe du paramètre / champ pour chaque API. Sauf lorsqu'elle est marquée comme formulation explicite de DeepSeek, chaque conclusion provient d'appels réels effectués le 2026-08-13 sur les API de production d'AIHubMix.

Légende : ✅ fonctionnement vérifié · 🟡 accepté mais effet non confirmable · ❗ nécessite une attention (voir les notes ci-dessus) · ➖ ce concept n'existe pas sur cette API

FAQ

Quelles API deepseek-v4-pro-0813 prend-il en charge sur AIHubMix ?
Chat Completions (/v1/chat/completions), Responses (/v1/responses) et l'API Messages compatible Claude (/v1/messages).

Pourquoi une conversation multi-tours renvoie-t-elle soudain une erreur 400 ?
La cause la plus fréquente est un historique de réflexion qui n'a pas été renvoyé. En mode thinking, le contenu de réflexion du tour précédent doit être rejoué à l'identique : reasoning_content sur le message assistant pour Chat, l'élément de sortie type="reasoning" pour Responses, et le bloc de contenu thinking pour Messages. Le multi-tours avec outils est le cas le plus touché : de nombreux frameworks filtrent les éléments de sortie par type == "message" lors de la construction de l'historique, ce qui supprime l'élément de raisonnement.

Peut-on désactiver le thinking ?
Oui. Envoyez thinking: {"type": "disabled"} sur Chat ou Messages, et reasoning: {"effort": "none"} sur Responses. Une fois désactivé, le contenu de réflexion et les jetons de réflexion disparaissent.

Les trois niveaux de reasoning_effort sont-ils différents ?
low / high / max sont tous acceptés (par défaut high ; medium et xhigh sont associés à high par compatibilité). Lors des tests, le nombre de jetons de réflexion pour une même question ne montre aucune différence monotone entre les niveaux, et rien n'est renvoyé, si bien que la différence ne peut pas être confirmée côté appelant. Seul le niveau none sur Responses (thinking désactivé) produit une différence nettement observable.

Pourquoi tool_choice: "required" renvoie-t-il une erreur 400 ?
Cette valeur n'est pas acceptée tant que le thinking est activé (le corps de l'erreur indique Thinking mode does not support this tool_choice). Utilisez un tool_choice nommant une fonction ({"type": "function", "function": {"name": "..."}}) pour forcer un appel précis avec le thinking activé, ou désactivez d'abord le thinking puis utilisez required.

Comment activer le cache de contexte ?
Vous n'avez rien à faire : il est automatique. Placez en début de requête le contenu stable et inchangé (prompts système, extraits de connaissances, définitions d'outils), et le nombre de hits est indiqué dans usage : prompt_tokens_details.cached_tokens sur Chat, input_tokens_details.cached_tokens sur Responses, et cache_read_input_tokens sur Messages.

Pour les tarifs et l'état en temps réel, consultez la page du modèle deepseek-v4-pro-0813 ; pour d'autres modèles, rendez-vous dans la galerie de modèles.

Guides pratiques associés : guide pratique Kimi K3 (nouveaux paramètres et matrice de prise en charge des trois API) et modifications de la mise en cache des prompts et de la facturation de GPT-5.6.