DeepSeek V4 Pro (0813) : Passback de Pensée & Matrice 3-API

Cet article couvre les notes d'utilisation et les pièges pour deepseek-v4-pro-0813. Sur AIHubMix, le modèle est disponible via les API Chat Completions, Responses et Messages compatibles avec Claude. Voir aussi : Documentation officielle de l'API DeepSeek.

Les conclusions "Vérifiées" et les exemples de réponses dans 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és" proviennent de la documentation officielle de DeepSeek.

1. Positionnement du Modèle et Spécifications en Un Coup d'Œil

V4 Pro est le niveau haut de gamme de la génération V4 de DeepSeek (le léger deepseek-v4-flash est son frère). La ligne de sortie remonte à DeepSeek-V4 Preview le 2026-04-24, et 0813 est l'étiquette de VERSION DU MODÈLE que DeepSeek a attribuée à la version actuelle. Au-delà des spécifications brutes, quatre éléments le distinguent :

• Un modèle de frontière sparse : 1,6T de paramètres au total / 49B activés (une architecture MoE, ou mélange d'experts — chaque passage d'inférence active uniquement un sous-ensemble de réseaux d'experts : 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 carte du modèle liste une attention hybride CSA+HCA, mHC et l'optimiseur Muon.
• Pondérations ouvertes sous MIT : deepseek-ai/DeepSeek-V4-Pro est publié sur HuggingFace sous la licence MIT (l'une des licences open-source les plus permissives — l'utilisation commerciale et la redistribution en source fermée sont toutes deux autorisées) et peut être auto-hébergé. MIT est rare pour un modèle de cette taille. Les notes d'auto-hébergement de la carte du modèle suggèrent également une fenêtre de contexte de ≥384K tokens lors de l'exécution en Think Max (le niveau de pensée le plus élevé) — c'est un guide de déploiement pour l'auto-hébergement, pas une spécification de l'API hébergée.
• Le support multi-protocole est de première partie, pas de traduction tierce : DeepSeek lui-même propose une API de Chat OpenAI, un point de terminaison compatible avec Anthropic (/anthropic, qui mappe claude-opus* sur ce modèle), et l'API Responses (DeepSeek décrit un support natif pour le format, avec des adaptations pour Codex). Il propose également une complétion FIM (remplir le milieu) comme fonctionnalité Beta sur un point de terminaison séparé, qui ne fait pas partie des trois API AIHubMix.
• Un écart d'environ 120× entre les prix de cache-hit et cache-miss : le mécanisme de tarification publié par DeepSeek est cache-hit 0,003625 $/M contre cache-miss 0,435 $/M (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 (invites système, longs documents), cet écart domine la facture. Le prix de détail réel est celui affiché sur la page du modèle.

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

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

❗ Les images ne déclenchent pas d'erreur, mais elles sont ignorées : la formulation officielle pour l'API Responses est "Les entrées d'image et de fichier ne sont pas prises en charge (les parties input_image ne provoquent pas d'erreur, mais sont remplacées par un texte de remplacement)" — une partie input_image ne fait pas échouer la demande, elle est remplacée par un texte de remplacement. Sur Chat Completions, le message utilisateur content n'accepte qu'une chaîne, et sur Messages, les blocs type="image" sont marqués Non Supportés. Lors de la construction d'un routage multimodal, ne considérez jamais "pas d'erreur" comme une preuve que le modèle a réellement vu l'image.

2. Comment Désactiver la Pensée ? Trois APIs, Trois Formes de Champ

V4 Pro pense par défaut : n'envoyez aucun paramètre et la réponse revient avec un contenu de pensée. Pour le désactiver, utilisez une forme de champ différente sur chacune des trois APIs.

Chat Completions

Utilisez l'objet de niveau supérieur thinking.

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

# Pensée activée (par défaut) : message.reasoning_content présent, reasoning_tokens = 43
# Pensée désactivée : reasoning_content absent, reasoning_tokens absent

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

Responses

Il n'y a pas de commutateur séparé sur Responses ; désactiver la pensée signifie 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] est l'élément de message directement (pas d'élément de raisonnement)
# effort non défini : la sortie commence toujours par un élément de raisonnement

Vérifié : reasoning.effort="none" diffère de manière observable du niveau par défaut (les tokens de pensée tombent à zéro, l'élément de reasoning disparaît), ce qui confirme qu'il a pris effet.

Messages

Même nom et même forme que Chat Completions : l'objet de niveau supérieur thinking.

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

# Pensée activée (par défaut) : content = [bloc de pensée, bloc de texte]
# Pensée désactivée : content = [bloc de texte]

Vérifié : une fois désactivé, le bloc thinking disparaît entièrement et seul le bloc text reste.

Sur les niveaux de pensée : low et max ont tous deux renvoyé 200 sur Chat Completions lors des tests (high est le par défaut et s'applique lorsque le champ est omis), mais les comptes de tokens de pensée ne montrent aucune différence monotone entre les niveaux pour la 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 (pensée désactivée) peut être confirmé du côté de la réponse.

3. Pourquoi Une Conversation Multi-Tour Retourne-T-Elle Soudainement 400 ? L'Histoire de Pensée Doit Être Renvoyée Verbatim

C'est le piège le plus courant avec ce modèle : en mode de pensée, une conversation multi-tour doit renvoyer le contenu de pensée du tour précédent tel quel, sinon la demande est rejetée. Pas dégradée, pas de moindre qualité — un HTTP 400 sévère.

Les trois APIs portent le même contenu de pensée sous différents noms de champ :

Vérifié (conditions de déclenchement) : cette validation se déclenche systématiquement sur les demandes multi-tour qui portent tools (le modèle émet un appel d'outil, puis le résultat de l'outil est renvoyé). Sur des demandes multi-tour simples sans outils, où le modèle répond directement, la validation ne s'est pas déclenchée lors de ce tour de tests et la demande a renvoyé 200. En d'autres termes, l'orchestration des outils (charges de travail d'agent / d'appel de fonction) est l'endroit où vous êtes le plus susceptible de rencontrer cela, donc considérez le contenu de pensée comme faisant partie de l'état de conversation que vous persistez et rejouez.

Chat Completions

# Multi-tour : renvoyer le message précédent de l'assistant tel quel, y compris 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."},
]

# Ignorer reasoning_content -> HTTP 400 invalid_request_error

Vérifié : un message historique de l'assistant manquant reasoning_content renvoie 400 ; le rajouter fait que la demande identique renvoie 200 et continue correctement.

Responses

# Multi-tour : input = entrée précédente + response.output (élément de raisonnement inclus) + nouveau message
input = previous_input + response.output + [
    {"role": "user", "content": "Add 1 to the result."}
]

# Filtrer l'élément type="reasoning" -> HTTP 400

Vérifié : réinsérer response.output tel quel est tout ce qu'il faut. Filtrer les éléments de sortie par type == "message" lors de l'assemblage 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-tour : renvoyer response.content tel quel comme message de l'assistant
messages = [
    {"role": "user", "content": "What's the weather in Paris?"},
    {"role": "assistant", "content": response.content},   # blocs de pensée + d'utilisation d'outil
    {"role": "user", "content": [tool_result_block]},
]

# Supprimer le bloc de pensée -> HTTP 400

Vérifié : retirer le bloc thinking du tableau de contenu renvoie 400 (avec error.type défini sur invalid_request_error).

4. Appel d'Outils

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

Chat Completions

Forme imbriquée (un objet function englobant name / parameters). Un tool_choice de 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"}},
)

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

❗ Vérifié : tool_choice: "required" ne peut pas être utilisé pendant que la pensée est activée — cela renvoie 400 Le mode de pensée ne prend pas en charge ce tool_choice ; désactiver la pensée (thinking.type="disabled") fait que la demande identique renvoie 200. Lorsque vous avez besoin de sémantique "doit appeler un outil", utilisez un tool_choice de fonction nommée à la place (comme ci-dessus, qui fonctionne avec la pensée activée), ou désactivez d'abord la pensée puis utilisez required.

Responses

Forme plate (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"]},
    }],
)

