Ouvrez le menu des modèles de presque n'importe quel outil d'IA : il y a un deuxième menu à côté. Les réglages d'effort se trouvent maintenant dans à peu près tous les modèles phares.[1] Quand OpenAI a lancé GPT-5.6 en juillet 2026, le modèle offrait six réglages d'effort de raisonnement, de Light à Ultra, et le sélecteur prévient que le plus élevé « consumes usage limits faster » (en anglais dans l'original), c'est-à-dire qu'il épuise plus vite vos limites d'utilisation.[1] Kimi Code, l'outil de programmation de Moonshot pour son modèle K3, offre les réglages low, high et max, et max est celui par défaut.[1] Il est facile d'y voir un bouton de qualité et de le laisser là où il était. C'est un levier de coût : chaque cran de plus demande au modèle de dépenser plus de jetons à réfléchir avant de répondre, et vous payez chacun d'eux.
Ce que le réglage d'effort change vraiment.
L'effort de raisonnement est le réglage qui indique à un modèle de raisonnement combien de jetons il peut dépenser à réfléchir avant de répondre : plus l'effort est élevé, plus la trace est longue, plus la facture grimpe et, jusqu'à un certain point, meilleure est la précision. La trace, c'est le travail du modèle (la « réflexion »), écrit avant sa réponse finale. Dans les modèles à poids ouverts gpt-oss d'OpenAI, le seul endroit où OpenAI a montré le mécanisme, le réglage est une ligne ajoutée au message système, devant votre invite : « Reasoning effort: low », « medium » ou « high » (en anglais dans l'original ; effort de raisonnement faible, moyen ou élevé). Le tout est envoyé au même modèle.[1][3] Selon la lecture que Raschka fait de la fiche technique de gpt-oss, un effort plus élevé donne des réponses plus longues et une meilleure précision, et il présume que GPT-5 et GPT-5.6 fonctionnent de la même façon.[1]
Les poids restent les mêmes quand vous déplacez le curseur. Le nombre de jetons augmente, et l'attente et la facture suivent : la même requête à un réglage plus élevé est plus longue, plus lente et plus chère. Que la réponse soit aussi meilleure, cela dépend de la tâche.
L'effort s'apprend à l'entraînement, il ne s'écrit pas dans l'invite.
Comme le contrôle est une ligne de texte, on est tenté de croire que n'importe quel modèle va y obéir. Raschka est direct là-dessus : coller la ligne « Reasoning effort: low » dans l'invite système d'un modèle quelconque ne produit rien de fiable. La ligne sélectionne un comportement que le post-entraînement y a mis.[1] Il passe en revue les six modèles phares à poids ouverts dont les rapports disent comment ils y sont arrivés (DeepSeek V4, Nemotron 3 Ultra, Kimi K2.5, GLM-5, Qwen3 et Inkling) et y trouve trois ingrédients communs.[1][2] Si seule la décision d'achat vous intéresse, passez directement à quel réglage pour quel travail.
- L'interrupteur marche/arrêt vient d'exemples d'entraînement mélangés.
Qwen3 est le cas le plus net : après son entraînement au raisonnement, une étape d'affinage mélange des exemples avec une trace de réflexion et des exemples avec une trace vide suivie d'une réponse courte. À l'exécution, désactiver la réflexion revient à préremplir la trace vide, et le modèle passe directement à la réponse.
- Les niveaux viennent de ce que la réflexion coûte à l'entraînement.
En apprentissage par renforcement (RL), la récompense soustrait une pénalité par jeton, et cette pénalité dépend de l'effort demandé. Un effort faible impose une forte pénalité, donc le modèle apprend à être bref ; un effort élevé en impose une légère. DeepSeek V4 va plus loin et entraîne un spécialiste distinct par mode (Non-think, Think High, Think Max, ce dernier avec une fenêtre de contexte plus longue, une pénalité de longueur plus faible et sa propre instruction système), puis les distille dans un seul modèle.
- Les budgets stricts s'entraînent à part.
Nemotron est affiné sur des traces coupées à des longueurs aléatoires pour que le modèle puisse quand même livrer une réponse quand sa réflexion est interrompue en route. Qwen3 a acquis le même comportement d'arrêt suivi d'une réponse sans y avoir été entraîné. Kimi alterne des tours d'entraînement avec budget et sans budget (plus de détails plus loin).
Pour un exploitant, deux choses en découlent. Si vous hébergez vous-même un modèle ouvert, utilisez le contrôle que sa documentation nomme (un paramètre du gabarit de conversation, un paramètre d'API, un réglage de budget), pas une phrase que vous avez écrite vous-même. Et le même mot veut dire des choses différentes d'un fournisseur à l'autre : « élevé » sur un modèle et « élevé » sur un autre sont le produit de recettes différentes et ont été achetés avec des budgets différents. Comparez les réglages d'après ce qu'ils coûtent et ce qu'ils donnent sur vos tâches, pas d'après leur nom. Notre note sur le rapport de Kimi K3 montre en détail l'échelle d'un laboratoire : un budget de jetons par problème, toute exécution qui le dépasse étant notée comme un échec même quand elle a résolu le problème.
Plus d'effort, des gains plus petits.
Le réglage achète de la précision avec des jetons, et le taux de change se dégrade à mesure qu'on monte. Raschka le montre de trois façons. Dans la fiche technique de gpt-oss, un effort plus élevé donne des réponses plus longues et de meilleurs scores.[1][3] Dans la parution d'Inkling de Thinking Machines, qui expose l'effort comme un nombre continu, l'augmenter fait généralement monter à la fois les jetons et les scores, « with diminishing or uneven gains at higher effort » (en anglais dans l'original), c'est-à-dire avec des gains décroissants ou inégaux à effort plus élevé.[1] Et sur l'Artificial Analysis Coding Agent Index v1.1 (un composite de trois bancs d'essai d'agents de programmation), le coût de GPT-5.6 Sol grimpe à chaque réglage tandis que son score plafonne près du sommet.[1][4] La synthèse de Raschka : augmenter les budgets de raisonnement « can become uneconomical at some point » (en anglais dans l'original), c'est-à-dire que cela peut finir par ne plus être rentable.[1]
Le haut du menu est l'endroit où l'argent part le plus vite. Ultra sur GPT-5.6, selon la légende de Raschka, utilise un niveau d'effort semblable à celui de Max, mais accélère le travail avec quatre sous-agents. Il s'attend à ce que ses scores soient proches de ceux de Max ; les résultats de bancs d'essai pour ce réglage n'étaient pas encore disponibles.[1] Si c'est le cas, Ultra achète de la vitesse plutôt que du score, et le sélecteur lui-même prévient qu'il épuise plus vite vos limites d'utilisation.
Deux leviers : taille du modèle et effort.
Le cadre le plus utile de Raschka pour un acheteur : le menu des modèles et le menu de l'effort sont deux façons distinctes de dépenser de l'argent.[1] Choisir Luna, Terra ou Sol (les trois tailles de GPT-5.6) revient à choisir un modèle entraîné différent, et un plus gros modèle coûte généralement plus cher à faire tourner par jeton. Déplacer le réglage d'effort garde le modèle et change le nombre de jetons qu'il dépense. Sur les courbes d'Artificial Analysis qu'il trace, chaque modèle dessine sa propre ligne à mesure que l'effort monte, et les lignes se chevauchent : un modèle plus petit à effort plus élevé peut parfois atteindre le score d'un modèle plus gros à effort plus faible, à un coût et à une vitesse différents.[1][4]
Cela fait du réglage d'effort une décision de routage. Si un petit modèle à effort élevé fait aussi bien le travail qu'un gros à effort faible, choisissez celui qui coûte le moins cher par tâche terminée, à la vitesse dont vous avez besoin : une longue trace sur un modèle bon marché est plus lente, tandis qu'une courte trace sur un modèle coûteux revient plus cher par jeton. Raschka ajoute que l'axe horizontal est le coût d'API, qui dépend de la tarification du fournisseur et du nombre de jetons générés.[1] Selon notre lecture, la réponse change donc chaque fois qu'une liste de prix change.
Une bonne part de la réflexion supplémentaire était du gaspillage.
La preuve la plus nette que les traces de raisonnement comportent du superflu vient du rapport Kimi K2.5 de Moonshot.[2] Il décrit une méthode d'entraînement appelée Toggle, qui alterne deux sortes de tours d'apprentissage par renforcement. Dans les tours avec budget, une bonne réponse est poussée à tenir dans un budget de jetons par problème, fixé d'après la longueur des bonnes réponses antérieures et activé seulement une fois que le modèle résout ce problème de façon fiable. Dans les tours sans budget, la pleine longueur est rétablie pour que le modèle garde la capacité de réfléchir longtemps quand il en a besoin. Testée sur le modèle K2 Thinking, plus ancien, la méthode Toggle a, selon le rapport, réduit les jetons générés d'environ 25 à 30 % avec peu de changement dans la performance aux bancs d'essai.[1][2]
Pour un exploitant, l'ampleur de la coupe compte plus que le laboratoire. Un quart ou plus des jetons de réflexion du modèle ont été retirés et les scores ont à peine bougé : beaucoup de ces jetons n'achetaient donc rien. Cela ne vous dit pas où se situe votre propre travail dans le menu d'effort, mais c'est une raison de tester un cran plus bas avant de supposer que le réglage le plus élevé vaut ce qu'il coûte.
Quel réglage pour quel travail.
Le pari final de Raschka, c'est la sélection automatique de l'effort : un routeur peu coûteux qui choisit le réglage d'après la demande, l'état des outils et le budget restant, avec la possibilité de le forcer à la main.[1] OpenAI l'a tenté avec le mode Auto de GPT-5, et il note que ce mode semble avoir disparu de l'interface. En attendant que les routeurs soient bons, le choix vous revient. Voici les points de départ que nous utilisons, et ils ne sont que cela : notre pratique, pas une recommandation d'un fournisseur, et chacun doit être mis à l'essai sur vos propres tâches.
| le travail | point de départ | pourquoi |
|---|---|---|
| trier, étiqueter, extraire des champs d'un formulaire propre | désactivé ou au plus bas | La réponse est courte et vérifiable ; une longue trace ajoute du coût et du délai, pas de la précision. |
| rédiger une réponse à partir d'un gabarit ou de faits connus | faible à moyen | Un peu de planification aide le ton et l'ordre ; les faits viennent de ce que vous remettez au modèle, pas du fait qu'il réfléchit plus longtemps. |
| travail en plusieurs étapes avec une vérification à la fin (du code avec des tests, une conciliation) | élevé, puis tester plus bas | C'est là que l'effort rapporte. Comme on peut vérifier le résultat, on voit si le réglage inférieur tient le coup. |
| longues exécutions d'agent sans surveillance | moyen plus budget strict | Le coût s'accumule à chaque étape ; sur le travail d'agent, un budget peut aussi compter les appels d'outils, pas seulement la réflexion. |
| le réglage le plus élevé (Max, Ultra) | par exception | Rendements décroissants, et les jetons les plus chers du menu. À réserver au cas difficile que vous avez déjà vu échouer un cran plus bas. |
Un contrôle à faire dès aujourd'hui : regardez quel est le réglage par défaut de chaque outil que vous payez. Si le défaut est le réglage le plus élevé, comme dans Kimi Code selon sa documentation, chaque requête courante dépense le plus de jetons de réflexion du menu et, avec un forfait, épuise votre limite d'utilisation le plus vite.[1]
Chiffrez-le sur votre propre travail.
Les bancs d'essai montrent la forme de la courbe. Pour savoir où se situe votre propre travail, il faut un test, et il est peu coûteux : un après-midi.
- Choisissez 20 vraies tâches dont le bon résultat est connu.
Dans votre propre file d'attente : des billets déjà résolus, des factures déjà conciliées, des modifications de code déjà approuvées en revue.
- Exécutez-les au réglage actuel et un cran plus bas.
Ajoutez un cran au-dessus pour les tâches qui ont échoué. Même modèle, même invite, mêmes outils ; ne changez que l'effort.
- Consignez les jetons et la réussite ou l'échec de chaque exécution.
Réussite veut dire que vous auriez utilisé le résultat tel quel. Le rapport d'utilisation de votre fournisseur ou la réponse de son API donne le nombre de jetons par appel ; c'est votre coût.
→ le chiffre à comparer : le coût par résultat accepté, pas le coût par appel - Descendez d'un cran partout où le taux de réussite tient.
Puis refaites le test quand le fournisseur lance un nouveau modèle ou change ses prix, car les deux déplacent la courbe.
Si vous suivez déjà le coût par étape d'agent, comme dans notre suivi du coût par étape, le réglage d'effort n'est qu'une colonne de plus. Pour les agents qui bouclent, jumelez le réglage à un arrêt strict ; notre planificateur qui sait s'arrêter applique la même idée un niveau plus haut, à l'ensemble des étapes d'un agent plutôt qu'à l'intérieur d'une seule réponse.
Ce que cette note ne prétend pas.
Des chiffres de fournisseurs, relayés. Le résultat de Toggle, la mise à l'échelle de gpt-oss et le balayage d'Inkling sont chacun des affirmations d'un laboratoire sur son propre modèle, lues par Raschka. Nous les citons telles que rapportées et ne les avons pas reproduites.
La méthode d'OpenAI est une reconstruction. OpenAI n'a pas publié la façon dont les réglages de GPT-5.6 sont entraînés. Raschka qualifie son propre schéma à ce sujet de « a possible implementation, not a confirmed description » (en anglais dans l'original), c'est-à-dire une mise en œuvre possible, pas une description confirmée, et les passages de cette note sur GPT-5.6 reposent sur son interface et sur des résultats de bancs d'essai, pas sur son entraînement.
Les bancs d'essai ne sont pas votre travail. Les courbes d'Artificial Analysis proviennent de bancs d'essai d'agents de programmation, et Raschka note que leur forme exacte est propre à chaque banc d'essai. La figure à deux leviers ci-dessus est un schéma de cette forme, sans données tracées.
Le tableau de routage est le nôtre. C'est un point de départ tiré de la façon dont nous réglons nos propres outils, pas une mesure. Le test en quatre étapes sert à le remplacer par vos propres chiffres.
Vous ne savez pas combien vos outils d'IA dépensent à réfléchir ? Envoyez-nous un mois d'exportations d'utilisation (sans données de clients) par le formulaire de contact et nous vous dirons, par écrit, quels réglages semblent valoir un essai un cran plus bas. L'optimisation des coûts fait partie de notre travail en assistants et agents.