La sala server che non si accende

Immagina una sala server nuova, costruita in fretta in una zona industriale dove tutto sembra pronto per accogliere una nuova generazione di infrastrutture AI: i rack sono installati, le GPU sono state ordinate, il sistema di raffreddamento è stato progettato e il personale è già stato assunto. Manca però una cosa che nessun modello linguistico può sostituire: la capacità elettrica necessaria per alimentare l’impianto.

Il problema può sembrare paradossale, soprattutto in un settore abituato a ragionare in termini di scalabilità quasi infinita, ma è proprio qui che emerge una delle contraddizioni dell’attuale economia dell’intelligenza artificiale. Il software può essere distribuito in pochi minuti, mentre una rete elettrica, una cabina primaria, una linea ad alta tensione o un nuovo impianto di generazione richiedono anni di progettazione, autorizzazioni e investimenti.

L’intelligenza artificiale è quindi un’industria pesante che si presenta come software.

Dietro ogni modello ci sono semiconduttori, memoria, packaging avanzato, data center, trasformatori, reti elettriche, sistemi di raffreddamento, acqua, cemento e infrastrutture logistiche. Questi elementi non seguono necessariamente i cicli di rilascio dei modelli e non possono essere moltiplicati con un aggiornamento software.

È questo il punto da cui partire per capire il prossimo problema dell’AI: non soltanto quanto saranno capaci i modelli, ma quanta capacità computazionale sarà fisicamente disponibile, dove sarà disponibile e a quale costo.

Il collo di bottiglia non è necessariamente il chip

Quando si parla di scarsità nell’AI si tende a pensare immediatamente alle GPU.

È una semplificazione comprensibile, ma ormai insufficiente.

La filiera degli acceleratori avanzati dipende da numerosi anelli che devono funzionare contemporaneamente. La litografia EUV, fondamentale per produrre i chip più avanzati, utilizza sistemi la cui tecnologia è unica nel settore e fornita da ASML. La produzione dei nodi avanzati è concentrata in pochi grandi operatori e TSMC continua a investire contemporaneamente in Taiwan e in nuovi impianti internazionali, mentre sviluppa anche capacità di packaging avanzato come CoWoS e tecnologie di stacking tridimensionale.

Poi arriva la memoria ad alta banda, indispensabile per gli acceleratori moderni. SK hynix, Samsung e Micron sono i principali produttori del mercato HBM e la crescita della domanda AI sta aumentando la pressione sulla capacità produttiva destinata a questo componente.

Il chip, quindi, è soltanto una parte della storia.

Una GPU senza memoria sufficiente non risolve il problema. Una GPU con memoria sufficiente ma senza packaging adeguato non risolve il problema. Un server completo senza elettricità disponibile non produce un solo token.

E un data center senza capacità di raffreddamento non può trasformare indefinitamente l’elettricità in calcolo.

Il vincolo minimo

Per descrivere questa situazione possiamo utilizzare un modello volutamente semplice, ma utile per ragionare sulle decisioni industriali:

[math]\displaystyle C = \min( C_{\text{chip}}, C_{\text{memoria}}, C_{\text{packaging}}, C_{\text{potenza}}, C_{\text{raffreddamento}}, C_{\text{acqua}} )[/math]

La capacità effettiva di calcolo disponibile è determinata, in prima approssimazione, dall’anello più stretto della catena.

Il modello non pretende di descrivere tutta la complessità tecnica di un data center. Serve a ricordare una cosa molto più concreta: aumentare la capacità di un componente che non rappresenta il collo di bottiglia non aumenta necessariamente la capacità complessiva del sistema.

Se il limite è la connessione alla rete, acquistare altre GPU non aggiunge capacità computazionale utilizzabile.

Se il limite è il raffreddamento, installare altri acceleratori peggiora il problema.

Se il limite è la memoria, un processore più potente non risolve la scarsità.

Se il limite è il packaging, avere wafer disponibili non significa avere acceleratori pronti per essere installati.

