Condividi tramite

Usare librerie Python personalizzate con Model Serving

In questo articolo si apprenderà come includere librerie personalizzate o librerie da un server mirror privato quando si registra il modello, in modo da poterle utilizzare con le distribuzioni del modello Mosaic AI Model Serving. È necessario completare i passaggi descritti in questa guida dopo avere un modello di Machine Learning con training pronto per la distribuzione, ma prima di creare un endpoint di gestione del modello di Azure Databricks.

Lo sviluppo di modelli spesso richiede l'uso di librerie Python personalizzate che contengono funzioni per pre-elaborazione o post-elaborazione, definizioni di modelli personalizzati e altre utilità condivise. Inoltre, molti team di sicurezza aziendali incoraggiano l'uso di mirror PyPi privati, ad esempio Nexus o Artifactory, per ridurre il rischio di attacchi a catena di approvvigionamento. Azure Databricks offre supporto nativo per l'installazione di librerie e librerie personalizzate da un mirror privato nell'area di lavoro di Azure Databricks.

Requisiti

  • MLflow 1.29 o versione successiva

Opzione 1: Usare un repository di pacchetti privati

Usare l'opzione 1 se l'organizzazione usa un mirror PyPI privato (ad esempio Nexus o Artifactory). Gli amministratori dell'area di lavoro possono configurarlo come repository di pacchetti predefinito per l'area di lavoro. Model Serving usa automaticamente questa configurazione a livello di area di lavoro durante la compilazione dell'ambiente del modello.

Per configurare un repository di pacchetti privati, vedere Configurare i repository di pacchetti Python predefiniti.

Dopo la configurazione, passare a Gestire il modello.

Opzione 2: Creare un pacchetto di librerie personalizzate come file wheel

Usare l'opzione 2 se un mirror PyPI privato non è accessibile o se sono disponibili librerie personalizzate non disponibili in alcun repository di pacchetti. È possibile impacchettarli come file Wheel Python e includerli quando si registra il modello.

Passaggio 1: Caricare il file di dipendenza

Databricks consiglia di caricare il file di dipendenza nei volumi del catalogo Unity. In alternativa, è possibile caricarlo in Databricks File System (DBFS) usando l'interfaccia utente di Azure Databricks.

Per assicurarsi che la libreria sia disponibile per il notebook, è necessario installarla usando %pip. Usando %pip installa la libreria nel notebook corrente e scarica la dipendenza nel cluster.

Passaggio 2: Registrare il modello con una libreria personalizzata

Dopo aver installato la libreria e caricato il file Wheel Python nei volumi di Unity Catalog o in DBFS, includi il codice seguente nello script. Nel extra_pip_requirements specifica il percorso del file di dipendenza.

mlflow.sklearn.log_model(model, "sklearn-model", extra_pip_requirements=["/volume/path/to/dependency.whl"])

Per DBFS, usare quanto segue:

mlflow.sklearn.log_model(model, "sklearn-model", extra_pip_requirements=["/dbfs/path/to/dependency.whl"])

Se si dispone di una libreria personalizzata, è necessario specificare tutte le librerie Python personalizzate associate al modello durante la configurazione della registrazione. È possibile farlo con i extra_pip_requirements parametri o conda_env in log_model().

Importante

Se si utilizza DBFS, assicurarsi di includere una barra inclinata, /, prima del path dbfs quando si registra extra_pip_requirements. Scopri di più sui percorsi DBFS su Azure Databricks nel documento Usare i file.

from mlflow.utils.environment import _mlflow_conda_env

mlflow.pyfunc.log_model(
    name="model",
    python_model=MyModel(),
    extra_pip_requirements=["/volumes/path/to/dependency"],
)

Se la libreria personalizzata è archiviata in un luogo diverso da un volume o DBFS, puoi specificare la sua posizione usando il parametro code_paths e passare il parametro "code/<wheel-file-name>.whl" nel parametro extra_pip_requirements.

