Routing basato sullo sforzo di ragionamento in un gateway API AI: controllo dei token di pensiero, della latenza e dei costi tra i provider

La profondità del ragionamento non è più una semplice opzione del modello. Alcuni provider espongono livelli di sforzo in stile enumerazione. Altri espongono budget simbolici, pensiero dinamico o famiglie modello in cui il pensiero non può essere completamente disabilitato. La risposta visibile potrebbe essere breve mentre il ragionamento nascosto consuma token di output fatturabili. Se ogni team applicativo imposta questi controlli direttamente, costi, latenza e qualità diventano difficili da spiegare.

La risposta pratica è spostare il controllo dello sforzo di ragionamento nel gateway API. Il gateway dovrebbe classificare il carico di lavoro, associarlo a un controllo di ragionamento specifico del provider, applicare i budget dei tenant, registrare l'utilizzo effettivo del ragionamento e rendere visibili nelle analisi le decisioni di downgrade. ID modello, livello di servizio, output massimo e profondità di ragionamento dovrebbero essere dimensioni politiche separate.

Problema del lettore: le richieste semplici pagano un ragionamento approfondito

I team che adottano modelli capaci di ragionare di solito iniziano con un obiettivo ragionevole: migliorare la qualità delle attività difficili. Il problema si presenta più tardi, quando le stesse impostazioni predefinite vengono riutilizzate per l'estrazione, i riassunti brevi, la formattazione e la classificazione. Tali richieste non necessitano di costosi calcoli in fase di test, ma potrebbero comunque attivarli.

Ciò crea tre errori operativi:

• Opacità dei costi: l'utente vede una risposta breve, ma il registro contiene token di ragionamento nascosti o equivalenti specifici del provider.
• Deriva della latenza: un flusso di lavoro che sembrava interattivo diventa lento perché lo sforzo di ragionamento è aumentato dietro lo stesso modello alias.
• Frammentazione delle policy: ogni team di prodotto apprende parametri diversi del fornitore e applica limiti diversi.

Una policy di ragionamento a livello di gateway risolve il problema di controllo prima che diventi un problema di fatturazione.

Fatti: i controlli del ragionamento del fornitore non sono equivalenti

Quelli che seguono sono fatti di implementazione, non raccomandazioni.

• Le API con capacità di ragionamento OpenAI espongono un Oggetto reasoning per i modelli supportati, inclusi valori di sforzo come none, minimal, low, medium, high e xhigh. Uno sforzo inferiore può ridurre i token di ragionamento e migliorare la velocità di risposta.
• La documentazione di OpenAI afferma che max_output_tokens può limitare il totale dei token generati, inclusi sia i token di ragionamento che quelli di output finale.
• Il pensiero antropico esteso può essere abilitato con un valore budget_tokens. I token di pensiero vengono fatturati come token di output e contano per max_tokens insieme al testo di risposta visibile.
• La documentazione di Anthropic rileva inoltre che il conteggio dei token di output fatturati potrebbe non corrispondere al conteggio dei token di risposta visibili, poiché i token di pensiero interni possono essere fatturati anche quando non sono completamente visibili.
• La documentazione di Gemini thinking afferma che i prezzi di risposta possono includere sia token di output che token di pensiero, con campi di utilizzo che separano token di pensiero e token di output.
• Gemini I controlli di stile 2.5 includono thinkingBudget, con pensiero dinamico sui modelli supportati e disabilitazione a budget zero su alcune famiglie di modelli. Alcuni modelli non possono disabilitare il pensiero.
• Le linee guida Gemini più recenti consigliano valori thinking_level come minimal, low, medium e high per i modelli in stile Gemini 3.x invece di budget numerici grezzi.

L'implicazione principale dell'architettura è semplice: non esporre i controlli di ragionamento nativi del provider come unico contratto. Non sono sufficientemente stabili, sufficientemente portabili o sufficientemente comparabili per la governance multi-provider.

