Bereitstellen von benutzerdefinierten Modellen

  • Artikel

In diesem Artikel wird die Unterstützung für das Bereitstellen eines benutzerdefinierten Modells mithilfe der Databricks-Modellbereitstellung beschrieben. Darüber hinaus enthält er Details zu unterstützten Modellprotokollierungsoptionen und Computetypen, zum Packen von Modellabhängigkeiten für die Bereitstellung sowie zur Erstellung und Skalierung von Endpunkten.

Was sind benutzerdefinierte Modelle?

Model Serving kann jedes Python-Modell als API auf Produktionsniveau bereitstellen. Databricks bezeichnet solche Modelle als benutzerdefinierte Modelle. Diese ML-Modelle können mit ML-Standardbibliotheken wie scikit-learn, XGBoost, PyTorch und HuggingFace-Transformatoren trainiert werden und können jeden Python-Code enthalten.

So stellen Sie ein benutzerdefiniertes Modell bereit:

  1. Protokollieren Sie das Modell oder den Code im MLflow-Format, indem Sie entweder systemeigene integrierte MLflow-Varianten oder Pyfunc verwenden.
  2. Registrieren Sie das Modell anschließend im Unity Catalog (empfohlen) oder in der Arbeitsbereichsregistrierung.
  3. Jetzt können Sie einen Modellbereitstellungsendpunkt erstellen, um Ihr Modell bereitzustellen und abzufragen.
    1. Weitere Informationen finden Sie unter Erstellen von benutzerdefinierten Modellbereitstellungsendpunkten.
    2. Siehe Abfragen von Bereitstellungsendpunkten für benutzerdefinierte Modelle.

Ein vollständiges Tutorial zum Bereitstellen von benutzerdefinierten Modellen auf Databricks finden Sie im Modellbereitstellungstutorial.

Databricks unterstützt auch die Bereitstellung von Foundation-Modellen für generative KI-Anwendungen. Siehe Foundation Model-APIs und externe Modelle für unterstützte Modelle und Computeangebote.

Wichtig

Wenn Sie Anaconda nutzen, finden weitere Informationen in den Vertragsbedingungen.

Protokollieren von ML-Modellen

Es gibt verschiedene Methoden zum Protokollieren Ihres ML-Modells für die Modellbereitstellung. In der folgenden Liste sind die unterstützten Methoden und Beispiele zusammengefasst.

  • Automatische Protokollierung: Diese Methode wird automatisch aktiviert, wenn Databricks Runtime für ML verwendet wird.

    import mlflow
from sklearn.ensemble import RandomForestRegressor
from sklearn.datasets import load_iris

iris = load_iris()
model = RandomForestRegressor()
model.fit(iris.data, iris.target)

  • Protokollieren mit integrierten MLflow-Varianten: Sie können diese Methode verwenden, wenn Sie das Modell manuell protokollieren möchten, um eine detailliertere Steuerung zu erhalten.

    import mlflow
from sklearn.ensemble import RandomForestClassifier
from sklearn.datasets import load_iris

iris = load_iris()
model = RandomForestClassifier()
model.fit(iris.data, iris.target)

with mlflow.start_run():
    mlflow.sklearn.log_model(model, "random_forest_classifier")

  • Benutzerdefinierte Protokollierung mit pyfunc: Sie können diese Methode verwenden, um beliebige Python-Codemodelle bereitzustellen oder zusätzlichen Code zusammen mit Ihrem Modell bereitzustellen.

      import mlflow
  import mlflow.pyfunc

  class Model(mlflow.pyfunc.PythonModel):
      def predict(self, context, model_input):
          return model_input * 2

  with mlflow.start_run():
      mlflow.pyfunc.log_model("custom_model", python_model=Model())

Signatur- und Eingabebeispiele

Das Hinzufügen eines Signatur- und Eingabebeispiels zu MLflow wird empfohlen. Signaturen sind für die Protokollierung von Modellen im Unity Catalog erforderlich.

Nachfolgend sehen Sie ein Signaturbeispiel:

from mlflow.models.signature import infer_signature

signature = infer_signature(training_data, model.predict(training_data))
mlflow.sklearn.log_model(model, "model", signature=signature)

Nachfolgend sehen Sie ein Eingabebeispiel:


input_example = {"feature1": 0.5, "feature2": 3}
mlflow.sklearn.log_model(model, "model", input_example=input_example)

Computetyp

Hinweis

Die GPU-Modellbereitstellung befindet sich in der öffentlichen Vorschau.

