LLM router: criteri di scelta, costi e test di qualità

Il modello più capace dovrebbe occuparsi del lavoro che lo richiede. Una risposta sullo stato di un ordine basata su dati autenticati e una contestazione di rimborso con informazioni contraddittorie non dovrebbero seguire automaticamente lo stesso percorso. La difficoltà sta nel distinguerle prima che una risposta economica costringa a costose rilavorazioni.

Il comportamento dei prodotti descritto qui è stato verificato sulla documentazione disponibile online il 21 ottobre 2026. Il carico di lavoro dell'assistenza e i calcoli sono esempi illustrativi: non sono misurazioni in produzione né promesse di risparmio dei fornitori.

Che cosa fa un LLM router

Un model router è una regola o un classificatore addestrato che sceglie quale modello linguistico di grandi dimensioni, o LLM, risponde a ogni richiesta. Un classificatore assegna un input a una categoria. Per scegliere il modello, il router può considerare il tipo di attività dell'applicazione, la conversazione, gli strumenti necessari, le dimensioni dell'input o una stima della difficoltà.

Immagina chi smista il lavoro in un team di assistenza. Una semplice consultazione di dati va a chi può gestirla con efficienza; una contestazione va a uno specialista. Serve anche una regola di escalation per le attività che nessuno è autorizzato a portare a termine.

In un'applicazione, questo significa verificare l'idoneità prima di ottimizzare: il modello può gestire l'input, chiamare gli strumenti richiesti ed essere eseguito tramite un provider approvato? Solo i candidati idonei dovrebbero essere confrontati per costo o qualità attesa.

La scelta del modello, la scelta del provider e il fallback rispondono a domande diverse. Il routing dei modelli sceglie il modello che risponderà. Il routing dei provider sceglie dove eseguire un modello già selezionato, per esempio tra diversi servizi di hosting. Il fallback stabilisce che cosa provare quando un tentativo fallisce. Un gateway, lo strato di accesso tra l'app e le API dei modelli, può implementare tutte queste funzioni; aggiungerne uno, però, non basta a ottenere un selettore di modelli che tenga conto della qualità.

Qui, per modello di frontiera si intende il candidato generalista più capace tra quelli che stai considerando. Può comunque dare una risposta sbagliata. Il routing distribuisce il lavoro in base alle capacità dei modelli: non stabilisce che cosa sia vero.

I tre approcci al routing dei modelli

Inizia con regole che sai spiegare. La selezione automatica diventa utile quando gestisce la variabilità che sfugge a quelle regole, continuando a superare i controlli di accettazione. Queste tre opzioni di implementazione possono sovrapporsi: un gateway può ospitare un router addestrato.

Regole definite nell'applicazione

L'applicazione associa ai modelli tipi di attività e vincoli già noti. Una richiesta proveniente da un endpoint sullo stato degli ordini, con dati autenticati e un modello di risposta approvato, è una candidata più solida per il modello piccolo rispetto a un messaggio considerato facile solo perché breve.

Le regole sono utili quando l'applicazione conosce già il flusso di lavoro. Il loro limite è l'ambiguità: lo stesso endpoint può ricevere una semplice richiesta di informazioni oppure un reclamo con dati contraddittori. Mantieni un percorso esplicito per i casi incerti, invece di allungare continuamente un elenco fragile di parole chiave.

Routing automatico tramite gateway

Invii una richiesta a un alias di routing e il gateway sceglie il modello. A seconda del prodotto, la selezione può basarsi su un classificatore, su livelli configurati o su altri segnali. Ottieni una gestione centralizzata, ma adotti anche i criteri con cui quel router decide quale modello sia adatto.

Questa opzione ha senso quando le attività in arrivo sono eterogenee e gestire un selettore proprio richiederebbe uno sforzo sproporzionato. Mantieni un insieme approvato di candidati e registra il modello che ha effettivamente risposto. Un alias non identifica un modello in modo stabile.

Come apprende un router per modelli LLM

Un router addestrato impara da esempi ed esiti etichettati quale candidato ha maggiori probabilità di riuscire meglio. La domanda utile per l'addestramento è se il modello più capace aggiunga valore a quella richiesta, non soltanto se il testo sembri complicato.

RouteLLM, un framework open source per eseguire e valutare router, documenta la selezione tra modelli più e meno capaci appresa da preferenze, insieme alla calibrazione della soglia. La soglia determina quanto spesso viene scelto il modello più capace. I risultati pubblicati non dimostrano come si comporterà sui tuoi ticket. Documentazione di RouteLLM.

La difficoltà di manutenzione nasce dai cambiamenti nella distribuzione dei dati: nuovi tipi di attività o modelli sostitutivi possono rendere inadeguata una soglia prima utile. Addestra o calibra il router sugli esempi di sviluppo, poi valutalo su casi separati che non siano mai stati usati per regolarlo.

