Modelli, token, costi, latenza: scegliere lo strumento giusto per il task

I modelli generativi non sono intercambiabili. Hanno dimensioni, ragionamento, finestra di contesto, costo per token, velocità di risposta diversi. Il modello “migliore” è il più adatto al task specifico, non quello in cima alle classifiche. Saperlo scegliere riduce costi (anche di 10x) e migliora qualità.

Perché questa lezione conta

Usare il modello più potente per ogni task è come usare un trapano industriale per appendere un quadro: funziona, ma è inefficiente e spesso peggiora il risultato. Modelli grandi sono più lenti, più costosi, e per task semplici producono output troppo elaborati. Modelli piccoli sono rapidi e poco costosi ma falliscono su ragionamento profondo. Senza criterio, si scelgono modelli per abitudine o marketing.

Obiettivo operativo

Alla fine devi saper:

1. leggere la scheda tecnica di un modello per capire a cosa serve;
2. abbinare task → modello in modo motivato;
3. ridurre costi senza degradare qualità tramite ottimizzazione del contesto.

Nucleo della lezione

1. Caratteristiche operative di un modello

Sei dimensioni che contano:

• Dimensione/capacità di ragionamento: modelli “frontier” (Claude Opus, GPT-5, Gemini Ultra) per ragionamento complesso, planning, debug profondo. Modelli “mid” (Claude Sonnet, GPT-5 mini) per la maggior parte dei task. Modelli “small/fast” (Claude Haiku, GPT-5 nano, Gemini Flash) per task semplici, classificazione, routing.
• Finestra di contesto: quanti token può ricevere in input. Va dai 4K-32K dei modelli vecchi ai 200K-2M dei moderni. Più contesto = più informazioni utilizzabili, ma costo cresce linearmente.
• Quality del codice: alcuni modelli sono ottimizzati per coding (Claude Sonnet, DeepSeek Coder, Qwen Coder). Altri sono generalisti.
• Multimodalità: vede immagini, PDF, audio. Utile per design review, screenshot di UI, schemi.
• Costo per token: input vs output, pricing molto diverso per fascia. Un modello frontier costa 10-30x un modello small.
• Latenza: tempo di risposta. Streaming (token mostrati man mano) maschera la latenza ma non la riduce. Per autocomplete serve latenza <300ms; per refactor profondo accetti 30s.

Le sei dimensioni non sono ordinate da una sola scala “qualità”: sono trade-off.

2. Token: cosa sono e cosa costano

Un token ≈ 4 caratteri in inglese, ~3 in italiano, 1 carattere o meno per CJK. Un file di 1000 righe di codice ≈ 5K-15K token a seconda di stile.

Costo: prezzato separatamente per input e output. Output costa tipicamente 3-5x l’input.

Esempio (ordine di grandezza, varia per fornitore):

• modello frontier: input ~$3-15 per milione token, output ~$15-75 per milione.
• modello mid: input ~$0.3-3, output ~$1.5-15.
• modello small: input ~$0.05-0.5, output ~$0.2-2.

Caching del prompt (offerto da Anthropic, OpenAI, altri) riduce drasticamente costo input ripetuto: se invii lo stesso AGENTS.md/contesto in 50 chiamate, dalla seconda paghi una frazione (10-25%).

Conseguenza pratica: un task pesante con modello frontier su contesto grande può costare ordini di euro. Un task ripetitivo su modello small costa frazioni di centesimo. Sapere ordini di grandezza prima di lanciare evita sorprese.

3. Abbinare task a modello

Linee guida:

• Autocomplete inline: small/fast. Latenza < qualità.
• Refactor di funzione, edit puntuale: mid. Buon rapporto qualità/costo/latenza.
• Planning architetturale, debug profondo, refactor cross-file: frontier. Ragionamento conta più di velocità.
• Classificazione, routing, riassunti brevi: small.
• Generazione test, boilerplate, scaffolding: mid.
• Code review approfondita: frontier (legge sfumature).
• Domanda fattuale generica: mid è quasi sempre sufficiente.
• Task lunghi su grandi codebase: frontier con ampia finestra di contesto.

Variante: alcuni IDE AI permettono di scegliere modello per livello di interazione (autocomplete = small, chat = mid, agente = frontier). Sfrutta la separazione.

Procedura pratica

Per ogni nuovo workflow stima:

1. Volume: quante chiamate al giorno/settimana?
2. Token medi per chiamata: input + output stimati.
3. Costo unitario: prezzo modello x token = costo per chiamata.
4. Costo aggregato: chiamate x costo unitario. Se sopra soglia personale, ottimizza.

Ottimizzazioni possibili:

