Condividi tramite

Procedure consigliate per il Deep Learning in Azure Databricks

  • Articolo

Questo articolo include suggerimenti per il Deep Learning su Azure Databricks e informazioni su strumenti e librerie predefiniti progettati per ottimizzare i carichi di lavoro di Deep Learning, come ad esempio i seguenti:

Databricks Mosaic AI offre un'infrastruttura di deep learning predefinita con Databricks Runtime per Machine Learning, che include le librerie di deep learning più comuni come TensorFlow, PyTorch e Keras. Include anche il supporto predefinito e preconfigurato della GPU, inclusi i driver e le librerie di supporto.

ML di Databricks Runtime include anche tutte le funzionalità dell'area di lavoro di Azure Databricks, come ad esempio la creazione e la gestione del cluster, la gestione di librerie e ambienti, la gestione del codice con cartelle Git di Databricks, il supporto per l'automazione, tra cui Processi e API di Databricks, nonché il MLflow integrato per il monitoraggio dello sviluppo dei modelli e la distribuzione e la gestione dei modelli.

Gestione delle risorse e dell'ambiente

Azure Databricks consente sia di personalizzare l'ambiente di Deep Learning che di mantenere coerente l'ambiente tra gli utenti.

Personalizzare l'ambiente di sviluppo

Con Databricks Runtime è possibile personalizzare l'ambiente di sviluppo a livello di notebook, cluster e processi.

Usare criteri di cluster

È possibile creare criteri di cluster per guidare gli scienziati dei dati verso le scelte appropriate, ad esempio l'uso di un cluster a nodo singolo per lo sviluppo e l'uso di un cluster di scalabilità automatica per processi di grandi dimensioni.

Prendere in considerazione GPU A100 per carichi di lavoro di Deep Learning

Le GPU A100 sono una scelta efficiente per molte attività di Deep Learning, come ad esempio il training e l'ottimizzazione di modelli linguistici di grandi dimensioni, l'elaborazione del linguaggio naturale, il rilevamento e la classificazione degli oggetti e i motori di raccomandazione.

  • Databricks supporta GPU A100 in tutti i cloud. Per l'elenco completo dei tipi di GPU supportati, vedere Tipi di istanze supportati.
  • Le GPU A100 hanno in genere disponibilità limitata. Contattare il provider di servizi cloud per l'allocazione delle risorse o prevedere di riservare la capacità in anticipo.

Pianificazione della GPU

Per ottimizzare le GPU per il training e l'inferenza di Deep Learning distribuiti, ottimizzare la pianificazione delle GPU. Vedere Pianificazione GPU.

Procedure consigliate per il caricamento dei dati

L'archiviazione dei dati cloud in genere non è ottimizzata per le operazioni di I/O, che può costituire una sfida per i modelli di Deep Learning che richiedono set di dati di grandi dimensioni. ML di Databricks Runtime include Delta Lake e Mosaic Streaming per ottimizzare la produttività dei dati per le applicazioni di Deep Learning.

Databricks consiglia di usare le tabelle Delta Lake per l'archiviazione dei dati. Delta Lake semplifica l'ETL e consente di accedere ai dati in modo efficiente. In particolare per le immagini, Delta Lake consente di ottimizzare l'inserimento sia per il training che per l'inferenza. La soluzione di riferimento per le applicazioni delle immagini offre un esempio di ottimizzazione dell'ETL per le immagini con Delta Lake.

Databricks consiglia Mosaic Streaming per il caricamento dei dati in PyTorch o Mosaic Composer, soprattutto quando comporta carichi di lavoro distribuiti. Le API StreamingDataset e StreamingDataLoader fornite consentono di semplificare il training su set di dati di grandi dimensioni, ottimizzando al contempo le garanzie di correttezza, le prestazioni, la flessibilità e la facilità d'uso in un ambiente distribuito. per altri dettagli, vedere Caricare i dati con Mosaic Streaming.

Procedure consigliate per il training di un modello di Deep Learning

Databricks consiglia di usare Databricks Runtime per Machine Learning e MLflow Tracking e Autologging per tutto il training del modello.

Iniziare con un cluster a nodo singolo

Un cluster GPU a nodo singolo (solo driver) è in genere più veloce e più conveniente per lo sviluppo di modelli di deep learning. Un nodo con 4 GPU è probabilmente più veloce per il training di Deep Learning rispetto a 4 nodi di lavoro con 1 GPU ciascuno. Questo perché il training distribuito comporta un sovraccarico di comunicazione di rete.

Un cluster a nodo singolo è un'opzione ottimale durante lo sviluppo iterativo rapido e per i modelli di training su dati di piccole e medie dimensioni. Se il set di dati è sufficientemente grande da rallentare il training in un singolo computer, è consigliabile passare a più GPU e persino all'elaborazione distribuita.

Usare TensorBoard e le metriche del cluster per monitorare il processo di training

TensorBoard è preinstallato in ML di Databricks Runtime. È possibile usarlo all'interno di un notebook o in una scheda separata. Per informazioni dettagliate, vedere TensorBoard.

Le metriche del cluster sono disponibili in tutti i Databricks Runtime. È possibile esaminare la rete, il processore e l'utilizzo della memoria per verificare eventuali colli di bottiglia. Per informazioni dettagliate, vedere metriche del cluster.

Ottimizzare le prestazioni per il Deep Learning

È possibile e si dovrebbero usare tecniche di ottimizzazione delle prestazioni di Deep Learning in Databricks.

Arresto anticipato

