Guide pratiche

L’economia dell’inferenza: quantizzazione, decodifica speculativa e l’arte di servire gli LLM a basso costo

PagedAttention, batching continuo, costi della cache KV, quantizzazione, decodifica speculativa, instradamento MoE e fasce batch: perché il costo minimo per token continua a scendere, mentre sopra di esso si è riaperta una fascia premium da

Gabriele Masetti · 2026-09-19

Perché l’inferenza ora assorbe il budget per l’IA

L’addestramento conquista i titoli; l’erogazione dei modelli presenta il conto. Secondo le stime del settore, l’inferenza rappresenta il 55-80% della spesa delle aziende per le GPU destinate all’IA. Gli analisti che seguono la fatturazione delle infrastrutture cloud affermano che, all’inizio del 2026, l’inferenza ha superato il 55% della spesa per l’IA nel cloud, oltrepassando per la prima volta l’addestramento. Il problema emerge nelle conference call sui risultati, non solo nei benchmark: il CEO di Salesforce Marc Benioff ha detto nel podcast All-In che Salesforce è sulla buona strada per spendere 300 milioni di dollari in token di Anthropic nel 2026, mentre il CEO di ServiceNow Bill McDermott ha parlato pubblicamente di clienti «sorpresi dalla tokenizzazione dei modelli» quando le fatture basate sull’utilizzo hanno inciso sui loro budget.

L’addestramento è una spesa in conto capitale sostenuta una sola volta, da ammortizzare su tutte le richieste che un modello servirà nel corso della sua esistenza. Ognuna di quelle richieste comporta però una chiamata di inferenza distinta e, su larga scala, questa moltiplicazione fa impallidire il conto dell’addestramento: una sola funzione di chat molto usata, o uno strumento di programmazione agentica, può generare in un mese più token di quanti ne abbia consumati l’intera fase di preaddestramento.

L’inferenza è inoltre soggetta a vincoli di latenza che l’addestramento non ha: un processo di addestramento può aspettare in coda, ma un utente che fissa un indicatore di caricamento no. Questo costringe a dimensionare le risorse sul carico di picco anziché su quello medio. Ciascuna delle tecniche descritte qui sotto agisce su una di tre leve: ridurre il calcolo per token, ridurre la memoria per token oppure ridurre il numero di token da calcolare.

Il crollo dei prezzi e la fascia che si è riaperta al di sopra

La prova più evidente del drastico aumento di efficienza nell’erogazione dei modelli è il prezzo di listino. Al lancio, nel 2023, GPT-4 costava 30 dollari per milione di token in input e 60 dollari per milione di token in output. GPT-5.1 è ancora a listino a 1,25 dollari per milione di token in input e 10 dollari per milione di token in output: un prezzo 24 volte più basso per l’input e 6 volte più basso per l’output, per un modello che nei benchmark supera nettamente l’originale del 2023.

GPT-5.1 non è più al vertice dell’offerta di OpenAI, e i modelli che lo precedono non costano meno. Nella famiglia GPT-5.6, Sol, il modello di punta, è a listino a 4 dollari in input e 20 dollari in output per milione di token con un contesto breve, e a 8 dollari in input e 30 dollari in output oltre quella soglia; Terra costa 2 dollari in input e 12 dollari in output; Luna, la fascia dei modelli piccoli, 0,20 dollari in input e 1,20 dollari in output. È con Luna che il crollo è proseguito: il suo prezzo per l’input è 150 volte più basso di quello di GPT-4, mentre Sol costa per token più di GPT-5.1.

I prezzi di Anthropic raccontano la stessa storia a due facce. Opus 5 e Opus 4.8 sono entrambi a listino a 5 dollari in input e 25 dollari in output per milione di token. Claude Sonnet 5 costa 2 dollari in input e 10 dollari in output, e quello che era stato presentato al lancio come prezzo introduttivo è ora il prezzo standard: Anthropic dichiara che l’aumento a 3 dollari in input e 15 dollari in output, previsto per il 1 settembre 2026, non ci sarà. Sonnet 5 resta 6 volte meno caro del prezzo originale di GPT-4 per l’output, pur essendo un modello più potente.

Sopra tutti questi modelli c’è una fascia che non esisteva quando questa curva fu tracciata per la prima volta: Claude Fable 5.1 e Mythos 5.1 costano 10 dollari in input e 50 dollari in output per milione di token, gli stessi prezzi della modalità fast di Opus 5 e Opus 4.8. Il prezzo minimo continua a scendere, mentre il massimo è stato ricostruito più in alto. Fare budget partendo dall’idea che «i prezzi scendono e basta» significa mettere in conto la fascia usata l’anno scorso, non quella che il responsabile di prodotto vuole quest’anno.

