Guides de l'utilisateur pour l'IA Runtime
Aperçu
Cette fonctionnalité est en aperçu public.
Migrez les charges de travail d'apprentissage profond existantes des clusters Databricks classiques vers AI Runtime, suivez l'utilisation et les coûts du GPU avec le tableau système d'utilisation facturable, et trouvez des exemples de notebooks et des correctifs pour les erreurs courantes.
Migration des charges de travail GPU classiques vers le serverless
Si vous déplacez une charge de travail de deep learning existante d'un cluster Databricks classique (avec Databricks Runtime ML) vers Serverless (avec AI Runtime), suivez les étapes suivantes :
- Remplacez le code dépendant du cluster. Supprimez toute référence à la formation distribuée basée sur Spark (par exemple,
TorchDistributor) et remplacez-les par le décorateur@distributeddeserverless_gpu. - **Mise à jour du chargement des données.** Remplacez les chemins DBFS directs par les chemins des volumes Unity Catalog (
/Volumes/...). Remplacer les opérations locales de DataFrame Spark par Spark Connect. Pour les données de streaming basées sur des fichiers provenant des volumes, utilisezUCVolumeDatasetdeserverless_gpu.data. Voir Charger des données sur AI Runtime. - Réinstallez les dépendances. Ne vous fiez pas aux bibliothèques préinstallées de Databricks Runtime ML. Ajoutez les commandes
%pip installexplicites pour tous les packages requis. - Mettre à jour les chemins des points de contrôle. Déplacer les points de contrôle de DBFS ou du stockage local vers les volumes Unity Catalog (
/Volumes/<catalog>/<schema>/<volume>/...). Pour les points de contrôle distribués, utilisezUCVolumeWriteretUCVolumeReaderdeserverless_gpu.data, qui gèrent les E/S via le NVMe local. Voir le point de contrôle du modèle. - Mettre à jour la configuration MLflow. Assurez-vous que les noms d'expérimentation utilisent des chemins absolus et configurez 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 la planifier en tant que Job.
Suivre l'utilisation et les coûts
Vous pouvez surveiller vos dépenses GPU Runtime IA en interrogeant la table système d'utilisation facturable (system.billing.usage). La query suivante renvoie l'utilisation totale pour les charges de travail GPU Serverless :
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.
AI Runtime facture par heure GPU sur le SKU d'entraînement de modèle aux prix suivants :
- H100 à la demande : 7,00 $/heure GPU (Est des États-Unis)
- A10 à la demande : 2,50 $ par heure GPU (Est des États-Unis)
Exemples de Notebooks
Les catégories de Notebooks d'exemple suivantes sont disponibles pour vous aider à start :
Catégorie | Description |
|---|---|
Affinement des grands modèles de langage, y compris les méthodes efficaces en paramètres (LoRA, QLoRA) | |
Détection d’objets, classification d’images et autres tâches de vision par ordinateur | |
Création de systèmes de recommandation à l'aide d'approches modernes de deep learning, tels que les modèles à deux tours | |
Tâches de ML traditionnelles incluant la formation de modèles XGBoost et la prévision de séries temporelles | |
Mise à l'échelle de l'entraînement sur plusieurs GPU à l'aide de l'API GPU Serverless |
Pour la liste complète, consultez les exemples de notebooks Runtime IA.
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.
ValueError : la taille de numpy.dtype a changé, cela peut indiquer une incompatibilité binaire. Attendu 96 de l'en-tête C, obtenu 88 de PyObject
L'erreur survient généralement lorsqu'il y a une incompatibilité 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 d'exécution. Cette incompatibilité est souvent due aux modifications de l'API C de NumPy et est particulièrement visible de NumPy 1.x à 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 de Serverless GPU Compute pour l’ environnement 4 et l’ environnement 3 pour des information sur les bibliothèques Python préinstallées. Si vous avez une dépendance vis-à-vis d'une version différente de NumPy, ajoutez cette dépendance à votre environnement de calcul.
PyTorch ne peut pas trouver libcudnn lors de l’installation de torch
Lorsque vous installez une version différente de torch, vous risquez de voir l'erreur : ImportError: libcudnn.so.9: cannot open shared object file: No such file or directory. Ceci est dû au fait que torch ne recherche la bibliothèque cuDNN que dans le chemin d'accès local.
Solution recommandée :
Réinstallez les dépendances en ajoutant --force-reinstall lors de l'installation de torch:
%pip install torch --force-reinstall