Aller au contenu principal
InfrastructureAWS ML Blog6sem

Inférence LLM accélérée par décodage spéculatif sur AWS Trainium et vLLM

Résumé IASource uniqueImpact UE
Source originale ↗·

AWS et ses partenaires ont publié des résultats de benchmarks démontrant que le décodage spéculatif (speculative decoding) sur les puces AWS Trainium2, couplé au framework vLLM et à Kubernetes, permet d'accélérer la génération de tokens jusqu'à trois fois pour les charges de travail intensives en décodage. Les tests ont été réalisés avec les modèles Qwen3, une famille de modèles de langage développée par Alibaba. La technique repose sur l'utilisation de deux modèles en tandem : un petit modèle "brouillon" (draft model) qui propose plusieurs tokens en avance, et le modèle principal qui vérifie ces propositions en une seule passe. Résultat : une latence inter-token réduite et un coût par token généré significativement plus faible.

L'impact est particulièrement marqué pour les applications comme les assistants à l'écriture, les agents de code ou tout système génératif qui produit beaucoup plus de tokens qu'il n'en consomme en entrée. Dans ces cas, la phase de décodage représente l'essentiel du coût d'inférence. Le problème fondamental du décodage autorégressif classique est que les accélérateurs matériels restent largement sous-utilisés : chaque étape ne produit qu'un seul token, ce qui génère de petites opérations matricielles inefficaces et monopolise inutilement la bande passante mémoire du cache KV. Le décodage spéculatif transforme ce goulot d'étranglement en permettant au modèle cible de traiter n tokens simultanément lors de la vérification, amortissant ainsi les accès mémoire et densifiant les calculs.

Deux paramètres clés pilotent les performances de cette approche : le choix du modèle brouillon et la valeur de numspeculativetokens, qui détermine combien de tokens sont proposés à chaque passe. Le modèle brouillon doit partager le même tokenizer et le même vocabulaire que le modèle principal, idéalement appartenir à la même famille architecturale, pour maximiser le taux d'acceptation des tokens proposés. Un taux d'acceptation élevé est crucial : si le modèle principal rejette trop souvent les suggestions, les gains de performance s'évaporent et le coût de calcul du modèle brouillon devient une charge nette. Fixer numspeculativetokens trop bas limite les gains ; trop haut, cela multiplie les rejections anticipées. Cette publication s'inscrit dans une tendance plus large de la course à l'optimisation de l'inférence LLM, où AWS cherche à positionner ses puces Trainium comme alternative crédible aux GPU Nvidia, notamment pour les entreprises cherchant à réduire leurs coûts d'inférence à grande échelle.

Impact France/UE

Les entreprises européennes utilisant AWS pourraient réduire leurs coûts d'inférence LLM en migrant vers Trainium2, sans impact réglementaire ou institutionnel direct pour la France ou l'UE.

Dans nos dossiers

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

À lire aussi

LightSeek Foundation publie TokenSpeed, moteur d'inférence LLM open source visant TensorRT-LLM pour agents autonomes
1MarkTechPost 

LightSeek Foundation publie TokenSpeed, moteur d'inférence LLM open source visant TensorRT-LLM pour agents autonomes

La LightSeek Foundation a publié TokenSpeed, un moteur d'inférence pour grands modèles de langage distribué en open source sous licence MIT. Encore en phase de préversion, TokenSpeed est conçu spécifiquement pour les charges de travail dites "agentiques", c'est-à-dire les systèmes d'IA qui enchaînent de multiples appels au modèle pour accomplir des tâches complexes, comme l'écriture ou la révision de code. L'objectif déclaré est d'atteindre des performances comparables à TensorRT-LLM de NVIDIA, tout en restant accessible à l'ensemble de l'écosystème. Le moteur vise à maintenir un débit minimum de 70 tokens par seconde par utilisateur, un seuil qui monte parfois à 200 TPS ou plus, tout en maximisant le nombre de tokens traités par GPU et par minute. L'enjeu dépasse la performance brute. Des outils comme Claude Code d'Anthropic, Codex d'OpenAI ou Cursor fonctionnent sur des contextes qui dépassent régulièrement 50 000 tokens et s'étalent sur des dizaines de tours de conversation, un profil très différent d'un simple chatbot. Or la plupart des benchmarks publics ne rendent pas compte de cette réalité. Lorsqu'un agent de développement logiciel analyse un dépôt entier, génère du code, exécute des tests et itère, chaque milliseconde de latence ajoutée se multiplie à chaque étape. Un moteur d'inférence mal adapté devient rapidement un goulot d'étranglement qui ralentit l'ensemble de la chaîne de production logicielle, et donc, à terme, les équipes d'ingénierie qui en dépendent. L'architecture de TokenSpeed repose sur cinq sous-systèmes complémentaires. Le premier est un mécanisme de parallélisme assisté par compilateur, basé sur le modèle SPMD (Single Program, Multiple Data), qui génère automatiquement les communications entre processus sans que le développeur n'ait à les écrire manuellement. Le planificateur de requêtes sépare strictement le plan de contrôle, implémenté en C++ sous forme de machine à états finis, du plan d'exécution écrit en Python, ce qui permet de détecter les erreurs de gestion du cache KV à la compilation plutôt qu'à l'exécution. Le troisième pilier est une couche de noyaux GPU modulaire et extensible, compatible avec des accélérateurs autres que ceux de NVIDIA, s'appuyant notamment sur l'un des noyaux MLA (Multi-head Latent Attention) les plus rapides disponibles pour les GPU Blackwell. Ce noyau MLA a d'ailleurs déjà été intégré dans vLLM, l'un des moteurs d'inférence open source les plus utilisés dans l'industrie. La fondation LightSeek positionne ainsi TokenSpeed comme une infrastructure commune pour l'ère où les agents IA deviennent le principal vecteur de production de code.

