Dépannage

Il peut être difficile de trouver la cause des erreurs qui surviennent lors de l'entraînement d'un modèle ou de l'obtention de prédictions dans le cloud. Cette page vous explique comment identifier et déboguer les problèmes que vous rencontrez sur AI Platform Training. Si vous rencontrez des problèmes avec le framework de machine learning que vous utilisez, consultez plutôt la documentation du framework de machine learning.

Outil de ligne de commande

ERROR: (gcloud) Invalid choice: 'ai-platform'.

Cette erreur signifie que vous devez mettre à jour gcloud. Pour mettre à jour gcloud, exécutez la commande suivante :

gcloud components update

ERROR: (gcloud) unrecognized arguments: --framework=SCIKIT_LEARN.

Cette erreur signifie que vous devez mettre à jour gcloud. Pour mettre à jour gcloud, exécutez la commande suivante :

gcloud components update

ERROR: (gcloud) unrecognized arguments: --framework=XGBOOST.

Cette erreur signifie que vous devez mettre à jour gcloud. Pour mettre à jour gcloud, exécutez la commande suivante :

gcloud components update

ERROR: (gcloud) Failed to load model: Could not load the model: /tmp/model/0001/model.pkl. '\\x03'. (Error code: 0)

Ce message d'erreur signifie que la bibliothèque qui a été utilisée pour exporter le modèle n'était pas la bonne. Pour y remédier, réexportez le modèle en utilisant la bibliothèque appropriée. Par exemple, exportez des modèles de la forme model.pkl avec la bibliothèque pickle et les modèles de la forme model.joblib avec la bibliothèque joblib.

ERROR: (gcloud.ai-platform.jobs.submit.prediction) argument --data-format: Invalid choice: 'json'.

Cette erreur signifie que vous avez spécifié json comme valeur de l'indicateur --data-format lors de l'envoi d'une tâche de prédiction par lot. Pour pouvoir utiliser le format de données JSON, vous devez indiquer text comme valeur de l'indicateur --data-format.

Versions Python

ERROR: Bad model detected with error:  "Failed to load model: Could not load the
model: /tmp/model/0001/model.pkl. unsupported pickle protocol: 3. Please make
sure the model was exported using python 2. Otherwise, please specify the
correct 'python_version' parameter when deploying the model. Currently,
'python_version' accepts 2.7 and 3.5. (Error code: 0)"

Ce message d'erreur signifie qu'un fichier de modèle exporté avec Python 3 a été déployé sur une ressource de version de modèle AI Platform Training paramétrée sur Python 2.7.

Pour remédier à ce problème, procédez comme suit :

• Créez une ressource de version de modèle en définissant "python_version" sur "3.5".
• Déployez le même fichier de modèle sur la nouvelle ressource de version de modèle.

La commande virtualenv est introuvable.

Si vous rencontrez cette erreur lorsque vous tentez d'activer virtualenv, une solution consiste à ajouter le répertoire contenant virtualenv à votre variable d'environnement $PATH. La modification de cette variable vous permet d'utiliser les commandes virtualenv sans avoir besoin de saisir leur chemin d'accès complet.

Pour commencer, installez virtualenv en exécutant la commande suivante :

pip install --user --upgrade virtualenv

Le programme d'installation vous invite à modifier la variable d'environnement $PATH et indique le chemin d'accès au script virtualenv. Sur macOS, ce chemin d'accès ressemble à ceci : /Users/[YOUR-USERNAME]/Library/Python/[YOUR-PYTHON-VERSION]/bin.

Ouvrez le fichier dans lequel l'interface système charge les variables d'environnement. En règle générale, il s'agit du fichier ~/.bashrc ou ~/.bash_profile dans macOS.

Ajoutez la ligne suivante, en remplaçant [VALUES-IN-BRACKETS] par les valeurs appropriées :

export PATH=$PATH:/Users/[YOUR-USERNAME]/Library/Python/[YOUR-PYTHON-VERSION]/bin

Enfin, exécutez la commande suivante pour charger votre fichier .bashrc ou .bash_profile mis à jour :

source ~/.bashrc

Utiliser des journaux de tâches

Les journaux de tâches enregistrés par Cloud Logging constituent un bon point de départ pour la résolution des problèmes.

Journalisation des différents types d'opérations

