Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Important
AI Runtime pour les tâches à nœud unique est disponible en préversion publique. L’API d’entraînement distribuée pour les charges de travail multi-GPU reste en version bêta.
Cette page inclut des informations de migration, des liens vers des exemples de notebooks et des informations de dépannage.
Migration de charges de travail GPU classiques vers serverless
Si vous déplacez une charge de travail d’apprentissage profond existante d’un cluster Databricks classique (avec Databricks Runtime ML) vers serverless (avec AI Runtime), procédez comme suit :
- Remplacez le code dépendant du cluster. Supprimez les références à l’entraînement distribué basé sur Spark (par exemple
TorchDistributor) et remplacez-les par le décorateur@distributeddeserverless_gpu. - Mettez à jour le chargement des données. Remplacez les chemins DBFS directs par les chemins de volumes du Unity Catalog (
/Volumes/...). Remplacez les opérations spark DataFrame locales par Spark Connect. - Réinstallez les dépendances. Ne vous fiez pas aux bibliothèques préinstallées Databricks Runtime ML. Ajoutez des commandes explicites
%pip installpour tous les packages requis. - Mettez à jour les chemins de point de contrôle. Déplacez les points de contrôle du stockage DBFS ou local vers les volumes du catalogue Unity (
/Volumes/<catalog>/<schema>/<volume>/...). - Mettez à jour la configuration de MLflow. Vérifiez que les noms d’expériences utilisent des chemins absolus et configurent les noms d’exécution afin qu’ils puissent être facilement redémarrés.
- Testez d’abord de manière interactive. Validez votre charge de travail dans un notebook interactif avant de le planifier en tant que travail.
Suivre l’utilisation et les coûts
Vous pouvez surveiller vos dépenses GPU d’IA Runtime en interrogeant la table du système de consommation facturable (system.billing.usage). La requête suivante renvoie l'utilisation totale des charges de travail GPU sans serveur :
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 du système d’utilisation facturable.
Frais du runtime IA par heure GPU sur la référence SKU Model Training aux prix suivants :
- H100 à la demande : 7,00 $ /HEURE GPU (USA Est)
- A10 à la demande : 4,90 $/HEURE GPU (USA Est)
Exemples de notebooks
Les catégories suivantes d’exemples de notebooks sont disponibles pour vous aider à commencer :
| Catégorie | Description |
|---|---|
| Modèles de langage volumineux (LLMs) | Réglage des modèles de langage volumineux, notamment des méthodes efficaces en paramètres (LoRA, QLoRA) |
| Vision par ordinateur | Détection d’objets, classification d’images et autres tâches de vision par ordinateur |
| Systèmes de recommandation Deep Learning | Création de systèmes de recommandation à l’aide d’approches d’apprentissage profond modernes comme des modèles à deux tours |
| ML classique | Tâches ML traditionnelles, notamment l’entraînement du modèle XGBoost et les prévisions de série chronologique |
| Apprentissage distribué multi-GPU | Mise à l’échelle de l’entraînement sur plusieurs GPU à l’aide de l’API GPU serverless |
Pour obtenir la liste complète, consultez les cahiers de notes exemples d'AI Runtime.
Résolution des problèmes
Genie Code peut vous aider à diagnostiquer et suggérer des correctifs pour les erreurs d’installation de bibliothèque. Consultez Utiliser Le code Genie pour déboguer les erreurs d’environnement de calcul.
ValueError : la taille numpy.dtype a changé, peut indiquer une incompatibilité binaire. Attendu 96 à partir de l’en-tête C, a obtenu 88 de PyObject
L’erreur se produit généralement lorsqu’il existe une incompatibilité dans les versions NumPy utilisées lors de la compilation d’un package dépendant et de la version NumPy actuellement installée dans l’environnement d’exécution. Cette incompatibilité se produit souvent en raison des modifications apportées à l’API C de NumPy et est particulièrement notable de NumPy 1.x à 2.x. Cette erreur indique que le package Python installé dans le notebook a peut-être changé la version de NumPy.
Solution recommandée :
Vérifiez la version numPy dans le runtime et vérifiez qu’elle est compatible avec vos packages. Consultez les notes de publication du calcul GPU serverless pour l’environnement 4 et l’environnement 3 pour plus d’informations sur les bibliothèques Python préinstallées. Si vous avez une dépendance sur une autre version de NumPy, ajoutez cette dépendance à votre environnement de calcul.
PyTorch ne peut pas trouver libcudnn lors de l’installation de torche
Lorsque vous installez une autre version de torch, vous pouvez voir l’erreur suivante : ImportError: libcudnn.so.9: cannot open shared object file: No such file or directory. Cela est dû au fait que torch recherche uniquement la bibliothèque cuDNN dans le répertoire local.
Solution recommandée :
Réinstallez les dépendances en ajoutant --force-reinstall lors de l’installation torch:
%pip install torch --force-reinstall