AI-PLATFORM · Pfad 4: Bauen und betreiben
Sovereign AI Platform Engineering
Fünf Tage, nach denen Ihr Team eine Inferenz-Plattform nicht nur beschreiben kann, sondern eine gebaut, vermessen und übergeben hat.
- Dauer
- 5 Tage
- Gruppe
- bis 12 Personen
- Format
- Inhouse · Offene Durchführung · Im Lab
- Sprache
- Deutsch oder Englisch
- Preis
- 39.500 € pauschal, zzgl. MwSt.
Für wen dieser Track ist
Plattform-Teams und Infrastruktur-Architekten, die LLM-Inferenz im eigenen Rechenzentrum oder auf Azure Local verantworten sollen. Auch für Teams, die vor einer GPU-Beschaffung stehen und die Sizing-Entscheidung mit Messwerten statt Herstellerfolien treffen wollen.
Für wen nicht
Nicht für Entwickler, die Anwendungen auf einer fertigen Plattform bauen wollen. Die sind im Enterprise RAG Engineering (AI-RAG) oder im Agentic Systems Engineering (AI-AGENT) richtig.
Ausgangssituation
Die Entscheidung für souveräne KI ist gefallen oder steht kurz bevor, die Hardware ist bestellt oder wird gerade dimensioniert. Ihr Team kennt Virtualisierung, Netzwerk und Container, aber GPU-Scheduling, Inference-Server und Modell-Registries sind Neuland. Cloud-Erfahrung hilft, überträgt sich aber nicht eins zu eins auf den Betrieb im eigenen Rack.
Das existiert nach dem Track
- Ein Referenzarchitektur-Dokument über alle Schichten: Compute, Netzwerk, Storage, Identity, Registry, Inference-Stack
- Ein GPU- und Kapazitätsmodell mit nachvollziehbarer Sizing-Rechnung von L40S bis H100 für Ihre Lastannahmen, gestützt auf eigene Messwerte aus dem Lab
- Ein lauffähiger Inference-Stack, den Ihr Team selbst aufgebaut hat: Modell-Registry, Inference-Server, API-Gateway, Monitoring
- Ein Betriebsübergabe-Paket mit Runbook-Gerüst, Update-Pfad und Störungsprotokollen aus den Übungen
- Ein Entscheidungslog zu den strittigen Architekturfragen Ihres Hauses mit dokumentierter Begründung
Voraussetzungen
Solide Infrastruktur-Grundlagen: Virtualisierung, Netzwerk, Container und Linux-Kommandozeile. Azure-Grundkenntnisse helfen, sind aber keine Bedingung.
Vorarbeit vor dem Track
Sie erhalten vorab einen Umgebungs-Steckbrief: geplante oder vorhandene Hardware, erwartete Nutzerzahlen, Modellgrößen, Vertraulichkeitsstufen der Daten und die drei wichtigsten Workloads. Diese Angaben werden am ersten Tag zur Sizing-Grundlage.
Lieferumfang
- 5 Trainingstage, gehalten von Dino Bordonaro
- Dedizierte Lab-Umgebung mit NVIDIA-GPUs je Zweierteam für die gesamte Woche, aus unserem Enterprise-Lab mit 2.516 Cores und 24 TB RAM
- Referenzarchitektur-Vorlagen und Infrastructure-as-Code-Bausteine zur Weiterverwendung
- Sizing-Rechenblatt mit den im Kurs erhobenen Benchmark-Werten
- Teilnahmezertifikate und revisionssichere Schulungsdokumentation
- 60-minütiges Follow-up mit dem Team 4 Wochen nach dem Kurs
Agenda
Tag 1
Ihre Lastannahmen auf dem Prüfstand
Auswertung der Umgebungs-Steckbriefe: Wie viele gleichzeitige Nutzer, welche Modellklassen, welche Antwortzeiten? Aus vagen Erwartungen werden messbare Anforderungen in Tokens pro Sekunde.
Die Referenzarchitektur Schicht für Schicht
Compute, Netzwerk, Storage, Identity, Registry, Inference, Gateway. Für jede Schicht die eine Entscheidung, die später teuer zu korrigieren ist, und woran BORDONARO sie in der Sovereign AI Appliance festgemacht hat.
GPU-Kapazitätsmodell von L40S bis H100
VRAM-Bedarf, Quantisierung, Batching, Concurrency: was die Wahl der Karte wirklich bestimmt. Live-Benchmark im Lab, dasselbe Modell auf zwei GPU-Klassen im direkten Vergleich.
Übung: Sizing-Rechnung für Ihr Szenario
Jedes Team rechnet sein eigenes Szenario mit dem Sizing-Blatt durch und verteidigt die Rechnung vor der Gruppe. Die häufigste Erkenntnis: erst falsch dimensioniert, dann korrigiert, dann verstanden.
Tagesergebnis: dokumentiertes Kapazitätsmodell
Jedes Team hat ein begründetes Kapazitätsmodell für sein Szenario, geprüft gegen die Benchmark-Werte des Tages. Es wird im Laufe der Woche gegen die echte Plattform validiert.
Tag 2
Azure Local als Fundament
Cluster-Anatomie, Storage Spaces Direct, Rollen und Grenzen der Plattform in der jeweils verfügbaren Version. Was Azure Local kann, was es nicht kann und wo ein reiner Kubernetes-Unterbau die ehrlichere Antwort ist.
Identity durchgängig gedacht
Entra ID, lokale Identitäten, Workload-Identity und Secrets-Verwaltung ohne Klartext in Configs. Konkrete Frage: Wer darf welches Modell mit welchen Daten aufrufen, und wo wird das durchgesetzt?
Netzwerkdesign und Egress-Kontrolle
Segmentierung der Inference-Zone, TLS im Innenverhältnis, kontrollierte Ausgänge. Übung am Whiteboard: Welche sieben Verbindungen braucht die Plattform wirklich, und welche davon lassen sich schließen?
Übung: Fundament-Design im Lab umsetzen
Jedes Team richtet Identity-Anbindung und Netzsegmentierung für seine Lab-Umgebung ein und weist mit einem Testzugriff nach, dass die Grenzen halten.
Tagesergebnis: freigegebenes Fundament
Identity und Netz stehen und sind getestet. Jedes Team dokumentiert sein Fundament-Design in der Blaupause, offene Streitfragen wandern begründet ins Entscheidungslog.
Tag 3
Registry: Herkunft und Signatur von Modellen
Modell- und Container-Registry als eine Disziplin: Versionierung, Signaturprüfung, Herkunftsnachweis. Warum ein unsigniertes Modell aus dem Internet in keiner souveränen Plattform landen darf.
Inference-Server im ehrlichen Vergleich
vLLM und Alternativen an denselben Messpunkten: Durchsatz, Latenz, Betriebsaufwand. Dazu der Blick auf Foundry Local auf Azure Local in der jeweils verfügbaren Version, derzeit Preview, mit klarer Einordnung, was das für Produktionsentscheidungen bedeutet.
Aufbau: vom Modell zum API-Endpunkt
Jedes Team baut den Stack durch: Modell aus der Registry ziehen, Signatur prüfen, servieren, hinter das API-Gateway legen. Am Ende antwortet die eigene Plattform auf den ersten authentifizierten Request.
Lasttest und Tuning
Lastgenerator gegen den eigenen Stack: Batching-Parameter, KV-Cache und Quantisierung verändern und die Wirkung messen. Das Kapazitätsmodell von Tag 1 trifft auf die Realität.
Tagesergebnis: lauffähiger Stack mit Messprotokoll
Jedes Team hat einen funktionierenden Inference-Stack und ein Messprotokoll, das die Abweichung zwischen Sizing-Rechnung und gemessener Leistung ausweist und erklärt.
Tag 4
Observability für GPU-Plattformen
GPU-Auslastung, Token-Durchsatz, Warteschlangen, Fehlerraten: welche Metriken ein Betriebsteam wirklich braucht und welche Alarme nachts wecken dürfen. Aufbau des Dashboards auf der eigenen Lab-Plattform.
Update-Pfad: Modelle, Treiber, Firmware, Container
Vier Update-Ströme mit vier Risikoprofilen. Konkrete Entscheidung je Strom: Wartungsfenster, Canary oder rollierend, und was vor jedem Modellwechsel zwingend gemessen wird.
Mandanten, Quoten und interne Verrechnung
Mehrere Teams auf einer GPU-Plattform: Quotenmodell, Priorisierung, Kostenzuordnung. Übung: ein Quotenmodell für drei konkurrierende Abteilungen entwerfen und begründen.
Störungsübung: der Node fällt aus
Wir ziehen einem Team kontrolliert einen GPU-Node weg. Erkennen, entscheiden, umleiten, kommunizieren: die Störung wird nach Runbook abgearbeitet und anschließend seziert.
Tagesergebnis: Betriebs-Dashboard und Störungsprotokoll
Jedes Team hat ein funktionierendes Monitoring-Dashboard und ein ausgefülltes Störungsprotokoll mit Zeitleiste, Entscheidungen und Verbesserungen fürs eigene Runbook.
Tag 5
Das Runbook wird vollständig
Startprozeduren, Update-Abläufe, Störungsszenarien, Eskalationswege: die Fragmente der Woche werden zu einem Runbook-Gerüst zusammengeführt, das ein Betriebsteam übernehmen kann.
Architektur-Review gegen Ihre Anforderungen
Die Blaupause jedes Teams im Review gegen Datenschutz-Anforderungen, interne Sicherheitsvorgaben und Anforderungen bis VS-NfD, für die die Architektur vorbereitbar sein soll. Lücken werden benannt, nicht wegdiskutiert.
Abnahme-Simulation: Übergabe an den Betrieb
Rollenspiel mit vertauschten Teams: ein Team übergibt seine Plattform, das andere prüft nach Abnahme-Checkliste und darf alles fragen. Was die Übergabe nicht überlebt, wird nachgebessert.
Transferplan für Montag
Jedes Team priorisiert die ersten drei Schritte im eigenen Haus: Was wird übernommen, was wird anders entschieden, was braucht eine Beschaffung? Terminierung des Follow-ups.
Abschlussergebnis: referenzierbare Blaupause
Jedes Team verlässt den Kurs mit einer dokumentierten Plattform-Blaupause, validiertem Kapazitätsmodell, Runbook-Gerüst und Entscheidungslog. Kurzes Review der Ergebnisse durch den Trainer als Abschluss.
Übungen und Lab-Anteil
Rund die Hälfte der Woche ist Arbeit an den Systemen: jedes Zweierteam baut auf dedizierten NVIDIA-GPUs unseres Enterprise-Labs einen kompletten Inference-Stack auf, vermisst ihn unter Last und arbeitet eine echte Störung ab.
Plattformen
Durchführung auf unserer Lab-Umgebung mit NVIDIA-GPUs und Azure Local in der jeweils verfügbaren Version. Foundry Local auf Azure Local zeigen wir als Preview und kennzeichnen es entsprechend, Produktionsempfehlungen leiten wir daraus nicht ab. BORDONARO ist unabhängiger Partner, keine Microsoft-Niederlassung.
Transfernachweis
Die Abnahme-Simulation am Tag 5 ist der Transfernachweis: jedes Team übergibt seine Plattform nach Checkliste und besteht das Review des Partner-Teams. Blaupause, Messprotokolle und Störungsprotokoll werden dokumentiert und den Teilnehmenden übergeben.
Mitgenommene Artefakte
- Referenzarchitektur-Blaupause als Dokument mit Infrastructure-as-Code-Bausteinen
- Kapazitätsmodell und Sizing-Rechenblatt mit eigenen Benchmark-Werten
- Runbook-Gerüst mit Update-Pfad und Störungsszenarien
- Abnahme-Checkliste für die Betriebsübergabe
- Entscheidungslog mit den begründeten Architekturentscheidungen der Woche
Optionale Erweiterungen
- LLMOps für verbundene, getrennte und Air-Gap-Umgebungen (AI-OPS) als betriebliche Vertiefung
- Sovereign AI Architecture Residency (AI-RESIDENCY) für den kundenindividuellen Entwurf im Lab
- Sovereign AI Appliance als vorkonfigurierte Plattform, wenn der Eigenbau nicht das Ziel ist
Abgrenzung
Der Kurs baut Kompetenz und eine Blaupause auf, keine Produktionsumgebung in Ihrem Rechenzentrum. Implementierung und Managed Service sind eigenständige Leistungen von BORDONARO und werden separat beauftragt.
Häufige Fragen
39.500 € sind eine Ansage. Wie rechnet sich das?
Bei 12 Teilnehmenden sind das rund 3.300 € pro Person für fünf Tage an dedizierter GPU-Hardware, weniger als viele einzelne Herstellerschulungen ohne eigene Hardware darunter. Eine einzige korrigierte Fehlbeschaffung bei GPUs deckt den Kurspreis mehrfach.
Wir haben noch keine eigene GPU-Hardware. Ist der Kurs zu früh?
Nein, eher genau richtig. Die gesamte Woche läuft auf unserem Lab, Sie brauchen nichts mitzubringen. Das Kapazitätsmodell vom ersten Tag ist gerade vor einer Beschaffung wertvoll, weil Sie die Sizing-Entscheidung danach mit eigenen Messwerten begründen können.
Wie gehen Sie mit Preview-Ständen bei Microsoft um?
Ehrlich. Foundry Local auf Azure Local ist Preview und wird so behandelt: wir zeigen es, kennzeichnen den Stand und bauen die Blaupause so, dass sie nicht von Preview-Funktionen abhängt. Alles Weitere gilt in der jeweils verfügbaren Version zum Kurstermin.