Conteneurs Docker pour les modèles ML

Une image ML peut regrouper le runtime Python, le code d'application, les bibliothèques et le point d'entrée de service nécessaires au chargement ou à l'exécution d'un modèle. Docker crée une image à partir d'instructions telles qu'une image de base, des copies de fichiers, l'installation de dépendances et la configuration des commandes. L'image est un modèle immuable ; un conteneur est une instance en cours d'exécution avec sa propre couche inscriptible et sa propre configuration d'exécution. Les données et les artefacts de modèle peuvent être inclus ou montés à partir d'un stockage externe, en fonction de la taille, du contrôle d'accès et de la stratégie de mise à jour. L’ordre des couches affecte la mise en cache de build. Si les métadonnées de dépendance changent rarement, la copie d'un fichier de verrouillage et l'installation de packages avant de copier le code source qui évolue rapidement permettent à Docker de réutiliser la couche de dépendance coûteuse. Les builds en plusieurs étapes utilisent une étape pour compiler ou préparer les artefacts et une étape ultérieure pour inclure uniquement ce dont l'exécution a besoin. Cela peut réduire la taille de l'image et supprimer les outils de construction, bien qu'une copie imprudente puisse omettre les bibliothèques d'exécution requises. La reproductibilité nécessite plus que l'écriture d'un Dockerfile. Épinglez les dépendances, sélectionnez une image de base explicite, préservez le contexte de construction et enregistrez les versions des artefacts du modèle. Une épingle de résumé peut identifier une image précise, tandis qu'une balise mobile peut ultérieurement faire référence à un contenu différent. Cependant, l’épinglage nécessite un processus de mise à jour délibéré des correctifs de sécurité. Les grands ensembles de données et les secrets appartiennent généralement à l’extérieur de l’image ; transmettre les informations d'identification via un mécanisme d'exécution sécurisé plutôt que de les intégrer dans des arguments ou des couches de construction. Les images de production doivent utiliser le minimum de privilèges, des utilisateurs non root lorsque cela est possible, un minimum de packages et une analyse des vulnérabilités. Les limites de ressources, les vérifications de l'état et la journalisation sont configurées au niveau des couches d'exécution ou d'orchestration. L'accès au GPU et les pilotes dépendent de la configuration de l'hôte et du runtime ; un conteneur ne contient pas le périphérique physique. Testez l'image construite dans un environnement ressemblant à un déploiement, y compris le chargement du modèle, la validation des entrées et le comportement d'arrêt. Les conteneurs améliorent la cohérence des emballages mais ne garantissent pas à eux seuls des résultats numériques identiques sur l’ensemble du matériel, une formation déterministe ou une chaîne d’approvisionnement sécurisée.