Velocità, volume, costo: scegliere uno significa rinunciare agli altri
Ogni sistema AI in produzione affronta un trilemma: throughput, latenza, costo. Non si ottimizzano tutti e tre insieme. Ecco cosa cambia nella pratica.
Quando una PMI inizia a usare un LLM (Large Language Model) in produzione, la prima domanda che si pone è: «costa troppo?». È la domanda giusta. Solo che quasi nessuno risponde nel modo giusto.
Il 22 aprile 2026, DigitalOcean ha pubblicato un'analisi tecnica firmata da Balaji Varadarajan, Staff Engineer, che chiarisce qualcosa che nell'ecosistema AI si tende a non dire esplicitamente: non puoi avere velocità, volume e costo basso allo stesso tempo. Devi scegliere cosa sacrificare.
Lo chiamano il trilemma dell'inferenza LLM.
Il trilemma non è un problema tecnico astratto
Throughput è quante richieste riesce a gestire il sistema in un certo tempo. Latenza è quanto tempo passa tra la domanda e la prima risposta. Costo è quello che paghi per farlo girare.
Aumenti il throughput? La latenza sale. Vuoi latenza bassa? Il costo cresce. Provi a tagliare il costo? Comprometti uno dei due.
Questo non è un difetto di configurazione. È una conseguenza fisica del modo in cui i modelli linguistici funzionano. A differenza dei classici servizi web, che si scalano aggiungendo istanze identiche dietro un load balancer, i modelli LLM sono vincolati alla memoria del processore grafico e alla velocità con cui quella memoria trasferisce i dati. Non basta aggiungere server.
Ho lavorato su questo problema con alcuni clienti industriali. La risposta giusta non è trovare la configurazione perfetta: è capire quale delle tre dimensioni conta davvero per il loro caso d'uso specifico.
Il costo che nessuno calcola
L'analisi di DigitalOcean distingue quattro tipi di costo, e i primi due sono quelli che le aziende conoscono. Il costo hardware e il costo operativo (elettricità, cloud, raffreddamento) sono numeri che si mettono in un foglio di calcolo.
Gli altri due, quasi nessuno li conta.
Il costo da opportunità mancata è l'equivalente moderno della GPU che gira a vuoto alle tre di notte perché non c'è traffico. Ogni minuto di inattività su hardware dedicato è denaro che non produce output. Senza orchestrazione, questa voce può diventare la più grande del totale.
Il costo di engineering è quello che sorprende di più: trovare la configurazione ottimale per uno stack come vLLM richiede settimane di lavoro specializzato. Le aziende possono spendere mesi di ingegneria per risparmiare qualche migliaio di euro al mese di GPU. L'economicità di quel compromesso dipende da chi fa il conto.
Quantizzazione: il primo posto dove intervenire
Il termine tecnico è quantizzazione. In pratica si tratta di ridurre la precisione numerica con cui il modello rappresenta i propri parametri. Passare da BF16 a FP8 dimezza la memoria richiesta, il che significa che lo stesso hardware gestisce più richieste contemporaneamente oppure si usa meno hardware per la stessa capacità.
Quando una PMI inizia a usare un LLM (Large Language Model) in produzione, la prima domanda che si pone è: «costa troppo?». È la domanda giusta. Solo che quasi nessuno risponde nel modo giusto.
Il 22 aprile 2026, DigitalOcean ha pubblicato un'analisi tecnica firmata da Balaji Varadarajan, Staff Engineer, che chiarisce qualcosa che nell'ecosistema AI si tende a non dire esplicitamente: non puoi avere velocità, volume e costo basso allo stesso tempo. Devi scegliere cosa sacrificare.
Lo chiamano il trilemma dell'inferenza LLM.
Il trilemma non è un problema tecnico astratto
Throughput è quante richieste riesce a gestire il sistema in un certo tempo. Latenza è quanto tempo passa tra la domanda e la prima risposta. Costo è quello che paghi per farlo girare.
Aumenti il throughput? La latenza sale. Vuoi latenza bassa? Il costo cresce. Provi a tagliare il costo? Comprometti uno dei due.
Questo non è un difetto di configurazione. È una conseguenza fisica del modo in cui i modelli linguistici funzionano. A differenza dei classici servizi web, che si scalano aggiungendo istanze identiche dietro un load balancer, i modelli LLM sono vincolati alla memoria del processore grafico e alla velocità con cui quella memoria trasferisce i dati. Non basta aggiungere server.
Ho lavorato su questo problema con alcuni clienti industriali. La risposta giusta non è trovare la configurazione perfetta: è capire quale delle tre dimensioni conta davvero per il loro caso d'uso specifico.
Il costo che nessuno calcola
L'analisi di DigitalOcean distingue quattro tipi di costo, e i primi due sono quelli che le aziende conoscono. Il costo hardware e il costo operativo (elettricità, cloud, raffreddamento) sono numeri che si mettono in un foglio di calcolo.
Gli altri due, quasi nessuno li conta.
Il costo da opportunità mancata è l'equivalente moderno della GPU che gira a vuoto alle tre di notte perché non c'è traffico. Ogni minuto di inattività su hardware dedicato è denaro che non produce output. Senza orchestrazione, questa voce può diventare la più grande del totale.
Il costo di engineering è quello che sorprende di più: trovare la configurazione ottimale per uno stack come vLLM richiede settimane di lavoro specializzato. Le aziende possono spendere mesi di ingegneria per risparmiare qualche migliaio di euro al mese di GPU. L'economicità di quel compromesso dipende da chi fa il conto.
Quantizzazione: il primo posto dove intervenire
Il termine tecnico è quantizzazione. In pratica si tratta di ridurre la precisione numerica con cui il modello rappresenta i propri parametri. Passare da BF16 a FP8 dimezza la memoria richiesta, il che significa che lo stesso hardware gestisce più richieste contemporaneamente oppure si usa meno hardware per la stessa capacità.
DeepSeek-V3, uno dei modelli più discussi di inizio 2025, è stato addestrato nativamente in FP8. Qwen3 distribuisce checkpoint ufficiali FP8 con qualità quasi identica alla versione completa. Sui processori più recenti (H100, MI300X), FP8 raddoppia circa il throughput in fase di decodifica.
Non è magia: è un compromesso esplicito tra precisione e velocità. Per la maggior parte dei casi d'uso aziendali, quel compromesso è accettabile.
La scelta che determina tutto
L'analisi di DigitalOcean arriva a un punto che trovo onesto: non esiste una risposta universale su quando ottimizzare per latenza e quando per throughput. Dipende dal tipo di workload.
Un assistente che risponde alle domande dei clienti in tempo reale ha bisogno di latenza bassa. Un sistema che elabora documenti in background può accettare latenza più alta in cambio di costo per token ridotto. Un'azienda che gestisce migliaia di richieste simultanee su batch notturni ha problemi completamente diversi da chi serve dieci utenti in tempo reale.
Il punto è questo: prima di acquistare o configurare qualunque infrastruttura AI, devi sapere quale dimensione stai ottimizzando. Throughput, latenza o costo. Non tutte e tre.
Se non lo hai ancora fatto, prendi uno dei tuoi processi AI attivi, quello che ha il volume più alto, e rispondi a questa domanda: la velocità della risposta è critica per chi la riceve, oppure conta solo che il risultato arrivi corretto entro la fine della giornata?
La risposta cambia la configurazione. E la configurazione cambia il costo., uno dei modelli più discussi di inizio 2025, è stato addestrato nativamente in FP8. Qwen3 distribuisce checkpoint ufficiali FP8 con qualità quasi identica alla versione completa. Sui processori più recenti (H100, MI300X), FP8 raddoppia circa il throughput in fase di decodifica.
Non è magia: è un compromesso esplicito tra precisione e velocità. Per la maggior parte dei casi d'uso aziendali, quel compromesso è accettabile.
La scelta che determina tutto
L'analisi di DigitalOcean arriva a un punto che trovo onesto: non esiste una risposta universale su quando ottimizzare per latenza e quando per throughput. Dipende dal tipo di workload.
Un assistente che risponde alle domande dei clienti in tempo reale ha bisogno di latenza bassa. Un sistema che elabora documenti in background può accettare latenza più alta in cambio di costo per token ridotto. Un'azienda che gestisce migliaia di richieste simultanee su batch notturni ha problemi completamente diversi da chi serve dieci utenti in tempo reale.
Il punto è questo: prima di acquistare o configurare qualunque infrastruttura AI, devi sapere quale dimensione stai ottimizzando. Throughput, latenza o costo. Non tutte e tre.
Se non lo hai ancora fatto, prendi uno dei tuoi processi AI attivi, quello che ha il volume più alto, e rispondi a questa domanda: la velocità della risposta è critica per chi la riceve, oppure conta solo che il risultato arrivi corretto entro la fine della giornata?
La risposta cambia la configurazione. E la configurazione cambia il costo.
Fonte: «The LLM Inference Trilemma: Throughput, Latency, Cost», DigitalOcean Engineering Blog, Balaji Varadarajan, 22 aprile 2026.