Amazon MLA-C01: Déploiement de modèles et inférence — 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.

Points de terminaison temps réel, serverless, asynchrones et par lots — concept de base

L’inférence en temps réel dans Amazon SageMaker est un modèle de service avec état et à faible latence où vous créez un Model, un EndpointConfig et un Endpoint qui alloue des ressources de calcul provisionnées (types d’instance

undefined

) et reste disponible pour servir les requêtes via l’API

undefined

accepte des

undefined

, et chaque

undefined

définit

undefined

, et

undefined

; vous pouvez modifier le trafic et la capacité avec

undefined

. Pour les besoins prévisibles à faible latence, les points de terminaison en temps réel provisionnés sont l’option principale et prennent en charge les pipelines d’inférence multi-conteneurs pour enchaîner les conteneurs de prétraitement, de modèle et de post-traitement.

L’inférence sans serveur (Serverless Inference) supprime la gestion des instances et est configurée au niveau du point de terminaison avec un

undefined

qui spécifie

undefined

pour chaque

undefined

; SageMaker gère le provisionnement des conteneurs et descend à zéro (scale-to-zero) lorsqu’il est inactif, ce qui le rend idéal pour les charges de travail irrégulières et à faible débit. L’inférence asynchrone (Asynchronous Inference) est optimisée pour les requêtes dont l’exécution est longue ou lorsque le client n’exige pas de réponse synchrone. Un point de terminaison asynchrone est créé avec

undefined

dans

undefined

(

undefined

avec

undefined

optionnel, et

undefined

) et les clients appellent

undefined

, en fournissant un URI S3 d’entrée ; les résultats sont écrits à l’emplacement de sortie S3 configuré. Batch Transform est un type de tâche distinct (

undefined

) pour les charges de travail d’inférence hors ligne volumineuses ; l’API requiert

undefined

