Übersicht über benutzerdefinierte Modelle

In diesem Artikel wird die Unterstützung für benutzerdefinierte Modelle mit Mosaik AI Model Serving beschrieben. Es enthält Details zu unterstützten Modellprotokollierungsoptionen und Computing-Typen, zum Bereitstellen von Modellabhängigkeiten für die Bereitstellung sowie zu Erwartungen an das Erstellen und Skalieren von Endpunkten.

Was sind benutzerdefinierte Modelle?

Model Serving kann jedes Python-Modell oder benutzerdefinierten Code als API auf Produktionsniveau mithilfe von CPU- oder GPU-Computeressourcen 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.

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 Sie mit den integrierten Varianten von MLflow. 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())
  

• Downloaden von HuggingFace. Sie können ein Modell direkt von Hugging Face herunterladen und dieses Modell zur Bereitstellung protokollieren. Beispiele finden Sie unter Notebookbeispiele.

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

Mosaic AI Model Serving bietet eine Vielzahl von CPU- und GPU-Optionen für die Bereitstellung Ihres Modells. Bei der Bereitstellung mit einer GPU müssen Sie sicherstellen, dass Ihr Code so eingerichtet ist, dass Vorhersagen auf der GPU ausgeführt werden, indem Sie die von Ihrem Framework bereitgestellten Methoden verwenden. MLflow führt dies automatisch für Modelle aus, die mit den PyTorch- oder Transformers-Varianten protokolliert werden.

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. Das Basisimage kann einige Abhängigkeiten auf Systemebene enthalten, aber Abhängigkeiten auf Anwendungsebene müssen explizit im MLflow-Modell angegeben werden.

Wenn nicht alle erforderlichen Abhängigkeiten im Modell enthalten sind, treten möglicherweise Abhängigkeitsfehler während der Bereitstellung auf. 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. Ausführliche Informationen zu Protokollierungsanforderungen und bewährten Methoden finden Sie in der Dokumentation zu MLflow-Modellen und in der MLflow Python-API-Referenz.

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"],)

Informationen zum Überprüfen und Aktualisieren von Abhängigkeiten vor der Bereitstellung finden Sie unter Vorabbereitstellungsüberprüfung für model Serving.

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

• Bereitstellungszeit: Das Bereitstellen einer neu registrierten Modellversion umfasst das Packen des Modells und seiner Modellumgebung und die Bereitstellung des Modellendpunkts selbst. Dieser Vorgang kann ungefähr 10 Minuten dauern, kann jedoch je nach Modellkomplexität, Größe und Abhängigkeiten länger dauern.
• Updates ohne Ausfallzeiten: Azure Databricks führt ein Zero-Downtime-Update von Endpunkten durch, indem die vorhandene Endpunktkonfiguration aktualisiert wird, bis die neue bereit ist. Dadurch wird das Risiko von Unterbrechungen für verwendete Endpunkte reduziert. Während dieses Updatevorgangs werden Sie sowohl für die alten als auch für die neuen Endpunktkonfigurationen in Rechnung gestellt, bis der Übergang abgeschlossen ist.
• Anforderungszeitüberschreitung: Wenn die Modellberechnung länger als 297 Sekunden dauert, laufen die Anforderungen ab.

Erwartungen an die Endpunktskalierung

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). Informationen zum Überprüfen der Parallelitätskonfiguration finden Sie unter "Load testing for serving endpoints".
• 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: Die Skalierung auf Null ist ein optionales Feature für Endpunkte, mit dem sie nach 30 Minuten Inaktivität auf Null skalieren können. Die erste Anforderung nach dem Skalieren auf Null hat einen "Kaltstart", was zu einer höheren Latenz führt. Die Skalierung von Null dauert in der Regel 10 bis 20 Sekunden, kann aber manchmal Minuten dauern. Es gibt keine SLA im Maßstab von null Latenz.
• Routenoptimierung: Für hohe QPS- und niedrige Latenzfälle ist die Routenoptimierung die optimale und empfohlene Option, um die Leistung zu verbessern.
• Serverlose optimierte Bereitstellungen: Verwenden Sie für eine schnellere Endpunktbereitstellungsgeschwindigkeit serverlose optimierte Bereitstellungen.

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 kann es zu einem Timeout im Bereitstellungsprozess kommen, wenn der Containeraufbau und die Modellbereitstellung eine Dauer von 60 Minuten überschreiten, oder der Containeraufbau kann mit der Fehlermeldung "Kein Speicherplatz mehr auf dem Gerät" aufgrund von Speicherbeschränkungen fehlschlagen. Verwenden Sie für große Sprachmodelle stattdessen Foundation Model-APIs .
• 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.

Anaconda-Lizenzierungshinweis für Ältere Modelle

Der folgende Hinweis richtet sich an Kunden, die mit älteren Modellen auf Anaconda vertrauen.

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

Zusätzliche Ressourcen

• Erstellen von benutzerdefinierten Modellbereitstellungsendpunkten
• Abfragen von Bereitstellungsendpunkten für benutzerdefinierte Modelle
• Debugginghandbuch für die Modellbereitstellung
• Verwenden benutzerdefinierter Python-Bibliotheken mit der Modellbereitstellung
• Packen von benutzerdefinierten Artefakten für die Modellbereitstellung
• Bereitstellen von Python-Code mit Model Serving
• Routenoptimierung für die Bereitstellung von Endpunkten
• Serverlose optimierte Bereitstellungen für modellbasierte Endpunkte
• Konfigurieren des Zugriffs auf Ressourcen über Modellbereitstellungsendpunkte