ML-Modellbereitstellung: Vom Training in die Produktion

Wie stellen Sie ein Modell sicher bereit, wenn einige Fehler erst nach der Veröffentlichung auftreten? Das Team hat vielleicht allen Grund, dem Kandidatenmodell zu vertrauen: starke Validierungsergebnisse, günstige Benchmark-Vergleiche, dokumentierte Genehmigungen und eine registrierte Version, die zur Beförderung bereit ist.

Aber die Produktion ist eine unübersichtliche Umgebung. Feature-Werte könnten spät oder in einem anderen Format eintreffen, Live-Traffic kann Verhalten aufdecken, das Testdaten nie gezeigt haben, oder ein Rollback-Pfad, der von schnellen manuellen Entscheidungen abhängt, hält dem Druck möglicherweise nicht stand. Bei der Modellbereitstellung muss diese Unsicherheit bewältigt werden.

Eine starke Bereitstellungsstrategie für Modelle steuert, wie viel Produktionspräsenz die neue Version erhält, welche Signale das Team überwacht und wie schnell der Traffic zum letzten genehmigten Modell zurückkehren kann, wenn sich etwas verschlechtert.

Bei der Bereitstellung beginnt ein Modell, in einem echten System zu arbeiten. Das Modell muss paketiert, versioniert, genehmigt, mit Produktionsdaten verbunden und in den richtigen Workflow geleitet werden. Für viele Teams, insbesondere in regulierten Branchen, muss die Bereitstellungs-Pipeline auch Beweise aufbewahren: wer das Modell genehmigt hat, welche Version veröffentlicht wurde, welche Validierungsergebnisse die Entscheidung gestützt haben und wie das Team ein Rollback durchführen kann, wenn sich die Produktionsmetriken verschlechtern.

Teams können Modelle auf verschiedene Weise bereitstellen, je nachdem, wo die Vorhersage erscheinen muss, wie schnell das System sie benötigt und wohin die Ausgabe als Nächstes gehen muss. Einige Modelle bewerten Millionen von Datensätzen nach einem Zeitplan und schreiben die Ergebnisse in eine Tabelle zurück, während andere in Millisekunden auf Benutzeraktionen reagieren und eine Vorhersage zurückgeben, während eine Transaktion, Empfehlung oder Betrugsprüfung noch im Gange ist. In anderen Fällen läuft das Modell vollständig außerhalb einer zentralisierten Umgebung, auf einem Gerät mit begrenzter Rechenressource, Speicherkapazität und Konnektivität.

Batch-Bereitstellung

Bei der Batch-Bereitstellung bewertet ein Modell eine große Menge von Datensätzen nach einem definierten Zeitplan oder als Reaktion auf ein Daten-Pipeline-Ereignis. Beispielsweise könnte ein Churn-Modell jede Nacht alle aktiven Kund:innen bewerten, oder ein Betrugsmodell könnte Transaktionen in stündlichen Batches analysieren.

Die Batch-Bereitstellung funktioniert gut, wenn Vorhersagen nicht sofort zurückgegeben werden müssen. Es passt auch zu Workflows, bei denen die Eingaben bereits in analytischen Tabellen vorliegen und die Ausgabe als bewertete Spalte, Tabelle oder Feature für die nachgelagerte Nutzung zurückgeschrieben werden kann.

Der Kompromiss ist die Latenz. Ein Batch-Modell kann effizient und einfacher zu verwalten sein, aber seine Vorhersagen sind nur so aktuell wie der Bewertungszeitplan. Für Anwendungsfälle, bei denen eine Entscheidung während einer Benutzersitzung, einer Transaktion oder eines operativen Ereignisses getroffen werden muss, ist eine Echtzeit-Bereitstellung in der Regel besser geeignet.

Echtzeit-Bereitstellung

Eine Echtzeit-Bereitstellung – manchmal auch Online-Bereitstellung genannt – stellt ein Modell über einen Endpunkt mit geringer Latenz bereit, der Vorhersagen synchron zurückgibt. Eine Anwendung sendet eine Anfrage, das Modell bewertet die Eingabe und die Anwendung verwendet die Ausgabe, während der Workflow noch im Gange ist.

