Modell-Deployments - Bring Your Own Container (BYOC)

Beim Erstellen, Aktualisieren oder Aktivieren von Modell-Deployment-Vorgängen prüft Data Science, ob ein autorisierter Pfad für den Zugriff auf das Containerimage im Mandanten vorhanden ist. Wenn die Prüfung nicht erfolgreich verläuft, kann dies an fehlenden Resource Principal Policys, einem falschen Imagepfad oder an einem nicht vorhandenen Image liegen. Stellen Sie sicher, dass die angegebenen Policys, der Pfad und das Image korrekt sind, und wiederholen Sie den Vorgang.

Jede Modell-Deployment-Ressource ruft das erstellte Containerimage aus OCI Registry in die Deployment-Compute-Instanz ab. Dort wird es dann als Container zur Inferenzierung ausgeführt. Der Download der Grafik muss innerhalb von 20 Minuten abgeschlossen sein. Wenn die Imagegröße jedoch zu groß ist oder eine temporäre Serviceausfallzeit in der Registry auftritt, kann der Vorgang wegen Timeout abgebrochen werden, sodass die Imagegröße innerhalb von 16 GB liegen muss. Wenn das Image größer ist, sollten Sie unnötige Abhängigkeiten entfernen, um die Größe zu reduzieren, und dann die Deployment-Erstellung erneut versuchen.

Beim Deployment eines Modells wird das Containerimage vom Mandanten an den Data Science-Servicemandanten übertragen und zur Ausführung des Modells als Container zur Inferenzierung verwendet. Der Container hat einen definierten Timeout von 10 Minuten für die Ausführung. Daher ist es wichtig sicherzustellen, dass der Inferenz-Servingcontainer innerhalb dieses Zeitrahmens startet.

Vor dem Deployment ist es wichtig, den Container lokal zu validieren, und test, dass sowohl die /predict- als auch die /health-Aufrufe erfolgreich sind.

Während des Deployments ist es auch wichtig zu prüfen, ob während der Containerausführung, des Vorhersageaufrufs oder des Health-Check-Aufrufs keine Fehler auftreten. Stellen Sie außerdem sicher, dass Egress beim Erstellen von Modell-Deployment-Ressourcen aktiviert ist, wenn die inferenzierende Logik, die im Container ausgeführt wird, auf das Internet zugreifen muss. Andernfalls kann es zu einem Bootstrap-Fehler des Modells kommen. Um dieses Szenario zu testen, deaktivieren Sie das Internet während lokaler Tests.

Stellen Sie sicher, dass genügend Arbeitsspeicher zum Laden und Inferenzieren des Modells zugewiesen ist, um Probleme wegen zu wenig Arbeitsspeicher zu vermeiden.

Weitere Informationen finden Sie in den BYOC-Best Practices und unter Container testen.

Es kann mehrere Gründe geben, warum ein Container nicht gestartet werden kann. Um dies zu beheben, ist es am besten, den Fehler während der lokalen Testphase zu identifizieren und zu beheben. Im Folgenden sind einige mögliche Gründe und Korrekturen aufgeführt:

• Für das Containerimage muss das Package curl installiert sein, damit die Docker-Policy HEALTHCHECK erfolgreich ausgeführt werden kann. Wenn dieses Package fehlt, kann der Container nicht gestartet werden.

• Die Docker-Befehlszeilenparameter CMD oder Entrypoint müssen entweder über die API oder Dockerfile angegeben werden, um den Webserver zu booten. Wenn diese Parameter ungültig sind, kann der Container nicht gestartet werden.

Beim Bootstrap dekomprimiert die Deployment-Compute-Instanz das Modellartefakt, und mounten Sie die Dateien im schreibgeschützten Modus im Verzeichnis /opt/ds/model/deployed_model im ausgeführten Container.

Alle aus diesem Pfad komprimierten Dateien werden in der Bewertungslogik verwendet. Zippen einer Gruppe von Dateien (einschließlich ML-Modell und Scoringlogik) oder eines Ordners mit einer Gruppe von Dateien, die einen anderen Speicherortpfad zum ML-Modell innerhalb des Containers haben.

Stellen Sie sicher, dass beim Laden des Modells in die Bewertungslogik der richtige Pfad verwendet wird.