Anche i confronti del prezzo per token tra generazioni sono meno netti di quanto sembrino. Anthropic osserva che Claude 4.7 e i modelli successivi usano un tokenizer più recente, che produce circa il 30% di token in più per lo stesso testo. Un taglio del prezzo per token non equivale a un taglio del prezzo per attività, e l’unico dato di cui fidarsi è quello della propria fattura.

Non è beneficenza: è l’effetto cumulativo di hardware migliore (H100 e ora Blackwell), software di erogazione più intelligente e formati di quantizzazione che al lancio di GPT-4 non esistevano. È l’ingegneria alla base del resto di questo articolo, e un andamento di cui si può beneficiare anche gestendo i modelli sulla propria infrastruttura.

Lo stack di serving: vLLM, SGLang e TensorRT-LLM

vLLM, sviluppato alla UC Berkeley (paper SOSP 2023), è il motore open source di riferimento per il serving per un motivo: PagedAttention. L’allocazione tradizionale della cache KV riserva per ogni richiesta un buffer contiguo dimensionato sulla lunghezza massima della sequenza. Questo comporta uno spreco di memoria GPU dovuto alla frammentazione: la maggior parte delle richieste non raggiunge mai quella lunghezza, ma la memoria viene comunque riservata. PagedAttention riprende il meccanismo della paginazione dei sistemi operativi: suddivide la cache KV in piccoli blocchi di dimensione fissa, non contigui, allocati secondo necessità, come avviene quando la memoria virtuale viene mappata sulla RAM fisica. La riduzione dello spreco di memoria riportata arriva fino al 90%.

La seconda idea fondamentale è il continuous batching (batching in-flight, o a livello di iterazione). Il batching tradizionale elabora un batch fisso durante il decode finché tutte le sequenze non sono terminate. Così, un batch di 32 richieste procede al ritmo della sequenza più lenta e gli slot della GPU restano inattivi per ogni richiesta conclusa prima delle altre. Il continuous batching, invece, pianifica il lavoro a livello del singolo passaggio di decode: a ogni forward pass, lo scheduler rimuove le sequenze terminate e ammette nuove richieste dalla coda. Il paper originale su vLLM ha misurato un aumento del throughput di 10-23 volte rispetto al batching statico; PagedAttention e continuous batching, insieme, sono generalmente indicati come responsabili di un miglioramento di 2-4 volte rispetto a un serving tradizionale.

SGLang punta invece sui prefissi ripetuti (prompt di sistema condivisi, esempi few-shot, cronologia delle conversazioni a più turni). La sua struttura RadixAttention conserva le voci della cache KV in un albero radix, così una nuova richiesta riutilizza automaticamente la cache del prefisso corrispondente più lungo già calcolato. I benchmark di SGLang riportano un throughput fino a 5 volte superiore a quello di vLLM e Guidance nei carichi di lavoro con molti prefissi condivisi; dati recenti su H100 con Llama-3.1-8B collocano SGLang a circa 16.200 token/sec contro i 12.550 di vLLM, un vantaggio di circa il 29%. Sotto una sovrapposizione dei prefissi condivisi di circa il 60%, però, il vantaggio si riduce fino ad avvicinarsi alla parità.

TensorRT-LLM, il motore di Nvidia basato sul compilatore TensorRT, implementa nativamente il batching in-flight, la cache KV paginata, la quantizzazione e il speculative decoding tramite un batch manager in C++, oltre al chunked prefill, che permette di alternare l’elaborazione dei prompt lunghi al decode già in corso. Richiede una configurazione più impegnativa rispetto a vLLM o SGLang (build del motore specifiche per ciascun modello), ma sfrutta al massimo l’hardware Nvidia ed è la scelta abituale quando il modello e la generazione di GPU destinati alla produzione sono stati fissati.

Cache KV: il costo della memoria che nessuno mette a bilancio

La cache KV conserva le proiezioni key e value di ogni token già elaborato, così l’attention non deve ricalcolarle per ogni nuovo token: è questo che rende il decode autoregressivo lineare, anziché quadratico, rispetto alla lunghezza del testo generato. La cache è distinta per sequenza, layer e head di attention e cresce con ogni token generato o acquisito.

