Distribuire modelli personalizzati
Questo articolo descrive il supporto per la distribuzione di un modello personalizzato con Mosaic AI 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,
- Registrare il modello o il codice nel formato MLflow usando le versioni predefinite di MLflow native o pyfunc.
- Dopo aver registrato il modello, registrarlo nel Catalogo Unity (scelta consigliata) o nel Registro di sistema dell'area di lavoro.
- Da qui è possibile creare un endpoint di gestione del modello per distribuire ed eseguire query sul modello.
- Vedere Creare endpoint personalizzati per la gestione di modelli
- 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 di modelli di intelligenza artificiale generativi per 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())
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:
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 ambiente di calcolo
Nota
La gestione del modello GPU è disponibile in anteprima pubblica.
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 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 lamlflow.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 apredict
.
- Oggetto
- Oggetto
content_type
incsv
formato ojson
. - Facoltativo
output_path
per scrivere le stime in un file. Se si omette questo parametro, le stime vengono stampate instdout
. - 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.
- Il valore predefinito è
- 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 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 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 o modelli esterni.
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.yaml
oggetto . 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
- 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
- Configurare l'ottimizzazione della route per la gestione degli endpoint