Dieser Ansatz unterstützt Anwendungsfälle wie Betrugserkennung an der Kasse, Produktempfehlungen während einer Browsing-Sitzung, dynamische Preisgestaltung, Personalisierung oder Echtzeit-Risikobewertung. Da sich die Vorhersage auf dem kritischen Pfad befindet, muss die Bereitstellung Latenz, Verfügbarkeit, Skalierung und Fehlerbehandlung berücksichtigen.

In der Praxis stellt eine Echtzeit-Bereitstellung höhere Anforderungen an die Produktionsumgebung. Das Team muss wissen, was passiert, wenn Anfragen ansteigen, wenn das Modell einen Fehler zurückgibt, wenn Features fehlen oder wenn die neue Version für eine Teilmenge von Nutzer:innen schlechter abschneidet. Eine Bereitstellungsstrategie wie Canary, Blue-Green oder Shadow Mode, die wir gleich besprechen werden, kann das Risiko verringern, das neue Modell zu breit bereitzustellen, bevor sein Produktionsverhalten verstanden wird.

Serverlose und asynchrone Bereitstellung

Serverlose Bereitstellung ist nützlich, wenn Workloads sprunghaft, intermittierend oder im Voraus schwer zu dimensionieren sind. Anstatt eine dedizierte Infrastruktur kontinuierlich auszuführen, wird das Modell ausgeführt, wenn es durch ein Ereignis, eine Anfrage oder einen Job ausgelöst wird. Dies kann für Workloads nützlich sein, bei denen der Traffic ungleichmäßig ankommt oder bei denen Teams den operativen Aufwand reduzieren möchten.

Asynchrone Inferenz eignet sich für Szenarien, in denen eine Anfrage keine sofortige Antwort erfordert. Ein Workflow zur Dokumentenklassifizierung könnte beispielsweise eine Datei akzeptieren, die Anfrage in die Warteschlange stellen, das Modell ausführen und das Ergebnis zurückschreiben, wenn die Verarbeitung abgeschlossen ist. Für Workloads mit großen Payloads, lang laufende Aufgaben oder variable Traffic-Muster kann eine asynchrone Bereitstellung ein saubereres Betriebsmodell bieten, als alles durch einen synchronen Endpunkt zu zwingen.

Es ist wichtig, nicht nur zu betrachten, wo das Modell ausgeführt wird, sondern auch, wie der Rest des Systems auf die Ausgabe wartet, sie abruft und verwendet. Warteschlangen, Wiederholungsversuche, Statusverfolgung und Fehlerbehandlung werden Teil der Bereitstellungsarchitektur.

Edge-Bereitstellung

Bei der Edge-Bereitstellung läuft das Modell auf einem Gerät oder in einer lokalen Umgebung und nicht in einem zentralisierten Produktionssystem. Ein Modell könnte auf einem Mobiltelefon, Sensor, Fahrzeug, Fabrikgerät oder einer eingebetteten Anwendung ausgeführt werden, wo geringe Latenz, Offline-Betrieb oder Datenlokalität wichtig sind.

Die Edge-Bereitstellung führt Einschränkungen ein, die in zentralisierten Umgebungen nicht immer auftreten. Das Modell muss möglicherweise komprimiert, für begrenzte Rechenressourcen optimiert oder durch einen Geräteverwaltungsprozess aktualisiert werden. Auch die Überwachung ändert sich. Wenn Vorhersagen außerhalb der zentralen Plattform stattfinden, benötigen Teams eine Möglichkeit, Performance-Signale zu sammeln, Modellversionen zu verwalten und veraltete Modelle in einer verteilten Flotte auszumustern.

Für regulierte oder sicherheitskritische Anwendungsfälle wirft die Edge-Bereitstellung auch eine Governance-Frage auf: Wie kann das Unternehmen nachweisen, welche Modellversion zu einem bestimmten Zeitpunkt auf welchem Gerät aktiv war?

Bereitstellungsstrategien steuern, wie eine neue Modellversion in der Produktion bereitgestellt wird. Anstatt den gesamten Traffic auf einmal an ein neues Modell zu senden, können Teams den Traffic schrittweise weiterleiten, Versionen vergleichen oder das neue Modell im Hintergrund ausführen, bevor seine Ausgaben echte Entscheidungen beeinflussen.

