Von GPU-Engpässen zu Industrial-Scale MLOps: Wie ayedo Sensoriq zur Kubernetes-basierten ML-Plattform geführt hat

Predictive Maintenance klingt nach „ein Modell trainieren und fertig". In der Praxis scheitern viele Projekte nicht am Modell, sondern an dem, was danach kommt: Datenströme, Inferenz-SLAs, reproduzierbare Experimente und eine Infrastruktur, die skaliert, ohne dass jedes neue Kundenprojekt ein neues Betriebsprojekt auslöst.

Sensoriq entwickelt KI-basierte Lösungen für die Fertigungsindustrie. Die Software analysiert Sensordaten in Echtzeit und prognostiziert Ausfälle, bevor sie eintreten. Das Produkt besteht aus Edge-Komponenten an der Maschine, einer Streaming-Pipeline und einer Cloud-Plattform für Training, Inferenz und Visualisierung.

Mehrere Pilotkunden liefen stabil. Der Sprung vom Piloten in den skalierbaren Produktbetrieb scheiterte jedoch an einer Infrastruktur, die historisch gewachsen war – und für das nächste Level nicht ausgelegt war.

Ausgangslage: Ein funktionierendes Produkt, das operativ nicht wachsen konnte

Das Team war stark aufgestellt: Data Scientists, ML Engineers, Backend-Entwickler, Sensorik- und Edge-Spezialisten. Was fehlte, war ein gemeinsamer, reproduzierbarer Maschinenraum für MLOps.

Training lief auf einem Mix aus lokalen Workstations mit NVIDIA-GPUs, einem kleinen On-Prem-Server mit zwei A100-Karten und gelegentlich gebuchten Cloud-GPU-Instanzen bei einem Hyperscaler. Die Streaming-Pipeline war auf manuell verwalteten VMs aufgebaut: Kafka auf drei Maschinen, dazu selbstgeschriebene Python-Consumer. Inferenz-Endpunkte liefen als einzelne Flask-Prozesse auf dedizierten GPU-Servern.

Dieses Setup ist typisch für die frühe Phase: schnell, pragmatisch, produktnah. Es kippt jedoch, sobald mehrere Teams parallel arbeiten, mehrere Kunden onboarden und ein echtes SLA entsteht.

Wo es knirschte: GPU-Engpass, keine Reproduzierbarkeit, fragiles Streaming

Der erste Engpass waren die GPU-Ressourcen. Zwei A100-Karten für zwölf Data Scientists – ohne Scheduling, ohne Quotas, ohne Isolation. Wer zuerst kam, belegte die GPU. Kleine Jobs blockierten große Modelle. Große Trainingsläufe blockierten alles. Es gab keine Möglichkeit, GPU-Kapazität sauber aufzuteilen oder fair zuzuteilen.

Parallel dazu war die Experiment-Reproduzierbarkeit nicht gegeben. Jede Person hatte ihre eigene lokale Umgebung: unterschiedliche CUDA-Versionen, andere Python-Abhängigkeiten, unterschiedliche Framework-Versionen. Ein Modell, das auf einem Notebook lief, ließ sich nicht zuverlässig auf einer anderen Maschine nachstellen. Onboarding wurde zum Setup-Projekt.

Am kritischsten war jedoch die Lücke zwischen Experiment und Produktion. Modelle entstanden in Jupyter Notebooks, wurden anschließend manuell in Skripte übertragen, in Container verpackt und auf GPU-Server deployt. Dieser Übergang dauerte Wochen und war eine dauerhafte Fehlerquelle. Jedes Mal, wenn man ein Notebook „produktisiert", entstehen Abweichungen – und damit Fehler, die erst im Live-Betrieb sichtbar werden.

Die Streaming-Pipeline war ebenfalls ein Risiko. Kafka auf drei VMs ließ sich nicht elastisch skalieren. Wenn ein neuer Kunde mit hunderten Sensoren angebunden wurde, bedeutete Skalierung: VM bestellen, Kafka manuell konfigurieren, Consumer manuell deployen. Das ist kein skalierbarer Prozess, sondern Handarbeit im Produktionsbetrieb.

Und dann die Inferenz: Flask-Prozess, einzelner Server, kein Autoscaling, kein Failover. Wenn ein Prozess abstürzte, fiel die Vorhersage aus, bis jemand manuell eingriff. Für Pilotkunden ist das unschön. Für industrielle SLAs ist es inakzeptabel.

Hinzu kam ein betriebswirtschaftlicher Schmerzpunkt: unkontrollierte Cloud-Kosten. Data Scientists buchten GPU-Instanzen in der Cloud, vergaßen sie nach dem Training abzuschalten, und niemand konnte nachvollziehen, welches Experiment welche Kosten verursacht hatte. Die monatliche Rechnung schwankte massiv.