(

undefined

avec

undefined

(

undefined

), et

undefined

(

undefined

). Batch Transform est idéal lorsque le débit est plus important que la latence et il prend en charge un parallélisme élevé sur de grands jeux de données.

Points de terminaison multi-modèles, pipelines d’inférence, shadowing et tests A/B — services et configuration clés

Pour héberger de nombreux modèles avec un faible nombre de requêtes par seconde (QPS) par modèle, les points de terminaison multi-modèles (MME) de SageMaker permettent à un seul conteneur d’héberger des dizaines voire des milliers d’artefacts de modèle stockés dans S3 et de les charger à la demande. Vous construisez un conteneur de serveur de modèles qui implémente le pattern de serveur multi-modèles de SageMaker ou utilisez une image de framework prise en charge, téléchargez les archives tar des modèles sur S3, et créez une ressource Model qui référence le conteneur. Au moment de l’invocation, vous passez le nom du modèle cible via le paramètre

undefined

de l’API

undefined

(ou l’en-tête

undefined

) afin que le serveur charge ce modèle depuis S3 en mémoire. Les MME permettent d’économiser de la mémoire et des coûts opérationnels pour de grandes flottes de modèles, mais ajoutent une latence de chargement à froid pour les modèles qui ne sont pas encore résidents dans l’environnement d’exécution.

Les pipelines d’inférence sont implémentés comme des modèles multi-conteneurs où la ressource Model liste les

undefined

dans l’ordre ; le point de terminaison achemine les charges utiles à travers le premier conteneur (prétraitement), puis le conteneur du modèle, puis le conteneur de post-traitement. Définissez chaque conteneur avec son propre

undefined

et ses propres variables d’environnement dans

undefined

. Pour les tests de type canary ou blue/green, utilisez plusieurs

undefined

dans un

undefined

et contrôlez la répartition du trafic avec

undefined

, puis plus tard via

undefined

. Un déploiement shadow (en miroir) peut être réalisé soit en envoyant une copie de chaque requête au niveau de la couche applicative à un point de terminaison shadow (sans poids de trafic sur le point de terminaison de production), soit en créant un

undefined

à faible poids pour que l’infrastructure du point de terminaison reçoive une partie du trafic en miroir ; la duplication des requêtes au niveau de la couche applicative vous offre une isolation complète de l’expérience et une observabilité indépendante.

Pour la surveillance continue et à la demande, configurez

undefined

lors de la création d’un point de terminaison pour persister les charges utiles des requêtes et des réponses sur S3. Les champs d’intérêt de

undefined

incluent

undefined

(true),

undefined

, et

undefined

(

undefined

). Les données capturées deviennent la base pour les vérifications post-déploiement de SageMaker Model Monitor et SageMaker Clarify ; vous pouvez créer des lignes de base avec

undefined

de Model Monitor et exécuter des tâches de traitement (Processing jobs) ad hoc qui utilisent le conteneur de surveillance de modèle intégré pour calculer les contraintes et les métriques de dérive.

Patrons de conception et compromis

Choisissez les points de terminaison provisionnés en temps réel lorsque vous avez besoin d’une latence de quelques millisecondes à deux chiffres (faible) et que vous pouvez vous permettre la capacité toujours active. Si le coût par minute en période d’inactivité est la contrainte principale et que le trafic est intermittent, les points de terminaison sans serveur réduisent les opérations : configurez ServerlessConfig.MemorySizeInMB et ServerlessConfig.MaxConcurrency pour chaque variante et laissez SageMaker gérer la mise à l’échelle automatique. Pour les charges de travail avec des inférences de longue durée ou des schémas d’échange de charges utiles volumineuses, les points de terminaison asynchrones découplent le cycle de vie du client du calcul ; ils nécessitent S3 pour les entrées/sorties et sont les plus appropriés lorsque les clients peuvent interroger (poll) ou recevoir des notifications S3 pour la complétion.

Les points de terminaison multi-modèles réduisent la duplication de la mémoire et la complexité de la gestion des objets S3, mais ils ajoutent une latence de démarrage à froid par modèle et nécessitent un serveur de modèles capable de charger à la demande depuis S3 et de gérer correctement le cycle de vie (éviction/LRU). Si la latence par modèle est critique, hébergez les modèles « chauds » (hot models) sur des ProductionVariants dédiées et déchargez les modèles à faible trafic sur un MME. Les pipelines d’inférence centralisent la logique de prétraitement et de post-traitement au plus près du modèle, ce qui réduit le code côté client et garantit une transformation cohérente entre l’entraînement et l’inférence, mais ils augmentent la complexité de démarrage du point de terminaison et exigent une conception robuste du contrat de conteneur (codecs d’entrée/sortie et types de contenu).

Les tests A/B utilisant les poids des ProductionVariant sont simples pour la répartition du trafic et la collecte de métriques hors ligne, mais lorsque vous souhaitez dupliquer le trafic en mode « shadow » sans affecter les métriques de production, préférez la mise en miroir au niveau de l’application. Pour les déploiements progressifs et l’automatisation de la restauration (rollback), intégrez UpdateEndpointWeightsAndCapacities dans un workflow CodePipeline ou Step Functions qui inclut une évaluation automatique des métriques à l’aide des métriques CloudWatch, des alertes Model Monitor et une action d’approbation manuelle qui contrôle la promotion finale.

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

Une erreur opérationnelle courante consiste à supposer que Model Monitor détectera les problèmes de disponibilité des étiquettes ; Model Monitor peut détecter la dérive de distribution des caractéristiques et les violations de qualité des données à partir des requêtes capturées, mais pour mesurer la dégradation des métriques basées sur les étiquettes (F1, rappel), vous devez renvoyer les étiquettes de vérité terrain (ground-truth) vers S3 dans un format que les tâches de surveillance peuvent consommer et planifier une tâche de surveillance qui calcule la prédiction par rapport à la vérité. Un autre piège est de ne pas dimensionner correctement ServerlessConfig.MemorySizeInMB ; une mémoire sous-provisionnée provoque une limitation (throttling) ou des plantages de conteneur, tandis qu’un sur-provisionnement augmente les coûts. Pour les points de terminaison multi-modèles, négliger de définir une disposition d’objet et un cycle de vie S3 appropriés (préfixes, manifestes de modèle) ralentit les chargements à froid et complique les politiques d’éviction.

Lorsque vous traitez le déséquilibre des classes pour la détection de fraude, préférez la pondération native de l’algorithme aux pipelines d’échantillonnage lourds pour une surcharge opérationnelle minimale ; par exemple, XGBoost (conteneur SageMaker XGBoost) prend en charge l’hyperparamètre ‘scale_pos_weight’ que vous calculez comme exemples_négatifs/exemples_positifs et que vous passez via la carte des hyperparamètres dans l’appel CreateTrainingJob. Pour le contrôle manuel du déploiement, utilisez le SageMaker Model Registry : créez un ModelPackageGroup, appelez CreateModelPackage pour enregistrer un package de modèle et définissez le statut du package de modèle sur PendingManualApproval ; une action d’approbation manuelle externe de CodePipeline ou une confirmation manuelle via Step Functions + SNS peut ensuite appeler UpdateModelPackage pour définir ApprovalStatus = “Approved” avant que CreateModel ou CreateEndpoint ne soient exécutés.

Problème pratique : Scénario d’utilisation

FraudDetectCo construit un système de détection de fraude en ligne qui doit consolider les journaux de transactions dans S3 et les tables de profil client d’une base MySQL sur site (on-prem), entraîner un modèle XGBoost, le déployer avec une latence quasi temps réel, imposer une porte d’approbation manuelle pour les mises en production, et détecter à la demande à la fois les anomalies de jeu de données et la dérive du modèle.

Agrégation et pré-traitement des données : utilisez AWS Database Migration Service (DMS) ou le connecteur JDBC d’AWS Glue pour répliquer en continu les tables MySQL sur site vers S3 (parquet) ou dans un lac de données compatible avec Amazon RDS/Athena ; cataloguez avec AWS Glue et enregistrez les caractéristiques dans le magasin hors ligne (offline store) d’Amazon SageMaker Feature Store pour fournir une recherche de caractéristiques cohérente pour l’entraînement et le service en ligne. Cela centralise la lignée des caractéristiques et applique les politiques de sécurité S3 et la gouvernance Lake Formation pour l’isolement.
Entraînement et gestion du déséquilibre des classes : exécutez des tâches d’entraînement SageMaker en utilisant le conteneur intégré SageMaker XGBoost. Calculez le ratio d’étiquettes d’entraînement et définissez l’hyperparamètre XGBoost “scale_pos_weight” dans la carte HyperParameters de CreateTrainingJob pour traiter le déséquilibre des classes avec un minimum de pré-traitement. Utilisez le mode Pipe pour le canal d’entraînement (DataSource avec S3DataSource et S3DataType défini sur S3Prefix, et activez “RecordWrapperType”:“None” si vous utilisez le mode Pipe) pour réduire le temps de démarrage et la latence de téléchargement des données entre les tâches consécutives.
Registre de modèles et approbation manuelle : enregistrez les modèles entraînés dans le SageMaker Model Registry en appelant CreateModelPackage au sein d’un ModelPackageGroup. Définissez l’ApprovalStatus initial sur PendingManualApproval, intégrez un AWS CodePipeline qui inclut une action d’approbation manuelle AWS (AWS Manual Approval), et après confirmation manuelle, appelez UpdateModelPackage avec ApprovalStatus=“Approved” avant de promouvoir le ModelPackage en production via CreateModel et CreateEndpointConfig.
Déploiement et topologie d’inférence : déployez le modèle sur un point de terminaison temps réel provisionné pour une notation à faible latence. Si des centaines de modèles doivent être hébergés ultérieurement, évaluez un point de terminaison multi-modèles (Multi-Model Endpoint) et utilisez le paramètre TargetModel de InvokeEndpoint pour diriger vers des modèles spécifiques stockés dans S3. Configurez DataCaptureConfig (EnableCapture=true, InitialSamplingPercentage=100, DestinationS3Uri=s3://<bucket>/captures, CaptureOptions=[‘REQUEST’,‘RESPONSE’]) pour collecter les charges utiles des requêtes/réponses pour une analyse à la demande.
Surveillance et détection d’anomalies : planifiez des lignes de base (baselines) SageMaker Model Monitor avec CreateMonitoringSchedule pour la qualité des données et la dérive des caractéristiques. Pour la détection d’anomalies et la visualisation au niveau du jeu de données, alimentez les données S3 capturées dans Amazon Lookout for Metrics pour détecter automatiquement les anomalies et dans Amazon QuickSight pour les tableaux de bord. Pour l’évaluation à la demande des biais et de la dérive, exécutez des tâches de traitement SageMaker Clarify sur les données capturées ou lancez une tâche de traitement ad hoc Model Monitor (via CreateProcessingJob) qui applique les contraintes de la ligne de base stockée et produit le rapport de comparaison.

Justification : cette approche centralise les caractéristiques pour un entraînement reproductible et un service à faible latence, utilise le paramètre scale_pos_weight de XGBoost pour le déséquilibre des classes avec une complexité de pipeline minimale, impose une approbation manuelle dans le Model Registry intégré à CodePipeline, réduit la latence de démarrage de l’entraînement en utilisant le mode Pipe pour le streaming des données d’entraînement, et fournit à la fois une détection d’anomalies automatisée (Lookout for Metrics) et des vérifications à la demande de l’équité/dérive (Clarify + Model Monitor) en utilisant les données d’inférence capturées.

← Évaluation et sélection de modèles · Tous les domaines · MLOps et gestion du cycle de vie des modèles →

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