Lo scorso dicembre AWS aveva annunciato Graviton5; ora le prime istanze M9g e M9gd sono finalmente disponibili in versione generale su EC2. I primi dati parlano di un miglioramento medio del 30% in termini di prestazioni geometriche rispetto a Graviton4. Un balzo costruito su fondamenta precise: core Arm Neoverse-V3 (contro i V2 della generazione precedente), fino a 192 core fisici e una frequenza di clock portata a 3,3 GHz dai 2,8 GHz del modello che l’ha preceduto.

Ma leggere questi numeri come un semplice refresh di prodotto sarebbe miope. Graviton5 non è un aggiornamento incrementale: è il segnale di una trasformazione strutturale nel modo in cui il cloud si costruisce il vantaggio hardware. E per chiunque abbia responsabilità di architettura dati – soprattutto quando si parla di deployment on-premise o ibridi – questa verticalizzazione impone una riflessione più scomoda del solito.

Il cuore della questione sta nella strategia di integrazione verticale. AWS non compra da un fornitore terzo, non si limita a personalizzare un progetto reference. Sviluppa internamente il silicio, dalla microarchitettura alla messa in produzione, e lo ottimizza per il proprio stack software. Il risultato è un chip che sul piano prestazionale rivaleggia con le alternative x86, ma che esiste solo dentro l’ecosistema AWS. Non è un prodotto che si può acquistare, installare in un rack aziendale e gestire con i propri strumenti. È una risorsa che si affitta, e che produce vantaggi solo all’interno di quel recinto.

Questa dinamica ha implicazioni di secondo ordine per chi oggi valuta strategie di lungo termine. Il guadagno del 30% generazione su generazione, a parità di consumi, non è solo una bella notizia per il bilancio tecnico di chi already usa EC2. È un incentivo potente a consolidare i carichi di lavoro proprio su quella piattaforma, perché difficilmente altrove – e men che meno on-premise – si troverà un rapporto prezzo-prestazioni equivalente nel breve periodo. La conseguenza è un effetto calamita: più valore viene estratto dal binomio hardware-software proprietario, più diventa costoso, tecnicamente e finanziariamente, spostare altrove i workload.

Chi lavora su architetture che richiedono sovranità dei dati, conformità normativa stringente o semplicemente il controllo fisico dell’infrastruttura, si trova così di fronte a un bivio. Da un lato, la promessa di efficienza operativa e di riduzione del TCO immediato offerta da chip come Graviton5. Dall’altro, il rischio concreto di dipendenza da un singolo provider, con tutti i vincoli di portabilità che ne derivano. Non è un caso che progetti come le CPU Ampere o iniziative open-source come OpenBMC per la gestione dei server stiano guadagnando attenzione: rappresentano il tentativo di costruire un’alternativa aperta e replicabile, ma senza il medesimo livello di integrazione verticale i benchmark parlano chiaro, il gap rimane.

C’è poi un terzo livello di lettura, che tocca direttamente il mondo del deployment per carichi di intelligenza artificiale. Graviton5 non è un acceleratore per il training o per l’inference di Large Language Model – ruolo che in casa AWS spetta a Trainium e Inferentia – ma resta la spina dorsale computazionale di pipeline di preprocessing, orchestrazione e serving su cui si appoggia l’intero stack AI. La crescente potenza di calcolo general-purpose disponibile esclusivamente in cloud ridefinisce i confini del “sufficiente” per chi valuta soluzioni self-hosted: se il costo per unità di calcolo sul cloud scende più rapidamente di quanto possa fare un data center privato con hardware commodity, le convenienze economiche classiche tra CapEx e OpEx si sbilanciano. E questo prima ancora di considerare la manutenzione, il raffreddamento e la gestione del ciclo di vita dell’hardware.

Certo, resta una domanda aperta: quanto di questo progresso resterà proprietà esclusiva del cloud e quanto invece filtrerà nell’ecosistema on-premise attraverso licenze di proprietà intellettuale, design aperti o semplicemente come pressione competitiva sui produttori di CPU tradizionali. Per ora, la risposta è nella direzione che AWS ha imboccato da anni: meno componenti standard, più integrazione verticale. E mentre le istanze M9g cominciano a macinare cicli di calcolo, chi progetta infrastrutture che non si arrendono al cloud pubblico ha una sola certezza: la strada per l’indipendenza architetturale non passa per un semplice refresh di server, ma per una progettazione che consideri la portabilità come un requisito di primo livello, non un compromesso.