Model Deployment

Die Modellbereitstellung umfasst den Prozess, ein trainiertes Modell des maschinellen Lernens in den Produktivbetrieb zu überführen, wo Anwendungen neue Daten senden und auf Grundlage der Vorhersagen handeln. Dazu gehören die Auswahl des Ausführungsorts des Modells, die Konvertierung in ein Format, das die Ziel-Laufzeitumgebung ausführen kann, die Anbindung an Ein- und Ausgaben über eine API oder App, die sichere Veröffentlichung neuer Versionen und die Überwachung des Modellverhaltens, sobald echte Nutzerinnen und Nutzer darauf angewiesen sind. Ein Modell mit guten Ergebnissen in einem Notebook ist nur ein Experiment, bis es bereitgestellt wird. Die Bereitstellung ist der Teil der Betriebsabläufe für maschinelles Lernen (MLOps), bei dem Data Science auf technische Vorgaben der Softwareentwicklung wie Latenz, Kosten, Verfügbarkeit und Sicherheit trifft.

Wo Modelle bereitgestellt werden#

• Cloud-Bereitstellung: Das Modell läuft auf Servern hinter einem REST- oder gRPC-Endpunkt, üblicherweise über ein System zur Modellbereitstellung, das Anfragen bündelt und die Zahl der Replikate dem Bedarf anpasst. Dieser Ansatz eignet sich für große Modelle und schwankenden Datenverkehr. Bei jeder Anfrage fällt jedoch die Netzwerklaufzeit an.
• Edge-Bereitstellung: Das Modell läuft auf dem Gerät, das die Daten erfasst, etwa einem Smartphone, einer Kamera, einem Roboter oder einem NVIDIA-Jetson-Modul. Die Eingaben verlassen das Gerät nie, was den Datenschutz schützt. Das Modell funktioniert auch offline, aber der begrenzte Speicher und die knappe Energieversorgung erfordern meist ein komprimiertes Modell.
• Serverlose Bereitstellung: Die Plattform startet bei Bedarf Instanzen und fährt sie im Leerlauf auf null herunter. Dafür fällt bei der ersten Anfrage eine Verzögerung durch den Kaltstart an. Solange keine Anfragen eingehen, entstehen keine Kosten.
• Stapelverarbeitung: Ein geplanter Auftrag bewertet einen großen Datensatz auf einmal, etwa für nächtliche Produktempfehlungen. Dabei ist der Durchsatz wichtiger als die Geschwindigkeit pro Anfrage.

Ultralytics Platform stellt ein trainiertes YOLO-Modell in einer von 42 Regionen an einem dedizierten Endpunkt bereit. Jeder Endpunkt hat eine eigene URL und Überwachung. Endpunkte mit der Standardressourcengröße werden im Leerlauf auf null herunterskaliert. Die Wahl des Zielsystems ergibt sich aus einigen Fragen zur Anwendung, die in der Lektion Ein Bereitstellungsziel auswählen der Ultralytics Academy ausführlich behandelt werden:

Ein Modell für den Produktivbetrieb vorbereiten#

Trainingsframeworks sind auf Flexibilität ausgelegt. Daher werden Modelle für den Produktivbetrieb üblicherweise in ein Format exportiert, das eine Inferenz-Engine effizient ausführt, etwa ONNX für Portabilität, TensorRT für NVIDIA-GPUs, OpenVINO für Intel-Hardware oder LiteRT und Core ML für Smartphones. Modellquantisierung und Modellbeschneidung verkleinern das Modell weiter, wenn das Zielgerät nur begrenzte Ressourcen hat. Anschließend werden das exportierte Modell und sein Vorverarbeitungscode mit festgelegten Abhängigkeiten verpackt, üblicherweise in einem Docker-Container, der auf einem Laptop, Server oder Kubernetes-Cluster gleich ausgeführt wird. So sieht es aus, einen trainierten Detektor zu exportieren und die exportierte Datei vor der Veröffentlichung für eine schnelle Prüfung zu laden:

from ultralytics import YOLO

# Load a trained model (replace with your own best.pt)
model = YOLO("yolo26n.pt")

# Export to ONNX, a portable format that many inference engines run
path = model.export(format="onnx")
print(f"Deployable model: {path}")

# Smoke-test the exported file with the same API before shipping it
onnx_model = YOLO(path)
results = onnx_model("https://ultralytics.com/images/bus.jpg")
results[0].save(filename="bus_onnx.jpg")

Der Exportaufruf gibt den Pfad zur neuen Datei yolo26n.onnx zurück. Das gespeicherte Bild bestätigt, dass die exportierte Datei geladen wird und Erkennungen erzeugt. Teams vergleichen außerdem Genauigkeit und Geschwindigkeit des exportierten Modells mit dem Original auf einem Validierungsdatensatz, da sich die Ausgaben durch Formatkonvertierung und geringere Präzision leicht ändern können.

Neue Modellversionen veröffentlichen#

Eine neue Modellversion wird in einer Modellregistrierung gespeichert und schrittweise veröffentlicht, da Offline-Metriken nicht alle Bedingungen im Produktivbetrieb erfassen. Bei einer Schattenbereitstellung erhält das neue Modell eine Kopie des Live-Datenverkehrs, während das aktuelle Modell weiterhin den Nutzerinnen und Nutzern antwortet. So lassen sich die beiden Modelle ohne Risiko vergleichen. Bei einer Canary-Veröffentlichung wird anschließend ein kleiner Teil des echten Datenverkehrs an die neue Version geleitet. Dieser Anteil wird nur erhöht, solange Fehlerquoten, Latenz und Vorhersagequalität stabil bleiben. A/B-Tests messen die Auswirkungen auf Geschäftsergebnisse. Wenn die vorherige Version weiterhin bereitgestellt werden kann, genügt zum Zurücksetzen eine Konfigurationsänderung statt eines Notfall-Neuaufbaus:

Modellbereitstellung im Vergleich zu verwandten Begriffen#

• Modelltraining: Lernt anhand eines Datensatzes die Gewichte des Modells. Die Bereitstellung beginnt mit den fertig trainierten Gewichten.
• Modellbereitstellung zur Inferenz: Die Laufzeitschicht, die Vorhersageanfragen beantwortet. Sie ist ein Teil der Bereitstellung, zu der auch Paketierung, Veröffentlichung und Überwachung gehören.
• Inferenzlatenz: Die Zeit, die das bereitgestellte Modell für jede einzelne Vorhersage benötigt. Sie ist eine der wichtigsten Anforderungen, die eine Bereitstellung erfüllen muss.

Überwachung nach der Bereitstellung#

Ein bereitgestelltes Modell verschlechtert sich unbemerkt, wenn sich die Umgebung verändert. Die Modellüberwachung erfasst Betriebskennzahlen wie Latenz, Durchsatz, Fehlerquoten und Hardwareauslastung, häufig mit Werkzeugen wie Prometheus und Grafana, sowie Statistiken zu Eingaben und Vorhersagen. Meldet die Überwachung ein Problem, annotieren Teams die neuen Fehlerfälle, trainieren das Modell erneut und durchlaufen mit der neuen Version denselben Veröffentlichungsprozess. Eingabestatistiken liefern die früheste Warnung: Eine Datenverschiebung, also eine Veränderung der Eingabeverteilung, etwa durch eine Kamera in einem neuen Winkel oder den Wechsel zur Winterbeleuchtung, wird oft schon Tage oder Wochen vorher sichtbar. Erst später treffen die Ground-Truth-Labels für die Produktionsdaten ein, mit denen sich die Genauigkeit messen lässt.