Amazon MLA-C01: Optimisation des coûts pour les charges de travail ML — Guide d'étude

By Laurynas Brazys · 3 August 2026 · #amazon #mla-c01 #certification #exam-prep #study-guide

Fait partie du AWS Machine Learning Engineer Associate MLA-C01 — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Amazon, ou passez des tests chronométrés sur ExamRoll.io.

Concept de base : d’où viennent les coûts et les leviers que vous pouvez actionner

Le coût des charges de travail de machine learning est déterminé par trois catégories fondamentales : le calcul pour l’entraînement et l’inférence, le stockage et le transfert de données pour les jeux de données et les points de contrôle, et les frais opérationnels liés à une infrastructure sous-utilisée ou mal provisionnée. L’entraînement est souvent le poste de dépense le plus important lorsque vous entraînez de grands modèles ou exécutez de nombreuses expériences. Le coût de l’inférence domine lorsque vous servez des modèles à grande échelle ou que vous avez besoin d’une faible latence pour des applications interactives. Les principaux leviers d’optimisation sont le choix de la famille et de la taille d’instance, les options d’achat (à la demande, Spot ou Savings Plans), les modèles de cycle de vie du modèle (batch, temps réel ou serverless) et les optimisations d’exécution telles que la compilation de modèle, la mise en cache et la consolidation d’instances.

Les techniques opérationnelles mettent ces leviers en pratique. Utilisez l’entraînement Spot géré avec la création de points de contrôle pour réduire les coûts de calcul pour l’entraînement jusqu’à 70 % par rapport à l’utilisation à la demande, mais associez-le à la création de points de contrôle (paramètre CheckpointConfig → S3Uri de CreateTrainingJob) et à l’indicateur EnableManagedSpotTraining de CreateTrainingJob défini sur true pour que les tâches puissent reprendre après des interruptions. Dimensionnez correctement les instances en profilant l’utilisation réelle du CPU/GPU/IO (métriques CloudWatch telles que GPUUtilization, HostCPUUtilization et les traces du profileur de SageMaker Debugger), puis passez à des familles de calcul qui correspondent aux caractéristiques de la charge de travail (ml.c5/ml.c6 pour le CPU, ml.g5/ml.p4 pour le GPU, ml.r5 pour une forte consommation de mémoire). Pour l’inférence, préférez les modèles à coût proportionnel : utilisez l’inférence serverless (variante de production de CreateEndpointConfig avec ServerlessConfig → MemorySizeInMB et MaxConcurrency) pour les charges de travail irrégulières et à faible débit ; utilisez des points de terminaison multi-modèles ou la compilation de modèles (SageMaker Neo) pour réduire les besoins en instances pour de nombreux petits modèles ; et déplacez les charges de travail volumineuses ou peu sensibles à la latence vers des transformations asynchrones ou par lots (AsyncInferenceConfig et Batch Transform).

Services et configuration clés

Amazon SageMaker expose des paramètres explicites pour le contrôle des coûts. Pour réduire les coûts d’entraînement, utilisez l’entraînement Spot géré : dans l’API CreateTrainingJob, définissez EnableManagedSpotTraining=true, incluez CheckpointConfig.S3Uri et définissez MaxWaitTimeInSeconds > MaxRuntimeInSeconds pour permettre l’acquisition de capacité Spot. Dans le SDK Python de SageMaker, vous pouvez définir estimator.use_spot_instances=True, estimator.max_wait et estimator.checkpoint_s3_uri sur l’emplacement du point de contrôle S3. Pour une faible latence reproductible entre les tâches d’entraînement consécutives, maintenez les conteneurs pré-chauffés (warm) en tirant parti de SageMaker Processing ou en entraînant des conteneurs sur une infrastructure provisionnée persistante lorsque la cadence d’expérimentation l’exige ; sinon, réduisez le temps de démarrage des conteneurs en utilisant des images de conteneur plus petites, des conteneurs SageMaker préconfigurés ou en réutilisant une instance d’entraînement persistante dans un environnement de développement.

Pour le contrôle des coûts d’inférence, CreateEndpointConfig/UpdateEndpointConfig prend en charge plusieurs stratégies. Utilisez ServerlessConfig dans ProductionVariants pour laisser SageMaker gérer la mise à l’échelle et facturer par invocation et par mémoire plutôt que par heures d’instance complètes ; le ServerlessConfig nécessite les valeurs MemorySizeInMB et MaxConcurrency. Pour les charges de travail stables et à haut débit, utilisez des instances provisionnées et appliquez des politiques de suivi de cible Application Auto Scaling au point de terminaison pour éviter le sur-provisionnement. Les points de terminaison multi-modèles réduisent les coûts lorsque vous hébergez de nombreux modèles rarement utilisés en partageant un seul conteneur et en chargeant les artefacts de modèle depuis S3 à la demande. Pour des recommandations sur le dimensionnement des modèles, appelez CreateInferenceRecommendationsJob dans Inference Recommender, qui fournit des conseils sur le type d’instance, la taille de lot (batch size) et la latence/le débit.

