Déployez des endpoints d'inférence SageMaker AI avec une capacité GPU définie via les plans d'entraînement

L'auto-surveillance de l'inférence pour les endpoints Amazon SageMaker AI avec Amazon Quick

AWS a publié une nouvelle architecture de référence pour la surveillance des modèles de machine learning en production, baptisée "méta-surveillance de l'inférence", conçue pour les endpoints Amazon SageMaker AI et pilotée via Amazon Quick. Le projet est disponible en open source sur GitHub, dans le dépôt sample-mlops-bestpractices, version v2.0.0, et s'installe via un modèle CloudFormation qui crée automatiquement le VPC, les sous-réseaux, un domaine SageMaker AI, un profil utilisateur et un espace JupyterLab. L'architecture combine des services managés AWS, Amazon SageMaker AI, Amazon Athena, AWS Lambda, Amazon EventBridge et Amazon Quick, avec des outils open source comme MLflow, via les SageMaker AI MLflow Apps, et Evidently AI pour la détection de dérive des données. Le système s'appuie sur cinq tables Iceberg dans Athena formant un data lake central. L'une, trainingdata, contient les 80% de données utilisées pour entraîner le modèle. L'autre, evaluationdata, conserve les 20% restants comme référence gelée servant à mesurer la dérive de chaque modèle enregistré, et non l'ensemble d'entraînement lui même. Les deux tables sont alimentées à partir du même fichier CSV de prédictions via une étape unique appliquant un découpage déterministe par hachage des transactions. Le pipeline d'entraînement, documenté dans le notebook 1trainingpipeline.ipynb, télécharge un jeu de données de détection de fraude bancaire depuis Kaggle et trace les expériences via MLflow. Cette solution répond à un angle mort classique du machine learning en production : sans mécanisme de suivi continu, les entreprises ne découvrent la dégradation de leurs modèles que lorsque les clients se plaignent ou lors de vérifications ponctuelles, ce qui abîme la confiance. Concrètement, les équipes anti-fraude voient les faux positifs grimper, les analystes de crédit laissent passer des dossiers qui auraient dû être signalés, et les planificateurs se retrouvent avec des stocks excédentaires à cause de prévisions de demande faussées. En superposant une couche de gouvernance au dessus des pipelines d'inférence, avec détection de dérive, intégration de données de vérité terrain différées et tableaux de bord automatisés, les équipes ML peuvent repérer un problème de qualité dès son apparition plutôt que des semaines plus tard, et agir avant que l'impact commercial ne devienne visible pour les clients. Cette initiative illustre un défi plus large de l'industrie : entraîner un modèle prédictif fiable, pour la détection de fraude, le scoring de crédit ou la prévision de la demande, mobilise souvent des mois de travail, mais rien ne garantit que ses performances restent stables une fois déployé. AWS propose ici un gabarit reproductible mêlant outils managés et open source, que les équipes peuvent adapter à leur propre domaine SageMaker en modifiant simplement un fichier de configuration .env, avant d'exécuter les notebooks fournis dans l'ordre pour reproduire l'ensemble du pipeline entraînement, inférence, surveillance.

« Lancement d'une interface pour les recommandations d'inférence en IA générative sur Amazon SageMaker AI »

Amazon vient d'ajouter une interface graphique dans Amazon SageMaker AI Studio pour ses recommandations d'inférence dédiées à l'intelligence artificielle générative, un outil sans code qui s'appuie sur une API lancée en avril 2026. Cette fonctionnalité, accessible depuis le menu Jobs puis Inference optimization, guide les équipes à travers un parcours complet : configuration de la charge de travail, optimisation, sélection du modèle et déploiement. Quatre profils prédéfinis couvrent les cas d'usage courants : Interact pour les échanges de type conversationnel avec des entrées courtes, Generate pour la génération de contenu long, Summarize pour le résumé de documents avec un fort ratio entrée/sortie, et un profil Custom pour importer son propre jeu de données. Les utilisateurs choisissent aussi un objectif d'optimisation parmi trois options : minimiser la latence pour les applications interactives, maximiser le débit de tokens par seconde pour les traitements par lots, ou minimiser le coût pour les charges de production à grande échelle. Les modèles peuvent provenir du catalogue SageMaker JumpStart, d'un fichier stocké sur Amazon S3, d'un registre de modèles existant ou d'un déploiement antérieur. Cette évolution s'attaque à un problème concret pour les équipes qui mettent des modèles génératifs en production : trouver la bonne combinaison entre type d'instance, conteneur de service et stratégie d'optimisation exigeait jusqu'ici un long cycle d'essais et de benchmarks manuels, souvent réservé à des ingénieurs spécialisés en infrastructure. Avec cette interface, ce processus se réduit à quelques minutes pour les charges de travail courantes et à quelques heures pour les configurations sur mesure. Les ingénieurs en machine learning peuvent désormais valider un déploiement sans écrire une ligne de code, tandis que les responsables techniques disposent d'une vue comparative directe des compromis entre coût et performance, ce qui accélère la prise de décision côté produit comme côté infrastructure. L'API sous-jacente, lancée quelques mois plus tôt, offrait déjà un accès programmatique à ces recommandations, mais elle supposait que l'utilisateur sache quels paramètres régler et comment interpréter des résultats de benchmark bruts. L'interface graphique supprime cette barrière technique en s'appuyant sur des profils d'usage préconfigurés et des comparaisons visuelles des résultats, ouvrant l'accès à des équipes moins expertes en infrastructure cloud. Les utilisateurs avancés conservent la possibilité de passer par l'API pour des réglages fins. Ce choix s'inscrit dans une tendance plus large chez les fournisseurs de cloud à simplifier le déploiement de modèles d'IA générative, à mesure que la demande d'infrastructures optimisées en coût et en performance s'intensifie face à la multiplication des modèles disponibles.

