Distribuire un modello personalizzato

Questo articolo descrive il supporto per la distribuzione di un modello personalizzato con Mosaic AI Model Serving. Inoltre, fornisce 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.

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. Consultare Eseguire query sugli endpoint per i modelli personalizzati.

Per un tutorial completo su come gestire modelli personalizzati in Databricks, vedere Tutorial sulla gestione dei modelli.

Databricks supporta anche la gestione di modelli di intelligenza artificiale generativi per applicazioni di intelligenza artificiale generative, vedere Fondazione Model APIs and API del modello di base e modelli esterni per i modelli e le offerte di calcolo supportati.

Importante

Se si utilizza su Anaconda, esaminare le condizioni per l’avviso sul servizio per ulteriori informazioni.

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

• Scarica da HuggingFace. È possibile scaricare un modello direttamente da Hugging Face e registrare tale modello per la gestione. Per esempi, vedere Esempi di notebook.

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 d’e-mail:

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.json:

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

Tipo di ambiente di calcolo

Mosaic AI 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 le versioni PyTorch o Transformers.

Tipo di carico di lavoro	Istanze GPU	memory
CPU		4GB 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 le versioni di carattere originali 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:

• Il parametro pip_requirements:

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

• Il 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.
• Il formato content_type in csv 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 si desidera installare la versione corrente di MLflow presente nell’ambiente con l'ambiente virtuale utilizzando install_mlflow. L’impostazione predefinita è False.
• Se si desidera 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 il parametro di sovrascrittura , 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"],
)

Sono state aggiornate le dipendenze di sviluppo

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 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 o modelli esterni.

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 all’incirca 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 sul ridimensionamento degli endpoint

Nota

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

La gestione degli endpoint viene ridimensionata automaticamente in base al traffico e alla potenza 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.
• Dimensionare a zero: Un endpoint di gestione dei modelli può essere ridotto a zero dopo 30 minuti di inattività. Avvio a freddo: la prima richiesta dopo il dimensionamento a zero provoca un “avvio a freddo”, causando una latenza più elevata. Per le applicazioni sensibili alla latenza, è consigliabile 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 potenza della 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 del servizio per i canali anaconda.org. In base alle nuove condizioni del 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 edizione Commerciale. L'uso di qualsiasi canale Anaconda è disciplinato dalle condizioni del 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 modelli defaults 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 canale defaults dall'ambiente conda per il modello, tale modello potrebbe avere una dipendenza dal canale defaults che potrebbe non essere prevista. Per verificare manualmente se un modello ha questa dipendenza, è possibile esaminare il valore channel nel file conda.yaml incluso nel pacchetto con il modello registrato. Ad esempio, un modello conda.yaml con una dipendenza defaults 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 stabilire se l'uso del repository di Anaconda per interagire con i propri modelli sia consentito dal rapporto con Anaconda, Databricks non obbliga i propri clienti ad apportare alcuna modifica. Se l'uso del repository di Anaconda.com attraverso l'uso di Databricks è consentito dalle condizioni 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 parametro conda_env di log_model().

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

Per ulteriori informazioni su conda.yaml, si veda la documentazione MLflow.

Risorse aggiuntive

• Creare endpoint di gestione dei 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 dei modelli
• Distribuire il codice Python con la gestione dei modelli
• Configurare l’ottimizzazione della route per la gestione degli endpoint
• Configurare l'accesso alle risorse dagli endpoint di gestione dei modelli.