Viele Leute denken, das Modell-Deployment sei ein Kinderspiel: Training abgeschlossen, Datei hochladen, eine Beschreibung schreiben, und das war's.
Aber jeder, der schon mal ein Produkt gemacht hat, weiß, dass die kniffligsten Teile oft erst nach dem Launch anfangen.
Daten aktualisieren sich, also muss neu trainiert werden; Parameter wurden angepasst, also muss eine neue Version raus; Feedback der Nutzer zeigt, dass die Performance schlechter geworden ist, und man muss herausfinden, was genau verändert wurde. Hier gibt's oft einen übersehenen Konflikt: Alle wollen, dass sich das Modell schnell aktualisiert, haben aber Angst, dass eine einzige Änderung die funktionierenden Features kaputt macht.
Deshalb denke ich, dass das Hosting von Modellen nicht nur ein Cloud-Speicher sein kann. Eine wirklich nützliche Plattform sollte zumindest den Entwicklern zeigen, was sich in jeder Version geändert hat, wer noch die alte Version nutzt, und ob die neue Version zuerst getestet werden kann, bevor sie live geht.
Das Model Hub von OpenGradient macht hier mehr aus einem Veröffentlichungs-System für Modelle.
Ein Modell kann zuerst ein unabhängiges Repository aufbauen und dann verschiedene Releases wie v1.00, v1.01, v2.00 veröffentlichen. Unter jeder Version können Modell-Dateien, Konfigurationen und Erläuterungen abgelegt werden, anstatt dass bei jedem neuen Upload das alte Modell einfach überschrieben wird.
Der tatsächliche Workflow ist auch ziemlich glatt.
Der Entwickler trainiert ein Risiko-Vorhersage-Modell, exportiert es zuerst im ONNX-Format, erstellt ein Repository im Model Hub und lädt v1.00 hoch. Dann kann er direkt im Web-Playground testen, um sicherzustellen, dass die Eingaben und Ergebnisse keine offensichtlichen Probleme aufweisen, bevor die Anwendung auf diese Version festgelegt wird.
Wenn später die Trainingsdaten aktualisiert werden, kann er weiterhin v1.01 veröffentlichen, die Änderungen klar darlegen und einen Teil der Anwendungen zuerst testen lassen. Die alte Version bleibt erhalten und wird durch ein Update nicht gleichzeitig alle Produkte, die sie nutzen, lahmlegen. Das Team kann auch über die Python SDK und CLI das Modell in ihren eigenen Trainings- oder Veröffentlichungsflow integrieren.
Natürlich, selbst wenn die Versionsnummer schick aussieht, beweist das nicht, dass das Modell zuverlässig ist. ONNX-Konvertierungen können Unterschiede mit sich bringen, neue Daten könnten die Performance verschlechtern, am Ende müssen Tests und echte Nutzungsergebnisse entscheiden.
Aber zumindest löst es ein sehr praktisches Problem: Ein Modell ist keine einmalige Datei, sondern eine Software, die langfristig gewartet werden muss. Klar zu kommunizieren, was sich bei jeder Änderung geändert hat, ist oft wichtiger, als beim ersten Release mehr Aufsehen zu erregen.
$OPG @OpenGradient #OPG
Aber jeder, der schon mal ein Produkt gemacht hat, weiß, dass die kniffligsten Teile oft erst nach dem Launch anfangen.
Daten aktualisieren sich, also muss neu trainiert werden; Parameter wurden angepasst, also muss eine neue Version raus; Feedback der Nutzer zeigt, dass die Performance schlechter geworden ist, und man muss herausfinden, was genau verändert wurde. Hier gibt's oft einen übersehenen Konflikt: Alle wollen, dass sich das Modell schnell aktualisiert, haben aber Angst, dass eine einzige Änderung die funktionierenden Features kaputt macht.
Deshalb denke ich, dass das Hosting von Modellen nicht nur ein Cloud-Speicher sein kann. Eine wirklich nützliche Plattform sollte zumindest den Entwicklern zeigen, was sich in jeder Version geändert hat, wer noch die alte Version nutzt, und ob die neue Version zuerst getestet werden kann, bevor sie live geht.
Das Model Hub von OpenGradient macht hier mehr aus einem Veröffentlichungs-System für Modelle.
Ein Modell kann zuerst ein unabhängiges Repository aufbauen und dann verschiedene Releases wie v1.00, v1.01, v2.00 veröffentlichen. Unter jeder Version können Modell-Dateien, Konfigurationen und Erläuterungen abgelegt werden, anstatt dass bei jedem neuen Upload das alte Modell einfach überschrieben wird.
Der tatsächliche Workflow ist auch ziemlich glatt.
Der Entwickler trainiert ein Risiko-Vorhersage-Modell, exportiert es zuerst im ONNX-Format, erstellt ein Repository im Model Hub und lädt v1.00 hoch. Dann kann er direkt im Web-Playground testen, um sicherzustellen, dass die Eingaben und Ergebnisse keine offensichtlichen Probleme aufweisen, bevor die Anwendung auf diese Version festgelegt wird.
Wenn später die Trainingsdaten aktualisiert werden, kann er weiterhin v1.01 veröffentlichen, die Änderungen klar darlegen und einen Teil der Anwendungen zuerst testen lassen. Die alte Version bleibt erhalten und wird durch ein Update nicht gleichzeitig alle Produkte, die sie nutzen, lahmlegen. Das Team kann auch über die Python SDK und CLI das Modell in ihren eigenen Trainings- oder Veröffentlichungsflow integrieren.
Natürlich, selbst wenn die Versionsnummer schick aussieht, beweist das nicht, dass das Modell zuverlässig ist. ONNX-Konvertierungen können Unterschiede mit sich bringen, neue Daten könnten die Performance verschlechtern, am Ende müssen Tests und echte Nutzungsergebnisse entscheiden.
Aber zumindest löst es ein sehr praktisches Problem: Ein Modell ist keine einmalige Datei, sondern eine Software, die langfristig gewartet werden muss. Klar zu kommunizieren, was sich bei jeder Änderung geändert hat, ist oft wichtiger, als beim ersten Release mehr Aufsehen zu erregen.
$OPG @OpenGradient #OPG
