Amazon MLS-C01: Déploiement, inférence et mise en service (Implémentation et opérations ML) — Guide d'étude

By Laurynas Brazys · 26 July 2026 · #amazon #mls-c01 #certification #exam-prep #study-guide

Fait partie du AWS Machine Learning Specialty MLS-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.

Modèles de déploiement et options de service (serving)

Les choix de service de modèles (model serving) équilibrent la latence, le coût, le débit et la complexité opérationnelle. Les points de terminaison (endpoints) SageMaker en temps réel (provisionnés ou sans serveur) offrent des latences inférieures à 100 ms jusqu’à la seconde, adaptées aux API interactives ; choisissez des familles d’instances telles que ml.c5/m5 pour les modèles CPU, ml.g4dn ou ml.p3 pour les modèles GPU, ou ml.inf1 pour l’inférence Inferentia à faible coût et à haut débit. L’inférence asynchrone et Batch Transform conviennent aux cas d’utilisation avec de grands lots (large-batch) ou à latence variable : Batch Transform est idéal pour les tâches hors ligne volumineuses (divisez les gros objets S3 en fragments (shards) et utilisez des instances ml.m5/c5 ou GPU selon les besoins), tandis que SageMaker Asynchronous Inference prend en charge des charges utiles (payloads) plus importantes avec une mise en file d’attente pour des lots quasi temps réel. Les points de terminaison multi-modèles (multi-model endpoints) hébergent de nombreux modèles derrière un seul conteneur, réduisant la surcharge de stockage en chargeant les modèles à la demande ; ils fonctionnent mieux lorsque les modèles sont petits, ont des coûts de démarrage à froid (cold-start) modestes et que les schémas d’accès sont sporadiques. Choisissez SageMaker Serverless Inference pour les charges de travail imprévisibles à faible débit afin d’éviter la gestion d’instances ; méfiez-vous des démarrages à froid (cold starts) et de la durée d’exécution limitée. Les critères de décision clés incluent les SLO de latence, le coût par invocation, le schéma de simultanéité (concurrency), la taille du modèle et la tolérance au démarrage à froid. Un piège courant consiste à utiliser des points de terminaison en temps réel pour des charges de travail par lots à très haut volume — c’est coûteux ; utilisez plutôt Batch Transform, Async Inference, ou invoquez les points de terminaison par lots avec des workers simultanés.

Mise à l’échelle, modelage du trafic et optimisation des coûts

La mise à l’échelle automatique (autoscaling), la répartition du trafic (traffic shifting) et le contrôle des coûts doivent être conçus conjointement avec la topologie de déploiement. Utilisez Application Auto Scaling pour mettre à l’échelle les variantes de points de terminaison SageMaker avec des politiques de suivi de cible (target-tracking) basées sur des métriques d’invocation ou des métriques CloudWatch personnalisées ; définissez des capacités min/max et des délais de récupération (cooldowns) raisonnables pour éviter l’instabilité (thrashing). Pour les déploiements bleu/vert (blue/green) et les déploiements progressifs (canary rollouts), utilisez des points de terminaison à variantes multiples ou des mises à jour de EndpointConfig avec des pourcentages de répartition du trafic et des augmentations progressives ; intégrez avec AWS CodeDeploy pour automatiser la répartition du trafic. Les optimisations de coûts incluent l’élagage de modèle (pruning), la quantification (FP16 ou int8), la compilation avec SageMaker Neo ou AWS Neuron pour Inf1, et le déplacement des charges de travail non sensibles à la latence vers Batch Transform ou l’inférence sans serveur. Les instances Spot réduisent les coûts d’entraînement mais ne sont pas applicables aux points de terminaison en temps réel ; à la place, dimensionnez correctement les types d’instances (cpu vs gpu vs inferentia) et consolidez les modèles avec des points de terminaison multi-modèles lorsque cela est approprié. Méfiez-vous des pièges comme le sur-provisionnement lors de l’utilisation du suivi de cible sans comprendre le débit par instance, ou le fait de supposer que les points de terminaison multi-modèles éliminent les limites de mémoire — le chargement du modèle nécessite toujours de la mémoire et peut augmenter la latence. Compressez également les artefacts de modèle (ONNX, TF SavedModel avec gz) et utilisez des stratégies de chargement paresseux (lazy-loading) pour réduire le stockage et les temps de démarrage à froid.

Edge, inférence à faible latence et placement du pré/post-traitement