Databricks Model Serving bietet eine Vielzahl von CPU- und GPU-Optionen für die Bereitstellung Ihres Modells. Bei der Bereitstellung mit einer GPU ist es wichtig, sicherzustellen, dass Ihr Code so eingerichtet ist, dass Vorhersagen mithilfe der von Ihrem Framework bereitgestellten Methoden auf der GPU ausgeführt werden. MLflow führt dies automatisch für Modelle aus, die mit den PyTorch- oder Transformers-Varianten protokolliert werden.

Workloadtyp GPU-Instanz Arbeitsspeicher
CPU 4 GB pro Parallelität
GPU_SMALL 1xT4 16 GB
GPU_LARGE 1xA100 80GB
GPU_LARGE_2 2xA100 160GB

Bereitstellungscontainer und Abhängigkeiten

Während der Bereitstellung wird ein Container auf Produktionsniveau erstellt und als Endpunkt bereitgestellt. Dieser Container enthält Bibliotheken, die automatisch erfasst oder im MLflow-Modell angegeben werden.

Der Modellbereitstellungscontainer enthält keine vorinstallierten Abhängigkeiten, was zu Abhängigkeitsfehlern führen kann, wenn nicht alle erforderlichen Abhängigkeiten im Modell enthalten sind. Wenn Modellbereitstellungsprobleme auftreten, empfiehlt Databricks, das Modell lokal zu testen.

Paket- und Codeabhängigkeiten

Benutzerdefinierte oder private Bibliotheken können Ihrer Bereitstellung hinzugefügt werden. Siehe Verwenden benutzerdefinierter Python-Bibliotheken mit Model Serving.

Bei nativen MLflow-Modellvarianten werden die erforderlichen Paketabhängigkeiten automatisch erfasst.

Für benutzerdefinierte pyfunc/Modelle können Abhängigkeiten explizit hinzugefügt werden.

So können Sie Paketabhängigkeiten hinzufügen:

  • Mithilfe des pip_requirements-Parameters:

    mlflow.sklearn.log_model(model, "sklearn-model", pip_requirements = ["scikit-learn", "numpy"])

  • Mithilfe des conda_env-Parameters:

    
conda_env = {
    'channels': ['defaults'],
    'dependencies': [
        'python=3.7.0',
        'scikit-learn=0.21.3'
    ],
    'name': 'mlflow-env'
}

mlflow.sklearn.log_model(model, "sklearn-model", conda_env = conda_env)

  • Verwenden Sie extra_pip_requirements, um zusätzliche Anforderungen, die nicht automatisch erfasst werden, einzuschließen.

    mlflow.sklearn.log_model(model, "sklearn-model", extra_pip_requirements = ["sklearn_req"])

Wenn Sie über Codeabhängigkeiten verfügen, können diese mithilfe von code_path angegeben werden.

  mlflow.sklearn.log_model(model, "sklearn-model", code_path=["path/to/helper_functions.py"],)

Abhängigkeitsüberprüfung

Bevor Sie ein benutzerdefiniertes MLflow-Modell bereitstellen, sollten Sie überprüfen, ob das Modell auch bedient werden kann. MLflow bietet eine API zur Validierung des Modellartefakts, die sowohl die Umgebung der Bereitstellung simuliert als auch das Testen von geänderten Abhängigkeiten ermöglicht.

Es gibt zwei APIs für die Validierung vor der Bereitstellung, die MLflow Python API und die MLflow CLI.

Mit einer dieser beiden APIs können Sie Folgendes angeben.

  • Die model_uri des Modells, das für die Modellverwaltung bereitgestellt wird.
  • Einer der folgenden:
    • Die input_data im erwarteten Format für den mlflow.pyfunc.PyFuncModel.predict()-Aufruf des Modells.
    • Den input_path, der eine Datei mit Eingabedaten definiert, die geladen und für den Aufruf von predict verwendet werden.
  • Den content_type im csv- oder json-Format.
  • Einen optionalen output_path zum Schreiben der Vorhersagen in eine Datei. Wenn Sie diesen Parameter weglassen, werden die Vorhersagen in stdout geschrieben.
  • Ein Umgebungsmanager, env_manager, der zum Erstellen der Umgebung für die Bereitstellung verwendet wird:
    • Der Standardwert ist virtualenv. Empfohlen für die Überprüfung.
    • local ist verfügbar, aber möglicherweise fehleranfällig für die Überprüfung. Wird in der Regel nur für schnelles Debuggen verwendet.
  • Ob die aktuelle Version von MLflow, die sich in Ihrer Umgebung befindet, mit der virtuellen Umgebung über install_mlflow installiert werden soll. Diese Einstellung ist standardmäßig auf False festgelegt.
  • Ob Sie verschiedene Versionen von Paketabhängigkeiten zur Problembehandlung oder Fehlersuche aktualisieren und testen möchten. Sie können dies als Liste von Zeichenfolgenabhängigkeiten angeben, die Sie mit dem Override-Argument pip_requirements_override überschreiben oder hinzufügen.

