Distribuire modelli personalizzati

Questo articolo descrive il supporto per la distribuzione di un modello personalizzato tramite Databricks Model Serving. Fornisce anche informazioni dettagliate sulle opzioni di registrazione dei modelli e sui tipi di calcolo supportati, su come creare un pacchetto delle dipendenze del modello per la gestione e la creazione e il ridimensionamento degli endpoint.

Che cosa sono i modelli personalizzati?

La gestione dei modelli può distribuire qualsiasi modello Python come API di livello di produzione. Databricks fa riferimento a modelli come modelli personalizzati. Questi modelli di Machine Learning possono essere sottoposti a training usando librerie di Machine Learning standard come scikit-learn, XGBoost, PyTorch e trasformatori HuggingFace e possono includere qualsiasi codice Python.

Per distribuire un modello personalizzato,

1. Registrare il modello o il codice nel formato MLflow usando le versioni predefinite di MLflow native o pyfunc.
2. Dopo aver registrato il modello, registrarlo nel Catalogo Unity (scelta consigliata) o nel Registro di sistema dell'area di lavoro.
3. Da qui è possibile creare un endpoint di gestione del modello per distribuire ed eseguire query sul modello.
   1. Vedere Creare endpoint personalizzati per la gestione di modelli
   2. Vedere Eseguire query sugli endpoint per i modelli personalizzati.

Per un'esercitazione completa su come gestire modelli personalizzati in Databricks, vedere Esercitazione sulla gestione dei modelli.

Databricks supporta anche la gestione dei modelli di base per le applicazioni di intelligenza artificiale generative, vedere Foundation Model APIs and External models for supported models and compute offerings (API del modello di base e modelli esterni per i modelli e le offerte di calcolo supportati).

Importante

Se si fa affidamento su Anaconda, esaminare le condizioni per l'avviso sul servizio per ulteriori informazioni.

Modelli di Machine Learning di log

Esistono diversi metodi per registrare il modello di Machine Learning per la gestione del modello. L'elenco seguente riepiloga i metodi e gli esempi supportati.

• Assegnazione automatica di tag Questo metodo viene abilitato automaticamente quando si usa Databricks Runtime per ML.

  import mlflow
  from sklearn.ensemble import RandomForestRegressor
  from sklearn.datasets import load_iris
  
  iris = load_iris()
  model = RandomForestRegressor()
  model.fit(iris.data, iris.target)
  

• Log con le versioni predefinite di MLflow. È possibile usare questo metodo se si vuole registrare manualmente il modello per un controllo più dettagliato.

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

• Registrazione personalizzata con pyfunc. È possibile usare questo metodo per distribuire modelli di codice Python arbitrario o distribuire codice aggiuntivo insieme al modello.

    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())
  

Esempi di firma e input

È consigliabile aggiungere una firma e un esempio di input a MLflow. Le firme sono necessarie per registrare i modelli nel catalogo unity.

Di seguito è riportato un esempio di firma:

from mlflow.models.signature import infer_signature

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

Di seguito è riportato un esempio di input:

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

Tipo di calcolo

Nota

La gestione del modello GPU è disponibile in anteprima pubblica.

Databricks Model Serving offre un'ampia gamma di opzioni di CPU e GPU per la distribuzione del modello. Quando si esegue la distribuzione con una GPU, è essenziale assicurarsi che il codice sia configurato in modo che le stime vengano eseguite sulla GPU, usando i metodi forniti dal framework. MLflow esegue questa operazione automaticamente per i modelli registrati con i tipi PyTorch o Transformers.

Tipo di carico di lavoro	Istanza GPU	memory
CPU		4 GB per concorrenza
GPU_SMALL	1xT4	16 GB
GPU_LARGE	1xA100	80 GB
GPU_LARGE_2	2xA100	160 GB

Contenitore di distribuzione e dipendenze

Durante la distribuzione, un contenitore di livello di produzione viene compilato e distribuito come endpoint. Questo contenitore include librerie acquisite o specificate automaticamente nel modello MLflow.

Il contenitore di gestione del modello non contiene dipendenze preinstallate, che potrebbero causare errori di dipendenza se non tutte le dipendenze necessarie sono incluse nel modello. Quando si verificano problemi di distribuzione del modello, Databricks consiglia di testare il modello in locale.

Dipendenze del pacchetto e del codice

È possibile aggiungere librerie personalizzate o private alla distribuzione. Vedere Usare librerie Python personalizzate con Model Serving.

Per i modelli di sapore nativi di MLflow, le dipendenze del pacchetto necessarie vengono acquisite automaticamente.