Il secondo aspetto importante è che il vincolo non rimane necessariamente nello stesso punto. Oggi può essere una componente della supply chain dei semiconduttori, domani può diventare la disponibilità elettrica e successivamente la capacità di trasmissione o raffreddamento.

Il terzo aspetto è geografico.

La capacità computazionale non è una grandezza puramente globale. È distribuita nello spazio e dipende dalle infrastrutture locali che permettono di trasformare capitale investito in calcolo effettivamente utilizzabile.

L’elettricità diventa una variabile industriale

Secondo l’International Energy Agency, i data center hanno consumato circa 415 TWh di elettricità nel 2024, pari a circa l’1,5% del consumo elettrico mondiale. Nel suo scenario di base, l’IEA prevede che il consumo possa superare i 945 TWh nel 2030, più che raddoppiando rispetto al 2024. L’AI rappresenta il principale motore della crescita della domanda dei data center, insieme all’espansione degli altri servizi digitali.

Il dato globale, tuttavia, rischia di nascondere la questione più interessante.

Un data center può rappresentare una quota relativamente piccola della domanda elettrica mondiale e contemporaneamente diventare un problema rilevante per una rete locale.

È proprio questa concentrazione geografica a rendere la questione infrastrutturale. L’IEA osserva che quasi metà della capacità dei data center statunitensi è concentrata in cinque cluster regionali e sottolinea che il sistema elettrico richiede tempi di pianificazione e costruzione molto più lunghi rispetto ai cicli con cui vengono sviluppati nuovi data center.

Questa differenza temporale è fondamentale.

Un modello può essere aggiornato in settimane.

Un data center può essere costruito nell’arco di pochi anni.

Una grande infrastruttura energetica può richiedere tempi ancora più lunghi.

Il rischio nasce quando questi tre orologi vengono fatti funzionare come se avessero la stessa velocità.

Il raffreddamento cambia scala

L’aumento della densità di potenza introduce un altro vincolo.

Gli acceleratori moderni concentrano in un’area fisica molto piccola una quantità di potenza che deve essere continuamente trasformata e dissipata sotto forma di calore. Per questo i data center progettati per carichi AI stanno adottando con maggiore frequenza soluzioni di raffreddamento a liquido e architetture progettate per densità di potenza molto superiori rispetto a quelle tipiche dei server tradizionali.

Il punto non è stabilire un singolo valore universale di watt per GPU o kilowatt per rack, perché questi numeri cambiano rapidamente con la generazione hardware, la configurazione del server e il profilo di utilizzo.

Il punto è un altro: la densità di calcolo sta diventando anche densità termica.

Questo trasforma il raffreddamento da funzione ausiliaria a componente della capacità computazionale.

Un data center non può semplicemente aggiungere acceleratori se non può dissipare il calore prodotto da quegli acceleratori.

E l’acqua?

Anche qui occorre evitare una semplificazione frequente: non esiste un unico consumo idrico dell’AI.

Il consumo dipende dalla tecnologia di raffreddamento, dal clima, dall’efficienza dell’impianto, dal sistema di ricircolo e dal modo in cui viene contabilizzata l’acqua associata all’infrastruttura energetica.

Un indicatore più utile del semplice “litri consumati” è il Water Usage Effectiveness (WUE), che consente di rapportare l’acqua utilizzata all’energia consumata dall’infrastruttura IT.

Un esempio recente mostra quanto possano variare le stime. Google ha dichiarato nel 2025 che, secondo la propria metodologia full-stack, un prompt testuale mediano di Gemini Apps richiede circa 0,24 Wh di energia e 0,26 millilitri di acqua. La stessa azienda precisa che una metodologia limitata al solo consumo degli acceleratori avrebbe prodotto una stima molto più bassa, pari a 0,10 Wh e 0,12 millilitri.

Questa differenza è istruttiva perché dimostra che anche la misurazione dell’impatto dipende dal perimetro scelto.

