Modell-Deployments

Training

Das Training eines Modells ist der erste Schritt zum Bereitstellen eines Modells. Sie verwenden Notizbuchsessions und Jobs zum Trainieren von Open-Source- und Oracle AutoML-Modellen.

Speichern

Als Nächstes speichern Sie das trainierte Modell im Modellkatalog. Sie haben folgende Optionen, um ein Modell im Modellkatalog zu speichern:

• Das ADS-SDK stellt eine Schnittstelle bereit, mit der ein Open-Source-Modell angegeben, das Modellartefakt vorbereitet und dieses Artefakt im Modellkatalog gespeichert wird.

• Sie können Ihr Modellartefakt mit der OCI-Konsole, den SDKs und den CLIs im Modellkatalog speichern.

• Verwenden Sie verschiedene Frameworks wie scikit-learn, TensorFlow oder Keras.

Für das Modell-Deployment müssen Sie eine Inferenz-Conda-Umgebung in der Modellartefaktdatei runtime.yaml angeben. Diese Inferenz-Conda-Umgebung enthält alle Modellabhängigkeiten und wird im Modellservercontainer installiert. Sie können entweder eine der Data Science-Conda-Umgebungen oder eine von Ihnen erstellte veröffentlichte Umgebung angeben.

Modell-Deployment

Nachdem ein Modell im Modellkatalog gespeichert wurde, steht es als Modell-Deployment-Ressource für das Deployment zur Verfügung. Der Service unterstützt Modelle, die in einer Python-Laufzeitumgebung ausgeführt werden. Deren Abhängigkeiten können in einer Conda-Umgebung verpackt werden.

Sie können ein Modell mit der OCI-Konsole, den OCI-SDKs, der OCI-CLI und dem ADS-SDK in Notizbuchsessions bereitstellen und aufrufen.

Modell-Deployments nutzen diese Schlüsselkomponenten, um ein Modell als HTTP-Endpunkt bereitzustellen:

Load Balancer.

Wenn Sie ein Modell-Deployment erstellen, müssen Sie einen Load Balancer konfigurieren. Ein Load Balancer bietet eine automatisierte Möglichkeit, Traffic von einem Einstiegspunkt auf viele Modellserver zu verteilen, die in einem Pool aus virtuellen Maschinen (VMs) ausgeführt werden. Die Bandbreite des Load Balancers muss in Mbps angegeben werden und ist ein statischer Wert. Sie können die Bandbreite des Load Balancers ändern, indem Sie das Deployment des Modells bearbeiten.

Ein Pool von VM-Instanzen, die den Modellserver, die Conda-Umgebung und das Modell selbst hosten

Eine Kopie des Modellservers wird für jede Compute-Instanz im VM-Pool erstellt.

Eine Kopie der Inferenz-Conda-Umgebung und des ausgewählten Modellartefakts wird ebenfalls in jede Instanz im Pool kopiert. Zwei Kopien des Modells werden für jede OCPU jeder VM-Instanz im Pool in den Arbeitsspeicher geladen. Beispiel: Wenn Sie eine VM.Standard2.4-Instanz zur Ausführung des Modellservers auswählen, werden gemäß der Berechnung "4 OCPUs x 2" 8 Kopien des Modells in den Arbeitsspeicher geladen. Mehrere Kopien des Modells helfen dabei, nebenläufige Anforderungen zu verarbeiten, die an den Modellendpunkt gesendet werden, indem diese Anforderungen auf die Modellreplikate im VM-Speicher verteilt werden. Stellen Sie sicher, dass Sie eine VM-Ausprägung mit ausreichend Arbeitsspeicher für diese Modellreplikate auswählen. Bei den meisten Modellen für maschinelles Lernen mit Größenordnungen im MB- oder niedrigen GB-Bereich ist der Arbeitsspeicher wahrscheinlich kein Problem.

Der Load Balancer verteilt Anforderungen an den Modellendpunkt auf die Instanzen im Pool. Es wird empfohlen, dass Sie kleinere VM-Ausprägungen verwenden, um das Modell mit einer größeren Anzahl von Instanzen zu hosten, anstatt weniger größere VMs auszuwählen.

Modellartefakte im Modellkatalog