mlflow.pyfunc.log_model(
    name="model",
    python_model=MyModel(),
    code_paths=["/path/to/dependency.whl"], # This will be logged as `code/dependency.whl`
    extra_pip_requirements=["code/dependency.whl"],
)

Passaggio 3: Aggiornare il modello MLflow con i file della rotellina Python

MLflow fornisce l'utilità add_libraries_to_model() per registrare il modello con tutte le relative dipendenze preconfezionate come file con rotellina Python. In questo modo le librerie personalizzate vengono incluse insieme al modello, oltre a tutte le altre librerie specificate come dipendenze del modello. Ciò garantisce che le librerie usate dal modello siano esattamente quelle accessibili dall'ambiente di training.

Nell'esempio seguente model_uri fa riferimento al registro dei modelli di Catalogo Unity usando la sintassi models:/<uc-model>/<model-version>. Per fare riferimento all'uso del registro dei modelli dell'area di lavoro (legacy), models:/<model-name>/<model-version>.

Quando si usa l'URI del Registro di sistema del modello, questa utilità genera una nuova versione nel modello registrato esistente.

import mlflow.models.utils
mlflow.models.utils.add_libraries_to_model(<model-uri>)

Servire il modello

Quando una nuova versione del modello con i pacchetti inclusi è disponibile nel Registro di sistema dei modelli, è possibile aggiungere questa versione del modello a un endpoint con Model Serving.

Risolvere i problemi di installazione dei pacchetti

Se la distribuzione del modello non riesce durante la fase di compilazione, è possibile esaminare i log di compilazione per identificare i problemi di installazione dei pacchetti.

  1. Passare alla pagina Serve nell'area di lavoro di Azure Databricks.
  2. Fare clic sul nome dell'endpoint per aprire i dettagli dell'endpoint.
  3. Fare clic sulla scheda Log .
  4. Selezionare la versione non riuscita dal menu a discesa.
  5. Fare clic su Compila log.

Esaminare i messaggi di errore per identificare il problema.

Dopo aver risolto il problema, creare una nuova distribuzione o aggiornare l'endpoint per attivare una nuova compilazione.

Risolvere i problemi relativi al repository di pacchetti privati

Se si usa un repository di pacchetti privati, i problemi comuni includono:

  • Pacchetti mancanti: il pacchetto non è disponibile nel repository configurato. Aggiungere il pacchetto necessario al repository privato.
  • Problemi di connessione: la gestione del modello non riesce a raggiungere il repository dei pacchetti. Verificare la connettività di rete e le regole del firewall.
  • Errori di autenticazione: le credenziali configurate per il repository non sono valide o scadute. Aggiorna i segreti nella configurazione dell'area di lavoro.

I notebook serverless usano lo stesso repository di pacchetti predefinito configurato per l'area di lavoro. È possibile usare un notebook per testare la connettività, l'autenticazione e la disponibilità dei pacchetti installando i requisiti dal file del modello prima di requirements.txt eseguire la distribuzione in Model Serving.

import mlflow
import subprocess
import sys

# Step 1: Set your model details
catalog = "<your_catalog>"
schema = "<your_schema>"
model_name = "<your_model>"
version = <your_version>

# Step 2: Download the model's requirements.txt
full_model_name = f"{catalog}.{schema}.{model_name}"
requirements_uri = f"models:/{full_model_name}/{version}/requirements.txt"

print(f"Downloading artifacts from: {requirements_uri}")
local_path = mlflow.artifacts.download_artifacts(requirements_uri)

# Step 3: Print the requirements
with open(local_path, "r") as f:
    print(f.read())

# Step 4: Install the requirements using the workspace's default package repository
print(f"Installing requirements from {local_path}...")
subprocess.check_call([sys.executable, "-m", "pip", "install", "-r", local_path])
print("Installation complete!")
  • Last updated on