Governance für Modelle und LLMs

  • Trainingsdaten-Provenance: Hashes von Datasets, reproduzierbare Cuts („Time-Travel“ der Tabellen), Versionierung der Pipelines.

  • Model Cards/Docs: Zweck, Trainingsdatenbereiche, bekannte Limitierungen, Freigabeprozess.

  • LLM-spezifisch: Retrieval-Provenance (welche Dokumente wurden herangezogen), Halluzinations- und Toxicity-Guards lokal, Prompt-Injektion-Tests; keine Telemetrie nach außen.

MLOps in der Industrie: Vom Datensatz zum robusten Dienst

Tooling ist Mittel zum Zweck. Wichtig ist ein fließendes, testbares End-to-End.

Baseline-Stack On-Prem

  • Versionsverwaltung/CI: Git mit On-Prem-Runnern; Artefakt-Registry; Infrastruktur als Code.

  • Orchestrierung: Argo Workflows oder Airflow; für ML-Pipelines Kubeflow/Tekton optional.

  • Tracking/Registry: MLflow oder vergleichbares für Experimente, Modelle, Metriken, Artefakt-URIs.

  • Feature Store: z. B. Feast (Online/Offline-Store getrennt, Feature-Definitions als Code).

  • Storage/Katalog: S3-kompatibler Objektspeicher, Lakehouse-Tabellen, Data Catalog (OpenMetadata/DataHub).

  • Datenqualität: Expectations/Constraints in CI und Produktion.

  • Messaging/Streaming: Kafka/Redpanda mit Schema-Registry.

  • Secrets/KMS: On-Prem-Secret-Store, HSM für Schlüssel, rotationsfähig.

Pipeline-Qualitätssicherung

  • Data Unit Tests: Schemata, Wertebereiche, Nullraten, Fremdschlüssel, Zeitkonsistenz.

  • Integrationstests: Ingestion bis Feature-Generierung; Replay-Szenarien für Edge Cases.

  • Offline-Evaluierung: Backtesting auf Time-Travel-Datasets, Leakage-Checks.

  • Fairness/Compliance-Checks dort, wo Personenbezug möglich ist.

Deployment-Patterns

  • Central vs Edge:

  • Zentrale Dienste für rechenintensive Batch/Asynchrones Scoring.

  • Edge-Inferenz für Latenz-kritische Vision/NLP im Werk; lichtbeständig, Watchdog, Offline-Fähigkeit.

  • Rollout-Strategien:

  • Shadow Mode: Predictions loggen, aber noch nicht steuern.

  • Canary/A-B: Prozentuale Ausspielung, automatische Rollback-Gates.

  • Blue/Green: Vollständige Umschaltung mit schnellem Rückweg.

  • Verpackung: Container mit GPU-Support (NVIDIA Container Toolkit), reproduzierbare Builds; Signierung und Verifikation.

Monitoring und Betriebstauglichkeit

  • Technisch: Latenz, Durchsatz, CPU/GPU-Auslastung, Queue-Längen, Speicherdruck.

  • Daten/Modell:

  • Drift-Metriken (z. B. PSI, Jensen–Shannon) für Features und Embeddings.

  • Performance mit verspätetem Ground Truth (delayed labels), aktive Lernschleifen.

  • LLM-Agenten:

  • Retrieval-Qualität (nDCG, MRR), Halluzinationsscores, Prompt/Tool-Aufrufe, Guardrail-Treffer.

  • Ausfallsichere Tool-Execution (Timeouts, Circuit Breakers), idempotente Aktionen.

On-Prem-GPU-Cluster vs Cloud-Training

Das ist keine Glaubensfrage, sondern eine Optimierung unter harten Nebenbedingungen: Daten-Souveränität, Kostenstruktur, Elastizität, Betriebsfähigkeit.

Wann On-Prem?

  • Daten dürfen das Werk/Unternehmen nicht verlassen (Betriebsgeheimnisse, DSGVO, Exportkontrolle).

  • Dauerhafte Grundlast (kontinuierliches Fine-Tuning, großvolumiges Vision-Training) rechtfertigt CapEx; egress-freie Datenwege.

  • Latenz/Verfügbarkeit: Edge- oder Near-Edge-Training/Finetuning, oder Air-Gap-Umgebungen.

