La lotteria dell'ID del modello: stessa richiesta, estrazione diversa

Dietro una porta di accesso multi-provider, un ID del modello non specifica cosa serve la tua richiesta. Nomina un insieme di distribuzioni con configurazioni di erogazione diverse e, a meno che non si pinni una in particolare, ogni richiesta è un'estrazione da quell'insieme. Abbiamo misurato questo nel modo più difficile: nella nostra valutazione di moonshotai/kimi-k2.5 tramite OpenRouter (186 chiamate, iniziate il 2026-04-22, round finali nei giorni successivi), la stessa configurazione di richiesta, stesso ID del modello, stessa indicazione provider: { sort: "latency" }, stesso set di dieci prompt, ha prodotto una mediana di 312 ms di tempo al primo token con zero caratteri di reasoning trasmessi in streaming in un round, 10 chiamate su 10, e 3.073 ms con una mediana di 2.627 caratteri di reasoning in un round successivo, ancora 10 chiamate su 10. Un provider diverso ha erogato lo stesso ID con un comportamento materialmente diverso, senza alcuna modifica del nostro codice. I metadati della risposta indicano effettivamente il provider che ha erogato la richiesta, se si pensa di registrarlo; nulla segnala che il comportamento sia cambiato.

Il risultato più significativo è che la flag di instradamento che ci aspettavamo di prevenire esattamente questo non l'ha fatto nei nostri test. Se il tuo prodotto dipende dalla profondità del reasoning, l'ID del modello nella tua configurazione non è ciò che hai distribuito. Quello che hai distribuito è un biglietto della lotteria e i controlli di instradamento della porta di accesso sono suggerimenti da verificare, non contratti su cui fare affidamento.

La stessa richiesta, due volte

Stavamo benchmarkando modelli candidati per un assistente di conformità, quindi ogni configurazione eseguiva gli stessi set di prompt: dieci prompt standard di conformità (spiega l'Allegato A.5.1 ISO 27001, l'Articolo 32 GDPR, il CC6.1 SOC 2, e così via) e cinque prompt complessi costruiti per la sintesi multi-framework, il tipo di domanda in cui la profondità del reasoning si mostra effettivamente. Per ogni chiamata abbiamo registrato il tempo al primo token, il tempo totale, i caratteri di reasoning trasmessi in streaming, i caratteri di contenuto trasmessi in streaming e il campo provider che OpenRouter restituisce in ogni chunk dello stream.

Con sort: "latency", i primi round instradavano tutte e dieci le chiamate del set standard a un provider ospitante (BaseTen): 312 ms di mediana al primo token, zero caratteri di reasoning trasmessi in streaming in ogni chiamata. In un round successivo, a distanza di giorni, la stessa configurazione di richiesta instradava tutte e dieci le chiamate a un provider diverso (ModelRun): 3.073 ms di mediana, 2.627 caratteri di reasoning di mediana. Un round ancora successivo instradava di nuovo al primo provider. Questo è ciò che sort: "latency" fa per progettazione. La documentazione di OpenRouter sulla selezione dei provider (consultata il 2026-07-15) afferma che con un sort esplicito, "il bilanciamento del carico sarà disabilitato e il router proverà i provider in ordine", ordinati in base alla latenza misurata. La latenza misurata cambia, quindi l'ordine cambia e, nei nostri test, cambia anche se viene prodotto output di reasoning.

Un aumento di latenza di 10 volte è fastidioso. Un comportamento che si inverte su e giù sotto un ID di modello stabile è un problema di classe diversa, perché nulla te lo segnala. Ogni risposta era un HTTP 200 con contenuto fluido e una contabilità dei token plausibile.

La flag che ci aspettavamo di individuarlo

Non abbiamo accettato il risultato con zero reasoning a prima vista. Abbiamo provato a forzare il reasoning sul percorso veloce con ogni parametro offerto dall'API: reasoning: { enabled: true }, reasoning: { effort: "high" }, reasoning: { max_tokens: 1024 }. Zero caratteri di reasoning trasmessi in streaming, ogni volta, ogni volta che la richiesta era erogata da quel provider.