Una politica di routing per l'assistenza, passo per passo

Affida al modello piccolo risposte fondate sui dati e con un perimetro definito; manda al modello di frontiera i casi che richiedono ancora ragionamento. Mantieni le decisioni sulle autorizzazioni nelle regole applicative. Nessun modello acquisisce il permesso di emettere un rimborso solo perché sa spiegarlo.

Immagina un rivenditore con un servizio in abbonamento la cui app recupera l'ordine del cliente, le condizioni applicabili e la cronologia della conversazione prima di preparare una risposta. Quella che segue è una politica proposta, non l'affermazione che un particolare modello piccolo sia già in grado di rispettarla.

Il percorso con il modello piccolo dovrebbe astenersi dal rispondere quando mancano gli elementi necessari. L'applicazione può rilevare campi dell'ordine mancanti, una struttura di output non valida o un'azione richiesta al di fuori del flusso consentito. Per individuare una contraddizione fattuale può servire un verificatore separato o una revisione umana. Una risposta sintatticamente valida può comunque essere sbagliata.

Usa il modello di frontiera per i casi difficili e passa a quel modello dopo un tentativo fallito del modello piccolo solo quando il fallimento è rilevabile. Se mancano dati, occorre recuperarli o chiedere chiarimenti: passare le stesse informazioni incomplete a un modello più grande non risolve il problema.

Conta anche le chiamate di escalation

Supponiamo che un lotto illustrativo contenga 1,000 richieste. La politica ne invia 700 al modello piccolo e 300 direttamente al modello di frontiera. Delle chiamate iniziali al modello piccolo, 70 non superano un controllo e vengono rieseguite sul modello di frontiera.

Ora paghi 700 chiamate al modello piccolo e 370 al modello di frontiera, oltre al routing e alla validazione. In totale sono 1,070 chiamate ai modelli che rispondono, non 1,000. Un nuovo tentativo è lavoro aggiuntivo anche quando l'utente vede solo la risposta finale.

Indichiamo con r il costo medio di routing per richiesta originale, con s il costo medio di una chiamata al modello piccolo, con f quello di una chiamata al modello di frontiera e con g gli addebiti aggiuntivi di gateway o validazione per l'intero lotto. In questo esempio semplificato, supponiamo che il costo medio del modello di frontiera sia lo stesso nella configurazione di riferimento, nelle chiamate dirette e nelle escalation:

Costo con routing = 1,000r + 700s + 370f + g

Riferimento con il solo modello di frontiera = 1,000f

Il routing costa meno soltanto quando 700(f − s) > 70f + 1,000r + g. Il lato sinistro rappresenta il costo iniziale di risposta evitato usando il modello piccolo; il lato destro comprende i tentativi aggiuntivi sul modello di frontiera e gli altri costi.

Calcola i costi delle chiamate con i modelli e le tariffe scelti: costo della chiamata = (token di input non in cache × tariffa di input + token di input in cache × tariffa per la cache + token di output fatturati × tariffa di output) / 1,000,000, quando le tariffe sono espresse per milione di token; aggiungi gli strumenti e gli addebiti per richiesta fatturati separatamente.

In produzione, sostituisci le medie semplificate con l'utilizzo effettivo per attività e percorso. I ticket difficili possono generare risposte più lunghe, le riesecuzioni possono includere più contesto e cambiare modello può modificare il riutilizzo della cache. Includi i token del classificatore del router e, dove previsto, i token di ragionamento fatturati, senza contare due volte lo stesso addebito. Confronta i due sistemi con la stessa politica di nuovi tentativi.

Il risultato utile è un costo per risoluzione accettata più basso, mantenendo la soglia minima di qualità. Una fattura inferiore accompagnata da più promesse di rimborso prive di fondamento non supera questa verifica.

Che cosa offrono le soluzioni di routing documentate

Esamina il meccanismo di selezione prima di adottare un endpoint di routing. Questi prodotti espongono decisioni diverse: il termine «router» in comune non rende equivalenti i comportamenti predefiniti.

OpenRouter: Auto Router sceglie in base all'attività

OpenRouter, un gateway gestito verso più provider di modelli, espone Auto Router tramite openrouter/auto. La documentazione attuale descrive una classificazione dell'attività seguita da un ordinamento dei modelli basato sulla spesa della community per quel tipo di attività negli ultimi 7 giorni, poi da filtri per fascia di costo e idoneità. È un segnale aggregato di utilizzo, non la tua griglia di valutazione della qualità dell'assistenza. Documentazione di Auto Router.

Le opzioni di cost_tier sono low, medium, high, xhigh e max; il comportamento predefinito corrisponde all'incirca a low. Un livello è una fascia, non un tetto rigido di spesa. Limita i candidati con allowed_models ed excluded_models e registra il campo model della risposta. La persistenza della scelta nella conversazione può mantenere il modello selezionato, ma non garantisce che resti invariato.