# Éléments de sortie observés : ["reasoning", "function_call"]; arguments = {"city": "Paris"}

Vérifié : copier la forme imbriquée de Chat Completions (function: {...}) dans Responses renvoie 400 — utilisez la forme plate. tool_choice: "required" est soumis à la même restriction de mode de pensée 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?"}],
)

# Observé : le contenu contient un bloc d'utilisation d'outil, nom = get_weather, input = {"city": "Paris"}

❗ L'appel d'outils en parallèle ne peut pas être désactivé, par conception de DeepSeek — la page de compatibilité officielle d'Anthropic indique, sur la ligne tool_choice, que disable_parallel_tool_use est ignoré, et la page Responses indique également parallel_tool_calls | Ignored (l'appel d'outils en parallèle est toujours activé). Les tests correspondent : demander des informations sur deux villes à la fois avec disable_parallel_tool_use: true renvoie toujours deux blocs tool_use. Si vous avez besoin d'une exécution sérielle, prenez le premier appel ou mettez-les en file d'attente vous-même du côté client.

Nombre d'outils et coût de contexte : envoyer 200 définitions de fonction dans une seule demande a toujours renvoyé 200 avec une réponse normale et n'a pas déclenché de validation de compte (observé sur ce chemin ; des comptes plus élevés n'ont pas été testés). Mais prompt_tokens pour cette demande a atteint 6 105 — les définitions d'outils entrent dans le contexte en entier et sont facturées. Lorsque vous avez de nombreux outils, réduisez l'ensemble d'outils par scénario plutôt que 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"},
)