Esempio di calcolo (ipotesi esplicitate). Consideriamo un modello denso della classe 70B con 80 layer e una dimensione dello stato nascosto di 8.192, in FP16 (2 byte per valore), senza grouped-query attention (il caso peggiore). La dimensione della cache KV per token è 2 (K e V) × 80 layer × 8.192 dimensioni dello stato nascosto × 2 byte ≈ 2,62 MB/token. I modelli della classe 70B usati in produzione impiegano di solito la grouped-query attention con un rapporto tra head delle query e head KV di circa 8:1, riducendo la dimensione a circa 330 KB/token.

Per un singolo contesto da 32K token, sono comunque 330 KB × 32.768 ≈ 10,3 GB di HBM per una sola sequenza, prima ancora che arrivi un secondo utente in contemporanea. Su una H100 da 80 GB, quella sola richiesta con un contesto lungo occupa già un ottavo della memoria totale: ecco perché l’allocazione paginata a livello di blocchi è preferibile alla prenotazione, per ogni richiesta, di un buffer contiguo dimensionato sul caso peggiore.

Il prefix caching è la risposta economica allo stesso problema: se i primi N token di una richiesta coincidono con quelli di una richiesta precedente (un prompt di sistema, un documento RAG, lo schema di uno strumento), si leggono le voci KV dalla cache invece di ricalcolarle. Anthropic applica alla lettura dalla cache una tariffa pari a 0,1 volte quella standard per l’input — uno sconto del 90% — mentre la scrittura costa 1,25 volte la tariffa standard con una TTL di 5 minuti o 2 volte con una TTL di 1 ora. Lo sconto si cumula con la riduzione del 50% della Batch API: una richiesta batch che usa la cache può quindi costare appena il 5% di una richiesta senza cache alla tariffa standard. Nella fascia Fable 5.1 e Mythos 5.1, la lettura dalla cache costa 0,025 volte la tariffa standard anziché 0,1 volte — 0,25 dollari per milione di token contro una tariffa base di 10 dollari — portando il costo minimo ottenibile cumulando gli sconti a circa l’1,25%.

OpenAI adotta una soluzione equivalente: i prompt di oltre 1.024 token vengono memorizzati automaticamente nella cache, con uno sconto del 90% sulla tariffa standard per l’input quando c’è una corrispondenza. Se un carico di lavoro presenta una struttura ripetuta — come accade nella maggior parte dei sistemi agentici e RAG — il prefix caching offre un vantaggio quasi gratuito, purché il contenuto stabile preceda quello variabile: qualsiasi modifica prima di un punto di interruzione della cache invalida tutto ciò che viene dopo.

Quantizzazione: da FP16 a FP8 a FP4/INT4

La quantizzazione riduce la precisione dei pesi (e talvolta delle attivazioni) per occupare meno memoria e aumentare la velocità dei calcoli: l’aritmetica a precisione inferiore è più rapida sull’hardware progettato per eseguirla. Ogni passaggio richiede nuovo hardware e nuove tecniche di calibrazione, non soltanto un formato numerico più piccolo.

FP8 è supportato nativamente da Hopper (H100/H200): i Tensor Core di quarta generazione e il Transformer Engine eseguono direttamente calcoli matriciali in FP8, offrendo un throughput applicativo pari a circa 2x quello di FP16 sullo stesso chip e dimezzando l’occupazione di memoria. Per contenere la perdita di accuratezza, alternano automaticamente FP8 e FP16 a seconda dell’operazione. Nell’inferenza, la perdita di qualità rispetto a FP16 è in genere minima: una riduzione di precisione quasi «gratuita». Per questo FP8 è ormai pressoché la scelta predefinita per l’erogazione di modelli di grandi dimensioni su flotte di GPU della classe H100.

INT4/FP4 comporta una riduzione maggiore e richiede una calibrazione più attenta. GPTQ (2022) è un metodo post-addestramento in un solo passaggio che comprime i pesi a 3-4 bit, mantenendo le attivazioni in FP16 e usando una correzione dell’errore di secondo ordine per limitare il degrado. AWQ, invece, individua i canali dei pesi più importanti in base all’ampiezza delle attivazioni e li protegge in via prioritaria; valutazioni indipendenti rilevano che, a 4 bit, AWQ mantiene l’accuratezza con maggiore costanza rispetto a GPTQ nelle diverse dimensioni della famiglia Llama, richiedendo meno dati di calibrazione. Nessuno dei due metodi è privo di costi: la quantizzazione a 4 bit riduce in misura rilevabile la qualità in alcuni compiti di ragionamento e su casi meno frequenti. Per questo, negli impieghi in produzione si eseguono benchmark sul proprio set di valutazione, anziché affidarsi a un dato aggregato di perplexity riportato in uno studio.

