Compute und Scheduling

  • GPU-Knoten: Ausgewogenes Verhältnis von GPU-Speicher, HBM-Bandbreite, PCIe/NVLink-Topologie. Mischen Sie nicht wild unterschiedliche GPU-Generationen in einem Trainingsjob.

  • Partitionierung: Multi-Instance GPU (MIG) oder zeitliche Partitionierung, um kleine Jobs effizient zu packen und Fairness durchzusetzen.

  • Scheduler-Varianten:

  • Kubernetes + GPU-Scheduler (z. B. mit Device Plugins, Namespace-Quotas, Pod Priority/Preemption) für Services, Pipelines, leichte/mittlere Trainingsjobs.

  • Slurm für HPC-lastige Trainings mit eng gekoppelter Kommunikation. Alternativ Kubernetes mit Batch-Scheduler (Volcano) – aber HPC-Kompetenz entscheidet.

  • Container-Baselines: Kuratierte Base-Images pro Framework/Compiler. Keine Internet-Builds im Produktionscluster; nutzen Sie interne Registry-Spiegel und SBOM-Scans.

  • Kommunikationen: NCCL-Tuning (Topology-Aware), richtige MTU/Jumbo Frames, P2P-Enablement. Netzwerktests (iperf, NCCL-tests) in CI einbetten.

MLOps und Reproduzierbarkeit

  • CI/CD und GitOps: Infrastruktur als Code, Pipelines als Code. Jede Trainingspipeline versioniert, deterministische Seeds, festgenagelte Container-Hashes.

  • Experiment-Tracking: Metriken, Artefakte, Konfigurationen zentral erfassen. Modelle nur mit vollständigem Kontext in die Registry.

  • Model Registry: Promotion-Regeln (staging→prod) mit Freigabeworkflow, Rollback-Fähigkeit, Signierung von Artefakten.

  • Feature-/Dataset-Store: Für Zeitreihen und tabellarische Use-Cases; für CV vor allem Dataset-Manifestierung (Shards, Augmentierungsrezepte).

  • Observability: Node- und Job-Level-Metriken (GPU-Utilization, VRAM, I/O), Pipeline-Latenzen, Daten- und Modell-Drift.

  • LLM-spezifische Governance: Prompt/Response-Logging, Halluzinations-Metriken, Policy-Checks, Red-Teaming. Für agentische Workflows On-Prem-Observability und Policy-Enforcement (z. B. mit einem dedizierten Agent-Governance-Layer wie Alpi-M, der Anfragen, Tools, Datenzugriffe und Outputs auditierbar macht).

Sicherheit und Compliance

  • Identität und Zugriffe: OIDC/SAML, fein granular via RBAC. Kein Shared-Account für Trainingsjobs.

  • Geheimnisse: Vault-ähnliche Secret-Stores, kurzlebige Tokens, niemals Klartext in Pipelines.

  • Verschlüsselung: Daten im Transit (mTLS), im Ruhezustand (LUKS/SED). Schlüsselverwaltung On-Prem, nicht im Cloud-HSM eines Drittlands.

  • Lieferkette: Signierte Container, SBOM, Vulnerability Scans in CI. Estrich gegen Supply-Chain-Angriffe wichtiger als eine weitere GPU.

  • Audit: Lückenlose Protokollierung der Datenentstehung, -transformation und -nutzung. Wer hat welches Modell womit trainiert und deployed? Das muss rückrechenbar bleiben.

Betrieb und Lebenszyklus

  • Patchfenster: Planbare Wartung, Rolling Upgrades, Canary-Jobs. Air-gapped? Dann Offline-Repository-Spiegel und signierte Update-Bundles pflegen.

  • Kapazitätsplanung: Belegen Sie GPU-Zeit in Schedulern; messen Sie Auslastung über Quartale. Reinvestitionspunkte an Kennzahlen knüpfen, nicht an Bauchgefühl.

  • DR/Backup: Snapshots von Registern, Metadaten, Objektspeichern. Wiederherstellungsübungen, sonst sind Backups nur Deko.

  • Support/SLA: Klare Eskalationspfade, 24/7-Bedarf? Dann Staffen oder Vertrag. Produktionslinien warten nicht auf einen Slack-Reply.