Für das Modell-Deployment ist ein Modellartefakt erforderlich, das im Modellkatalog gespeichert ist. Außerdem muss das Modell sich in einem aktiven Status befinden. Das Modell-Deployment macht die Funktion predict() verfügbar, die in der Datei score.py des Modellartefakts definiert ist.

Conda-Umgebung mit Modelllaufzeitabhängigkeiten

Eine Conda-Umgebung kapselt alle Drittanbieter-Python-Abhängigkeiten (wie Numpy, Dask oder XGBoost), die für ein Modell erforderlich sind. Die Python-Conda-Umgebungen unterstützen Python-Versionen 3.7, 3.8, 3.9, 3.10 und 3.11. Die Python-Version, die Sie mit INFERENCE_PYTHON_VERSION angeben, muss mit der Version übereinstimmen, die beim Erstellen des Conda-Pakets verwendet wird.

Das Modell-Deployment ruft eine Kopie der Inferenz-Conda-Umgebung ab, die in der Datei runtime.yaml des Modellartefakts definiert ist, um das Modell und seine Abhängigkeiten bereitzustellen. Die relevanten Informationen zur Modell-Deployment-Umgebung finden Sie unter dem Parameter MODEL_DEPLOYMENT in der Datei runtime.yaml. Die MODEL_DEPLOYMENT-Parameter werden automatisch erfasst, wenn ein Modell mit ADS in einer Notizbuchsession gespeichert wird. Um ein Modell im Katalog zu speichern und mit dem OCI-SDK, der CLI oder der Konsole bereitzustellen, müssen Sie eine runtime.yaml-Datei als Teil eines Modellartefakts angeben, die diese Parameter enthält.

Hinweis

Wenn Modellartefakte im Modellkatalog ohne runtime.yaml-Datei gespeichert sind oder der Parameter MODEL_DEPLOYMENT in der Datei runtime.yaml fehlt, wird eine Standard-Conda-Umgebung im Modellserver installiert und zum Laden eines Modells verwendet. Die verwendete Standard-Conda-Umgebung ist Allgemeines maschinelles Lernen mit Python Version 3.8.

Verwenden Sie die folgenden Conda-Umgebungen:

Conda-Umgebungen für Data Science

Eine Liste der Conda-Umgebungen finden Sie unter Conda-Umgebungen anzeigen.

Im folgenden Beispiel weist die Datei runtime.yaml das Modell-Deployment an, die veröffentlichte Conda-Umgebung aus dem Objektspeicherpfad abzurufen, der mit INFERENCE_ENV_PATH in ONNX 1.10 für CPU unter Python 3.7 definiert ist.

MODEL_ARTIFACT_VERSION: '3.0'
MODEL_DEPLOYMENT:
  INFERENCE_CONDA_ENV:
    INFERENCE_ENV_SLUG: envslug
    INFERENCE_ENV_TYPE: data_science
    INFERENCE_ENV_PATH: oci://service-conda-packs@id19sfcrra6z/service_pack/cpu/ONNX 1.10 for CPU on Python 3.7/1.0/onnx110_p37_cpu_v1
    INFERENCE_PYTHON_VERSION: '3.7'

Ihre veröffentlichten Conda-Umgebungen

Sie können Conda-Umgebungen zur Verwendung in Modell-Deployments erstellen und veröffentlichen.

Im folgenden Beispiel weist die Datei runtime.yaml das Modell-Deployment an, die veröffentlichte Conda-Umgebung aus dem mit INFERENCE_ENV_PATH definierten Objektspeicherpfad abzurufen. Anschließend wird die Umgebung auf allen Instanzen des Pools installiert, der den Modellserver und das Modell selbst hostet.

MODEL_ARTIFACT_VERSION: '3.0'
MODEL_DEPLOYMENT:
  INFERENCE_CONDA_ENV:
    INFERENCE_ENV_SLUG: envslug
    INFERENCE_ENV_TYPE: published
    INFERENCE_ENV_PATH: oci://<bucket-name>@I/<prefix>/<env>
    INFERENCE_PYTHON_VERSION: '3.7'

Für alle Modellartefakte, die im Katalog ohne runtime.yaml-Datei gespeichert sind, verwenden Modellbereitstellungen auch die Standard-Conda-Umgebung für das Modell-Deployment. Ein Modell-Deployment kann auch eine Data Science-Conda-Umgebung oder eine Conda-Umgebung abrufen, die Sie erstellen oder ändern und dann veröffentlichen.

