Amazon MLA-C01: Entraînement de modèles et optimisation des hyperparamètres — 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

L’entraînement de modèles dans Amazon SageMaker est un processus orchestré qui combine du code d’entraînement conteneurisé, des ressources de calcul, un stockage persistant et des infrastructures de communication distribuée optionnelles. Une tâche d’entraînement SageMaker (training job) est définie par une image d’entraînement ou un estimateur de framework, une spécification des données d’entrée qui pointe vers des emplacements S3, et une configuration des ressources qui inclut InstanceType, InstanceCount et VolumeSizeInGB. Pour l’entraînement spot géré, vous définissez EnableManagedSpotTraining sur true et fournissez MaxWaitTimeInSeconds et MaxRuntimeInSeconds afin que SageMaker puisse enchérir sur la capacité de rechange et reprendre ou arrêter les tâches dans la fenêtre de temps que vous avez autorisée. La création de points de contrôle (checkpointing) est configurée via CheckpointConfig avec S3Uri et LocalPath ; lors de l’utilisation d’instances spot gérées, vous devez créer des points de contrôle fréquemment et définir MaxWaitTimeInSeconds sur une valeur suffisamment supérieure à MaxRuntimeInSeconds pour que les tâches interrompues puissent être relancées.

L’entraînement distribué est mis en œuvre soit par des stratégies de parallélisme de données (data-parallel), soit de parallélisme de modèles (model-parallel). SageMaker prend en charge l’entraînement distribué natif avec parallélisme de données via PyTorch DistributedDataParallel ou Horovod, et propose la bibliothèque smdistributed avec smdistributed.dataparallel pour une communication NCCL optimisée. Le parallélisme de modèles est disponible via smdistributed.modelparallel ou par partitionnement spécifique au framework. La communication inter-nœuds à haut débit nécessite des familles d’instances prenant en charge NVLink et EFA (Elastic Fabric Adapter) — sélectionnez ml.p4d, ml.p3dn, ou d’autres types d’instances compatibles EFA et définissez use_mpi ou use_nccL selon les besoins de votre script d’entraînement pour obtenir une réduction efficace des gradients (all-reduce). Pour les tâches à grande échelle, fournissez des InstanceTypes avec une mémoire GPU et des caractéristiques réseau adaptées à la taille des fragments de votre modèle (model shards) afin d’équilibrer les ratios calcul/communication.

L’optimisation des hyperparamètres est gérée par SageMaker Automatic Model Tuning (AMT), qui lance de nombreuses tâches d’entraînement pour explorer un espace d’hyperparamètres et optimiser une métrique objective. La configuration HyperParameterTuningJobConfig inclut ParameterRanges, ResourceLimits avec MaxNumberOfTrainingJobs et MaxParallelTrainingJobs, et une Strategy (Bayésienne par défaut ; les alternatives incluent Random ou Grid pour des recherches exhaustives ou moins corrélées). Définissez ObjectiveMetricName et MetricDefinitions pour que AMT puisse analyser les journaux d’entraînement ; si votre objectif est le score F1, définissez ObjectiveType sur Maximize et assurez-vous que l’expression régulière (regex) de vos MetricDefinitions correspond à la métrique émise. Pour accélérer l’optimisation tout en maîtrisant le budget, utilisez WarmStartConfig pour réutiliser les résultats des tâches d’optimisation précédentes et activez les politiques d’arrêt anticipé (EarlyStoppingType: Auto) là où elles sont prises en charge pour terminer les tâches d’entraînement non prometteuses.

Services et configuration clés

Lors de la création d’un flux de travail de bout en bout pour l’entraînement et l’optimisation, vous utiliserez couramment plusieurs services AWS et fonctionnalités SageMaker ensemble :

• Amazon SageMaker Training Jobs (API Estimator / CreateTrainingJob)
• SageMaker Automatic Model Tuning (CreateHyperParameterTuningJob)
• SageMaker Model Registry (ModelPackage et CreateModelPackageGroup)
• AWS Glue / AWS Lake Formation pour la centralisation et la sécurisation du catalogue de données
• Amazon S3 pour le stockage durable des points de contrôle et des artefacts

Dans la configuration d’une tâche d’entraînement, vous spécifierez ResourceConfig, y compris InstanceType et InstanceCount, et vous passerez les hyperparamètres via HyperParameters. Pour l’entraînement spot géré, incluez EnableManagedSpotTraining et définissez CheckpointConfig.S3Uri pour que les tâches interrompues sauvegardent leur état. Lors du lancement de tâches d’optimisation via CreateHyperParameterTuningJob, remplissez HyperParameterTuningJobConfig.ParameterRanges avec des entrées IntegerParameterRange, ContinuousParameterRange et CategoricalParameterRange, et définissez ResourceLimits avec MaxNumberOfTrainingJobs et MaxParallelTrainingJobs. Utilisez WarmStartConfig avec ParentHyperParameterTuningJobs et définissez WarmStartType sur IDENTICAL_DATA_AND_ALGORITHM ou TRANSFER_LEARNING pour amorcer la recherche à partir de résultats précédents.

