Non serve sempre il modello più potente: alle aziende serve il modello giusto
Nel mondo dell'intelligenza artificiale generativa si parla quasi solo di potenza. Più parametri, più contesto, punteggi più alti nei benchmark. È una gara tecnologica importante, perché i modelli di punta permettono di affrontare problemi che fino a poco tempo fa sembravano fuori portata.
Per un'azienda, però, la domanda giusta non è quale sia il modello più potente sul mercato. La domanda giusta è un'altra: qual è il modello meno costoso e meno complesso che svolge questo lavoro con la qualità che mi serve. Sembra una sfumatura, e invece è proprio qui che si decide se un progetto di AI sta in piedi dal punto di vista economico oppure no.
Il modello migliore non è sempre quello adatto
La maggior parte del lavoro in azienda non consiste nel dimostrare teoremi o analizzare da soli migliaia di pagine tecniche. Nella pratica di ogni giorno l'AI serve per cose molto più concrete. Classificare richieste e documenti, estrarre i dati da una fattura, riassumere un testo, riscrivere una mail, cercare un'informazione in un archivio, assegnare un ticket al reparto giusto.
Per attività come queste un modello di punta funziona di sicuro. Il problema è che è una potenza enorme rispetto a quello che serve davvero. È come pagare un fuoriclasse per un lavoro che verrebbe bene a chiunque.
L'imbianchino o la grande impresa di ristrutturazioni
Immaginiamo di dover tinteggiare le pareti di una stanza. Non abbiamo tempo o voglia di farlo da soli, quindi ci affidiamo a qualcuno.
Possiamo chiamare un imbianchino, un professionista che arriva, protegge i mobili, dà due mani di pittura e in una giornata ha finito. Oppure possiamo rivolgerci a una grande impresa di ristrutturazioni, quella con squadre, cantieri organizzati, uffici tecnici e mezzi per rifare interi edifici.
La parete, alla fine, resta dipinta allo stesso modo. La differenza è che la grande impresa ci fattura molto di più, perché con lei paghiamo una struttura pensata per lavori ben più grandi, che per una sola stanza non ci serve.
Con i modelli di AI succede la stessa cosa. Quando li scegliamo guardando la potenza sulla carta invece del compito reale, non stiamo pagando il risultato. Stiamo pagando una capacità che nella maggior parte dei casi resta inutilizzata.
La trappola del benchmark
Non è una storia nuova. Per anni abbiamo confrontato telefoni e computer a colpi di core, frequenze e benchmark, per poi usare una minima parte di quella potenza.
Con i modelli linguistici capita lo stesso. Un modello va meglio in matematica avanzata o nel codice complesso, e da lì si conclude che convenga usarlo anche per classificare una richiesta commerciale o sistemare una mail. È un errore di prospettiva. Un benchmark misura una capacità in condizioni precise, non dimostra che quella capacità produca valore in ogni processo aziendale.
Tra un modello che prende novanta e uno che prende novantaquattro in una prova generale ci può essere una bella differenza tecnica. Ma se sul tuo compito specifico arrivano tutti e due al novantanove, nella pratica quella differenza sparisce. A quel punto contano molto di più il costo per operazione, la velocità di risposta, la prevedibilità del risultato, la possibilità di tenere i dati in casa e la stabilità nel tempo.
Il prezzo mette in chiaro lo spreco
Basta guardare i listini per capire quanto pesa la scelta. Dentro lo stesso fornitore, il modello di punta può costare decine o addirittura centinaia di volte più del modello piccolo della stessa famiglia, a parità di richiesta.
Su una singola chiamata la differenza sembra niente. Su milioni di chiamate all'anno diventa una voce di bilancio vera. E il conto reale spesso è più alto di quello che sembra, perché a quello che leggi si sommano i passaggi di ragionamento, i contesti lunghi, i tentativi ripetuti, le chiamate a strumenti esterni e i controlli. Un'applicazione che sulla carta era semplice si trasforma in una catena di chiamate costose, soprattutto quando si mette un agente autonomo a fare un lavoro che si risolveva con una sola risposta ben impostata.
Uno studio recente racconta il caso di un'azienda arrivata a spendere oltre duecentomila dollari al mese di sola inferenza, con più di sette richieste su dieci che erano attività ordinarie, gestibili benissimo da modelli più piccoli. È il caso di quella singola azienda, non una regola valida per tutti, ma rende bene l'idea di quanto sia concreto il rischio di sovradimensionare.
Non un modello solo, ma un insieme di modelli
Il tema è così sentito che è nato un intero filone di ricerca dedicato, quello del model routing. L'idea è semplice. Invece di mandare ogni richiesta al modello più potente, un sistema valuta quanto è difficile il compito e sceglie il modello adatto. Le richieste facili vanno ai modelli economici, solo quelle davvero complesse salgono a quello superiore.
Diversi lavori in questo campo hanno mostrato tagli di costo importanti mantenendo la stessa qualità. Non sono numeri da prendere come garanzia universale, perché dipendono dai modelli e dal tipo di richieste, ma il principio resta chiaro. La qualità di un sistema non dipende dall'usare sempre il modello più potente, dipende da quanto bene si combinano modelli diversi.
I modelli piccoli e l'inferenza in casa
Per molti compiti ripetitivi un modello piccolo offre vantaggi che vanno oltre il prezzo. È più veloce, più prevedibile e più facile da specializzare. In diversi casi può girare direttamente sui server aziendali, o anche su una workstation, senza mandare i dati fuori.
Tenere l'inferenza in casa vuol dire meno dipendenza da servizi esterni e più controllo su dati riservati, tempi di risposta e versioni del modello. Attenzione però, locale non vuol dire gratis. Hardware, energia, manutenzione e sicurezza hanno un costo, e per volumi bassi una API remota può restare la scelta più conveniente. Il punto non è schierarsi tra grande e piccolo, tra API e server in casa. Il punto è mettere insieme gli strumenti giusti e usare ognuno dove rende.
Come decidere davvero
Per farlo, un'azienda deve smettere di comprare "intelligenza artificiale" in generale e iniziare a guardare i propri processi. Per ogni attività conviene fissare qualche paletto. Qual è la qualità minima che accetto, quanto posso spendere per operazione, quanta attesa tollero, quanto sono sensibili i dati.
Poi si prova sul campo, con richieste vere dell'azienda e non con i benchmark pubblici. Sapere quale modello vince in astratto serve a poco. Serve sapere quale modello gestisce meglio proprio le tue fatture, i tuoi ticket, i tuoi contratti e le tue comunicazioni. La domanda corretta non è quale sia il modello più intelligente, ma quale sia il più economico che tiene il livello di servizio richiesto sui tuoi casi reali.
La maturità non è usare sempre il massimo
Le aziende più mature con l'AI non saranno quelle che useranno più modelli di punta, ma quelle che sapranno tenerli per i problemi dove servono per davvero. Ricerca, sviluppo complesso, analisi difficili, ragionamenti su casi nuovi.
Un modello potente resta prezioso proprio perché costa. E proprio per questo non andrebbe sprecato su ogni richiesta. L'obiettivo non è rinunciare alla potenza, è evitare di pagarla quando non serve. Non dobbiamo scegliere una volta per tutte tra l'imbianchino e la grande impresa. Chiamiamo l'imbianchino per tinteggiare la stanza e la grande impresa quando c'è davvero da ristrutturare tutto l'edificio.
La domanda da cui partire, allora, non è "possiamo usare il modello più avanzato", ma "in quali casi il modello più avanzato produce abbastanza valore da giustificare quello che costa". È una domanda semplice, e spesso è quella che trasforma l'AI da esperimento costoso a strumento di lavoro sostenibile.
Nota. Il caso aziendale citato è descritto dagli autori di un preprint del 2026 sul model routing e riguarda un singolo partner, quindi va inteso come esempio e non come una percentuale valida per tutte le imprese. Anche le stime di risparmio di questo filone di ricerca dipendono dai modelli e dai dati usati nei test.
“RouteNLP: Closed-Loop LLM Routing with Conformal Cascading and Distillation Co-Optimization”