Zum Beispiel:

import mlflow

run_id = "..."
model_uri = f"runs:/{run_id}/model"

mlflow.models.predict(
  model_uri=model_uri,
  input_data={"col1": 34.2, "col2": 11.2, "col3": "green"},
  content_type="json",
  env_manager="virtualenv",
  install_mlflow=False,
  pip_requirements_override=["pillow==10.3.0", "scipy==1.13.0"],
)

Updates für Abhängigkeiten

Wenn es Probleme mit den Abhängigkeiten gibt, die mit einem protokollierten Modell angegeben wurden, können Sie die Anforderungen mit Hilfe der MLflow CLI oder mlflow.models.model.update_model_requirements() in der MLflow Python API aktualisieren, ohne ein weiteres Modell protokollieren zu müssen.

Das folgende Beispiel zeigt, wie Sie die pip_requirements.txt eines protokollierten Modells direkt aktualisieren.

Sie können vorhandene Definitionen mit angegebenen Paketversionen aktualisieren oder der Datei pip_requirements.txt nicht vorhandene Anforderungen hinzufügen. Diese Datei befindet sich im MLflow-Modellartefakt am angegebenen Speicherort model_uri.

from mlflow.models.model import update_model_requirements

update_model_requirements(
  model_uri=model_uri,
  operation="add",
  requirement_list=["pillow==10.2.0", "scipy==1.12.0"],
)

Erwartungen und Einschränkungen

In den folgenden Abschnitten werden bekannte Erwartungen und Einschränkungen für die Bereitstellung von benutzerdefinierten Modellen mithilfe von Model Serving beschrieben.

Erwartungen an die Erstellung und Aktualisierung von Endpunkten

Hinweis

Die Informationen in diesem Abschnitt gelten nicht für Endpunkte, die Basismodelle bereitstellen.

Die Bereitstellung einer neu registrierten Modellversion umfasst das Packen des Modells und seiner Modellumgebung sowie die Bereitstellung des Modellendpunkts selbst. Dieser Prozess kann ca. 10 Minuten dauern.

Azure Databricks führt ein Update ohne Ausfallzeiten für Endpunkte durch, indem die vorhandene Endpunktkonfiguration so lange beibehalten wird, bis der neue Endpunkt bereit ist. Dadurch wird das Risiko von Unterbrechungen für verwendete Endpunkte reduziert.

Wenn die Modellberechnung länger als 120 Sekunden dauert, wird ein Timeout für Anforderungen ausgeführt. Wenn Sie glauben, dass ihre Modellberechnung länger als 120 Sekunden dauert, wenden Sie sich an Ihr Azure Databricks-Kontoteam.

Databricks führt gelegentlich Systemupdates ohne Downtime und Wartung auf vorhandenen Modellbereitstellungsendpunkten durch. Während der Wartung lädt Databricks Modelle neu und kennzeichnet einen Endpunkt als fehlerhaft, wenn ein Modell nicht neu geladen werden kann. Stellen Sie sicher, dass Ihre angepassten Modelle robust sind und jederzeit neu geladen werden können.

Erwartungen der Endpunktskalierung

Hinweis

Die Informationen in diesem Abschnitt gelten nicht für Endpunkte, die Basismodelle bereitstellen.

Die Bereitstellung von Endpunkten wird basierend auf dem Datenverkehr und der Kapazität der bereitgestellten Parallelitätseinheiten automatisch skaliert.

  • Bereitgestellte Parallelität: Die maximale Anzahl paralleler Anforderungen, die das System verarbeiten kann. Sie können die erforderliche bereitgestellte Parallelität mithilfe der folgenden Formel schätzen: bereitgestellte Parallelität = Abfragen pro Sekunde (QPS) * Modellausführungszeit (s).
  • Skalierungsverhalten: Endpunkte skalieren bei erhöhtem Datenverkehr fast sofort hoch, und sie skalieren alle fünf Minuten nach unten, um sich dem reduzierten Datenverkehr anzupassen.
  • Skalierung auf Null: Endpunkte können nach 30 Minuten Inaktivität auf Null skaliert werden. Die erste Anforderung nach dem Skalieren auf Null erfährt einen „Kaltstart“, was zu einer höheren Latenz führt. Bei latenzsensiblen Anwendungen sollten Sie Strategien in Betracht ziehen, um diese Funktion effektiv zu verwalten.

