Résolution des problèmes¶
Ce guide explique comment surveiller vos déploiements dans Snowpark Container Services (SPCS) et résoudre les problèmes courants liés aux dépendances des paquets, à la mémoire et à la configuration de l’environnement.
Surveiller les déploiements de SPCS¶
Vous pouvez surveiller le déploiement en inspectant les services lancés à l’aide de la requête SQL suivante.
SHOW SERVICES IN COMPUTE POOL my_compute_pool;
Deux tâches sont lancées :
MODEL_BUILD_xxxxx : Les derniers caractères du nom sont choisis de façon aléatoire pour éviter les conflits de noms. Cette tâche construit l’image et se termine une fois l’image construite. Si une image existe déjà, la tâche est ignorée.
Les connexions sont utiles pour résoudre des problèmes tels que des conflits dans les dépendances des paquets. Pour voir les journaux de cette tâche, exécutez la commande SQL ci-dessous, en veillant à utiliser les mêmes caractères finaux :
CALL SYSTEM$GET_SERVICE_LOGS('MODEL_BUILD_xxxxx', 0, 'model-build');
MYSERVICE : Le nom du service tel que spécifié dans l’appel à
create_service. Cette tâche est démarrée si la tâche MODEL_BUILD aboutit ou est ignorée. Pour voir les journaux de cette tâche, exécutez la commande SQL ci-dessous :CALL SYSTEM$GET_SERVICE_LOGS('MYSERVICE', 0, 'model-inference');
Si les journaux ne sont pas disponibles via SYSTEM$GET_SERVICE_LOG parce que la tâche de construction ou le service a été supprimé, vous pouvez consulter la table des événements (si activée) pour voir les journaux :
SELECT RESOURCE_ATTRIBUTES, VALUE
FROM <EVENT_TABLE_NAME>
WHERE true
AND timestamp > dateadd(day, -1, current_timestamp()) -- choose appropriate timestamp range
AND RESOURCE_ATTRIBUTES:"snow.database.name" = '<db of the service>'
AND RESOURCE_ATTRIBUTES:"snow.schema.name" = '<schema of the service>'
AND RESOURCE_ATTRIBUTES:"snow.service.name" = '<Job or Service name>'
AND RESOURCE_ATTRIBUTES:"snow.service.container.instance" = '0' -- choose all instances or one particular
AND RESOURCE_ATTRIBUTES:"snow.service.container.name" != 'snowflake-ingress' --skip logs from internal sidecar
ORDER BY timestamp ASC;
Conflits de paquets¶
Deux systèmes dictent les paquets installés dans le conteneur de services : le modèle lui-même et le serveur d’inférence. Pour réduire les conflits avec les dépendances de votre modèle, le serveur d’inférence ne nécessite que les paquets suivants :
gunicorn<24.0.0starlette<1.0.0uvicorn-standard<1.0.0
Assurez-vous que les dépendances de votre modèle, ainsi que celles ci-dessus, peuvent être résolues par pip ou conda, quel que soit votre choix.
Si un modèle possède à la fois conda_dependencies et pip_requirements, elles seront installées comme suit via conda :
Canaux :
conda-forgenodefaults
Dépendances :
all_conda_packagespip :
all_pip_packages
Snowflake obtient des paquets Anaconda de conda-forge lors de la création d’images de conteneurs, car le canal Snowflake conda n’est disponible que dans les entrepôts, et le canal par défaut exige que les utilisateurs acceptent les conditions d’utilisation d’Anaconda, ce qui n’est pas possible lors d’une construction automatisée. Pour obtenir des paquets d’un canal différent, comme les valeurs par défaut, indiquez chaque paquet avec le nom du canal, comme dans defaults::pkg_name.
Note
Si vous spécifiez à la fois conda_dependencies et pip_requirements, l’image du conteneur se construit avec succès même si les deux ensembles de dépendances ne sont pas compatibles, ce qui peut faire que l’image du conteneur qui en résulte ne fonctionne pas comme prévu. Snowflake recommande d’utiliser uniquement conda_dependencies ou uniquement pip_requirements, et non les deux.
Service à court de mémoire¶
Certains modèles ne sont pas thread-safe, donc Snowflake charge une copie distincte du modèle en mémoire pour chaque processus de travail. Cela peut entraîner des conditions de pénurie de mémoire pour les grands modèles avec un nombre plus élevé de workers. Essayez de réduire num_workers.
Impossible de modifier les spécifications du service¶
Les spécifications des services de création de modèles et d’inférence ne peuvent pas être modifiées à l’aide de ALTER SERVICE. Vous ne pouvez modifier que des attributs tels que TAG, MIN_INSTANCES, et ainsi de suite. Cependant, étant donné que l’image est publiée dans le référentiel d’images, vous pouvez copier la spécification, la modifier et créer un nouveau service à partir de celle-ci, que vous pouvez démarrer manuellement.
Paquet non trouvé¶
Le déploiement du modèle a échoué lors de la phase de création de l’image. Les journaux model-build montrent qu’un paquet demandé n’a pas été trouvé. (Cette étape utilise conda-forge par défaut si le paquet est mentionné dans conda_dependencies.)
L’installation d’un paquet peut échouer pour l’une des raisons suivantes :
Le nom ou la version du paquet n’est pas valide. Vérifiez l’orthographe et la version du paquet.
La version demandée du paquet n’existe pas dans conda-forge. Vous pouvez essayer de supprimer la spécification de version pour obtenir la dernière version disponible dans conda-forge, ou utiliser
pip_requirementsà la place. Vous pouvez parcourir tous les paquets disponibles ici.Parfois, vous pouvez avoir besoin d’un paquet provenant d’un canal spécial (par exemple, pytorch). Ajoutez un préfixe
channel_name::à la dépendance, commepytorch::torch.
Inadéquation de la version de Hugging Face Hub¶
Un service d’inférence du modèle Hugging Face peut échouer avec le message d’erreur suivant :
ImportError: huggingface-hub>=0.30.0,<1.0 is required for a normal functioning of this module, but found huggingface-hub==0.25.2
Cela est dû au fait que le paquet transformers ne spécifie pas les dépendances correctes dans huggingface-hub, mais qu’il les vérifie dans le code. Pour résoudre ce problème, connectez à nouveau le modèle, en spécifiant cette fois explicitement la version requise de huggingface-hub dans conda_dependencies ou pip_requirements.
Torch n’est pas compilé avec CUDA activé¶
La cause typique de cette erreur est que vous avez spécifié conda_dependencies et pip_requirements. Comme mentionné dans la section Conflits de paquets, conda est le gestionnaire de paquets utilisé pour créer l’image du conteneur. Anaconda ne résout pas les paquets provenant à la fois de conda_dependencies et pip_requirements et donne la priorité aux paquets conda. Cela peut conduire à une situation dans laquelle les paquets conda ne sont pas compatibles avec les paquets pip. Vous avez peut-être spécifié torch dans pip_requirements, et non dans conda_dependencies. Envisagez de consolider les dépendances dans conda_dependencies ou pip_requirements. Si ce n’est pas possible, spécifiez les paquets les plus importants dans conda_dependencies.