Small LLM vs Frontier Model: quale serve davvero alla tua funzionalità AI?

La maggior parte delle funzionalità AI all'interno di un prodotto SaaS non ha bisogno di un frontier model. Se il task è circoscritto (classificare un ticket, estrarre campi da un documento, redigere un'email a partire da fatti già disponibili), un modello piccolo con un prompt rigoroso e un validatore dell'output è di solito sufficiente e costa una frazione per chiamata. I frontier model vanno riservati al ragionamento aperto, al tool use multi-step complesso e a tutti i contesti in cui una risposta sbagliata ha un costo reale.

La domanda giusta non è "qual è il modello più intelligente"

I founder tendono a chiederci quale modello sia il migliore. È la domanda sbagliata, perché il modello in cima a una leaderboard è raramente quello più adatto a una funzionalità che girerà cinquantamila volte al mese all'interno del vostro prodotto. La domanda giusta è: qual è il modello più economico che supera il mio eval set con l'accuratezza che mi serve e i guardrail che posso permettermi di costruire?

Prendiamo l'esempio della classificazione dei ticket citato all'inizio e rendiamolo concreto. A cinquantamila ticket al mese, sia il modello in cima alla leaderboard che un modello "flash" distillato etichetteranno allo stesso modo i casi ovvi. La differenza emerge su quelli ambigui, e un validatore che controlla il tag rispetto alla lista consentita e riprova in caso di errore recupera una buona parte degli sbagli del modello piccolo. L'unico modo per sapere se il residuo è accettabile è far girare i cinquanta o alcune centinaia di ticket reali del vostro eval set su entrambi i modelli e confrontare i risultati, con il prezzo per chiamata a fianco di ciascuno.

Inquadrata così, la decisione smette di essere una scommessa sul marketing dei vendor e diventa una misurazione ingegneristica. La categoria dei modelli piccoli si è evoluta rapidamente; la recente ondata di release "flash" e distillate da diversi laboratori significa che un modello che due anni fa sarebbe stato all'avanguardia ora costa pochissimo per token e gira su una singola GPU. Se sia sufficiente per le vostre esigenze dipende da quattro fattori.

Le quattro domande che decidono tutto

1. Il task è circoscritto?

Un task circoscritto ha una forma di input nota, una forma di output nota e un insieme ristretto di risposte accettabili. "Estrai il numero fattura, la data di scadenza e il totale da questo PDF" è circoscritto. "Leggi le ultime sei email di questo cliente e decidi cosa fare" non lo è.

I modelli piccoli eccellono nei task circoscritti perché il prompt può portare la maggior parte dell'intelligenza: lo schema, le regole, tre esempi pratici. Degradano nei task non circoscritti perché devono improvvisare, ed è esattamente lì che le prestazioni calano al diminuire del numero di parametri.

2. Si può verificare l'output a basso costo?

Se un controllo deterministico riesce a intercettare la maggior parte degli output errati, si può usare un modello più piccolo e lasciare che sia il validatore a fare il lavoro pesante. Validazione dello schema JSON, regex su date e importi, lookup nel vostro database, un limite di lunghezza: queste operazioni non costano nulla per chiamata e trasformano l'errore occasionale del modello in un retry invece di un bug visibile al cliente. Abbiamo descritto questo pattern in guardrail deterministici per l'affidabilità delle funzionalità AI.

Se l'unico modo per verificare l'output è che un essere umano lo legga, il modello deve sbagliare meno spesso e di propria iniziativa, il che vi spinge verso l'alto nel listino prezzi.

3. Quanto costa una risposta sbagliata?

Un ticket di supporto mal classificato costa a un operatore dieci secondi. Un riassunto del dosaggio errato in uno strumento sanitario, o una decisione di rimborso sbagliata in un agente e-commerce, costa molto di più. Prezzate il fallimento, non la chiamata. Dove il fallimento è economico, ottimizzate il costo per chiamata. Dove il fallimento è costoso, il premium per token di un frontier model è irrilevante rispetto al rischio, e dovreste aggiungere anche un passaggio di revisione umana indipendentemente dal modello scelto.

4. L'input entra nel contesto e serve memoria?

I modelli piccoli hanno tipicamente un contesto utile più breve e si perdono prima nei documenti lunghi. Se la vostra funzionalità deve tenere in vista un contratto di 200 pagine, o mantenere lo stato attraverso un flusso di lavoro in venti step, o fate chunking aggressivo (più engineering) oppure pagate per un modello che regge il carico. Il lavoro agentivo multi-step con tool è il caso più lampante a favore dei frontier model, e vale la pena leggere agenti versus workflow prima di dare per scontato di aver bisogno dell'agente.

A cosa serve davvero un modello piccolo: il nostro motore di outreach

Il nostro strumento di outbound è un esempio concreto. Esegue il crawling del sito di ogni prospect con un'istanza self-hosted di Firecrawl, passa il testo della pagina a un modello locale e scrive un'email personalizzata per azienda. Il task è circoscritto: l'input è qualche pagina di testo, l'output è una breve email che segue il nostro template e il nostro tono, e un validatore rifiuta tutto ciò che è troppo lungo, cita un prodotto che non offriamo o non fa riferimento a un fatto tratto dal sito.

