Che cosa deve sapere chi decide prima di usare un modello di linguaggio: la serie in dieci decisioni

Il preventivo di un progetto con modelli di linguaggio arriva in un’unità che non avete mai comprato: il token. La scheda del fornitore dichiara i numeri che vuole, il listino sale con voci dai nomi nuovi - contesto, ragionamento, finestra - e le promesse ripetono la lezione più antica del campo: il clamore prepara la delusione. Prima di firmare serve un sapere minimo, e non è quello di chi costruisce i modelli: è quello di chi li sceglie e li paga.

Questa serie insegna quel sapere in dieci pezzi, dal tokenizzatore all’addestramento. Questo pezzo è l’ingresso, e mette le dieci decisioni nell’ordine delle tre domande di chi decide: quanto mi costerà davvero, come scelgo il fornitore, come mi tutelo. Prima delle domande, però, va nominata la scelta di fondo che cambia dove ogni costo colpisce: in quale dei tre modi si compra.

Un confine, detto subito: questo pezzo copre il sapere tecnico che viene prima della firma - come la macchina è fatta e dove nascono i suoi costi. La riservatezza dei dati, la conformità e le clausole dei contratti sono un capitolo a parte e qui non entrano: meritano più di un inciso.

I tre modi di comprare un modello

A servizio si paga a token e l’infrastruttura è del fornitore; su macchine a noleggio si paga a ore e i pesi sono vostri; su macchine proprie si investe e tutto diventa dimensionamento. Le dieci decisioni valgono in tutti e tre i modi, ma colpiscono in punti diversi.

A servizio (API a token). Si manda la richiesta al fornitore e si paga a consumo, per token: niente macchine, niente motore da gestire. Tutte le voci di costo - la lingua, il contesto, il ragionamento - arrivano in un’unica fattura, e l’infrastruttura è invisibile, compresa nella tariffa. È il modo più rapido per partire; in cambio, spesso la scheda del modello è muta, e ogni domanda - coi documenti che porta con sé - passa dai server del fornitore: i dati escono dal vostro perimetro.

Modello privato su macchine a noleggio. Si prende un modello coi pesi disponibili e lo si fa girare su macchine affittate: si paga a ore di macchina, non a token. Qui il preventivo cambia natura: contano i parametri totali (dimensionano la macchina da affittare), il motore che esegue i pesi, e il contesto come memoria per ogni utente collegato. La scheda si può verificare, i dati restano nel proprio perimetro. E pagare a ore ha un vantaggio suo: se l’uso sta in una fascia certa - l’assistente interno che serve dalle 8 alle 18 - le macchine si accendono lì, e fuori fascia non si paga; un investimento in macchine proprie, invece, costa uguale anche di notte.

Su macchine proprie. Stesso schema del noleggio, ma le macchine si comprano: un investimento, più le competenze per tenerle in vita. Tutto il costo diventa dimensionamento - memoria per i parametri totali, finestra per utenti insieme, perfino i pesi letti dal disco quando la memoria non basta - e il pezzo sui motori, il satellite che affianca la serie, è la mappa di questo mondo: llama.cpp, vLLM e gli altri, con i loro compromessi.

Nelle dieci decisioni che seguono, i modi di acquisto di un modello dicono dove guardare per fare una scelta consapevole:

• a servizio pesano le quattro voci della fattura - la lingua (1), il contesto (2), il ragionamento (3) e le chiamate dell’agente (4) - più la scheda (6), che a servizio è spesso muta;
• a noleggio pesano i parametri della taglia (5), la scheda (6) e i tre livelli (7);
• su macchine proprie il contesto (2) torna, stavolta come memoria, insieme ai due numeri della taglia (5), ai tre livelli (7) e al satellite dei motori;
• le tutele - il collaudo (8), le promesse (9) e i limiti (10) - valgono identiche in tutti e tre i modi.

Quanto costerà davvero

Cinque voci decidono il costo per token: la lingua, la lunghezza del contesto, il ragionamento, le chiamate dell’agente coi suoi strumenti e i parametri attivi. Si pagano in token, l’unità dei listini - e contesto e parametri anche in memoria.

