Condividi tramite


Guide utente per il runtime di intelligenza artificiale

Importante

Il runtime di intelligenza artificiale per le attività a nodo singolo è disponibile in anteprima pubblica. L'API di training distribuita per i carichi di lavoro con più GPU rimane in beta.

Questa pagina include informazioni sulla migrazione, collegamenti a notebook di esempio e informazioni sulla risoluzione dei problemi.

Migrazione di carichi di lavoro GPU classici a serverless

Se si sposta un carico di lavoro di Deep Learning esistente da un cluster Databricks classico (con Databricks Runtime ML) a serverless (con runtime di intelligenza artificiale), seguire questa procedura:

  1. Sostituire il codice che dipende dal cluster. Rimuovere tutti i riferimenti al training distribuito basato su Spark (ad esempio, TorchDistributor) e sostituirli con il decoratore @distributed di serverless_gpu.
  2. Aggiornare il caricamento dei dati. Sostituire i percorsi DBFS diretti con i percorsi dei volumi del catalogo Unity (/Volumes/...). Sostituire le operazioni dei dataframe Spark locali con Spark Connect.
  3. Reinstallare le dipendenze. Non fare affidamento sulle librerie preinstallate di Databricks Runtime ML. Aggiungere comandi espliciti %pip install per tutti i pacchetti necessari.
  4. Aggiorna i percorsi di checkpoint. Spostare checkpoint da DBFS o archiviazione locale ai volumi del Catalogo Unity (/Volumes/<catalog>/<schema>/<volume>/...).
  5. Aggiornare la configurazione di MLflow. Assicurarsi che i nomi degli esperimenti usino percorsi assoluti e configurare i nomi di esecuzione in modo che possano essere riavviati facilmente.
  6. Eseguire prima il test in modo interattivo. Validare il carico di lavoro in un notebook interattivo prima di pianificarlo come attività.

Tenere traccia dell'utilizzo e dei costi

È possibile monitorare la spesa della GPU del runtime di intelligenza artificiale eseguendo una query sulla tabella del sistema di utilizzo fatturabile (system.billing.usage). La query seguente restituisce l'utilizzo totale per i carichi di lavoro GPU serverless:

SELECT
  SUM(usage_quantity)
FROM
  system.billing.usage
WHERE
  product_features.serverless_gpu IS NOT NULL

Per altre informazioni sullo schema della tabella di utilizzo fatturabile, vedere Informazioni di riferimento sulla tabella di sistema di utilizzo fatturabile.

Il runtime di intelligenza artificiale viene addebitato per ora di GPU sullo SKU di training del modello ai seguenti prezzi:

  • H100 su richiesta: $ 7,00/ora GPU (Stati Uniti orientali)
  • A10 su richiesta: $ 4,90/ORA GPU (Stati Uniti orientali)

Notebook di esempio

Per iniziare, sono disponibili le categorie di notebook di esempio seguenti:

Categoria Descrizione
Modelli di linguaggio di grandi dimensioni Ottimizzazione di modelli linguistici di grandi dimensioni, inclusi metodi efficienti per i parametri (LoRA, QLoRA)
Visione artificiale Rilevamento degli oggetti, classificazione delle immagini e altre attività di visione artificiale
Sistemi di raccomandazione di Deep Learning Creazione di sistemi di raccomandazione con approcci di Deep Learning moderni, ad esempio modelli a due torre
ML classico Attività di Machine Learning tradizionali, tra cui il training del modello XGBoost e la previsione delle serie temporali
Addestramento distribuito su GPU multiple Ridimensionamento della formazione su più GPU con l'API GPU senza server

Per l'elenco completo, vedere Notebook di esempio dell'ambiente di esecuzione IA.

Risoluzione dei problemi

Genie Code consente di diagnosticare e suggerire correzioni per gli errori di installazione della libreria. Vedere Usare Genie Code per eseguire il debug degli errori dell'ambiente di calcolo.

ValueError: dimensione numpy.dtype modificata, può indicare incompatibilità binaria. Previsto 96 dall'intestazione C, ottenuto 88 da PyObject

L'errore si verifica in genere quando si verifica una mancata corrispondenza nelle versioni di NumPy usate durante la compilazione di un pacchetto dipendente e la versione di NumPy attualmente installata nell'ambiente di runtime. Questa incompatibilità si verifica spesso a causa di modifiche nell'API C di NumPy ed è particolarmente evidente da NumPy 1.x a 2.x. Questo errore indica che il pacchetto Python installato nel notebook potrebbe aver modificato la versione di NumPy.

Soluzione consigliata:

Controllare la versione di NumPy nel runtime e assicurarsi che sia compatibile con i pacchetti. Per informazioni sulle librerie Python preinstallate, vedere le note di rilascio del calcolo della GPU serverless, per l'ambiente 4 e l'ambiente 3. Se si ha una dipendenza da una versione diversa di NumPy, aggiungere tale dipendenza all'ambiente di calcolo.

PyTorch non riesce a trovare libcudnn durante l'installazione di torch

Quando si installa una versione diversa di torch, è possibile che venga visualizzato l'errore : ImportError: libcudnn.so.9: cannot open shared object file: No such file or directory. Ciò è dovuto al fatto che torch cerca la libreria cuDNN solo nel percorso locale.

Soluzione consigliata:

Reinstallare le dipendenze aggiungendo --force-reinstall durante l'installazione di torch:

%pip install torch --force-reinstall