Per i modelli personalizzati pyfunc , le dipendenze possono essere aggiunte in modo esplicito.

È possibile aggiungere dipendenze dei pacchetti usando:

• Parametro pip_requirements :

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

• Parametro conda_env :

  
  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)
  

• Per includere requisiti aggiuntivi oltre a quanto acquisito automaticamente, usare extra_pip_requirements.

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

Se si hanno dipendenze di codice, è possibile specificare queste dipendenze usando code_path.

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

Convalida delle dipendenze

Prima di distribuire un modello MLflow personalizzato, è utile verificare che il modello sia in grado di essere servito. MLflow fornisce un'API che consente la convalida dell'artefatto del modello che simula l'ambiente di distribuzione e consente di testare le dipendenze modificate.

Sono disponibili due API di convalida pre-distribuzione dell'API Python MLflow e dell'interfaccia della riga di comando di MLflow.

È possibile specificare quanto segue usando una di queste API.

• Oggetto model_uri del modello distribuito nella gestione del modello.
• Uno dei seguenti:
  • Oggetto input_data nel formato previsto per la mlflow.pyfunc.PyFuncModel.predict() chiamata del modello.
  • Oggetto input_path che definisce un file contenente i dati di input che verranno caricati e usati per la chiamata a predict.
• Oggetto content_type in csv formato o json .
• Facoltativo output_path per scrivere le stime in un file. Se si omette questo parametro, le stime vengono stampate in stdout.
• Gestore dell'ambiente, env_manager, usato per compilare l'ambiente per la gestione:
  • Il valore predefinito è virtualenv. Consigliato per la convalida.
  • local è disponibile, ma potenzialmente soggetto a errori per la gestione della convalida. In genere viene usato solo per il debug rapido.
• Se installare la versione corrente di MLflow presente nell'ambiente con l'ambiente virtuale usando install_mlflow. Per impostazione predefinita, questa impostazione è False.
• Se aggiornare e testare versioni diverse delle dipendenze del pacchetto per la risoluzione dei problemi o il debug. È possibile specificare questa impostazione come elenco di sostituzioni o aggiunte di dipendenze di stringa usando l'argomento di override , pip_requirements_override.

Ad esempio:

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

Aggiornamenti delle dipendenze

Se si verificano problemi con le dipendenze specificate con un modello registrato, è possibile aggiornare i requisiti usando l'interfaccia della riga di comando di MLflow o mlflow.models.model.update_model_requirements() nell'API Python MLflow senza dover registrare un altro modello.

Nell'esempio seguente viene illustrato come aggiornare l'oggetto pip_requirements.txt di un modello registrato sul posto.

È possibile aggiornare le definizioni esistenti con le versioni del pacchetto specificate o aggiungere requisiti inesistenti al pip_requirements.txt file. Questo file si trova all'interno dell'artefatto del modello MLflow nel percorso specificato 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"],
)

Aspettative e limitazioni

Nelle sezioni seguenti vengono descritte le aspettative note e le limitazioni per la gestione di modelli personalizzati tramite Model Serving.

Aspettative di creazione e aggiornamento degli endpoint

Nota

Le informazioni contenute in questa sezione non si applicano agli endpoint che servono modelli di base.

La distribuzione di una versione del modello appena registrata comporta la creazione del pacchetto del modello e il relativo ambiente del modello e il provisioning dell'endpoint del modello stesso. Questo processo può richiedere circa 10 minuti.

Azure Databricks esegue un aggiornamento senza tempi di inattività degli endpoint mantenendo attiva la configurazione dell'endpoint esistente fino a quando il nuovo non diventa pronto. In questo modo si riduce il rischio di interruzione per gli endpoint in uso.

Se il calcolo del modello richiede più di 120 secondi, si verifica il timeout delle richieste. Se si ritiene che il calcolo del modello richiederà più di 120 secondi, contattare il team dell'account Azure Databricks.

Databricks esegue occasionalmente aggiornamenti e manutenzione del sistema senza tempi di inattività sugli endpoint di gestione dei modelli esistenti. Durante la manutenzione, Databricks ricarica i modelli e contrassegna un endpoint come Non riuscito se un modello non riesce a ricaricare. Assicurarsi che i modelli personalizzati siano affidabili e siano in grado di ricaricare in qualsiasi momento.

Aspettative di ridimensionamento degli endpoint

Nota

Le informazioni contenute in questa sezione non si applicano agli endpoint che servono modelli di base.

La gestione degli endpoint viene ridimensionata automaticamente in base al traffico e alla capacità delle unità di concorrenza di cui è stato effettuato il provisioning.

