InfrastructureAWS ML Blog · 10 juin 2026, 18:26· 2 min de lecture

Fini le réglage manuel des kernels : Neuron Agentic Development accélère les optimisations AWS Trainium

Amazon Web Services vient d'annoncer les capacités "Neuron Agentic Development", un ensemble d'agents IA et de compétences spécialisées conçues pour accélérer le développement de kernels sur ses puces Trainium et Inferentia. Ces outils permettent aux agents de développement comme Kiro et Claude d'écrire, déboguer et profiler automatiquement des kernels NKI (Neuron Kernel Interface), la couche logicielle bas niveau qui détermine l'efficacité réelle du matériel. Le package comprend cinq compétences distinctes suivant le pipeline naturel de développement : écriture, débogage, profilage et analyse. Concrètement, la compétence d'écriture traduit du code PyTorch, NumPy ou une simple description en langage naturel en kernels NKI corrects, en respectant les contraintes matérielles spécifiques comme les dimensions de partition de 128 éléments. La compétence de débogage couvre 28 codes d'erreur du compilateur Neuron, tandis que les outils de profilage génèrent des traces exploitables via neuron-explorer avec un détail au niveau des opérations DMA. Ces capacités s'intègrent directement dans des environnements comme VS Code, Cursor ou Kiro, et nécessitent une instance Amazon EC2 basée sur Trainium.

L'enjeu est considérable : l'écart entre les performances théoriques d'un accélérateur IA et ce qu'une équipe obtient réellement en pratique reste souvent énorme, faute de développeurs capables d'écrire des kernels matériels optimisés. Jusqu'ici, cette expertise demandait des années d'expérience au niveau de l'architecture des puces, rendant l'optimisation de bas niveau inaccessible à la majorité des équipes de machine learning. En automatisant cette couche via des agents IA, AWS permet à n'importe quel ingénieur ML de produire du code hardware-aware sans formation spécialisée, réduisant potentiellement le temps d'implémentation de plusieurs mois à quelques jours. Pour les équipes qui déploient des modèles à grande échelle, des gains même marginaux sur l'efficacité des kernels se traduisent directement en coûts d'inférence réduits et en meilleures latences pour les utilisateurs finaux.

Cette annonce s'inscrit dans la stratégie d'AWS de différencier ses puces maison face à Nvidia, dont les GPU H100 et H200 restent la référence dans l'industrie. Trainium et Inferentia existent depuis plusieurs années mais peinent à convaincre des équipes habituées à l'écosystème CUDA, bien établi et documenté. En abaissant la barrière d'entrée via l'automatisation agentique, Amazon cherche à élargir la base de développeurs prêts à migrer ou à tester ses accélérateurs. La question de la généralisation reste entière : ces capacités agentiques pourraient préfigurer une tendance plus large où chaque fabricant de silicium embarque son propre assistant IA pour faciliter l'adoption, transformant la guerre des puces en une guerre des outils de développement.

Dans nos dossiers

Agents IA AWS CUDA NVIDIA

Cet article vous a été utile ?

Vu une erreur factuelle dans cet article ? Signalez-la. Toutes les corrections valides sont publiées sur /corrections.

À lire aussi

1AWS ML Blog

La mise en cache des conteneurs dans Amazon SageMaker AI accélère le déploiement des modèles

