Déploiements de modèle BYOC

Lors de la création, de la mise à jour ou de l'activation d'opérations de déploiement de modèle, Data Science vérifie qu'un chemin autorisé pour accéder à l'image de conteneur existe dans la location. Si la vérification échoue, cela peut être dû à des stratégies de principal de ressource manquantes, à un chemin d'image incorrect ou à l'absence d'image. Assurez-vous que les stratégies, le chemin et l'image indiqués sont corrects et réessayez.

Chaque ressource de déploiement de modèle implique l'extraction de l'image de conteneur créée à partir d'OCI Registry vers l'instance Compute de déploiement, où elle est ensuite exécutée en tant que conteneur pour l'inférence. Le téléchargement de l'image doit être terminé dans les 20 minutes. Cependant, si la taille de l'image est trop grande ou qu'un temps d'inactivité temporaire du service se produit dans le registre, l'opération peut expirer, de sorte que la taille de l'image doit être inférieure à 16 Go. Si l'image est plus grande que celle-ci, envisagez de supprimer les dépendances inutiles pour réduire la taille, puis réessayez de créer le déploiement.

Lors du déploiement d'un modèle, l'image de conteneur est transférée de la location vers la location du service Data Science et utilisée pour exécuter le modèle en tant que conteneur pour l'inférence. Le conteneur a un délai d'attente défini de 10 minutes pour s'exécuter. Il est donc essentiel de s'assurer que le conteneur de service d'inférence démarre dans cette période.

Avant le déploiement, il est important de valider le conteneur localement et de tester que les appels /predict et /health réussissent.

Lors du déploiement, il est également essentiel de vérifier qu'aucune erreur ne se produit lors de l'exécution du conteneur, de l'appel de prévision ou de l'appel de vérification de l'état. Assurez-vous également que la sortie est activée lors de la création de la ressource de déploiement de modèle si la logique d'inférence en cours d'exécution dans le conteneur doit accéder à Internet. Si vous ne le faites pas, vous risquez d'échouer lors de l'initialisation du modèle. Pour tester ce scénario, essayez de désactiver Internet pendant les tests locaux.

Assurez-vous que suffisamment de mémoire est allouée pour charger et inférer le modèle afin d'éviter les problèmes de mémoire insuffisante.

Pour plus d'informations, reportez-vous aux meilleures pratiques BYOC et au test du conteneur.

Plusieurs raisons peuvent expliquer l'échec du démarrage d'un conteneur. Pour y remédier, il est préférable d'identifier et de corriger l'échec lors de la phase de test locale. Voici quelques raisons et corrections possibles :

• Le package curl doit être installé sur l'image de conteneur pour que la stratégie Docker HEALTHCHECK réussisse. Si ce package est manquant, le conteneur ne démarre pas.

• Les paramètres de ligne de commande Docker CMD ou Entrypoint doivent être fournis via l'API ou le fichier Dockerfile pour initialiser le serveur Web. Si ces paramètres ne sont pas valides, le conteneur ne démarre pas.

Lors de l'initialisation, l'instance Compute des déploiements décompresse l'artefact de modèle et monte les fichiers dans le répertoire /opt/ds/model/deployed_model du conteneur en cours d'exécution en mode lecture seule.

Tous les fichiers compressés à partir de ce chemin sont utilisés dans la logique de scoring. Zipper un ensemble de fichiers (y compris le modèle ML et la logique de scoring), ou un dossier contenant un ensemble de fichiers qui ont un chemin d'emplacement différent vers le modèle ML dans le conteneur.

Assurez-vous que le chemin correct est utilisé lors du chargement du modèle dans la logique d'évaluation par score.