AI-PLATFORM · Percorso 4: Costruire e gestire
Sovereign AI Platform Engineering
Cinque giorni dopo i quali il Suo team non sa solo descrivere una piattaforma di inferenza, ma ne ha costruita, misurata e consegnata una.
- Durata
- 5 giorni
- Gruppo
- da 4 a 12 persone
- Formato
- Inhouse · Edizione aperta · Nel lab
- Lingua
- Tedesco o inglese
- Preavviso
- da 6 settimane
- Prezzo
- 39.500 € forfettario, IVA esclusa
Erogazione a partire da quattro partecipanti effettivamente iscritti. La data viene confermata per iscritto dopo aver concordato contenuti, prerequisiti e disponibilità.
Per chi è questo track
Team di piattaforma e architetti dell’infrastruttura chiamati a rispondere dell’inferenza LLM nel proprio data center o su Azure Local. Anche per team davanti a un acquisto di GPU che vogliono prendere la decisione di sizing con valori misurati invece che con le slide dei produttori.
Per chi no
Non per sviluppatori che vogliono costruire applicazioni su una piattaforma pronta. Loro sono al posto giusto in Enterprise RAG Engineering (AI-RAG) o in Agentic Systems Engineering (AI-AGENT).
Situazione di partenza
La decisione per l’AI sovrana è presa o imminente, l’hardware è ordinato o in fase di dimensionamento. Il Suo team conosce virtualizzazione, rete e container, ma GPU scheduling, inference server e model registry sono terreno nuovo. L’esperienza cloud aiuta, ma non si trasferisce uno a uno all’esercizio nel proprio rack.
Questo esiste dopo il track
- Un documento di architettura di riferimento su tutti gli strati: compute, rete, storage, identity, registry, stack di inferenza
- Un modello di GPU e capacità con calcolo di sizing tracciabile da L40S a H100 per le Sue ipotesi di carico, sostenuto da valori misurati in proprio nel Lab
- Uno stack di inferenza funzionante che il Suo team ha costruito da sé: model registry, inference server, API gateway, monitoring
- Un pacchetto di consegna all’esercizio con struttura di runbook, percorso di update e protocolli dei guasti dalle esercitazioni
- Un log delle decisioni sulle questioni architetturali controverse della Sua organizzazione con motivazione documentata
Prerequisiti
Solide basi di infrastruttura: virtualizzazione, rete, container e riga di comando Linux. Le conoscenze di base di Azure aiutano, ma non sono una condizione.
Preparazione prima del track
Riceverà in anticipo una scheda dell’ambiente: hardware pianificato o esistente, numeri di utenti attesi, dimensioni dei modelli, livelli di riservatezza dei dati e i tre workload più importanti. Il primo giorno questi dati diventano la base per il sizing.
Contenuto della fornitura
- 5 giornate di formazione, tenute da Dino Bordonaro
- Ambiente Lab dedicato con GPU NVIDIA per ogni coppia per l’intera settimana, dal nostro Enterprise Lab con 2.516 core e 24 TB di RAM
- Modelli di architettura di riferimento e componenti Infrastructure as Code da riutilizzare
- Foglio di calcolo del sizing con i valori di benchmark rilevati nel corso
- Certificati di partecipazione e documentazione formativa verificabile in sede di audit
- Follow-up di 60 minuti con il team 4 settimane dopo il corso
Agenda
Giorno 1
Le Sue ipotesi di carico al banco di prova
Analisi delle schede dell’ambiente: quanti utenti simultanei, quali classi di modello, quali tempi di risposta? Le aspettative vaghe diventano requisiti misurabili in token al secondo.
L’architettura di riferimento strato per strato
Compute, rete, storage, identity, registry, inferenza, gateway. Per ogni strato la singola decisione che dopo costa cara da correggere e su cosa BORDONARO l’ha fissata nella Sovereign AI Appliance.
Modello di capacità GPU da L40S a H100
Fabbisogno di VRAM, quantizzazione, batching, concurrency: cosa determina davvero la scelta della scheda. Benchmark dal vivo nel Lab, lo stesso modello su due classi di GPU nel confronto diretto.
Esercizio: calcolo di sizing per il Suo scenario
Ogni team calcola il proprio scenario con il foglio di sizing e difende il calcolo davanti al gruppo. La scoperta più frequente: prima dimensionato male, poi corretto, poi capito.
Risultato della giornata: modello di capacità documentato
Ogni team ha un modello di capacità motivato per il proprio scenario, verificato contro i valori di benchmark della giornata. Nel corso della settimana verrà validato contro la piattaforma reale.
Giorno 2
Azure Local come fondamento
Anatomia del cluster, Storage Spaces Direct, ruoli e limiti della piattaforma nella versione di volta in volta disponibile. Cosa sa fare Azure Local, cosa no e dove una base puramente Kubernetes è la risposta più onesta.
Identity pensata da cima a fondo
Entra ID, identità locali, workload identity e gestione dei secrets senza testo in chiaro nelle config. Domanda concreta: chi può chiamare quale modello con quali dati e dove viene fatto rispettare?
Design della rete e controllo dell’egress
Segmentazione della zona di inferenza, TLS nei collegamenti interni, uscite controllate. Esercizio alla lavagna: di quali sette connessioni la piattaforma ha davvero bisogno e quali di queste si possono chiudere?
Esercizio: realizzare il design del fondamento nel Lab
Ogni team configura collegamento identity e segmentazione di rete per il proprio ambiente Lab e dimostra con un accesso di test che i confini tengono.
Risultato della giornata: fondamento approvato
Identity e rete sono in piedi e testate. Ogni team documenta il proprio design del fondamento nella blueprint, le controversie aperte finiscono motivate nel log delle decisioni.
Giorno 3
Registry: origine e firma dei modelli
Model registry e container registry come un’unica disciplina: versionamento, verifica delle firme, prova di provenienza. Perché un modello non firmato preso da internet non deve finire in nessuna piattaforma sovrana.
Inference server nel confronto onesto
vLLM e alternative sugli stessi punti di misura: throughput, latenza, onere di esercizio. In più lo sguardo a Foundry Local su Azure Local nella versione di volta in volta disponibile, attualmente Preview, con un inquadramento chiaro di cosa significhi per le decisioni di produzione.
Costruzione: dal modello all’endpoint API
Ogni team costruisce lo stack per intero: prelevare il modello dalla registry, verificare la firma, servirlo, metterlo dietro l’API gateway. Alla fine la propria piattaforma risponde alla prima richiesta autenticata.
Test di carico e tuning
Generatore di carico contro il proprio stack: modificare parametri di batching, KV cache e quantizzazione e misurarne l’effetto. Il modello di capacità del Giorno 1 incontra la realtà.
Risultato della giornata: stack funzionante con protocollo di misura
Ogni team ha uno stack di inferenza funzionante e un protocollo di misura che espone e spiega lo scostamento tra calcolo di sizing e prestazione misurata.
Giorno 4
Observability per piattaforme GPU
Utilizzo delle GPU, throughput in token, code, tassi di errore: quali metriche servono davvero a un team di esercizio e quali allarmi possono svegliare di notte. Costruzione del dashboard sulla propria piattaforma Lab.
Percorso di update: modelli, driver, firmware, container
Quattro flussi di update con quattro profili di rischio. Decisione concreta per ogni flusso: finestra di manutenzione, canary o rolling, e cosa va misurato obbligatoriamente prima di ogni cambio di modello.
Tenant, quote e ripartizione interna dei costi
Più team su una piattaforma GPU: modello di quote, prioritizzazione, attribuzione dei costi. Esercizio: progettare e motivare un modello di quote per tre reparti in concorrenza.
Esercitazione di guasto: il nodo cade
Togliamo a un team, in modo controllato, un nodo GPU. Riconoscere, decidere, deviare, comunicare: il guasto viene gestito secondo runbook e poi sezionato.
Risultato della giornata: dashboard di esercizio e protocollo del guasto
Ogni team ha un dashboard di monitoring funzionante e un protocollo del guasto compilato con linea temporale, decisioni e miglioramenti per il proprio runbook.
Giorno 5
Il runbook diventa completo
Procedure di avvio, sequenze di update, scenari di guasto, vie di escalation: i frammenti della settimana vengono riuniti in una struttura di runbook che un team di esercizio può prendere in carico.
Review dell’architettura contro i Suoi requisiti
La blueprint di ogni team in review contro requisiti di protezione dei dati, direttive di sicurezza interne e requisiti fino a VS-NfD, per i quali l’architettura deve poter essere predisposta. Le lacune vengono nominate, non minimizzate a parole.
Simulazione di collaudo: consegna all’esercizio
Gioco di ruolo a team invertiti: un team consegna la propria piattaforma, l’altro verifica secondo checklist di collaudo e può chiedere tutto. Ciò che non sopravvive alla consegna viene sistemato.
Piano di trasferimento per lunedì
Ogni team prioritizza i primi tre passi nella propria organizzazione: cosa viene adottato, cosa viene deciso diversamente, cosa richiede un acquisto? La data del follow-up viene fissata.
Risultato finale: blueprint referenziabile
Ogni team lascia il corso con una blueprint di piattaforma documentata, modello di capacità validato, struttura di runbook e log delle decisioni. Breve review dei risultati da parte del trainer a chiusura.
Esercitazioni e quota lab
Circa metà della settimana è lavoro sui sistemi: ogni coppia costruisce su GPU NVIDIA dedicate del nostro Enterprise Lab uno stack di inferenza completo, lo misura sotto carico e gestisce un guasto reale.
Piattaforme
Svolgimento sul nostro ambiente Lab con GPU NVIDIA e Azure Local nella versione di volta in volta disponibile. Mostriamo Foundry Local su Azure Local come Preview e lo contrassegniamo come tale, non ne deriviamo raccomandazioni di produzione. BORDONARO è un partner indipendente, non una filiale Microsoft.
Prova di transfer
La simulazione di collaudo del Giorno 5 è la prova di trasferimento: ogni team consegna la propria piattaforma secondo checklist e supera la review del team partner. Blueprint, protocolli di misura e protocollo del guasto vengono documentati e consegnati ai partecipanti.
Artefatti che porta con sé
- Blueprint dell’architettura di riferimento come documento con componenti Infrastructure as Code
- Modello di capacità e foglio di calcolo del sizing con valori di benchmark propri
- Struttura di runbook con percorso di update e scenari di guasto
- Checklist di collaudo per la consegna all’esercizio
- Log delle decisioni con le scelte architetturali motivate della settimana
Estensioni opzionali
- LLMOps per ambienti connessi, separati e Air-Gap (AI-OPS) come approfondimento operativo
- Sovereign AI Architecture Residency (AI-RESIDENCY) per il progetto su misura del cliente nel Lab
- Sovereign AI Appliance come piattaforma preconfigurata, se l’autocostruzione non è l’obiettivo
Delimitazione
Il corso costruisce competenza e una blueprint, non un ambiente di produzione nel Suo data center. Implementazione e managed service sono prestazioni autonome di BORDONARO e vengono incaricate separatamente.
Domande frequenti
39.500 € sono una dichiarazione. Come si ripaga?
Con 12 partecipanti sono circa 3.300 € a persona per cinque giorni su hardware GPU dedicato, meno di molti corsi dei singoli produttori che non hanno hardware proprio sotto. Un solo acquisto GPU sbagliato e poi corretto copre più volte il prezzo del corso.
Non abbiamo ancora hardware GPU nostro. Il corso arriva troppo presto?
No, semmai al momento giusto. L’intera settimana gira sul nostro Lab, non deve portare nulla. Il modello di capacità del primo giorno è prezioso proprio prima di un acquisto, perché dopo può motivare la decisione di sizing con valori misurati in proprio.
Come gestite gli stati Preview di Microsoft?
Con onestà. Foundry Local su Azure Local è Preview e viene trattato come tale: lo mostriamo, ne contrassegniamo lo stato e costruiamo la blueprint in modo che non dipenda da funzioni Preview. Tutto il resto vale nella versione disponibile alla data del corso.