Together AI publie OSCAR en open source : un système de quantification KV cache 2 bits adaptatif pour les LLM à long contexte

MoonMath AI publie en open source un kernel d'attention HIP pour AMD MI300X surpassant AITER v3 sur toutes les configurations

MoonMath AI, une équipe de recherche spécialisée en optimisation GPU, a publié en open source un noyau de calcul d'attention en bf16 pour le GPU AMD MI300X, sous licence MIT. Écrit en HIP (le langage de programmation GPU d'AMD), ce noyau implémente l'opération d'attention centrale des transformers, le calcul softmax(QKᵀ/√d)·V, et surpasse sur tous les cas testés AITER v3, le propre noyau optimisé d'AMD. Les gains géométriques mesurés atteignent 1,18×, 1,15× et 1,08× selon les modes d'arrondi, avec un pic à 1,26× sur certaines configurations. Les tests ont été conduits sur du matériel bare-metal fourni par HotAisle, un fournisseur cloud AMD. Le noyau cible exclusivement l'architecture CDNA3 du MI300X (ISA gfx942), avec une dimension de tête fixée à 128 et une prise en charge de longueurs de séquence arbitraires, y compris l'attention croisée. Une pull request concrète dans SGLang a utilisé ce noyau pour accélérer la génération vidéo par le modèle Wan2.1 de 1,23× sans aucune régression de qualité. Ce résultat est significatif pour l'écosystème AMD, longtemps considéré comme en retard sur NVIDIA en matière de performance logicielle pour l'inférence de modèles de langage. Battre AMD sur son propre terrain, avec un noyau non assembleur, donc lisible et maintenable, démontre qu'il est possible d'extraire des performances compétitives du MI300X sans recourir à du code machine manuscrit opaque. Pour les équipes qui déploient des LLMs ou des modèles de diffusion vidéo sur infrastructure AMD, ce noyau représente un gain immédiat et vérifiable. La précision numérique est soigneusement préservée : chaque sortie finie reste dans une unité bf16 ULP d'AITER, les comportements NaN et Inf sont bit-identiques, et les résultats sont déterministes. Sur le plan technique, la performance provient de deux innovations principales. D'abord, une astuce d'assemblage inline qui enveloppe exactement une instruction dans une fonction forceinline, laissant le compilateur gérer l'allocation des registres tout en gardant le contrôle de l'opcode, évitant ainsi les copies de registres inutiles qui pénalisent les approches naïves. Ensuite, un placement mémoire rigoureux : K est chargé depuis la HBM vers la mémoire partagée locale (LDS) en double-buffering, V reste chaud dans le cache L1, et Q avec les accumulateurs résident dans les registres. La stratégie d'ordonnancement des vagues, huit vagues par bloc, en deux groupes de quatre décalés en phase, permet au cœur matriciel de ne jamais rester inactif, en alternant calcul et softmax à la manière de FlashAttention-3, mais adaptée aux spécificités de CDNA3 où toute opération mémoire est déjà asynchrone. Ce travail s'inscrit dans une tendance plus large de la communauté open source qui, faute de support logiciel mature d'AMD, prend elle-même en charge l'optimisation bas niveau de ces GPUs.

💬 Quand une équipe externe bat AMD sur ses propres GPUs, sans même toucher à l'assembleur, c'est que le support logiciel officiel avait un vrai problème. Ce kernel HIP lisible et maintenable qui surpasse AITER v3 sur toutes les configs, c'est exactement le signal qu'on attendait pour prendre AMD au sérieux en prod, pas juste sur les benchmarks marketing. Et le fait que ça tourne déjà dans SGLang sur de la génération vidéo, c'est pas un proof-of-concept de labo.

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.

NVIDIA lance Ising : sa première famille de modèles d'IA quantique ouverts pour systèmes hybrides quantique-classique

