Colmare il divario tra calcolo ad alte prestazioni (HPC) e intelligenza artificiale sovrana: parte due di tre
Se non hai ancora letto la prima parte sui fondamenti del calcolo ad alte prestazioni (HPC), leggila subito!
Principi chiave di un data lakehouse autonomo
The open data lakehouse: un semplice PaaS per ingegneri
Sebbene il tradizionale software di simulazione ingegneristica eccelli nell'aiutare gli ingegneri meccanici a preparare, eseguire e analizzare i lavori di simulazione, manca di un design nativo per gestire i flussi di lavoro e i pipeline dati moderni di machine learning (ML). Un open data lakehouse può colmare questo divario, offrendo agli ingegneri di R&D funzionalità solide e contemporanee su una piattaforma con cui il reparto IT probabilmente ha già familiarità.
I principali casi d'uso e i benefici di un data lakehouse aperto includono:
Archiviazione dei dati governata e conveniente: offre uno spazio di archiviazione virtualmente illimitato e a basso costo per archiviare anni di istantanee di simulazione (i set di dati generati dalle sessioni del solver). Questo spazio di archiviazione è gestito e governato in modo coerente in tutte le organizzazioni e i team di ingegneria e IT. In modo fondamentale, i metadati essenziali e il lineage per ogni dataset vengono preservati, trasformandolo da un file opaco in un asset affidabile che può essere facilmente riutilizzato oltre il creatore originale.
Accesso semplificato alle risorse di calcolo: Gli ingegneri possono facilmente e rapidamente distribuire notebook condivisi e cluster Apache Spark o Python Ray. Spesso condividono le stesse risorse GPU dedicate utilizzate dal cluster HPC principale.
Protezione tramite standard aperti: un data lakehouse aperto dà priorità agli standard aperti come Apache Iceberg, Parquet e Python rispetto ai formati di ingegneria proprietari. Questo è fondamentale per salvaguardare la Proprietà Intellettuale (IP) di un'azienda, garantendo che i dati di simulazione rimangano accessibili e utilizzabili da qualsiasi strumento, ora e in futuro, indipendentemente dall'infrastruttura IT in evoluzione dell'azienda o dalla strategia dei fornitori.
Un'esperienza PaaS simile al cloud: o data lakehouse strutturati come stack platform-as-a-service (PaaS) self-service e user-friendly semplificano l'uso di complessi strumenti di ingegneria dei dati e MLOps, colmando efficacemente il divario di conoscenze tra utenti con diversi background tecnici e favorendo uno scambio produttivo di competenze.
Il rischio del cloud pubblico per la protezione della proprietà intellettuale di R&S
Sebbene una data lakehouse offra molti vantaggi, non è, di per sé, una soluzione completa per settori altamente regolamentati (come aerospaziale, difesa, energia e automotive) dove la sovranità è un requisito non negoziabile. In parole povere: non tutti i data lakehouse possono essere implementati e gestiti in conformità con i mandati di sovranità dei dati e affidarsi al cloud pubblico comporta un rischio significativo per il mantenimento del controllo più rigoroso sulla proprietà intellettuale.
Ad esempio, una singola istantanea di un lavoro di fluidodinamica computazionale (CFD) (come un nuovo progetto di motore) rappresenta di fatto il progetto completo delle sue prestazioni e del design industriale; questo dataset è il gioiello della corona di un'azienda. È quindi fondamentale determinare quali capacità chiave non funzionali di un data lakehouse possano fornire l'assoluta garanzia legale di sovranità operativa necessaria per archiviare tali asset strategici. Questo conduce direttamente al nocciolo del dibattito tra residenza e sovranità.
Residenza dei dati e sovranità
La definizione tradizionale di sovranità come operare nel paese d'origine di un'impresa è una nozione superata, un residuo dell'era pre-cloud. In precedenza, l'infrastruttura dei data center era tipicamente gestita da personale locale, intrinsecamente soggetta alla giurisdizione locale e agli obblighi legali dell'azienda. Tuttavia, la diffusione delle offerte di cloud commerciali e la necessità per i fornitori di garantire livelli di servizio estremamente elevati 24 ore su 24, 7 giorni su 7, hanno reso pienamente possibili le operazioni cloud globali remote, in modalità "follow-the-sun". Questo progresso rende impossibile garantire, almeno nelle regioni con standard commerciali, la residenza del team di gestione, recidendo così il legame tra "residenza dei dati" e vera "sovranità".
Di conseguenza, l'architettura più affidabile per gestire ed elaborare dati ingegneristici critici è un data lakehouse sovrano: un data lakehouse aperto che è nativamente ibrido e indipendente dal cloud.
Questo approccio offre la velocità e la facilità di un'esperienza PaaS simile al cloud, insieme a una conformità progettata appositamente, consentendo a un'azienda di rispettare politiche nazionali o di altre giurisdizioni che richiederebbero di operare interamente all'interno di un ambiente sovrano, privato e controllato (e personale).
Durata |
Spiegazione |
Impatto sull'attività |
Residenza dei dati |
I dati risiedono fisicamente su hardware all'interno dei confini geopolitici di un paese specifico. |
Gestisce i requisiti di conformità locali di base, non necessariamente legati alla sicurezza, ma principalmente alla latenza tra i dati stessi e le soluzioni IT che utilizzano quel particolare set di dati. |
Sovranità operativa |
Assicura che le persone che gestiscono l'infrastruttura cloud (Cloud Ops) e il quadro giuridico che governa il fornitore siano anch'essi locali e sotto la giusta sovranità. |
Previene il rischio di richieste di accesso da parte di governi stranieri che potrebbero legalmente costringere il provider a consegnare IP sensibili senza il consenso dell'azienda. |
Economia dell'AI: raggiungere la prevedibilità dei costi per i modelli di AI
Oltre alla sicurezza e alla conformità legale, un'architettura sovrana di data lakehouse offre un altro vantaggio cruciale: una gestione prevedibile dei costi per l'implementazione di workflow di AI.
Il modello finanziario per l'esecuzione dei servizi AI nel cloud pubblico è intrinsecamente variabile e basato sul consumo, collegando direttamente i costi alle metriche di utilizzo (come GPU-ore, token processati, volume operativo e dati scansionati). Man mano che sempre più team, progetti e applicazioni sfruttano l'infrastruttura cloud, i costi crescono esponenzialmente. Questo modello è particolarmente impegnativo per compiti ad alta richiesta come l'addestramento di modelli complessi di AI generativa (GenAI) o autoencoder pesanti, che richiedono un uso dedicato, costante e massiccio della GPU, spesso difficile da condividere in modo efficiente.
La transizione verso un data lakehouse sovrano distribuito in un data center privato o di colocation a costo fisso sposta l'organizzazione verso una spesa prevedibile:
Stabilire l'investimento in immobilizzazioni: le organizzazioni investono in infrastrutture fisse e condivisibili. Questa configurazione consente a più team e progetti di utilizzare le stesse risorse, riducendo di fatto il costo marginale di avvio di nuovi esperimenti di ricerca e sviluppo a livelli prossimi allo zero.
Eliminare il "bill shock": questa architettura elimina completamente qualsiasi rischio finanziario associato a spese inaspettate e massicce, come quelle causate da inferenze ad alto volume, cicli di addestramento iterativo continuo di R&S o tariffe proibitive per il trasferimento dati comuni nelle zone cloud pubbliche.
Per saperne di più, continua a leggere nella terza parte!