Sempre più organizzazioni si chiedono se abbia senso continuare a gestire l'intero traffico con modelli di grandi dimensioni (LLM) oppure adottare un'architettura ibrida in cui un modello più piccolo e specializzato (SLM) gestisce il “pane quotidiano”, mentre l'LLM interviene come specialista. In questo lavoro propongo un quadro decisionale completo per rispondere alla domanda in modo operativo: quando e come un sistema SLM‑first, con router e fallback, può battere un sistema LLM‑only in termini di costo e latenza, a parità di qualità percepita. Il contributo è duplice. Da un lato, offro un modello quantitativo per stimare costo e latenza attesi e per derivare condizioni di break‑even comprensibili a chi decide il budget. Dall'altro, dettaglio il “come fare”: progettare e valutare il router (il vero fattore critico del ROI), impostare guardrail e telemetria, portare il sistema in produzione con shadow mode, A/B test e rollout controllato, e mantenerlo nel tempo. Un caso studio su triage di sinistri auto illustra numericamente il passaggio da LLM‑only a SLM‑first, mostrando riduzioni di costo nell'ordine del 40–50% e di latenza del 15–25% nelle condizioni giuste. Il messaggio centrale è semplice: la convenienza dipende soprattutto da tre leve, la quota di richieste davvero adatte allo SLM, la qualità del router e il costo/ritardo del fallback. Con un router eccellente anche uno SLM “medio” diventa profittevole; con un router mediocre i benefici si dissolvono, specialmente quando il fallback è frequente e costoso.
1. Introduzione
Negli ultimi anni gli LLM hanno dimostrato una straordinaria capacità di generalizzazione e una qualità spesso superiore alle alternative. Questo successo ha reso naturale adottare architetture "LLM‑only” per una vasta gamma di problemi: un unico modello, una singola API, tutto passa da lì. Tuttavia, questa semplicità ha un costo. I modelli grandi sono più lenti e più costosi per richiesta, e non sempre sono necessari per compiti ripetitivi o strutturati. In parallelo, i Small Language Models sono cresciuti di maturità: se ben addestrati e incastonati in pipeline con regole chiare e controlli di qualità, riescono a gestire una parte consistente del traffico con efficienza superiore.
Il punto non è "LLM o SLM” in assoluto, ma "quale mix, per quali richieste, con quale regia”. Il cuore del problema è il routing: un componente che decide, in pochi millisecondi e con alta affidabilità, se una richiesta è adatta allo SLM oppure debba andare direttamente all'LLM. Se la decisione è corretta, si risparmia e si risponde più in fretta; se è sbagliata, si innesca il fallback (prima SLM, poi LLM), che fa perdere sia tempo sia denaro. Scopo di questo lavoro è trasformare questa intuizione in un processo ripetibile: un modello quantitativo per stimare costi e latenze attesi, una metodologia per misurare i parametri con dati reali, e linee guida per la messa in produzione senza sacrificare qualità o SLA.
2. Contesto e lavori correlati
Le architetture eterogenee con router, comuni nel mondo dei mixture‑of‑experts, hanno una storia consolidata: quando la funzione di assegnazione (il "gate”) è ben calibrata, i benefici di throughput e costo sono sostanziali. Nei sistemi agentici, l'uso di SLM specializzati e componenti più semplici ma ben orchestrati riduce la necessità di un'unica "intelligenza universale”. La letteratura sulle pipeline LLM‑centrate ha inoltre chiarito l'importanza dei guardrail e della calibrazione delle confidenze: è più economico e sicuro "mettere regole” e "misurare bene” che confidare in magia statistica. Questo lavoro si posiziona a metà strada tra ricerca e operatività: meno interessato a proporre un nuovo algoritmo di routing, più a fornire un prontuario decisionale e ingegneristico per chi deve scegliere e implementare.
3. Architettura SLM‑first
Un'architettura SLM‑first introduce un bivio all'ingresso. Ogni richiesta passa per un router che, sulla base del contenuto e di altri segnali (lunghezza, parole chiave, metadati, cronologia), decide se la richiesta è "adatta” a uno SLM specializzato o se richiede da subito un LLM. Quando la richiesta imbocca il ramo SLM, l'output viene sottoposto a controlli automatici: struttura corretta, campi obbligatori, coerenza con l'input e rispetto delle policy. Se anche un solo controllo fallisce, si attiva il fallback. Dal punto di vista dell'utente finale, la promessa è che il sistema risponda sempre in modo affidabile; dal punto di vista economico, l'obiettivo è che la quota di richieste che "passa” dal solo SLM sia la più alta possibile senza compromettere qualità o SLA.
La telemetria è parte integrante del disegno. Ogni decisione del router, ogni passaggio sui guardrail, ogni fallback deve essere tracciato, con motivazioni e indicatori di confidenza. Questi dati alimentano due cicli virtuosi: il retraining del router per ridurre gli errori e l'affinamento dello SLM per migliorare il tasso di "pass” ai guardrail. Infine, per i casi ambigui esiste una valvola di sfogo: è possibile aumentare temporaneamente il calcolo a runtime per lo SLM (più passaggi di ragionamento, auto‑verifica), migliorando la qualità senza alzare immediatamente la mano e chiedere aiuto all'LLM. È un'opzione da usare con parsimonia, poiché impatta costi e latenza, ma spesso consente di ridurre i fallback "a un soffio” dal successo.
4. Un modello quantitativo, senza farsi male
Per decidere con raziocinio servono poche variabili chiare. La prima è la quota di richieste davvero adatte allo SLM, che indico con . Se vale significa che, guardando alle richieste reali e al livello di qualità richiesto, sei richieste su dieci potrebbero essere gestite dallo SLM. Poi c'è il router, che misuro con due "recall”: è la capacità di intercettare i casi adatti e mandarli allo SLM; è la capacità di riconoscere i casi non adatti e mandarli al LLM. Idealmente li vorremmo entrambi alti, ma in pratica daremo priorità a , perché gli errori in cui un caso complesso finisce allo SLM sono i più costosi.
Ogni chiamata ha un costo e una latenza: e per lo SLM, e per l'LLM. Il router non è gratis: ha un costo e una latenza , piccoli ma non trascurabili. Infine, quando c'è fallback paghiamo un overhead di orchestrazione () e introduciamo ulteriore latenza (), oltre al costo e al tempo della chiamata LLM che chiude il caso. Con queste grandezze possiamo scrivere la spesa media per richiesta in modo semplice: si paga sempre il router; una quota seguirà il percorso "adatto” e, a seconda che il router colga o meno l'occasione, pagheremo SLM o LLM; una quota seguirà il percorso "non adatto” e, se il router sbaglia, pagheremo SLM più fallback, altrimenti LLM direttamente. La stessa logica vale per la latenza media.
La domanda chiave diventa: il costo medio del sistema con router è inferiore al costo di usare sempre e solo l'LLM? E la latenza media, inclusi router e fallback, è inferiore a quella di LLM‑only e in linea con gli SLA? Queste due disuguaglianze – costo e latenza – definiscono il break‑even. Non serve aritmetica sofisticata per cogliere la sostanza: la convenienza migliora quando è alto (molte richieste semplici), quando e sono alti (router affidabile) e quando il costo del fallback è contenuto. In un mondo reale la variabilità conta: le latenze aumentano sotto carico, il tasso di fallback può differire per cluster di richieste, i guardrail possono essere più o meno severi. È utile quindi affiancare al modello deterministico una semplice simulazione stocastica per esplorare scenari, confermare la robustezza della soluzione e impostare soglie prudenti.
5. Che cosa fa davvero la differenza
Tre leve spostano l'esito più di tutte. La prima è , la "suitability”: se solo una richiesta su quattro è davvero semplice, è difficile far tornare i conti; se diventano quattro o cinque su dieci, la partita si fa interessante. La seconda è la qualità del router: aumentare di dieci o quindici punti il richiamo sui casi complessi () riduce drasticamente i fallback e preserva il risparmio. La terza è il costo del fallback: se passare da SLM a LLM costa molto ed è lento, le soglie di decisione del router dovranno essere più conservative, accettando qualche "spreco” in più verso l'LLM per ridurre i casi in cui si paga due volte.
6. Il router, spiegato come lo progetterei in un team prodotto
Immagino il router come un selezionatore disciplinato. Deve essere rapido, trasparente e calibrato. In pratica, uso un approccio ibrido. Innanzitutto, regole dure per i segnali di rischio: parole che indicano feriti, controversie, elementi legali; richieste troppo lunghe o con pattern che storicamente hanno generato problemi; presenza di dati sensibili. Questi casi vanno direttamente all'LLM. Poi un classificatore addestrato sui dati storici, con etichette "adatto SLM” e "non adatto”, che restituisce una probabilità ben calibrata; fisso due soglie: sopra una certa confidenza mando allo SLM, sotto un'altra mando all'LLM, in mezzo considero la zona grigia e scelgo l'LLM per prudenza. La calibrazione delle confidenze è importante: voglio che "80% di confidenza” significhi davvero "otto volte su dieci ci ho preso”.
A valle dello SLM, imposto guardrail multilivello. Il primo è di forma: la risposta rispetta lo schema atteso? Ha tutti i campi minimi? Il secondo è semantico: quanto è coerente con l'input? Contiene affermazioni che non possono essere dedotte dai dati disponibili? Il terzo è di policy: sono rispettate le regole aziendali e normative? Solo se i tre livelli sono superati rispondo all'utente; altrimenti attivo il fallback. Tutto viene loggato: decisioni, confidenze, motivi dei fallback, costi e latenze, così da addestrare versioni successive del router, aggiornare le soglie e affinare lo SLM.
7. Mettere il sistema in produzione senza sorprese
Dal punto di vista operativo non imposto mai un cambio architetturale "tutto e subito”. Parto con una fase di shadow mode: il router classifica in ombra, ma le risposte vengono comunque prodotte dall'LLM. In questo modo posso stimare , e su dati reali, misurare quanto sarebbe costato il fallback e raccogliere esempi per il retraining, senza rischi per gli utenti. Quando i numeri sono confortanti, passo a un A/B test su una fetta limitata di traffico, attivando davvero il percorso SLM‑first con guardrail e fallback. Qui misuro costo per richiesta, latenza, tasso di fallback, eventuali violazioni di policy e, soprattutto, soddisfazione cliente ed escalation umane. Se le metriche restano allineate o migliori della baseline, aumento gradualmente la percentuale di traffico. Se qualcosa deraglia, ho un piano di rollback e posso tornare temporaneamente all'LLM‑only per la parte problematica.
Questa disciplina va mantenuta nel tempo. I comportamenti degli utenti e la distribuzione dei casi evolvono; il router può soffrire di drift; lo SLM può dover essere aggiornato. Pianifico retraining periodici, rivedo le soglie ogni poche settimane, controllo i trend del tasso di fallback e tengo d'occhio e delle latenze. Un piccolo investimento continuo in MLOps e labeling è il prezzo della stabilità.
8. Un caso reale: triage dei sinistri auto
Consideriamo una compagnia assicurativa che gestisce 50.000 richieste di sinistro al mese. La baseline usa un LLM "premium”, con un costo medio di 0,12 euro a richiesta e una latenza tipica di 3,5 secondi. Un'analisi di diecimila casi storici rivela che circa il 60% delle richieste è costituito da eventi standard: graffi in parcheggio, piccoli tamponamenti senza feriti, vetri rotti. Il restante 40% richiede analisi più approfondite: incidenti con dinamiche complesse, versioni discordanti, feriti o possibili contenziosi.
Addestriamo un router su cinquemila esempi etichettati. In shadow mode stimiamo pari a 0,85 (cioè intercetta correttamente l'85% dei casi adatti allo SLM) e pari a 0,80 (riconosce correttamente l'80% dei casi non adatti). Lo SLM specializzato costa in media 0,015 euro a richiesta e risponde in circa 1,2 secondi; il router costa 0,003 euro e 0,3 secondi; l'overhead di fallback è stimato in 0,02 euro e 0,5 secondi. Attiviamo un A/B sul 20% del traffico e misuriamo.
I risultati sono incoraggianti. Il costo medio per richiesta scende a circa 0,063 euro, quasi la metà della baseline. La latenza media scende a circa 2,8 secondi, un miglioramento del 20% circa. Naturalmente non tutte le richieste beneficiano allo stesso modo: quando il router manda a SLM un caso che in realtà è complesso, i guardrail bloccano l'output e attivano il fallback; qui paghiamo sia SLM sia LLM, e la latenza peggiora. È precisamente per limitare questi casi che teniamo soglie conservative e investiamo per migliorare . Su base mensile, il risparmio si traduce in qualche migliaio di euro; su base annuale, intorno ai trentamila, al netto di orchestrazione, monitoraggio e retraining. La soddisfazione cliente resta stabile o cresce sui casi standard, dove lo SLM, opportunamente "normalizzato”, risponde in modo più consistente.
9. Variazioni sul tema ed estensioni
Esistono domini in cui non basta uno SLM, ma ne servono più di uno, ciascuno specializzato in un sotto‑compito: estrazione di campi, classificazione, generazione di risposte template. In questi casi il router diventa multi‑classe e deve decidere quale SLM invocare, oltre a mantenere un'opzione "LLM diretto”. I principi restano gli stessi: soglie conservative, guardrail, telemetria, e una funzione obiettivo che bilanci costo e latenza sotto vincoli di qualità.
Un'altra estensione pratica riguarda la capacità. Se lo SLM diventa un collo di bottiglia durante i picchi, a poco serve essere economici: si generano code, si attivano fallback per timeout e il ROI evapora. Conviene dimensionare e scalare la capacità in base ai percentili alti del carico (), impostare timeouts coerenti e tenere pronto un piano di autoscaling.
10. Simulare per decidere meglio
Al di là del modello deterministico, una semplice simulazione Monte Carlo permette di esplorare scenari di stress prima di metterli in produzione: cosa succede se il router degrada del 5%? Se la latenza dell'LLM cresce per congestione esterna? Se i guardrail diventano più severi e aumentano i fallback? La simulazione aiuta a scegliere le soglie e a fissare gli allarmi, oltre a fornire intervalli di confidenza sui benefici attesi. Non è necessario un simulatore sofisticato: l'importante è rappresentare correttamente le distribuzioni rilevanti e misurare con volumi adeguati.
11. Limiti e ambiti di applicabilità
Questo quadro non è una bacchetta magica. Funziona meglio quando il traffico contiene una porzione sostanziale di casi ripetitivi e quando si accetta una manutenzione continua del router e dello SLM. È meno indicato in ambiti in cui la tolleranza all'errore è virtualmente nulla, in cui i casi sono sempre diversi o dove mancano dati e competenze per addestrare e mantenere un router affidabile. Inoltre, i conti economici devono includere i costi di transizione: integrazione, MLOps, QA, labeling. Infine, il modello economico non sostituisce le metriche qualitative: la soddisfazione del cliente e la severità degli errori contano quanto, se non più, di costo e latenza.
12. Conclusioni
Adottare una strategia SLM‑first non significa scegliere modelli "poveri”, ma usare bene le risorse. L'LLM resta lo specialista a cui affidare i casi difficili; lo SLM, con una buona regia, gestisce in modo eccellente i casi di routine, facendo risparmiare e accelerando il servizio. Il cardine è il router: quanto meglio decide, tanto più i benefici crescono. La ricetta è lineare: misurare la quota di richieste adatte allo SLM, addestrare e calibrare un router con soglie conservative, impostare guardrail seri, partire in shadow mode, validare con A/B test, scalare gradualmente e mantenere il sistema con disciplina. Quando queste condizioni si allineano, i numeri migliorano davvero e l'esperienza utente non ne risente; spesso, anzi, si rafforza grazie a risposte più rapide e consistenti sui casi standard.
Appendice. Una bussola operativa in poche righe
Se dovessi riassumere in un percorso concreto: partirei con una definizione chiara di "adatto allo SLM” nel tuo dominio e raccoglierei un dataset etichettato. Costruirei un router ibrido regole+ML e lo metterei in shadow mode per due‑quattro settimane, stimando , , e il tasso potenziale di fallback. Verificherei che il rapporto di costo tra LLM e SLM sia sufficientemente favorevole e che il fallback non sia troppo oneroso. Avvierei un A/B test prudente, con guardrail rigidi e telemetria completa, focalizzandomi non solo su costo e latenza ma anche su CSAT ed escalation. Infine, procederei per step, con soglie riviste regolarmente e retraining mensile. Se dopo tre mesi i numeri reggono, il sistema è pronto per scalare. Se non reggono, avrai capito dove intervenire: dati, router, guardrail o capacità. È così che un'idea giusta diventa una pratica sostenibile.