Contrôles de raisonnement LLM : comportement de 13 modèles

Le même paramètre de contrôle du raisonnement signifie trois choses différentes selon le modèle auquel vous l’envoyez : thinking_budget: 16 consomme exactement 16 jetons de raisonnement sur Qwen 3.8 Max, GLM 5.2 et les deux versions de DeepSeek V4, est ignoré silencieusement sur Kimi K3 et MiniMax M3, et est rejeté avec une erreur 400 par GPT-5.6. Nous avons sondé 13 modèles de neuf fournisseurs avec toutes les orthographes de contrôle que la surface compatible OpenAI accepte, puis mesuré ce que chaque position du curseur coûte en jetons de raisonnement et ce qu’elle casse en précision, sur les quatre mêmes tâches salées, trois exécutions par cellule.

TL;DR

• thinking: {"type": "disabled"} met le raisonnement à zéro sur 11 des 13 modèles ; les deux exceptions (Gemini pro, GPT-5.6) le rejettent.
• Qwen, GLM et DeepSeek consomment thinking_budget: 16 comme exactement 16 ; Kimi et MiniMax acceptent le champ sans rien changer : Kimi en a consommé 8-97 par rapport à ce plafond, jamais 16.
• La désactivation du raisonnement a fait chuter l’arithmétique à 5 étapes de 3/3 à 0-1/3 sur huit modèles ; DeepSeek V4 Pro et Claude ont maintenu 3/3 en inscrivant les étapes dans la réponse visible.
• L’extraction JSON a obtenu 3/3 avec le raisonnement désactivé sur les 12 modèles qui prennent en charge la désactivation.

Quels contrôles de raisonnement chaque API accepte-t-elle ?

Les interfaces compatibles OpenAI exposent trois familles de contrôles, mais aucun modèle ne les respecte toutes. reasoning_effort accepte une valeur d’énumération, de none à max. thinking_budget prend un nombre de tokens. thinking: {"type": "disabled"} et sa variante enable_thinking: false demandent une désactivation complète. Voici la matrice d’acceptation mesurée avec une question simple et salée par cellule :

Deux lignes méritent un signalement. Google divise sa propre ligne : le palier flash se désactive proprement tandis que le palier pro rejette toute orthographe de désactivation avec une erreur 400, ce qui correspond à la position de Google selon laquelle le raisonnement de classe pro ne peut pas être désactivé. Et les deux cellules claude-fable-5 marquées « accepted » diffèrent du contrat publié par Anthropic pour ce modèle, qui précise que le raisonnement ne peut pas être désactivé ; considérez ces cellules comme instables.

« Accepté » signifie-t-il « appliqué » ?

Non, et l’écart est facturé. Une réponse 200 indique seulement que le paramètre a été analysé, pas qu’il est arrivé jusqu’au modèle. Le test est simple : envoyez un budget de 16 et consultez le compteur.

Qwen, GLM et les deux versions de DeepSeek ont brûlé exactement 16. Kimi a brûlé 8, 19, 79 et 97 face au même plafond sur quatre exécutions, jamais 16, et MiniMax s’est comporté de la même manière à 18-44, facturé comme d’habitude, sans que rien dans la réponse ne laisse entendre que le plafond avait été abandonné. Gemini traduit les budgets dans son contrôle natif à une granularité grossière : sur flash, les plafonds de 0 à 64 se comportaient comme un arrêt total tandis que 1,024 autorisait la réflexion (médiane de 141 sur notre tâche à 5 étapes) ; le palier pro réduisait sa consommation sous un plafond mais plafonnait autour de 200 face à un plafond demandé de 64 et ne peut atteindre zéro. GPT-5.6 et Claude se situent à l’extrémité honnête du spectre : les budgets numériques sont rejetés avec un 400 et vous savez immédiatement où vous en êtes.

En pratique, après avoir défini un contrôle du raisonnement, consultez completion_tokens_details.reasoning_tokens dans la réponse suivante et vérifiez que la valeur a changé. Un contrôle qui échoue explicitement coûte une nouvelle tentative. S’il échoue silencieusement, vous payez à chaque appel les tokens de raisonnement que vous pensiez avoir plafonnés.

Existe-t-il un interrupteur universel ?

thinking: {"type": "disabled"} est ce qui s’en approche le plus : il a mis le raisonnement à zéro sur 11 des 13 modèles, couvrant Kimi, Qwen, les deux DeepSeeks, GLM, Gemini flash, MiniMax, la gamme Seed de ByteDance et les trois modèles Claude. Son sosie enable_thinking: false lui correspond presque partout, avec une exception silencieuse : MiniMax l’accepte et continue de raisonner (31 jetons de raisonnement lors de notre test).

Les deux exceptions échouent bruyamment plutôt que silencieusement : Gemini pro renvoie une erreur 400 pour chaque orthographe erronée (le palier ne peut pas désactiver la réflexion), et GPT-5.6 rejette aussi le champ. GPT-5.6 n’a pas besoin d’interrupteur d’arrêt au même sens : gpt-5.6-luna ne consomme aucun token de raisonnement pour les recherches et extractions simples par défaut (le modèle à deux leviers de cette famille), et reasoning_effort: "none" fixe ce comportement pour les entrées de forme mathématique également.

