Cette page est traduite de la documentation anglaise. Les commandes, identifiants et exemples sont inchangés. Runtime 7.24.4 · SDK 2.6.7. Source anglaise

Contrôles de raisonnement des modèles actuels

Statut : actif

Portée : état actuel

Dernière revue : 2026-09-14

Responsable : runtime AX Code

AX Code choisit les contrôles de raisonnement d’après l’identifiant de modèle amont et le protocole du SDK. Ces profils couvrent les routes Chat compatibles OpenAI pour les identifiants exacts ci-dessous. Ils préservent le comportement existant du SDK natif, du GPU privé, d’AX Engine et des passerelles contraintes.

Les options de raisonnement explicites du modèle ou de l’agent, ainsi que les variantes choisies, l’emportent sur la politique d’effort automatique. Une déclaration négative de capacité de raisonnement empêche les variantes d’effort automatiques et ces contrôles auxiliaires. GLM et DeepSeek conservent le défaut du fournisseur lorsque les requêtes ordinaires ne choisissent pas d’effort. Les requêtes auxiliaires utilisent leurs propres contrôles sans changer la sélection enregistrée de l’utilisateur.

Conflits d'options Qwen et outils forcés

Qwen 3.8 accepte soit reasoning_effort, soit thinking_budget, jamais les deux. Un budget de réflexion explicite supprime la sélection automatique d’effort. Lorsque les options fusionnées contiennent à la fois un effort et un budget, l’effort l’emporte. high et max se normalisent vers xhigh, minimal vers low, et none désactive la réflexion. Les routes de plan Alibaba conservent leur plafond existant de budget de jetons, y compris le repli borné lorsqu’aucun effort n’est choisi. Ces correspondances suivent l’API Chat d’Alibaba.

Le mode réflexion de Qwen refuse les appels d’outils forcés. Pour tool_choice: required, AX Code désactive la réflexion pour cette requête et retire les options incompatibles d’effort, de budget et de préservation. Les tours d’outils automatiques suivants reprennent l’effort choisi. Le traitement DeepSeek existant des outils requis maintient aussi la réflexion désactivée pour cette requête, comme l’exige son API de mode réflexion.

Continuité du raisonnement

Qwen, GLM et DeepSeek rejouent le raisonnement stocké via reasoning_content. Les requêtes Chat MiniMax M2.7/M3 utilisent reasoning_split: true afin que le SDK reçoive le raisonnement séparément et puisse le rejouer exactement. Cela évite de convertir le raisonnement de passerelle vers le format <mm:think> utilisé par les déploiements GPU privés. Un reasoning_split: false explicite conserve le rejeu natif <think>. Les signatures Anthropic et le traitement des balises de GPU privé conservent leurs chemins existants. Voir l’API Chat de MiniMax.

La réflexion GLM préservée d’un tour à l’autre reste sur activation via le options.preserveThinking: true du fournisseur pendant les requêtes d’agent long éligibles. Elle envoie thinking: { type: "enabled", clear_thinking: false }. Ne l’activez que pour un historique complet et non modifié du même modèle ; cela peut augmenter l’entrée facturée. Le rejeu ordinaire d’un tour d’outil n’exige pas cette activation. Z.ai documente les exigences de préservation. GLM 5.3 raisonne toujours, donc les requêtes auxiliaires utilisent un effort bas plutôt que de le désactiver. Contrôles de GLM 5.3.

Déploiements personnalisés

Une passerelle peut exposer le même identifiant de modèle avec un dialecte de paramètres différent. Pour conserver le comportement de transformation antérieur d’un modèle, définissez options.nativeReasoning: false sur la configuration de fournisseur de ce modèle :

{
  "provider": {
    "my-gateway": {
      "models": {
        "glm-5.3": {
          "options": { "nativeReasoning": false }
        }
      }
    }
  }
}

C’est un refus local du profil, pas une commande pour désactiver la réflexion du modèle. Il est retiré avant l’envoi de la requête. Les variantes déjà configurées explicitement restent des contrôles de l’utilisateur. Le SDK DeepSeek natif ne reçoit pas de variantes d’effort de ce profil, car son sérialiseur installé ne les prend pas en charge.

L’acceptation par l’API, la poursuite des outils et le rejeu exact côté client sont des preuves de compatibilité. Elles ne prouvent pas qu’un amont honore chaque indication d’effort, que son cache réussit plus souvent, ni que la qualité ou la vitesse de programmation s’améliore. Utilisez l’évaluation de harnais appariée pour les comparaisons au niveau de la tâche.