Déploiements de modèle BYOC

Lors de la création, de la mise à jour ou de l'activation des opérations de déploiement de modèle, le service de science des données 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û à l'absence de politiques principales de ressource, à un chemin d'image incorrect ou à l'absence d'image. Assurez-vous que les politiques, le chemin et l'image spécifiés sont corrects et réessayez.

Chaque ressource de déploiement de modèle consiste à extraire l'image de conteneur créée du registre OCI vers l'instance de calcul 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. Toutefois, si la taille de l'image est trop grande ou si un temps d'arrêt 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 toutes les dépendances inutiles pour réduire la taille, puis réessayez la création du 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 de science des données 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 fonctionner, il est donc crucial de s'assurer que le conteneur de service d'inférence commence dans ce délai.

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

Lors du déploiement, il est également crucial de valider qu'aucune erreur ne se produit lors de l'exécution du conteneur, de l'appel de prédiction ou de l'appel de vérification de l'état. De plus, assurez-vous que le trafic sortant est activé lors de la création de la ressource de déploiement de modèle si la logique d'inférence exécutée dans le conteneur doit accéder à Internet. Si vous ne le faites pas, cela peut entraîner une défaillance de l'amorçage du modèle. Pour tester ce scénario, essayez de désactiver Internet lors des tests locaux.

Assurez-vous qu'une quantité suffisante de mémoire est allouée pour charger et déduire le modèle afin d'éviter les problèmes de mémoire insuffisante.

Pour plus d'informations, consultez les meilleures pratiques BYOC et Tester le conteneur.

Il peut y avoir plusieurs raisons pour lesquelles un conteneur ne démarre pas. Pour y remédier, il est préférable d'identifier et de corriger l'échec pendant la phase de test local. Voici quelques raisons et corrections possibles :

• Pour que la politique HEALTHCHECK de Docker réussisse, l'ensemble curl doit être installé sur l'image de conteneur. Si ce paquet est manquant, le conteneur ne démarre pas.

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

Lors du démarrage, l'instance de calcul des déploiements décompresse l'artefact de modèle et monte les fichiers dans le répertoire /opt/ds/model/deployed_model à l'intérieur 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 notation. Zip d'un jeu de fichiers (y compris le modèle d'apprentissage automatique et la logique de notation) ou d'un dossier contenant un jeu de fichiers ayant un chemin d'accès différent au modèle d'apprentissage automatique dans le conteneur.

Assurez-vous que le chemin correct est utilisé lors du chargement du modèle dans la logique de notation.