1 · La lingua ha un sovrapprezzo. Il testo entra nel modello diviso in unità chiamate token, e i listini fatturano token. Quante unità servono per lo stesso contenuto lo decide il vocabolario, che arriva insieme al modello e non si sceglie: per l’italiano servono da un terzo alla metà di token in più che per l’inglese (93 contro 72 sulla codifica dei modelli recenti, 113 contro 75 su quella di GPT-2), e fra lingue diverse il divario misurato arriva a quindici volte. La domanda da fare: quanti token consuma un nostro documento tipo? Si misura in un pomeriggio, coi contatori pubblici, prima di firmare. Il pezzo sul tokenizzatore spiega da dove nasce il sovrapprezzo e perché accompagna il modello per tutta la sua vita.

2 · Il contesto si paga più che in proporzione. La finestra di contesto è la quantità massima di testo, misurata in token, che il modello può ricevere in una volta: dentro ci stanno la domanda, i documenti allegati e la conversazione fatta fin lì. Ciò che resta fuori, per il modello, non esiste; allungare la finestra quindi serve, ma il calcolo cresce col quadrato - un contesto dieci volte più lungo, fino a cento volte più lavoro - ed è la ragione dei listini che salgono col contesto, e del rincaro della memoria. Su macchine a noleggio o proprie il contesto è anche un dimensionamento: ogni utente collegato occupa la propria finestra, e la memoria si calcola, come prima stima prudente, moltiplicando quella di una finestra per il numero di utenti collegati insieme - i motori migliori ottimizzano proprio questa moltiplicazione, e il satellite sui motori racconta come. E il contesto per domanda non è un dato di natura: è la prima leva del progettista, perché recuperare meglio i passaggi che servono significa portarne meno. La domanda da fare: quanto contesto serve davvero al nostro caso d’uso, e che cosa paghiamo per il di più? Il pezzo sull’attenzione mostra il costo quadratico, quello sulle evoluzioni la memoria che il contesto occupa.

3 · Il ragionamento del modello fa parte dei token che si pagano. I modelli di ragionamento pensano prima di rispondere, e ogni token di quel pensiero si fattura come la risposta: cento token di risposta possono arrivare dopo mille token di ragionamento, e il costo è undici volte quello della sola risposta. E il pensiero si paga due volte: in token sulla fattura, e in secondi davanti allo schermo di chi aspetta. Per molti compiti quel pensiero vale il prezzo; per molti altri basta un modello che risponde subito. La domanda da fare: questo caso d’uso ha bisogno di un modello che ragiona? E i token di ragionamento compaiono in fattura? Il pezzo sull’addestramento racconta da dove nasce la capacità, e perché si paga in token.

4 · Una domanda all’agente, molte chiamate al modello: si pagano tutte. I preventivi degli assistenti nascondono spesso una voce intera: gli strumenti con cui l’agente cerca, legge gli archivi, esegue le azioni. Per servirsene, l’agente chiama il modello più volte per ogni domanda dell’utente: gli chiede che cosa fare, esegue lo strumento indicato, gli riporta il risultato, e ricomincia finché la risposta non è pronta. Ogni chiamata si paga, e le definizioni degli strumenti, come i loro risultati, sono token anche loro, rimessi nel contesto a ogni chiamata. Il costo di una domanda va quindi moltiplicato per il numero delle chiamate - che dal di fuori non si vede: si conta alla prova, facendo lavorare l’agente su domande tipo e leggendo i contatori di consumo che ogni servizio espone. La domanda da fare: quante chiamate al modello fa una domanda tipo, e quanti token consumano gli strumenti a ogni chiamata? Com’è fatto un agente lo spiega la serie sugli agenti, che racconta anche la lingua con cui parla coi suoi strumenti.

5 · I parametri attivi decidono quanto costa ogni token, i totali quanta memoria serve. La scheda di un modello moderno porta due numeri: i parametri totali, che stanno in memoria, e quelli attivi, che lavorano a ogni token. DeepSeek-V4 Flash dichiara 284 miliardi di totali e 13 attivi: un parametro su ventidue fa il calcolo di ogni token, ma tutti e 284 miliardi vogliono memoria. Chi è a servizio paga soprattutto il secondo numero, dentro la tariffa; chi affitta o possiede le macchine paga tutti e due, perché i totali dimensionano la macchina. Chi legge solo i totali sbaglia il preventivo nelle due direzioni. La domanda da fare: quanti parametri attivi per token, e quanti totali da tenere in memoria? Il pezzo sulle evoluzioni spiega la miscela di esperti che sta dietro i due numeri.