Votre expérience de journalisation varie selon le type d'opération, comme illustré dans les sections ci-dessous.

Journaux d'entraînement

Toutes vos tâches d'entraînement sont enregistrées. Les journaux incluent les événements du service d'entraînement et de votre application d'entraînement. Vous pouvez placer des événements de journalisation dans votre application grâce aux bibliothèques Python standards (la bibliothèque logging, par exemple). AI Platform Training enregistre tous les messages de journalisation depuis votre application. Tous les messages envoyés à stderr sont automatiquement enregistrés dans l'entrée de votre projet dans Cloud Logging.

Journaux de prédiction par lot

Toutes vos tâches de prédiction par lot sont enregistrées.

Journaux de prédiction en ligne

Vos requêtes de prédiction en ligne ne génèrent pas de journaux par défaut. Vous pouvez activer Cloud Logging lorsque vous créez une ressource de modèle :

gcloud

Incluez l'indicateur --enable-logging lorsque vous exécutez la commande gcloud ai-platform models create.

Python

Définissez onlinePredictionLogging sur True dans la ressource Model que vous utilisez pour appeler projects.models.create.

Trouver les journaux

Les journaux de tâches contiennent tous les événements de l'opération, y compris les événements de tous les processus de votre cluster lorsque vous effectuez un entraînement distribué. Si vous exécutez une tâche d'entraînement distribué, les journaux au niveau de la tâche sont signalés pour le processus du nœud maître. La première étape de la résolution d'une erreur consiste généralement à examiner les journaux de ce processus, en filtrant les événements enregistrés pour les autres processus de votre cluster. Les exemples de cette section illustrent ce type de filtre.

Vous pouvez filtrer les journaux à partir de la ligne de commande ou dans la section Cloud Logging de Google Cloud Console. Dans les deux cas, utilisez les valeurs de métadonnées suivantes dans votre filtre si nécessaire :

Élément de métadonnées	Filtrer les journaux affichant les événements pour lesquels cet élément est…
resource.type	égal à "cloud_ml_job".
resource.labels.job_id	égal au nom de votre tâche.
resource.labels.task_name	égal à "master-replica-0" pour lire uniquement les entrées de journal de votre nœud de calcul maître.
severity	supérieur ou égal à ERROR pour lire uniquement les entrées de journal correspondant à des conditions d'erreur.

Ligne de commande

Exécutez gcloud beta logging read pour construire une requête répondant à vos besoins. Vous trouverez quelques exemples ci-dessous.

Chaque exemple s'appuie sur les variables d'environnement suivantes :

PROJECT="my-project-name"
JOB="my_job_name"

Vous pouvez remplacer ces variables par des chaînes littérales si vous le souhaitez.

Remarque : Certains de ces exemples montrent des commandes comportant le code --project flag. Le plus souvent, vous devez utiliser un projet que vous avez configuré comme projet par défaut sur votre ordinateur de développement. Dans ce cas, vous pouvez omettre cet indicateur : il n'est obligatoire que si vous demandez les journaux d'un projet qui n'est pas votre projet par défaut actuel.

Pour générer une sortie-écran de vos journaux de tâche, exécutez cette commande :

gcloud ai-platform jobs stream-logs $JOB

Vous pouvez consulter l'intégralité des options disponibles pour la commande gcloud ai-platform jobs stream-logs.

Pour générer une sortie-écran du journal correspondant au nœud de calcul maître, exécutez cette commande :

gcloud beta logging read --project=${PROJECT} "resource.type=\"ml_job\" and resource.labels.job_id=${JOB} and resource.labels.task_name=\"master-replica-0\""

Pour générer une sortie-écran uniquement pour les erreurs détectées sur le nœud de calcul maître, exécutez cette commande :

gcloud beta logging read --project=${PROJECT} "resource.type=\"ml_job\" and resource.labels.job_id=${JOB} and resource.labels.task_name=\"master-replica-0\" and severity>=ERROR"

Les exemples précédents représentent les cas de filtrage les plus courants pour les journaux de votre tâche d'entraînement AI Platform Training. Cloud Logging fournit de nombreuses options de filtrage puissantes que vous pouvez utiliser si vous avez besoin d'affiner votre recherche. La documentation sur le filtrage avancé décrit ces options en détail.

Console

