La notizia non è solo che Microsoft ha deciso di aprire il codice e i checkpoint del suo modello meteorologico più avanzato. È che lo ha fatto mentre spinge, in parallelo, per un modello operativo cloud-first, lasciando agli altri attori — dai centri di ricerca alle utility energetiche — un bivio strategico: valutare Aurora 1.5 in locale, con tutti i costi e la complessità dell’inference su GPU, oppure affidarsi ai servizi gestiti di Azure.

Aurora 1.5 non è un singolo Large Language Model, ma un sistema di fondazione pensato per l’intero Earth system. Rispetto alla prima Aurora — pubblicata su Nature nel 2025 dopo il debutto nel 2024 — questa versione aggiunge 22 variabili meteorologiche (portando il totale a 26), spaziando da radiazione solare e copertura nuvolosa fino a campi di precipitazione e umidità. La risoluzione temporale scende a un’ora, e soprattutto arriva una delle funzionalità più richieste dalla comunità: il forecasting probabilistico d’insieme, che non si limita a una singola previsione deterministica ma genera molteplici scenari per quantificare l’incertezza.

Sul piano delle prestazioni, i numeri diffusi da Microsoft Research sono notevoli. Il nuovo approccio ensemble supera il modello dinamico di riferimento ECMWF nell’88,9% dei target valutati, e riduce di circa un terzo l’errore di tracciamento dei cicloni tropicali — un dato concretizzato con l’uragano Helene. Tutto bene, fin qui. Il punto è un altro: chi può davvero replicare questi risultati senza passare dal cloud di Microsoft?

La trappola del “tutto aperto”

L’apertura del codice su GitHub e dei checkpoint su Hugging Face è reale, e non va sminuita. Ma l’operazione Aurora 1.5 dimostra come l’open source nel mondo dei foundation model stia diventando un’arma a doppio taglio. Da un lato, aziende come BKW – utility energetica svizzera – stanno già usando il modello a fianco dei servizi operativi Microsoft Weather per gestire la generazione rinnovabile, intrinsecamente dipendente dalle condizioni atmosferiche. Qui l’inference ensemble è un abilitatore: permette di stimare la distribuzione di probabilità della produzione eolica o solare, anziché un singolo valore puntuale, riducendo il rischio nelle decisioni di dispacciamento.

Dall’altro lato, però, l’inference ensemble moltiplica il carico computazionale. Ogni membro dell’ensemble è una simulazione aggiuntiva, e Aurora 1.5 impiega perturbazioni stocastiche nel percorso di condizionamento latente, oltre a un fine-tuning auto-regressivo su dati ECMWF ad alta risoluzione. Tutto questo richiede GPU con una quantità di VRAM non trascurabile e una pipeline di serving ottimizzata. Microsoft, non a caso, offre l’integrazione nativa con Azure AI Foundry e Planetary Computer Pro, costruendo di fatto un percorso agevole che dalla ricerca aperta conduce dritto al consumo di credito cloud.

Chi ci perde e chi ci guadagna

Per i centri meteorologici nazionali, abituati a gestire modelli fisici su supercomputer dedicati, l’arrivo di un foundation model aperto potrebbe essere un’opportunità per ridurre i costi operativi, ma anche una minaccia alla loro posizione di gatekeeper dell’informazione meteorologica. Se un’utility o un trader agricolo possono girare Aurora 1.5 sul proprio hardware, magari arricchito con dati locali tramite fine-tuning, il valore aggiunto dell’agenzia statale si sposta altrove — forse verso la validazione e la certificazione dei risultati, più che sulla produzione della previsione.

C’è poi il nodo della sovranità dei dati. Settori come l’agricoltura, i trasporti e la pianificazione di emergenza trattano informazioni che molti governi considerano strategiche. Affidare l’inference a un’API cloud estera — anche se operata da un hyperscaler — può incontrare resistenze normative (si pensi al GDPR per dati geospaziali o a regolamenti nazionali sulla resilienza). In questo scenario, il self-hosting di Aurora 1.5 diventa un requisito, non un’opzione. Ma allora serve una capacità di calcolo locale adeguata, e l’assenza di benchmark hardware pubblici rende il dimensionamento un salto nel buio.

Non solo meteo: il segnale per il deployment on-premise

L’utilizzo di Aurora da parte di Terradot per stimare la rimozione di CO₂ tramite enhanced rock weathering, o le esplorazioni del Met Office britannico per modelli climatici data-driven, segnalano che i foundation model per l’Earth system stanno allargando il perimetro ben oltre il nowcasting. Ogni nuovo caso d’uso porta con sé una domanda implicita: l’inference può rimanere vincolata al cloud, o è necessaria un’esecuzione locale per motivi di latenza, confidenzialità o costo totale di possesso?

La risposta non è binaria, e Microsoft stessa lo sa. L’azienda ha costruito un ecosistema a più livelli: open source puro per la ricerca e la validazione indipendente, servizi gestiti per l’uso operativo snello, e uno strato di integrazione con gli Agent skills di Azure che semplifica l’adattamento a nuovi domini. Per chi valuta scenari di deployment on-premise, la partita si gioca sul TCO: acquistare e mantenere un cluster GPU dedicato ha un costo capitale che solo volumi di inference molto elevati giustificano, ma se i dati non possono lasciare il perimetro aziendale, la bilancia pende verso il self-hosted. Aurora 1.5 non risolve questo trade-off, lo porta alla luce del sole.