Il problema non è quindi trovare “il numero dell’acqua consumata da una domanda AI”, come se fosse una costante universale, ma stabilire quale sistema stiamo misurando e quali componenti stiamo includendo nel calcolo.

Quanto costa davvero una risposta?

La stessa cautela serve per l’energia consumata durante l’inferenza.

Epoch AI ha stimato nel 2025 un consumo di circa 0,3 Wh per una query testuale tipica di GPT-4o, precisando però che il valore dipende fortemente dalla lunghezza dell’input, dalla quantità di output, dall’hardware e dall’utilizzazione del sistema. Per input molto lunghi, la stessa analisi stima consumi sensibilmente superiori.

Google ha pubblicato una stima indipendente per Gemini Apps pari a 0,24 Wh per il prompt testuale mediano, utilizzando una metodologia full-stack.

I due valori sono vicini, ma non devono essere trasformati in una presunta costante universale.

Una richiesta breve a un modello efficiente è una cosa.

Un lungo contesto documentale è un’altra.

Un modello di ragionamento che produce numerosi token intermedi è ancora un’altra.

Un agente che esegue decine di chiamate a modelli, strumenti, database e API è un problema diverso.

La domanda “quanto consuma una risposta AI?” è quindi incompleta.

La domanda interessante diventa:

quanto compute serve per ottenere un risultato corretto?

Parametri attivi non significa automaticamente meno watt

Il confronto tra modelli densi e Mixture-of-Experts rende evidente il problema.

DeepSeek-V3 è un modello Mixture-of-Experts con 671 miliardi di parametri complessivi, dei quali circa 37 miliardi vengono attivati per ciascun token. Il technical report descrive proprio questa architettura come uno degli elementi utilizzati per ottenere un’inferenza più efficiente.

Come approssimazione molto semplificata, il numero di operazioni associate ai parametri attivi può essere espresso come:

[math]\displaystyle \text{FLOP/token} \approx 2 \times \text{parametri attivi}[/math]

Con questa approssimazione, un modello denso da 70 miliardi di parametri richiede circa 140 GFLOP per token, mentre un modello con circa 37 miliardi di parametri attivi richiede circa 74 GFLOP per token.

Ma qui arriva la parte interessante.

Questa relazione descrive il lavoro computazionale teorico associato ai parametri attivi; non descrive da sola il consumo energetico reale.

Un modello MoE deve infatti gestire anche la memoria necessaria per i parametri complessivi, la comunicazione tra acceleratori, il routing dei token, la KV cache, il parallelismo e l’utilizzazione effettiva dell’hardware.

Nel caso di DeepSeek-V3, 671 miliardi di parametri rappresentano, come semplice ordine di grandezza, circa 671 GB se ogni parametro fosse memorizzato utilizzando un byte. Si tratta però del solo peso del modello: deployment reale, cache, overhead e configurazione hardware richiedono ulteriore memoria e una configurazione multi-GPU.

Per questo motivo non è corretto trasformare il numero di parametri attivi in una previsione diretta dei watt consumati.

Parametri attivi misurano una parte del lavoro teorico; non sono una misura dell’energia necessaria per ottenere il risultato.

L’esempio numerico: perché il throughput non basta

Supponiamo, soltanto a scopo illustrativo, che una GPU assorba mediamente 700 W durante un certo carico e raggiunga 2.000 token al secondo.

Avremmo:

[math]\displaystyle 700\ W / 2.000\ \text{token/s} = 0{,}35\ J/\text{token}[/math]

che corrisponde a circa:

[math]\displaystyle 0{,}000097\ Wh/\text{token}[/math]

ovvero circa:

[math]\displaystyle 0{,}097\ Wh/1.000\ \text{token}[/math]

Questo numero non deve essere interpretato come una misura universale dell’efficienza di una GPU o di un modello. È un esempio che serve a mostrare il passaggio dimensionale.