Le leve, poi, non pesano uguale: nel caso tipico comandano il contesto e le chiamate dell’agente, seguiti dal ragionamento; la lingua è la leva più piccola - e l’unica che non si può spegnere. Il caso svolto più avanti mette i moltiplicatori uno accanto all’altro.

E accanto ai token corre una seconda unità che i listini non mostrano: i secondi. La velocità di risposta si misura in token al secondo, e un modello che costa poco ma risponde lento può costare carissimo nell’uso - un cliente al telefono non aspetta il risparmio. La latenza non sta in nessuna scheda: si misura al collaudo, col cronometro, come il resto (decisione 8).

Un’avvertenza sul denaro: le cifre in euro qui non ci sono, perché il pezzo non invecchi a ogni ritocco dei listini. Il lato economico - l’unità di spesa, i consumi, chi paga che cosa - sta nella serie sugli agenti, nei pezzi sull’impatto computazionale ed energetico e su chi paga il conto degli agenti.

Come si sceglie il fornitore

La scheda del modello è il documento del mestiere: si legge coi due numeri della taglia e si giudica da quanto se ne può verificare; poi si completa chiedendo chi risponde di ciascun livello.

6 · La scheda del modello vale quanto se ne può verificare. La scheda è il documento che presenta il modello, e le voci che contano sono cinque: famiglia, parametri totali e attivi, finestra di contesto, tokenizzatore, licenza - che cosa si compra e che cosa si paga. La famiglia dice se il modello è denso o a miscela di esperti, e non è un verdetto di qualità ma un compromesso: il denso è semplice e prevedibile, il misto costa meno per token e più in memoria. Le schede, poi, non sono tutte uguali. DeepSeek, Qwen e GLM pubblicano il rapporto tecnico e i pesi: modelli documentati, dove si può verificare tutto, fino a scaricare i pesi e misurarli. GPT e Claude, da GPT-4 in poi, non dichiarano né architettura né taglia: modelli muti. La qualità non c’entra: cambia quanto potete verificare di persona, e in un contratto la differenza pesa. La domanda da fare: qual è la scheda completa, coi due numeri della taglia - e che cosa posso verificarne io? Il pezzo sulle architetture insegna a leggerla voce per voce, documentati e muti compresi.

7 · Tre livelli, tre responsabili: l’addestramento, il motore, i pesi. Dietro il sistema che comprate lavorano tre cose diverse, e nei contratti possono diventare tre controparti diverse: chi ha addestrato il modello, il motore che lo esegue - col fornitore che lo ospita - e i pesi che avete scelto, con la loro architettura. Ognuno dei tre risponde di cose sue. Dall’addestramento viene il carattere del modello: assistente ordinato o ragionatore ostinato. Dal motore vengono la velocità e la memoria occupata. Dai pesi vengono il vocabolario - e quindi il sovrapprezzo della lingua della decisione 1 - e i costi di base. Tenere distinti i tre livelli serve a leggere bene la scheda e il preventivo, e a sapere chi risponde di che cosa quando qualcosa non va. La domanda da fare: se cambio il motore, o chi lo ospita, che cosa mi porto via e che cosa devo rifare? Il pezzo sulle evoluzioni e quello sull’addestramento fissano la distinzione fra i tre livelli.

Come ci si tutela

Tre cautele che la storia del campo insegna dal 1958: il collaudo si fa su casi mai visti e si ripete in esercizio; le promesse si collaudano oggi, i limiti si leggono nel loro perimetro - e a promesse e limiti si mette una data di riesame. La quarta viene dal mercato: il modello ha un ciclo di vita, e la difesa è la sostituibilità.

8 · Il collaudo si fa su casi mai visti, e non finisce alla firma. Chi addestra un modello tiene da parte una serie di esempi, addestra sul resto e alla fine conta quanti di quegli esempi mai visti il modello risolve. La capacità che si misura così si chiama generalizzazione, ed è il metro che accompagna tutta la serie: il percettrone riconosce l’83,2% delle cifre mai viste, la rete multistrato il 96,3%. Chi compra verifica un’altra cosa: che il sistema intero - il modello, le istruzioni, il contorno che li tiene insieme - funzioni sul proprio compito. Il principio però non cambia, e va applicato due volte. La prima volta al collaudo: i casi li portate voi, e il fornitore non deve averli mai visti, né nelle demo né durante la messa a punto. La seconda in esercizio: i modelli a servizio si aggiornano, i dati veri cambiano, e un collaudo fatto una volta sola invecchia con loro - la prova va ripetuta. Gli stessi casi, infine, servono a mettere due offerte a confronto: la gara si gioca lì, e non sulle demo preparate dai fornitori. Le grandezze da confrontare sono tre:

• le risposte, giudicate sui vostri casi;
• i tempi, cioè la latenza di ogni risposta;
• i consumi, cioè le chiamate al modello che ogni domanda innesca.

Tempi e consumi si misurano solo alla prova: non stanno in nessun listino. La domanda da fare: con quali casi collaudiamo, chi li ha visti prima, e ogni quanto rifacciamo la prova? Il concetto di generalizzazione lo abbiamo illustrato per la prima volta nell’articolo sul percettrone.

9 · La promessa si collauda oggi, e si riesamina presto. Nel 1958 il New York Times annunciò la macchina che «cammina, parla, vede, scrive, si riproduce ed è cosciente»; la macchina vera era un percettrone che imparava lentamente e si fermava a un limite preciso. Chi credette all’annuncio credette a una cosa falsa - eppure quattro di quelle sei promesse, camminare, parlare, vedere e scrivere, si sono poi avverate, con oltre mezzo secolo di ritardo: l’annuncio sbagliava i tempi più che la direzione. Una promessa va quindi trattata come un’affermazione da verificare, non come una funzione già consegnata: si collauda oggi, su ciò che il prodotto sa fare adesso, e si scrive in calendario la data del riesame - perché i progressi veri, ormai, si contano in mesi. La domanda da fare: che cosa è verificabile oggi, e fra quanto riesaminiamo la promessa? La storia delle origini racconta l’annuncio e la macchina vera.

10 · Un limite dimostrato non chiude la strada. Nel 1969 una dimostrazione matematica stabilì che cosa un percettrone non avrebbe mai potuto imparare, e chi finanziava la ricerca si ritirò; il limite era vero, ma valeva per quella macchina - le reti a più strati lo superarono. Quello che il 1958 insegna sulle promesse, il 1969 lo insegna sui verdetti: anche un limite ha un perimetro, e anche un limite ha una data. La domanda da fare: questo limite è del prodotto che ho davanti o della strada intera - e quando lo ricontrolliamo? Il limite del 1969 è raccontato nel pezzo sul percettrone, il suo superamento in quello sulle reti multistrato.

Gli ultimi due punti guardano la stessa storia dai suoi due eccessi: le promesse gonfiate del 1958, il verdetto preso per definitivo del 1969. Chi decide non deve farsi né incantare né frenare, e la difesa è la stessa per entrambi gli eccessi: una data di riesame sul calendario.

Alle tre cautele della storia se ne aggiunge una del mercato, che questa serie non copre e la serie gemella di strategia ha già misurato: il modello che comprate è un prodotto, con un ciclo di vita deciso dal fornitore. Resta in servizio per una durata che nessuno dichiara; quando viene messo in dismissione, il preavviso pubblicato va da due settimane a sei mesi, e poi smette di rispondere. La tutela non è cercare il modello eterno, che non esiste: è la sostituibilità - progettare fin dal primo giorno che cambiare modello sia una configurazione e non una riscrittura, col collaudo della decisione 8 a dire se il nuovo lavora come il vecchio. La domanda da fare: se il fornitore ritira il nostro modello, che cosa dobbiamo riscrivere - e abbiamo il collaudo per verificare il sostituto? Il pezzo su chi paga il conto degli agenti racconta il ciclo di vita, i preavvisi misurati e la sostituibilità.

Il preventivo, svolto su un caso

Un assistente che risponde ai clienti sui manuali, in italiano: le dieci decisioni al lavoro su un caso solo, coi moltiplicatori al posto degli euro.

