0 / 0
Retourner à la version anglaise de la documentation
Dépannage de l'exécution de watsonx.ai
Dernière mise à jour : 06 févr. 2025
Dépannage de l'exécution de watsonx.ai

Suivez ces conseils pour résoudre les problèmes courants que vous pouvez rencontrer lorsque vous travaillez avec le Runtime watsonx.ai

Dépannage de l'instance de service watsonx.ai Runtime

Dépannage de AutoAI

Dépannage des déploiements

Dépannage de l'instance de service watsonx.ai Runtime

Suivez ces conseils pour résoudre les problèmes courants que vous pouvez rencontrer lorsque vous travaillez avec l'instance de service watsonx.ai Runtime.

Instance d'exécution watsonx.ai inactive

Symptômes

Après avoir essayé de soumettre une requête d'inférence à un foundation model en cliquant sur le bouton Generate dans le Prompt Lab, le message d'erreur suivant s'affiche :

'code': 'no_associated_service_instance_error',
'message': 'WML instance {instance_id} status is not active, current status: Inactive'

Causes possibles

L'association entre votre projet watsonx.ai et l'instance de service watsonx.ai Runtime associée a été perdue.

Solutions possibles

Recréez ou actualisez l'association entre votre projet watsonx.ai et l'instance de service watsonx.ai Runtime correspondante. Pour cela, procédez comme suit :

  1. Dans le menu principal, développez Projets, puis cliquez sur Afficher tous les projets.
  2. Cliquez sur votre projet watsonx.ai
  3. Dans l'onglet Gérer, cliquez sur Services et intégrations.
  4. Si l'instance de service watsonx.ai Runtime appropriée est listée, dissociez-la temporairement en sélectionnant l'instance, puis en cliquant sur Remove (Supprimer). Confirmer le retrait.
  5. Cliquez sur Associer un service.
  6. Choisissez l'instance de service watsonx.ai Runtime appropriée dans la liste, puis cliquez sur Associer.

Dépannage de AutoAI

Suivez ces conseils pour résoudre les problèmes courants que vous pouvez rencontrer lorsque vous travaillez avec l'AutoAI.

L'exécution d'une expérience de série temporelle AutoAI avec prédiction d'anomalie échoue

La fonction permettant de prédire les anomalies dans les résultats d'une expérience de série temporelle n'est plus prise en charge. La tentative d'exécution d'une expérience existante entraîne des erreurs dues à l'absence de bibliothèques d'exécution. Par exemple, vous pouvez voir cette erreur :

The selected environment seems to be invalid: Could not retrieve environment. CAMS error: Missing or invalid asset id

Ce comportement est normal car les durées d'exécution pour la prédiction des anomalies ne sont pas prises en charge. Il n'existe pas de solution à ce problème.

Le cahier d'inférence de lAutoAI pour une expérience RAG dépasse les limites du modèle

Parfois, lors de l'exécution d'un cahier d'inférence généré pour une expérience AutoAI RAG, vous pouvez obtenir cette erreur :

MissingValue: No "model_limits" provided. Reason: Model <model-nam> limits cannot be found in the model details.

L'erreur indique que les limites des jetons pour déduire le foundation model utilisé pour l'expérience sont manquantes. Pour résoudre le problème, recherchez la fonction " default_inference_function et remplacez " get_max_input_tokens par le nombre maximal de jetons pour le modèle. Par exemple :

