Questa pagina è tradotta dalla documentazione inglese. Comandi, identificatori ed esempi restano invariati. Runtime 7.24.4 · SDK 2.6.7. Testo inglese

Controlli di ragionamento del modello corrente

Stato: Attivo

Ambito: stato attuale

Ultima revisione: 2026-09-14

Responsabile: runtime di ax-code

AX Code seleziona i controlli di ragionamento usando l’ID del modello a monte e il protocollo SDK. Questi profili coprono le route Chat compatibili con OpenAI per gli ID esatti sotto indicati. Preservano il comportamento esistente di SDK nativo, GPU privata, AX Engine e gateway vincolato.

Le opzioni esplicite di ragionamento di modello e agente, e le varianti selezionate, hanno la precedenza sulla policy automatica di sforzo. Una dichiarazione negativa della capacità di ragionamento impedisce le varianti automatiche di sforzo e questi controlli ausiliari. GLM e DeepSeek mantengono il predefinito del provider quando le richieste ordinarie non selezionano uno sforzo. Le richieste ausiliarie usano i propri controlli senza modificare la selezione salvata dall’utente.

Conflitti di opzioni Qwen e strumenti forzati

Qwen 3.8 accetta reasoning_effort oppure thinking_budget, mai entrambi. Un budget di pensiero esplicito sopprime la selezione automatica dello sforzo. Quando le opzioni unite contengono sia uno sforzo sia un budget, vince lo sforzo. high e max si normalizzano in xhigh, minimal in low, e none disattiva il pensiero. Le route del piano Alibaba conservano il tetto esistente di budget di token, incluso il fallback limitato quando non è selezionato alcuno sforzo. Queste corrispondenze seguono la API Chat di Alibaba.

La modalità di pensiero di Qwen rifiuta le chiamate di strumenti forzate. Per tool_choice: required, AX Code disattiva il pensiero per quella richiesta e rimuove le opzioni incompatibili di sforzo, budget e conservazione. I turni automatici successivi degli strumenti riprendono lo sforzo selezionato. La gestione esistente degli strumenti obbligatori di DeepSeek mantiene anch’essa il pensiero disattivato per quella richiesta, come richiesto dalla sua API della modalità di pensiero.

Continuità del ragionamento

Qwen, GLM e DeepSeek riproducono il ragionamento memorizzato tramite reasoning_content. Le richieste Chat di MiniMax M2.7/M3 usano reasoning_split: true così che l’SDK riceva il ragionamento separatamente e possa riprodurlo esattamente. Questo evita di convertire il ragionamento del gateway nel formato <mm:think> usato dalle distribuzioni su GPU privata. Un reasoning_split: false esplicito conserva la riproduzione nativa di <think>. Le firme Anthropic e la gestione dei tag su GPU privata mantengono i percorsi esistenti. Vedi la API Chat di MiniMax.

Il pensiero conservato tra i turni di GLM resta facoltativo tramite il provider options.preserveThinking: true durante le richieste idonee di agenti lunghi. Invia thinking: { type: "enabled", clear_thinking: false }. Attivalo solo per una cronologia completa e non modificata dello stesso modello; può aumentare l’input fatturato. La riproduzione ordinaria dei turni di strumenti non richiede questa adesione. Z.ai documenta i requisiti di conservazione. GLM 5.3 ragiona sempre, quindi le richieste ausiliarie usano uno sforzo basso anziché disattivarlo. Controlli di GLM 5.3.

Distribuzioni personalizzate

Un gateway può esporre lo stesso ID di modello usando un dialetto di parametri diverso. Per conservare il comportamento di trasformazione precedente di un modello, imposta options.nativeReasoning: false nella configurazione del provider di quel modello:

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

Si tratta di un’esclusione locale del profilo, non di un comando per disattivare il pensiero del modello. Viene rimossa prima dell’invio della richiesta. Le varianti già configurate in modo esplicito restano controlli dell’utente. L’SDK nativo di DeepSeek non ottiene varianti di sforzo da questo profilo, perché il serializzatore installato non le supporta.

L’accettazione dell’API, la continuazione degli strumenti e la riproduzione esatta del client sono prove di compatibilità. Non dimostrano che un sistema a monte onori ogni suggerimento di sforzo, che la sua cache colpisca più spesso, o che la qualità o la velocità di scrittura del codice migliorino. Usa la valutazione del harness abbinata per i confronti a livello di compito.