Les engagements de facturation sont mieux gérés avec les SageMaker Savings Plans ou les AWS Compute Savings Plans. Achetez un Savings Plan via la console AWS Billing pour vous engager sur un montant en $/heure sur une période de 1 ou 3 ans ; cela offre une réduction sur le calcul SageMaker à la demande (entraînement et hébergement) pour toutes les familles d’instances. Notez que les Savings Plans s’appliquent à l’utilisation à la demande et non à l’utilisation Spot. Combinez donc les stratégies : achetez des Savings Plans pour l’utilisation de base stable et utilisez des instances Spot pour l’entraînement en rafale ou expérimental.

Patrons de conception et compromis

Le patron Spot géré + points de contrôle est la solution de prédilection pour les entraînements distribués longs ou de grande envergure. Il ne nécessite que des modifications de code minimes : activez EnableManagedSpotTraining, fournissez CheckpointConfig.S3Uri et définissez un MaxWaitTimeInSeconds approprié pour tolérer la planification Spot. Le compromis réside dans la complexité du redémarrage et un temps d’exécution total légèrement plus long si les interruptions Spot sont fréquentes ; l’avantage est une réduction drastique des coûts. Pour l’expérimentation itérative où la latence de démarrage entre les tâches consécutives est importante, maintenez un environnement de développement « chaud » (warm) : utilisez des instances provisionnées plus petites de type ml.m5 ou ml.c5 avec des données préchargées sur un cache NVMe/local, ou exécutez de nombreuses expériences en tant que tâches de traitement local sur la même instance en utilisant SageMaker Processing ou les notebooks Studio. Cela augmente le coût de base mais réduit le temps de cycle total.

Pour l’inférence, choisissez entre des points de terminaison serverless et provisionnés en fonction du profil de trafic. L’inférence serverless (ServerlessConfig) élimine la planification de capacité et constitue la solution la moins coûteuse pour un trafic intermittent et imprévisible, car vous payez par invocation et par allocation de mémoire. Le compromis est la latence de démarrage à froid (cold start) et les limites de taille ; pour des SLA de faible latence stricts, préférez des instances provisionnées avec mise à l’échelle automatique (autoscaling) et envisagez l’optimisation du modèle avec SageMaker Neo pour réduire le nombre d’instances. Lorsque de nombreux modèles doivent être hébergés mais que le trafic par modèle est faible, les points de terminaison multi-modèles consolident l’utilisation du disque et de la mémoire et réduisent le coût par modèle, au prix d’un temps de chargement à froid légèrement plus élevé pour un modèle non chargé.

Le dimensionnement correct (right-sizing) doit d’abord reposer sur l’observation, et non sur des suppositions. Utilisez le profilage de SageMaker Debugger et CloudWatch pour collecter les métriques GPUUtilization et DiskReadOps ; puis exécutez une tâche Inference Recommender (CreateInferenceRecommendationsJob) pour valider la classe/le type d’instance et les performances. Si les exigences de latence du modèle sont strictes, envisagez la quantification du modèle ou sa compilation avec SageMaker Neo, ou l’utilisation d’accélérateurs Elastic Inference pour attacher une capacité d’inférence GPU fractionnée à des instances CPU ; Elastic Inference vous permet d’attacher un petit accélérateur à une instance CPU, réduisant ainsi le coût par rapport à des instances GPU complètes pour certains modèles.

Pièges courants et critères de décision

Une erreur fréquente consiste à appliquer une seule optimisation des coûts à toutes les charges de travail. Les Savings Plans sont puissants pour une utilisation de base stable, mais doivent être combinés avec Spot pour les charges de travail expérimentales et le serverless pour l’inférence avec des pics de trafic. Ne présumez pas que Spot est gratuit — il nécessite la mise en place de points de contrôle (checkpointing) et une logique d’entraînement tolérante aux interruptions ; configurez CreateTrainingJob.CheckpointConfig et EnableManagedSpotTraining, et calculez un MaxWaitTimeInSeconds qui reflète la durée pendant laquelle vous accepterez un démarrage retardé. Un autre piège est de négliger la télémétrie : sans profilage (SageMaker Debugger, CloudWatch et Inference Recommender), vous risquez de sur-provisionner ou de choisir une famille d’instances dont les caractéristiques CPU, GPU et mémoire sont mal alignées. Enfin, l’inférence serverless simplifie les coûts mais peut introduire des démarrages à froid (cold starts) imprévisibles ; mesurez la latence de bout en bout lors de l’utilisation de ServerlessConfig et revenez à des points de terminaison provisionnés avec autoscaling pour les SLA stricts.