Einschränkungen der GPU-Workload

Die folgenden Einschränkungen gelten für die Bereitstellung von Endpunkten mit GPU-Workloads:

  • Das Erstellen von Containerimages für GPU-Bereitstellungen dauert aufgrund der Modellgröße und erhöhter Installationsanforderungen für Modelle, die auf der GPU bereitgestellt werden, länger als die Imageerstellung für die CPU-Bereitstellung.
  • Bei der Bereitstellung sehr großer Modelle könnte ein Timeout für der Bereitstellungsprozess auftreten, wenn die Containerbuild- und Modellimplementierung eine Dauer von 60 Minuten überschreitet. In diesem Fall sollte das Modell beim Wiederholen des Prozesses erfolgreich bereitgestellt werden.
  • Die automatische Skalierung dauert für die GPU-Bereitstellung länger als für die CPU-Bereitstellung.
  • Die GPU-Kapazität wird beim Skalieren auf Null nicht garantiert. GPU-Endpunkte erwarten bei der ersten Anfrage nach der Skalierung auf Null möglicherweise eine besonders lange Wartezeit.
  • Diese Funktionalität ist in northcentralus nicht verfügbar.

Anaconda-Lizenzierungsupdate

Der folgende Hinweis richtet sich an Kunden, die sich auf Anaconda verlassen.

Wichtig

Anaconda Inc. hat die Vertragsbedingungen für die Kanäle von anaconda.org aktualisiert. Gemäß den neuen Vertragsbedingungen benötigen Sie nun möglicherweise eine kommerzielle Lizenz für die Nutzung der Paket- und Verteilungslösung von Anaconda. Weitere Informationen finden Sie unter Anaconda Commercial Edition FAQ (Häufig gestellte Fragen zu Anaconda Commercial Edition). Jegliche Nutzung von Anaconda-Kanälen unterliegt den Anaconda-Vertragsbedingungen.

MLflow-Modelle, die vor v1.18 (Databricks Runtime 8.3 ML oder früher) wurden standardmäßig mit dem conda-defaults Kanal (https://repo.anaconda.com/pkgs/) als Abhängigkeit protokolliert. Aufgrund dieser Lizenzänderung hat Databricks die Verwendung des defaults-Kanals für Modelle beendet, die mit MLflow v1.18 und höher protokolliert werden. Der protokollierte Standardkanal ist jetzt conda-forge, der auf die verwaltete Community https://conda-forge.org/ verweist.

Wenn Sie ein Modell vor MLflow v1.18 protokolliert haben, ohne den Kanal defaults aus der conda-Umgebung für das Modell auszuschließen, hat dieses Modell möglicherweise eine Abhängigkeit vom Kanal defaults, den die Sie möglicherweise nicht beabsichtigt haben. Um manuell zu überprüfen, ob ein Modell diese Abhängigkeit aufweist, können Sie den Wert von channel in der Datei conda.yaml untersuchen, die mit dem protokollierten Modell gepackt ist. Beispielsweise sieht die Datei conda.yaml eines Modells mit einer Abhängigkeit vom Kanal defaults wie folgt aus:

channels:
- defaults
dependencies:
- python=3.8.8
- pip
- pip:
    - mlflow
    - scikit-learn==0.23.2
    - cloudpickle==1.6.0
      name: mlflow-env

Da Databricks nicht bestimmen kann, ob Ihre Verwendung des Anaconda-Repositorys für die Interaktion mit Ihren Modellen gemäß Ihrer Beziehung mit Anaconda zulässig ist, erzwingt Databricks keine Änderungen von der Kundschaft. Wenn Ihre Nutzung des Anaconda.com-Repositorys über die Verwendung von Databricks unter den Bedingungen von Anaconda zulässig ist, müssen Sie keine Maßnahmen ergreifen.

Wenn Sie den Kanal ändern möchten, der in der Umgebung eines Modells verwendet wird, können Sie das Modell mit einer neuen Datei conda.yaml erneut bei der Modellregistrierung registrieren. Dazu geben Sie den Kanal im conda_env-Parameter von log_model() an.

Weitere Informationen zur log_model()-API finden Sie in der MLflow-Dokumentation für die Modellvariante, mit der Sie arbeiten, zum Beispiel log_model für scikit-learn.

Weitere Informationen zu conda.yaml-Dateien finden Sie in der MLflow-Dokumentation.

Zusätzliche Ressourcen