• Konfiguration als Code: Deklarative Manifeste (z. B. YAML) repräsentieren gewünschte Zustände; Edge-Agenten ziehen periodisch signierte Snapshots (Pull statt Push).
  • Containerisierte Workloads: Orchestrierung mit leichtgewichtigen Runtimes (containerd/nerdctl, bei Bedarf K3s). Hard-Real-Time-Tasks verbleiben außerhalb; ML/ETL läuft containerisiert.
  • Canary und Wellen: Prozentuale Rollouts, Hardware- und Standort-Labeling, Rollback anhand Health-Signalen aus der Observability.
  • Content-Addressable Caching: Lokale Registries/Satelliten in Werken; Delta-Updates statt vollständiger Images.
  • Vertrauenskette: Secure Boot, TPM-gestützte Schlüssel, signierte Images, SBOMs für Nachvollziehbarkeit. Remote Attestation vor dem Ausrollen sensibler Modelle.
  • Log- und Metrik-Hygiene: Edge-first Aggregation, downsampled Exporte, strikte Budgetierung von Telemetriebandbreite.

Hybrid-Architektur: Edge-Inferenz, zentrales Training

Der robuste Standard in der Industrie ist Hybrid, aber sauber geschnitten:

  • Am Edge:
  • Feature-Extraktion, Inferenzen, Postprocessing, strikte Rate-Limits für Exporte
  • Vorselektion für Training: Nur Beispiele mit Unsicherheit, Fehlerverdacht, Edge-Kennzeichnung “interessant”
  • OOD- und Drift-Signale: Statistiken über Eingabeverteilungen, Aktivierungen, Score-Histogramme – in aggregierter Form
  • In der Zentrale (on-prem Rechenzentrum, souveräne Private Cloud):
  • Datenannahme mit Prioritätswarteschlangen und rechtssicherem Quarantänepfad
  • Training/Fine-Tuning, Evaluierung, Reproduzierbarkeit (Seed, Environment, DVC/MLflow-ähnliche Artefaktverfolgung)
  • Modellfreigabe mit Governance: signierte Modelle, Kompatibilitäts-Check gegen Edge-Runtime, automatisierte Benchmarks auf Hardware-Profilen
  • Deployment und Betrieb:
  • Shadow-Modus am Edge (Modell n+1 rechnet mit, aber entscheidet nicht), Metrikvergleich gegen n
  • Graduelle Aktivierung nach Freigabekriterien (Qualität, Latenz, Ressourcen)
  • Rollback-Pfade ohne Downtime; Fallback-Modelle lokal vorgehalten

Drift und Qualitätssicherung, ohne Datenabfluss

Qualität muss man messen – auch wenn Daten das Werk nicht verlassen. Drei praktikable Bausteine:

  • Referenzfenster: Edge hält rollierende Fenstermetriken (z. B. Verteilungs-Momente, Kullback-Leibler-ähnliche Divergenzen) und sendet nur Kennzahlen, nicht Rohdaten.
  • Unschärfeschwellen: Autoadaptive Confidence-Thresholds mit Hysterese; Edge zählt “Unsicherheiten pro Stunde” als Signal.
  • Periodische Golden-Batches on-site: Kuratierte, freigegebene Stichproben werden intern manuell oder semi-automatisch gelabelt; dienen als lokaler QS-Standard und bleiben im Perimeter.

Referenzarchitektur aus Projekterfahrung

Aus der Kombination von Pilotentrainings-Cloud und Bahn-Fleet-Intelligence hat sich folgende mehrschichtige Architektur bewährt:

  • Gerätelayer
  • Kameras, Sensoren, SPS/PLC
  • Härtung: Netzsegmentierung, nur ausgehende Verbindungen zu Edge-Brokern, kein direkter Inbound
  • Edge-Runtime
  • Leichtgewichtiges OS, Secure Boot, TPM
  • Containerisierte ML-Inferenz, Vorverarbeitung, Protokoll-Gateways (MQTT/OPC UA)
  • Lokaler Broker, lokaler persistent Log, Warteschlangen für Exporte
  • Policy-Enforcement: Ressourcenlimits, Priorisierung, Safeguards für Aktorik
  • Standort-Datenschicht
  • Site-Registry/Cache für Images und Modelle
  • Konfigurations-Snapshots signiert; Canary-Gruppen per Label
  • Eventuelle Mini-Kafka/Filesystem-Buffer für hochvolumige Rohdaten
  • Zentrale Plattform (on-prem/Private Cloud)
  • Kafka-Backbone mit Schema-Registry für Events
  • Feature-Store, Artefakt-Repository, Trainings-Cluster
  • Observability: Tracing, Metriken, Log-Indizes – alles eigentümergeführt
  • Governance: Freigabe-Workflows, Audit-Protokolle, Versionskatalog
  • Schnittstellen nach außen
  • Falls überhaupt: streng kontrollierte, pseudonymisierte Reports in Drittsysteme
  • Kein direkter Zugriff Dritter auf Edge-Runtimes oder zentrale Produktiv-Datenpfade