Quel est l’impact de la désactivation sur la précision ?

Sur une chaîne arithmétique en 5 étapes, l’impact est total : dès que le raisonnement est désactivé, huit modèles passent de 3/3 à 0/3 ou 1/3. Sur un problème textuel en 2 étapes, la baisse est bien plus faible. La plupart des modèles restent à 3/3 sans raisonnement. Seuls Kimi et MiniMax tombent à 0/3, avec le même état désactivé fragile que l’étude de K3 avait relevé sur sa version de lancement. Le décrochage apparaît lorsque le nombre d’étapes dépasse ce que le modèle peut traiter en un seul passage visible.

Les trois modèles qui résistent utilisent la même méthode : lorsque le raisonnement est désactivé, ils écrivent les étapes intermédiaires dans la réponse visible. La réponse médiane de DeepSeek V4 Pro passe de 115 à 142 tokens, celle de Sonnet 5 de 70 à 139. Vous ne payez plus le raisonnement caché, mais le raisonnement visible. Sur la plupart des grilles tarifaires, les deux sont facturés au même tarif de sortie. Le bouton de désactivation déplace donc surtout la dépense au lieu de la supprimer. Les modèles qui répondent docilement en 1 à 4 tokens lorsqu’il est désactivé sont précisément ceux dont la précision s’effondre.

Lorsqu’une chute se produit, un petit budget suffit à rétablir la précision. thinking_budget: 256 ramène Qwen et les deux versions de DeepSeek à 3/3, avec une médiane comprise entre 77 et 128 tokens de raisonnement. C’est le même mécanisme de rattrapage par budget minimal que nous avons mesuré sur le réentraînement de DeepSeek et sur les limites cachées de Qwen 3.8.

Une cellule de notre matrice n’a produit aucun chiffre : claude-fable-5 a renvoyé stop_reason: "refusal" (catégorie cyber) pour la formulation exacte de notre problème arithmétique lors des 12 exécutions sur 12, quel que soit le niveau d’effort. Une reformulation sémantiquement identique a réussi 12 fois sur 12. Anthropic décrit le refus comme une raison d’arrêt à part entière, avec un mécanisme de fallback activable. Si votre rotation comprend des modèles de la classe fable, gérez cette raison d’arrêt avant qu’elle ne survienne en production.

Qu’apportent réellement les niveaux d’effort ?

La courbe varie d’un fournisseur à l’autre, et seule celle de Google progresse régulièrement. Nous avons exécuté chaque valeur acceptée par chaque modèle sur la même tâche en 5 étapes, avec trois essais par position, puis tracé les médianes sur une échelle commune :

Les courbes se répartissent en quatre catégories. Réglages effectifs : les deux Gemini progressent de façon monotone, de 137 à 390 tokens de raisonnement sur flash et de 180 à 387 sur pro, avec un plafonnement au niveau high. Le niveau low conserve une précision de 3/3 en consommant entre un tiers et la moitié des tokens des positions les plus élevées. C’est donc le réglage par défaut à fixer dans les pipelines Gemini. Courbes plates : DeepSeek passe de 78 au niveau low à 54 au niveau max, avec une légère baisse ; Kimi de 94 au niveau minimal à 67 au niveau max ; MiniMax oscille entre 61 et 93 sans ordre particulier. Ces modèles exposent plusieurs positions, mais aucune ne produit de changement réel. La fiche de DeepSeek publie pourtant des benchmarks en « max reasoning effort », un réglage que nous avions déjà trouvé impossible à distinguer de la valeur par défaut. Plafonds non atteints : les niveaux de Qwen servent de limites budgétaires, mais restent invisibles sur une tâche de cette taille (85-156 sans tendance). Ils n’ont d’effet que sur les tâches longues, comme l’ont montré nos mesures dédiées. Comportement non monotone : le niveau high de GLM consomme 116 tokens, contre 184 au niveau low et 345 au niveau max. Tant que cette correspondance n’est pas stabilisée, considérez ses positions intermédiaires comme non ordonnées. Les deux modèles adaptatifs ont à peine besoin de ce réglage : gpt-5.6-luna varie seulement de 32 à 41 tokens sur toute l’énumération, et le paramètre output_config.effort d’Opus 5 ne fait varier la sortie visible que dans la marge de bruit (54-63 tokens, même constat pour Sonnet 5 avec 71-92). Le raisonnement adaptatif prend la décision réelle.

La règle opérationnelle découle directement de ces courbes. Sur Gemini, choisissez explicitement un niveau, car chaque palier a un coût réel. Sur Qwen, GLM et DeepSeek, utilisez thinking_budget, qui est exact, ainsi que l’interrupteur de désactivation, plutôt que l’énumération. Sur les autres modèles, les positions entre off et la valeur par défaut sont décoratives. Pour identifier le comportement d’un modèle, il faut effectuer le test par paliers décrit ci-dessus : même tâche, toutes les positions, puis lecture du compteur.