1. Ouvrez la page Tâches d'AI Platform Training dans la console Google Cloud.

   Accéder aux tâches dans la console Google Cloud

2. Sélectionnez la tâche qui a échoué dans la liste affichée sur la page Jobs (Tâches) pour en consulter les détails.

1. Cliquez sur Afficher les journaux pour ouvrir Cloud Logging.

Vous pouvez également accéder directement à Cloud Logging, mais cette procédure implique de rechercher votre tâche :

1. Développez le sélecteur de ressources.
2. Dans la liste des ressources, développez "Tâche Cloud ML".
3. Recherchez le nom de votre tâche dans la liste "ID de tâche". (Vous pouvez saisir les premières lettres du nom dans le champ de recherche pour affiner les résultats.)
4. Développez la tâche et sélectionnez master-replica-0 dans la liste des tâches.

Obtenir des informations à partir des journaux

Une fois que vous avez trouvé le journal correspondant à votre tâche et que vous l'avez filtré sur master-replica-0, vous pouvez examiner les événements enregistrés afin d'identifier la source du problème. Vous devez suivre la procédure de débogage Python standard, mais gardez à l'esprit les points suivants :

• Les événements possèdent plusieurs niveaux de gravité. Vous pouvez appliquer un filtre pour n'afficher que les événements d'un certain niveau (par exemple, les erreurs, ou encore les erreurs et les avertissements).
• Un problème entraînant la fermeture de votre application d'entraînement avec une condition d'erreur non récupérable (code renvoyé supérieur à 0) est enregistré en tant qu'exception, précédée de la trace de la pile :

• Pour obtenir plus d'informations, développez les objets dans le message JSON enregistré (indiqué par une flèche orientée vers la droite et le contenu répertorié en tant que {...}). Par exemple, vous pouvez développer jsonPayload pour afficher la trace de la pile sous une forme plus lisible que celle indiquée dans la description de l'erreur principale :

• Certaines erreurs indiquent des instances d'erreurs renouvelables. Elles n'incluent généralement pas de trace de la pile, et leur diagnostic peut être plus difficile à établir.

Tirer pleinement parti de la journalisation

Le service d'entraînement AI Platform Training enregistre automatiquement les événements suivants :

• Informations sur l'état interne au service
• Messages envoyés par votre application d'entraînement à stderr
• Texte de sortie envoyé par votre application d'entraînement à stdout

Vous pouvez faciliter la résolution des problèmes de votre application d'entraînement en suivant les bonnes pratiques de programmation ci-dessous :

• Envoyez des messages pertinents à stderr (avec journalisation par exemple).
• Relevez l'exception la plus logique et la plus descriptive en cas de problème.
• Ajoutez des chaînes descriptives aux objets de l'exception.

La documentation Python fournit plus d'informations sur les exceptions.

Résolution des problèmes relatifs à l'entraînement

Cette section décrit les concepts et les conditions d'erreur qui s'appliquent aux tâches d'entraînement.

Comprendre les codes renvoyés pour les applications d'entraînement

Votre tâche d'entraînement dans le cloud est contrôlée par le programme principal qui s'exécute sur le processus du nœud maître de votre cluster d'entraînement :

• Si vous effectuez un entraînement dans un processus unique (non distribué), vous ne disposez que d'un seul nœud de calcul, considéré comme maître.
• Votre programme principal correspond à la fonction __main__ de votre application d'entraînement TensorFlow.
• Le service d'entraînement d'AI Platform Training exécute votre application d'entraînement jusqu'à ce qu'elle aboutisse ou qu'elle rencontre une erreur non récupérable. Cela signifie qu'il peut redémarrer les processus si des erreurs renouvelables se produisent.

Le service d'entraînement gère vos processus. La fermeture du programme est gérée en fonction du code renvoyé par votre processus de nœud maître :

Code renvoyé	Signification	Réponse d'AI Platform Training
0	Application exécutée avec succès	Les ressources liées à la tâche sont fermées et libérées
1 - 128	Erreur non récupérable	L'exécution de la tâche est terminée et l'erreur est enregistrée