Se cambiamo batch size, quantizzazione, lunghezza del contesto, modello, hardware o livello di utilizzo, il risultato cambia.

Ed è proprio qui che il confronto tra modelli diventa interessante.

Un modello può avere meno FLOP per token ma utilizzare l’hardware in modo meno efficiente.

Un altro può avere più FLOP teorici ma un serving estremamente efficiente.

Il dato che interessa davvero a un’azienda non è quindi soltanto il costo energetico del token.

È il costo energetico del compito risolto correttamente.

Energia per risultato corretto

Possiamo formalizzare questa idea con una metrica semplice:

[math]\displaystyle E_{\text{task}} = \frac{ Wh/token \times token/task }{ tasso\ di\ successo }[/math]

La formula cambia il modo di leggere l’efficienza.

Immaginiamo due sistemi.

Il sistema A consuma 0,10 Wh per tentativo e produce una risposta corretta nell’80% dei casi:

[math]\displaystyle E_A = \frac{0{,}10}{0{,}80}=0{,}125\ Wh[/math]

Il sistema B consuma soltanto 0,06 Wh per tentativo, ma raggiunge il risultato corretto nel 40% dei casi:

[math]\displaystyle E_B = \frac{0{,}06}{0{,}40}=0{,}15\ Wh[/math]

Guardando soltanto il consumo per tentativo, B sembra più efficiente.

Guardando il consumo necessario per ottenere un risultato corretto, la relazione cambia.

Questo principio diventa ancora più importante quando entrano in gioco sistemi agentici, perché un singolo compito può richiedere più chiamate al modello, recupero di informazioni, esecuzione di strumenti, verifiche e tentativi successivi.

L’unità di misura interessante non è più necessariamente il token.

Può diventare il risultato affidabile per unità di compute.

Dal compute abbondante al compute razionato

Quando la domanda supera la capacità disponibile, il mercato non deve necessariamente collassare.

Può razionare la risorsa.

Il razionamento può avvenire attraverso il prezzo, le quote di utilizzo, le priorità contrattuali, la disponibilità geografica, i tempi di attesa o la differenziazione tra livelli di servizio.

È quello che possiamo chiamare compute rationing.

Il termine non implica necessariamente una crisi. Significa semplicemente che una risorsa non è più disponibile in quantità illimitata per tutti gli utilizzi.

Per un’azienda questo cambia la domanda da:

“Quale modello è più potente?”

a:

“Quale capacità computazionale devo riservare ai compiti che producono più valore?”

Questa è una domanda economica prima ancora che tecnologica.

Tre possibili traiettorie

Abbondanza apparente

L’efficienza hardware e software cresce abbastanza rapidamente da compensare l’aumento della domanda.

Il costo per unità di risultato continua a diminuire e l’accesso al compute rimane relativamente ampio.

Esiste però un possibile effetto rimbalzo: quando il costo di una tecnologia diminuisce, il suo utilizzo può aumentare abbastanza da assorbire una parte dei guadagni di efficienza.

In questo scenario l’AI diventa più economica, ma non necessariamente meno affamata di infrastruttura.

Razionamento a strati

La capacità computazionale rimane disponibile, ma non in modo uniforme.

I compiti semplici vengono eseguiti da modelli piccoli e relativamente economici, mentre i modelli più costosi e i processi di ragionamento più lunghi vengono riservati ai casi in cui il beneficio economico giustifica il consumo di compute.

Potrebbero emergere differenze significative tra organizzazioni con budget computazionali molto diversi, non soltanto in termini di accesso ai modelli, ma anche nella possibilità di eseguire più tentativi, utilizzare contesti più lunghi o delegare processi complessi a sistemi agentici.

In questo scenario il budget AI non sarebbe soltanto un costo IT.

Diventerebbe una variabile di allocazione delle risorse.

Frammentazione geografica

Il calcolo potrebbe concentrarsi maggiormente nelle aree dove energia, rete e raffreddamento risultano più favorevoli.