Canary-Bereitstellung

Bei einer Canary-Bereitstellung wird zunächst ein kleiner Prozentsatz des Produktions-Traffics an die neue Modellversion weitergeleitet. Das bestehende Modell verarbeitet weiterhin den Großteil des Traffics, während sich die neue Version bei Live-Eingaben bewährt.

Beispielsweise könnte ein Team 5 % der Anfragen an ein neues Empfehlungsmodell weiterleiten, die Konversionsrate, Latenz und Fehlerraten mit der aktuellen Version vergleichen und dann den Traffic schrittweise erhöhen, wenn die Ergebnisse stabil bleiben. Wenn sich die Metriken verschlechtern, kann der Traffic zurückverlagert werden, bevor das Problem die gesamte Produktionsumgebung betrifft.

Die Canary-Bereitstellung ist nützlich, wenn Teams echte Produktionsnachweise ohne eine vollständige Umstellung wünschen. Sie funktioniert am besten, wenn bereits ein Monitoring eingerichtet ist und das Team über klare Kriterien für die Übernahme und das Rollback verfügt. Ohne diese Schwellenwerte kann sich ein Canary-Release in ein langsames Produktionsexperiment ohne offensichtlichen Entscheidungspunkt verwandeln.

Blue-Green-Bereitstellung

Bei einer Blue-Green-Bereitstellung existieren zwei Produktionsumgebungen nebeneinander. In der blauen Umgebung wird das aktuelle Modell ausgeführt. In der grünen Umgebung wird das neue Modell ausgeführt. Nachdem die neue Version in der grünen Umgebung validiert wurde, wechselt der Traffic von Blau zu Grün.

Der Vorteil ist eine saubere Trennung. Da die vorherige Umgebung verfügbar bleibt, kann ein Rollback schnell erfolgen: Leiten Sie den Traffic einfach wieder auf Blau um. Dies ist besonders hilfreich, wenn Teams einen vorhersehbaren Release-Prozess und einen klaren Fallback-Pfad benötigen.

Die Blue-Green-Bereitstellung scheint die offensichtliche Wahl zu sein, erfordert jedoch in der Regel mehr Infrastruktur und eine engere Koordination. Die beiden Umgebungen müssen so eng aufeinander abgestimmt bleiben, dass der Wechsel keine Konfigurationsabweichungen, Abhängigkeitsprobleme oder Unterschiede beim Datenzugriff mit sich bringt.

Shadow-Bereitstellung

Bei der Shadow-Bereitstellung erhält das neue Modell eine Kopie des Live-Produktions-Traffics, aber seine Vorhersagen werden nicht an Nutzer:innen oder nachgelagerte Systeme weitergegeben. Das aktuelle Modell trifft weiterhin die Produktionsentscheidung, während das neue Modell im Hintergrund parallel läuft.

Teams wählen diese Strategie oft, wenn sie beobachten möchten, wie sich ein Modell bei Live-Eingaben verhält, bevor sie seinen Ausgaben vertrauen. Ein Betrugsmodell könnte beispielsweise echte Transaktionen im Shadow-Modus bewerten, während Analyst:innen seine Vorhersagen mit dem aktuellen Produktionsmodell und den tatsächlichen Ergebnissen vergleichen.

Der Shadow-Modus ist besonders wertvoll für risikoreiche Anwendungsfälle, da er Teams produktionsähnliche Nachweise liefert, ohne die Nutzererfahrung oder Geschäftsentscheidungen zu ändern. Der Kompromiss besteht darin, dass der Betrieb komplexer sein kann. Teams müssen Eingaben duplizieren, Ausgaben erfassen und Ergebnisse vergleichen, ohne Latenzzeiten einzuführen oder nachgelagerte Systeme zu verwirren.

A/B-Tests und Champion-Challenger-Bereitstellung

A/B-Tests vergleichen Modellversionen, indem sie verschiedenen Varianten unterschiedliche Nutzer:innen, Anfragen oder Segmente zuweisen. Im Gegensatz zum Shadow-Modus wirkt sich die Ausgabe des neuen Modells auf die Produktionserfahrung der ihm zugewiesenen Gruppe aus.