# Contenu de réponse observé : {"a":1}

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

Responses

Déclarez un schéma JSON via text.format, avec le mode strict 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"]},
        }
    },
)

# Texte de sortie observé : {"a":1}

Vérifié : la sortie est strictement conforme au schéma donné.

Messages

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

6. Comment Activer la Mise en Cache du Contexte ? Vous Ne Pouvez Pas, C'est Automatique

La mise en cache du contexte (les préfixes identiques sont réutilisés, et la portion mise en cache est facturée à un tarif inférieur) est activée par défaut et ne nécessite aucun paramètre. Une seconde demande avec le même long préfixe rapporte le hit dans usage, sous un nom de champ qui varie selon l'API. Pour les détails de mise en cache et les prix actuels, voir la page du modèle ; pour la stratégie de mise en cache entre modèles et les techniques de taux de réussite, voir pratiques de mise en cache des invites.

Chat Completions

# utilisation du second appel avec un long préfixe identique
"prompt_tokens_details": {"cached_tokens": 640}   # premier appel : 0

Vérifié : deux appels consécutifs avec le même long préfixe sur le même canal ont déplacé cached_tokens de 0 à 640.

Responses

# utilisation du second appel avec des instructions longues identiques
"input_tokens_details": {"cached_tokens": 896}    # premier appel : 0

Messages

# utilisation d'un appel dont le long préfixe système était déjà réchauffé
"cache_read_input_tokens": 896

Vérifié : le préfixe ci-dessus a été réchauffé par une demande Responses avec un contenu identique, et le premier appel Messages a atteint 896 immédiatement — cohérent avec le fait que la mise en cache est basée sur le préfixe de contenu et partagée entre les surfaces de protocole.

7. logprobs : Chat Renvoie Deux Canaux

logprobs (log probabilités — le détail de confiance par candidat-token du modèle) revient sous des formes différentes sur les deux APIs, et le code de parsing doit les gérer 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,
)

# Observé : choices[0].logprobs contient DEUX tableaux
#   logprobs.content[]            -> tokens de la réponse finale
#   logprobs.reasoning_content[]  -> tokens du texte de pensée

❗ Vérifié : Chat renvoie des log probabilités pour à la fois content et reasoning_content. Le code qui lit uniquement logprobs.content, selon la forme de réponse standard d'OpenAI, ne déclenchera pas d'erreur mais manquera silencieusement le canal de pensée ; si votre code suppose un tableau unique sous logprobs, ajoutez d'abord une vérification de forme.

Responses

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

# Observé : logprobs uniquement sur le dernier élément de message
#   output[-1].content[0].logprobs[] avec logprob + détails top_logprobs

Vérifié : Responses attache des logprobs uniquement au dernier élément de texte — aucun des doubles canaux observés sur Chat.

Messages

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

8. Quelles APIs Peuvent Rechercher sur le Web ?

La recherche sur le Web ici est un outil côté serveur (la récupération s'exécute sur le serveur ; le client n'émet jamais la demande lui-même), et elle s'exécute réellement sur les APIs 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"}],
)

# Séquence d'éléments de sortie observée :
# ["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 réellement exécuté 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?"}],
)

# Séquence de blocs de contenu observée :
# ["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 compte 1 — la demande de récupération a vraiment eu lieu et a été mesurée.

Chat Completions

La recherche sur le 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 de recherche n'importe où dans le schéma de demande (c'est une absence établie en parcourant la liste des champs un par un ; DeepSeek n'a fait aucune déclaration explicite niant le support). L'API avec une déclaration de support officielle explicite pour la recherche côté serveur est Responses (web_search), et la page de compatibilité Messages liste également les blocs de contenu liés à la recherche.

# Trois groupes de contrôle, même question nécessitant des informations en direct, tous HTTP 200 :
# Un sans champ de recherche       -> "cannot retrieve", annotations = null
# B options_web_search    -> "cannot retrieve", annotations = null, utilisation identique à A
# C enable_search         -> "cannot retrieve", annotations = null, utilisation identique à A

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