Vous n'avez aucune opération à effectuer concernant le code de retour de votre fonction __main__. Python renvoie automatiquement zéro à la fin de l'exécution réalisée avec succès et renvoie un code positif lorsqu'il rencontre une exception non gérée. Si vous avez l'habitude de définir des codes de retour spécifiques pour vos objets d'exception (une pratique valide mais peu commune), cela n'interfère pas avec votre tâche AI Platform Training, tant que vous suivez le modèle du tableau ci-dessus. Même dans ce cas, le code client n'indique généralement pas directement les erreurs renouvelables, qui proviennent de l'environnement d'exploitation.

Gérer des conditions d'erreur spécifiques

Cette section fournit des conseils sur des conditions d'erreur spécifiques, connues pour avoir une incidence sur certains utilisateurs.

Ressource épuisée

La demande en GPU et ressources de calcul est importante dans la région us-central1. Il est possible que le message d'erreur suivant s'affiche dans les journaux de votre tâche : Resources are insufficient in region: <region>. Please try a different region..

Pour contourner ce problème, essayez d’utiliser une autre région ou réessayez plus tard.

L'exécution de l'application d'entraînement reste en suspens sans progresser

Certaines situations peuvent entraîner l'exécution ininterrompue de votre application d'entraînement sans que la tâche d'entraînement ne progresse. Ce blocage peut se produire lorsqu'un appel attend une ressource qui ne peut être rendue disponible. Vous pouvez atténuer ce problème en configurant un délai avant expiration pour votre application d'entraînement.

Configurer un délai avant expiration pour votre application d'entraînement

Vous pouvez définir un délai avant expiration, exprimé en millisecondes, soit au moment de la création de votre session, soit au moment de l'exécution d'une étape de votre graphique :

• Définissez la valeur de délai avant expiration souhaitée à l'aide du paramètre config au moment de la création de l'objet Session :

  sess = tf.Session(config=tf.ConfigProto(operation_timeout_in_ms=500))
  

• Définissez le délai avant expiration souhaité pour un seul appel à Session.run à l'aide du paramètre options :

  v = session.run(fetches, options=tf.RunOptions(timeout_in_ms=500))
  

Consultez le Documentation sur les sessions TensorFlow pour en savoir plus.

Fermeture du programme avec un code -9

Si le code de sortie -9 est renvoyé de manière cohérente, il se peut que votre application d'entraînement utilise plus de mémoire que celle allouée à son processus. Pour corriger cette erreur, réduisez l'utilisation de la mémoire, servez-vous de types de machines avec plus de mémoire, ou combinez ces deux solutions.

• Vérifiez si votre graphique et votre application d'entraînement présentent des opérations qui utilisent plus de mémoire que prévu. La complexité des données et des opérations dans votre graphique de calcul a une incidence sur l'utilisation de la mémoire.
• L'augmentation de la mémoire allouée à votre tâche peut exiger une certaine attention :
  • Si vous utilisez un niveau d'évolutivité défini, vous ne pouvez pas augmenter la part de mémoire allouée par machine sans ajouter de machines à votre ensemble. Vous devez passer au niveau personnalisé et définir vous-même les types de machines dans le cluster.
  • La configuration précise de chaque type de machine défini est susceptible d'être modifiée, mais vous pouvez effectuer des comparaisons approximatives. Vous trouverez un tableau comparatif des types de machines sur la page relative aux concepts d'entraînement.
  • Lors du test des types de machines pour allouer la part de mémoire appropriée, vous pouvez utiliser une seule machine ou un cluster de taille réduite pour minimiser les frais encourus.

Fermeture du programme avec un code -15

En règle générale, un code de sortie -15 indique une maintenance sur le système. Il s'agit d'une erreur renouvelable, donc votre processus devrait redémarrer automatiquement.

Tâche mise en file d'attente depuis longtemps

Si l'état d'une tâche d'entraînement est QUEUED pendant une période prolongée, il se peut que vous ayez dépassé votre quota de requêtes de tâches.

AI Platform Training démarre les tâches d'entraînement en fonction de leur date de création, en appliquant la méthode "premier entré, premier sorti". Si votre tâche est mise en file d'attente, cela signifie généralement que l'intégralité du quota de projet est utilisé par d'autres tâches soumises avant que votre tâche ou la première tâche de la file d'attente ne demande plus d'unités de machine learning/de GPU que le quota disponible.

La raison derrière la mise en file d'attente d'une tâche est enregistrée dans les journaux d'entraînement. Recherchez dans le journal les messages similaires à la requête suivante :

