L’efficienza energetica degli agenti AI diventa un problema da architettura software

I flussi agentici consumano troppa energia. Non è un’opinione: è il punto di partenza di una ricerca sviluppata al MIT in collaborazione con Microsoft Azure, presentata a USENIX OSDI 2026. Il problema non è il modello AI in sé, ma il modo in cui i workflow agentici vengono progettati, dispiegati ed eseguiti: senza ottimizzazione sistematica dell’allocazione delle risorse, l’energia sprecata è strutturale, non accidentale.

Gohar Chaudhry, dottorando MIT EECS e primo autore del paper, è diretto nella diagnosi: “I flussi agentici stanno diventando la spina dorsale di ciò che fanno i provider cloud. L’uso di energia è una preoccupazione enorme, dobbiamo essere molto attenti all’efficienza. È molto facile sovra-allocare risorse, sprecando energia e denaro.” La risposta che il team propone si chiama Murakkab — un sistema di orchestrazione che ottimizza automaticamente la progettazione e il dispiegamento di flussi agentici in ambiente cloud.

Il problema: flussi agentici che sprecano risorse per design

Un flusso agentico tipico in produzione è composto da più componenti: un modello linguistico principale, tool specializzati (ricerca, esecuzione di codice, chiamate API), memoria di contesto, layer di orchestrazione. Ogni componente richiede risorse computazionali — CPU, GPU, memoria — che vengono allocate all’avvio del workflow e rimangono assegnate per tutta la sua durata.

Il problema è la granularità dell’allocazione. Chi progetta un flusso agentico deve scegliere quale modello usare per ogni task, quanta GPU allocare, come bilanciare velocità e costo. Queste decisioni vengono prese una volta, in fase di progettazione, e restano fisse anche quando le condizioni cambiano. Se un modello piccolo potrebbe gestire un certo task ma il sistema ha allocato un modello grande per sicurezza, l’energia in eccesso viene sprecata senza che nessuno lo sappia.

Moltiplicato su milioni di chiamate giornaliere, questo spreco è enorme. Il consumo energetico dei datacenter AI ha già raggiunto livelli che mettono sotto pressione le reti elettriche — e i flussi agentici sono tra le componenti a crescita più rapida. L’attuale stato dell’arte richiede che ogni scelta venga cablata manualmente da un ingegnere esperto: non esiste un meccanismo che ottimizzi l’allocazione in funzione del task specifico e delle condizioni di runtime.

Murakkab: descrivi cosa vuoi, il sistema ottimizza da solo

La proposta del paper accademico è un cambio di approccio radicale rispetto alla configurazione manuale. Invece di richiedere al developer di specificare ogni componente del flusso agentico, Murakkab riceve una descrizione in linguaggio naturale del compito desiderato e autonomamente seleziona modelli, strumenti e configurazione hardware ottimale.

Il sistema lavora su due livelli distinti. Il primo è la fase di progettazione: dati i requisiti espressi in linguaggio naturale e le preferenze di ottimizzazione (massimizza velocità, minimizza costo, minimizza energia), Murakkab costruisce il flusso selezionando i componenti più adatti. Il developer descrive cosa vuole ottenere, il sistema decide come ottenerlo nel modo più efficiente.

Il secondo livello è il runtime: Murakkab adatta le allocazioni in tempo reale in base al carico effettivo e alla complessità del task specifico. Se un’attività si rivela più semplice del previsto, il sistema riduce le risorse allocate. Se un passaggio richiede più potenza, la aumenta. Questa elasticità elimina lo spreco strutturale che deriva da configurazioni statiche dimensionate per il caso peggiore.

La novità tecnica più rilevante riguarda la visibilità che Murakkab offre al provider cloud: il sistema condivide le risorse tra più carichi di lavoro simultanei, eliminando i silos di allocazione che oggi impediscono la condivisione. Un server che esegue dieci flussi agentici separati può, con Murakkab, gestire la stessa quantità di lavoro con molte meno risorse — perché i picchi di consumo di un flusso raramente coincidono con i picchi degli altri.

I numeri: -73% energia, -75% costi, accuratezza quasi intatta

I risultati sperimentali riportati da MIT News sono netti. Murakkab richiede solo il 35% della computazione necessaria con i metodi alternativi, il 27% dell’energia e meno del 25% del costo. In uno dei test più significativi, il consumo energetico si è ridotto di oltre un ordine di grandezza — con un calo di accuratezza di appena il 2%.

Quest’ultimo dato merita attenzione. Un calo del 2% di accuratezza è spesso irrilevante nelle applicazioni enterprise reali, dove completezza e velocità hanno priorità sull’ottimizzazione fine. Un agente che risponde correttamente al 98% delle richieste con un quarto dei costi energetici è una proposta economicamente molto più interessante di un agente con il 100% di accuratezza che brucia quattro volte l’energia.

La soglia del 2% non è universale: per certi use case — diagnosi medica, supporto legale ad alto rischio, analisi finanziaria con impatto regolatorio — la tolleranza per l’errore è molto più bassa. Ma per la grande maggioranza delle applicazioni enterprise — automazione di processi, assistenza clienti, analisi di documenti, reportistica — il trade-off è più che accettabile. Il rapporto tra risparmio energetico e degradazione della qualità non ha precedenti nella letteratura sull’ottimizzazione dei sistemi AI.

Il punto di svolta: quando il provider vede dentro i flussi

L’elemento più dirompente di Murakkab non è tecnico ma architetturale. Oggi un cloud provider come Azure, AWS o GCP gestisce le risorse a livello di istanza: sa quante CPU e GPU sta consumando un cliente, ma non ha visibilità su cosa sta facendo internamente quel workload. Murakkab cambia questo: per ottimizzare l’allocazione, l’orchestratore deve conoscere la struttura interna del flusso agentico.

Questo introduce una nuova dinamica tra chi usa il cloud e chi lo eroga. Se l’orchestratore agisce a livello di provider — come Murakkab è pensato per fare — il provider acquisisce informazioni sulle applicazioni che oggi non ha. Non è un problema tecnico risolvibile con la crittografia: è una questione di governance e trasparenza che le aziende dovranno affrontare esplicitamente quando questo tipo di tecnologia arriverà in produzione.

L’architettura Murakkab è un passo avanti rispetto alle AI Factory come sono concepite oggi: non solo acceleratori hardware ottimizzati per l’AI, ma infrastrutture software che ottimizzano dinamicamente l’allocazione in base ai flussi specifici. Il provider non si limita a fornire potenza computazionale raw: gestisce attivamente l’efficienza delle applicazioni che vi girano sopra.

Cosa significa per le aziende che usano agenti AI

Murakkab è ancora ricerca accademica, non un prodotto disponibile. I tempi di adozione dipendono dall’integrazione nei servizi cloud dei grandi provider — Azure, co-firmatario del paper, è il candidato naturale per la prima implementazione commerciale. Ma le implicazioni pratiche meritano di essere anticipate.

Il primo segnale da cogliere è che il problema dell’efficienza energetica nei flussi agentici è già reale oggi. Le aziende stanno razionando i token perché i costi esplodono — ma il razionamento del consumo di token è solo la superficie del problema. Sotto c’è un livello più profondo: il modo in cui i flussi agentici vengono orchestrati determina quante risorse vengono consumate indipendentemente dal numero di token prodotti. Un flusso mal orchestrato spreca GPU, CPU e memoria anche quando produce pochi token.

La ricerca sulle reti neurali asincrone a basso consumo ha già mostrato che è possibile ridurre il consumo energetico dell’AI di ordini di grandezza con scelte architetturali diverse. Murakkab aggiunge un livello: non basta un modello efficiente, serve un’orchestrazione efficiente. Il risparmio energetico non è solo una questione di chip — è una questione di software.

Per le aziende che stanno costruendo agenti AI in produzione, questo si traduce in tre indicazioni concrete. Prima: monitorare il consumo energetico e di risorse dei flussi agentici con la stessa attenzione dedicata al consumo di token. Seconda: preferire orchestratori che ottimizzano l’allocazione dinamicamente rispetto a configurazioni statiche. Terza: scegliere provider cloud che offrano visibilità e ottimizzazione a livello di workflow, perché il costo totale di ownership di un agente dipende dall’efficienza dell’infrastruttura su cui gira, non solo dal prezzo del modello.

Il prossimo buco nero dei costi AI non sarà la bolletta dei token: sarà l’over-provisioning dei flussi agentici. Murakkab lo dimostra — e lo risolve, almeno in laboratorio.