Amazon SageMaker AI : l'inférence asynchrone supporte désormais les payloads intégrés

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 un portail personnalisé avec les applications MLflow d'Amazon SageMaker AI intégrées

Amazon Web Services propose une approche architecturale permettant aux équipes de machine learning d'intégrer Amazon SageMaker AI MLflow Apps directement dans un portail interne sur mesure, sans distribuer d'URLs présignées ni accorder d'accès individuels à la console AWS. La solution repose sur quatre composants déployés via AWS Cloud Development Kit (CDK) : un Application Load Balancer (ALB) comme point d'entrée unique, une application React embarquant l'interface MLflow dans un iframe, un reverse proxy Flask tournant sur Amazon EC2, et le service managé SageMaker AI MLflow Apps en backend. L'authentification AWS Signature Version 4 (SigV4) est gérée de façon transparente par le proxy Flask, qui intercepte chaque requête, la signe avec des identifiants temporaires obtenus via un rôle IAM dédié, puis la transmet à l'endpoint MLflow. Le résultat est une URL unique et permanente donnant accès à l'intégralité de l'interface MLflow, y compris le suivi des expériences, les métriques, les paramètres et les artefacts. Pour les équipes data comptant plusieurs dizaines de data scientists, ce modèle résout un problème opérationnel concret : l'impossibilité de distribuer des URLs présignées à grande échelle, et la charge administrative que représente la gestion des accès individuels à la console AWS. En intégrant MLflow au même portail SSO que les autres outils internes, les data scientists n'ont plus besoin de s'authentifier séparément ni de gérer des identifiants AWS. Les pipelines CI/CD et les scripts d'automatisation peuvent également interagir avec l'API REST MLflow via ce même endpoint proxy, sans modification côté client. Pour les responsables infrastructure, cela signifie moins de tickets d'accès, un onboarding simplifié et une surface d'attaque réduite, l'accès direct au service AWS restant invisible pour l'utilisateur final. MLflow s'est imposé comme standard de facto pour le suivi des expériences de machine learning, mais son intégration dans des environnements d'entreprise avec SSO et portails internes reste un point de friction fréquent. AWS, qui a intégré MLflow nativement dans SageMaker il y a moins d'un an, cherche à faciliter son adoption en entreprise en éliminant les barrières opérationnelles. Cette architecture de proxy inverse n'est pas nouvelle, elle s'applique à de nombreux services AWS accessibles via navigateur, mais sa documentation officielle pour MLflow marque une étape vers un usage plus industrialisé. La solution reste cependant incomplète en production : l'implémentation présentée utilise HTTP sans chiffrement, et AWS recommande explicitement d'ajouter HTTPS via AWS Certificate Manager avant tout déploiement réel. L'intégration SSO effective, mentionnée comme cas d'usage principal, n'est pas non plus couverte dans le guide, laissant aux équipes le soin d'assembler cette couche supplémentaire.

L'inférence désagrégée sur AWS propulsée par llm-d est désormais disponible

AWS et la communauté open source llm-d annoncent la disponibilité de l'inférence désagrégée sur AWS, une avancée majeure pour le déploiement à grande échelle des modèles de langage. Cette collaboration, menée avec l'appui de Red Hat, aboutit à la mise à disposition d'un conteneur dédié, ghcr.io/llm-d/llm-d-aws, intégrant les bibliothèques spécifiques à l'infrastructure AWS, notamment l'Elastic Fabric Adapter (EFA) et libfabric. À mesure que l'IA passe de la phase de prototypage à un déploiement industriel, l'inférence devient le goulot d'étranglement central. Les modèles raisonnants et agentiques génèrent désormais 10 fois plus de tokens que les systèmes à réponse directe, créant une charge variable et exponentielle qui dégrade les performances. L'inférence désagrégée répond à ce défi en séparant physiquement les deux phases du processus : la phase prefill (fortement liée au calcul) et la phase decode (fortement liée à la mémoire), permettant d'allouer des ressources GPU adaptées à chacune. llm-d est un framework Kubernetes-natif construit au-dessus de vLLM, enrichi d'orchestration de niveau production, de planification avancée des requêtes et de support pour les interconnexions haute performance. La nouvelle intégration avec la bibliothèque NIXL permet notamment l'inférence multi-nœuds désagrégée et le parallélisme d'experts. Le tout est disponible sur Amazon SageMaker HyperPod et Amazon Elastic Kubernetes Service (EKS), après plusieurs mois de benchmarks itératifs pour garantir une version stable prête à l'emploi. Cette initiative s'inscrit dans une tendance de fond : l'optimisation de l'inférence LLM devient un enjeu compétitif aussi important que l'entraînement des modèles eux-mêmes. En proposant des architectures de référence packagées, les well-lit paths, llm-d et AWS cherchent à démocratiser l'accès à ces optimisations avancées, jusqu'ici réservées aux équipes disposant d'une expertise infrastructure poussée.