This job is number 2 in the queue and requires
4.000000 ML units and 0 GPUs. The project is using 4.000000 ML units out of 4
allowed and 0 GPUs out of 10 allowed.

Le message explique l'emplacement actuel de votre tâche dans la file d'attente, ainsi que l'utilisation et le quota actuels du projet.

Veuillez prendre en compte que la raison justifiant la mise en file d'attente ne sera enregistrée que pour les dix premières tâches, dans l'ordre de leur création.

Si vous avez régulièrement besoin d'un nombre de requêtes supérieur à celui qui vous est attribué, vous pouvez demander une augmentation de quota. Contactez l'assistance si vous disposez d'une formule d'assistance Premium. Sinon, vous pouvez envoyer votre demande par e-mail au service client d'AI Platform Training.

Quota dépassé

Si une erreur s'affiche avec un message indiquant un problème au niveau du quota de "project_number", vous avez peut-être dépassé l'un de vos quotas de ressources. Vous pouvez surveiller votre consommation de ressources et demander une augmentation sur la page des quotas AI Platform Training dans le gestionnaire d'API de votre console.

Chemin de sauvegarde non valide

Si l'exécution de votre tâche est interrompue par un message d'erreur indiquant la restauration de l'appel avec un chemin d'enregistrement invalide gs://..., il se peut que vous utilisiez un bucket Google Cloud Storage mal configuré.

1. Ouvrez la page Navigateur de Google Cloud Storage dans la console Google Cloud.

   Ouvrir la page "Navigateur" dans la console Google Cloud

2. Vérifiez la Classe de stockage par défaut pour le bucket que vous utilisez.

• Cette classe devrait être définie sur Regional (Régional). Si c'est le cas, le problème provient d'un autre dysfonctionnement. Essayez d'exécuter de nouveau la tâche.
• Si la classe est définie sur Multi-Regional (Multirégional), vous devez modifier cette valeur sur Regional (Régional) ou déplacer vos supports d'entraînement vers un autre bucket. Si vous optez pour la première solution, recherchez les instructions de modification de la classe de stockage d'un bucket dans la documentation Cloud Storage.

L'application d'entraînement est interrompue par une erreur AbortedError

Cette erreur peut se produire si vous exécutez une application d'entraînement qui gère les tâches distribuées à l'aide de TensorFlow Supervisor. TensorFlow renvoie parfois des exceptions AbortedError dans des situations où l'intégralité de la tâche ne devrait pas être interrompue. Vous pouvez intercepter cette exception dans l'application d'entraînement et réagir en conséquence. Notez que TensorFlow Supervisor n'est pas compatible avec les applications d'entraînement exécutées avec AI Platform Training.

Résoudre des problèmes de prédiction

Vous trouverez dans cette section la description de certains problèmes fréquemment rencontrés lors de l'obtention de prédictions.

Gérer les conditions spécifiques à la prédiction en ligne

Cette section fournit des conseils sur des conditions d'erreur de prédiction en ligne spécifiques que rencontrent certains utilisateurs.

Exécution trop longue des prédictions (30 à 180 secondes)

La lenteur d'exécution des prédictions en ligne est souvent due au scaling des nœuds de traitement à partir de zéro. Si des requêtes de prédiction sont régulièrement effectuées auprès de votre modèle, le système maintient en permanence un ou plusieurs nœuds prêts à diffuser des prédictions. Si votre modèle n'a pas diffusé de prédiction depuis longtemps, le service s'adapte à la baisse en faisant repasser le nombre de nœuds prêts à zéro. La prochaine requête de prédiction effectuée après une telle réduction prendra beaucoup plus de temps que d'habitude, car le service devra de nouveau provisionner des nœuds pour la traiter.

Codes d'état HTTP

Lorsqu'une erreur se produit au moment d'une requête de prédiction en ligne, le service renvoie généralement un code d'état HTTP. Voici les codes les plus courants, accompagnés de leur signification, dans le cadre des prédictions en ligne :

429 : mémoire saturée

Le nœud de traitement s'est trouvé à court de mémoire durant l'exécution de votre modèle. Il n'existe aucun moyen d'augmenter la mémoire allouée aux nœuds de prédiction pour le moment. Vous pouvez essayer les solutions suivantes pour faire fonctionner votre modèle :

