8) ML/LLM-Betrieb on-prem

  • GPU-Scheduling und Isolierung: Workloads sprechen explizit Ressourcen an; Partitionierung nutzen, wo verfügbar. Monitoring von thermalen/elektrischen Limits.

  • Modelllebenszyklus: Versionierte Modelle in lokalem Registry/Artefakt-Store. Automatisierte Verträglichkeits-Checks (z. B. Feature-Schema, Onnx/TensorRT-Kompatibilität).

  • Governance für LLM-Agenten: Keine externen API-Calls. Prompt/Context-Logging mit Redaktionen für PII. Policy-Engines erzwingen Retrieval nur aus freigegebenen Indizes. Offline-Evaluationssuites, um Drifts und Regressionen zu erkennen.

Was in der Praxis besser funktioniert als „Lift & Shift“

  • Modularer Monolith für Kern-Workloads, Microservices nur für klar abgegrenzte, unabhängig skalierbare Komponenten. On-Prem verringert die Vorteile fein ziselierter Services, erhöht aber deren Betriebsaufwand. Ein modularer Monolith mit klaren Modulgrenzen, internen Events und hartem API-Vertrag reduziert Komplexität ohne Agilität zu opfern.
  • Stateful Services bewusst zentralisieren: Ein robuster, gut gesicherter Postgres-Cluster on-prem schlägt fünf exotische Datenbanken mit jeweils eigenem Operationsmodell. State verteilt man über Replikation und Events, nicht über zehn unterschiedliche Stateful Stacks.
  • Embedded Edge-Pattern: An der Produktionslinie oder im Fahrzeug läuft ein schlanker Agent: Datenaufnahme, Vorverarbeitung, lokale Inferenz, kurzzeitige Pufferung. Eine regionale Zentrale übernimmt Aggregation, Training/Feinjustierung und Auditing. Die Public Cloud ist optional für synthetische Lasttests oder nicht-sensible Offline-Analysen – niemals als kritischer Pfad.

Anti-Patterns, die regelmäßig Projekte bremsen

  • Versteckte Cloud-Kopplungen: Telemetrie-Exporte, Lizenz-Server, externe Zeitdienste, CDN-Only-Installer. Alles, was im Audit auffällt, fliegt spätestens in der Abnahme.
  • SaaS-UX in Air-Gap denken: „Wir shippen jeden Tag 20 kleine Features“ – in Air-Gap-Umgebungen heißt das 20 mal mehr Paketierung und Test. Besser gebündelte Releases mit klaren Migrationspfaden.
  • „Wir machen das wie in der Cloud, nur ohne Cloud“: Viele Managed Services (z. B. Secrets-as-a-Service, Observability-as-a-Service) müssen plattformseitig ersetzt werden. Einfach zu tun, schwer zu betreiben – ohne Runbooks und SLOs kippt das System in Tribal Knowledge.
  • Multi-Region-HA über unzuverlässige Links: Ein etcd-Quorum oder synchrones Replizieren über WAN-Leitungen ist ein Garant für Split-Brain oder Stillstand. Besser: Lokale Verfügbarkeit maximieren, asynchrone Replikation und klar definierte Recovery-Prozeduren.

Konkrete Architekturen aus Projekterfahrung

Beispiel 1: Fleet Intelligence für Bahnnetze

  • Problem: Events aus Fahrzeugen (Zug/Triebwagen), sporadische Konnektivität, harte Vorgaben zu Datenlokalität.

  • Architektur:

  • Edge: Schlanke Agenten sammeln Telemetrie, Vorverarbeitung (Zustandsverdichtung, Ausreißererkennung), lokale Persistenz als Append-Only-Log.

  • Regional-Cluster on-prem: Kubernetes-Cluster mit Event-Broker, Timeseries-DB, Feature-Store, Batch- und Stream-Analysen. GitOps steuert Deployments. Observability lokal.

  • Datenfluss: Edge→Regional asynchron, mit Re-Transmit und Deduplizierung. Kein direkter Remote-Write ins Zentrum.

  • Analytics: Modelle werden regional trainiert/justiert, Inferenzmodelle als versionierte Artefakte zurück zum Edge gepusht (signierte Bundles).

  • Trade-off: Höhere Betriebskomplexität in der Zentrale vs. robuste Resilienz bei Feldverbindungen. Entscheidender Vorteil: Kein sensibler Fluss verlässt das Netz.

