La parte difficile del routing dei modelli non è il router

Il tuo CFO si chiede perché la spesa per Claude Opus sia raddoppiata il mese scorso. La tua dashboard può mostrare quale applicazione e quale chiave API hanno speso quei soldi. Ma non può dirti se quel lavoro richiedesse effettivamente Opus.

Questa distinzione sta diventando una delle domande più importanti nell'infrastruttura AI.

La selezione del modello non è più un dettaglio tecnico nascosto all'interno di un'applicazione. È una decisione di allocazione delle risorse presa migliaia — o milioni — di volte ogni mese. Eppure, la maggior parte delle aziende la tratta ancora come una configurazione statica: si sceglie un modello capace, lo si collega al prodotto e si lascia che ogni richiesta fluisca attraverso di esso.

Era un modo ragionevole per lanciare la prima versione. È un modo decisamente costoso per gestire la decima.

Il default più sicuro sta diventando il più costoso

Oggi, lo stesso modello di frontiera può analizzare un codebase complesso, riassumere la trascrizione di una riunione, estrarre il nome di un'azienda e classificare un ticket di supporto.

I risultati possono essere tutti eccellenti. Ma questo non rende l'allocazione efficiente.

Quando un modello costoso esegue un lavoro che un modello più piccolo potrebbe completare altrettanto bene, lo spreco è quasi invisibile. Non ci sono interruzioni di servizio, messaggi di errore o evidenti problemi di qualità. Il sistema funziona esattamente come previsto; semplicemente, l'azienda paga più del dovuto.

La differenza di prezzo può diventare rilevante molto rapidamente. Al momento in cui scriviamo, Anthropic addebita 1 $ per milione di token di input e 5 $ per milione di token di output per Claude Haiku 4.5. Claude Opus 4.8 costa rispettivamente 5 $ e 25 $ — cinque volte di più per lo stesso volume di token.

Per un milione di richieste mensili con una media di 1.000 token di input e 500 token di output, si tratta di circa 3.500 $ su Haiku e 17.500 $ su Opus. La differenza è di 168.000 $ all'anno, prima di cache, sconti e altre rettifiche di prezzo.

Questo sovrapprezzo può essere interamente giustificato per ragionamenti difficili, coding complesso o analisi ad alto rischio. È più difficile da difendere quando una gran parte del carico di lavoro consiste in classificazione, estrazione, formattazione o riassunti di routine.

Il problema non è che l'azienda stia usando troppa AI. È che l'azienda non ha un modo affidabile per determinare quanta intelligenza richieda ogni singolo task.

I router hanno risolto l'esecuzione, non il giudizio

I vantaggi del routing dei modelli sono ormai ampiamente dimostrati.

FrugalGPT di Stanford ha dimostrato che i sistemi a cascata di modelli possono eguagliare le prestazioni del modello singolo più forte, con riduzioni dei costi fino al 98% sui carichi di lavoro valutati. RouteLLM ha successivamente dimostrato che le richieste più semplici possono essere inviate a modelli più economici riservando i modelli più forti per le query più difficili, registrando risparmi fino all'85% e mantenendo il 95% delle prestazioni di benchmark di GPT-4.

Questi numeri non devono essere presi come una promessa assoluta. I risparmi in produzione dipendono dal carico di lavoro, dai modelli messi a confronto e dagli standard di qualità che il prodotto deve mantenere.

Ma la conclusione di fondo è difficile da contestare:

Il modello giusto non è lo stesso per ogni richiesta.

L'infrastruttura si sta rapidamente adeguando a questa intuizione. L'Auto Router di OpenRouter, ad esempio, analizza un prompt e seleziona da un pool di modelli in base a fattori come il tipo di task, la complessità, la capacità e il compromesso costi-qualità desiderato.

Questo rende il routing più facile da eseguire. Ma non elimina la necessità di una strategia di routing.

Un router può scegliere tra diversi modelli. Ma non può sapere automaticamente cosa la tua azienda consideri un risultato accettabile, quanto costi un errore, se una risposta abbia effettivamente risolto il problema dell'utente o quali workflow richiedano uno standard più elevato rispetto a quanto suggerito dai loro stessi prompt.

La parte difficile non è inviare il traffico a un altro modello. La parte difficile è decidere, dati alla mano, che il traffico debba effettivamente andare lì.

L'unità di misura dell'economia dell'AI è il task

La maggior parte delle dashboard dei costi dell'AI è organizzata intorno a provider, modelli, token, applicazioni e chiavi API. Queste dimensioni spiegano dove sono finiti i soldi, ma non se sono stati spesi bene.

La dimensione mancante è il task.

Per ogni carico di lavoro ricorrente, i team dovrebbero essere in grado di rispondere a quattro domande:

1. Cosa è stato chiesto di fare al modello?

2. Quale modello ha gestito il task?

3. Il risultato ha soddisfatto lo standard di qualità richiesto?

4. Un altro modello avrebbe potuto ottenere lo stesso risultato a un costo inferiore?

Noi definiamo questo concetto come task-to-model fit: il grado in cui la capacità e il costo di un modello corrispondono ai requisiti effettivi del lavoro.