Ein Champion-Challenger-Muster ist ein verwandter Ansatz. Das aktuelle Produktionsmodell ist der Champion, und ein oder mehrere neue Modelle fungieren als Challenger. Die Challenger werden anhand von Live-Traffic, Geschäftsmetriken oder verzögerten Ergebnisdaten mit dem Champion verglichen. Wenn ein Challenger besser abschneidet und die betrieblichen Anforderungen erfüllt, kann er den Champion ersetzen.

Für einige Anwendungsfälle können Teams auch Multi-Armed-Bandit-Strategien verwenden, die im Laufe der Zeit dynamisch mehr Traffic den leistungsstärkeren Varianten zuweisen. Dieser Ansatz kann nützlich sein, wenn Teams während des Testens optimieren möchten, erfordert jedoch ein sorgfältiges Metrikdesign. Wenn der Bandit für das falsche Ergebnis optimiert, kann der Bereitstellungsprozess mehr Traffic an ein Modell weiterleiten, das nach einem Maßstab erfolgreich aussieht, während es andernorts nachgelagerte Probleme verursacht.

Eine Bereitstellungsstrategie steuert die Traffic-Exposition, aber die Bereitstellungs-Pipeline steuert, wie eine Modellversion vom Training in die Produktion gelangt. In ausgereiften ML-Umgebungen ist diese Pipeline wiederholbar, überprüfbar und mit der Modell-Registry verbunden.

Eine typische Modellbereitstellungs-Pipeline umfasst die folgenden Schritte:

1. Modell verpacken: Das Modellartefakt, die Abhängigkeiten, die Laufzeitanforderungen und der Inferenzcode werden für die Bereitstellung vorbereitet. Je nach Umgebung kann dies die Containerisierung, Serialisierung oder das Verpacken des Modells mit seiner Vorverarbeitungslogik umfassen.
2. Modell registrieren: Das Modell wird in einer Modell-Registry mit seiner Version, seinen Metadaten, dem Trainingskontext, den Evaluierungsmetriken und der Lineage protokolliert. Die Registry fungiert als Übergabepunkt zwischen Entwicklung und Bereitstellung.
3. Kandidaten bereitstellen und validieren: Vor dem Release wird die Kandidatenversion in einer Staging-Umgebung überprüft. Tests können das Eingabeschema, die Feature-Verfügbarkeit, Latenz, Sicherheit, Fairness, Erklärbarkeit oder geschäftsspezifische Akzeptanzkriterien abdecken.
4. Release genehmigen: In regulierten Umgebungen benötigt eine Modellversion häufig die Genehmigung eines:einer Model Owners, eines Risikoteams, eines:einer Data Stewards oder eines:einer Compliance-Prüfer:in. Der Genehmigungs-Workflow sollte erfassen, wer das Modell genehmigt hat, wann es genehmigt wurde und welche Nachweise überprüft wurden.
5. Modell bereitstellen: Das Modell wird in der Ziel-Serving-Umgebung freigegeben, z. B. in einer Batch-Scoring-Pipeline, einem Echtzeit-Endpunkt, einer Serverless-Funktion oder einem Edge-Gerät.
6. Traffic weiterleiten: Je nach Strategie kann sich der Traffic auf einmal, schrittweise durch eine Canary-Bereitstellung, atomar durch einen Blue-Green-Wechsel oder im Hintergrund durch den Shadow-Modus verlagern.
7. Produktionsverhalten überwachen: Nach dem Release verfolgt das Monitoring technische Metriken, die Modellqualität und die Geschäftsergebnisse. Latenz, Fehlerrate, Drift, Vorhersageverteilung, Feature-Qualität und Ergebnismetriken können alle darauf hinweisen, ob die Bereitstellung wie erwartet funktioniert.
8. Rollback oder Übernahme: Wenn die neue Version gut abschneidet, kann sie mehr Traffic erhalten oder das vorherige Modell ersetzen. Wenn sie sich verschlechtert, benötigt das Team einen Rollback-Pfad, der die vorherige Version sauber wiederherstellt.

Ein Rollback wird oft als technische Maßnahme beschrieben: den Traffic auf das vorherige Modell zurückleiten. In der Praxis ist es jedoch auch ein Governance-Prozess.