Beispiel 2: Visuelle Qualitätsprüfung in der Fertigung

  • Problem: Sub-100ms Latenz, kameranahe Auswertung, regelmäßige Modell-Updates, auditsichere Nachvollziehbarkeit.

  • Architektur:

  • Linie: Industrierechner mit GPU, Containerisierte Inferenzdienste, lokaler Bildpuffer (z. B. Minutenbereich) für forensische Zwecke, Event-Ausgabe an SPS/PLC.

  • Werk-Cluster: Kubernetes on-prem, Artefakt-Registry, Modell-Registry, CI/CD mit Offline-Signing. Observability und Traceability werk-intern.

  • Governance: Jedes Modell-Deployment erfordert signierte Freigabe, Validierungsbericht, Rückroll-Plan. Ein zentrales Policieset verhindert das Laden unfreigegebener Modelle.

  • Trade-off: Weniger „Always-Latest“-Features, dafür deterministische Deployments und rechtssichere Audits.

Praktische Checkliste für die ersten 90 Tage

  • Datenklassifizierung und Segmentierung:
  • Welche Daten sind PII, welche sind betriebskritisch, welche sind unkritisch?
  • Netzsegmente und Namespaces entsprechend planen, Zugriffspfade hart definieren.
  • Plattform-Baseline:
  • Kubernetes-Distro mit HA, interne Container-Registry, Git on-prem, Artefakt-Store, IdP, Secrets-Manager, Observability-Stack.
  • Standard-Node-Images und Härtung (CIS-Benchmarks, Minimal-Footprint).
  • Supply-Chain-Sicherheit:
  • SBOM-Pflicht für alle Artefakte, Signatur-Pflicht vor Deploy.
  • Mirror-Strategie für Upstream-Abhängigkeiten, Scan-Prozess in Staging.
  • GitOps und Release-Management:
  • Pull-basiert, Air-Gap-Bundles, Promotion-Stufen (Dev→Staging→Prod).
  • Release-Kadenz festlegen (z. B. 4–6 Wochen) mit Bugfix-Out-of-Band-Prozessen.
  • Betriebs-SLOs und Runbooks:
  • SLOs für Verfügbarkeit, Latenz, Recovery Time/Point Objectives (RTO/RPO).
  • Alarme, On-Call, Eskalationspfade dokumentieren und testen.
  • Backup/DR:
  • Regelmäßige Backups von Control-Plane, State und Artefakt-Registry. Restore-Tests früh und wiederholt.
  • Security-Reviews:
  • Netzwerk-Policies, mTLS, Secrets-Scans, Image-Härtung – automatisiert in der Pipeline.

Cloud-native vs. On-Prem: Die echten Trade-offs

  • Kontrolle vs. Bequemlichkeit: On-Prem gibt Ihnen volle Kontrolle, kostet aber mehr in Day-2-Operation. Sie brauchen Platform Engineering Fähigkeiten: IaC, GitOps, Observability, Security.
  • Kostenwahrheit: On-Prem investiert vorab, aber Daten-Egress, Storage und GPU-Zeiten in der Cloud summieren sich schnell. Für kontinuierliche, datenintensive Workloads ist On-Prem häufig planbarer und günstiger – vorausgesetzt, die Auslastung ist da.
  • Geschwindigkeit: Cloud beschleunigt Prototypen. Serienreife in regulierten Umgebungen verlangt jedoch reproduzierbare, auditierbare Deployments – hier ist ein durchdachter On-Prem-Stack mit GitOps meist schneller über die Ziellinie als ad-hoc Cloud-Bastelei, die später umgebaut werden muss.
  • Vendor Lock-in: Cloud-Managed-Services verkürzen Time-to-Value, aber binden an proprietäre APIs. On-Prem diszipliniert bei API-Design, Datenmodellen und offenen Standards – was der Langlebigkeit hilft.

LLM- und Agentensysteme on-prem: Governance first