Aller au contenu principal
Dernière mise à jour le

Bonnes pratiques de deep learning sur Databricks

Cet article contient des conseils pour l'apprentissage profond sur Databricks et des informations sur les outils et bibliothèques intégrés conçus pour optimiser les charges de travail d'apprentissage profond, notamment :

Databricks fournit une infrastructure de deep learning préconstruite avec Databricks Runtime for Machine Learning, qui inclut les bibliothèques de deep learning les plus courantes comme TensorFlow, PyTorch et Keras. Il dispose également d'un support GPU intégré, préconfiguré, comprenant les Drivers et les bibliothèques de support.

Databricks Runtime ML inclut également toutes les fonctionnalités du Workspace Databricks, telles que la création et la gestion de clusters, la gestion des bibliothèques et de l’environnement, la gestion du code avec les dossiers Git Databricks, la prise en charge de l’automatisation, notamment Lakeflow Jobs et les APIs, ainsi que l’intégration de MLflow pour le suivi du développement des modèles, leur déploiement et leur service.

Gestion des ressources et de l'environnement​

Databricks vous aide à personnaliser votre environnement de deep learning et à maintenir la cohérence de l'environnement entre les utilisateurs.

Personnaliser l’environnement de développement​

Avec Databricks Runtime, vous pouvez personnaliser votre environnement de développement au niveau du Notebook, du cluster et du Job.

Utiliser les règles de cluster​

Vous pouvez créer des règles de cluster pour guider les data scientists vers les bons choix, tels que l'utilisation d'un cluster à nœud unique pour le développement et l'utilisation d'un cluster à mise à l'échelle automatique pour les tâches importantes.

Envisagez les GPU A100 pour les charges de travail de deep learning​

Les GPU A100 constituent un choix efficace pour de nombreuses tâches d'apprentissage profond, telles que la formation et l'ajustement de grands modèles linguistiques, le traitement du langage naturel, la détection et la classification d'objets, et les moteurs de recommandation.

  • Databricks prend en charge les GPU A100 sur tous les clouds. Pour la liste complète des types de GPU pris en charge, consultez les types d'instances pris en charge.
  • Les GPU A100 ont généralement une disponibilité limitée. Contactez votre fournisseur de cloud pour l'allocation des ressources, ou envisagez de réserver la capacité à l'avance.

Planification des GPU​

Pour optimiser l'utilisation de vos GPU pour l'entraînement et l'inférence du deep learning distribué, optimisez la planification des GPU. Consultez la planification GPU.

Bonnes pratiques pour le chargement des données​

Le stockage des données dans le cloud n'est généralement pas optimisé pour les E/S, ce qui peut être un défi pour les modèles de deep learning qui nécessitent de grands datasets. Databricks Runtime ML inclut Delta Lake pour optimiser le throughput pour les applications de deep learning.

Databricks recommande d'utiliser les tables Delta Lake pour le stockage de données. Delta Lake simplifie l'ETL et vous permet d'accéder efficacement aux données. En particulier pour les images, Delta Lake aide à optimiser l'ingestion pour l'entraînement et l'inférence. La solution de référence pour les applications d'image fournit un exemple d'optimisation de l'ETL pour les images à l'aide de Delta Lake.

Pour les très grands datasets qui ne tiennent pas en mémoire, utilisez les approches de streaming :

Bonnes pratiques pour l'entraînement des modèles de deep learning​

Databricks recommande d'utiliser Databricks Runtime for Machine Learning, le suivi MLflow et l'autologging pour toutes les tâches d'entraînement de modèles.

Start with a Single Node cluster​

Un cluster GPU à nœud unique (Driver uniquement) est généralement le plus rapide et le plus rentable pour le développement de modèles d'apprentissage profond. Un nœud avec 4 GPU est susceptible d'être plus rapide pour l'entraînement de modèles d'apprentissage profond que 4 nœuds worker avec 1 GPU chacun. C'est parce que la formation distribuée entraîne une surcharge de communication réseau.

Un cluster à nœud unique est une bonne option pendant le développement rapide et itératif et pour l'entraînement de modèles sur des données de petite à moyenne taille. Si votre dataset est suffisamment grand pour rendre l'entraînement lent sur une seule machine, envisagez de passer au multi-GPU et même au compute distribué.

Utilisez TensorBoard et les métriques de clusters pour surveiller le processus de formation.​

TensorBoard est préinstallé dans Databricks Runtime ML. Vous pouvez l'utiliser dans un notebook ou dans un tab séparé. Voir TensorBoard pour plus de détails.

Les métriques de clusters sont disponibles dans tous les Databricks Runtimes. Vous pouvez examiner l'utilisation du réseau, du processeur et de la mémoire pour détecter les goulots d'étranglement. Consultez les métriques de clusters pour plus de détails.

Optimiser les performances pour le deep learning​

Vous pouvez, et devriez, utiliser des techniques d'optimisation des performances de l'apprentissage profond sur Databricks.

Arrêt anticipé​

L'arrêt anticipé surveille la valeur d'une métrique calculée sur l'ensemble de validation et arrête l'entraînement lorsque la métrique cesse de s'améliorer. C'est une meilleure approche que de deviner un bon nombre d'époques à achever. Chaque bibliothèque de deep learning fournit une API native pour l'arrêt anticipé ; par exemple, consultez les API de rappel EarlyStopping pour TensorFlow/Keras et pour PyTorch Lightning. Pour un exemple de Notebook, consultez l'exemple de Notebook TensorFlow Keras.

