Model Serving: Die Runtime-Schicht, die ML in der Produktion am Laufen hält

Beim produktiven maschinellen Lernen ist das Modell oft der kleinste Teil des Systems. Die Forscher David Sculley et al. haben dies in ihrem Papier Hidden Technical Debt in Machine Learning Systems dargelegt und argumentiert, dass nur ein kleiner Bruchteil vieler realer ML-Systeme dem Lernen oder der Vorhersage gewidmet ist. Der Rest ist das umgebende Produktionssystem: Datenerfassung, Feature-Extraktion, Verifizierung, Konfiguration, Monitoring, Ressourcenmanagement, Prozessmanagement, Serving-Infrastruktur und der Glue-Code, der die Komponenten miteinander verbindet. In ausgereiften Systemen, so stellten die Autoren fest, kann sich das Gleichgewicht auf bis zu 5 % Code für maschinelles Lernen und 95 % unterstützenden Systemcode verschieben.

Model Serving ist direkt in diese Produktionsarchitektur integriert. Es ist nicht nur der Akt, ein Modell über einen Endpunkt bereitzustellen. Es ist die Runtime-Schicht, die Vorhersagen über Online-Inferenz, Batch-Scoring und Streaming-Workflows hinweg verfügbar, zuverlässig und kontrolliert hält. In der Praxis muss das Serving auch Routing, Latenz, Skalierung, Versionierung, Feature-Konsistenz und Governance verwalten – die operativen Aspekte, die bestimmen, ob ein Modell Produktionsentscheidungen zuverlässig unterstützen kann.

Ohne die richtige Serving-Architektur können Modellbereitstellungen anfangen, benutzerdefinierte Infrastruktur anzuhäufen. Techniker:innen verwalten separate Endpunkte, Feature-Pipelines, Registries, Anmeldeinformationen, Monitoring-Systeme und Rechenressourcen-Umgebungen. Im Laufe der Zeit wird der Serving-Pfad zu einem weiteren Ort, an dem ML-Systeme operative Schulden anhäufen.

Model Serving ist die Runtime-Schicht, die ein trainiertes Modell für die Inferenz in der Produktion verfügbar macht. Sie empfängt Produktionsdaten, sendet diese Daten an die richtige Modellversion und gibt die resultierende Vorhersage an eine Anwendung, einen Workflow oder ein nachgelagertes System zurück.

Ein bereitgestelltes Modell ohne zuverlässigen Serving-Pfad hinterlässt einem Team ungelöste Produktionsfragen: Wie erreichen Anfragen das Modell? Was passiert bei Nachfragespitzen? Welche Version sollte den Produktions-Traffic erhalten? Wie führt das System ein Rollback durch, wenn ein Challenger-Modell nicht die erwartete Leistung erbringt? Wo befindet sich die Feature-Logik und ist sie zwischen Training und Inferenz konsistent?

Das Ziel von Model Serving ist es, diese Fragen zu beantworten – ein trainiertes Modell in der Produktion nutzbar zu machen. Zu diesem Zweck übernimmt die Serving-Schicht die operative Arbeit rund um die Inferenz: Weiterleitung von Anfragen an die richtige Modellversion, Skalierung der Kapazität an die Nachfrage, Rückgabe von Vorhersagen innerhalb der Latenzanforderungen und Verbindung des Modells mit den Daten und der Feature-Logik, die es zur Laufzeit benötigt.

Bei Produktionssystemen muss die Serving-Schicht auch Latenz-SLAs, Durchsatzziele und Laufzeiteffizienz berücksichtigen. Das kann bedeuten, Kaltstartzeiten zu reduzieren, damit ein Modell nach einer Zeit der Inaktivität schnell reagieren kann, warme Pools von Rechenressourcen für hochpriorisierte Workloads verfügbar zu halten oder Multi-Model-Serving zu unterstützen, wenn sich mehrere Modelle oder Versionen dieselbe Infrastruktur teilen.

Modellbereitstellung und Model Serving sind eng miteinander verbunden, beschreiben aber unterschiedliche Teile des Produktionslebenszyklus.

• Modellbereitstellung ist der Akt, ein trainiertes Modell in eine Produktionsumgebung zu überführen. Dies kann das Paketieren des Modells, dessen Registrierung, die Freigabe zur Veröffentlichung und die Bereitstellung für eine Anwendung oder einen Scoring-Workflow umfassen.
• Model Serving ist die Runtime-Infrastruktur, die das Modell nach der Bereitstellung verfügbar hält.

In diesem Sinne ist die Bereitstellung ein Übergang. Serving ist das darauf folgende Betriebsmodell.