Pour la sécurité et le contrôle opérationnel, centralisez les artefacts de modèle en enregistrant des objets ModelPackage dans un ModelPackageGroup au sein du SageMaker Model Registry ; définissez ModelApprovalStatus sur PendingManualApproval pour exiger un passage manuel à l’état Approved avant le déploiement. Combinez les événements du Model Registry avec AWS CodePipeline ou AWS Step Functions pour construire une action d’approbation manuelle qui met à jour ModelPackage.ModelApprovalStatus via l’API UpdateModelPackage. Pour surveiller les points de terminaison (endpoints) en direct et détecter la dérive (drift), activez DataCaptureConfig sur les points de terminaison et utilisez SageMaker Model Monitor pour établir une base de référence des statistiques de pré-déploiement avec CreateMonitoringSchedule, puis utilisez la capture de données de BatchTransform ou RealTimeInference avec S3 DestinationS3Uri pour une évaluation continue.

Patrons de conception et compromis

Choisir un entraînement distribué en parallélisme de données avec de nombreux fragments (shards) plus petits permet une mise à l’échelle simple et constitue généralement le patron le plus simple lorsque votre modèle tient sur un seul GPU. Les approches de parallélisme de données utilisant PyTorch DDP ou Horovod se mettent bien à l’échelle si l’infrastructure réseau est à haute performance et si les instances prennent en charge EFA et NCCL. Lorsque les poids du modèle dépassent la mémoire d’un seul GPU, le parallélisme de modèle ou le parallélisme de pipeline est requis ; smdistributed.modelparallel aide à partitionner les tenseurs sur plusieurs GPU, mais cela augmente la complexité du débogage, de la gestion des points de contrôle (checkpointing) et de l’équilibrage entre le calcul et la communication. Un patron de conception pratique est l’approche hybride : utiliser le partitionnement de modèle (model sharding) pour les très grandes couches et le parallélisme de données entre les groupes de workers.

Les compromis en matière d’optimisation des hyperparamètres concernent principalement le temps par rapport au coût. Une recherche large de type Aléatoire (Random) ou en Grille (Grid) est simple mais coûteuse ; l’optimisation bayésienne (la stratégie par défaut d’AMT) utilise les résultats précédents pour concentrer la recherche et peut réduire le nombre de tâches d’entraînement nécessaires pour atteindre une bonne configuration. Utilisez WarmStartConfig pour transférer les connaissances d’une optimisation précédente vers de nouvelles expériences lorsque les changements du jeu de données ou du modèle sont incrémentiels. La parallélisation de nombreuses tâches d’entraînement accélère l’optimisation en temps réel (wall-clock) mais augmente le coût instantané et peut atteindre les quotas de service ; configurez MaxParallelTrainingJobs de manière conservatrice et utilisez des instances Spot pour les tâches d’optimisation afin de réduire les dépenses, mais configurez toujours CheckpointConfig et MaxWaitTimeInSeconds pour tolérer les interruptions.

La fréquence des points de contrôle et le choix du stockage affectent à la fois la résilience et le coût. Des points de contrôle fréquents réduisent la perte de calcul lors des interruptions mais ajoutent une surcharge en termes de débit (throughput) et de latence sur S3 ; utilisez la gestion de points de contrôle incrémentielle à l’intérieur du conteneur (LocalPath) et synchronisez de manière asynchrone avec S3 pour une récupération durable. Lors de l’entraînement sur des instances spot gérées, définissez un intervalle de point de contrôle robuste et utilisez un plus petit nombre d’instances pour les tâches d’entraînement qui peuvent se terminer dans les fenêtres d’interruption typiques, ou concevez la boucle d’entraînement pour tolérer la préemption en utilisant les hooks SIGTERM fournis par SageMaker pour encadrer la création de points de contrôle cohérents.

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

Un piège opérationnel courant consiste à s’appuyer sur des images de conteneurs personnalisées sans tests de performance ; les images fournies par le framework (images pré-construites PyTorch, TensorFlow, XGBoost de SageMaker) démarrent plus rapidement, incluent une intégration pour l’émission automatique de métriques et minimisent la latence de démarrage à froid (cold-start). Une autre erreur fréquente en HPO est d’avoir des MetricDefinitions ou un ObjectiveMetricName mal configurés, ce qui empêche AMT de trouver et d’optimiser le bon signal ; validez toujours l’expression régulière (regex) utilisée pour extraire les métriques des journaux avant de mettre à l’échelle une tâche de réglage (tuning job). Négliger d’activer CheckpointConfig lors de l’utilisation de l’entraînement spot géré entraînera la perte de la progression de la tâche en cas d’interruption et peut conduire à une durée d’exécution cumulée plus longue et à un coût plus élevé.