Raccomandazione: creare profili di ragionamento neutrali rispetto al fornitore

Definire un piccolo vocabolario interno che i team di prodotto possano comprendere senza leggere ogni riferimento all'API del fornitore.Per la maggior parte dei gateway, cinque profili sono sufficienti:

Il profilo è il contratto rivolto all'applicazione. I parametri del provider diventano dettagli dell'adattatore. Ciò mantiene il codice client portabile e consente ai proprietari della piattaforma di aggiornare le mappature man mano che cambiano le API del provider.

Mappatura delle classi di carico di lavoro prima della mappatura dei provider

Il ragionamento dovrebbe essere scelto in base all'intento del carico di lavoro, non alle preferenze personali o alla popolarità del modello. Aggiungi un campo gateway come workload_class, fornito dal client o dedotto da una configurazione di percorso approvata.

Esempio di policy del carico di lavoro

{
  "politiche_carico di lavoro": {
    "extract_invoice_fields": {
      "default_reasoning_profile": "nessuno",
      "max_reasoning_profile": "basso",
      "max_output_tokens": 800
    },
    "classify_support_ticket": {
      "default_reasoning_profile": "nessuno",
      "max_reasoning_profile": "basso",
      "max_output_tokens": 300
    },
    "bozza_cliente_risposta": {
      "default_reasoning_profile": "basso",
      "max_reasoning_profile": "standard",
      "max_output_tokens": 1200
    },
    "revisione_codice": {
      "default_reasoning_profile": "standard",
      "max_reasoning_profile": "profondo",
      "max_output_tokens": 4000
    },
    "revisione_sicurezza": {
      "default_reasoning_profile": "profondo",
      "max_reasoning_profile": "capped-deep",
      "max_output_tokens": 6000
    },
    "piano_agente": {
      "default_reasoning_profile": "standard",
      "max_reasoning_profile": "profondo",
      "max_output_tokens": 5000
    }
  }
}

Questa politica fa due cose utili. Innanzitutto, impedisce agli endpoint semplici di ereditare impostazioni predefinite costose. In secondo luogo, offre agli amministratori una superficie di revisione concreta: quali flussi di lavoro sono autorizzati a richiedere un ragionamento approfondito e con quali limiti?

Crea una matrice di compatibilità

L'adattatore gateway dovrebbe mantenere una matrice per ogni provider e famiglia di modelli. Come minimo, memorizza se il modello supporta la disabilitazione del ragionamento, l'impegno di enumerazione, il budget numerico, il pensiero dinamico, il budget massimo supportato e i campi di utilizzo per i token di ragionamento.

Esempio di forma di matrice

{
  "fornitori": {
    "fornitore_a": {
      "model_family_x": {
        "supports_reasoning": vero,
        "control_type": "effort_enum",
        "allowed_values": ["none", "minimal", "low", "medium", "high", "xhigh"],
        "can_disable": vero,
        "reports_reasoning_tokens": vero
      }
    },
    "provider_b": {
      "model_family_y": {
        "supports_reasoning": vero,
        "control_type": "budget_tokens",
        "min_budget_tokens": 1024,
        "max_budget_tokens": 32000,
        "can_disable": falso,
        "reports_reasoning_tokens": vero
      }
    },
    "provider_c": {
      "model_family_z": {
        "supports_reasoning": vero,
        "control_type": "thinking_level",
        "allowed_values": ["minimo", "basso", "medio", "alto"],
        "can_disable": falso,
        "reports_reasoning_tokens": vero
      }
    }
  }
}

Una matrice di compatibilità non è una documentazione riservata solo agli esseri umani. Dovrebbe essere una politica eseguibile. Il router di richiesta dovrebbe utilizzarlo prima dell'invio e il registro di fatturazione dovrebbe utilizzarlo durante la liquidazione.

Traduzione dei profili interni in parametri del fornitore