Vorgänge ohne Ausfallzeit

Bei Vorgängen ohne Ausfallzeit für Modell-Deployments kann der Modellinferenzendpunkt (Vorhersage) kontinuierlich Anforderungen ohne Unterbrechung oder Instabilität bedienen.

Modell-Deployments unterstützen eine Reihe von Vorgängen, die ohne Ausfallzeiten ausgeführt werden können. Dieses Feature ist für alle Anwendungen, die den Modellendpunkt konsumieren, von entscheidender Bedeutung. Sie können Vorgänge ohne Ausfallzeit anwenden, wenn sich das Modell in einem aktiven Status befindet und Anforderungen bedient. Verwenden Sie diese Vorgänge ohne Ausfallzeit, um das Modell durch ein anderes zu ersetzen sowie die VM-Ausprägung und die Loggingkonfiguration zu ändern und dabei Ausfallzeiten zu vermeiden.

Erfassung von Logs aus Modell-Deployment durch Loggingintegration

Sie können Modellbereitstellungen in den Logging-Service integrieren. Mit dieser optionalen Integration können Sie Logs aus einem Modell ausgeben und diese Logs dann prüfen.

Benutzerdefinierter Container mit Laufzeitabhängigkeiten für Modelle

Ein benutzerdefinierter Container kapselt alle erforderlichen Drittanbieterabhängigkeiten, die ein Modell für die Inferenz benötigt. Es enthält auch einen bevorzugten Inferenzserver, wie Triton Inference Server, TensorFlow Serving, ONNX Runtime Serving usw.

GPU-Inferenz

Die Inferenz der grafischen Verarbeitungseinheit wird häufig für rechenintensive Modelle wie LLaMa oder generative vortrainierte Transformatoren verwendet.

Benutzerdefinierter Egress

Sie können zwischen serviceverwaltetem Networking oder vom Kunden verwaltetem Networking auswählen, ähnlich wie beim benutzerdefinierten Egress mit Jobs und Notizbüchern.

Privater Endpunkt

Um die Sicherheit und Kontrolle zu verbessern, können Sie über ein privates Netzwerk (privates Modell-Deployment) auf Modell-Deployments zugreifen. Mit Unterstützung für private Endpunkte bleibt Ihr Inferenzverkehr sicher im privaten Netzwerk. Weitere Informationen finden Sie im Abschnitt Privaten Endpunkt erstellen und Modell-Deployment erstellen, um ein Modell-Deployment mit einem privaten Endpunkt zu konfigurieren.

Modell-Deployment-Details

Nachdem Sie ein Projekt ausgewählt haben, wird die Detailseite für das Projekt mit einer Liste von Notizbuchsessions und anderen Ressourcen wie Modell-Deployments angezeigt.

Wählen Sie Modell-Deployment aus, um zur Detailseite für Modell-Deployment für das ausgewählte Compartment zu gehen. Dort können Sie folgende Aktionen ausführen:

• Sie können Modell-Deployments erstellen.

• Sie können Modell-Deployments auswählen, um ihre Details anzuzeigen und damit zu arbeiten.

• Über das Menü Aktionen (drei Punkte) können Sie Details anzeigen, ein Modell-Deployment bearbeiten, verschieben oder ein Modell-Deployment löschen.

• OCID: Die OCID einer Ressource. Eine gekürzte Version der OCID wird angezeigt. Sie können die Anzeige der OCID aber auch mit Anzeigen und Ausblenden ändern. Klicken Sie auf den Link Kopieren, um die gesamte OCID in der Zwischenablage zu speichern, um sie anderswo einzufügen. Beispiel: Sie können sie in eine Datei einfügen und speichern und dann in Modellskripten verwenden.

• Mit dem Filter Listengeltungsbereich können Sie mit dem ausgewählten Projekt verknüpfte Modellbereitstellungen in einem anderen Compartment anzeigen.

• Mit der Liste Status können Sie Modell-Deployments nach Status filtern. Standardmäßig werden alle Statustypen angezeigt.

• Wenn Tags auf Modell-Deployments angewendet wurden, können Sie Modell Deployments weiter filtern, indem Sie neben Tagfilter auf Hinzufügen oder Löschen klicken.

• Wählen Sie andere Data Science-Ressourcen aus, wie Modelle, Modell-Deployments und Notizbuchsessions.