Accueil → Aide

400 unsupported parameter sur un modèle de raisonnement

Les modèles de raisonnement fixent leur propre échantillonnage. Envoyer temperature, top_p ou les paramètres de pénalité est refusé net plutôt qu'ignoré, donc un constructeur de requêtes partagé qui les définit toujours casse dès que vous le pointez vers l'un d'eux.

Ce que vous voyez

400 unsupported_parameter: 'temperature' is not supported with this model
Unsupported value: 'temperature' does not support 0.7 with this model
The identical request works if you switch to a non-reasoning model
invalid_request_error mentioning top_p, presence_penalty or frequency_penalty

Pourquoi cela arrive

La chaîne de raisonnement est produite avec des réglages contrôlés par le fournisseur. Permettre à l'appelant de les modifier changerait le comportement pour lequel le modèle a été ajusté, donc l'API refuse plutôt que d'écraser en silence.

La plupart des bibliothèques définissent temperature par défaut. Le paramètre est dans la requête même si vous ne l'avez jamais écrit, et c'est pourquoi l'erreur apparaît dans du code qui « n'utilise pas temperature ».

L'ensemble des paramètres refusés varie d'une famille de modèles à l'autre et change au fil des versions. Une liste d'exceptions codée en dur vieillit mal.

Comment le corriger

Omettez les paramètres d'échantillonnage au lieu de fixer des valeurs par défautConstruisez la requête sans temperature ni top_p, sauf si l'appelant les a explicitement demandés. Envoyer temperature=1 « par sécurité », c'est quand même l'envoyer.
Faites une branche selon le modèle, pas selon l'erreurGardez une petite table des modèles qui acceptent les paramètres d'échantillonnage et retirez-les avant l'appel. Intercepter le 400 et relancer fonctionne, mais double la latence de chaque requête.
Utilisez le réglage d'effort de raisonnement quand il existeQuand un modèle expose un réglage d'effort ou de budget de réflexion, c'est le bouton prévu pour vous. C'est aussi lui qui explique l'écart de coût entre deux exécutions.

Sur APICLAN, la sortie de raisonnement est facturée comme des tokens de sortie, donc les réglages d'effort agissent directement sur la facture. La page de chaque modèle indique le tarif, et votre journal d'utilisation décompose chaque appel en entrée, sortie, lecture de cache et écriture en cache.

Voir aussi

Unexpected token '<' lors d'un appel à une API compatible OpenAI 401 invalid API key : quand la clé semble correcte mais échoue quand même

Dernière vérification le 2026-10-01. Rédigé à partir de problèmes diagnostiqués sur une passerelle compatible OpenAI en production, pas compilé à partir d'autres sites.