NVIDIA introduit une méthode de pré-entraînement en 4 bits avec NVFP4, validée sur un modèle hybride Mamba-Transformer de 12 milliards de paramètres

Prime Intellect publie prime-rl 0.6.0 pour entraîner des modèles MoE à mille milliards de paramètres sur des tâches RL à base d'agents

Prime Intellect a publié la version 0.6.0 de son framework open source prime-rl, conçu pour entraîner des modèles de langage de très grande taille via du reinforcement learning asynchrone. Cette mise à jour majeure cible spécifiquement les modèles Mixture-of-Experts (MoE) à l'échelle du trillion de paramètres, avec un focus sur des tâches dites "agentiques" longues et complexes, comme la résolution autonome de bugs logiciels. Pour illustrer les capacités du framework, l'équipe a entraîné GLM-5, le modèle de l'organisation zai-org, sur des tâches d'ingénierie logicielle (SWE) avec des séquences allant jusqu'à 131 000 tokens. Résultat : des temps d'étape inférieurs à cinq minutes, des batchs de 256 rollouts, le tout sur seulement 28 noeuds H200, une efficacité matérielle remarquable pour cette classe de modèles. Le framework est également compatible avec d'autres modèles MoE massifs comme Kimi-K2.7-Code de Moonshot AI ou le Nemotron-3-Ultra-550B de NVIDIA. Ce type d'infrastructure répond à un problème concret du reinforcement learning à grande échelle : les tâches agentiques génèrent des "outliers" temporels, certains rollouts de code pouvant s'étirer sur plusieurs heures. Dans un système synchrone classique, les GPU restent à l'arrêt en attendant la fin de ces longues exécutions avant chaque mise à jour de politique. prime-rl résout ce goulot d'étranglement en découplant complètement le moteur d'inférence du moteur d'entraînement : les deux fonctionnent et scalent indépendamment, avec un unique point de synchronisation au moment de la mise à jour des poids. Côté inférence, le système combine calcul en FP8 avec les kernels DeepEP et DeepGEMM, un "Wide Expert Parallelism" répartissant les experts sur 32 GPU ou plus, une séparation des workers de prefill et de decode, et un système de gestion hiérarchique du cache KV avec offloading vers CPU ou disque. Le mécanisme "Router Replay" (R3) est particulièrement notable : il rejoue les décisions de routage de l'inférence directement sur le trainer, réduisant le décalage KL d'un ordre de grandeur. Cette publication s'inscrit dans une course à la scalabilité du post-training par RL, accélérée par le succès des modèles de raisonnement comme DeepSeek-R1 ou les modèles de la série o1 d'OpenAI. L'approche MoE est devenue centrale pour atteindre des capacités de niveau "trillion de paramètres" sans exploser les coûts de calcul à l'inférence, mais elle impose des contraintes d'orchestration redoutables, notamment la coordination des experts entre des dizaines de GPU. Prime Intellect, qui se positionne sur l'entraînement distribué open source, mise sur prime-rl pour démocratiser l'accès à ces techniques jusqu'ici réservées aux grands laboratoires disposant de clusters propriétaires. La compatibilité avec Slurm et des routeurs comme NVIDIA Dynamo suggère une orientation claire vers des déploiements en production à l'échelle industrielle.

💬 Le vrai problème du RL agentique, c'est pas la puissance brute, c'est les rollouts qui s'étirent sur des heures et laissent les GPU à l'arrêt. prime-rl règle ça en découplant complètement inférence et entraînement, avec un seul point de synchro, et leur mécanisme R3 réduit le décalage KL d'un ordre de grandeur. Un labo européen sans cluster propriétaire a désormais un chemin crédible vers le post-training RL à l'échelle trillion.

Xiaomi MiMo et TileRT franchissent les 1000 tokens par seconde avec un modèle d'un billion de paramètres sur GPU grand public