Der Wendepunkt war ein Großauftrag: Ein Automobilzulieferer wollte über 2.000 Sensoren an drei Standorten gleichzeitig überwachen – mit Echtzeit-Inferenz und einem SLA von unter 500 ms. Mit dem bestehenden Setup war das nicht realistisch umsetzbar.

ayedos Ansatz: Eine Kubernetes-basierte ML-Plattform – durchgängig von Notebook bis Inferenz

Unser Ziel war nicht, einzelne Komponenten zu „modernisieren". Unser Ziel war eine Plattform, die den gesamten ML-Lifecycle abdeckt: interaktive Entwicklung, verteiltes Training, reproduzierbare Experimente, standardisiertes Deployment, skalierbare Streaming-Verarbeitung und observability-first Betrieb.

Die ayedo Managed Kubernetes Plattform wurde dafür zum Backbone – nicht als Buzzword, sondern als deklaratives Betriebsmodell, das Scheduling, Isolation, Automatisierung und Nachvollziehbarkeit zusammenbringt.

GPU-Scheduling und Partitionierung: GPUs als echte Plattformressource

Der größte operative Hebel war die GPU-Verwaltung. Mit dem NVIDIA GPU Operator und NVIDIA MPS (Multi-Process Service) haben wir GPUs als schedulbare Ressourcen im Cluster etabliert – inklusive Partitionierung in kleinere Slices.

Damit bekommt ein experimenteller Notebook-Job nicht „eine ganze GPU", sondern genau den Slice, den er braucht. Gleichzeitig können große Trainingsläufe dedizierte Full-GPU-Zuweisungen erhalten, inklusive Prioritäten und Quotas pro Team/Namespace.

Das ändert die Arbeitsrealität fundamental: Niemand wartet mehr auf „freie GPUs". Niemand blockiert andere durch überdimensionierte Reservierungen. Und die GPU-Auslastung wird planbar und effizient.

JupyterHub als Self-Service: reproduzierbare Notebook-Workspaces in Minuten

Anstatt individueller lokaler Umgebungen arbeitet das Team nun über JupyterHub auf Kubernetes. Jede Person startet per Self-Service eine isolierte Notebook-Umgebung mit definierter CUDA- und Framework-Version, persistentem Storage und konfigurierbarem GPU-Zugriff.

Der entscheidende Punkt ist Reproduzierbarkeit: Containerisierte Notebook-Images schaffen identische Bedingungen – unabhängig davon, wer arbeitet oder wann ein Notebook gestartet wird. Onboarding wird damit von „Tage Setup" zu „Minuten Workspace".

MLflow: Experiment-Tracking und Model Registry als verbindender Layer

Damit der Weg von Experiment zu Produktion nicht mehr von Handarbeit lebt, haben wir MLflow als Experiment-Tracking und Model Registry eingeführt.

Jedes Training protokolliert automatisch Hyperparameter, Metriken, Datenreferenzen und Artefakte. Modelle werden registriert und erhalten einen Lifecycle-Status – von Experiment über Staging bis Production. Damit ist Modellmanagement nachvollziehbar und auditierbar, statt in Notebooks und Ordnerstrukturen zu verschwinden.

KServe: standardisiertes Model Serving mit Canary, Rollback und Autoscaling

Für die Inferenz haben wir KServe als Serving-Layer aufgebaut. Modelle werden als versionierte Artefakte deployt, nicht als „neues Flask-Skript auf einem Server".

KServe ermöglicht Canary-Deployments, A/B-Tests und Rollbacks – mit Health Checks und Autoscaling, das auf Latenz und Last reagieren kann. Genau das ist entscheidend, wenn ein SLA unter 500 ms eingehalten werden muss und Lastprofile schwanken.

Echtzeit-Streaming auf Kubernetes: Kafka mit Strimzi statt VM-Handarbeit

Die Sensor-Streaming-Pipeline wurde auf Kafka mit dem Strimzi Operator migriert. Das ist nicht nur „Kafka in Kubernetes", sondern ein Kubernetes-natives Betriebsmodell: Topics, Partitionen, ACLs und Konfigurationen werden deklarativ verwaltet und über GitOps ausgerollt.

Neue Kunden mit hunderten Sensoren bedeuten damit kein manuelles Serverprojekt mehr, sondern skalierbare Kapazität im Cluster – einschließlich klarer Betriebsprozesse und Observability.

LLM-Serving für Berichte: vLLM produktiv, Ollama fürs Experimentieren

Sensoriq nutzt LLMs, um Anomalien in Klartextberichte zu übersetzen – etwa Handlungsempfehlungen für Wartungsteams. Dafür haben wir vLLM als hochperformanten Inference-Layer produktiv betrieben, inklusive Autoscaling und effizienter GPU-Speicherausnutzung.

Für Entwicklungs- und Testumgebungen wurde Ollama integriert, damit Data Scientists Modelle schnell ausprobieren können, ohne produktive Ressourcen zu belasten. Der wichtige Punkt: Die LLM-Inferenz bleibt self-hosted – Sensordaten verlassen nicht die europäische Infrastruktur.

Observability: ML-Betrieb messbar machen

Ein MLOps-System ohne Observability ist ein Blindflug. Deshalb haben wir VictoriaMetrics, VictoriaLogs, Grafana und Tempo als Full-Stack Observability integriert.

Sensoriq überwacht heute GPU-Auslastung, Inferenz-Latenz, Streaming-Throughput, Fehlerquoten und auch ML-spezifische Signale wie Modell-Drift. Alerting greift, bevor SLA-Verletzungen entstehen – nicht erst, wenn der Kunde sie meldet.

GitOps als Betriebsstandard: ArgoCD und Authentik

ArgoCD verwaltet die gesamte Plattform per GitOps – von Kafka-Konfigurationen über KServe-Deployments bis zu Notebook-Templates. Änderungen sind versioniert, reviewbar und auditierbar.

Authentik bildet die zentrale Identitäts- und Zugriffsschicht: Data Scientists sehen ihre Workspaces und Experimente, Kunden ihre Dashboards, das Ops-Team die Infrastruktur – sauber getrennt, mit einem Login.

Ergebnis: Industrial-Scale Betrieb wird möglich – und planbar

Mit der neuen ML-Plattform hat Sensoriq den Übergang vom Pilotbetrieb zum skalierbaren Industrieprodukt geschafft.

Die GPU-Auslastung stieg signifikant, weil Partitionierung und Scheduling Leerlauf und Blockaden eliminieren. Data Scientists arbeiten parallel, ohne sich gegenseitig zu bremsen.

Der Weg von Experiment zu Produktion wurde standardisiert: Notebook → MLflow Registry → Deployment via ArgoCD/KServe. Was früher Wochen dauerte und fehleranfällig war, passiert heute in Tagen – reproduzierbar.

Der Großauftrag aus der Automotive-Industrie läuft stabil: Echtzeit-Inferenz liegt unter 200 ms bei über 2.000 Sensoren. Autoscaling und GPU-Scheduling halten die SLA-Anforderungen auch bei Lastspitzen.

Kosten sind transparent und planbar. Verbrauch wird pro Team/Namespace erfasst, und der Wildwuchs aus vergessenen Cloud-GPUs ist verschwunden. Insgesamt sanken die Infrastrukturkosten gegenüber dem vorherigen Mix deutlich.

Und nicht zuletzt: Datensouveränität ist gesichert. LLM-Inferenz und Sensordatenverarbeitung laufen vollständig auf europäischer Infrastruktur – ein entscheidendes Verkaufsargument in der Fertigungsindustrie.

Warum dieser Ansatz funktioniert

MLOps scheitert selten am Algorithmus. Es scheitert an fehlender Plattformlogik: keine reproduzierbaren Umgebungen, kein standardisiertes Model Serving, kein Scheduling für GPUs, keine Observability für ML-spezifische Signale.

Kubernetes ist hier nicht „der neue Standard", sondern das Werkzeug, um ML wie Software zu betreiben: deklarativ, versioniert, automatisiert, skalierbar.

Genau das haben wir für Sensoriq umgesetzt – mit einem Plattformmodell, das das Team beschleunigt und den Betrieb industrialisiert.

Call to Action

Wenn eure ML-Teams um GPUs kämpfen, Experimente nicht reproduzierbar sind und der Weg vom Notebook in die Produktion Wochen dauert, dann ist das kein Teamproblem – sondern ein Plattformproblem.

ayedo baut Kubernetes-basierte ML-Plattformen, die GPU-Ressourcen planbar machen, Self-Service für Data Scientists ermöglichen und Inferenz unter SLA-Bedingungen zuverlässig betreiben – inklusive Streaming-Pipelines, Model Registry, Observability und GitOps-Betrieb.

Wenn ihr den Schritt vom Pilotprojekt zum industriellen Maßstab gehen wollt, sprechen wir darüber, wie eure Zielarchitektur aussieht – und wie ihr sie ohne Infrastruktur-Overhead betreibt.