Aller au contenu principal
Dernière mise à jour le

Guide de debugging pour Model Serving

Cet article montre les étapes de debugging pour les problèmes courants que les utilisateurs peuvent rencontrer lorsqu'ils travaillent avec des endpoints de mise en service de modèles. Les problèmes courants peuvent inclure des erreurs rencontrées par les utilisateurs lorsque l'Endpoint ne parvient pas à s'initialiser ou à start, des échecs de build liés au conteneur, ou des problèmes lors de l'Opération ou de l'exécution du modèle sur l'Endpoint.

:::tip Validez avant le debugging Vous rencontrez des problèmes de déploiement ? Start par une validation avant le déploiement pour identifier les problèmes courants avant qu’ils ne surviennent. :::

Déboguez votre build de conteneur​

Databricks vous recommande de consulter les Logs pour le debugging et le dépannage des erreurs dans vos workloads de diffusion de modèles. Consultez Surveiller la qualité du modèle et la santé de l'Endpoint pour plus d'information sur les Logs et la façon de les consulter.

Les logs d'événements (cliquez sur l'onglet Événements ) dans l'interface utilisateur du Workspace contiennent des informations sur la progression d'une construction de conteneur. Une construction de conteneur réussie est mise en évidence par un type d'événement SERVED_ENTITY_CONTAINER_EVENT et un message Container image creation finished successfully. Si vous ne voyez aucun événement de build ou message après une heure de création de l'endpoint, contactez le support Databricks pour obtenir de l'aide.

Si votre build est réussi, mais que vous rencontrez d'autres erreurs, consultez Déboguer après la réussite de la création du conteneur. Si votre build échoue, consultez Déboguer après l'échec du build du conteneur.

Déboguer après la réussite de la construction du conteneur​

Même si le conteneur se construit avec succès, il peut y avoir des problèmes lorsque vous exécutez le modèle ou pendant l'Opération de l'Endpoint lui-même. Les sous-sections suivantes détaillent les problèmes courants et la manière de les résoudre.

remarque

Si le code de votre modèle renvoie MlflowException erreurs, attendez-vous à ce que le code de réponse soit mappé à une réponse 4xx. Databricks considère que ces erreurs de code de modèle sont des erreurs causées par les clients, car elles peuvent être résolues en fonction du message d'erreur résultant. Les codes d'erreur 5xx sont réservés pour communiquer les erreurs où Databricks est en cause.

Dépendance manquante​

Vous pouvez obtenir une erreur de type An error occurred while loading the model. No module named <module-name>., ce qui peut indiquer qu’une dépendance est manquante dans le conteneur. Vérifiez que vous avez correctement désigné toutes les dépendances qui doivent être incluses dans la création du conteneur. Portez une attention particulière aux bibliothèques personnalisées et assurez-vous que les fichiers .whl sont inclus en tant qu'artefacts.

Le modèle échoue ou expire lorsque des requêtes sont envoyées à l'Endpoint​

Vous pourriez recevoir une erreur comme Encountered an unexpected error while evaluating the model. Verify that the input is compatible with the model for inference. lorsque predict() est appelé sur votre modèle.

Cette erreur peut indiquer un problème de code dans la fonction predict(). Databricks vous recommande de charger le modèle de MLflow dans un Notebook et de l’appeler. Cela met en évidence les problèmes dans la fonction predict(), et vous pouvez voir où la défaillance se produit au sein de la méthode.

Analyse des causes fondamentales des requêtes échouées​

Si une requête vers un Endpoint échoue, vous pouvez effectuer une analyse des causes profondes en utilisant des tables d'inférence. Si elles sont activées, les tables d'inférence enregistrent automatiquement toutes les requêtes et réponses vers votre Endpoint dans une table Unity Catalog afin que vous puissiez les interroger.

Pour interroger les tables d'inférence :

  1. Dans votre workspace, accédez à l'onglet Serving et sélectionnez le nom de votre endpoint.

  2. Dans la section Tables d'inférences , trouvez le nom complet de la table d'inférence. Par exemple, my-catalog.my-schema.my-table.

  3. Exécutez ce qui suit dans un Notebook Databricks :

    Python
    %sql
    SELECT * FROM my-catalog.my-schema.my-table

  4. Afficher et filtrer sur les colonnes telles que request, response, request_time et status_code pour comprendre les requêtes et affiner les résultats.

    Python
    %sql
    SELECT * FROM my-catalog.my-schema.my-table
    WHERE status_code != 200

  5. Si vous avez activé le traçage des agents pour les agents IA, consultez la colonne **Réponse** pour afficher les traces détaillées. Consultez Activer les tables d'inférence pour les agents IA.

Le Workspace dépasse la simultanéité provisionnée​

Vous pourriez recevoir une erreur Workspace exceeded provisioned concurrency quota. Cela indique que vous avez atteint votre quota de Workspace pour la simultanéité provisionnée. Consultez les limites et régions de Model Serving pour plus d'information sur les limites de simultanéité.

Vous pouvez libérer ce quota en supprimant ou en arrêtant les Endpoints inutilisés.