Un’azienda vuole un assistente che risponda ai clienti a partire dai manuali e dai contratti, in italiano. Parte a servizio, per fare presto. Ogni domanda di un cliente pesa circa duecento token; ma per rispondere il modello deve leggere le pagine giuste del manuale, e ogni domanda porta con sé sedicimila token di contesto - ottanta volte la domanda: è la voce più grossa del costo (decisione 2). Tutto questo, in italiano, costa circa un terzo in più che in inglese (decisione 1). Il fornitore propone il modello «che ragiona»: per risposte da manuale non serve, e attivarlo moltiplicherebbe per undici il costo di ogni risposta (decisione 3). E l’assistente è già un piccolo agente: prima cerca le pagine giuste, poi risponde - più chiamate al modello per ogni domanda, e anche la ricerca è fatta di token (decisione 4). Al collaudo l’azienda porta cinquanta domande vere dei suoi clienti, mai mostrate al fornitore, col cronometro accanto alle risposte - e nella gara scarta l’offerta più economica proprio lì: i contenuti reggevano, i tempi no, e al telefono i secondi si sentono tutti. Fissa il riesame ogni tre mesi (decisioni 8 e 9); quando una prova va male, prima di archiviare chiede se il limite è del modello provato o della strada intera (decisione 10). Un anno dopo, coi volumi cresciuti, valuta il passaggio su macchine a noleggio con un modello aperto: da lì in poi contano i due numeri della scheda - 284 miliardi di parametri da tenere in memoria, 13 che lavorano a ogni token (decisioni 5 e 6) - e il motore diventa una scelta sua (decisione 7). In tutto il racconto non c’è un euro: solo i moltiplicatori, che restano veri quando i listini cambiano.

Le dieci domande, da portare in riunione

La tabella raccoglie le dieci decisioni nella forma in cui si usano: la decisione, la domanda da fare al fornitore o al proprio tecnico, e il pezzo della serie che spiega il perché. In coda la cautela sul ciclo di vita, che viene dalla serie gemella.

Dietro le dieci domande sta una scommessa vecchia di tre quarti di secolo: Turing immaginò nel 1950 una macchina istruita con premi e punizioni, e i modelli di ragionamento di oggi sono addestrati esattamente così. Chi vuole vedere come è fatta la scommessa può salire la scala della serie dal primo gradino, un pezzo alla volta: in cima, queste dieci domande saranno diventate vostre.

I concetti che questo articolo introduce

Due voci sono nuove, le lenti di questo ingresso: i tre modi di acquisto e il costo per token. Le altre voci citate appartengono ai pezzi della serie, che le definiscono.

---

Fonti

Le affermazioni di questo pezzo vengono dalla serie che introduce: i numeri citati stanno nei dieci pezzi, ognuno coi propri rimandi alle fonti primarie. Fa eccezione la scheda di DeepSeek-V4 Flash, citata direttamente.

• DeepSeek-AI, DeepSeek-V4-Flash, scheda del modello su Hugging Face, 2026, scheda pubblica consultata il 18/8 - 284 miliardi di parametri totali, 13 attivi per token, licenza MIT.
• Improve and Manage, Le origini del machine learning, 2026 - la distinzione fondativa (programmare o far apprendere) e la lezione del clamore: il New York Times del 1958.
• Improve and Manage, Il percettrone, 2026 - la generalizzazione misurata sui dati mai visti (83,2%) e il muro del 1969.
• Improve and Manage, Reti neurali multilivello, 2026 - il salto al 96,3% e la lezione dei limiti che spostano la ricerca.
• Improve and Manage, Dal testo ai token: il tokenizzatore, 2026 - il costo della lingua (113 contro 75, fino a quindici volte) e la scelta che si fa prima del modello.
• Improve and Manage, Dai token ai vettori: l’embedding, 2026 - la matrice degli embedding e il trapianto del vocabolario.
• Improve and Manage, Dai vettori alle relazioni: l’attenzione, 2026 - il costo quadratico del contesto (mille token, un milione di confronti).
• Improve and Manage, Il Transformer, aperto col cacciavite, 2026 - il montaggio del modello e la generazione un token alla volta.
• Improve and Manage, Le evoluzioni: MoE e cache di chiavi e valori, 2026 - i parametri attivi contro i totali (671 e 37 su DeepSeek-V3) e il bilancio architettura, motore, addestramento.
• Improve and Manage, Le architetture a confronto, 2026 - la lettura della scheda e la trasparenza dei documentati contro i muti.
• Improve and Manage, L’addestramento che fa la differenza, 2026 - il carattere che viene dall’addestramento, il costo del ragionamento e il dibattito sull’emergenza.
• Improve and Manage, I motori che eseguono i pesi, 2026 - la mappa dei motori per chi affitta o possiede le macchine: llama.cpp, vLLM e gli altri, lo streaming dal disco e la scelta pesata.
• Improve and Manage, serie-machine-learning, GitHub, 2026 - il repository dei widget della serie, citato dalle fonti dei singoli pezzi.