Poi abbiamo cercato il controllo di instradamento. La documentazione di OpenRouter descrive require_parameters in questo modo: "Quando imposti require_parameters su true, la richiesta non verrà instradata nemmeno a quel provider", riferendosi ai provider che non supportano tutti i parametri nella tua richiesta (documentazione sull'instradamento dei provider, consultata il 2026-07-15). Abbiamo impostato require_parameters: true accanto a reasoning: { effort: "high" }. La richiesta è stata instradata comunque allo stesso provider e la risposta non conteneva nuovamente testo di reasoning.

Prima di trarre conclusioni, abbiamo verificato il formato dei nostri parametri rispetto a distribuzioni note per essere valide, perché "il modello non fa reasoning" e "questo endpoint non espone reasoning" sembrano identici dall'esterno. Pinzando a DeepInfra, lo stesso ID del modello ha prodotto 3.116 caratteri di reasoning senza flag e 3.807 con reasoning: { enabled: true }. Pinzando a Novita: 3.460 caratteri. Questi test risolvono la domanda che conta: la famiglia del modello fa reasoning, la nostra sintassi di richiesta era valida e la variabile era l'endpoint di erogazione, non il modello.

Per essere precisi su ciò che questo mostra e ciò che non mostra: require_parameters è documentato come filtro dei provider in base al supporto dei parametri e, dalle sole risposte, non possiamo dire se i nostri risultati con zero reasoning riflettessero i metadati di capacità dell'endpoint, la gestione dei parametri lato provider o una configurazione di erogazione che semplicemente non espone testo di reasoning. Un endpoint che non espone reasoning può essere una scelta di erogazione deliberata e legittima; un tempo al primo token di 312 ms è un prodotto reale da offrire e zero caratteri di reasoning trasmessi in streaming dimostra solo che non è stato esposto reasoning a noi, non che non sia avvenuto alcun calcolo. Quello che possiamo dire è più ristretto e più utile: nei nostri test di aprile 2026, dichiarare il parametro di reasoning come richiesto non ci ha instradato verso un endpoint le cui risposte contenevano output di reasoning. Qualunque sia il meccanismo, il contratto pratico che pensavamo di avere non ha retto e solo la misurazione dell'output ci ha informato.

Perché un prodotto di conformità se ne accorge, e perché il tuo potrebbe non farlo

Ecco la parte scomoda, esposta chiaramente: nei nostri cinque prompt complessi, la configurazione con zero reasoning sembrava comunque competente. Chiedendo di trovare sovrapposizioni di controlli e un conflitto tra ISO 27001, GDPR Articolo 32 e PCI DSS per una società SaaS di 50 persone, ha prodotto un'analisi strutturata con riferimenti specifici agli articoli, come registrato nei nostri appunti di esecuzione: controlli ISO 27001 Allegato A A.9.1 fino a A.9.4, GDPR Art. 32(1)(a), requisiti PCI DSS 3.4 e 4.1. Nota la particolarità all'interno della fluidità: A.9.x è la numerazione della versione superata ISO/IEC 27001:2013; la revisione del 2022 ha riorganizzato l'Allegato A. La risposta sembrava autorevole e portava una staleness a livello di edizione che nulla nella risposta segnala; l'abbiamo notato solo controllando la numerazione rispetto alla revisione del 2022. Questa è la forma di fallimento in miniatura: fluida, strutturata, specifica e silenziosamente non il comportamento che avevi configurato. Se la nostra valutazione fosse stata "dai un'occhiata ad alcune risposte per un fallimento ovvio", la perdita di output di reasoning sarebbe passata inosservata. È emersa perché abbiamo registrato i caratteri di reasoning per chiamata come metrica di prima classe e la colonna è andata a zero.

Il resto della scansione della famiglia kimi ha rafforzato quanto ogni percorso fallisca in modo diverso. La variante dedicata al pensiero (moonshotai/kimi-k2-thinking) ha prodotto output di reasoning in ogni prompt complesso (4.103 caratteri di mediana) ma ha raggiunto 178.618 ms al primo token su un prompt di reasoning profondo, tre minuti di attesa su una rotellina. Pinzando kimi-k2.5 a un provider in grado di reasoning (Inceptron) ha prodotto reasoning reale ma ha fallito 2 dei 5 prompt complessi: la risposta ha consumato l'intero budget di 2.048 token per il reasoning e ha emesso zero contenuto. Veloce senza output di reasoning, reasoning senza latenza limitata o reasoning che esaurisce la risposta. Tre modalità di fallimento in una sola famiglia di modelli e nessuna di esse visibile negli ID. Abbiamo rinunciato a tutti questi percorsi per la produzione.

Per un assistente di conformità le poste in gioco sono specifiche: la risposta alimenta una valutazione del rischio o una risposta a un audit e una risposta può sembrare autorevole mentre porta esattamente la staleness che un revisore cerca. "Fluida, ma non il comportamento che hai configurato" è la peggiore forma di fallimento in questo dominio, perché nulla nella risposta la segnala come un fallimento. Il blog di ingegneria di OpenRouter stesso riconosce il lato qualitativo di questa varianza: "Alcuni provider erogano varianti di un modello più pesantemente quantizzate che performano peggio rispetto allo stesso modello ospitato altrove" (How OpenRouter Model Routing Works, pubblicato il 2026-06-12). I nostri dati aggiungono una dimensione comportamentale a questo quadro: non solo lo stesso modello erogato peggio, ma output di reasoning presenti o assenti dietro un ID stabile.

La lotteria dell'ID del modello

Questa è l'idea denominata e il modello mentale che applichiamo ora a ogni integrazione tramite porta di accesso: quando un ID del modello bilancia il carico tra provider con configurazioni di erogazione diverse, ogni richiesta è un'estrazione della lotteria e il nome stampato sul biglietto è la cosa meno informativa al riguardo. L'ID del modello ti dice la famiglia dei pesi. Non ti dice la quantizzazione, la distribuzione della latenza, se l'output di reasoning apparirà o se i parametri che hai segnato come richiesti saranno riflessi in ciò che torna indietro. Queste sono proprietà della tripla (modello, provider, giorno) e due delle tre variabili sono al di fuori del tuo file di configurazione.

La checklist portatile

Se instradi traffico LLM tramite una porta di accesso multi-provider, non solo OpenRouter:

• Registra gli output comportamentali come metriche di prima classe. Caratteri o token di reasoning per chiamata, insieme alla latenza, indicizzati dal provider di erogazione che la risposta segnala. Un comportamento che non viene misurato per risposta può scomparire senza che nessuno se ne accorga. Imposta avvisi sul collasso in produzione, non solo nelle valutazioni.
• Tratta le flag di instradamento e parametro come suggerimenti finché non li hai confermati rispetto all'output. Invia una richiesta che richiede una capacità, poi verifica quale provider l'ha erogata e se la capacità è effettivamente apparsa nella risposta.
• Prima di concludere "questo modello non può X", pinna un provider noto per essere valido e fai A/B testing sulla flag. La nostra richiesta era valida per tutto il tempo; la variabile era l'endpoint di erogazione. Senza la verifica pinzata avremmo incolpato il modello.
• Risegui il campionamento dell'instradamento su base oraria e giornaliera, non all'interno di una singola sessione. Dieci chiamate su dieci verso un provider di martedì è un campione, non una proprietà. La nostra oscillazione è emersa solo tra round a distanza di giorni.
• Discrimina con prompt complessi e riporta le distribuzioni. I nostri dieci prompt facili hanno prodotto risposte che non potevamo classificare in modo significativo; solo i cinque prompt complessi hanno separato la qualità della risposta tra le configurazioni e le mediane hanno nascosto la coda di 178 secondi. La colonna del massimo è dove vivono le configurazioni non distribuibili.
• Se il comportamento deterministico conta, pinna il provider e verificalo su base programmata. Il pinning sacrifica il failover e a volte la latenza. Per un dominio regolamentato questa è spesso la scelta giusta.

Limiti

Questa è una valutazione: 186 chiamate, 5 a 10 prompt per configurazione, sul nostro set di prompt di conformità, iniziate il 2026-04-22 con round finali nei giorni successivi (abbiamo registrato la data della valutazione, non i timestamp per round). Ogni numero qui è una nostra misurazione sui nostri compiti in quella finestra, non un'affermazione sul comportamento, configurazione o intento attuale di alcun vendor. Gli identificatori dei modelli sono gli ID pubblici della porta di accesso richiesti al momento; non abbiamo registrato indipendentemente le revisioni sottostanti dei modelli. Le distribuzioni dei provider, la logica di instradamento di OpenRouter e la documentazione che citiamo (consultata il 2026-07-15) potrebbero essere cambiate da allora. L'osservazione su require_parameters è relativa a un modello su una coppia di provider; non l'abbiamo estesa al catalogo completo. Zero caratteri di reasoning trasmessi in streaming significa che non è stato esposto reasoning nella risposta, nient'altro. E le dimensioni del campione sono sufficienti per la nostra decisione di distribuzione, indicative per la tua. Ciò di cui siamo sicuri è il meccanismo: quando il comportamento di erogazione varia per provider dietro un ID stabile, l'unica capacità che hai effettivamente è quella che misuri in uscita.

L'ID del modello nella tua configurazione è un nome per una distribuzione. Misura le estrazioni.