UELa disponibilité d'un moteur d'inférence open source compatible avec des accélérateurs non-NVIDIA pourrait réduire la dépendance des équipes européennes aux solutions propriétaires de NVIDIA.

InfrastructureActu
1 source
2Next INpact 

☕️ Amazon envisage de vendre ses puces Trainium à des tiers

Dans sa lettre annuelle aux actionnaires publiée le 9 avril 2026, Andy Jassy, PDG d'Amazon, a ouvert la porte à une révolution discrète : vendre les puces Trainium d'Amazon à des entreprises tierces. Jusqu'ici exclusivement réservées aux infrastructures internes du groupe, notamment à AWS et à la plateforme d'IA Bedrock, ces semiconducteurs représentent selon Jassy une activité dépassant 20 milliards de dollars en 2025, avec une croissance annuelle à trois chiffres. Il va plus loin en estimant que si cette division vendait ses puces à l'extérieur comme le font d'autres acteurs du marché, son chiffre d'affaires annuel approcherait les 50 milliards de dollars. Les puces Trainium 3, annoncées fin 2025, sont déjà quasi intégralement allouées en interne, et une part significative du contingent Trainium 4 est déjà réservée, alors que la production de masse n'est attendue que dans 18 mois. L'enjeu est considérable pour l'ensemble de l'industrie des semi-conducteurs dédiés à l'intelligence artificielle. Si Amazon franchit le pas, le groupe deviendrait un concurrent direct de NVIDIA sur le segment des puces d'entraînement pour l'IA, un marché aujourd'hui dominé très largement par le fabricant de Santa Clara. Pour les entreprises clientes, cela signifierait l'apparition d'une alternative sérieuse, à la fois en termes de performance et de rapport prix/performance. Jassy cite l'exemple de ses processeurs Graviton, lancés en 2018, qui offrent jusqu'à 40 % de meilleur rapport prix/performance que les processeurs x86 et sont aujourd'hui utilisés par 98 % des 1 000 principaux clients EC2 d'Amazon. La trajectoire suggérée pour Trainium est explicitement similaire. Ce mouvement s'inscrit dans une tendance plus large où les grands acteurs du cloud développent leurs propres puces pour réduire leur dépendance à NVIDIA et améliorer leurs économies d'échelle. Google a déjà emprunté ce chemin en proposant ses TPU à des tiers du cloud comme Crusoe, CoreWeave ou Fluidstack, transformant la vente de composants en alternative au modèle classique de location de ressources. Amazon, fort de l'expérience acquise avec Graviton, dispose des capacités industrielles et de la base clients pour répliquer cette stratégie à grande échelle. Jassy prend soin de ménager NVIDIA, affirmant qu'AWS restera une plateforme de choix pour les solutions du fabricant, tout en signalant clairement que les clients cherchent mieux ailleurs et qu'Amazon est prêt à répondre à cette demande. La question n'est plus de savoir si Amazon entrera sur le marché des puces tierces, mais quand.

UEUne alternative sérieuse à NVIDIA pour les puces d'entraînement IA pourrait réduire les coûts d'infrastructure pour les entreprises et laboratoires européens, aujourd'hui dépendants d'un marché dominé par un seul fournisseur.

💬 20 milliards déjà en interne, et Jassy commence à regarder par-dessus la clôture, ça dit quelque chose. Graviton a mis 6 ans pour convaincre 98 % des gros clients EC2, donc Trainium en vente libre c'est pas pour demain matin, mais la direction est posée. Ce qui m'intéresse vraiment c'est si le rapport prix/perf tient hors de l'écosystème AWS, parce que sur du hardware vendu à nu, les comparatifs NVIDIA vont être brutaux.

InfrastructureOpinion
1 source
3AWS ML Blog 

Bonnes pratiques pour l'inférence sur Amazon SageMaker HyperPod