L'arresto anticipato monitora il valore di una metrica calcolata nel set di convalida e arresta il training quando la metrica non migliora più. Si tratta di un approccio migliore rispetto a un buon numero di periodi da completare. Ogni libreria di Deep Learning fornisce un'API nativa per l'arresto anticipato; ad esempio, vedere le API di callback EarlyStopping per TensorFlow/Keras e per PyTorch Lightning. Per un Notebook di esempio, vedere Notebook di esempio TensorFlow Keras.

Ottimizzazione delle dimensioni batch

L'ottimizzazione delle dimensioni batch consente di ottimizzare l'utilizzo della GPU. Se le dimensioni del batch sono troppo piccole, i calcoli non possono usare pienamente le funzionalità GPU. È possibile usare le metriche del cluster per visualizzare le metriche GPU.

Regolare le dimensioni del batch in combinazione con la frequenza di apprendimento. Una buona regola generale è che, quando si aumentano le dimensioni del batch di n, occorre aumentare la frequenza di apprendimento per sqrt(n). Quando l'ottimizzazione viene eseguita manualmente, provare a modificare le dimensioni del batch in base a un fattore pari a 2 o 0,5. Continuare quindi l'ottimizzazione per ottimizzare le prestazioni, manualmente o testando una serie di iperparametri usando uno strumento automatizzato come Optuna.

Transfer Learning

Con l'apprendimento induttivo si inizia con un modello precedentemente sottoposto a training e lo si modifica in base alle esigenze per la propria applicazione. L'apprendimento induttivo può ridurre significativamente il tempo necessario per eseguire il training e ottimizzare un nuovo modello. Per altre informazioni e un esempio, vedere Definizione delle funzionalità per l'apprendimento induttivo.

Passare al training distribuito

ML di Databricks Runtime include TorchDistributor, DeepSpeed e Ray per facilitare il passaggio dal training a nodo singolo a quello distribuito.

TorchDistributor

TorchDistributor è un modulo open source in PySpark che facilita l'esecuzione del training distribuito con PyTorch nei cluster Spark, che consente di avviare processi di training PyTorch come processi Spark. Vedere Training distribuito con TorchDistributor.

Optuna

Optuna fornisce l'ottimizzazione degli iperparametri adattivi per Machine Learning.

Procedure consigliate per l'inferenza

Questa sezione contiene suggerimenti generali sull'uso dei modelli per l'inferenza con Azure Databricks.

  • Per ridurre al minimo i costi, considerare le CPU e le GPU ottimizzate per l'inferenza, ad esempio NC T4_v3-series. Non esiste alcuna raccomandazione chiara, poiché la scelta migliore dipende dalle dimensioni del modello, dalle dimensioni dei dati e da altre variabili.

  • Usare MLflow per semplificare la distribuzione e la gestione dei modelli. MLflow può registrare qualsiasi modello di Deep Learning, inclusa la logica di pre-elaborazione e post-elaborazione personalizzata. I modelli in Unity Catalog o nei modelli registrati nel Workspace Model Registry possono essere distribuiti per inferenza batch, streaming o online.

Gestione online

L'opzione migliore per la gestione a bassa latenza è quella online tramite un'API REST. Databricks fornisce Model Serving per l'inferenza online. Model Serving offre un'interfaccia unificata per implementare, gestire ed eseguire query sui modelli di IA e supporta la gestione di quanto segue:

  • Modelli personalizzati. Si tratta di modelli Python inclusi nel formato MLflow. Gli esempi includono i modelli scikit-learn, XGBoost, PyTorch e Hugging Face transformer.
  • Modelli aperti e all'avanguardia sono resi disponibili da API dei modelli di base. Questi modelli sono architetture di modelli di base curate che supportano l'inferenza ottimizzata. Ad esempio, i modelli di base, come Llama-2-70B-chat, BGE-Large e Mistral-7B sono disponibili per un uso immediato con prezzi pay-per-token. Per i carichi di lavoro che richiedono garanzie di prestazioni e varianti di modello ottimizzate, è possibile distribuirli con velocità effettiva con provisioning.
  • Modelli esterni. Si tratta di modelli ospitati all’esterno di Databricks. Ad esempio modelli di IA generativa come GPT-4 di OpenAI, Claude di Anthropic e altri. Gli endpoint che servono questi modelli possono essere regolati in maniera centralizzata e i clienti ne possono stabilire limiti di velocità e controlli di accesso.

In alternativa, MLflow fornisce API per la distribuzione in vari servizi gestiti per l'inferenza online, nonché le API per la creazione di contenitori Docker per soluzioni di gestione personalizzate.

Altri servizi gestiti comuni per l'inferenza online includono:

Inferenza batch e streaming

L'assegnazione dei punteggi batch e streaming supporta l'assegnazione di punteggi ad elevata produttività e a basso costo, con latenze di appena pochi minuti. Per altre informazioni, vedere Usare MLflow per l'inferenza del modello.

  • Se si prevede di accedere più volte ai dati per l'inferenza, è consigliabile creare un processo di pre-elaborazione per eseguire l'ETL dei dati in una tabella Delta Lake prima di eseguire il processo di inferenza. In questo modo, il costo di inserimento e preparazione dei dati viene distribuito tra più letture dei dati. La separazione della pre-elaborazione dall'inferenza consente anche di selezionare hardware diverso per ogni processo per ottimizzare i costi e le prestazioni. Ad esempio, è possibile usare CPU per l'ETL e GPU per l'inferenza.
  • Usare le funzioni Spark Pandas definite dall'utente per ridimensionare l'inferenza batch e streaming in un cluster.