• Concorrenza con provisioning: numero massimo di richieste parallele che il sistema può gestire. Stimare la concorrenza richiesta usando la formula: concorrenza con provisioning = query al secondo (QPS) * tempo di esecuzione del modello (s).
• Comportamento di ridimensionamento: gli endpoint aumentano quasi immediatamente con un maggiore traffico e riducono le prestazioni ogni cinque minuti per trovare una corrispondenza con il traffico ridotto.
• Scala a zero: gli endpoint possono ridurre fino a zero dopo 30 minuti di inattività. La prima richiesta dopo il ridimensionamento a zero presenta un "avvio a freddo", causando una latenza più elevata. Per le applicazioni sensibili alla latenza, prendere in considerazione strategie per gestire questa funzionalità in modo efficace.

Limitazioni del carico di lavoro GPU

Di seguito sono riportate le limitazioni per la gestione degli endpoint con carichi di lavoro GPU:

• La creazione di immagini del contenitore per la gestione della GPU richiede più tempo rispetto alla creazione di immagini per la gestione della CPU a causa delle dimensioni del modello e dei requisiti di installazione maggiori per i modelli serviti nella GPU.
• Quando si distribuiscono modelli di dimensioni molto grandi, il processo di distribuzione potrebbe verificarsi un timeout se la compilazione del contenitore e la distribuzione del modello superano una durata di 60 minuti. In questo caso, avviare un nuovo tentativo del processo deve distribuire correttamente il modello.
• La scalabilità automatica per il servizio GPU richiede più tempo rispetto alla gestione della CPU.
• La capacità GPU non è garantita quando si passa a zero. Gli endpoint GPU potrebbero prevedere una latenza elevata aggiuntiva per la prima richiesta dopo il ridimensionamento a zero.
• La funzionalità non è disponibile in northcentralus.

Aggiornamento delle licenze Anaconda

L'avviso seguente è destinato ai clienti che si basano su Anaconda.

Importante

Anaconda Inc. ha aggiornato le condizioni per anaconda.org canali. In base alle nuove condizioni di servizio, potrebbe essere necessaria una licenza commerciale se ci si affida alla distribuzione e alla creazione di pacchetti di Anaconda. Per altre informazioni, vedere Domande frequenti su Anaconda Commercial Edition. L'uso di qualsiasi canale Anaconda è disciplinato dalle condizioni per il servizio.

I modelli MLflow registrati prima della versione 1.18 (Databricks Runtime 8.3 ML o versioni precedenti) sono stati registrati per impostazione predefinita con il canale conda defaults (https://repo.anaconda.com/pkgs/) come dipendenza. A causa di questa modifica della licenza, Databricks ha interrotto l'uso del canale per i defaults modelli registrati usando MLflow v1.18 e versioni successive. Il canale predefinito registrato è ora conda-forge, che punta alla community gestita https://conda-forge.org/.

Se è stato registrato un modello prima di MLflow v1.18 senza escludere il defaults canale dall'ambiente conda per il modello, tale modello potrebbe avere una dipendenza dal defaults canale che potrebbe non essere previsto. Per verificare manualmente se un modello ha questa dipendenza, è possibile esaminare channel il conda.yaml valore nel file incluso nel pacchetto con il modello registrato. Ad esempio, un conda.yaml modello con una defaults dipendenza del canale può essere simile al seguente:

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

Poiché Databricks non è in grado di determinare se l'uso del repository Anaconda per interagire con i modelli è consentito nella relazione con Anaconda, Databricks non impone ai clienti di apportare modifiche. Se l'uso del repository Anaconda.com tramite l'uso di Databricks è consentito in base ai termini di Anaconda, non è necessario eseguire alcuna azione.

Se si vuole modificare il canale usato nell'ambiente di un modello, è possibile registrare nuovamente il modello nel registro dei modelli con un nuovo conda.yamloggetto . A tale scopo, è possibile specificare il canale nel conda_env parametro di log_model().

Per altre informazioni sull'API log_model() , vedere la documentazione di MLflow relativa al modello con cui si sta lavorando, ad esempio log_model per scikit-learn.

Per altre informazioni sui conda.yaml file, vedere la documentazione di MLflow.

Risorse aggiuntive

• Esercitazione: Distribuire ed eseguire query su un modello personalizzato
• Creare endpoint di gestione di modelli personalizzati
• Eseguire query sugli endpoint per i modelli personalizzati
• Usare librerie Python personalizzate con Model Serving
• Creare un pacchetto di artefatti personalizzati per la gestione del modello
• Distribuire il codice Python con la gestione dei modelli
• Gestire più modelli a un endpoint model serving
• Configurare l'accesso alle risorse dagli endpoint di gestione del modello