Inferenz unter Druck: Wie man industrielle SLAs von < 500 ms garantiert

In einem Pilotprojekt verzeiht man einer KI vieles. Wenn die Vorhersage einer Anomalie mal zwei Sekunden dauert, ist das kein Weltuntergang. Doch in der industriellen Fertigung - etwa bei der Überwachung von Hochgeschwindigkeits-Pressen oder Roboterarmen - ist Zeit kein relativer Begriff, sondern ein harter Vertragsparameter (SLA).

Wenn eine Sensor-Analyse-Software verspricht, Ausfälle innerhalb von 500 ms zu prognostizieren, darf die Infrastruktur nicht zum Flaschenhals werden. Ein einfacher Python-Prozess auf einem Server reicht hier nicht mehr aus. Wir brauchen eine Architektur, die auf Lastspitzen reagiert, bevor der Nutzer sie bemerkt.

Die Hürden: Warum Inferenz in Produktion schwierig ist

Im Gegensatz zu klassischen Web-Apps verbraucht KI-Inferenz massiv Ressourcen (GPU/RAM) in sehr kurzer Zeit. Drei Probleme treten dabei oft auf:

1. Kaltstart-Probleme: Wenn ein neues Modell geladen werden muss, dauert das oft Sekunden - Zeit, die im SLA nicht vorgesehen ist.
2. Unvorhersehbare Last: Wenn plötzlich 500 Sensoren gleichzeitig Daten senden, steigt die Warteschlange. Ohne Autoscaling explodiert die Latenz.
3. Update-Risiko: Ein neues, „besseres" Modell könnte in der echten Welt langsamer reagieren als im Testlabor. Ein „Big Bang Rollout" gefährdet dann den gesamten Betrieb.

Die Lösung: Cloud-Native Model Serving mit KServe

Um diese Herausforderungen zu meistern, setzen wir auf einen spezialisierten Serving-Layer innerhalb von Kubernetes.

1. Autoscaling basierend auf Latenz (nicht nur CPU)

Klassisches Autoscaling schaut auf die CPU-Auslastung. Bei KI-Inferenz ist das trügerisch, da die GPU oft der begrenzende Faktor ist. Wir konfigurieren das System so, dass es auf die Anzahl der parallelen Anfragen oder die Antwortzeit (p99 Latenz) reagiert. Bevor die Latenz die 500-ms-Marke reißt, schaltet Kubernetes automatisch weitere Inferenz-Pods hinzu.

2. Canary-Deployments und Traffic-Splitting

Wir rollen Modelle niemals für alle Kunden gleichzeitig aus. Mit Tools wie Istio oder Argo Rollouts führen wir ein neues Modell zunächst als „Canary" ein:

• 5 % des Traffics gehen an das neue Modell.
• Das Monitoring prüft permanent die Latenz und die Fehlerrate.
• Erst wenn alle Metriken im grünen Bereich sind, wird der Traffic schrittweise auf 100 % erhöht.
• Bei Problemen erfolgt ein automatischer Rollback in Millisekunden.

3. GPU-Optimierte Laufzeiten (vLLM & TensorRT)

Um das Maximum aus der Hardware herauszuholen, nutzen wir spezialisierte Inferenz-Engines wie vLLM oder NVIDIA TensorRT. Diese sind darauf optimiert, Anfragen zu bündeln (Batching) und den Grafikspeicher so effizient zu nutzen, dass die reine Rechenzeit pro Inferenz oft unter 50 ms liegt.

Fazit: Stabilität ist ein Feature

Bei einem Kunden konnten wir durch diesen Ansatz die Inferenz-Latenz stabil unter 200 ms halten - selbst bei Lastspitzen von über 2.000 Sensoren. Der Schlüssel liegt darin, das Modell nicht als isoliertes Skript zu betrachten, sondern als Teil einer elastischen, überwachten Plattform.

Industrielle KI braucht industriellen Betrieb. Nur wer seine Latenz im Griff hat, gewinnt das Vertrauen der Kunden in der Fertigungsindustrie.

FAQ

Was bedeutet „p99 Latenz" im Kontext von KI-Inferenz? Die p99 Latenz besagt, dass 99 % aller Anfragen schneller als ein bestimmter Wert (z. B. 500 ms) beantwortet werden. Dies ist eine viel wichtigere Kennzahl als der Durchschnitt, da Ausreißer in der Industrie oft zu Produktionsstopps führen können.

Wie verhindert man, dass ein Modell-Update die Produktion stoppt? Durch Canary-Deployments. Hierbei wird das neue Modell parallel zum alten betrieben. Nur ein minimaler Teil der Anfragen wird an das neue Modell geleitet. Bei Fehlern wird der Traffic sofort wieder auf das alte, bewährte Modell umgeleitet.

Kann ich Inferenz-Kosten sparen, wenn gerade keine Daten fließen? Ja, durch Scale-to-Zero (z. B. mit Knative). Wenn keine Anfragen eingehen, werden die Inferenz-Pods komplett heruntergefahren. Bei der ersten neuen Anfrage starten sie automatisch wieder. Dies erfordert jedoch optimierte Ladezeiten für das Modell, um den „Kaltstart" kurzzuhalten.

Welche Rolle spielt die GPU beim Model Serving? Die GPU beschleunigt die mathematischen Berechnungen (Matrizen-Multiplikation) massiv. Während eine CPU für eine Inferenz vielleicht 800 ms braucht, schafft eine optimierte GPU-Laufzeit dasselbe in 30 ms. Dies ist entscheidend für das Einhalten strenger SLAs.

Wie unterstützt ayedo beim Erreichen von Inferenz-SLAs? Wir bauen die gesamte Infrastruktur-Pipeline auf: vom schnellen NVMe-Storage für das Laden der Modelle über das GPU-Scheduling bis hin zum Latenz-basierten Autoscaling und Monitoring. Wir sorgen dafür, dass Ihr System auch unter Volllast performant bleibt.