Réglage de la taille de batch​

L'ajustement de la taille des batchs permet d'optimiser l'utilisation du GPU. Si la taille du batch est trop petite, les calculs ne peuvent pas utiliser pleinement les capacités du GPU. Vous pouvez utiliser les métriques de cluster pour afficher les métriques GPU.

Ajustez la taille de batch conjointement avec le taux d'apprentissage. Une bonne règle de base est que, lorsque vous augmentez la taille de batch de n, vous augmentez le taux d'apprentissage de la racine carrée de n. Lorsque vous ajustez manuellement, essayez de modifier la taille de batch par un facteur de 2 ou 0,5. Continuez ensuite l'ajustement pour optimiser les performances, soit manuellement, soit en testant une variété d'hyperparamètres à l'aide d'un outil automatisé tel que Optuna.

Apprentissage par transfert​

Avec l'apprentissage par transfert, vous start avec un modèle pré-entraîné et le modifiez selon les besoins de votre application. L'apprentissage par transfert peut réduire considérablement le temps nécessaire pour entraîner et ajuster un nouveau modèle. Consultez Featurization pour l'apprentissage par transfert pour plus d'informations et un exemple.

Passer à la formation distribuée​

Databricks Runtime ML inclut TorchDistributor, DeepSpeed et Ray pour faciliter le passage de l'entraînement à nœud unique à l'entraînement distribué.

TorchDistributor​

TorchDistributor est un module open source dans PySpark qui facilite l'entraînement distribué avec PyTorch sur les clusters Spark, ce qui vous permet de lancer des Jobs d'entraînement PyTorch sous forme de Jobs Spark. Voir Entraînement distribué avec TorchDistributor.

Optuna​

Optuna fournit un ajustement adaptatif des hyperparamètres pour le Machine Learning.

Bonnes pratiques pour l'inférence​

Cette section contient des conseils généraux sur l’utilisation des modèles pour l’inférence avec Databricks.

  • Pour minimiser les coûts, envisagez les processeurs et les GPU optimisés pour l'inférence, tels que les instances Amazon EC2 G4 et G5. Il n'y a pas de recommandation claire, car le meilleur choix dépend de la taille du modèle, des dimensions des données et d'autres variables.

  • Utilisez MLflow pour simplifier le déploiement et le service de modèles. MLflow peut enregistrer n'importe quel modèle de deep learning, y compris la logique de prétraitement et de post-traitement personnalisée. Les modèles dans Unity Catalog ou les modèles enregistrés dans le Workspace Model Registry peuvent être déployés pour l'inférence par batch, en streaming ou en ligne.

Service en ligne​

La meilleure option pour une mise à disposition à faible latence est la mise à disposition en ligne derrière une API REST. Databricks propose Model Serving pour l'inférence en ligne. Model Serving fournit une interface unifiée pour déployer, gouverner et query les modèles d'IA et prend en charge le Model Serving pour les éléments suivants :

  • Modèles personnalisés. Ce sont des modèles Python empaquetés au format MLflow. Les exemples incluent scikit-learn, XGBoost, PyTorch et les modèles de transformateur Hugging Face.
  • Des modèles ouverts de pointe mis à disposition par les Foundation Model APIs. Ces modèles sont des architectures de modèle de fondation organisées qui prennent en charge l’inférence optimisée. Par exemple, des modèles de base comme Meta-Llama-3.3-70B-Instruct, GTE-Large et Gemma-3-12B sont disponibles pour une utilisation immédiate avec un paiement par jeton . Pour les charges de travail qui nécessitent des garanties de performance et des variantes de modèles ajustés, vous pouvez les déployer avec un throughput de provisionnement .
  • Modèles externes. Ce sont des modèles qui sont hébergés en dehors de Databricks. Par exemple, des modèles d'IA générative comme GPT-4 d'OpenAI, Claude d'Anthropic et d'autres. Les Endpoints qui servent ces modèles peuvent être gérés de manière centralisée et les clients peuvent établir des limites de taux et des contrôles d'accès pour ceux-ci.

Par ailleurs, MLflow fournit des API pour le déploiement vers divers services gérés pour l'inférence en ligne, ainsi que des API pour la création de conteneurs Docker pour des solutions de diffusion personnalisées.

Inférence par batch et streaming​

La notation par batch et en streaming prend en charge une notation à haut throughput et à faible coût, avec des latences de l’ordre de quelques minutes. Pour plus d’information, consultez Déployer des modèles pour l’inférence par batch et la prédiction.

  • Si vous prévoyez d'accéder aux données d'inférence plus d'une fois, envisagez de créer un Job de prétraitement pour l'ETL des données dans une table Delta Lake avant d'exécuter le Job d'inférence. De cette façon, le coût de l'ingestion et de la préparation des données est réparti sur plusieurs lectures des données. Séparer le prétraitement de l'inférence vous permet également de sélectionner du matériel différent pour chaque Job afin d'optimiser les coûts et les performances. Par exemple, vous pouvez utiliser des CPU pour l'ETL et des GPU pour l'inférence.
  • Utilisez les UDF Spark Pandas pour mettre à l'échelle l'inférence par lot et en streaming sur un cluster.
Sur cette page