💬 Reste à voir qui va vraiment configurer ces quatre profils correctement, parce qu'un mauvais choix entre Interact et Generate te fait payer le prix fort sans t'en rendre compte. Sur le papier c'est malin : AWS transforme un benchmark qui demandait un ingénieur infra en un menu déroulant de trois minutes. Mais l'histoire se répète, chaque cloud simplifie sa couche d'inférence dès que la concurrence sur les coûts devient trop visible, et Amazon arrive après Azure et GCP sur ce terrain-là.

Créer des agents Strands avec les modèles SageMaker AI et MLflow

Amazon Web Services a publié un guide technique détaillant la construction d'agents d'intelligence artificielle en combinant trois de ses outils : le SDK open source Strands Agents, les endpoints de modèles Amazon SageMaker AI, et la plateforme d'observabilité MLflow hébergée sur SageMaker Serverless. Le SDK Strands, à approche pilotée par le modèle, permet de créer un agent fonctionnel en quelques lignes de code en associant un modèle de langage, un prompt système et un ensemble d'outils. Les modèles sont déployés via SageMaker JumpStart, un hub machine learning qui permet d'évaluer et de sélectionner rapidement des modèles de fondation selon des critères de qualité et de responsabilité prédéfinis. L'intégration de MLflow permet ensuite de tracer les appels d'agents, de versionner les modèles et d'implémenter des tests A/B entre plusieurs variantes de modèles pour en évaluer les performances à l'aide de métriques objectives. Cette architecture répond à un besoin concret des grandes entreprises qui ne peuvent pas se contenter des services de modèles entièrement gérés : contrôle précis sur les instances de calcul, politiques de mise à l'échelle, configuration réseau compatible avec les architectures de sécurité existantes, et conformité en matière de résidence des données. Là où Amazon Bedrock simplifie l'accès aux modèles de fondation en masquant l'infrastructure, SageMaker AI laisse à l'organisation la maîtrise de l'endroit et de la manière dont l'inférence se produit, ce qui est décisif pour les secteurs réglementés comme la finance ou la santé. La couche MLflow ajoute une dimension industrielle : les équipes peuvent comparer les performances de différents modèles dans des conditions réelles, réduire les coûts en sélectionnant le modèle le plus efficace pour chaque tâche, et maintenir un historique d'expériences exploitable dans le temps. La publication de ce guide s'inscrit dans une course plus large pour capter les déploiements d'agents IA en production. AWS répond ainsi à la demande croissante des équipes MLOps qui veulent bénéficier de la commodité du cloud tout en conservant une maîtrise fine de l'infrastructure, une position souvent impossible avec les APIs gérées de type Bedrock ou OpenAI. Strands Agents, rendu open source par Amazon, concurrence directement des frameworks comme LangChain ou CrewAI, avec l'avantage d'une intégration native dans l'écosystème AWS. L'accent mis sur les tests A/B et l'évaluation continue des agents signale que le secteur entre dans une phase de maturité : il ne s'agit plus seulement de faire fonctionner un agent, mais de le mesurer, le comparer, et l'améliorer de façon systématique en production.

Métriques enrichies pour les endpoints Amazon SageMaker AI : une visibilité approfondie pour de meilleures performances

Amazon SageMaker AI enrichit ses capacités de monitoring avec le lancement de métriques améliorées pour ses endpoints de déploiement de modèles. Cette mise à jour majeure apporte une visibilité granulaire jusqu'au niveau des conteneurs individuels et des instances EC2, permettant aux équipes d'ingénierie d'identifier précisément les goulots d'étranglement en production avant qu'ils n'affectent les utilisateurs finaux. Jusqu'ici, les métriques CloudWatch proposées par SageMaker n'offraient qu'une vue agrégée sur l'ensemble des instances et conteneurs d'un endpoint. Cette approche masquait les problèmes individuels : une instance défaillante, un conteneur saturé ou une distribution inégale du trafic restaient invisibles dans les moyennes globales. La nouvelle fonctionnalité comble ce manque critique pour les équipes MLOps qui exploitent des modèles en production à grande échelle. Les métriques enrichies se déclinent en deux catégories principales. Les métriques de ressources EC2 couvrent l'utilisation CPU, GPU et mémoire, disponibles pour chaque instance de tout endpoint SageMaker, y compris l'utilisation par accélérateur individuel sur les instances GPU. Les métriques d'invocation permettent de tracer requêtes, erreurs 4XX/5XX, latence modèle et latence overhead jusqu'au niveau instance. Pour les utilisateurs d'Inference Components, qui hébergent plusieurs modèles sur un même endpoint, une couche supplémentaire expose ces mêmes métriques au niveau conteneur, identifiées par InferenceComponentName et ContainerId, publiées dans les namespaces CloudWatch /aws/sagemaker/Endpoints, /aws/sagemaker/InferenceComponents et AWS/SageMaker. Au-delà du diagnostic, cette granularité ouvre une capacité nouvelle : calculer le coût réel par modèle dans un environnement multi-tenant. En traçant l'allocation GPU au niveau de chaque Inference Component, les équipes peuvent désormais imputer précisément les coûts d'infrastructure à chaque modèle déployé, un argument fort pour les organisations qui cherchent à optimiser leurs dépenses cloud en IA.