• Réduisez la taille de votre modèle en appliquant l'une de ces méthodes :
  • Utilisez des variables moins précises.
  • Quantifiez vos données continues.
  • Diminuez la taille des autres caractéristiques d'entrée (par exemple, en utilisant des termes plus courts).
  • Renvoyez la requête avec un lot d'instances plus petit.

429 - Too many pending requests

Votre modèle reçoit plus de requêtes qu'il ne peut en traiter. Si vous utilisez l'autoscaling, le délai nécessaire aux requêtes pour arriver est plus court que celui dont a besoin le système pour évoluer.

Avec l'autoscaling, vous pouvez essayer de renvoyer les requêtes avec un intervalle exponentiel entre les tentatives. Ainsi, le système a le temps de s'adapter.

429 : quota

Votre projet Google Cloud Platform est limité à 10 000 requêtes toutes les 100 secondes (soit environ 100 par seconde). Si cette erreur se produit lors de pics d'activité temporaires, vous pouvez généralement réessayer en spécifiant un intervalle exponentiel entre les tentatives, afin que toutes vos requêtes finissent par être traitées. Si ce code s'affiche systématiquement, vous pouvez demander une augmentation de quota. Pour en savoir plus, consultez la page relative aux quotas.

503 : nos systèmes ont détecté un trafic inhabituel provenant de votre réseau informatique

La fréquence à laquelle votre modèle a reçu des requêtes depuis une seule et même adresse IP est si élevée que le système soupçonne une attaque par déni de service. N'envoyez plus de requêtes pendant une minute, puis reprenez les envois à un rythme moins soutenu.

500 : impossible de charger le modèle

Le système n'est pas parvenu à charger votre modèle. Pour remédier au problème, suivez les étapes ci-dessous :

• Assurez-vous que votre application d'apprentissage exporte le bon modèle.
• Exécutez une prédiction test à l'aide de la commande gcloud ai-platform local predict.
• Réexportez votre modèle, puis réessayez.

Erreurs de mise en forme pour les requêtes de prédiction

Les messages ci-dessous sont tous liés à vos données de saisie de prédiction.

"JSON vide ou mal formé/non valide dans le corps de la requête"

Le service n'a pas pu analyser le texte JSON spécifié dans votre requête, ou votre requête est vide. Vérifiez votre message pour trouver des erreurs ou des omissions empêchant l'analyse du texte JSON.

"Missing 'instances' field in request body"

Le corps de la requête ne respecte pas le format approprié. Il doit s'agir d'un objet JSON avec une seule clé nommée "instances" qui contient une liste avec toutes vos instances d'entrée.

Erreur d'encodage JSON lors de la création d'une requête

Votre requête inclut des données encodées en base64, mais pas au format JSON approprié. Chaque chaîne encodée en base64 doit être représentée par un objet avec une seule clé nommée "b64". Exemple :

  {"b64": "an_encoded_string"}

Une autre erreur base64 se produit lorsque des données binaires ne sont pas encodées en base64. Encodez vos données et mettez-les en forme de la manière suivante :

  {"b64": base64.b64encode(binary_data)}

En savoir plus sur la mise en forme et l'encodage des données binaires.

La prédiction dans le cloud prend plus de temps que via l'application de bureau

La prédiction en ligne est conçue pour être un service évolutif qui diffuse rapidement un nombre élevé de requêtes de prédiction. Ce service est optimisé pour assurer des performances globales sur l'ensemble des requêtes diffusées. L'accent étant mis sur l'évolutivité, les critères de performances ne sont pas les mêmes que pour l'exécution d'un petit nombre de prédictions sur votre ordinateur local.

Étapes suivantes

• Accédez à l'assistance.
• Obtenez plus d'informations sur le modèle d'erreur des API Google, en particulier sur les codes d'erreur canoniques définis dans google.rpc.Code et sur les informations relatives aux erreurs courantes définies dans google/rpc/error_details.proto.
• Apprenez à surveiller vos tâches d’entraînement.
• Reportez-vous à la section concernant le dépannage et les questions fréquentes pour Cloud TPU. Vous y trouverez de l'aide pour diagnostiquer et résoudre les problèmes que vous pouvez rencontrer lorsque vous exécutez AI Platform Training avec Cloud TPU.