9. Notes d'Utilisation : Conception de DeepSeek vs Déviations sur Notre Chemin

Tout ce qui suit renvoie HTTP 200 tout en se comportant de manière contre-intuitive. Les causes diffèrent, et ce que vous devez faire à leur sujet aussi, donc elles sont listées séparément : le premier groupe est comment DeepSeek a conçu le modèle, et changer de fournisseur ne changera pas cela ; le second groupe est le comportement actuel sur le chemin AIHubMix, sur lequel nous travaillons.

9.1 Par Conception de DeepSeek

9.2 Comportement Actuel sur le Chemin AIHubMix

9.3 Indéfini par DeepSeek, Donc Pas de Verdict Dans un Sens ou Dans l'Autre

Envoyer une valeur en dehors de l'énumération pour reasoning_effort (par exemple bogus_xyz) renvoie 200 avec une réponse normale, pas d'erreur, et aucun effet observable. Le fait est suffisamment clair — ce chemin ne valide actuellement pas l'énumération reasoning_effort. Ce qui n'est pas clair, c'est s'il devrait : DeepSeek publie l'énumération légale mais n'indique jamais si un niveau illégal devrait être rejeté, donc il n'y a pas de référence pour juger, ce qui signifie que cela ne compte ni comme un comportement officiel ni comme un défaut sur notre chemin. L'approche sécurisée côté client : validez le niveau vous-même et ne comptez pas sur l'API pour le détecter.

10. Matrice de Capacité × Support API

Les cellules ci-dessous donnent l'orthographe des paramètres / champs pour chaque API. Sauf indication contraire comme formulation explicite de DeepSeek, chaque conclusion provient d'appels réels effectués le 2026-08-13 contre les APIs de production AIHubMix.

Légende : ✅ vérifié fonctionnel · 🟡 accepté mais ne peut pas être confirmé efficace · ❗ nécessite une attention (voir les notes ci-dessus) · ➖ aucun concept de ce type sur cette API

FAQ

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

Pourquoi une conversation multi-tour retourne-t-elle soudainement 400 ?
La cause la plus courante est l'historique de pensée qui n'a pas été renvoyé. En mode de pensée, le contenu de pensée du tour précédent doit être rejoué tel quel : reasoning_content sur le message de l'assistant pour Chat, l'élément de sortie type="reasoning" pour Responses, et le bloc de contenu thinking pour Messages. Les multi-tours avec outils sont là où cela blesse le plus — de nombreux frameworks filtrent les éléments de sortie par type == "message" lors de l'assemblage de l'historique, ce qui supprime l'élément de raisonnement.

La pensée peut-elle être désactivée ?
Oui. Envoyez thinking: {"type": "disabled"} sur Chat ou Messages, et reasoning: {"effort": "none"} sur Responses. Une fois désactivée, à la fois le contenu de pensée et les tokens de pensée disparaissent.

Les trois niveaux de reasoning_effort diffèrent-ils ?
low / high / max sont tous acceptés (valeur par défaut high ; medium et xhigh sont mappés à high pour compatibilité). Lors des tests, les comptes de tokens de pensée pour la même question ne montrent aucune différence monotone entre les niveaux et rien n'est renvoyé, donc la différence ne peut pas être confirmée du côté de l'appelant. Seul le niveau none sur Responses (pensée désactivée) produit une différence observable claire.

Pourquoi tool_choice: "required" renvoie-t-il 400 ?
Cette valeur n'est pas acceptée pendant que la pensée est activée (le corps de l'erreur indique Le mode de pensée ne prend pas en charge ce tool_choice). Utilisez un tool_choice de fonction nommée ({"type": "function", "function": {"name": "..."}}) pour forcer un appel spécifique avec la pensée activée, ou désactivez d'abord la pensée puis utilisez required.

Comment activer la mise en cache du contexte ?
Vous ne pouvez pas — c'est automatique. Mettez le contenu stable et immuable (invites système, extraits de connaissances, définitions d'outils) au début de la demande, et le nombre de hits est rapporté dans l'utilisation : prompt_tokens_details.cached_tokens sur Chat, input_tokens_details.cached_tokens sur Responses, et cache_read_input_tokens sur Messages.

Pour les prix et l'état en temps réel, consultez la page du modèle deepseek-v4-pro-0813 ; pour plus de modèles, visitez la galerie de modèles.

Guides pratiques connexes : Guide pratique Kimi K3 (nouveaux paramètres et matrice de support à trois APIs) et changements de mise en cache des invites et de facturation de GPT-5.6.