Der richtige Serving-Modus hängt davon ab, wie Vorhersagen konsumiert werden. Einige Workloads benötigen Antworten mit geringer Latenz für einzelne Anfragen. Andere benötigen High-Throughput-Scoring über große Datasets hinweg. In einigen Anwendungen konsumiert die Serving-Schicht einen kontinuierlichen Stream von Ereignissen; in anderen läuft das Modell auf einem Gerät oder am Netzwerkrand.

Online-Inferenz ist der Modus, der am häufigsten mit einem Modell-Endpunkt in Verbindung gebracht wird. Eine Anwendung sendet eine Anfrage, normalerweise über REST oder gRPC, und das Modell gibt eine Vorhersage schnell genug für die Nutzer:innen oder das System zurück, die auf die Antwort warten. Betrugserkennung, Empfehlungen, Personalisierung und Such-Ranking verwenden dieses Muster häufig, da die Vorhersage eine unmittelbare Entscheidung beeinflusst.

Batch-Scoring funktioniert anders. Anstatt auf eine Anfrage nach der anderen zu antworten, führt das Modell die Inferenz nach einem Zeitplan über ein Dataset aus. Beispielsweise könnte ein Modell zur Kundenabwanderung jede Nacht Konten bewerten oder ein Modell zur Nachfrageprognose jeden Morgen die Projektionen aktualisieren. Da keine Nutzer:innen auf eine Antwort warten, sind Durchsatz und Kosteneffizienz in der Regel wichtiger als Latenzen im Subsekundenbereich.

Bei der Streaming-Inferenz konsumiert das Modell Ereignisse aus einem Stream und gibt Vorhersagen zurück, sobald neue Daten eintreffen. Ein IoT-Anomalieerkennungsmodell könnte beispielsweise Sensormesswerte bei ihrem Eintreffen auswerten, anstatt auf einen nächtlichen Batch-Job zu warten.

Die Edge-Bereitstellung rückt das Modell näher an die Quelle der Aktivität. Wenn ein Gerät offline arbeiten muss, Round-Trip-Latenzen vermieden werden sollen oder Daten lokal gehalten werden müssen, ist das Serving von einem zentralisierten Endpunkt aus ungeeignet. In diesen Fällen läuft das Modell auf dem Gerät oder am Netzwerkrand, mit einem separaten Prozess für Paketierung, Verteilung, Updates und Monitoring.

Diese Modi existieren oft nebeneinander. Ein Unternehmen könnte Batch-Scoring für eine breite Kundensegmentierung, Online-Inferenz für Echtzeit-Angebote und Streaming-Inferenz für operative Warnungen verwenden. Die Wahl der Serving-Architektur ist wichtig, da jede eine andere Mischung aus Latenz-, Rechenressourcen-, Governance- und operativen Anforderungen mit sich bringt.

Eines der schwierigsten Serving-Probleme beginnt, bevor das Modell jemals Produktions-Traffic sieht. Training-Serving Skew tritt auf, wenn sich die während des Trainings verwendete Feature-Logik von der während der Inferenz angewendeten Logik unterscheidet. Das Modell wurde mit einer Darstellung der Daten evaluiert und dann mit einer anderen bereitgestellt. Der Endpunkt reagiert weiterhin so, als würde das Modell dieselbe Art von Daten erhalten, die es während des Trainings gesehen hat. Die Vorhersage wird jedoch aus Eingaben getroffen, für deren Verständnis das Modell nie trainiert wurde.

Googles Regeln für maschinelles Lernen identifiziert Training-Serving Skew als echtes Produktionsproblem, einschließlich Diskrepanzen zwischen Trainings- und Serving-Pipelines, Datenänderungen zwischen Training und Serving sowie Feedbackschleifen, die durch das System selbst eingeführt werden. Die Vorgabe ist unmissverständlich: Messen Sie den Skew, damit System- und Datenänderungen ihn nicht unbemerkt einführen.

In vielen Stacks ist die Ursache architektonischer Natur. Das Training nutzt oft eine Batch-Pipeline, während das Serving oft eine Echtzeit-Pipeline verwendet. Unterschiedliche Teams warten sie, und unterschiedlicher Code drückt die Feature-Transformationen aus. Im Laufe der Zeit führen selbst kleine Änderungen zu einem Drift zwischen der Offline-Modellentwicklungsumgebung und dem Online-Inferenzpfad.

Ein Feature Store behebt diese Trennung, indem er die Feature-Logik für Training und Inferenz wiederverwendbar macht. Anstatt eine Version eines Features in einer Trainings-Pipeline und eine andere in einer Serving-Anwendung zu definieren, definieren Teams das Feature einmal und verwenden es in beiden Kontexten.