Ein starker Rollback-Plan beantwortet mehrere vorbereitende Fragen. Welche Metriken lösen ein Rollback aus? Wer ist befugt, es zu genehmigen? Welche Modellversion ist der als funktionierend bekannte Fallback? Was passiert mit Vorhersagen, die bereits von dem verschlechterten Modell erstellt wurden? Muss das Team nachgelagerte Stakeholder benachrichtigen, Beweise sichern oder eine Richtlinienausnahme dokumentieren?

Bei einem risikoarmen Personalisierungsmodell kann ein Rollback von Konversionsraten, Latenzzeiten und Fehlerschwellenwerten abhängen. Bei einem Kredit-, Gesundheits- oder Versicherungsmodell könnte ein Rollback auch eine Aufzeichnung darüber erfordern, wer die Entscheidung getroffen hat, welche Beweise sie stützten und wie das Unternehmen mit den betroffenen Ausgaben umgegangen ist.

Die Modell-Registry spielt hier eine wichtige Rolle. Wenn jede Modellversion mit Metadaten, Lineage, Genehmigungsstatus und Bereitstellungsstatus registriert ist, kann das Team identifizieren, welche Version in Produktion ist und welche Version sie bei einem Rollback ersetzen soll. Ohne diese Source of Truth kann ein Rollback von Stammeswissen, alten Tickets oder manueller Rekonstruktion während eines Produktionsproblems abhängen.

Ein starker Rollback-Workflow umfasst in der Regel:

• Einen klaren Auslöser, wie z. B. verschlechterte Genauigkeit, Drift, Latenz, Fehlerrate oder Bewegung von Geschäfts-KPIs
• Eine als funktionierend bekannte vorherige Version, die in der Modell-Registry gepflegt wird
• Einen Traffic-Routing-Mechanismus, der die vorherige Version schnell wiederherstellen kann
• Ein Audit-Protokoll, das zeigt, wer das Rollback initiiert hat und warum
• Eine Überprüfung der betroffenen Vorhersagen, nachgelagerten Systeme und Monitoring-Lücken nach dem Rollback

Das Ziel ist nicht, jede Bereitstellung risikofrei zu machen – das ist unmöglich. Aber Teams können das Risiko sichtbar, begrenzt und reversibel machen.

Eine gut konzipierte Pipeline kann Modelle schnell in die Produktion überführen, da die erforderlichen Prüfungen, Genehmigungen und Rollback-Pfade bereits definiert sind.

Beginnen Sie mit einem Bereitstellungsziel, nicht nur mit einem Modellartefakt

Bevor Sie ein Modell verpacken, definieren Sie, wie seine Vorhersagen konsumiert werden. Ein Modell, das beispielsweise tägliche Scores in eine Tabelle schreibt, hat andere Anforderungen als ein Modell, das in 50 Millisekunden auf ein Checkout-Ereignis reagiert. Das Bereitstellungsziel prägt die Laufzeit-, Monitoring-, Rollback- und Teststrategie.

Halten Sie Vorverarbeitung und Feature-Logik aufeinander abgestimmt

Viele Bereitstellungsfehler resultieren aus Diskrepanzen zwischen Trainings- und Produktionseingaben. Beispielsweise kann ein Feature, das während des Trainings auf eine Weise und bei der Inferenz auf eine andere Weise berechnet wird, das Verhalten des Modells ändern, ohne die Modelldatei selbst zu ändern. Bündeln Sie die Vorverarbeitungslogik nach Möglichkeit mit dem Modell oder verwenden Sie kontrollierte Feature-Pipelines, die die Definitionen über Training und Produktion hinweg konsistent halten.

Nutzen Sie die Model Registry als Übergabepunkt

Eine Modell-Registry sollte Modellversionen, Eigentümer:innen, Metadaten, Metriken, Lineage, Genehmigungsstatus und Bereitstellungsstatus erfassen. Wenn die Registry als Übergabepunkt zwischen Training und Bereitstellung fungiert, können Teams Modelle mit einer klareren Aufzeichnung darüber veröffentlichen, was genehmigt wurde und was sich geändert hat.

Passen Sie die Bereitstellungsstrategie an das Risiko an