• modello più piccolo dove qualità è sufficiente;
• prompt caching per parti ripetute;
• contesto più mirato (riduzione input);
• output più mirato (“rispondi in 3 righe” invece di paragrafi);
• batch / spezzettamento se il fornitore offre tariffe ridotte.

Laboratorio guidato

Stima costo per tre workflow:

Workflow 1 — Debug rapido: 10 chat al giorno, 2K token input, 500 token output. Modello mid.

Workflow 2 — Generazione feature: 1 sessione agente al giorno, 50K token input (codebase + AGENTS.md), 10K output. Modello frontier. (Con prompt caching su AGENTS.md.)

Workflow 3 — Code review PR: 5 review al giorno, 30K token input (diff + contesto), 3K output. Modello mid o frontier.

Per ognuno: costo giornaliero stimato, costo mensile (× 22 giorni), confronto fra “tutto frontier” e “scelta calibrata”. Il delta tra le due strategie è il valore della lezione.

Output atteso

Una tabella personale a 3 colonne (task, modello scelto, motivazione + costo orientativo) e ~10 righe (i task ricorrenti). Documento da aggiornare quando arrivano nuovi modelli o cambiano i prezzi.

Studio passo passo

Studia questa lezione in tre passaggi, senza correre subito al prompt o al codice.

1. Prima lettura: chiarisci l’obiettivo: leggere le caratteristiche operative di un modello in funzione del lavoro da svolgere, non del marketing. Se non riesci a riscriverlo in una frase tua, rileggi il nucleo della lezione.
2. Seconda lettura: trasforma i contenuti in domande operative:

• Contesto, ragionamento, multimodalità, qualità del codice, costo per richiesta e tempo di risposta.
• Task brevi e task profondi: quando serve velocità, quando serve accuratezza, quando serve una finestra di contesto ampia.
• Come evitare sprechi: ridurre input irrilevante, chiedere output mirato, spezzare richieste, riusare artefatti.

3. Applicazione: svolgi il laboratorio: stimare il costo operativo di tre workflow: debug rapido, generazione feature, revisione di una pull request. L’output da ottenere è: una tabella di scelta strumento/task con compromessi tra costo, velocità, qualità e rischio.

Prima di passare alla lezione successiva, controlla di avere un artefatto concreto: una tabella, un prompt, una checklist, un mini report, un diff commentato o una decisione scritta. Nel vibe coding la comprensione resta astratta finché non produce una traccia verificabile.

Checklist di verifica

• so dare ordine di grandezza del costo di un modello frontier vs small;
• ho un workflow in cui ho davvero ridotto il modello e mantenuto qualità;
• conosco la finestra di contesto del modello che uso di default;
• ho attivato prompt caching dove il fornitore lo offre.

Errori comuni

Default frontier per tutto. Comodo, costoso. Per metà dei task qualità non cambia.

Ignorare la finestra di contesto. Mandare 300K token a un modello da 200K causa errori di troncamento o costo inaspettato (alcuni fornitori escludono, altri tagliano silenziosamente).

Confondere ragionamento e dimensione. Un modello con “extended thinking” / reasoning può superare un modello più grande senza thinking su task complessi. La dimensione non è l’unica leva.

Non monitorare consumi. Senza dashboard, scopri il costo a fine mese. Tutti i fornitori principali offrono usage dashboards: usali.

Confondere latenza e qualità. Modello veloce ≠ modello peggiore. Per molti task la latenza bassa abilita workflow che modelli lenti rendono frustranti.

Prompt di lavoro

Aiutami a stimare costo e modello giusto per questo workflow:

Descrizione: [es. agente che genera test per ogni PR]
Frequenza: [es. 20 PR/giorno]
Input medio: [es. 30K token: codice + diff + AGENTS.md]
Output medio: [es. 5K token: nuovi test]
Vincoli qualità: [es. test devono essere eseguibili e passare]

Per ognuno di {small, mid, frontier} dammi:
1. fit con la qualità richiesta (alto/medio/basso)
2. costo stimato giornaliero (con e senza prompt caching)
3. latenza tipica
4. rischio principale

Concludi con raccomandazione esplicita e indicazione del breakeven (quando saltare al livello superiore).

Esercizio finale

Vai sulla dashboard di consumi del tuo fornitore principale (Anthropic Console, OpenAI Dashboard, Google AI Studio, Cursor settings, ecc.). Quanti token hai consumato l’ultima settimana? In quali workflow? C’è un workflow che da solo pesa più del 50%? Quel workflow è il candidato n.1 per ottimizzazione: modello più piccolo, contesto ridotto, prompt caching.