La geografia del compute diventerebbe quindi una variabile economica distinta dalla geografia delle persone che utilizzano il servizio.

Per molte applicazioni la latenza non è abbastanza critica da impedire che il calcolo venga eseguito lontano dall’utente finale, mentre per altre applicazioni, soprattutto quelle industriali e real-time, la localizzazione rimane determinante.

Il risultato potrebbe essere una geografia dell’intelligenza artificiale sempre più legata alla geografia dell’energia.

La matrice di fragilità computazionale

Per un’organizzazione che utilizza servizi AI, la questione può essere trasformata in uno strumento di analisi.

La matrice seguente assegna a ogni dimensione un punteggio da 1 a 5, dove 1 indica una bassa esposizione e 5 una forte esposizione. Il peso serve a distinguere i fattori che hanno maggiore rilevanza per il processo analizzato.

Dimensione	Domanda guida	Peso
Concentrazione del fornitore	Quanti fornitori alternativi posso utilizzare senza riprogettare il processo?	3
Esposizione geografica	Da quali regioni e infrastrutture dipende realmente il servizio?	2
Elasticità del budget	Cosa accade se il costo computazionale raddoppia?	3
Sostituibilità	Esiste un modello alternativo più piccolo che copre una parte significativa dei casi?	3
Criticità del compito	Il processo può fermarsi senza conseguenze operative rilevanti?	2
Competenze interne	Esistono competenze per ottimizzare serving, caching, quantizzazione e routing dei modelli?	2

Il punteggio complessivo può essere utilizzato come indicatore interno di esposizione, ma le soglie non devono essere considerate una classificazione universale. Un’organizzazione può calibrare le soglie in funzione della criticità del processo, della volatilità dei costi, della sostituibilità dei fornitori e del livello di rischio che è disposta ad accettare.

La parte importante non è il numero finale preso isolatamente.

È capire dove si trova la fragilità.

Un’azienda potrebbe avere un punteggio elevato perché dipende da un solo fornitore.

Un’altra potrebbe avere lo stesso punteggio perché non dispone di un’alternativa tecnica nel caso in cui il costo dell’inferenza aumenti.

Il numero aggregato nasconde quindi una domanda più utile: quale anello della catena devo rendere sostituibile?

Un caso semplice: 100.000 task al mese

Consideriamo un’organizzazione che esegue 100.000 attività AI al mese.

Supponiamo che il sistema A consumi mediamente 0,20 Wh per tentativo e raggiunga un risultato corretto nel 90% dei casi.

Il consumo energetico atteso per risultato corretto è:

[math]\displaystyle \frac{0{,}20}{0{,}90}=0{,}222\ Wh[/math]

Con 100.000 task:

[math]\displaystyle 100.000 \times 0{,}222 = 22.222\ Wh[/math]

ovvero circa:

[math]\displaystyle 22{,}2\ kWh[/math]

Questo numero, preso da solo, non dice ancora nulla sulla convenienza economica del sistema. Mancano il costo dell’elettricità, il prezzo del servizio, il valore del risultato, i costi infrastrutturali e soprattutto il costo degli errori.

Supponiamo ora che un secondo sistema consumi 0,12 Wh per tentativo ma abbia un tasso di successo del 65%:

[math]\displaystyle \frac{0{,}12}{0{,}65}=0{,}185\ Wh[/math]

In questo caso il secondo sistema richiede meno energia per risultato corretto.

Ma se il compito è altamente critico e ogni errore richiede una revisione umana costosa, la sola metrica energetica non è sufficiente.

Questo è il punto fondamentale: l’efficienza computazionale non può essere separata dall’economia del compito.

Un modello piccolo può essere perfetto per classificare milioni di richieste semplici e completamente inadatto a una decisione complessa.

Un modello grande può essere uno spreco su una classificazione banale e giustificato quando il valore dell’errore evitato è elevato.