Ciò che ci ha sorpreso è che una singola chiamata con il compito "estrai i fatti e redigi l'email" ha battuto una chain multi-step (estrai, poi pianifica, poi scrivi) sia su costo che su qualità, anche con il modello più piccolo. Meno passaggi significa meno punti in cui il modello può allontanarsi dal testo di partenza. Abbiamo trattato il caso generale in singola chiamata versus agent chain. Il punto per chi acquista: un modello piccolo ben vincolato più un validatore era lo strumento giusto, e un frontier model avrebbe aggiunto costo senza cambiare il tasso di risposta.

Quando vale la pena pagare per il frontier model

Siate onesti sui casi in cui il risparmio diventa un costo. Il motore di outreach sopra se la cava con un modello piccolo per un solo motivo: c'è un unico hop, testo della pagina in entrata ed email in uscita, con un validatore a monte. Rimuovete una qualsiasi di queste condizioni e il quadro cambia.

• Ragionamento aperto su input disordinato. Triage che richiede giudizio, non regole. Tutto ciò in cui le istruzioni dicono "usa la tua discrezionalità". Il nostro validatore può rifiutare un'email che non cita nessun fatto dal sito; non può valutare se il modello ha scelto il fatto giusto, e quando quel giudizio è l'intera funzionalità, si vuole il modello più potente.
• Tool use multi-step. Agenti che chiamano più API, interpretano i risultati e decidono il passo successivo. Nel momento in cui il nostro task diventasse "esegui il crawl del sito, decidi quali pagine contano, controlla il CRM, poi scrivi", il modello piccolo dovrebbe mantenere lo stato attraverso i passaggi, che è esattamente dove perde il filo.
• Chiamate a basso volume e alto valore. Se la funzionalità gira alcune centinaia di volte al mese e ogni risultato viene rivisto da una persona senior, la differenza di costo è trascurabile. Comprate accuratezza.
• Generazione di codice e trasformazioni complesse. Il divario qualitativo è ancora ampio.
• La prima versione, prima di avere gli eval. Spesso è più conveniente lanciare su un modello potente, raccogliere traffico reale, costruire un eval set di cinquanta o alcune centinaia di esempi reali e poi scalare verso il basso dove gli eval lo consentono.

Quest'ultimo punto è importante. Partire da un frontier model e scendere è una decisione misurata, supportata da un eval set. Partire da un modello piccolo e scoprire in produzione che non è all'altezza significa riscrivere prompt e guardrail sotto pressione, senza un eval set che vi dica quando avete finito.

Come la scelta cambia il vostro preventivo

I founder si aspettano che il modello piccolo renda il progetto meno costoso da sviluppare. Per lo più non è così. Il costo di sviluppo sta nella progettazione del prompt, nel validatore, nell'eval set, nella logica di retry e fallback e nell'integrazione nel prodotto. Questo lavoro è lo stesso qualunque modello ci sia dietro. Se mai, un modello piccolo richiede uno strato di validazione più spesso, che significa leggermente più engineering, non meno.

Ciò che cambia è il costo operativo. I prezzi per chiamata tra un frontier model e un modello piccolo su API hosted differiscono di un multiplo significativo, e su un anno di traffico reale quella differenza può superare il budget di sviluppo iniziale. Chiedete una proiezione su tre livelli di volume prima di firmare; la nostra guida all'ottimizzazione dei costi LLM elenca le leve che contano oltre alla scelta del modello, come il caching e la lunghezza del prompt.

Il self-hosting del modello piccolo è una decisione separata. Strumenti come vLLM e Ollama lo rendono tecnicamente semplice, ma conviene solo a volumi stabili o quando la residenza dei dati lo impone. Ai volumi tipici delle prime fasi, un modello economico su API hosted vince una volta contabilizzato il tempo ingegneristico.

La soluzione di compromesso: costruite l'interruttore, non la scommessa

Qualunque cosa decidiate, non lasciate che sia incorporata nel codice. Pretendete tre cose nel brief:

• Il modello dietro un unico valore di configurazione. Passare da un frontier model a uno piccolo, o tra provider diversi, deve essere un deployment, non uno sprint.
• Un eval set rilasciato insieme alla funzionalità. Da cinquanta a qualche centinaio di esempi reali con output attesi, da eseguire prima di ogni cambio di modello. Senza di esso, "il modello più economico è abbastanza buono?" è una supposizione. Sosteniamo che questo debba rientrare nel contratto in eval nei contratti con vendor AI.
• Un percorso di fallback. Quando il modello piccolo non supera la validazione due volte, escalate quella singola chiamata al modello più potente invece di restituire un errore all'utente. Questo vi dà l'economia del modello piccolo con la qualità worst-case del frontier model.

Impostato così, la questione del modello diventa una manopola che regolate man mano che arrivano traffico ed evidenze, invece di una decisione presa una volta sola senza dati.

Se state definendo il perimetro di una funzionalità AI e volete una risposta diretta su quale tier di modello richiede e quanto costerà farla girare, parliamone.