Cloud-Training pragmatisch nutzen – ohne Souveränität zu verlieren
Wenn Cloud, dann bewusst und minimal-invasiv:

  • Datenminimierung: Nur das Nötige exportieren. Vorher Pseudonymisierung, Sampling, Downscaling. Keine Rohbilder mit Personen, wenn Ziele mit anonymisierten Patches erreichbar sind.

  • Einbahnstraße: Kein schreibender Zugriff der Cloud-Jobs auf On-Prem-Quellen. Pull von whitelisted Buckets, Push nur der Modelle/Artefakte zurück.

  • Verschlüsselung und Schlüsselhoheit: Client-seitige Verschlüsselung; Schlüssel On-Prem. Kein Key Escrow.

  • Kostenkontrollen: Quoten, Budget-Alerts, Preemptibles/Spot nur für nicht-kritische Jobs. Reproduzierbarkeit sichern trotz Preemption.

  • Region und Anbieterwahl: Bevorzugen Sie Anbieter mit klarer EU-Rechtsbindung und ohne US-Rechtsdurchgriff. Prüfen Sie vertraglich Audit-Rechte, Datenlokation und Unterauftragsverhältnisse.

  • Exit-Strategie: Images, Artefakte, Pipelines portieren können. Vermeiden Sie proprietäre Managed-Dienste in kritischen Pfaden, die Re-Hosting erschweren.

TCO: Wie man rechnet, nicht welche Zahl herauskommt
Eine brauchbare TCO-Betrachtung ist eine Funktion der Lastprofile, nicht nur Hardwarepreise. Komponenten:

  • CAPEX: GPUs, Server, Netzwerk, Storage, Racks, Kühlung. Amortisation über 3–5 Jahre, je nach Lifecycle.

  • OPEX: Strom (IT + Kühlung), Fläche, Serviceverträge, Ersatzteile, Personal.

  • Opportunitätskosten: Wartezeiten (Beschaffung, Scheduling), Umschulung/Training des Teams, Ausfälle durch Instabilitäten.

  • Cloud-Kosten: Compute- und Storage-Zeit, Datenbewegung, Reservierungen, Management-Overhead.

  • Risiko- und Compliance-Kosten: Audit, Vertragsprüfungen, Datenschutz-Folgenabschätzungen, mögliche Produktionsstillstände.

Rechnen Sie Szenarien:

  • Stetig mittlere Last → On-Prem tendiert günstiger und kontrollierbarer.

  • Sporadisch extreme Spitzen → Cloud-Bursting kann sich lohnen, wenn Daten minimiert sind.

  • Hochsensitiv + hohe Datenrate → On-Prem nahezu gesetzt; Cloud nur randständig.

Fallstricke aus Projekten – und wie man sie vermeidet

  • Heterogene GPU-Generationen im selben Cluster: Führt zu instabilen verteilten Trainings. Partitionieren Sie nach Generation oder pinnen Sie Jobs.

  • „Wir fangen mal mit NFS an“: Einzelnes NFS als Engpass bricht CV-Pipelines das Genick. Früh in verteilte, bandbreitenstarke Storage-Patterns investieren.

  • Kein Seed/Aufzeichnungsdisziplin: Ohne feste Seeds und Artefakt-Logging sind Ergebnisse nicht reproduzierbar – Audits scheitern.

  • Schatten-Clouds von Data-Science-Teams: Wenn Governance zu schwerfällig ist, bauen Teams heimlich Workloads extern – Compliance-Risiko. Besser: einen schnellen, sicheren On-Prem-Sandbox-Pfad anbieten.

  • Overfitting auf Benchmarks statt Linienrealität: Domain-Shift wird unterschätzt. Planen Sie aktives Lernen und kontinuierliches Daten-Curation-Budget ein.

Migrationspfad: Vom PoC-Cluster zur Produktionsplattform

  • Phase 1 – Minimal lebensfähige Plattform: 2–4 GPU-Knoten, S3-kompatibler Objektspeicher, Kubernetes für Services, Slurm oder K8s-Batch für Training, interne Registry, Grundschutz (RBAC/Secrets), Experiment-Tracking.

  • Phase 2 – Produktionsreife: Dataset-Versionierung, Model Registry mit Promotions, Observability, DLP-Gates vor Lake, Policy-Enforcement für LLM/Agents, DR-Backups, signierte Supply Chain.

  • Phase 3 – Skalierung/Feintuning: Scheduler-Tuning, MIG für Packdichte, Topology-aware NCCL, NVMe-over-Fabrics, feingranulare Quotas, Chargeback/Showback zur Kostentransparenz.