Guides utilisateur pour AI Runtime

info

Aperçu

Cette fonctionnalité est en Aperçu public.

Migrez les charges de travail de deep learning existantes des clusters Databricks classiques vers AI Runtime, suivez l'utilisation et les coûts des GPU avec la table système d'utilisation facturable, et trouvez des exemples de notebooks ainsi que des correctifs pour les erreurs courantes.

Migration des charges de travail GPU classiques vers le mode serverless

Si vous déplacez un workload de deep learning existant d'un cluster Databricks classique (avec Databricks Runtime ML) vers le serverless (avec AI Runtime), suivez ces étapes :

1. Remplacer le code dépendant du cluster. Supprimez toute référence à l'entraînement distribué basé sur Spark (par exemple, TorchDistributor) et remplacez-les par le décorateur @distributed provenant de serverless_gpu.
2. Mettez à jour le chargement des données. Remplacez les chemins d’accès DBFS directs par des chemins d’accès aux volumes Unity Catalog (/Volumes/...). Remplacez les opérations locales sur les DataFrame Spark par Spark Connect. Pour le streaming de données basées sur des fichiers à partir de volumes, utilisez UCVolumeDataset depuis serverless_gpu.data. Voir Charger des données sur AI Runtime.
3. Réinstallez les dépendances. Ne vous reposez pas sur les bibliothèques préinstallées de Databricks Runtime ML. Ajoutez des commandes %pip install explicites pour tous les packages requis.
4. Mettre à jour les chemins des points de contrôle. Déplacez les points de contrôle depuis DBFS ou le stockage local vers des volumes Unity Catalog (/Volumes/<catalog>/<schema>/<volume>/...). Pour le checkpointing distribué, utilisez UCVolumeWriter et UCVolumeReader depuis serverless_gpu.data, qui mettent en staging les E/S via NVMe local. Voir Model checkpointing.
5. Mettre à jour la configuration MLflow. Assurez-vous que les noms des expérimentations utilisent des chemins absolus et configurez les noms des exécutions afin qu'ils puissent être facilement redémarrés.
6. Testez d’abord de manière interactive. Validez votre charge de travail dans un notebook interactif avant de la planifier en tant que job.

Suivre l'utilisation et les coûts

Vous pouvez surveiller vos dépenses GPU AI Runtime en interrogeant la table système d'utilisation facturable (system.billing.usage). La query suivante renvoie l'utilisation totale pour les workloads GPU serverless :

SQL

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

Pour plus d'informations sur le schéma de la table d'utilisation facturable, consultez la référence de la table système d'utilisation facturable.

Les frais de Runtime IA par heure de GPU sur le SKU d'entraînement de modèle sont aux tarifs suivants :

• H100 à la demande : 7,00 $/heure GPU (US East)
• A10 à la demande : 2,50 $/heure par GPU (États-Unis Est)

Exemples de notebooks

Les catégories de Notebooks d’exemple suivantes sont disponibles pour vous aider à start :

Catégorie	Description
Grands modèles de langage (LLM)	Affinement de grands modèles de langage, y compris les méthodes efficaces en termes de paramètres (LoRA, QLoRA)
Vision par informatique	Détection d’objets, classification d’images et autres tâches de vision par ordinateur
Systèmes de recommandation de deep learning	Construction de systèmes de recommandation utilisant des approches modernes de deep learning comme les modèles two-tower
ML classique	Tâches de ML traditionnelles, y compris l’entraînement de modèles XGBoost et les prévisions de séries temporelles
Entraînement distribué multi-GPU	Mise à l'échelle de l'entraînement sur plusieurs GPU à l'aide de l'API GPU Serverless

Catégorie	Description
Grands modèles de langage (LLM)	Affinement de grands modèles de langage, y compris les méthodes efficaces en termes de paramètres (LoRA, QLoRA)
Vision par informatique	Détection d’objets, classification d’images et autres tâches de vision par ordinateur
Systèmes de recommandation de deep learning	Construction de systèmes de recommandation utilisant des approches modernes de deep learning comme les modèles two-tower
ML classique	Tâches de ML traditionnelles, y compris l’entraînement de modèles XGBoost et les prévisions de séries temporelles
Entraînement distribué multi-GPU	Mise à l'échelle de l'entraînement sur plusieurs GPU à l'aide de l'API GPU Serverless

Pour la liste complète, voir les notebooks d’exemple AI Runtime.

Dépannage

Genie Code peut aider à diagnostiquer et à suggérer des correctifs pour les erreurs d'installation de bibliothèque. Consultez Utiliser Genie Code pour déboguer les erreurs d'environnement de compute.

Pour déboguer de manière interactive sur le compute, utilisez le terminal Web pour exécuter des commandes Shell, inspecter l’utilisation du GPU avec nvidia-smi et gérer les fichiers. Le terminal Web est disponible lorsqu’il est connecté à la version 5 ou supérieure de l’environnement GPU serverless. Voir Exécuter des commandes Shell dans le terminal Web Databricks.

ValueError : la taille de numpy.dtype a changé, ce qui peut indiquer une incompatibilité binaire. 96 attendu depuis l'en-tête C, 88 obtenu depuis PyObject

L'erreur survient généralement lorsqu'il existe une inadéquation entre les versions de NumPy utilisées lors de la compilation d'un package dépendant et la version de NumPy actuellement installée dans l'environnement Runtime. Cette incompatibilité survient souvent en raison de changements dans l'API C de NumPy et est particulièrement notable entre NumPy 1.x et 2.x. Cette erreur indique que le package Python installé dans le notebook a peut-être modifié la version de NumPy.

Solution recommandée :

Vérifiez la version de NumPy dans le runtime et assurez-vous qu'elle est compatible avec vos packages. Consultez les notes de version du compute GPU Serverless pour l'environnement 4 et l'environnement 3 pour obtenir des informations sur les bibliothèques Python préinstallées. Si vous avez une dépendance sur une version différente de NumPy, ajoutez cette dépendance à votre environnement de compute.

PyTorch ne parvient pas à trouver libcudnn lors de l'installation de torch

Lorsque vous installez une version différente de torch, vous pouvez voir l’erreur : ImportError: libcudnn.so.9: cannot open shared object file: No such file or directory. C’est parce que torch recherche uniquement la bibliothèque cuDNN dans le chemin local.

Solution recommandée :

Réinstallez les dépendances en ajoutant --force-reinstall lors de l'installation de torch:

Python

%pip install torch --force-reinstall