Xiaomi, en collaboration avec le groupe système TileRT, a publié MiMo-V2.5-Pro-UltraSpeed, un mode de serving haute vitesse pour son modèle existant MiMo-V2.5-Pro. Ce modèle, basé sur une architecture Mixture-of-Experts (MoE) à l'échelle du trillion de paramètres, franchit pour la première fois la barre des 1 000 tokens par seconde sur cette classe de modèles, avec des pics mesurés à 1 200 tokens/s. Ce qui rend la performance remarquable, c'est le matériel utilisé : non pas des puces custom ou des accélérateurs spécialisés, mais un nœud standard de 8 GPU grand public. Le résultat découle de trois techniques coordonnées que Xiaomi qualifie de "codesign modèle-système extrême" : la quantification FP4 (format MXFP4 appliqué sélectivement aux experts MoE, le reste restant en FP8), le décodage spéculatif DFlash, et le moteur d'exécution TileRT. La qualité des benchmarks reste comparable au modèle original grâce à un entraînement avec conscience de la quantification (QAT). Ces vitesses changent concrètement ce qu'il est possible de faire avec un grand modèle en production. À 1 000 tokens/s, des tâches qui supposaient d'attendre plusieurs secondes entre chaque étape deviennent quasi-instantanées : un agent de code peut enchaîner les cycles génération-exécution-correction sans temps mort perceptible, des stratégies de raisonnement Best-of-N peuvent faire tourner des dizaines de branches en parallèle dans le même temps horloge, et des usages temps réel comme la détection de fraude ou le dialogue interactif deviennent viables sans infrastructure dédiée. Les démos publiées montrent la génération d'un jeu Snake en une dizaine de secondes, illustrant la fluidité atteinte pour des tâches de prototypage rapide. DFlash, la pièce centrale du gain de vitesse, résout un problème structurel du décodage spéculatif classique : le modèle brouillon génère les tokens un par un, créant un goulot d'étranglement séquentiel. DFlash utilise une prédiction parallèle masquée par blocs, permettant au modèle brouillon de remplir un bloc entier de positions en un seul passage. Sur des tâches de code, six à sept tokens sur huit sont acceptés à chaque round de vérification, atteignant parfois 7,14 en moyenne. TileRT complète le tableau côté système : à ces vitesses, chaque opérateur ne dure que quelques microsecondes, et les coûts de lancement d'opérateurs traditionnels fracturent le flux d'exécution. TileRT maintient un noyau persistant sur le GPU avec spécialisation par warp, éliminant ces interruptions. Xiaomi positionne cette combinaison comme une réponse directe à la montée en puissance de la vitesse d'inférence comme métrique concurrentielle, face aux investissements croissants de Meta, Google et OpenAI dans leurs propres accélérateurs propriétaires.

Optimiser l'entraînement des modèles sur Amazon SageMaker AI avec NVIDIA Blackwell