Le mappature dei fornitori devono essere esplicite e con versione. Non fare affidamento su una frase vaga come “usa un ragionamento più intelligente”. Il gateway dovrebbe sapere esattamente quale parametro del provider è stato inviato.

Mappatura di esempio

{
  "reasoning_profile_mappings": {
    "nessuno": {
      "effort_enum": "nessuno",
      "gettoni_budget": 0,
      "thinking_level": "minimo"
    },
    "basso": {
      "effort_enum": "basso",
      "gettoni_budget": 2048,
      "thinking_level": "basso"
    },
    "standard": {
      "effort_enum": "medio",
      "gettoni_budget": 8192,"thinking_level": "medio"
    },
    "profondo": {
      "effort_enum": "alto",
      "gettoni_budget": 20000,
      "thinking_level": "alto"
    },
    "capped-profondo": {
      "effort_enum": "alto",
      "gettoni_budget": 12000,
      "thinking_level": "alto"
    }
  }
}

Questi numeri sono esempi, non valori predefiniti universali. I budget giusti dipendono dalla famiglia di modelli, dai prezzi, dai requisiti di latenza e dai risultati della valutazione. Il dettaglio importante dell'implementazione è che il gateway possiede la mappatura e registra il parametro del provider risolto per ogni richiesta.

Fail chiuso quando una mappatura non è sicura

I controlli di ragionamento non supportati non dovrebbero diventare silenziosamente valori predefiniti del provider. Le impostazioni predefinite possono essere costose e possono cambiare nel tempo.

Utilizza uno dei tre risultati quando un profilo richiesto non può essere mappato in modo sicuro:

• Consenti: il provider/modello supporta il profilo richiesto e la politica del tenant lo consente.
• Downgrade: il profilo richiesto è superiore alla politica, quindi il gateway applica il profilo approvato più alto e registra il downgrade.
• Rifiuta: il profilo non può essere rappresentato in modo sicuro, l'affittuario richiede un comportamento rigoroso o il downgrade violerebbe le aspettative del prodotto.

Esempio di record decisionale

{
  "request_id": "req_123",
  "tenant_id": "tenant_42",
  "api_key_id": "key_abc",
  "flusso di lavoro": "code_review",
  "requested_reasoning_profile": "profondo",
  "applied_reasoning_profile": "standard",
  "decisione": "declassato",
  "decision_reason": "tenant_monthly_deep_reasoning_budget_exceeded",
  "served_provider": "provider_a",
  "served_model": "model_family_x",
  "provider_reasoning_param": {
    "sforzo": "medio"
  }
}

Questo registro delle decisioni è prezioso durante il supporto, le controversie sulla fatturazione e le indagini sulla qualità. Inoltre, impedisce regressioni invisibili della qualità durante pressioni di budget.

I controlli del budget richiedono più dei token di output massimi

Un limite massimo di token di output è necessario, ma non è sufficiente. Per i modelli capaci di ragionamento, il modello può spendere gran parte del ragionamento limite e lasciare troppo poco spazio per la risposta finale. L'utente potrebbe quindi pagare per una risposta troncata inutilizzabile.

Utilizza limiti a più livelli:

• max_reasoning_profile per tenant, chiave API e flusso di lavoro.
• max_thinking_budget o equivalente per coppia provider/modello.
• max_output_tokens per i token totali generati in cui il provider conteggia il ragionamento e l'output visibile insieme.
• daily_deep_reasoning_spend per tenant o cliente rivenditore.
• deep_reasoning_requests_per_hour per endpoint con volume elevato.
• reasoning_token_ratio_threshold per avvisi di anomalie.

Il controllo del budget dovrebbe avvenire prima dell'invio. La fase di liquidazione dovrebbe quindi riconciliare l'utilizzo effettivo dopo l'arrivo della risposta del fornitore. Se il fornitore segnala i token pensanti separatamente, conservali separatamente. Se riporta solo i token di output totali, memorizza i migliori campi normalizzati disponibili e contrassegna il livello di confidenza.

Campi registro per l'utilizzo del ragionamento