Für das Model Serving ist dies mehr als nur ein Data Engineering-Thema. Die Feature-Konsistenz bestimmt, ob die Serving-Schicht Vorhersagen von dem Modell zurückgibt, das das Team evaluiert hat – oder von einer zufälligen Variation, die durch die Produktions-Pipeline erstellt wurde.

Sobald ein Modell für die Produktion bereit ist, muss die Serving-Schicht wissen, welche Version verwendet werden soll, woher sie stammt und unter welchen Bedingungen sie hochgestuft oder zurückgesetzt werden soll.

Eine Modell-Registry bietet diesen Kontrollpunkt. Sie speichert trainierte Modellartefakte zusammen mit Versionsverlauf, Evaluierungsmetriken, Bereitstellungsstatus und Lineage. Anstatt Modelle als in die Produktion kopierte Dateien zu behandeln, behandelt die Registry sie als kontrollierte Assets mit definierten Lebenszyklusstatus.

Dieser Unterschied ist wichtig, wenn mehr als eine Version aktiv ist oder für ein Release infrage kommt. Ein Modell kann als registriert beginnen, nach der Validierung in die Staging-Phase übergehen und erst dann in die Produktion aufsteigen, wenn es Schwellenwerte für Genauigkeit, Latenz, Fairness oder Kosten erfüllt. Diese Promotion-Gates machen die Bereitstellung weniger abhängig von manuellen Übergaben und mehr abhängig von Richtlinien.

Lineage fügt eine weitere Kontrollebene hinzu. Für eine bereitgestellte Modellversion sollte die Registry anzeigen, welche Trainingsdaten, welcher Code, welche Parameter und welche Evaluierungsergebnisse sie hervorgebracht haben. Wenn sich die Performance verschiebt, eine Audit-Anfrage eintrifft oder ein Rollback erforderlich wird, wird dieser Verlauf operativ nützlich und nicht nur administrativ.

Die Registry unterstützt auch Champion-Challenger-Serving-Muster. Ein Produktionsmodell kann weiterhin den Großteil des Traffics verarbeiten, während ein Challenger-Modell einen kleineren Anteil erhält. Wenn der Challenger eine bessere Leistung erbringt, kann sich der Traffic verlagern. Wenn die Leistung schlechter ist, ist ein Rollback unkompliziert, da die Serving-Schicht mit der Versionierung und dem Bereitstellungsstatus verbunden ist.

Large Language Models (LLMs) bringen andere Serving-Einschränkungen mit sich. Die Grundidee ist immer noch Inferenz: Das Modell empfängt Eingaben und gibt Ausgaben zurück. Die Laufzeitmechanik unterscheidet sich jedoch in wichtigen Punkten vom traditionellen ML-Serving.

Eine LLM-Serving-Schicht muss Token-Durchsatz, Kontextlänge, GPU-Speicher, Batching-Strategien, KV-Cache-Management und Decodierungsverhalten berücksichtigen. In hochvolumigen Anwendungen hängt die Performance davon ab, wie effizient das System Anfragen plant und Berechnungen wiederverwendet. Techniken wie spekulative Decodierung, kontinuierliches Batching und Modellquantisierung existieren, weil die Bereitstellung großer Modelle bei nutzbarer Latenz und Kosten ebenso ein Systemproblem wie ein Modellierungsproblem ist.

Neuere LLM-Serving-Stacks konzentrieren sich zunehmend auf die Inferenz-Optimierung: wie man GPU-Speicher effizient nutzt, Anfragen plant, zwischengespeicherte Berechnungen wiederverwendet und den Durchsatz verbessert, ohne Latenz oder Kosten über die Produktionsgrenzen hinaus zu treiben.

Prompt-Versionierung wird ebenfalls Teil der Serving-Disziplin. Im traditionellen ML bedeutet die Änderung des Modellverhaltens in der Regel erneutes Training, Fein-Anpassung oder den Austausch von Modellversionen. In LLM-Anwendungen kann eine Prompt-Änderung das Verhalten ändern, ohne die Modellgewichte zu verändern. Prompts, Systemanweisungen und Retrieval-Vorlagen benötigen daher Versionierungs-, Test- und Rollback-Praktiken, die denen anderer Produktionsartefakte ähneln.

RAG-Pipelines machen den Serving-Pfad noch komplexer. Eine Benutzeranfrage kann den Abruf aus einem Vektorindex, die Zusammenstellung von Kontext, die Generierung durch das Modell und die Evaluierung der Ausgabe auslösen, bevor eine Antwort die Anwendung erreicht. Wenn Abruf und Generierung zu weit auseinander liegen – operativ oder physisch –, steigt die Latenz. Wenn sich die Abruflogik ohne Versionierung ändert, ändert sich das Ausgabeverhalten, selbst wenn das Modell gleich bleibt.

