Sì, un piccolo modello locale può instradare le richieste verso modelli più grandi con un'affidabilità sufficiente per essere utile, ma non sufficiente per costituire l'unico meccanismo di sicurezza. L'instradamento dei modelli funziona al meglio quando il router locale gestisce un problema di ottimizzazione: quali richieste sono probabilmente abbastanza semplici da poter essere gestite da un modello più economico o più piccolo? Le attività ad alto impatto, ambigue, con contesto lungo o che fanno ampio uso di strumenti dovrebbero comunque essere soggette a regole di escalation deterministiche.
L'obiettivo non è prevedere perfettamente l'“intelligenza”. È ridurre l'inferenza costosa non necessaria mantenendo il costo degli errori di instradamento entro una tolleranza misurata.
Che cosa decide realmente un router di modelli locali?
Richiesta in ingresso
|
v
Router locale piccolo
|
+-- facile / di routine ----> modello locale piccolo
|
+-- difficile / incerto --> modello locale più grande
|
+-- serve un modello all'avanguardia ---> modello cloud
Il router può essere un classificatore, un sistema di similarità basato su embedding, un piccolo LLM, un modello di preferenza appreso oppure una combinazione di regole e punteggi appresi.
Progetti come RouteLLM dimostrano questo schema producendo un punteggio usato con una soglia per scegliere tra un modello debole e uno potente.
Perché una soglia è più importante dell'etichetta del router
Un router che dice “facile” o “difficile” nasconde la decisione operativa reale. Un punteggio più una soglia consentono di scegliere il compromesso tra costo e qualità.
punteggio del router: necessità stimata di un modello potente
0.0 -------------------------- 1.0
facile difficile
soglia = 0.35
punteggio >= 0.35 -> escalation
La documentazione di RouteLLM raccomanda di calibrare la soglia su query simili al carico di lavoro reale in ingresso, perché la percentuale instradata al modello potente cambia in base alla distribuzione delle richieste. Questo avvertimento è particolarmente importante a casa: il tuo insieme di comandi Home Assistant, domande di programmazione, RAG privato, ricerche familiari e ragionamento esteso non assomiglia per nulla a un benchmark generico.
Definisci regole di escalation rigide prima dell'instradamento appreso
Alcune richieste dovrebbero bypassare completamente il router di piccole dimensioni.
| Tipo di richiesta | Instradamento consigliato | Perché |
|---|---|---|
| Classificazione / formattazione semplice | Locale di piccole dimensioni | Bassa complessità e facile da verificare |
| Intento noto di controllo domestico | Deterministico / locale di piccole dimensioni | Veloce e circoscritto |
| Debug di una base di codice grande | Modello grande | Contesto lungo + ragionamento |
| Decisione ad alto impatto | Modello grande + verifica | Il costo dell'errore è elevato |
| Richiesta di uno strumento sconosciuto | Inoltra a un modello superiore o richiedi approvazione | Rischio legato all'autorizzazione |
| Confidenza del router vicina alla soglia | Modello grande | Fallback conservativo |
Questo impedisce che i guasti di instradamento si trasformino in falle di sicurezza. La guida al confine di fiducia per l'esecuzione degli strumenti di ZimaSpace è pertinente: scegliere un modello e concedere un effetto collaterale sono decisioni separate.
Che cosa significa «affidabile» per un router?
Misura l'errore che ti interessa davvero. Un router può sembrare accurato nel complesso e continuare a inviare i prompt peggiori al modello meno potente.
Monitora almeno:
- tasso di errori del modello più potente: prompt che richiedevano un'escalation ma sono rimasti sul modello più piccolo;
- tasso di escalation non necessaria: prompt semplici inviati al modello costoso;
- successo dell'attività finale: il flusso di lavoro finale è stato completato correttamente?
- latenza: l'instradamento ha aggiunto più ritardo di quanto ne abbia fatto risparmiare?
- costo o energia: quanta inferenza costosa è stata evitata?
Per molti sistemi domestici, gli errori del modello più potente meritano più peso delle escalation non necessarie. Effettuare un'inferenza aggiuntiva è solitamente meno costoso che restituire in silenzio un comando di backup errato o un piano di automazione sbagliato.
Usa un periodo di valutazione in modalità shadow
Prima di lasciare che il router scelga i modelli in produzione, eseguilo in modalità shadow:
- invia ogni richiesta attraverso l'attuale percorso affidabile;
- registra quale modello avrebbe selezionato il router;
- confronta offline le risposte del modello più piccolo e di quello più grande;
- classifica gli errori per categoria di richiesta;
- scegli una soglia in base agli errori accettabili;
- solo dopo consenti l'instradamento automatico.
Alcune centinaia di richieste rappresentative degli utenti domestici sono solitamente più utili che inseguire il punteggio di una classifica pubblica che misura un altro dominio.
Le conversazioni a più turni sono più difficili dei prompt singoli
Instradare una singola domanda come «converti questa data» è più facile che instradare il quinto turno di una conversazione in cui il contesto importante si trova nei messaggi precedenti.
L'implementazione attuale del controller di RouteLLM rileva esplicitamente che i suoi router sono stati addestrati su dati del primo turno e che l'instradamento in conversazioni a più turni richiede ulteriori ricerche. È un utile avvertimento generale: un router che valuta solo l'ultima frase dell'utente potrebbe vedere «sì, fallo» senza avere idea che «fallo» si riferisca a una complessa migrazione dell'infrastruttura.
Le opzioni includono:
- instrada la richiesta sulla base di un riepilogo compatto della conversazione più l'ultimo turno;
- fissa un solo modello per tutta la durata dell'attività;
- inoltra automaticamente la richiesta dopo l'uso di uno strumento o quando inizia un contesto lungo;
- lascia che sia il modello più potente a subentrare quando il modello più piccolo chiede aiuto.
Il modello più piccolo può stabilire di non essere sicuro?
La fiducia dichiarata dal modello è utile come uno dei segnali, ma non costituisce una garanzia. I modelli possono sbagliarsi con grande sicurezza.
Un router più sicuro combina diversi segnali:
punteggio di instradamento =
difficoltà appresa
+ lunghezza del contesto
+ requisito dello strumento
+ regola del dominio
+ importanza per l'utente
+ categoria del precedente errore
Ad esempio, un modello 3B potrebbe classificare «riassumi questa nota di due paragrafi» come sicura per l'elaborazione locale, mentre una regola deterministica inoltra a un modello più potente qualsiasi richiesta contenente un piano di modifica dell'infrastruttura, un'operazione su una chiave di crittografia o un'istruzione finanziaria/legale.
Usa la verifica per individuare il routing insufficiente
Alcune attività del modello piccolo dispongono di validatori economici. Il JSON può essere verificato rispetto allo schema. Il codice può eseguire test. Gli spostamenti di file possono essere simulati. Le risposte basate sul recupero di informazioni possono richiedere citazioni. Un classificatore può essere verificato rispetto alle etichette consentite.
Quando la convalida fallisce, inoltra la stessa attività al modello più grande insieme al contesto originale e all'errore di convalida.
risultato del modello piccolo
|
v
validatore
| |
superato non superato
| |
fatto v
modello grande
Questo trasforma il routing in un sistema adattivo anziché in una valutazione fatta una sola volta.
Perché il routing è adatto a un server IA domestico
Un server domestico dispone spesso di un modello economico sempre attivo, ma di una capacità limitata per un modello locale più grande. Potrebbe inoltre avere accesso a un'API frontier per le attività difficili. Il routing consente al sistema domestico di mantenere private ed economiche le attività di routine, inoltrandole a un livello superiore solo quando necessario.
Questo completa il più ampio modello dei costi dell'IA locale, via API e ibrida: un sistema ibrido non deve inviare ogni prompt allo stesso livello di calcolo.
Una policy di routing prudente per l'uso domestico
- Assegna per impostazione predefinita l'estrazione, l'etichettatura e la formattazione ripetitive al modello più piccolo.
- Inoltra a un modello superiore le richieste oltre una soglia di complessità verificata.
- Inoltra a un modello superiore per regola le categorie ad alto impatto, indipendentemente dal punteggio.
- Inoltra a un modello superiore quando i validatori falliscono.
- Inoltra a un modello superiore le attività ambigue e con più turni.
- Registra le decisioni e gli esiti del routing.
- Ricalibra quando cambiano i modelli, i prompt o la composizione del carico di lavoro.
- Mantieni un override manuale “usa il modello più potente”.
Domande frequenti
Il router deve essere necessariamente un LLM?
No. Un classificatore di piccole dimensioni, un modello di similarità basato su embedding, un motore di regole o un router delle preferenze addestrato possono essere più veloci e facili da calibrare.
Il routing può garantire la stessa qualità dell'uso costante del modello più grande?
No. Il routing è un compromesso. Puoi ridurre il tasso di errori con soglie prudenti, regole rigide di escalation e validatori, ma ci saranno sempre cambiamenti nella distribuzione dei dati ed errori di classificazione.
Un router dovrebbe scegliere anche gli strumenti oltre ai modelli?
Può aiutare a classificare l'intento, ma l'autorizzazione degli strumenti dovrebbe rimanere in un livello separato di policy. La selezione del modello è una decisione di ottimizzazione; l'esecuzione privilegiata è una decisione di sicurezza.
Verdetto finale
Un piccolo modello locale può essere un router utile se lo rendi prudente, misurabile e sostituibile. Calibralo su richieste reali, definisci le categorie che devono sempre essere inoltrate a un modello superiore, convalida gli output economici e monitora gli errori dei modelli più potenti. Il compito del router non è dimostrare che il piccolo modello sia capace, ma decidere quando vale la pena spendere più risorse di calcolo per ridurre il rischio.
Hub Tecnologico e AI
Altro da leggere

Le 10 migliori interfacce web per l’IA locale per home lab nel 2026
Confronta 10 interfacce web AI locali self-hosted per home lab, includendo il supporto a Ollama, RAG, agenti, accesso multiutente, difficoltà di configurazione e casi...

Quanto costa GPT-6 Astra nel tempo? Quando conviene l’IA cloud rispetto all’IA locale
Una guida pratica ai costi di GPT-6 Astra che illustra l’utilizzo dei token, i carichi di lavoro IA a lungo termine, i compromessi tra...

GPT-6 Astra vs IA locale: quali parti di un agente dovrebbero rimanere sul tuo server domestico?
GPT-6 Astra può rimanere nel cloud, mentre il tuo server domestico conserva localmente file, memoria, RAG, strumenti, autorizzazioni e lo stato persistente dell’agente.