Amazon Web Services vient d'annoncer une nouvelle fonctionnalité pour SageMaker AI : le cache des images de conteneurs lors des événements de mise à l'échelle. Concrètement, cette optimisation réduit jusqu'à 51 % la latence de démarrage lors du lancement de nouvelles instances, et jusqu'à 2x pour les modèles d'IA générative en conditions réelles. Pour illustrer le gain : avec le modèle Qwen3-8B (16 Go) sur une instance ml.g6.2xlarge et le conteneur LMI de SageMaker (17,7 Go compressé), la latence de démarrage passe de 525 secondes à 258 secondes. Avant le cache, le téléchargement de l'image depuis Amazon ECR prenait à lui seul 333 secondes, en parallèle du téléchargement des poids du modèle depuis S3 (168 secondes). Avec le cache, l'image est déjà disponible localement (0 seconde), et le téléchargement du modèle tombe à 77 secondes, la compétition pour la bande passante réseau étant éliminée. L'enjeu est considérable pour les équipes qui déploient des modèles de langage en production. Lors d'un pic de trafic, chaque seconde de latence au démarrage d'une nouvelle instance se traduit directement en requêtes non servies ou en surcoût d'instances pré-chauffées. Les workloads d'IA générative sont particulièrement touchés car ils utilisent des conteneurs très volumineux, LMI (basé sur vLLM), vLLM natif, NVIDIA Triton, qui pouvaient représenter la majeure partie du temps d'initialisation. La fonctionnalité s'applique aux deux architectures d'endpoints SageMaker : les endpoints à modèle unique (où chaque nouvelle instance héberge sa propre copie du modèle) et les endpoints à composants d'inférence (où de nouvelles instances sont lancées uniquement quand aucune instance existante n'a la capacité suffisante). Si le cache est indisponible, SageMaker revient automatiquement au téléchargement depuis ECR, sans interruption de service. Cette annonce s'inscrit dans une stratégie progressive d'AWS pour réduire la latence de mise à l'échelle sur SageMaker. La plateforme avait déjà introduit des métriques CloudWatch sub-minute permettant de détecter les besoins de scale-out jusqu'à 6 fois plus vite, ainsi qu'un cache de données par instance pour les composants d'inférence réutilisant des instances déjà en cours d'exécution. Mais ces solutions précédentes ne couvraient pas le cas où une toute nouvelle instance devait être lancée, le scénario le plus coûteux. Le cache de conteneurs comble précisément ce manque. Dans un contexte où la concurrence entre AWS, Google Cloud et Azure s'intensifie sur les performances d'inférence, cette optimisation renforce la position de SageMaker pour les déploiements LLM à grande échelle, notamment dans les entreprises qui font face à des pics de charge imprévisibles.

UELes entreprises françaises et européennes déployant des LLMs sur Amazon SageMaker bénéficieront directement de cette réduction de latence au scale-out, sans configuration supplémentaire.

InfrastructureActu

1 source

2Meta Engineering ML

Meta lance KernelEvolve, un agent IA pour optimiser les infrastructures d'entraînement

Meta a présenté KernelEvolve, un système d'optimisation de kernels piloté par intelligence artificielle, développé en interne pour accélérer ses modèles de publicité et d'IA générative. Intégré à l'agent Ranking Engineer Agent, KernelEvolve automatise la création et l'optimisation de kernels — ces programmes bas niveau qui traduisent les opérations de haut niveau d'un modèle en instructions spécifiques à chaque puce. Le système cible une infrastructure hétérogène composée de GPU NVIDIA, de GPU AMD, de CPU classiques et des puces MTIA, les accélérateurs personnalisés de Meta. Les résultats publiés sont substantiels : plus de 60 % d'amélioration du débit d'inférence pour le modèle publicitaire Andromeda sur GPU NVIDIA, et plus de 25 % de gain en débit d'entraînement sur les puces MTIA. Des travaux qui auraient normalement demandé plusieurs semaines à des ingénieurs spécialisés ont été accomplis en quelques heures. L'article associé sera présenté au 53e International Symposium on Computer Architecture (ISCA) 2026. L'enjeu est direct et massif : Meta sert chaque jour des milliards d'expériences alimentées par l'IA, des recommandations personnalisées aux assistants génératifs. Chaque requête d'entraînement ou d'inférence repose sur une couche de kernels hautement optimisés, et à mesure que les modèles gagnent en complexité et que le parc matériel se diversifie, le nombre de configurations possibles explose — atteignant des milliers de combinaisons selon le hardware, l'architecture du modèle et le type d'opérateur. L'optimisation manuelle par des experts ne peut plus suivre ce rythme, créant un goulot d'étranglement critique qui freine l'adoption de nouveaux matériels et ralentit les cycles d'itération des modèles. KernelEvolve résout ce problème en traitant l'optimisation comme une recherche automatisée : un environnement d'évaluation dédié teste chaque kernel candidat, renvoie les diagnostics au LLM, et pilote une exploration continue sur des centaines d'alternatives — dépassant les performances des kernels écrits à la main par des experts humains. Cette initiative s'inscrit dans une tendance de fond chez les grandes plateformes technologiques : déléguer des tâches d'ingénierie de bas niveau à des agents IA pour absorber la complexité croissante des infrastructures de calcul. Meta fait face à la même contrainte que Google, Microsoft ou Amazon — accélérer sans cesse les modèles tout en maîtrisant les coûts de calcul sur un parc matériel qui ne cesse de se diversifier. KernelEvolve génère des kernels dans des langages aussi bien de haut niveau comme Triton ou CuteDSL que de bas niveau comme CUDA, HIP ou MTIA C++, ce qui lui confère une portabilité rare. À terme, ce type d'agent pourrait devenir standard dans l'industrie, réduisant drastiquement le besoin d'ingénieurs spécialisés en optimisation matérielle et accélérant la mise en production de nouvelles architectures de modèles sur des puces encore inconnues.

InfrastructureActu

1 source

3AWS ML Blog

Comment AWS accélère l'entraînement des modèles d'IA pour les effets visuels chez Outpost VFX

Outpost VFX, studio d'effets visuels operant au Royaume-Uni, au Canada et en Inde, a multiplie par 8 la vitesse d'entrainement de ses modeles d'intelligence artificielle dedies au remplacement de visages dans les productions cinema et series, grace a une infrastructure cloud AWS. L'entreprise, cliente d'AWS depuis 2022, a collabore avec les equipes du Generative AI Innovation Center pour moderniser ses algorithmes. Auparavant, Outpost VFX entrainait ses modeles sur des stations de travail equipees de cartes graphiques RTX 3090, en alimentant les algorithmes avec de petits jeux de donnees d'acteurs et de leurs doublures. Ce processus prenait entre une et deux semaines par cycle d'affinage, et la technologie ne pouvait exploiter qu'un seul GPU a la fois, ce qui limitait l'acces a la memoire video et donc la capacite de traitement. Le studio est passe a des instances Amazon EC2 de type P5, equipees de GPU NVIDIA H100 concus pour l'entrainement distribue, et reliees par une interconnexion NV Link plus performante que la communication PCIe utilisee sur les instances de la serie G. Ce changement transforme concretement le quotidien des equipes de production. Les methodes traditionnelles de remplacement de visages, qu'il s'agisse de compositing ou de techniques specialisees de rajeunissement ou de vieillissement numerique, necessitaient plus de cinq jours pour produire une premiere version soumise a validation du realisateur. Ce delai constituait un goulot d'etranglement des les premieres etapes du processus d'approbation, une phase pourtant critique pour le respect des plannings. En accelerant l'entrainement, Outpost VFX reduit les delais de livraison aux clients, limite les couts lies aux iterations multiples et accelere les boucles de retour creatif, des enjeux cruciaux dans une industrie ou chaque jour de retard se repercute sur l'ensemble du calendrier de production. Cette evolution s'inscrit dans une demande plus large de scalabilite, de securite et de qualite. Outpost VFX avait identifie trois besoins techniques prioritaires: la possibilite de paralleliser l'entrainement sur plusieurs GPU pour sortir des limites du mono-GPU, le respect de standards de securite stricts pour traiter des donnees de production hautement sensibles dans un environnement cloud segregue, et une architecture capable de gerer des jeux de donnees plus volumineux ainsi que des images en plus haute resolution afin d'ameliorer la qualite des resultats. La solution a consiste a adapter le code existant du modele de remplacement de visages pour qu'il fonctionne en entrainement distribue sur des instances P5 dans un environnement cloud securise, aligne sur l'infrastructure deja virtualisee du studio. L'experience d'Outpost VFX illustre une tendance plus generale dans l'industrie des effets visuels, ou les studios cherchent a combiner puissance de calcul a la demande et exigences de confidentialite pour accelerer des workflows IA jusque-la freines par des contraintes materielles locales.

InfrastructureActu

1 source

4AWS ML Blog

Les applications d'IA à base d'agents sur AWS avec une stratégie moderne de maillage de données

Amazon Web Services a publié un guide architectural détaillé pour construire des applications d'IA agentique sur un maillage de données distribué, en réponse aux lacunes de gouvernance que les systèmes actuels de type RAG (Retrieval Augmented Generation) ne permettent pas de combler. L'architecture proposée repose sur trois composants clés : Amazon S3 Vectors pour les bases de connaissances vectorielles, qui réduit les coûts de stockage et de requête jusqu'à 90 % par rapport aux bases de données vectorielles spécialisées dans des charges de travail à fréquence modérée ; Amazon S3 Tables avec support natif d'Apache Iceberg, qui offre jusqu'à dix fois plus de transactions par seconde que les tables Iceberg auto-gérées, avec sécurité au niveau des lignes, colonnes et cellules individuelles via AWS Lake Formation ; et enfin, une exposition du maillage de données sous forme d'outils MCP (Model Context Protocol) via AgentCore Gateway, avec des intercepteurs Lambda pour un contrôle d'accès déterministe à chaque invocation. L'enjeu est considérable pour les entreprises qui déploient des agents IA en production. Contrairement aux pipelines RAG classiques, où l'agent se contente de récupérer des extraits d'un index vectoriel préexistant, les agents autonomes modernes découvrent dynamiquement des schémas de bases de données, construisent des requêtes SQL et synthétisent des données issues de sources multiples. Ce comportement expose des failles de gouvernance que le modèle à point de contrôle unique ne peut pas gérer : un agent de service client qui interroge simultanément des bases de commandes, des politiques de retour et des données clients peut contourner des restrictions d'accès si le contrôle n'est pas appliqué à chaque étape de la chaîne. L'architecture décrite impose des autorisations distinctes au niveau de la couche agent, de la passerelle, des outils et du maillage de données lui-même, sans point de défaillance unique. Ce travail s'inscrit dans une évolution plus large de l'écosystème AWS vers l'IA agentique d'entreprise. Un article précédent d'AWS avait déjà abordé le contrôle d'accès fin pour les applications RAG sur des lacs de données serverless. La nouvelle architecture l'étend en intégrant Amazon Bedrock AgentCore Runtime, un environnement d'hébergement serverless qui déploie les agents dans des microVM isolés avec isolation de session, et le framework LangGraph pour orchestrer les appels aux outils MCP. Les intercepteurs de requêtes valident les jetons JWT et appliquent les périmètres d'autorisation, tandis que les intercepteurs de réponses gèrent la rédaction des données sensibles et la journalisation d'audit. AWS Bedrock Guardrails surveille en temps réel les injections de prompts et les contenus dangereux à chaque invocation d'outil. Cette architecture cible directement les équipes data et les architectes cloud qui doivent mettre en production des agents IA tout en respectant des contraintes de conformité et de sécurité strictes.

UELes contrôles d'accès granulaires au niveau ligne/colonne/cellule et la journalisation d'audit intégrés facilitent la mise en conformité RGPD pour les entreprises européennes déployant des agents IA sur AWS.

InfrastructureActu

1 source

Recevez l'essentiel de l'IA chaque jour

Une sélection éditoriale quotidienne, sans bruit. Directement dans votre boîte mail.

Recevez l'essentiel de l'IA chaque jour

Gratuit · 1 email le matin, l'essentiel de l'IA · désinscription en un clic