Amazon a enrichi sa plateforme SageMaker HyperPod d'un ensemble de fonctionnalités dédiées à l'inférence de modèles d'IA générative, avec pour promesse affichée une réduction du coût total de possession allant jusqu'à 40%. La solution s'appuie sur Amazon Elastic Kubernetes Service (EKS) comme orchestrateur et permet de créer un cluster en quelques clics depuis la console SageMaker AI. Deux modes de configuration sont proposés : une installation rapide avec des ressources par défaut, et une installation personnalisée permettant d'intégrer des infrastructures existantes. Une fois le cluster actif, l'opérateur d'inférence intégré permet de déployer des modèles directement depuis des buckets S3, des systèmes de fichiers FSx for Lustre, ou depuis le catalogue SageMaker JumpStart, sans écrire une seule ligne de code. Des notebooks d'exemple couvrent les cas d'usage courants : modèles préconstruits, modèles fine-tunés, configurations personnalisées. L'enjeu central de cette mise à jour est la gestion dynamique des ressources GPU, historiquement coûteuse et complexe à piloter. HyperPod introduit une architecture de scalabilité à deux niveaux : KEDA (Kubernetes Event-Driven Autoscaling), un projet open source de la Cloud Native Computing Foundation, gère l'autoscaling des pods en fonction de métriques temps réel comme la longueur de la file de requêtes, la latence, ou des métriques CloudWatch et Prometheus personnalisées. KEDA peut réduire le nombre de pods à zéro en l'absence de trafic, supprimant ainsi les coûts à l'arrêt. En parallèle, Karpenter opère au niveau des nœuds de calcul : il provisionne ou retire des instances selon les besoins des pods en attente, et tourne dans le plan de contrôle EKS, ce qui évite tout surcoût lié à l'autoscaler lui-même. Cette combinaison permet de passer de zéro à une charge de production en réponse à la demande réelle. Ce lancement intervient dans un contexte où le déploiement de modèles de fondation à grande échelle est devenu un point de friction majeur pour les équipes IA en entreprise : infrastructure difficile à calibrer, pics de trafic imprévisibles, surinvestissement GPU, et délais de mise en production allongés. AWS positionne HyperPod comme une réponse complète à ce trilemme coût-performance-simplicité, en absorbant la complexité opérationnelle dans une couche managée. La plateforme concurrence directement les offres de Google (Vertex AI) et Microsoft Azure (ML endpoints managés), qui proposent des approches similaires. Les suites probables incluent une intégration plus poussée avec les outils d'observabilité AWS et une extension du support à d'autres architectures de modèles, alors que la course aux infrastructures d'inférence efficaces s'intensifie dans tout le secteur cloud.

InfrastructureActu
1 source
Google lance ses TPU v8 et spécialise ses puces pour l’IA : enjeux et comparatif maison
4Next INpact 

Google lance ses TPU v8 et spécialise ses puces pour l’IA : enjeux et comparatif maison

Google a annoncé sa huitième génération de Tensor Processing Units (TPU), ses puces spécialisées dans les calculs d'intelligence artificielle. Pour la première fois dans l'histoire de la gamme, la firme de Mountain View propose deux variantes distinctes basées non plus sur le niveau de performance, mais sur le type d'usage : le TPU v8t, orienté vers l'entraînement des modèles, et le TPU v8i, dédié à l'inférence. C'est une rupture notable avec les générations précédentes, comme les v5e et v5p, qui se différenciaient uniquement par l'efficacité énergétique contre la puissance brute. Cette spécialisation par usage représente un changement de stratégie significatif pour Google. Selon la firme elle-même, "les deux puces peuvent gérer différentes charges de travail, mais la spécialisation permet d'obtenir des gains significatifs". En séparant l'entraînement de l'inférence au niveau matériel, Google cherche à optimiser le rapport performances/coût pour chaque étape du cycle de vie d'un modèle d'IA. Pour les entreprises clientes de Google Cloud, cela se traduit potentiellement par des coûts d'exploitation réduits et une meilleure efficacité dans le déploiement de modèles génératifs à grande échelle. Cette annonce s'inscrit dans une course aux puces IA qui s'est considérablement intensifiée depuis 2018, date des TPU v3. En huit générations, Google a construit une alternative crédible aux GPU de Nvidia, qui dominent encore largement le marché de l'accélération IA. La firme utilise ses TPU en interne pour entraîner ses propres modèles Gemini, ce qui lui confère un avantage compétitif double : maîtrise du hardware et du software. Face à la montée en puissance de concurrents comme les puces Trainium d'Amazon ou les Gaudi d'Intel, la spécialisation des TPU v8 pourrait devenir un argument commercial décisif pour attirer les grandes entreprises vers Google Cloud plutôt que vers AWS ou Azure.

UELes entreprises européennes qui s'appuient sur Google Cloud pour entraîner ou déployer des modèles d'IA pourraient bénéficier d'une réduction des coûts d'exploitation grâce à la spécialisation matérielle des TPU v8.

InfrastructureOpinion
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