Condividi tramite

Procedure consigliate per il Deep Learning in Azure Databricks

  • Articolo

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

Databricks Machine Learning 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 della GPU, inclusi i driver e le librerie di supporto.

Databricks Runtime ML include anche tutte le funzionalità dell'area di lavoro di Azure Databricks, 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é MLflow integrato per il monitoraggio e la distribuzione e la gestione dei modelli.

Gestione delle risorse e dell'ambiente

Azure Databricks consente di personalizzare l'ambiente di Deep Learning e 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 librerie Python con ambito notebook o librerie R con ambito notebook per usare un set o una versione specifiche delle librerie senza influire sugli altri utenti del cluster.
  • Installare librerie a livello di cluster per standardizzare le versioni per un team o un progetto.
  • Configurare un processo di Azure Databricks per assicurarsi che un'attività ripetuta venga eseguita in un ambiente coerente e non modificabile.

Usare i criteri del cluster

È possibile creare criteri di cluster per guidare i data scientist alle 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, 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 istanza supportati.
  • Le GPU A100 hanno in genere disponibilità limitata. Contattare il provider di servizi cloud per l'allocazione delle risorse o prendere in considerazione la prenotazione della capacità in anticipo.

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. Databricks Runtime ML include Delta Lake e Petastorm per ottimizzare la velocità effettiva 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 di immagine offre un esempio di ottimizzazione dell'ETL per le immagini con Delta Lake.

Petastorm fornisce API che consentono di preparare i dati in formato Parquet per l'uso da parte di TensorFlow, Keras o PyTorch. L'API SparkConverter fornisce l'integrazione dei dataframe Spark. Petastorm fornisce anche il partizionamento orizzontale dei dati per l'elaborazione distribuita. Per informazioni dettagliate, vedere Caricare i dati con Petastorm .

Procedure consigliate per il training di modelli di Deep Learning

Databricks consiglia di usare Il runtime di Databricks per Machine Learning e il rilevamento di MLflow e l'assegnazione automatica di tag 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 che 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 a calcolo distribuito.

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

TensorBoard è preinstallato in Databricks Runtime ML. È 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 runtime di Databricks. È possibile esaminare l'utilizzo di rete, processore e memoria per verificare eventuali colli di bottiglia. Per informazioni dettagliate, vedere Metriche del cluster.

Ottimizzare le prestazioni per l'apprendimento avanzato

È possibile e devono 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 smette di migliorare. 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 di 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 completamente 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, aumentare la frequenza di apprendimento per sqrt(n). Quando si ottimizza 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 un'ampia gamma di iperparametri usando uno strumento automatizzato come Hyperopt.

Transfer Learning

Con l'apprendimento per il trasferimento si inizia con un modello sottoposto a training in precedenza e lo si modifica in base alle esigenze per l'applicazione. L'apprendimento per il trasferimento 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 del trasferimento.

Passare al training distribuito

Databricks Runtime ML include HorovodRunner, spark-tensorflow-distributor, TorchDistributor e Hyperopt per facilitare il passaggio da un nodo singolo al training distribuito.

HorovodRunner

Horovod è un progetto open source che ridimensiona il training di Deep Learning in un calcolo multi-GPU o distribuito. HorovodRunner, compilato da Databricks e incluso in Databricks Runtime ML, è un wrapper Horovod che fornisce la compatibilità con Spark. L'API consente di ridimensionare il codice a nodo singolo con modifiche minime. HorovodRunner funziona con TensorFlow, Keras e PyTorch.

spark-tensorflow-distributor

spark-tensorflow-distributor è un pacchetto nativo open source in TensorFlow per il training distribuito con TensorFlow nei cluster Spark. Vedere il notebook di esempio.

TorchDistributor

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

Hyperopt

Hyperopt fornisce l'ottimizzazione degli iperparametri adattivi per Machine Learning. Con la classe SparkTrials è possibile ottimizzare in modo iterativo i parametri per i modelli di Deep Learning in parallelo in un cluster.

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 la serie di T4_v3 NC. 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 pre-elaborazione personalizzata e la logica di post-elaborazione. I modelli nel catalogo Unity o nei modelli registrati nel Registro dei modelli di area di lavoro possono essere distribuiti per l'inferenza batch, streaming o online.

Servizio online

L'opzione migliore per la gestione a bassa latenza è quella online dietro un'API REST. Databricks fornisce la gestione dei modelli per l'inferenza online. Model Serving offre un'interfaccia unificata per distribuire, gestire ed eseguire query sui modelli di intelligenza artificiale e supporta la gestione delle operazioni seguenti:

  • 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 all'avanguardia resi disponibili dalle API del modello foundation. 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 con pagamento 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 base come, GPT-4 di OpenAI, Claude di Anthropic e altri. Gli endpoint che servono questi modelli possono essere regolati centralmente e i clienti possono stabilire limiti di frequenza e controlli di accesso per loro.

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 in batch e di streaming supporta l'assegnazione di punteggi ad alta velocità effettiva e a basso costo a latenze fino a minuti. Per altre informazioni, vedere Usare MLflow per l'inferenza del modello.

  • Se si prevede di accedere ai dati per l'inferenza più volte, è consigliabile creare un processo di pre-elaborazione per etlare i 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 ETL e GPU per l'inferenza.
  • Usare le funzioni definite dall'utente di Spark Pandas per ridimensionare l'inferenza batch e di streaming in un cluster.
    • Quando si registra un modello da Azure Databricks, MLflow fornisce automaticamente il codice di inferenza per applicare il modello come funzione definita dall'utente pandas.
    • È anche possibile ottimizzare ulteriormente la pipeline di inferenza, soprattutto per i modelli di Deep Learning di grandi dimensioni. Per un esempio, vedere la soluzione di riferimento per image ETL .