Pour les environnements à très faible latence ou déconnectés, déployez des modèles sur AWS IoT Greengrass (v2) ou utilisez SageMaker Edge Manager pour empaqueter et surveiller les modèles sur des appareils en périphérie (edge devices) ; compilez avec SageMaker Neo ou des composants AWS IoT Greengrass et utilisez la quantification pour respecter les contraintes de mémoire/CPU. Placez le pré-traitement et l’extraction de caractéristiques (feature extraction) là où cela minimise la latence de bout en bout et le coût : des filtres simples peuvent s’exécuter dans le firmware de l’appareil ou une Lambda Greengrass, le traitement par lots (batching) et les transformations lourdes ont leur place sur une passerelle en périphérie (edge gateway) ou dans le cloud. Pour les fenêtres d’événements en streaming (par ex., des fenêtres glissantes de 10 minutes), ingérez avec Amazon Kinesis Data Streams ou Amazon MSK, utilisez Kinesis Data Analytics ou Flink/Apache Spark pour le fenêtrage et l’agrégation, et transférez les caractéristiques résumées à un point de terminaison SageMaker ou à un modèle léger en périphérie (on-edge) — cela réduit la sortie réseau (egress) et la fréquence d’invocation du modèle. Méfiez-vous des pièges tels que l’ignorance de la gestion des versions de modèles (versioning) sur les appareils en périphérie, ou l’échec du provisionnement d’un stockage suffisant sur l’appareil pour les artefacts de modèle. Pour les microservices côté serveur, colocalisez le pré-traitement (API Gateway + Lambda ou ALB + Fargate) pour éviter la surcharge des appels à froid (cold-call) et réduire la taille des charges utiles (payloads) envoyées au modèle.

Surveillance, audit, gouvernance et traitement des données

Le ML opérationnel nécessite une surveillance continue de la santé des modèles et une gouvernance des données. Utilisez SageMaker Model Monitor pour établir une base de référence (baseline) des données d’entraînement avec un DataQualityJob et configurez une surveillance continue pour détecter la dérive des données (data drift), les régressions de qualité du modèle, les valeurs manquantes et les contraintes personnalisées ; activez DataCaptureConfig sur les points de terminaison (endpoints) pour capturer les entrées/sorties vers S3 et déclencher des tâches Model Monitor. Pour le lignage (lineage) et l’audit au niveau des caractéristiques (features), utilisez Amazon SageMaker Feature Store (magasins en ligne et hors ligne) combiné avec AWS Glue Data Catalog et CloudTrail pour suivre l’accès aux jeux de données et leurs transformations ; Amazon Macie et les tâches de traitement Glue/SageMaker Processing peuvent découvrir et expurger les PII (informations d’identification personnelle) avant l’entraînement. Les pièges du chiffrement incluent SSE-KMS : lorsque les objets S3 sont chiffrés avec une clé gérée par le client (CMK), assurez-vous que le rôle d’exécution de SageMaker dispose des autorisations kms:Decrypt et kms:GenerateDataKey et que la politique de la CMK accorde l’accès ; assurez-vous également que les politiques de compartiment (bucket policies) S3 et les points de terminaison de VPC (VPC endpoints) ne bloquent pas l’accès. Pour les objets S3 volumineux quotidiens (par ex., 100 Go), évitez l’ingestion en un seul fichier : partitionnez-les en de nombreux objets plus petits, stockez-les au format Parquet et compressez-les, et utilisez Athena/Glue pour la détection de schéma. Les pièges courants incluent des planifications de surveillance insuffisantes, le fait de ne pas générer une base de référence appropriée pour Model Monitor, et l’oubli d’accorder l’accès KMS à tous les principaux de service (SageMaker, Glue, Lambda) qui ont besoin du déchiffrement.

Problème pratique : Scénario d’utilisation

Scénario : Streamlytic Media exploite une plateforme d’analyse de podcasts sur AWS. Ils utilisent Kinesis Data Streams pour ingérer les événements des utilisateurs, stockent les caractéristiques agrégées dans S3 et hébergent des modèles dans SageMaker pour la prédiction d’engagement en temps réel. Les données contiennent occasionnellement des PII et sont chiffrées avec une clé gérée par le client SSE-KMS.

Défi : Fournir des prédictions à faible latence sur une fenêtre glissante d’événements de 10 minutes, expurger les PII avant l’entraînement du modèle, s’assurer que SageMaker peut lire les données S3 chiffrées et mettre en œuvre une surveillance continue de la dérive des caractéristiques (feature drift).

Approche recommandée :

Créer un Kinesis Data Stream pour ingérer les événements, exécuter Kinesis Data Analytics (Flink) pour maintenir des fenêtres glissantes de 10 minutes et émettre les caractéristiques agrégées vers S3 au format Parquet avec des partitions horaires.
Détecter et expurger les PII en utilisant Amazon Macie pour la découverte et une tâche SageMaker Processing (ou une tâche AWS Glue) pour appliquer une expurgation/tokenisation déterministe ; stocker les résultats dans un magasin hors ligne (offline store) de Feature Store pour l’entraînement.
Accorder au rôle d’exécution de SageMaker les autorisations kms:Decrypt et kms:GenerateDataKey sur la CMK, ajouter le rôle à la politique de clé de la CMK, et s’assurer que la politique de compartiment S3 ou le point de terminaison de VPC autorise l’accès pour SageMaker.
Déployer le modèle en tant que point de terminaison en temps réel SageMaker sur des instances ml.inf1, activer DataCaptureConfig, créer une base de référence (baseline) Model Monitor à partir des données d’entraînement, et configurer une surveillance continue avec des alertes vers CloudWatch.

Justification : L’agrégation en streaming avec Kinesis + Flink minimise le volume d’événements et la latence ; l’expurgation au moment du traitement préserve la confidentialité et la conformité ; des autorisations KMS explicites préviennent les échecs d’accès ; les points de terminaison basés sur Inferentia et Model Monitor équilibrent un faible coût d’inférence avec une observabilité opérationnelle.

← Entraînement · Tous les domaines · Sécurité →

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