Les décisions en matière de sécurité et de gouvernance doivent être centrées sur le moindre privilège et le contrôle du cycle de vie du modèle. Utilisez SageMaker Model Registry avec le flux de travail d’approbation de ModelPackage et les politiques IAM pour garantir que seules les versions autorisées de ModelPackage atteignent la production. Protégez les données d’entraînement dans S3 avec le chiffrement (SSE-S3 ou SSE-KMS) et contrôlez l’accès via les rôles IAM assumés par la tâche d’entraînement (paramètre RoleArn dans CreateTrainingJob) et Lake Formation lorsque des politiques d’accès centralisées aux données sont requises. Pour la détection de dérive et l’analyse des causes profondes, combinez SageMaker Model Monitor avec les artefacts de Model Registry pour suivre quelles versions d’artefacts se dégradent et déclencher des flux d’approbation avec intervention humaine (human-in-the-loop) avant le redéploiement.

Problème pratique : Scénario d’utilisation

Entreprise : FinGuard Inc. — Défi : construire un modèle de détection de fraude entraîné sur des journaux de transactions stockés dans S3 et des profils clients dans une base MySQL sur site (on-premises), minimiser les coûts, tolérer les interruptions des instances spot, exécuter une optimisation automatisée des hyperparamètres, imposer une approbation manuelle avant le déploiement en production, et détecter les biais ou la dérive après le déploiement.

1. Agrégation et préparation des données : Ingérer directement les journaux de transactions S3 et utiliser AWS Glue avec une connexion JDBC à la base de données MySQL sur site pour crawler et cataloguer les tables de profils clients. Enregistrer les caractéristiques (features) préparées dans un FeatureGroup de SageMaker Feature Store pour un accès à faible latence et pour garantir la cohérence du schéma ; chiffrer l’OfflineStore S3 avec SSE-KMS et contrôler l’accès via les politiques IAM et Lake Formation.

2. Entraînement et configuration distribuée : Utiliser un SageMaker Estimator avec un conteneur XGBoost intégré pour le modèle initial ; configurer ResourceConfig avec InstanceType ml.m5.4xlarge pour la référence et passer à ml.p3.2xlarge pour les expériences accélérées par GPU. Pour les expériences à grande échelle, utiliser smdistributed.dataparallel sur des instances compatibles EFA (ml.p3dn.24xlarge ou ml.p4d.24xlarge) et définir CheckpointConfig.S3Uri sur s3://finguard-checkpoints/{job-name} et LocalPath sur /opt/ml/checkpoints. Activer l’entraînement spot géré en définissant EnableManagedSpotTraining sur true et en définissant MaxWaitTimeInSeconds à au moins 2 fois MaxRuntimeInSeconds pour permettre les nouvelles tentatives.

3. Optimisation des hyperparamètres : Lancer SageMaker Automatic Model Tuning avec HyperParameterTuningJobConfig.ParameterRanges pour eta, max_depth et scale_pos_weight (pour gérer le déséquilibre des classes sans pré-traitement lourd). Définir ObjectiveMetricName sur validation:F1 et fournir une expression régulière (regex) dans MetricDefinitions qui extrait la valeur F1. Utiliser la stratégie bayésienne (Strategy Bayesian), ResourceLimits avec MaxNumberOfTrainingJobs 50 et MaxParallelTrainingJobs 5, et WarmStartConfig si vous itérez à partir de résultats de réglage précédents. Exécuter les tâches de réglage sur des instances spot gérées pour réduire les coûts, en s’assurant que CheckpointConfig est actif pour chaque tâche d’entraînement.

4. Gouvernance et déploiement du modèle : Enregistrer les meilleurs artefacts du modèle dans SageMaker Model Registry en tant que ModelPackage au sein d’un ModelPackageGroup et définir ModelApprovalStatus sur PendingManualApproval. Implémenter un pipeline AWS Step Functions qui inclut une étape d’approbation humaine (tâche manuelle) et qui, après approbation, appelle UpdateModelPackage pour définir ModelApprovalStatus sur Approved, puis déclenche CreateModel et CreateEndpointConfig/CreateEndpoint pour le déploiement. Utiliser DataCaptureConfig sur le point de terminaison (Endpoint) pour capturer les requêtes et les réponses d’inférence vers s3://finguard-capture pour Model Monitor.

Justification AWS : AWS Glue centralise et catalogue les sources de données hybrides et s’intègre avec SageMaker ; SageMaker Feature Store standardise les caractéristiques (features) et les sécurise pour l’entraînement et l’inférence ; l’entraînement spot géré associé à CheckpointConfig réduit les coûts de calcul tout en préservant la progression malgré les préemptions ; SageMaker Automatic Model Tuning avec MetricDefinitions et WarmStartConfig accélère la recherche d’hyperparamètres robustes tout en maîtrisant le budget ; Model Registry avec PendingManualApproval, associé à Step Functions ou CodePipeline, impose la gouvernance et la promotion des modèles en production selon le principe du moindre privilège ; SageMaker Model Monitor et DataCaptureConfig fournissent une détection automatisée de la dérive et des biais pour des contrôles continus de la santé du modèle.

← Ingénierie des données et ingénierie des caractéristiques · Tous les domaines · Évaluation et sélection de modèles →

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

Parcourir Amazon →