Was es operativ braucht:

  • Hardware:

  • GPU-Klassen passend wählen: Reine Inferenz häufig mit Mittelklasse-GPUs; Training/Fine-Tuning erfordert High-Bandwidth-Memory, NVLink; Partitionierung via MIG möglich.

  • Storage: NVMe-Backends, paralleles Filesystem (z. B. BeeGFS/CEPH) für Durchsatz; dedizierte Trainings- und Feature-Stores entkoppeln.

  • Netzwerk: 100G Ethernet oder InfiniBand je nach Skala; RoCEv2 sauber getuned.

  • Scheduling:

  • Kubernetes mit GPU-Operator für Multi-Tenant-Workloads und ML-Services.

  • Slurm für großskaliges verteiltes Training; oder Hybride: Slurm für Jobs, K8s für Services.

  • Software:

  • Reproduzierbare Toolchains (Container), deterministische Builds; Artefakt-Signing.

  • Lizenzserver offline-fähig; Paketspiegel für Air-Gap-Updates.

  • Sicherheit:

  • Zero-Trust, mTLS end-to-end; zentrale Geheimnisverwaltung; Härtung der Base-Images.

Wann Cloud?

  • Forschung/Exploration mit anonymisierten/synthetischen Daten; kurzfristige Elastizität.

  • Methoden-Exploration (neue Architekturen) ohne vollen On-Prem-Betriebsaufwand.

  • „Bursting“ nur mit vorab-entschärften Datasets und vertraglich nachvollziehbaren EU-Standorten.

Kostenrealität:

  • Kurzfristig ist Cloud-Opex attraktiv für Spikes; langfristig kann On-Prem bei konstanter Last und egress-sensiblen Daten günstiger und souveräner sein.

  • Vermeiden: „Daten gratis rein, teuer raus“ – lock-in durch egress. Architektur so planen, dass Trainingsartefakte nicht in proprietären Formaten gefangen sind.

LLM in der Industrie: RAG vor Fine-Tuning, Governance vor Spielerei

  • Retrieval-Augmented Generation (RAG) schafft schnell Mehrwert: Technische Handbücher, Wartungsberichte, Sicherheitsvorschriften; Embeddings und Vektorsuche On-Prem.
  • Datenpfad:
  • Dokumentenaufnahme mit OCR, Strukturierung, Chunking, PII-Redaktion.
  • Indexierung in einer Vektor-DB On-Prem; Metadaten in Lakehouse-Tabellen.
  • Abfragen nur mit Zugriffspolicies (Row-/Attribute-Level).
  • Fine-Tuning gezielt:
  • Domänenspezifische QA/Tool-Nutzung, LoRA/QLoRA reduziert GPU-Bedarf.
  • Messbare Gains gegenüber gutem RAG notwendig, sonst komplexitätslastig.
  • Governance:
  • Prompt/Completion-Logging mit PII-Filter; Tool-Aufrufe auditierbar.
  • Red-Team-Tests (Prompt-Injektion, Data Exfiltration); Guardrails lokal.

Referenzarchitektur – ein pragmatischer Bauplan

  • Quellen:
  • OPC UA/MQTT aus OT; CDC aus MES/ERP; Dateidrops für Bild/Video; DMS/ShareCrawler für Office/PDF.
  • Ingestion:
  • Edge-Gateways mit lokalen Puffern; sichere Weiterleitung per mTLS nach IT-Zone in Kafka/Objektspeicher.
  • Schema-Validierung und PII-Filter im Ingest.
  • Storage/Lakehouse:
  • S3-kompatibel On-Prem als Rohspeicher; Iceberg/Delta als Tabellenlayer; Tiering für kalte Daten.
  • Verarbeitung:
  • Batch (Spark/Dask/Ray) für Feature-Generierung/Backfills; Streaming (Flink/Kafka Streams) für Online-Features.
  • MLOps:
  • Orchestrierung (Argo/Airflow), ML-Tracking/Registry (MLflow), Feature Store (Feast), Katalog (OpenMetadata).
  • Serving:
  • Zentrale Scoring-Services (REST/gRPC) für nicht-latency-kritische Aufgaben.
  • Edge-Services für Vision/NLP in Zellen, mit lokalem Cache/Model-Store; Watchdog und Offline-Fähigkeit.
  • Sicherheit/Governance:
  • mTLS, SPIFFE-Identitäten; OPA-Policies; zentrale Audit-Logs; Pseudonymisierungsservice; Policy-as-Code-Repos.
  • LLM-Schicht:
  • Dokumenten-Pipeline (OCR, Chunking, PII-Redaktion), Vektor-Index On-Prem; Guardrails; Tool-Proxy mit Circuit Breakers.
  • Betrieb:
  • Observability-Stack (Logs, Metriken, Traces); Model-/Data-Drift-Dashboards; Alarmierung mit SLOs.
  • Change-Management, Release-Trains, Disaster Recovery (Backups, Restore-Tests).

Antipatterns, die wir immer wieder sehen