Nous remercions Victor Barrau, notre collaborateur avec qui nous avons écrit cet article.
Dans un contexte où l'industrialisation des modèles de machine learning devient critique pour les entreprises, AWS SageMaker Batch Transform se présente comme une solution robuste pour le traitement par lots des inférences. Cet article explore comment adapter un modèle externe (BYOC - Bring Your Own Container) à SageMaker Batch Transform et pourquoi cette approche peut être pertinente pour votre cas d'usage.
Pourquoi faire du batch ?
Le choix du traitement par batch plutôt que du temps réel repose sur plusieurs considérations stratégiques :
- Optimisation des ressources : un endpoint en temps réel implique des ressources allouées en permanence, même lorsqu’il n’est pas sollicité. Le batch processing, en revanche, fonctionne à la demande, optimisant l’usage des infrastructures.
- Réduction des coûts : la facturation est basée uniquement sur l’exécution des tâches, ce qui est idéal pour les charges de travail intermittentes.
- Scalabilité : capable de gérer de vastes volumes de données, le batch processing est adapté aux besoins où la latence en temps réel n’est pas nécessaire.
- Simplicité opérationnelle : la gestion des infrastructures est plus simple qu’une architecture en temps réel, réduisant ainsi la complexité de déploiement et de maintenance.
Le traitement par batch est pertinent pour des tâches comme l’inférence sur un grand jeu de données en une seule exécution, l’analyse d’images ou de documents en masse, ou encore la classification de contenus. Ces cas d’usage ne nécessitent pas une réponse instantanée, car les résultats peuvent être exploités après coup sans impacter directement l’expérience utilisateur ou le processus métier en temps réel.
Quand choisir AWS Sagemaker et pourquoi ?
AWS SageMaker est une plateforme managée qui propose un ensemble de services pour le développement, l'entraînement et le déploiement de modèles de machine learning. Cette approche managée délègue la gestion des infrastructures à AWS, permettant aux équipes de se concentrer sur le développement des modèles plutôt que sur l'orchestration des ressources.
La plateforme offre une intégration native avec l'écosystème Python et les frameworks ML courants (TensorFlow, PyTorch, Scikit-Learn). SageMaker couvre différentes étapes du cycle de vie ML à travers des services modulaires : développement interactif (Studio, Data Wrangler), entraînement (Training distribué, AutoML) et déploiement (Batch Transform, Endpoints, Pipelines, Model Monitor).
Cette approche modulaire permet aux équipes d'adopter uniquement les services nécessaires à leur projet. L'intégration avec les autres services AWS (S3, IAM, CloudWatch, Lambda) facilite l'intégration dans un écosystème existant.
Cependant, cette approche présente certaines contraintes :
- Couplage avec l'écosystème AWS
- Courbe d'apprentissage pour maîtriser les spécificités SageMaker
- Coûts potentiellement plus élevés pour des cas d'usage simples
- Moins de contrôle granulaire comparé à une solution sur-mesure
Le choix de SageMaker dépend donc du contexte : taille de l'équipe, expertise DevOps disponible, contraintes budgétaires et besoins de scalabilité.
Par exemple, les équipes disposant d'une forte expertise Kubernetes préféreront souvent Kubeflow pour sa portabilité multi-cloud et la maîtrise complète de l'orchestration.
De même, les projets nécessitant un contrôle fin de l'infrastructure, comme le debugging avancé des modèles ou l'implémentation d'optimisations système spécifiques, trouveront les abstractions de SageMaker limitantes. Dans ces cas, une approche custom sur EC2 ou Kubernetes offre la granularité nécessaire, même si elle implique une charge opérationnelle plus importante.
Enfin, les contraintes de souveraineté des données peuvent rendre SageMaker inadapté lorsque l'hébergement doit se faire dans des datacenters spécifiques ou sous certaines juridictions.
Alternatives à SageMaker Batch Transform dans l’environnement AWS
Bien que SageMaker Batch Transform soit une solution robuste, d'autres approches méritent considération selon le contexte et les contraintes spécifiques du projet.
AWS Batch avec Step Functions constitue une alternative pour les équipes recherchant un contrôle sur l'infrastructure tout en conservant les bénéfices d'un service managé. Cependant, elle demande une expertise plus poussée en configuration AWS et peut présenter des temps de démarrage à froid impactant les performances pour des tâches courtes.
ECS avec Step Functions s’adresse aux équipes techniques privilégiant la flexibilité maximale. Cette architecture permet un paramétrage fin des ressources et des stratégies d'auto-scaling. La contrepartie réside dans une complexité opérationnelle significative et des coûts potentiellement plus élevés sans un monitoring rigoureux.
Amazon EKS (Elastic Kubernetes Service) représente une option intéressante pour les équipes déjà familiarisées avec l'écosystème Kubernetes. Cette approche offre une portabilité multi-cloud et permet d'exploiter des outils spécialisés comme Kubeflow pour les workflows ML. EKS convient particulièrement aux organisations ayant une stratégie container-first ou souhaitant maintenir une cohérence technologique avec leurs autres applications. Cependant, cette solution nécessite une expertise Kubernetes solide et implique une charge opérationnelle plus importante que les services managés.
Le choix optimal dépend de plusieurs facteurs : la maturité de l'équipe, les contraintes budgétaires et la stratégie cloud de l'organisation. SageMaker reste pertinent pour les équipes privilégiant la rapidité de mise en œuvre et l'intégration native avec l'écosystème AWS, tandis que les alternatives offrent plus de contrôle au prix d'une complexité accrue.
Comment utiliser Batch Transform pour différents besoins ?
Si SageMaker Batch Transform est principalement conçu pour l'inférence par lots, son utilisation peut être étendue à d'autres cas d'usages stratégiques dans le cycle de vie des modèles de machine learning. Cette section explore les applications pratiques de Batch Transform au-delà de son utilisation conventionnelle.
Batch Transform appliqué au cycle de développement et validation.
Même si l'entraînement classique se fait généralement via des jobs dédiés, Batch Transform offre des atouts significatifs pour la phase de validation et d'expérimentation. Cette approche permet de couvrir une multitude d'actions nécessaires pour la mise en production :
- Validation à grande échelle : après l'entraînement, évaluer la robustesse du modèle sur des datasets étendus via des jobs parallélisés, sans nécessiter d'endpoints permanents.
- Tests A/B comparatifs : appliquer différentes versions de modèles sur des batchs identiques pour une analyse objective des performances et décider quelle version déployer en production.
- Détection de data drift : le "data drift" désigne la divergence entre données d'entraînement et de production, causant une dégradation des performances. Un modèle de ventes de glaces entraîné sur des données d'été perdra en précision l'hiver. Batch Transform permet de détecter périodiquement ces dérives sur des échantillons récents, anticipant ainsi les besoins de ré-entraînement avant une dégradation significative.
Comment créer un modèle Sagemaker à partir d’un modèle de machine learning entraîné en local
Un modèle Sagemaker est capable d’exécuter un ou plusieurs modèles de machine learning. Pour créer un modèle Sagemaker, il est nécessaire de fournir une image de conteneur qui sera utilisée pour effectuer les inférences. Cette image est appelée image primaire. Des images secondaires peuvent également être fournies au modèle si nécessaire.
Supposons que nous disposons d’un modèle de machine learning entraîné hors de Sagemaker (approche BYOC) et possédant des fichiers de poids (dans le cadre du transfert learning par exemple). Pour importer ce modèle dans Sagemaker afin de l’utiliser pour effectuer des inférences, il faut que ce modèle soit partie intégrante d’un modèle Sagemaker.
Pour ce faire, il faut procéder comme suit :
- Conteneuriser le modèle (s’il ne l’est pas déjà) et stocker l’image du conteneur dans un registre ECR (Elastic Container Registry).
- Créer une archive (au format tar.gz) contenant les artefacts du modèle de machine learning (ici le dossier contenant les fichiers de poids) puis stocker cette archive dans un bucket S3. En effet, Sagemaker exige dans certains cas tels que l’utilisation de Batch Transform, que les artefacts du modèle soient stockés dans un fichier compressé. Hormis ces cas, il est possible de créer un modèle ne nécessitant pas de compression préalable des artefacts en spécifiant à la création du modèle l’option ModelDataSource afin d’indiquer l’emplacement dans S3 où sont stockés les artefacts du modèle.
- Créer le modèle Sagemaker en lui fournissant l’image primaire à utiliser et le lien vers l’archive contenant les artefacts du modèle.
Comment optimiser les inférences avec Sagemaker ?
Sagemaker propose un large éventail d’instances pour la réalisation d’inférences. Le choix du type d’instance approprié à vos besoins dépend des performances que vous souhaitez atteindre et de votre budget. Optimiser les inférences nécessite d’effectuer des tests de charge sur différents types d’instances et avec différentes configurations telles que l’exécution de tâches sur une seule instance ou la parallélisation de tâches sur plusieurs instances.
Dans le cas d’une tâche Batch Transform, il est possible d’optimiser l’inférence en modifiant dans la configuration de lancement de la tâche les valeurs par défaut de certains paramètres tels que MaxConcurrentTransforms, BatchStrategy, et MaxPayloadInMB. Si aucune valeur n’a été renseignée pour ces paramètres, avant d’utiliser leurs valeurs par défaut, SageMaker enverra une requête HTTP GET à l'instance lorsqu’elle démarrera, sur le point de terminaison /execution-parameters (si vous l’avez implémenté dans le modèle).
Méthodologie pour les tests de charge
La première étape consiste à tester votre modèle sur une instance de base (ml.m5.large par exemple) avec les paramètres par défaut. Cette baseline vous permettra d'évaluer l'impact des optimisations suivantes.
Testez ensuite différentes configurations en ne modifiant qu'un paramètre à la fois. Par exemple, augmentez progressivement MaxConcurrentTransforms de 1 à 4, puis testez différentes valeurs de MaxPayloadInMB. Cette approche méthodique permet d'identifier l'impact de chaque paramètre indépendamment.
Les métriques clés à surveiller incluent :
- Le débit : nombre d'inférences par minute
- La latence moyenne : temps moyen par requête
- L'utilisation des ressources : CPU, mémoire et GPU si applicable
- Le coût par inférence : calcul du coût total divisé par le nombre d'inférences
Comme nous pouvons le constater, l’optimisation des inférences nécessite des compétences en machine learning, du temps et des efforts (qui peuvent parfois être conséquents) pour pouvoir effectuer les tests nécessaires. Afin de faciliter ce processus, Sagemaker dispose d’une fonctionnalité nommée SageMaker Inference Recommender : c’est un outil qui permet d’automatiser les tests de charge et d’effectuer des recommandations sur les instances susceptibles d’être les plus adaptées à la réalisation d’inférences avec votre modèle.
SageMaker Inference Recommender automatise ce processus d'optimisation en lançant des tests comparatifs sur différents types d'instances et configurations. L'outil évalue automatiquement diverses valeurs pour MaxConcurrentTransforms, BatchStrategy et MaxPayloadInMB, puis présente les résultats sous forme de métriques de performance et d'utilisation des ressources. Cette approche vous évite les tests manuels fastidieux et vous aide à identifier rapidement la configuration optimale pour vos besoins spécifiques.
Choix CPU vs GPU
Important à retenir : SageMaker Batch Transform ne propose pas d'autoscaling automatique. Le nombre d'instances est défini au lancement du job et reste fixe pendant toute sa durée. Cette approche diffère des endpoints en temps réel qui supportent l'autoscaling.
Choix entre CPU et GPU : Les instances CPU (séries ml.m5, ml.c5) sont généralement suffisantes pour :
- Les modèles de machine learning classiques (régression, classification avec scikit-learn)
- Le traitement de données tabulaires
- Les modèles de NLP légers
Les instances GPU (séries ml.p3, ml.g4dn) sont nécessaires pour :
- Les réseaux de neurones
- Le traitement d'images
- Les modèles de NLP volumineux
- Toute inférence nécessitant des calculs matriciels intensifs
Conclusion
AWS SageMaker Batch Transform constitue une option viable pour l'industrialisation des modèles de machine learning lorsque l'inférence en temps réel n'est pas requise. Cette solution peut s'étendre au-delà du traitement par lots classique pour couvrir la validation de modèles, la détection de data drift, ou l'optimisation des pipelines MLOps.
L'approche BYOC (Bring Your Own Container) offre la flexibilité nécessaire pour adapter des modèles existants. Cette flexibilité implique cependant une responsabilité en termes d'optimisation : comprendre les paramètres de configuration et mettre en place une méthodologie de test appropriée reste essentiel pour obtenir des performances satisfaisantes.
Avant de choisir cette solution, il convient d'évaluer si les bénéfices (infrastructure managée, intégration AWS) compensent les contraintes (couplage, coûts, courbe d'apprentissage) par rapport aux alternatives disponibles.