Una buona policy di routing, quindi, non si chiede: "Quale modello costa meno?"

Si chiede:

Qual è il modello meno costoso che supera costantemente la soglia di qualità per questo task?

Questa soglia di qualità non può derivare solo da una classifica generica. Deve riflettere i prompt, i dati, gli utenti e le conseguenze di un eventuale errore specifici dell'organizzazione. Un breve riassunto interno e una risposta regolamentata a un cliente possono sembrare simili a livello di prompt, pur richiedendo standard decisamente diversi.

Dall'osservabilità dei modelli all'intelligenza dei modelli

Questo è il problema attorno al quale stiamo costruendo Nebuly.

Il segnale che ci arriva dai clienti è chiaro: i team non vogliono solo confrontare quanto spendono su Claude, Gemini, ChatGPT o su un modello interno. Vogliono capire quali tipi di lavoro appartengono a ciascuno di essi.

Nebuly Intelligence è in fase di sviluppo per analizzare le interazioni reali dell'AI, identificare i task ricorrenti e collegare tali task ai modelli, ai costi e ai segnali di risultato che li sottendono. L'obiettivo è consigliare il modello più adatto per ciascun carico di lavoro e stimare quanto l'organizzazione potrebbe risparmiare mantenendo costante la qualità dell'output richiesta.

Quest'ultima condizione è fondamentale.

La raccomandazione di spostare un workflow su un modello più leggero dovrebbe essere trattata come un'ipotesi da verificare, non come un downgrade automatico. Le interazioni storiche rappresentative possono essere riprodotte sul modello alternativo. Verifiche deterministiche, revisioni umane, risultati degli utenti o valutazioni calibrate basate su modelli possono quindi determinare se la soglia di qualità viene preservata.

Supponiamo che un'azienda scopra che i riassunti ad alto volume rappresentano una quota significativa della spesa per i modelli di frontiera. Se un modello più piccolo produce risultati equivalenti su esempi rappresentativi, il risparmio potenziale può essere calcolato sui livelli di traffico attuali. Se non supera il test di qualità, il carico di lavoro rimane dove si trova e non viene rivendicato alcun risparmio.

L'obiettivo non è ridurre la qualità del modello. È smettere di pagare per una capacità che non migliora il risultato.

Le policy di routing dovrebbero essere gestite come un portafoglio

Per i team delle piattaforme AI, questo richiede un modello operativo diverso.

In primo luogo, monitora il lavoro a livello di task anziché affidarti solo ai totali di modelli e token. "Opus ha consumato 500 milioni di token" è un dato contabile. "Opus ha consumato 500 milioni di token per riassumere documenti interni" è un'opportunità di ottimizzazione.

In secondo luogo, misura la qualità per task e per modello. Un punteggio globale del modello nasconde le variazioni da cui dipende il routing. Un modello leggero può funzionare estremamente bene sull'estrazione e male sulla scrittura sfumata; un altro può mostrare il pattern opposto.

In terzo luogo, monitora i risparmi potenziali a parità di qualità. Ridurre i costi senza un vincolo di qualità è facile ma pericoloso. La metrica utile è quanta spesa può essere eliminata mantenendo il risultato al di sopra della soglia richiesta.

Infine, tratta il routing come una decisione continua piuttosto che come una configurazione una tantum. I modelli migliorano, i prezzi cambiano, i prompt si evolvono e il mix di richieste degli utenti si sposta. Un modello che rappresenta la scelta migliore oggi potrebbe non esserlo più tra sei mesi.

La policy di routing deve muoversi insieme al mercato.

L'intelligenza va allocata, non standardizzata

I modelli di frontiera continueranno a essere importanti. Man mano che le loro capacità miglioreranno, le aziende troveranno problemi sempre più preziosi da far loro risolvere.

L'errore sta nello standardizzare l'intelligenza di livello di frontiera su ogni problema semplicemente perché è il default più sicuro.

L'ottimizzazione dei costi dell'AI non consiste nell'usare modelli più deboli. Consiste nell'acquistare la giusta quantità di intelligenza per ogni task.

Il router può eseguire questa decisione. Il vero valore sta nel sapere quale debba essere tale decisione.

Questo è il livello che stiamo sviluppando in Nebuly, e condivideremo ciò che impareremo man mano che lo valideremo su carichi di lavoro reali.

Nebuly

Nebuly è la piattaforma di ROI per l'AI aziendale. Si collega agli agenti AI su cui gira il tuo business, agli assistenti con cui interagiscono i tuoi clienti e agli strumenti che i tuoi dipendenti usano ogni giorno, inclusi Claude, ChatGPT e Copilot, traducendo tale attività in valore aziendale. Quanto tempo viene risparmiato tra i vari team. Su quali ricavi influisce la tua AI. Come si presentano in pratica l'adozione e la competenza nell'uso dell'AI, tra reparti e aree geografiche. Tutto aggregato a livello organizzativo, mai legato ai singoli individui.

Se hai bisogno di chiarezza su cosa stia effettivamente offrendo il tuo investimento in AI, prenota una demo.