Feinabgestimmte und adapterbasierte Modelle führen eine weitere Ebene ein. Mit LoRA-Serving können mehrere aufgabenspezifische Adapter gegen ein gemeinsames Basismodell ausgeführt werden, sodass Teams spezialisiertes Verhalten unterstützen können, ohne für jeden Anwendungsfall ein vollständig separates Modell laden zu müssen. Quantisierung wie INT4 oder INT8 reduziert die Speicher- und Rechenanforderungen, wodurch größere Modelle unter Kosten- und Latenzbeschränkungen praktischer bereitzustellen sind.

Für LLMOps ist das Serving nicht länger nur ein enges Endpunkt-Thema. Es umfasst Prompt-Management, Retrieval-Architektur, GPU-Effizienz, Laufzeitevaluierung und Modellvarianten-Management. Die Behandlung der LLM-Bereitstellung als größere Version eines scikit-learn-Workflows verfehlt die Serving-Primitive, die generative KI-Anwendungen in der Produktion funktionsfähig machen.

Traditionelle MLOps-Stacks verteilen die Serving-Verantwortlichkeiten oft auf mehrere Systeme. Ein Team verwendet möglicherweise ein Tool für die Modell-Registry, ein anderes für das Serving, ein weiteres für das Monitoring und eine separate Kubernetes-Umgebung für die Rechenressourcen. Jedes System bringt seine eigenen Anmeldeinformationen, Konfigurationen, Zugriffskontrollen und operativen Praktiken mit.

Dieses Setup kann funktionieren, erhöht aber in der Regel die operative Angriffsfläche und Komplexität. Das trainierte Modell wird nur zu einer Komponente in einer größeren Serving-Umgebung, die Ingenieur:innen zusammenstellen und warten müssen. In der Sprache des zuvor erwähnten Papiers über technische Schulden besteht das Risiko in mehr Glue-Code: mehr Konnektoren, mehr duplizierte Logik, mehr Konfigurationspfade und mehr Stellen, an denen das Produktionsverhalten von den Entwicklungsannahmen abweichen kann.

Snowflakes Ansatz unterstützt End-to-End-KI/ML-Workflows, indem Modell-Registry, Feature Store, GPU-Compute-Pools mit Snowpark Container Services, Batch- und Online-Inferenz sowie Modell-Monitoring in einer kontrollierten Plattform zusammengeführt werden. Dies kann die Notwendigkeit verringern, separate Tools für Registry, Serving und Monitoring zusammenzufügen, sodass Ingenieur:innen für unterstützte Workflows direkt in Python und SQL arbeiten können.

Mit den GPU-Compute-Pools der Snowpark Container Services können Teams benutzerdefinierte Container für GPU-beschleunigte Inferenz einbringen, ohne kontrollierte Daten für viele unterstützte Inferenz-Workflows aus Snowflake verschieben oder eine separate Kubernetes-Umgebung verwalten zu müssen. Diese Workloads können innerhalb der kontrollierten Umgebung von Snowflake ausgeführt werden, wobei rollenbasierte Zugriffskontrollen für das Zugriffsmanagement verwendet werden.

Für die Batch-Inferenz können Teams ein registriertes Modell aus einem Snowpark-DataFrame mit minimalem Serving-Setup aufrufen. Für die Online-Inferenz können Teams Modelle über SPCS-REST-Endpunkte bereitstellen.

Das Ergebnis ist ein saubererer Serving-Pfad. Ingenieur:innen wählen weiterhin das richtige Muster für den Workload, optimieren die Performance und verwalten Modellversionen. Sie verbringen weniger Zeit damit, Infrastruktur zusammenzufügen, die nur dazu dient, Daten und Vorhersagen zwischen getrennten Systemen zu verschieben.

Model Serving bringt trainierte Modelle in die operative Realität von Produktionssystemen. Es bestimmt, wie Vorhersagen angefordert werden, wo die Berechnungen ausgeführt werden, welche Version antwortet, wie Features angewendet werden und ob Latenz-, Kosten- und Governance-Anforderungen unter realen Workloads Bestand haben.

Eine starke Serving-Schicht hält diese Teile enger zusammen. Online-Inferenz, Batch-Scoring, Streaming-Workflows und LLM-Serving stellen jeweils unterschiedliche Anforderungen, aber der zugrunde liegende Bedarf ist derselbe: ein Produktionspfad, der Modelle, Daten, Features, Rechenressource und Governance verbindet, ohne jede Bereitstellung zu einem benutzerdefinierten Infrastrukturprojekt zu machen.