Come cambia l'infrastruttura per l'AI: acquisti, porting, ottimizzazioni e narrazione

OpenAI cerca sviluppatori con esperienza su TPU. È un segnale operativo: l’azienda valuta gli acceleratori di Google Cloud per i futuri datacenter Stargate¹. La corsa alla capacità sta spingendo aziende e governi a ridisegnare insieme hardware, stack software e linguaggio pubblico dell’infrastruttura.

Diversificare la capacità: TPU, GPU e accordi industriali

Pochi giorni dopo una fuga di notizie, OpenAI ha pubblicato offerte di lavoro legate alle TPU. OCI ha annunciato l’intenzione di comprare TPU da Google Cloud per i propri datacenter nel 2027. OCI è partner di OpenAI nel progetto Stargate negli Stati Uniti, con edifici dedicati e cofinanziati. Le due mosse potrebbero riferirsi allo stesso piano di approvvigionamento e a una infrastruttura condivisa¹.

Secondo l’analista Matt Kimball, Moor Insights & Strategy, Nvidia vende le GPU più richieste a circa 40.000 dollari l’unità e con disponibilità limitata. Diversificare i fornitori aumenta il potere negoziale e consente di sommare ore macchina per addestramento e servizi¹. OpenAI aveva già affiancato alle GPU Nvidia acceleratori progettati internamente e fabbricati da Broadcom. Le TPU di Google Cloud estenderebbero questa linea di acquisti¹.

La politica spinge nella stessa direzione. Al Digitalgipfel del 2 novembre 2026, a Berlino, Friedrich Merz ha annunciato un piano per quadruplicare la capacità di calcolo per l’IA entro il 2030 e ha chiesto di ridurre “drasticamente” la dipendenza da singoli fornitori. Ha legato la strategia a collaborazioni con Canada, Singapore, Giappone e Corea del Sud³.

La diversificazione non è un semplice ordine d’acquisto. Impone scelte che pesano sullo stack software e sul modo in cui si costruiscono e si operano i sistemi.

Il conto tecnico del porting fra ecosistemi divergenti

OpenAI sviluppa su PyTorch, usa CUDA di Nvidia e il server di inferenza Triton. L’ecosistema TPU di Google Cloud si fonda su JAX e su OpenXLA. Spostare carichi su TPU significa portare codice, adattare librerie e ritarare pipeline. È un costo di ingegneria oltre al prezzo a listino¹.

La capacità aggiuntiva dà respiro in fase di addestramento e in produzione, ma ogni nuovo acceleratore introduce un secondo percorso di compilazione, test e osservabilità. La promessa è sommare ore macchina a un prezzo efficace. Il rischio è aprire un cantiere software che ritarda il beneficio netto.

La scelta di OpenAI dialoga con il messaggio di Merz. La riduzione della dipendenza da singoli fornitori richiede investimenti coordinati su toolchain, standard e formazione. Per chi lavora su sistemi di AI il compito è stimare il tempo uomo per il porting e confrontarlo con il guadagno in throughput addestrativo. Se il collo di bottiglia è la disponibilità di GPU da 40.000 dollari, il porting su TPU può convenire. Se il collo di bottiglia è altrove, no^1,3.

Ottimizzare la piattaforma operativa: Pando e i colli di bottiglia interni

Non tutta la capacità arriva dall’hardware. OpenAI ha messo in produzione ad aprile Pando, un backend Git interno. Secondo l’azienda ha ridotto la latenza delle push di quasi cinque volte e oggi serve quasi un petabyte di dati al giorno. Entro fine anno i commit trimestrali nel monorepo cresceranno di oltre il 2.400% rispetto al primo trimestre 2024².

Il team ha scelto di restare su Git. Ha osservato che l’affidabilità del vecchio backend era scesa sotto il 90%, con fetch lenti e merge falliti. La diagnosi ha spostato il focus dal client all’architettura del server². Pando elimina due vincoli comuni: non impone coerenza simultanea tra tutti i branch e non costruisce un packfile personalizzato per ogni fetch. Gestisce ogni branch in modo indipendente. Così le push su rami non correlati non si intralciano. Il prezzo è una possibile vista sfalsata tra branch quando li si osserva insieme, ma agli sviluppatori interessa l’ordine interno al singolo ramo².

Durante una push, Pando valida il packfile mentre lo scrive in blob storage, senza scompattarlo in un repository locale. Registra il nuovo tip, la posizione del pack e le dipendenze in un metastore². È un esempio di come si libera capacità: si sposta il collo di bottiglia dal coordinamento fine-grained al disaccoppiamento, si riducono contese, si aumenta il throughput senza comprare nuovi acceleratori.

Per chi guida piattaforme AI la priorità è cercare i colli di bottiglia nella toolchain prima di aggiungere hardware. La velocità di sviluppo e la freschezza del codice che entra in addestramento dipendono anche da come si serve il monorepo. Una pipeline più veloce accorcia i cicli di prova e riduce il costo opportunità di ogni esperimento².

Politica e percezione: potere, regolazione e linguaggio dei data center

La capacità è anche politica e consenso. Sempre a Berlino, Merz ha affiancato al piano per i frontier model una strategia di lungo periodo su “Weltmodelle” e “IA fisica”, dentro la Hightech-Agenda Deutschland. Ha rivendicato ricadute già visibili in elettronica e macchinari, citando i portafogli ordini. Karsten Wildberger ha frenato gli entusiasmi. “Siamo ancora troppo lenti”, ha detto. Ha chiesto decisioni rapide su energia, infrastrutture e investimenti, con tempi certi e responsabilità definite³.

Sul fronte privato, OpenAI prepara una campagna pubblica dopo le midterm. Valuta di chiamare i propri data center “AI compute campuses”. Chris Lehane, chief global affairs officer, ha descritto la tabella di marcia. Ha parlato di “speed limits” per l’AI, di autonomia nella vita quotidiana, di standard globali. E di riposizionare i data center con un nuovo nome⁴. “I data center sono profondamente impopolari”, nota l’articolo originale. La domanda è se il linguaggio possa spostare la percezione pubblica, mentre la discussione sui progetti locali si fa più accesa⁴.

Questi piani incidono su permessi, tempi e costi. Se le comunità chiedono responsabilità e rendicontazione, come sostiene Lehane, le aziende devono presentare metriche e benefici concreti. Secondo lui, solo così le comunità possono ottenere “un beneficio trasformativo” da questi investimenti⁴. Sul lato pubblico, l’obiettivo di quadruplicare la capacità entro il 2030 richiede scelte coordinate su energia. Servono decisioni con scadenze, come ha chiesto Wildberger³.

Per chi progetta infrastrutture, il piano di approvvigionamento deve considerare il rischio politico. Diversificare hardware, investire nel porting, ottimizzare la toolchain e curare la relazione con le comunità locali restano leve dello stesso problema: accesso certo e tempestivo a ore macchina.

Il nodo è l’intersezione di queste leve con i vincoli di energia e con la discussione pubblica sui progetti locali^1,3,4.