model = ModelInference(api_client=client, **params['model"])
# model_max_input_tokens = get+max_input_tokens(model=model, params=params)
model_max_input_tokens = 4096

Vous pouvez trouver la valeur maximale du jeton pour le modèle dans le tableau des modèles de fondation pris en charge disponibles avec watsonx.ai

L'entraînement d'une expérience AutoAI échoue avec les informations d'identification du service

Si vous formez une expérience AutoAI en utilisant la clé API pour le serviceID, formation peut échouer avec cette erreur :

User specified in query parameters does not match user from token.

Une façon de résoudre ce problème est d'exécuter l'expérience avec vos identifiants d'utilisateur. Si vous souhaitez exécuter l'expérience avec des informations d'identification pour le service, suivez ces étapes pour mettre à jour les rôles et les stratégies pour l'identifiant du service.

  1. Ouvrez votre site serviceID sur IBM Cloud. Recherche de la page de politique de serviceID
  2. Créez un nouvel serviceID ou mettez à jour l'identifiant existant avec la politique d'accès suivante :
    • Tous les services de gestion de compte IAM avec les rôles suivants : réviseur de clé API, créateur de clé API d'utilisateur, visualiseur, opérateur et éditeur. L'idéal serait de créer un nouvel apikey pour ce site ServiceId. Mise à jour de la politique et des rôles pour un serviceID
  3. La politique actualisée se présentera comme suit : Mise à jour de la politique d'serviceID
  4. Exécutez à nouveau la formation avec les informations d'serviceID mis à jour.

La demande de prédiction pour le modèle de séries temporelles de l AutoAI peut être interrompue si le nombre de nouvelles observations est trop élevé

Une demande de prédiction peut être interrompue pour un modèle de série temporelle AutoAI déployé si le nombre de nouvelles observations transmises est trop élevé. Pour résoudre ce problème, procédez de l'une des manières suivantes :

  • Réduire le nombre de nouvelles observations.
  • Étendre les données de formation utilisées pour l'expérience en ajoutant de nouvelles observations. Ensuite, relancez l'expérience AutoAI sur les séries temporelles avec les données de formation mises à jour.

Membres de classe insuffisants dans les données d'entraînement pour l'expérimentation AutoAI

Les données d'entraînement d'une expérimentation AutoAI doivent comporter au moins 4 membres pour chaque classe. Si vos données d'entraînement ne contiennent pas un nombre suffisant de membres dans une classe, vous rencontrerez l'erreur suivante:

ERROR: ingesting data Message id: AC10011E. Message: Each class must have at least 4 members. The following classes have too few members: ['T'].

Pour résoudre le problème, mettez à jour les données d'entraînement afin de supprimer la classe ou d'ajouter d'autres membres.

Impossible d'ouvrir les actifs de Cloud Pak for Data qui nécessitent watsonx.ai

Si vous travaillez dans le contexte Cloud Pak for Data, vous ne pouvez pas ouvrir les actifs qui nécessitent un contexte de produit différent, comme watsonx.ai Par exemple, si vous créez une expérience AutoAI pour un modèle RAG à l'aide de watsonx.ai, vous ne pouvez pas ouvrir cette ressource lorsque vous êtes dans le contexte Cloud Pak for Data. Dans le cas des expériences AutoAI, vous pouvez visualiser le type de formation dans la liste des actifs. Vous pouvez ouvrir des expériences avec un type d'apprentissage automatique, mais pas avec un type de génération augmentée par récupération.

Dépannage des déploiements

Suivez ces conseils pour résoudre les problèmes courants que vous pouvez rencontrer lorsque vous travaillez avec les déploiements de watsonx.ai Runtime.

Les déploiements par lots qui utilisent des volumes de données volumineux en tant qu'entrée risquent d'échouer

Si vous évaluez un travail par lots qui utilise de grands volumes de données comme source d'entrée, le travail risque d'échouer en raison de paramètres de délai d'attente internes. Un symptôme de cet incident peut être un message d'erreur similaire à l'exemple suivant:

Incorrect input data: Flight returned internal error, with message: CDICO9999E: Internal error occurred: Snowflake sQL logged error: JDBC driver internal error: Timeout waiting for the download of #chunk49(Total chunks: 186) retry=0.

Si le délai d'attente se produit lorsque vous évaluez votre déploiement par lots, vous devez configurer la limitation du délai d'attente au niveau de la requête de la source de données pour gérer les travaux à exécution longue.

Les informations de délai d'attente de niveau requête pour les sources de données sont les suivantes:

Informations sur la limitation du temps au niveau de la requête pour les sources de données
Source de données Limitation du temps au niveau de la requête Limite de temps par défaut Modifier la limite de temps par défaut
Apache Cassandra Oui 10 secondes Définissez les paramètres read_timeout_in_ms et write_timeout_in_ms dans le fichier de configuration Apache Cassandra ou dans la connexion Apache Cassandra URL pour modifier la limite de temps par défaut.
Cloud Object Storage Non Non disponible Non disponible
Db2 Oui Non disponible Définissez le paramètre QueryTimeout pour indiquer la durée (en secondes) pendant laquelle un client attend la fin de l'exécution d'une requête avant de tenter d'annuler l'exécution et de renvoyer le contrôle à l'application.
Hive via Execution Engine for Hadoop Oui 60 minutes (3600 secondes) Définissez la propriété hive.session.query.timeout dans l' URL connexion pour modifier la limite de temps par défaut.
Microsoft SQL Server Oui 30 secondes Définissez l'option de configuration du serveur QUERY_TIMEOUT pour modifier la limite de temps par défaut.
MongoDB Oui 30 secondes Définissez le paramètre maxTimeMS dans les options de requête pour modifier la limite de temps par défaut.
MySQL Oui 0 secondes (pas de limite de temps par défaut) Définissez la propriété timeout dans l' URL connexion ou dans les propriétés du pilote JDBC pour spécifier une limite de temps pour votre requête.
Oracle Oui 30 secondes Définissez le paramètre QUERY_TIMEOUT dans le pilote Oracle JDBC pour spécifier la durée maximale d'exécution d'une requête avant qu'elle ne soit automatiquement annulée.
PostgreSQL Non Non disponible Définissez la propriété queryTimeout pour spécifier la durée maximale d'exécution d'une requête. La valeur par défaut de la propriété queryTimeout est 0.
Snowflake Oui 6 h Définissez le paramètre queryTimeout pour modifier la limite de temps par défaut.

Pour éviter que vos déploiements par lots échouent, partitionnez votre fichier ou réduisez sa taille.

Sécurité pour les téléchargements de fichiers

Les fichiers que vous téléchargez via l'interface utilisateur de watsonx.ai Studio ou watsonx.ai Runtime ne sont pas validés ou analysés pour détecter des contenus potentiellement malveillants. Il est recommandé d'exécuter un logiciel de sécurité, tel qu'une application antivirus, sur tous les fichiers avant de les télécharger afin d'assurer la sécurité de votre contenu.

Les déploiements avec des spécifications logicielles restreintes échouent après une mise à niveau

Si vous mettez à niveau vers une version plus récente d'IBM Cloud Pak for Data et déployez une ressource applicative R Shiny qui a été créée en utilisant des spécifications logicielles restreintes en mode FIPS, votre déploiement échoue.

Par exemple, les déploiements qui utilisent les spécifications logicielles 'shiny-r3.6 et 'shiny-r4.2 échouent après la mise à niveau d'IBM Cloud Pak for Data version 4.7.0 vers 4.8.4 ou ultérieure. Vous pourriez recevoir le message d'erreurError 502 - Bad Gateway .

Pour éviter l'échec de votre déploiement, mettez à jour la spécification restreinte de votre actif déployé afin d'utiliser la dernière spécification logicielle. Pour plus d’informations, consultez Gestion des spécifications ou des frameworks logiciels obsolètes. Vous pouvez également supprimer le déploiement de votre application si vous n'en avez plus besoin.

La création d'une tâche pour un flux SPSS Modeler dans un espace de déploiement échoue

Au cours du processus de configuration d'un job batch pour votre flux SPSS Modeler dans un espace de déploiement, le mappage automatique des ressources de données avec leur connexion respective peut échouer.

L'image montre que la cartographie automatique des actifs de données et des connexions échoue

Pour corriger l'erreur de mappage automatique des ressources de données et des connexions, procédez comme suit :

  1. Cliquez sur Créer pour enregistrer votre progression et quitter la boîte de dialogue Configuration d'un nouveau travail.

  2. Dans votre espace de déploiement, cliquez sur l'onglet Jobs et sélectionnez votre job de flux SPSS Modeler pour consulter les détails de votre job.

  3. Dans la page des détails du travail, cliquez sur l'icône Modifier Image de l'icône d'édition pour mettre à jour manuellement le mappage de vos ressources de données et de vos connexions.

  4. Après avoir mis à jour le mappage des ressources de données et des connexions, vous pouvez reprendre le processus de configuration des paramètres de votre travail dans la boîte de dialogue Nouveau travail. Pour plus d'informations, voir Création de tâches de déploiement pour les flux de SPSS Modeler

    L'image montre que la cartographie automatique des données et des connexions est réussie

Le déploiement d'un foundation model personnalisé à partir d'un espace de déploiement échoue

Lorsque vous créez un déploiement pour un foundation model personnalisé à partir de votre espace de déploiement, votre déploiement peut échouer pour de nombreuses raisons. Suivez ces conseils pour résoudre les problèmes courants que vous pouvez rencontrer lorsque vous déployez vos modèles de fondation personnalisés à partir d'un espace de déploiement.

Cas 1 : La valeur du paramètre est hors plage

Lorsque vous créez un déploiement pour un foundation model personnalisé à partir de votre espace de déploiement, vous devez vous assurer que les valeurs des paramètres de votre modèle de base se situent dans la plage spécifiée. Pour plus d'informations, voir Propriétés et paramètres des modèles de fondation personnalisés. Si vous entrez une valeur qui se situe en dehors de la plage spécifiée, vous risquez de rencontrer une erreur.

Par exemple, la valeur du paramètre " max_new_tokens doit être inférieure à celle du paramètre " max_sequence_length. Lorsque vous mettez à jour les valeurs des paramètres du modèle de base, si vous introduisez une valeur pour " max_new_tokens supérieure ou égale à la valeur de " max_sequence_length (2048), vous risquez de rencontrer une erreur.

L'image suivante montre un exemple de message d'erreur : Value must be an integer between 20 and 1000000000000000 and be greater than 'Max New Tokens'.

Exemple de message d'erreur

Si les valeurs par défaut des paramètres de votre modèle entraînent une erreur, contactez votre administrateur pour modifier le registre du modèle dans le CR watsonxaiifm.

Cas 2 : Type de données non pris en charge

Vous devez vous assurer que vous sélectionnez un type de données pris en charge par votre foundation model personnalisé. Lorsque vous mettez à jour les valeurs des paramètres du modèle de base, si vous mettez à jour le type de données de votre modèle déployé avec un type de données non pris en charge, votre déploiement risque d'échouer.

Par exemple, le modèle " LLaMA-Pro-8B-Instruct-GPTQ ne prend en charge que le type de données " float16 Si vous déployez le modèle 'LLaMA-Pro-8B-Instruct-GPTQ avec 'float16 'Enum', puis mettez à jour le paramètre 'Enum de 'float16 à 'bfloat16, votre déploiement échoue.

Si le type de données que vous avez sélectionné pour votre foundation model personnalisé entraîne une erreur, vous pouvez remplacer le type de données pour le foundation model personnalisé lors de la création du déploiement ou contacter votre administrateur pour modifier le registre du modèle dans le CR watsonxaiifm.

Cas 3 : La valeur du paramètre est trop importante

Si vous introduisez une valeur très élevée pour les paramètres 'max_sequence_length et 'max_new_token, vous risquez de rencontrer une erreur. Par exemple, si vous définissez la valeur de " max_sequence_length comme étant " 1000000000000000, vous obtenez le message d'erreur suivant :

Échec du déploiement du foundation model personnalisé. L'opération a échoué en raison de 'max_batch_weight (19596417433) not large enough for (prefill) max_sequence_length (1000000000000000)'. Renouvelez l'opération. Contactez le support IBM si le problème persiste.

Vous devez vous assurer que vous saisissez une valeur pour le paramètre qui est inférieure à la valeur définie dans le fichier de configuration du modèle (config.json).

Cas 4 : le fichier " model.safetensors est enregistré avec des bibliothèques non prises en charge

Si le fichier " model.safetensors de votre foundation model personnalisé utilise un format de données non pris en charge dans l'en-tête des métadonnées, votre déploiement risque d'échouer.

Par exemple, si vous importez le foundation model personnalisé " OccamRazor/mpt-7b-storywriter-4bit-128g de Hugging Face dans votre espace de déploiement et que vous créez un déploiement en ligne, celui-ci risque d'échouer. Cela est dû au fait que le fichier " model.safetensors pour le modèle " OccamRazor/mpt-7b-storywriter-4bit-128g est enregistré avec le fichier " save_pretrained, qui est une bibliothèque non prise en charge. Le message d'erreur suivant risque d'apparaître :

L'opération a échoué car l'objet 'NoneType' n'a pas d'attribut 'get'.

Vous devez vous assurer que votre foundation model personnalisé est enregistré avec la bibliothèque " transformers prise en charge.

Cas 5 : Le déploiement d'un modèle Llama 3.1 échoue

Dans votre modèle Llama 3.1, le déploiement échoue, essayez d'éditer le contenu du fichier 'config.json de votre modèle :

  1. Recherchez l'entrée " eos_token_id
  2. Changer la valeur de l'entrée d'un tableau en un entier.

Essayez ensuite de redéployer votre modèle.

Les modèles de fondation déployés à la demande ne peuvent pas être déployés dans un espace de déploiement

Vous ne pouvez déployer qu'une seule instance d'un foundation model déployé à la demande dans un espace de déploiement. Si le modèle sélectionné est déjà déployé, l'espace de déploiement dans lequel le modèle est déployé est désactivé.

Si vous avez besoin de plus de ressources pour votre modèle, vous pouvez ajouter des copies supplémentaires de votre ressource de modèle déployée en faisant évoluer le déploiement.

La conversion d'un modèle de LightGBM à ONNX échoue

Si vous utilisez une fonction objective non prise en charge pour convertir vos modèles LightGBM au format ONNX, votre déploiement risque d'échouer. Par exemple, si vous utilisez une fonction objective non prise en charge dans la définition de lightgbm.Booster, vous risquez d'avoir des problèmes de conversion.

Pour résoudre ce problème, assurez-vous d'utiliser une fonction objective prise en charge lorsque vous convertissez les modèles LightGBM en ONNX.

L'exemple de code suivant montre comment remplacer la fonction objective non prise en charge dans la définition de lightgbm.Booster par une fonction compatible avec convert_lightgbm.

lgb_model = lightgbm.Booster(model_str=lgb_model.model_to_string().replace('<unsupported_objective_function>', '<compatible_objective_function>'))

Le déploiement d'un agent en tant que service d'IA échoue

Lorsque vous créez un agent dans le laboratoire d'agents avec toutes les options d'outils activées (y compris Vector Index) et que vous l'enregistrez en tant que carnet de déploiement contenant un service AI, la création du déploiement échoue.

Le message d'erreur suivant risque d'apparaître :

La création du déploiement a échoué. Erreur : 400.

Le problème survient lorsque la clé API utilisée dans le bloc-notes provient d'un compte différent qui n'a pas d'identifiant de tâche. La clé API doit provenir du même compte que le projet.

Pour résoudre le problème, assurez-vous que la clé API utilisée dans le bloc-notes provient du même compte que le projet. Si la clé API provient d'un autre compte, créez une nouvelle clé API à partir du compte correct et mettez à jour le carnet de notes en conséquence.