NVIDIA a lancé Ising, la première famille de modèles d'IA quantique ouverts au monde, conçue pour aider chercheurs et entreprises à construire des processeurs quantiques capables de faire tourner des applications réelles. La famille comprend deux composants distincts : Ising Calibration, un modèle de langage visuel qui interprète en temps réel les mesures des processeurs quantiques et ajuste automatiquement le système pour le maintenir en fonctionnement optimal, réduisant les temps de calibration de plusieurs jours à quelques heures ; et Ising Decoding, disponible en deux variantes de réseau de neurones convolutif 3D optimisées respectivement pour la vitesse et la précision, qui effectuent le décodage d'erreurs quantiques en temps réel. Ising Decoding se montre jusqu'à 2,5 fois plus rapide et 3 fois plus précis que pyMatching, l'actuel standard open source du secteur. Dès le premier jour, des organisations comme IonQ, IQM Quantum Computers, Infleqtion, le Fermi National Accelerator Laboratory, Harvard, Sandia National Laboratories, l'Université de Chicago et une douzaine d'autres acteurs académiques et commerciaux ont déjà adopté ces outils. L'enjeu est considérable : le principal frein au déploiement concret de l'informatique quantique n'est pas la puissance brute des processeurs, mais leur extrême sensibilité aux perturbations extérieures. Les qubits, unités de calcul fondamentales, accumulent des erreurs à une vitesse qui rend tout calcul utile quasiment impossible sans une calibration rigoureuse et une correction d'erreurs en temps réel. Ces deux opérations étaient jusqu'ici manuelles, lentes et difficiles à mettre à l'échelle. En automatisant ces processus critiques par l'IA, NVIDIA s'attaque directement au goulot d'étranglement qui sépare les démonstrateurs de laboratoire des machines véritablement opérationnelles. Une réduction des temps de calibration de plusieurs jours à quelques heures représente un gain de productivité transformateur pour les équipes de recherche. Ising s'inscrit dans la stratégie plus large de NVIDIA pour positionner ses GPU au coeur de l'informatique hybride quantique-classique. Les modèles Ising complètent CUDA-Q, la plateforme logicielle de NVIDIA pour les workflows hybrides, et s'intègrent avec NVQLink, l'interconnexion matérielle GPU-QPU développée par l'entreprise pour permettre une communication à faible latence entre processeurs graphiques et unités quantiques. Cette approche suit la même philosophie que CUDA pour l'accélération GPU : coupler étroitement calcul classique et calcul accéléré. Alors que des acteurs comme IBM, Google et des startups spécialisées investissent massivement dans la course au quantique, NVIDIA parie sur une stratégie de plateforme transversale, agnostique aux technologies de qubits, qui lui permet de s'imposer comme couche d'infrastructure indispensable quelle que soit la technologie gagnante.

💬 La calibration des qubits qui passe de plusieurs jours à quelques heures, c'est le vrai goulot d'étranglement du quantique, et c'est la première fois qu'on voit une solution à la hauteur du problème. NVIDIA fait exactement ce qu'ils ont fait avec CUDA : s'imposer comme couche d'infra incontournable avant même de savoir quelle technologie va gagner. Harvard, Fermi Lab, IQM dès le premier jour, ça ne s'invente pas.

Dégradation du contexte, dérive d'orchestration et montée des défaillances silencieuses dans les systèmes d'IA

Les systèmes d'intelligence artificielle déployés en entreprise souffrent d'un angle mort critique : leurs pannes les plus coûteuses ne déclenchent aucune alarme. Un système peut afficher un uptime parfait, une latence dans les clous et un taux d'erreur nul, tout en produisant des réponses fausses, construites sur des données périmées ou des contextes corrompus. C'est ce que les ingénieurs spécialisés en infrastructure IA appellent le « reliability gap », l'écart entre la santé opérationnelle d'un service et sa fiabilité comportementale. Contrairement aux bugs classiques, ces défaillances silencieuses n'apparaissent ni dans Prometheus, ni dans Datadog, ni dans aucun tableau de bord traditionnel. Le modèle lui-même est rarement en cause : c'est la couche d'infrastructure qui l'entoure, pipelines de données, systèmes de récupération d'information, logique d'orchestration, workflows aval, qui dérive sans être détectée. Quatre patterns de rupture reviennent systématiquement dans les déploiements en production. La dégradation du contexte survient quand le modèle raisonne sur des données obsolètes ou incomplètes sans que l'utilisateur final ne s'en aperçoive : la réponse paraît soignée, le grounding a disparu, et la détection n'arrive que des semaines plus tard via des conséquences indirectes. La dérive d'orchestration touche les pipelines agentiques : stables en test, ils se comportent très différemment en charge réelle, quand les latences se cumulent et que les cas limites s'enchaînent. Les pannes partielles silencieuses, elles, font basculer un système dans la méfiance des utilisateurs bien avant qu'un ticket d'incident ne soit créé. Enfin, le blast radius de l'automatisation est propre aux workflows IA : une mauvaise interprétation tôt dans la chaîne se propage à travers plusieurs systèmes et décisions métier, avec des conséquences organisationnelles très difficiles à inverser. Ce problème prend de l'ampleur à mesure que les entreprises industrialisent leurs usages de l'IA dans des domaines critiques, opérations réseau, logistique, plateformes d'observabilité. Les deux dernières années ont été consacrées à évaluer les modèles eux-mêmes : benchmarks, scores de précision, red-teaming. Mais en production, c'est l'infrastructure qui cède. La réponse technique passe par l'ajout d'une couche de télémétrie comportementale en complément des outils existants, non pour les remplacer, mais pour capturer ce que le modèle a réellement fait avec le contexte reçu, et pas seulement si le service a répondu. La question n'est plus « le service est-il en ligne ? » mais « le service se comporte-t-il correctement ? » Ce sont deux instruments différents, et l'industrie commence à peine à construire le second.