FP4 è il passaggio più recente ed è vincolato all’hardware: il formato NVFP4 di Nvidia è supportato nativamente solo dai chip Blackwell (B200, B300, RTX 5090, RTX PRO 6000). Usa piccoli blocchi di microscaling da 16 valori, con fattori di scala per blocco in FP8 (e4m3), rendendo il calcolo in virgola mobile a 4 bit non solo veloce, ma anche numericamente praticabile. Nei benchmark condotti da Nvidia su Llama-2-70B, Blackwell raggiunge fino a 4x i token/s per GPU di H100; Fireworks riferisce che il suo stack FireAttention V4 supera i 250+ token/s per utente su B200. Ma questi risultati sono possibili solo dopo che una flotta è effettivamente passata da Hopper a Blackwell.

Decodifica speculativa, distillazione e modelli piccoli

La decodifica speculativa affronta un collo di bottiglia diverso: la decodifica autoregressiva è limitata dalla larghezza di banda della memoria e genera un token per ogni passaggio completo nel modello, anche quando resta capacità di calcolo inutilizzata. Un modello preliminare piccolo e poco costoso propone diversi token in anticipo; il modello principale, più grande, li verifica tutti in un unico passaggio elaborato in batch, accettando quelli che avrebbe generato comunque. Se le previsioni del modello preliminare sono buone, si ottiene un’accelerazione generando più token per passaggio.

Medusa ed EAGLE sono i due approcci principali: entrambi addestrano teste di predizione aggiuntive sul modello principale stesso, anziché usare un modello preliminare separato. I benchmark SpecBench indicano per entrambi un’accelerazione complessiva di circa 2,4x su una singola A100, che sale a circa 2,8x nelle conversazioni a più turni e nel ragionamento matematico: più prevedibile è la continuazione, maggiore è il vantaggio. EAGLE-3 riporta accelerazioni di 2-6x a seconda delle dimensioni del modello e della configurazione del batch; per i modelli più grandi (70B+), i risultati tendono verso 4-6x, perché il costo aggiuntivo delle teste di predizione diventa trascurabile rispetto al risparmio sulla larghezza di banda della memoria. Nei benchmark di produzione su H100, EAGLE-3 supera EAGLE-2 e Medusa-2 del 15-25% in token/s. DeepSeek-V3 integra la predizione di più token direttamente nell’addestramento del modello di base, rendendo la decodifica speculativa una capacità incorporata anziché un’aggiunta successiva.

Distillazione e modelli piccoli affrontano i costi dall’altro lato: non serve erogare un modello grande per compiti che uno piccolo svolge abbastanza bene. Llama 3.2 offre varianti da 1B e 3B per il solo testo, destinate all’uso su dispositivi edge e all’erogazione a basso costo; Phi-3.5-Mini di Microsoft è un modello da 3,8B parametri ottimizzato per il ragionamento e il codice; Gemma 3 di Google è disponibile in una versione multilingue e multimodale da 4B.

Google ha reso noto che i suoi modelli Gemma 2 2B e 9B sono stati addestrati mediante distillazione delle conoscenze da un modello più grande, migliorando in misura rilevabile la qualità rispetto all’addestramento da zero di modelli delle stesse dimensioni. Un modello distillato da 8B che soddisfi i requisiti di qualità di un compito può costare 5-10x meno per token di un modello da 70B+, prima ancora di applicare quantizzazione o decodifica speculativa.

Erogazione dei modelli MoE e fascia batch/offline

Le architetture mixture-of-experts separano il numero di parametri dal costo di calcolo per token. DeepSeek-V3 è l’esempio pubblico più chiaro: 671B parametri totali, di cui solo 37B attivi per token. A ogni passaggio completo nel modello lavora circa il 5,5% dei parametri, con 256 esperti per livello e 8 selezionati per token tramite routing top-k; inoltre, la multi-head latent attention (MLA) riduce l’occupazione della cache KV, che altrimenti vanificherebbe parte del risparmio.

Secondo il rapporto tecnico di DeepSeek, il risultato è una qualità paragonabile a quella dei modelli più avanzati, a circa un decimo del costo di addestramento di un modello denso con capacità analoghe. La stessa sparsità riduce anche il calcolo necessario per l’inferenza: per ogni token si eseguono soltanto i FLOP degli esperti attivi, anche se la memoria HBM deve contenere tutti gli esperti. È questo il compromesso dei modelli MoE: impiegare più memoria GPU (per ospitare tutti gli esperti) in cambio di meno calcolo GPU (eseguendone solo una parte). Per questo i modelli MoE richiedono GPU con molta memoria e batch di grandi dimensioni.