Le analisi devono mostrare la differenza tra la lunghezza della risposta visibile e lo sforzo di ragionamento pagato. Una riga del registro utile dovrebbe includere:

• tenant_id, api_key_id, end_user_id e workflow.
• requested_model, served_model, provider e alias del modello.
• requested_reasoning_profile e applied_reasoning_profile.
• provider_reasoning_param, archiviato come JSON strutturato.
• input_tokens, visible_output_tokens, reasoning_tokens_or_equivalent, cached_tokens e total_billable_tokens.
• max_output_tokens e qualsiasi budget pensato specifico del fornitore.
• latency_to_first_token_ms, total_latency_ms e stato di completamento dello streaming.
• estimated_cost_before_dispatch, reserved_budget, costo_stabilito e reconciliation_status.
• policy_decision, ad esempio consentito, declassato, rifiutato o fallback.

Non registra la catena di pensiero non elaborata per impostazione predefinita. Per la maggior parte del lavoro di governance e FinOps, i conteggi e le decisioni politiche sono sufficienti. La memorizzazione di testo di ragionamento sensibile può creare problemi evitabili di privacy, conformità e conservazione.

Flusso di implementazione

Un gateway di produzione può implementare l'instradamento dello sforzo di ragionamento come una pipeline di richieste deterministica.

1. Autentica la richiesta. Risolvi tenant, chiave API, utente, team e flusso di lavoro.
2. Classifica il carico di lavoro. Utilizza un campo client esplicito ove possibile.Per gli endpoint noti, associa la classe del carico di lavoro alla configurazione del percorso.
3. Carica policy. Unisci vincoli globali, tenant, chiave e flusso di lavoro.
4. Seleziona candidati modello. Utilizza l'alias del modello esistente o la policy di selezione del modello prima di risolvere i controlli di ragionamento.
5. Risolvi il profilo di ragionamento. Inizia dal profilo richiesto, quindi applica i valori predefiniti e massimi del flusso di lavoro.
6. Controlla compatibilità. Conferma che la coppia fornitore/modello supporta il profilo selezionato in modo sicuro.
7. Stima del costo e del budget di riserva. Includi il probabile utilizzo del ragionamento, non solo l'output visibile.
8. Invia con parametri nativi del fornitore. Invia sforzo di enumerazione, token di budget, livello di pensiero o nessun controllo del ragionamento in base all'adattatore.
9. Normalizza l'utilizzo alla risposta. Separa input, output visibile, ragionamento, memorizzato nella cache, strumento e token totali ove possibile.
10. Risolvi e avvisa. Riconcilia i costi effettivi e riservati, aggiorna le quote ed emette segnali di anomalia.

Questa pipeline mantiene il controllo del ragionamento verificabile. Offre inoltre ai team della piattaforma un unico posto in cui modificare le impostazioni predefinite quando le API del provider si evolvono.

Valutazione prima di modificare le impostazioni predefinite

Non promuovere uno sforzo di ragionamento più intenso basato solo su alcuni esempi impressionanti. Esegui valutazioni prima di modificare le impostazioni predefinite per una classe di carico di lavoro.

Misura almeno quattro risultati:

• Qualità dell'attività: accuratezza, accettazione del revisore, validità dello schema o successo della chiamata allo strumento.
• Latenza: tempo per il primo token e tempo di completamento totale.
• Costo: costo per richiesta e costo per risposta accettata.
• Insuccesso modalità: troncamento, rifiuto, output non valido, chiamate eccessive a strumenti o timeout.

La metrica chiave non è "token per richiesta". Una risposta con token inferiore che non supera la convalida potrebbe essere più costosa dopo i nuovi tentativi. Una risposta con un ragionamento più elevato può essere giustificata per la revisione della sicurezza ma inutile per l'etichettatura dei ticket. Valutare in base al flusso di lavoro.

Compromessi

La governance del ragionamento aggiunge controllo, ma non è gratuita.