Cette limite peut être augmentée en fonction de la disponibilité régionale. Contactez votre équipe de compte Databricks et fournissez votre ID de Workspace pour demander une augmentation de la simultanéité.

Le Workspace dépasse la limite de requêtes parallèles​

Vous pourriez recevoir l'erreur 429 suivante : Exceeded max number of parallel requests. Please contact your Databricks representative to increase the limit. Cette limite indique que vous avez atteint la limite du workspace sur le nombre maximal de requêtes pouvant être envoyées en parallèle. Consultez les limites et régions de Model Serving pour plus d'information sur cette limite.

Databricks recommande de passer aux endpoints optimisés pour l'itinéraire, où cette limite a été supprimée. Si vous ne pouvez pas passer à des Endpoints optimisés en termes de routage, vous pouvez soit réduire le nombre de clients envoyant des requêtes d'inférence, soit contacter votre représentant Databricks pour une augmentation de quota.

Trop de requêtes simultanées​

Vous pourriez recevoir l'erreur 429 suivante : Too many concurrent requests. Consider increasing the provisioned concurrency of the served entity. Cette erreur indique que la concurrence provisionnée actuelle de votre Endpoint ne peut pas gérer le volume de trafic entrant. Si vous avez activé la mise à l'échelle automatique pour votre Endpoint, le système provisionnera automatiquement une concurrence supplémentaire jusqu'à la limite configurée de l'Endpoint pour gérer la charge accrue. Si la mise à l'échelle automatique n'est pas activée, envisagez d'augmenter manuellement la concurrence provisionnée ou d'activer la mise à l'échelle automatique pour gérer les pics de trafic.

Déboguer après l'échec de la construction du conteneur​

Cette section décrit en détail les problèmes qui peuvent survenir lorsque votre build échoue.

OSError: [Errno 28] No space left on device​

L'erreur No space left peut être due à un nombre excessif d'artefacts volumineux qui sont journalisés inutilement avec le modèle. Vérifiez dans MLflow que les artefacts superflus ne sont pas journalisés avec le modèle et essayez de redéployer le package allégé.

Échec de la compilation en raison du manque de disponibilité du GPU​

En raison des restrictions concernant l'approvisionnement et la disponibilité des GPU, votre build GPU peut échouer avec cette erreur : Build could not start due to an internal error - please contact your Databricks representative..

Veuillez contacter l'équipe de votre compte Databricks pour obtenir de l'aide. En fonction de la disponibilité régionale, l'équipe peut provisionner davantage de ressources GPU.

Versions des packages de bibliothèque installés​

Databricks vous recommande de définir toutes les bibliothèques importantes comme dépendances de modèle pour garantir un comportement de modèle cohérent et reproductible dans tous les environnements. Dans les logs de build, vous pouvez confirmer les versions de package qui sont correctement installées.

  • Pour les versions MLflow, si vous n'avez pas spécifié de version, Model Serving utilise la dernière version.
  • Pour le service GPU personnalisé, Model Serving installe les versions recommandées de cuda et cuDNN conformément à la documentation publique de PyTorch et Tensorflow.

Journaliser les modèles qui nécessitent flash-attn​

Si vous enregistrez un modèle qui requiert flash-attn, Databricks vous recommande d'utiliser une version personnalisée de roue de flash-attn. Sinon, des erreurs de compilation telles que ModuleNotFoundError: No module named 'torch' peuvent en résulter.

Pour utiliser une version de roue personnalisée de flash-attn, spécifiez toutes les exigences pip sous forme de liste et transmettez-les en tant que paramètre à votre fonction mlflow.transformers.log_model. Vous devez également spécifier les versions de pytorch, torch et torchvision compatibles avec la version CUDA spécifiée dans votre wheel flash attn.

Par exemple, Databricks recommande d'utiliser les versions et les roues suivantes pour CUDA 11.8 :

Python

logged_model=mlflow.transformers.log_model(
transformers_model=test_pipeline,
       artifact_path="artifact_path",
       pip_requirements=["--extra-index-url https://download.pytorch.org/whl/cu118", "mlflow==2.13.1", "setuptools<70.0.0", "torch==2.0.1+cu118", "accelerate==0.31.0", "astunparse==1.6.3", "bcrypt==3.2.0", "boto3==1.34.39", "configparser==5.2.0", "defusedxml==0.7.1", "dill==0.3.6", "google-cloud-storage==2.10.0", "ipython==8.15.0", "lz4==4.3.2", "nvidia-ml-py==12.555.43", "optree==0.12.1", "pandas==1.5.3", "pyopenssl==23.2.0", "pytesseract==0.3.10", "scikit-learn==1.3.0", "sentencepiece==0.1.99", "torchvision==0.15.2+cu118", "transformers==4.41.2", "https://github.com/Dao-AILab/flash-attention/releases/download/v2.5.8/flash_attn-2.5.8+cu118torch2.0cxx11abiFALSE-cp311-cp311-linux_x86_64.whl"],
       input_example=input_example,
       registered_model_name=registered_model_name)
Sur cette page