LLM-Agenten in der Industrie: Observability und Richtlinien on-prem

Sobald Automatisierungen per LLM-Agenten in die Nähe von Fertigungsdaten, Instandhaltungsplänen oder Betriebsanweisungen kommen, gelten dieselben Prinzipien:

  • Vollständige Protokollierung der Agentenläufe, inklusive Tool-Calls, Eingaben/Ausgaben, Policy-Entscheidungen – aber innerhalb Ihres Perimeters.
  • Durchsetzbare Policies (z. B. welche Datenklassen dürfen in Prompts, welche Aktionen sind genehmigungspflichtig).
  • Reproduzierbarkeit: deterministische Seeds dort, wo möglich; Versionierung von Prompt-Templates und Tool-Schnittstellen.
  • Kein Abfluss in US-zentrierte Public-APIs, wenn die Datenklassifikation das verbietet. Lokale oder europäisch souveräne Laufzeiten, Inferenz-Server und Vektorspeicher.

Kosten und Komplexität ehrlich rechnen

Edge/On-Prem ist kein “kostenloses Sicherheitsgefühl”. Es braucht Kompetenzen: Hardware-Lebenszyklen, Patch-Management offline, Observability in fragmentierten Netzen, Root-Cause-Analysen ohne vollständige Rohdaten in der Cloud. In der Gesamtrechnung relativieren sich jedoch vermeintliche Cloud-Vorteile:

  • Netzwerk-Egress und Latenzkosten vs. lokale GPU-Zyklen
  • Vendor-Lock-in-Risiken vs. eigene Betriebsfähigkeit
  • Audits, Zertifizierungen, forensische Anforderungen – leichter, wenn alle kritischen Pfade in der eigenen Domäne liegen

Checkliste für Architekten: zehn Fragen vor der ersten Zeile Code

1) Maximal erlaubte Latenz vom Sensor bis zur Aktion?
2) Verpflichtende Offline-Betriebsdauer ohne WAN?
3) Datenklassen, die den Standort nicht verlassen dürfen?
4) Wer besitzt die Schlüssel für Laufzeit, Registry, Artefakte?
5) Wie erfolgt Zertifikatsrotation ohne Internet?
6) Welche Metriken belegen Modellqualität am Rand, ohne Rohdatenexport?
7) Wie wird ein Notfall-Rollback durchgeführt – auch bei Netzpartition?
8) Welche Protokolle sprechen Ihre SPS/PLCs heute? Wie sieht die Migrationsbrücke aus?
9) Wie wird Drift erkannt, gemeldet und bearbeitet?
10) Wie sieht Ihr Vendor-Exit konkret aus – Test einmal jährlich durchführen?

Konkrete Umsetzungstipps aus der Praxis

  • Zero-Copy-Pfade: Vermeiden Sie unnötige (De-)Serialisierung. Setzen Sie Shared-Memory/GPUDirect dort ein, wo Kamera → Vorverarbeitung → Inferenz eng gekoppelt sind.
  • Ressourcenlimitierung: Per cgroups/containers CPU/GPU/IO hart deckeln, damit Nebenjobs die Latenzpfade nie stören.
  • Determinismus im Build: Reproduzierbare Container (pinned Base-Images, Lockfiles), damit ein Audit gleiche Bits erneut bauen kann.
  • Telemetrie mit Budget: Legen Sie ein Byte- und CPU-Budget pro Edge-Knoten für Logs/Metriken fest. Alles darüber wird gedrosselt oder verworfen – bewusst statt zufällig.
  • Ein Artefakt, mehrere Targets: Optimieren Sie Modelle per Toolchain für die Zielhardware (INT8, TensorRT/ONNX Runtime/OpenVINO), aber halten Sie eine kanonische, signierte Ursprungsversion vor.

Wann Cloud explizit sinnvoll ist