Amazon Web Services a rendu disponibles sur Amazon SageMaker AI les instances P6-B200, équipées de huit GPU NVIDIA Blackwell B200, pour l'entraînement de modèles de machine learning à grande échelle. Ces GPU de nouvelle génération embarquent 180 Go de mémoire HBM par puce (268 Go sur le B300), contre des capacités bien inférieures sur les générations précédentes, et s'interconnectent via NVLink 5 qui atteint 1,8 To/s de bande passante bidirectionnelle entre GPU. La configuration cible des modèles Transformer allant de 1 à 64 milliards de paramètres, entraînés en parallélisme de données fragmentées (FSDP de PyTorch) sur un nœud unique à huit GPU. L'accès à ces instances peut être réservé via le programme Flexible Training Plan d'AWS pour bénéficier d'une capacité prévisible et d'une gestion automatisée des ressources. Cette architecture modifie concrètement ce qui est réalisable dans l'entraînement de grands modèles. Jusqu'ici, les ingénieurs se heurtaient à trois contraintes classiques : des tailles de batch limitées par la mémoire GPU, des séquences tronquées pour éviter les erreurs out-of-memory, et un fractionnement du modèle sur plusieurs nœuds qui génère une surcharge réseau importante. Avec 180 Go par GPU, certains modèles qui nécessitaient auparavant plusieurs nœuds peuvent désormais tenir sur un seul nœud à huit GPU, ce qui réduit la latence de communication, accélère les cycles d'itération et diminue les coûts d'infrastructure. Des séquences plus longues deviennent viables pour les tâches de dépendances à longue portée, et le nombre d'étapes de synchronisation des gradients diminue avec des batchs plus grands, améliorant le débit global. NVIDIA Blackwell représente la cinquième génération de Tensor Cores de la marque, et son architecture dual-chip marque une rupture par rapport aux générations Ampere et Hopper. L'explosion de la taille des modèles ces trois dernières années, de GPT-3 à 175 milliards de paramètres jusqu'aux modèles actuels dépassant le trillion, a poussé les fournisseurs cloud et les fabricants de puces à repenser conjointement leurs offres. AWS et NVIDIA ont renforcé leur partenariat autour de SageMaker pour proposer une intégration clé en main qui abstrait la gestion de l'infrastructure. Les prochaines étapes pratiques pour les équipes ML consistent à calibrer le format de précision (FP8, BF16 ou FP16 selon la taille du modèle), ajuster le checkpointing d'activations pour équilibrer mémoire et calcul, et décider si la priorité est le débit, la réduction des communications inter-GPU ou la longueur de contexte. L'enjeu pour AWS est de capter une part croissante des budgets d'entraînement de modèles fondationnels, un marché où Google Cloud et Microsoft Azure jouent également des capacités GPU Blackwell.

Guide pratique : utiliser le Transformer Engine NVIDIA avec précision mixte, vérifications FP8 et exécution de secours

Le Transformer Engine de NVIDIA s'impose progressivement comme un outil de référence pour accélérer l'entraînement des modèles de deep learning en entreprise. Un tutoriel technique publié récemment propose une implémentation complète en Python, couvrant l'installation des composants, la vérification de la compatibilité GPU et CUDA, ainsi que la comparaison directe entre un pipeline PyTorch standard et un pipeline optimisé via le Transformer Engine. La démonstration construit deux réseaux neuronaux (enseignant et élève), les entraîne en parallèle, mesure leurs performances respectives en termes de vitesse d'exécution et de consommation mémoire, et produit des visualisations comparatives. Le tutoriel prend soin de gérer les échecs d'installation silencieusement, de manière à ce que le notebook reste exécutable même lorsque l'extension native ne peut pas être compilée, via un mode de repli automatique. Ce type d'outillage répond à un besoin concret des équipes d'IA cherchant à réduire les coûts d'entraînement sans changer d'architecture. Le Transformer Engine exploite la précision FP8 (8 bits flottants), disponible sur les GPU NVIDIA à partir de l'architecture Hopper (H100), pour effectuer les calculs matriciels les plus lourds avec une empreinte mémoire réduite et un débit augmenté, tout en maintenant la précision finale du modèle grâce à la gestion automatique des facteurs d'échelle. En pratique, cela peut se traduire par des gains de vitesse significatifs sur les passes avant et arrière des transformers, réduisant directement le temps et le coût des runs d'entraînement à grande échelle. L'approche intéresse aussi bien les laboratoires de recherche que les équipes MLOps en production. NVIDIA a développé le Transformer Engine en réponse à la montée en puissance des modèles de langage et de vision nécessitant des milliards de paramètres, pour lesquels la précision FP32 ou même FP16 devient un goulot d'étranglement. Introduit officiellement avec les GPU H100 et le framework TransformerEngine open source, il s'intègre à PyTorch et JAX via des couches drop-in comme te.Linear et te.TransformerLayer. La complexité d'installation, notamment la nécessité d'un compilateur NVCC et des headers cuDNN présents sur la machine, freine encore son adoption hors des environnements cloud spécialisés. Le tutoriel aborde précisément ce point de friction en proposant une détection automatique de l'environnement et un fallback propre, ce qui devrait abaisser la barrière d'entrée pour les équipes souhaitant expérimenter avant de migrer leurs pipelines de production vers cette technologie.