Le fasce batch/offline sono la leva di risparmio più semplice per le attività che non richiedono risposte rapide. Sia Anthropic sia OpenAI offrono endpoint batch asincroni con uno sconto fisso del 50% sui token di input e output; i risultati arrivano di norma ben prima del limite di 24 ore. Per le valutazioni, la classificazione su larga scala, il completamento degli embedding mancanti o l’elaborazione notturna di documenti, la modalità batch offre quasi un risparmio di 2x senza altre modifiche. Lo sconto batch di Anthropic, inoltre, si combina in modo moltiplicativo con la cache dei prompt: il costo di una richiesta in batch con prompt memorizzato nella cache può scendere a circa il 5% di quello di una richiesta senza cache alla tariffa standard.

Sviluppare o acquistare: quando l’hosting in proprio conviene davvero

Il noleggio delle H100 non ha un prezzo di mercato unico, e le rilevazioni differiscono di oltre il doppio. Un’indagine aggiornata ad agosto 2026 colloca i prezzi tra 1,49 dollari/ora (una tariffa promozionale di Vast.ai) e 6,98 dollari/ora su Azure, con una fascia intermedia di 2,89-3,90 dollari e senza una media pubblicata, perché i fornitori offrono le H100 in configurazioni di nodi, regioni e fasce di servizio diverse. Un’altra rilevazione, riferita a settembre 2026, indica 2,89-11,06 dollari/ora, con una mediana vicina a 4,17 dollari presso i cloud specializzati contro 7,89 dollari presso gli hyperscaler. È questa variabilità il dato significativo: la scelta tra sviluppare e acquistare dipende da quale fornitore sia effettivamente disposto a vendervi capacità, e l’hosting in proprio conviene solo se quelle ore di GPU vengono sfruttate.

Esempio di calcolo (ipotesi esplicitate). Ipotizziamo un modello di classe 70B in FP8, gestito in proprio su 2 H100 SXM a 3,20 dollari/ora ciascuna (6,40 dollari/ora in totale), una tariffa pubblicata da un cloud specializzato, ed erogato tramite vLLM con batching continuo. Supponiamo inoltre che raggiunga — come ipotesi illustrativa, non verificata con un benchmark — una produzione aggregata di 2.000 token di output al secondo a pieno utilizzo. Sono 7,2 milioni di token/ora, pari a circa 0,89 dollari/Mtok come costo complessivo del solo noleggio delle GPU (esclusi i costi tecnici di gestione).

Confrontiamo questa cifra con un costo medio ponderato secondo un rapporto di 3:1 tra input e output, calcolato sui prezzi standard di Claude Sonnet 5: (3×2 dollari + 1×10 dollari) / 4 = 4 dollari/Mtok. Con queste ipotesi, l’hosting in proprio sembra costare circa 4-5 volte meno, ma solo con un utilizzo vicino al 100%. Se l’utilizzo scende al 30% (un livello realistico per un traffico a picchi), il costo effettivo sale a circa 2,96 dollari/Mtok, cancellando gran parte del vantaggio ancor prima di considerare il team necessario per far funzionare vLLM in produzione e gestire i guasti delle GPU. Il confronto, inoltre, non è esatto token per token: il tokenizer più recente del modello ospitato addebita più token per lo stesso testo.

La regola pratica è questa: l’hosting in proprio conviene con un traffico sostenuto e di grande volume, che mantenga le GPU vicine alla saturazione — pipeline batch interne, funzionalità con un QPS elevato o modelli sottoposti a fine-tuning che nessun fornitore di API offre. Le API convengono quando il traffico è discontinuo, serve una qualità di frontiera che nessun modello aperto raggiunge oppure il volume è troppo basso per tenere occupata una flotta di GPU. La maggior parte dei team sottovaluta quest’ultima condizione e paga ore di GPU inutilizzate che, con il caching attivo, sarebbero costate meno sotto forma di chiamate API.

A settembre 2026, la maggior parte dei grandi fornitori cloud è ancora nel pieno della migrazione da Hopper a Blackwell. Dove viene indicato, il prezzo della capacità B200 varia da 3,50 a 27,04 dollari/ora; la capacità assegnata da NVIDIA è già impegnata fino al 2027 e quella per il packaging CoWoS è esaurita. Di fatto, quindi, Blackwell è riservato agli hyperscaler, mentre Hopper resta ampiamente disponibile. La flotta di H100 su cui si basano oggi i calcoli economici dell’FP8 non è quella su cui si baseranno domani quelli dell’FP4: per la maggior parte dei team, l’FP4 è ancora un progetto, non un prezzo.