Ein internes Batch-Modell mit geringem Risiko erfordert möglicherweise nur eine einfache geplante Bereitstellung mit Überwachung und Rollback, während ein kundenorientiertes Echtzeit-Modell möglicherweise eine Canary-Bereitstellung, den Shadow-Modus oder ein Blue-Green-Release benötigt. In regulierten Umgebungen sollten Genehmigungs-Workflows und Audit-Nachweise in den Release-Prozess integriert sein und nicht daneben stehen.

Definieren Sie das Rollback, bevor Produktions-Traffic eintrifft

Ein Rollback sollte nicht improvisiert werden. Identifizieren Sie vor dem Release die Fallback-Version, den Rollback-Trigger, die entscheidungsverantwortliche Person und den Traffic-Routing-Mechanismus. Bei Modellen, deren Ausgaben regulierte Entscheidungen beeinflussen, sollten Sie auch die Nachweisanforderungen einbeziehen.

Überwachen Sie das Modell und das umgebende System

Ein bereitgestelltes Modell fällt häufig aus, weil sich das Modell verschlechtert, sich die Daten ändern oder das umgebende System überlastet ist. Überwachen Sie Modellqualität, Input-Drift, Vorhersageverteilung, Feature-Aktualität, Latenz, Durchsatz und Fehlerraten. Wenn Ergebnisse später eintreffen, verwenden Sie Proxy-Metriken, bis die Ground Truth verfügbar ist.

Snowflake unterstützt Ansätze zur Modellbereitstellung, die Teams dabei helfen, Modelle, Daten und Governance-Kontrollen enger zusammenzuführen. Mit der Snowflake Model Registry können Teams unterstützte Modelle und zugehörige Metadaten in Snowflake verwalten, einschließlich Versionsinformationen, Metriken, Lineage und Genehmigungsstatus, während Modelle von der Entwicklung in die Produktion übergehen.

Für die Inferenz bietet Snowflake Bereitstellungsoptionen über unterstützte Ausführungsumgebungen hinweg, einschließlich Warehouse-basierter Ausführung und Snowpark Container Services. Der richtige Ansatz hängt von der Latenz, dem Datentyp und den Skalierungsanforderungen des Workloads ab, was sich in den praktischen Bereitstellungsoptionen widerspiegelt, vor denen Teams stehen: Batch-Scoring, Echtzeit-Inferenz oder containerisierte Workloads.

Für anwendbare Echtzeit-Inferenz-Anwendungsfälle können Teams Modelle als Dienste in Snowpark Container Services bereitstellen und über Endpunkte darauf zugreifen. Die Snowflake Container Runtime bietet außerdem vorkonfigurierte, anpassbare Umgebungen für unterstützte ML-Workloads auf Snowpark Container Services, einschließlich Workflows wie Training und Inferenz.

Dies kann für die Bereitstellung wertvoll sein, da einige Workflows die Notwendigkeit verringern können, kontrollierte Daten in einen separaten operativen Stack zu verschieben. Ein Modell kann näher an den von ihm verwendeten Daten registriert, versioniert und bereitgestellt werden, was Teams dabei hilft, die Kontrollen rund um Zugriff, Lineage und Governance aufrechtzuerhalten.

Für Unternehmen, die regulierte oder sensible Daten verwalten, kann diese Architektur dazu beitragen, Teile der Nachweiskette zu vereinfachen, abhängig von den Kontrollen, Implementierungs- und Dokumentationspraktiken des Unternehmens: welche Daten in das Modell eingeflossen sind, welche Version genehmigt wurde, wo es bereitgestellt wurde und wie es nach dem Release überwacht wurde.

Die Modellbereitstellung befindet sich an dem Punkt, an dem technische Bereitschaft und operative Verantwortlichkeit aufeinandertreffen. Bei guter Handhabung bietet die Bereitstellung Teams eine wiederholbare Möglichkeit, neue Modellversionen einzuführen, ohne die Kontrolle über den Release-Umfang, das Produktionsverhalten und das Rollback zu verlieren. Diese Kontrolle ist für jedes produktive ML-System von entscheidender Bedeutung, aber sie ist noch wichtiger, wenn Modellausgaben in regulierte Entscheidungen, kundenorientierte Workflows oder automatisierte Geschäftsprozesse einfließen.