Problème pratique : Scénario d’utilisation

Entreprise : FinSight Analytics. Défi : FinSight doit construire un pipeline de détection de fraude qui s’entraîne fréquemment sur des journaux de transactions et des profils clients stockés sur S3, maintient les données isolées, prend en charge la gouvernance des versions de modèles avec une approbation manuelle avant le déploiement en production, réduit les coûts d’entraînement pour le réentraînement nocturne, minimise la latence de démarrage par tâche lors de l’expérimentation rapide, et dessert un point de terminaison temps réel à faible latence avec une sensibilité aux coûts pour le trafic en pics.

Registre de modèles et de données centralisé et sécurisé. Stockez les données dans un compartiment S3 sécurisé avec un chiffrement par défaut et des politiques de compartiment qui restreignent l’accès au rôle d’exécution de SageMaker. Enregistrez les modèles dans SageMaker Model Registry ; utilisez l’étape RegisterModel de SageMaker Pipelines pour créer des paquets de modèles avec ModelApprovalStatus défini par défaut sur “PendingManualApproval”. Mettez en œuvre le flux de travail humain d’approbation manuelle en créant un pipeline SageMaker qui émet un paquet de modèle et une étape d’approbation manuelle ; lorsque les réviseurs autorisés terminent la validation, ils appellent boto3 sagemaker.update_model_package(ModelPackageName=…, ModelApprovalStatus=‘Approved’) pour autoriser le déploiement. Justification : Model Registry fournit un versioning centralisé, et ModelApprovalStatus s’intègre directement avec les API de SageMaker pour un minimum d’opérations personnalisées.
Réentraînement nocturne rentable. Utilisez l’entraînement Spot managé en créant des tâches d’entraînement avec EnableManagedSpotTraining=true, incluez CheckpointConfig.S3Uri pour persister l’état de l’optimiseur, et définissez MaxRuntimeInSeconds et MaxWaitTimeInSeconds de manière appropriée pour que les tâches puissent reprendre après les interruptions Spot. Combinez cela avec l’achat d’un Savings Plan de base dimensionné pour couvrir les heures moyennes d’entraînement/inférence à la demande afin de réduire les coûts stables, et utilisez Spot pour l’expérimentation où les interruptions sont tolérables. Justification : L’entraînement Spot managé réduit les coûts de calcul avec des changements de code minimes ; les Savings Plans s’appliquent à l’utilisation de base à la demande pour diminuer les dépenses prévisibles.
Réduire la latence de démarrage pour l’expérimentation. Pour les cycles d’expérimentation interactifs, maintenez un profil d’instance de développement persistant (un ml.c5 ou ml.m5) dans SageMaker Studio ou une petite instance de notebook dédiée avec des jeux de données préchargés sur EBS/NVMe et réutilisez cet environnement pour de nombreuses exécutions d’entraînement rapides. Pour les tâches nocturnes de production, continuez d’utiliser l’entraînement Spot managé avec des points de contrôle. Justification : Un environnement persistant évite les démarrages à froid des conteneurs et améliore la vitesse d’itération tout en préservant les économies de coûts pour les exécutions lourdes.
Service temps réel à faible latence et sensible aux coûts. Déployez le modèle approuvé sur un point de terminaison provisionné pour une faible latence de base et attachez une politique Application Auto Scaling au point de terminaison pour réduire la capacité (scale down) pendant les heures creuses. Pour les pics de trafic imprévisibles, mettez en place une option d’inférence Serverless pour les modèles à faible volume ou utilisez l’inférence asynchrone (AsyncInferenceConfig avec S3 OutputConfig) pour les tâches lourdes de scoring par lots non temps réel. Appliquez la compilation SageMaker Neo au modèle avant le déploiement pour réduire son empreinte CPU/GPU. Justification : La combinaison provisionné + autoscaling offre une faible latence stable et un contrôle des coûts ; les points de terminaison serverless ou asynchrones gèrent les charges de travail en pics ou par lots de manière plus rentable, et Neo réduit les besoins en instances.

Cette approche combine EnableManagedSpotTraining avec CheckpointConfig pour la réduction des coûts d’entraînement, SageMaker Model Registry et UpdateModelPackage pour les approbations manuelles, une instance de développement persistante pour une latence de démarrage réduite, et un mélange de modèles provisionnés, serverless et compilés pour optimiser les coûts d’inférence.

← IA générative et modèles de fondation · Tous les domaines · Vision par ordinateur →

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →