Model Serving
Konzept und Praktiken zur Bereitstellung trainierter Machine‑Learning‑Modelle für Produktionsanfragen mit Fokus auf Skalierbarkeit, Versionierung und Observability.
Klassifikation
- KomplexitätMittel
- AuswirkungTechnisch
- EntscheidungstypArchitektur
- OrganisationsreifeFortgeschritten
Technischer Kontext
Prinzipien & Ziele
Use Cases & Szenarien
Kompromisse
- Stillgelegte Modelle verursachen stille Ausfälle bei API‑Clients
- Nicht überwachte Modellregressionen im Live‑Traffic
- Sicherheitsrisiken durch unsichere Modellartefakte oder Abhängigkeiten
- Klar definierte API‑Contracts und Versionierung
- Automatisierte Canary‑Releases mit Monitoring
- Use‑Case‑angepasste Ressourcenprofile und Caching
I/O & Ressourcen
- Trainiertes Modellartefakt (z. B. SavedModel, ONNX)
- Payload‑Schema und API‑Contract
- Ressourcenprofile und SLA‑Ziele
- Produktive Vorhersage‑API mit Versionierung
- Monitoring‑Metriken, Logs und Traces
- Deployment‑Audit und Reproduktionsartefakte
Beschreibung
Model Serving beschreibt Verfahren und Infrastruktur, mit denen trainierte Machine‑Learning‑Modelle in Produktionsumgebungen bereitgestellt, skaliert und für Anfragen verfügbar gemacht werden. Es umfasst Serving‑APIs, Modellversionierung, Ressourcenmanagement, Routing und Monitoring. Typische Implementierungen nutzen Model‑Servers, Inference‑Runtimes und Orchestrierungslösungen.
✔Vorteile
- Schnelle, skalierbare Bereitstellung von Vorhersagen
- Klare Trennung von Verantwortlichkeiten im ML‑Lifecycle
- Bessere Observability und Fehlererkennung im Produktivbetrieb
✖Limitationen
- Erhöhter infrastruktureller Aufwand und Betriebskosten
- Komplexität bei Modellkompatibilität und Serialisierung
- Latenzbegrenzungen bei sehr ressourcenintensiven Modellen
Trade-offs
Metriken
- P99‑Latenz
95./99. Perzentil der Antwortzeiten zur Messung von Worst‑Case‑Latenz.
- Durchsatz (Requests pro Sekunde)
Anzahl erfolgreich bedienter Inferenzanfragen pro Zeiteinheit.
- Fehlerrate
Anteil fehlerhafter oder fehlgeschlagener Anfragen am Gesamttraffic.
Beispiele & Implementierungen
TensorFlow Serving für Bildklassifikation
Einsatz von TensorFlow Serving zur Bereitstellung und Versionierung eines CNN‑Modells mit gRPC‑API.
KServe in Kubernetes für A/B‑Tests
KServe nutzt Knative/Ingress‑Routing für Canary‑Rollouts und Traffic‑Splits.
Batch‑Inference mit Spark und ONNX
Skalierte Offline‑Vorhersagen mit ONNX‑Runtime als Spark‑Job für Reporting.
Implementierungsschritte
Modell validieren, serialisieren und in Registry eintragen
Serving‑Image erstellen und als Version bereitstellen
Routing, Autoscaling und Observability konfigurieren
⚠️ Technische Schulden & Engpässe
Tech Debt
- Legacy‑Modelle ohne registrierte Metadaten
- Ad‑hoc‑Serving‑Scripts statt standardisierter Images
- Fehlende automatisierte Rollback‑Mechanismen
Bekannte Engpässe
Beispiele für Missbrauch
- Live‑Änderungen am Modell ohne Tests im Staging
- Bereitstellung hoher Ressourcen für seltene Batchjobs
- Ignorieren von Drift‑Monitoring nach Deployment
Typische Fallen
- Unterschätzen von Serialisierungsincompatibilities
- Fehlende Absicherung gegen fehlerhafte Modellinputs
- Ungenügende Canaries vor Vollausrollung
Erforderliche Fähigkeiten
Drivers (Architectural Drivers)
Constraints
- • Kompatibilität zwischen Modellformaten
- • Datenschutz‑ und Compliance‑Vorgaben
- • Beschränkte Hardware (z. B. keine GPUs verfügbar)