La forme de la tâche compte aussi. Sur notre extraction JSON en une seule étape, le raisonnement activé a produit les consommations les plus élevées de toute la matrice : 377 tokens de raisonnement sur GLM et 332 sur Gemini flash. Ce coût n’a apporté aucun gain, puisque les 12 modèles permettant de désactiver le raisonnement ont tous obtenu 3/3 sur cette tâche une fois celui-ci coupé. L’extraction structurée paie la plus forte taxe de raisonnement inutile, alors que c’est précisément le type de charge pour lequel la désactivation est sûre.

Peut-on voir ce qui est facturé ?

Le compteur de facturation est universel, mais le raisonnement ne l’est pas. Six modèles issus de familles open weight renvoient le texte du raisonnement dans reasoning_content. GLM 5.2 et DeepSeek V4 Pro ont renvoyé ce qui ressemble à la chaîne complète : 508 et 312 caractères pour respectivement 167 et 100 tokens de raisonnement. Kimi, Qwen, DeepSeek Flash, MiniMax et Seed ont fourni des traces plus courtes, globalement cohérentes avec leur faible consommation. GPT-5.6 et les deux Gemini ne renvoient rien : les tokens de raisonnement sont facturés mais restent invisibles. Claude renvoie des blocs thinking dont le contenu est omis par défaut sur l’interface que nous avons mesurée. Vous savez donc qu’un raisonnement a eu lieu, sans pouvoir le consulter.

Cette différence de visibilité complique le débogage des budgets. Pour les modèles qui ne renvoient rien, le champ reasoning_tokens des détails d’usage est le seul instrument disponible. Il faut se fier au compteur, pas au code 200.

FAQ

Comment désactiver le raisonnement sur une API compatible OpenAI ?

Envoyez thinking: {"type": "disabled"} ; dans notre matrice de 13 modèles, cela a mis le raisonnement à zéro sur 11 (Kimi, Qwen, DeepSeek x2, GLM, Gemini flash, MiniMax, Seed et la famille Claude). Gemini pro ne peut pas être désactivé et renvoie une erreur 400 ; GPT-5.6 rejette le champ mais réfléchit à peine sur les tâches simples par défaut. Vérifiez en lisant reasoning_tokens sur la réponse suivante.

thinking_budget: 0 désactive-t-il le raisonnement ?

Cela dépend du modèle. Sur Gemini flash et ByteDance Seed, 0 se comporte comme une désactivation nette ; Qwen et DeepSeek rejettent 0 avec une erreur 400 ; Kimi et MiniMax acceptent n’importe quel budget et l’ignorent. Là où les budgets sont appliqués au token près (Qwen, GLM, DeepSeek), la valeur utile minimale est un petit nombre positif : 256 a tenu 3/3 sur Qwen et sur les deux versions de DeepSeek pour notre tâche en 5 étapes, tandis que GLM a fléchi à 2/3 avec le même paramètre.

Peut-on désactiver le raisonnement sans risque pour l’extraction JSON ?

Oui dans nos tests. L’extraction en une étape a obtenu 3/3 sans raisonnement sur tous les modèles qui permettent de le désactiver. Avec le raisonnement activé, la même sortie a consommé jusqu’à 377 tokens de raisonnement. La limite dépend du nombre d’étapes, pas du format de sortie : sans raisonnement, les tâches à plusieurs étapes se sont effondrées sur 8 modèles sur 11. Une réserve issue de notre étude de DeepSeek : sur le réentraînement 0731, le raisonnement activé altérait les valeurs en JSON strict. Dans ce cas, le désactiver corrige aussi la sortie.

Quels modèles appliquent exactement les budgets de raisonnement ?

Qwen 3.8 Max, GLM 5.2 et les deux versions de DeepSeek V4 : demandez 16, le compteur affiche 16. Kimi K3 et MiniMax acceptent le même champ et l’ignorent ; Gemini le traduit grossièrement (les petites valeurs agissent comme off sur flash, pro plafonne à high) ; GPT-5.6 et les modèles de la génération Claude 5 rejettent purement et simplement les budgets numériques (le budget_tokens de Claude renvoie une erreur 400 pointant vers la réflexion adaptative).

Mesuré les 11-12/08/2026 via la passerelle Synthorai : sondes d’acceptation pour reasoning_effort (7 valeurs), thinking_budget (0/16/1024), enable_thinking et thinking:{"type":"disabled"} sur 13 modèles, revérifiées quelques heures avant publication ; puis une matrice fiscale de 552 appels (quatre formes de tâche salées x 3 exécutions par bras, les bras étant limités aux commandes vérifiées comme fonctionnelles de chaque modèle), une échelle d’énumération complète de 183 appels sur la tâche à 5 étapes (les données du graphique), des cellules de complément et une sonde de visibilité du raisonnement par modèle. Précision évaluée à partir des réponses brutes ; médianes de jetons sur n=3 ; jetons de raisonnement lus depuis completion_tokens_details.reasoning_tokens (les modèles Claude ne rapportent que les jetons de sortie). Prompts salés par appel. La sémantique des cadrans et les énumérations constituent la surface que nous avons mesurée à cette date et peuvent changer ; resondez avant de vous fier à une quelconque cellule.

← Retour au blog