Quando la rete elettrica è sotto pressione, un job di embedding può aspettare. Un checkout WordPress, una chat di assistenza o un’automazione che aggiorna il magazzino no. La scelta tra carichi AI flessibili e capacità sempre accesa si decide qui: non sull’energia consumata in assoluto, ma su quali elaborazioni possono essere spostate senza rompere il servizio.
Il criterio: quanto ritardo può tollerare il lavoro
Il 16 settembre 2026 Emerald AI, Google e NVIDIA hanno annunciato la AI Energy Management Alliance, a cui partecipa anche Anthropic. L’obiettivo è trattare i data center come carichi regolabili: quando la rete entra in una fase critica, il software riduce o sposta le elaborazioni non urgenti, usa eventuali batterie e protegge i workload prioritari.
Non è un confronto tra data center “acceso” e “spento”. Entrambe le opzioni restano operative. Cambia il contratto con il tempo: l’approccio flessibile accetta una finestra di completamento per alcuni job; quello sempre acceso riserva capacità e alimentazione per rispondere subito. Il criterio corretto è quindi la latenza massima accettabile per ogni coda di lavoro.
Approccio A: rendere flessibili i carichi AI
La flessibilità funziona bene con addestramento, fine-tuning, generazione massiva di immagini, indicizzazione vettoriale, trascrizioni batch e analisi pianificate. Sono attività importanti, ma spesso non devono terminare nello stesso secondo in cui vengono richieste. Un orchestratore può rallentarle, metterle in pausa o spostarle in un’altra regione quando arriva un segnale dalla rete.
Il vantaggio concreto è usare meglio capacità che esiste già. In una dimostrazione su un cluster commerciale da 256 GPU, Emerald AI e i partner hanno ridotto del 25% la potenza del cluster per tre ore durante eventi di picco, mantenendo i livelli di servizio dichiarati per i workload AI. È un risultato di campo, non la prova che ogni applicazione possa cedere un quarto della potenza: dipende dal mix dei job e dai vincoli impostati.
I pro sono chiari: meno dipendenza dai picchi, possibilità di negoziare capacità flessibile e migliore utilizzo dell’infrastruttura. I contro sono software più complesso, code da governare, telemetria affidabile e il rischio di accumulare ritardo. Se un job viene rinviato senza una scadenza, il risparmio energetico diventa debito operativo.
Approccio B: capacità garantita e sempre disponibile
La capacità fissa resta la scelta giusta per inferenza interattiva, pagamenti, login, ricerca interna, assistenza in tempo reale e automazioni collegate a un processo operativo. Qui la prevedibilità vale più della flessibilità. Il sistema deve rispondere anche quando la rete o il cloud sono sotto pressione, usando capacità riservata, ridondanza e piani di continuità.
Il beneficio è una latenza più stabile e un’architettura più semplice da spiegare al cliente. Il costo è pagare margine inutilizzato e dimensionare il sistema sui picchi. È lo stesso errore che si vede nei progetti AI venduti “a token” senza distinguere il valore del task: se tutto riceve la priorità massima, si finisce per comprare capacità premium anche per lavori che potevano aspettare. Il tema è già visibile nel costo di memoria, server ed energia dell’AI.
Costo, messa in opera e punto di rottura
| Criterio | Carichi flessibili | Capacità sempre accesa |
|---|---|---|
| Costo | Può ridurre il premio pagato per i picchi, ma richiede orchestrazione e osservabilità. | Paga capacità e ridondanza anche quando restano inutilizzate. |
| Messa in opera | Richiede code, priorità, deadline, retry e test di sospensione. | È più lineare, purché il dimensionamento e il failover siano corretti. |
| Cosa si rompe crescendo | Le code si allungano e i job differiti possono superare la scadenza. | Il costo sale e la capacità riservata può diventare un collo di bottiglia. |
Google offre un’indicazione utile sui confini. Nei suoi programmi di demand response sposta elaborazioni non urgenti e ha esteso i test ai workload di machine learning, ma riconosce che servizi come Search, Maps e i sistemi cloud per settori essenziali hanno margini inferiori. La flessibilità della domanda è uno strumento del portafoglio, non il sostituto di nuova generazione, trasmissione e capacità affidabile.
Cosa cambia per PMI, WordPress e automazioni
Una PMI non compra una rete elettrica, ma compra servizi cloud che incorporano queste scelte. Conviene quindi classificare i workload prima di scegliere istanze, regioni o fornitori. Il frontend WordPress, WooCommerce, i webhook che confermano un ordine e il recupero password appartengono alla corsia garantita. La rigenerazione delle thumbnail, l’audit notturno, gli embedding del catalogo e la trascrizione di un archivio possono stare in una coda flessibile.
La stessa logica vale quando si decide tra GPU locale e API cloud. Non serve spostare tutto. Serve separare il percorso sincrono dal batch, assegnare una deadline, registrare il tempo passato in coda e prevedere un fallback. Per le automazioni significa usare identificatori idempotenti, retry con limite e una dead-letter queue: una pausa energetica non deve generare doppie pubblicazioni o ordini duplicati.
La mia scelta: architettura ibrida, ma con priorità esplicite
Per una PMI sceglierei capacità garantita per il percorso che produce ricavi o serve una persona in tempo reale. Renderei flessibili tutti i job batch misurabili, iniziando da quelli che possono slittare di un’ora senza conseguenze. È meno elegante di una risposta unica, ma è più solido.
La take finale è netta: non pagare l’alimentazione “sempre accesa” per ogni token e non rendere flessibile ciò che ha un SLA reale. Se il team non sa indicare deadline, priorità e fallback di un job, non è ancora pronto a consegnarne il controllo alla rete.