Con una chiave API impostata nell'ambiente, questo comando invia una richiesta minima di routing:

curl --fail-with-body https://openrouter.ai/api/v1/chat/completions \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openrouter/auto",
    "messages": [{"role": "user", "content": "Rewrite this status politely: Your parcel is in transit."}],
    "plugins": [{"id": "auto-router", "cost_tier": "low"}]
  }'

Per la valutazione usa un insieme delimitato di candidati. Se i modelli disponibili cambiano, diventa più difficile interpretare il risultato di qualità ottenuto ieri.

LiteLLM: distinguere il routing dei deployment da Auto Router

LiteLLM, un gateway LLM configurabile, documenta strategie per instradare le richieste tra deployment: selezione ponderata, scelta del meno occupato, routing basato sulla latenza e routing basato sui costi. La strategia predefinita simple-shuffle non è un classificatore della difficoltà dei ticket di assistenza. Documentazione del router.

La funzione separata Auto Router documenta classificatori euristici, basati su LLM, su regole per parole chiave e su plugin personalizzati. I livelli SIMPLE, MEDIUM, COMPLEX e REASONING corrispondono a modelli o gruppi configurati. Nella dashboard, il percorso documentato è Models + Endpoints → Add Model → Auto Router, seguito dalla configurazione e da Test Routing. Documentazione di Auto Router.

È adatto a chi sviluppa e vuole controllare i modelli candidati e il comportamento della classificazione. Il limite è la responsabilità operativa: associare i modelli ai livelli non significa aver verificato che rispettino le regole di accettazione. Il confronto tra LiteLLM e OpenRouter approfondisce questa scelta infrastrutturale.

Vercel AI Gateway: scelta del provider e controlli espliciti di routing

Vercel AI Gateway, uno strato di accesso gestito alle API dei modelli, sceglie i provider predefiniti in base alla disponibilità e alla latenza recenti. Le opzioni dei provider ne controllano l'ordine e i filtri; i fallback dei modelli specificati come stringhe provano modelli di riserva quando il principale fallisce o non è disponibile. Sono meccanismi utili per l'affidabilità. Da soli, però, non decidono se un ticket di assistenza richieda un modello di frontiera. Documentazione su routing dei provider e fallback.

Le regole di routing del gateway consentono anche di sostituire il modello richiesto con un altro o di rifiutare la richiesta. Una riscrittura può migrare il traffico in modo centralizzato, ma sostituire un modello per tutte le richieste è diverso dal classificare la difficoltà di ciascuna. Documentazione delle regole di routing.

Quando serve un comportamento esplicito, usa questi controlli al di sotto di una politica di selezione applicativa. L'errore è presumere che la scelta automatica del provider includa anche la scelta automatica in base alla qualità richiesta dall'attività. Per la scelta più ampia dello strato di accesso, consulta la guida ai gateway AI per app con più modelli.

Microsoft Foundry: un router addestrato e gestito dal provider

Il model router di Microsoft Foundry è un selettore di modelli addestrato, esposto come deployment. Microsoft descrive una selezione basata su complessità, ragionamento, tipo di attività e altri attributi. Offre le modalità Balanced, Quality e Cost, oltre a sottoinsiemi di modelli. Concetti del model router.

È adatto a un'applicazione che usa già Foundry e vuole una selezione gestita tra i modelli idonei. Il limite principale è l'insieme dei candidati: area geografica e accesso influiscono sulla disponibilità, e la documentazione Microsoft avverte che la finestra di contesto più piccola tra i modelli sottostanti limita ciò che il router può accettare in modo affidabile. Restringi il sottoinsieme ai modelli che soddisfano i requisiti dei tuoi input.

Una modalità chiamata Quality non sostituisce la valutazione sull'attività. Prova il sottoinsieme scelto con le lunghezze effettive delle conversazioni, gli strumenti e le regole di accettazione della tua applicazione.

Come scegliere un router per modelli AI

Mantieni le regole applicative quando riesci a individuare in modo affidabile il lavoro semplice. Valuta il routing automatico gestito quando la varietà delle attività rende fragili quelle regole. Considera l'addestramento di un selettore quando hai abbastanza esiti rappresentativi ed etichettati da giustificarne la manutenzione.

Per le alternative infrastrutturali oltre a questi meccanismi, il confronto successivo è la guida alle alternative a OpenRouter. La prima decisione resta la politica di routing e le evidenze che la sostengono, non un elenco più lungo di provider.

Come valutare un router con un set di test

Misura le risposte prodotte dal routing, non la corrispondenza con etichette come «facile» e «difficile». Un selettore può classificare correttamente le categorie di attività e comunque inviare al modello piccolo i casi sbagliati.