L’obiettivo non è quindi utilizzare sempre il modello più piccolo.

È utilizzare la quantità di compute coerente con il valore e il rischio del compito.

Cosa può fare concretamente un’organizzazione

La prima misura consiste nel classificare i task AI non in base al modello utilizzato, ma in base alla loro criticità.

I compiti possono essere separati in attività essenziali, importanti e opzionali, associando a ciascuna categoria un budget computazionale e un livello di servizio.

La seconda consiste nel mantenere almeno un’alternativa tecnica verificata sui casi d’uso reali. Un modello open-weight di riserva è utile soltanto se è stato effettivamente testato sul lavoro dell’organizzazione; avere un modello scaricato su un server non equivale ad avere un piano di continuità operativa.

La terza consiste nel misurare il consumo per risultato corretto, non soltanto il costo per token.

La quarta consiste nell’utilizzare modelli differenti per compiti differenti, evitando di sottoporre ogni richiesta al modello più costoso disponibile.

La quinta consiste nel documentare le dipendenze infrastrutturali: fornitore, regione, modello, hardware, sistema di serving, costi, tempi di sostituzione e alternative disponibili.

La sesta consiste nel monitorare il collo di bottiglia prima che diventi emergenza.

Se oggi il problema è il costo dell’inferenza, la domanda successiva dovrebbe essere quale componente potrebbe diventare il limite quando la domanda raddoppierà.

Se oggi il problema è la disponibilità delle GPU, domani potrebbe essere la rete elettrica.

Se oggi è l’energia, il limite successivo potrebbe essere la capacità di raffreddamento.

La gestione del compute diventa così una forma di gestione della supply chain.

Il vero limite potrebbe non essere il modello

La discussione sull’intelligenza artificiale tende ancora a concentrarsi soprattutto sulle capacità dei modelli: quanti parametri hanno, quali benchmark superano, quanto sono bravi nel ragionamento, quanto sono lunghi i loro contesti.

Sono metriche importanti, ma raccontano soltanto una parte della storia.

Un modello non esiste nel vuoto.

Esiste dentro una catena industriale che parte dalla produzione dei semiconduttori, passa attraverso memoria e packaging, arriva ai server, attraversa una rete elettrica, produce calore, richiede sistemi di raffreddamento e viene infine trasformata in un servizio che qualcuno deve pagare.

L’IEA prevede che il consumo elettrico dei data center più che raddoppi entro il 2030, arrivando a circa 945 TWh nello scenario di base. La stessa analisi sottolinea però l’incertezza delle proiezioni e il ruolo decisivo che avranno sia l’efficienza tecnologica sia i possibili colli di bottiglia del sistema energetico.

Questo significa che non esiste una sola traiettoria inevitabile.

L’efficienza dei modelli può migliorare.

L’hardware può diventare più efficiente.

Il software di serving può utilizzare meglio gli acceleratori.

La domanda può crescere più lentamente o più rapidamente delle attese.

La produzione elettrica può aumentare.

Le infrastrutture possono essere costruite in nuove aree.

Ma ogni scenario deve comunque passare dalla stessa porta: la disponibilità fisica delle risorse necessarie a trasformare energia e materia in calcolo.

La domanda strategica per le aziende, quindi, non è soltanto quanto diventeranno capaci i modelli.

È quanta capacità computazionale sarà disponibile, dove sarà disponibile, quanto costerà e quale risultato sarà possibile ottenere con quella capacità.

Perché il prossimo vantaggio competitivo dell’AI potrebbe non appartenere a chi possiede il modello più grande.

Potrebbe appartenere a chi sa ottenere un risultato affidabile quando il compute non è più una risorsa infinita.

---

Fonti:

IEA – Energy and AI: fonte principale per domanda elettrica, data center, AI, concentrazione geografica e tempi infrastrutturali.

ASML – Annual Report / EUV: per la posizione di ASML nella litografia EUV.

SK hynix: per la crescita della domanda HBM legata all’AI.