Model Serving: Definition und Abgrenzung im ML-Stack

Model Serving bezeichnet das Bereitstellen eines trainierten KI-Modells als aufrufbare Programmier-Schnittstelle (API-Endpunkt), sodass andere Anwendungen es über das Netzwerk anfragen können. Eine Serving-Plattform übernimmt dabei den Betrieb. Sie skaliert die Rechenleistung mit dem Anfrage-Volumen (Autoscaling), verteilt Anfragen (Traffic-Routing), verwaltet Modell-Versionen und überwacht den Endpunkt. Typische Ausprägungen sind Echtzeit-Endpunkte für einzelne, sofortige Vorhersagen und Batch-Endpunkte für geplante Läufe über größere Datenmengen.

Was ist Model Serving?

Ein trainiertes Modell (klassisches Machine-Learning-Modell, Deep-Learning-Modell oder Large Language Model, also großes Sprachmodell) wird in einer Model Registry (Versions-Verzeichnis für Modell-Dateien) abgelegt und über eine Serving-Plattform als Programmier-Schnittstelle veröffentlicht. Eine aufrufende Anwendung (Client) schickt eine Anfrage mit den Eingabedaten (Merkmale für ein ML-Modell, Prompt für ein Sprachmodell); die Plattform lädt das Modell in eine isolierte Ausführungsumgebung (Container), berechnet die Vorhersage und liefert das Ergebnis zurück. Die Plattform kapselt Modell-Laden, Skalierung, Rechtekontrolle und Metriken.

Der Begriff hat sich als eigene Kategorie etabliert, weil ein direkter Aufruf des Modells aus einem Notebook oder Trainings-Framework die Betriebsanforderungen einer produktiven Anwendung nicht abdeckt. Die Serving-Schicht löst genau diese Aufgaben: Autoscaling nach Anfrage-Volumen (einschließlich Scale-to-Zero für kalte Endpunkte), Blue-Green- und Canary-Deployments für Modellwechsel, Zugriffskontrolle über Token oder SSO, Rate-Limiting, Latenz- und Fehlerraten pro Endpunkt, Drift-Erkennung auf Ein- und Ausgangsdaten sowie Nachvollziehbarkeit, welche Modellversion welche Anfrage beantwortet hat.

Verbreitete Plattformen decken diese Aufgaben mit unterschiedlicher Tiefe ab: [Databricks Model Serving](https://docs.databricks.com/en/machine-learning/model-serving/index.html) integriert Real-Time-Endpunkte mit der MLflow-Registry auf der Data-Intelligence-Plattform. Amazon SageMaker Endpoints, Azure Machine Learning Managed Online Endpoints und Google Vertex AI Prediction bilden die hyperscaler-nativen Angebote ab. Im Open-Source-Umfeld sind [KServe](https://kserve.github.io/website/) (Kubernetes-nativ, CNCF-Standard), [Ray Serve](https://docs.ray.io/en/latest/serve/index.html) (framework-agnostisch, Python-nativ) und [NVIDIA Triton Inference Server](https://docs.nvidia.com/deeplearning/triton-inference-server/) (multi-framework, GPU-optimiert) etabliert; Seldon Core und BentoML besetzen daneben spezialisierte Nischen.

Betrieblich wird zwischen zwei Formen unterschieden. Real-Time-Serving liefert synchrone Vorhersagen pro Anfrage mit Latenz-SLA im Millisekunden- bis Sekundenbereich. Batch-Serving verarbeitet endliche Datensätze in geplanten Läufen ohne wartenden Aufrufer. Manche Plattformen bieten zusätzlich Streaming-Endpunkte für kontinuierliche Ereignisströme. Bei Large Language Models sitzt eine spezialisierte Inference Engine wie [vLLM](https://docs.vllm.ai/), TensorRT-LLM oder TGI unter der Serving-Schicht: Die Serving-Plattform übernimmt Endpunkt-Verwaltung, Autoscaling und Traffic-Routing, die Engine erledigt Batching, KV-Cache und Token-Streaming. Ergänzend kommen bei LLMs Kostenaggregation pro Token, Model Routing zwischen mehreren Modellen und ein vorgelagertes LLM Gateway für Governance hinzu.

Abgrenzung: Inference Engine, Model Routing, Batch, Registry, MLOps

Der Begriff wird häufig mit Nachbarbausteinen im ML-Stack vermischt. Die wichtigsten Abgrenzungen:

Nachbar-Begriff	Verhältnis zu Model Serving
Inference Engine	Laufzeit-Software direkt darunter (vLLM, TensorRT-LLM, TGI). Führt den Modell-Vorwärtslauf aus, optimiert Batching und Speicher. Die Serving-Plattform ruft die Engine als Backend auf.
Model Routing	Verteilt Anfragen über mehrere Modelle hinter demselben logischen Endpunkt nach Kosten, Latenz oder Qualität. Serving stellt den Endpunkt bereit, Routing entscheidet, welches Modell die Anfrage beantwortet.
Batch-Inferenz	Betriebsform ohne wartenden Aufrufer, arbeitet auf endlichen Datensätzen ohne Latenz-SLA. Real-Time-Serving hinter einem Endpunkt ist die andere Betriebsform.
Model Registry (MLflow, SageMaker Model Registry)	Verwaltet Modell-Artefakte, Metadaten, Versionen und Genehmigungs-Stufen. Die Serving-Plattform greift auf die Registry zu, um eine Version zu laden. Registry und Serving sind getrennte Bausteine.
MLOps / LLMOps	Übergreifende Betriebsdisziplinen, die Model Serving einschließen. Sie umfassen zusätzlich Training-Pipelines, Feature-Store, Registry, Monitoring und Governance. Model Serving ist der Baustein, MLOps die Disziplin darum herum.

Beispiel: Empfehlungsmodell mit Canary-Deployment und LLM-Chat-Dienst

Ein Empfehlungsmodell für Produktvorschläge wird nach dem Training in der MLflow Registry als neue Version registriert und über Databricks Model Serving als Real-Time-Endpunkt bereitgestellt. Die Serving-Plattform lädt die Modellversion, exponiert einen HTTPS-Endpunkt mit Token-Authentifizierung, skaliert die Container automatisch mit dem Traffic und protokolliert Anfrage-Latenz und Fehlerraten. Für den Rollout einer neuen Version übernimmt sie zehn Prozent des Traffics als Canary-Deployment, die restlichen neunzig Prozent laufen weiter auf der Vorgängerversion; nach Freigabe wird der Split auf hundert Prozent erhöht.

Für einen LLM-Chat-Dienst desselben Unternehmens sitzt vLLM als Inference Engine unter derselben Serving-Schicht. Ein LLM Gateway davor übernimmt Rate-Limiting und Kostenumlage, ein Model-Routing-Layer entscheidet pro Anfrage zwischen einem großen und einem kleinen Modell nach Prompt-Komplexität. Die Serving-Plattform bleibt in beiden Fällen die gleiche Deployment-Schicht; die Details darunter (Inference Engine, Routing, Gateway) und darüber (Client-Integration, Feature-Store) ändern sich je Anwendungsfall.