Un set di valutazione è una raccolta ripetibile di richieste, contesto e criteri di accettazione. Per l'app di assistenza, ogni caso dovrebbe includere la conversazione, un'istantanea dei dati dell'ordine, le condizioni applicabili, i fatti attesi, le affermazioni o azioni vietate e il comportamento di escalation richiesto.

La scheda di valutazione dovrebbe rendere visibili gli errori costosi:

Se nessun caso rientra nel denominatore di una metrica, riportala come non definita, non come zero. Stima il tasso di assegnazioni dannose al modello piccolo usando gli output dei modelli valutati indipendentemente, e riporta anche gli errori finali dopo eventuali escalation. Segnala a parte i casi in cui entrambi i modelli falliscono: un selettore non può ricavare una risposta accettabile da quei candidati.

Stabilisci prima del test quale differenza di qualità non critica sia accettabile e indaga ogni nuova regressione critica. Usa intervalli di confidenza adatti al campione appaiato; se l'incertezza comprende ancora una perdita inaccettabile, raccogli più evidenze invece di dichiarare l'equivalenza.

Infine, esegui il router in modalità shadow su un campione circoscritto di traffico reale, mentre il modello attuale continua a rispondere ai clienti. Le chiamate shadow comportano una spesa aggiuntiva. Dopo aver esaminato i risultati, procedi con un rilascio limitato e la possibilità di tornare immediatamente alla politica di selezione esistente. Continua a monitorare per tipo di richiesta e ripeti la valutazione quando cambiano prompt, strumenti, modelli o comportamento del routing.

Quali promesse sul routing dei modelli sono esagerate?

«La stessa qualità a un costo inferiore» è un risultato legato a uno specifico carico di lavoro, non una proprietà del router. Dipende dalle richieste in arrivo, dai candidati disponibili e da ciò che viene considerato accettabile. Nessuna percentuale di risparmio ottenuta sul carico di lavoro altrui sostituisce queste misurazioni.

Anche una risposta API riuscita dice poco sulla qualità della risposta. Un fallback in caso di errore può aggirare un endpoint non disponibile; non rileva una condizione inventata in una risposta fluente. L'escalation per motivi di qualità richiede un controllo separato, che ha a sua volta un tasso di errore e un costo.

I punteggi di difficoltà meritano la stessa attenzione. La confidenza di un classificatore non equivale automaticamente alla probabilità che il modello selezionato risponda correttamente. Calibra ogni soglia sugli esiti osservati delle attività. Non permettere che frasi dell'utente come «è facile» prevalgano sulle autorizzazioni applicative o sui vincoli relativi ai candidati.

Infine, la selezione automatica può cambiare anche senza modifiche al codice dell'applicazione. I candidati di OpenRouter, selezionati in base alla spesa, evolvono; alla versione attuale del model router di Microsoft possono essere aggiunti modelli sottostanti. Questi comportamenti documentati rendono la registrazione dei candidati e l'aggiornamento delle valutazioni parte della gestione del router, non attività accessorie.

Chi dovrebbe iniziare, chi aspettare e da dove partire

Chi sviluppa dovrebbe iniziare quando riesce a isolare attività ripetibili con una condizione di successo chiara. Aggiungi un percorso con il modello piccolo per le risposte sullo stato basate su dati verificabili, mantieni un percorso prudente per i casi incerti e assegna versioni alla politica, così i fallimenti sono riproducibili.

Chi gestisce il servizio dovrebbe pretendere evidenze sull'intero flusso di lavoro. Una fattura di inferenza più bassa non basta se aumentano i ticket riaperti, le revisioni umane o il tempo di risoluzione. Monitora questi esiti insieme alla valutazione offline.

Chi acquista dovrebbe chiedere una prova sui propri casi. Pretendi visibilità sui modelli selezionati e sul comportamento del fallback. Un benchmark generale non può dimostrare che un router comprenda le tue condizioni di rimborso.

Aspetta se non sai definire un risultato corretto, non puoi limitare l'insieme dei candidati o non hai abbastanza traffico da ripagare il lavoro operativo. Un'applicazione che usa già un modello piccolo validato per un'attività fissa e circoscritta potrebbe ricavare poco da un altro selettore.

La prima cosa da fare lunedì: esporta un insieme rappresentativo di casi di assistenza, fissa le informazioni su cui si basano e valuta il modello attuale accanto a un candidato più piccolo. Scrivi una regola di routing circoscritta ai casi in cui il candidato più piccolo supera la verifica. Affida traffico a un router automatico solo dopo che ha battuto quella regola sui costi, rispettando gli stessi requisiti di qualità.

Domande frequenti sul routing dei modelli

Iscriviti alla newsletter per ricevere guide pratiche allo sviluppo e alla valutazione di applicazioni AI.