• Portabilità rispetto alle funzionalità del fornitore: i profili interni mantengono portabile il codice dell'applicazione, ma i team avanzati potrebbero aver bisogno di una via di fuga approvata per controlli specifici del fornitore.
• Certezza del budget rispetto alla qualità: i limiti rigidi proteggono gli inquilini dalle spese fuori controllo, ma i limiti eccessivamente rigidi possono troncare risposte utili dopo che i token di ragionamento sono già stati spesi.
• Pensiero dinamico rispetto a prevedibilità: i controlli dinamici del fornitore possono migliorare la comodità, ma indeboliscono le stime dei costi prima dell'invio a meno che il gateway non registri l'utilizzo effettivo e applichi i limiti di liquidazione.
• Declassare la disponibilità rispetto alla coerenza: il downgrade del ragionamento durante la pressione sul budget preserva la disponibilità, ma la risposta deve essere etichettata nella telemetria e inclusa nella valutazione della qualità.
• Analitica rispetto a privacy: le metriche dei token di ragionamento sono utili, ma le tracce del ragionamento grezzo non dovrebbero essere archiviate a meno che non vi sia una politica di conservazione deliberata e approvata.

Previsione: la politica di ragionamento diventerà un controllo del gateway standard

Questa è una previsione, non un fatto verificato: lo sforzo di ragionamento diventerà un normale controllo di produzione insieme al routing del modello, ai limiti di velocità, ai livelli di servizio e ai budget dei token. Poiché i fornitori continuano a esporre controlli di pensiero diversi, i team applicativi avranno meno propensione a codificare tali differenze nel codice del prodotto.

I gateway che trattano il ragionamento come una dimensione di runtime governata avranno una fatturazione al tenant più chiara, una portabilità più pulita e un migliore controllo sulla latenza.I gateway che lo trattano come un parametro del modello incidentale avranno difficoltà a spiegare perché le risposte brevi a volte costano più di quelle lunghe.

Elenco di controllo utilizzabile

• Definisci profili interni: none, low, standard, deep e capped-deep.
• Assegna profili predefiniti e massimi a ciascun carico di lavoro class.
• Costruisci una matrice di compatibilità provider/modello per i controlli del ragionamento.
• Traduci i profili in parametri nativi del provider nel livello dell'adattatore.
• Fail closed quando un profilo richiesto non può essere mappato in modo sicuro.
• Riserva budget prima dell'invio utilizzando stime basate sul ragionamento.
• Registra il profilo richiesto, il profilo applicato, il parametro del provider, l'utilizzo del ragionamento, l'output visibile, la latenza e il costo.
• Aggiungi avvisi di anomalia per alta rapporti token di ragionamento e ragionamento approfondito in flussi di lavoro semplici ad alto volume.
• Esegui valutazioni a livello di flusso di lavoro prima di modificare l'impegno predefinito.
• Evita di registrare testo di ragionamento non elaborato per impostazione predefinita; memorizza invece i conteggi e le decisioni politiche.

Conclusione

I modelli capaci di ragionare sono utili perché possono spendere più risorse di calcolo su problemi difficili. Quella stessa capacità diventa costosa quando viene applicata indiscriminatamente. Il gateway dovrebbe decidere quando è consentito un ragionamento più approfondito, come associarlo a ciascun fornitore, quanto budget può consumare e come viene misurato il risultato.

Il modello duraturo consiste nel separare lo sforzo di ragionamento dall'ID del modello. Instradamento in base al carico di lavoro, limite in base alla politica del tenant, adattamento in base al fornitore e registrazione dell'utilizzo effettivo nel registro. Ciò trasforma il ragionamento da una variabile di costo nascosta in una superficie di controllo esplicita per il controllo dei costi dell'API AI.

Leggi correlati

• registro di fatturazione che prenota e liquida ogni chiamata modello
• alias modello interno e contratti di capacità
• streaming token accounting per utilizzo finale e parziale risposte