Condividi tramite

Panoramica dei modelli personalizzati

Questo articolo descrive il supporto per i modelli personalizzati che usano Mosaic AI Model Serving. 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 sulle aspettative per la creazione e il ridimensionamento degli endpoint.

Che cosa sono i modelli personalizzati?

La gestione dei modelli può distribuire qualsiasi modello Python o codice personalizzato come API di livello di produzione usando risorse di calcolo CPU o GPU. 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 dei modelli di base per le applicazioni di intelligenza artificiale generative. Vedere Foundation Model API e Modelli esterni per i modelli e le offerte di calcolo supportati.

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, è necessario assicurarsi che il codice sia configurato in modo che le stime vengano eseguite nella 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 Memoria
CPU 4GB per concorrenza
GPU_SMALL 1xT4 16 GB
GPU_LARGE 1xA100 80 GB
GPU_LARGE_2 2xA100 160 GB
GPU_LARGE_4 4xA100 320 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. L'immagine di base può includere alcune dipendenze a livello di sistema, ma le dipendenze a livello di applicazione devono essere specificate in modo esplicito nel modello MLflow.

Se non tutte le dipendenze necessarie sono incluse nel modello, potrebbero verificarsi errori di dipendenza durante la distribuzione. 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. Per informazioni dettagliate sui requisiti di registrazione e sulle procedure consigliate, vedere la documentazione sui modelli MLflow e le informazioni di riferimento sulle API Python di MLflow.

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

Per informazioni sulla convalida e l'aggiornamento delle dipendenze prima della distribuzione, vedere Validazione pre-distribuzione per il Servizio Modelli.

Aspettative e limitazioni

Nota

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

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

  • Tempo di distribuzione: la distribuzione di una versione del modello appena registrata comporta la creazione di pacchetti del modello e il relativo ambiente del modello e il provisioning dell'endpoint del modello stesso. Questo processo può richiedere circa 10 minuti, ma può richiedere più tempo a seconda della complessità, delle dimensioni e delle dipendenze del modello.
  • Aggiornamenti senza tempi di inattività: Azure Databricks esegue un aggiornamento senza tempi di inattività degli endpoint mantenendo attiva la configurazione dell'endpoint esistente fino a quando non ne diventa pronto uno nuovo. In questo modo si riduce il rischio di interruzione per gli endpoint in uso. Durante questo processo di aggiornamento, vengono addebitati i costi sia per le configurazioni degli endpoint vecchie che per quelle nuove fino al completamento della transizione.
  • Timeout della richiesta: se il calcolo del modello richiede più di 297 secondi, si verifica il timeout delle richieste.

Importante

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. Se un modello non viene ricaricato, l'aggiornamento dell'endpoint viene contrassegnato come non riuscito e la configurazione dell'endpoint esistente continua a gestire le richieste. Assicurarsi che i modelli personalizzati siano affidabili e siano in grado di ricaricare in qualsiasi momento.

Aspettative di ridimensionamento degli endpoint

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). Per convalidare la configurazione della concorrenza, vedere Test di carico per la gestione degli endpoint.
  • 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 su zero: La scalabilità a zero è una funzionalità facoltativa per gli endpoint che consente di 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. Scalare da zero richiede in genere 10-20 secondi, ma a volte può richiedere minuti. Non esiste alcun SLA per la scalabilità da una latenza zero.
  • Ottimizzazione route: Per i casi d'uso di QPS elevati e bassa latenza, l'ottimizzazione della route è l'opzione ottimale e consigliata per migliorare le prestazioni.
  • Distribuzioni ottimizzate per serverless: Per una maggiore velocità di distribuzione degli endpoint, usare distribuzioni ottimizzate serverless.

Avvertimento

La scalabilità a zero non deve essere usata per i carichi di lavoro di produzione che richiedono tempi di attività coerenti o tempi di risposta garantiti. Per le applicazioni o gli endpoint sensibili alla latenza che richiedono la disponibilità continua, disabilitare la scalabilità su zero.

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.
  • 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.

Avviso sulle licenze Anaconda per i modelli obsoleti

Nota

Questa sezione si applica solo ai modelli registrati con MLflow v1.17 o versioni precedenti (Databricks Runtime 8.3 ML o versioni precedenti). Se si usa una versione più recente, è possibile ignorare questa sezione.

L'avviso seguente è destinato ai clienti che utilizzano Anaconda con modelli obsoleti.

Importante

Anaconda Inc. ha aggiornato le condizioni del servizio per i canali anaconda.org. In base alle nuove condizioni di servizio, potrebbe essere necessaria una licenza commerciale se ci si affida alla distribuzione di Anaconda e al suo packaging. 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 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 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 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 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

  • Last updated on