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

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.

Les sessions persistantes et l'exécution de commandes shell grâce à la configuration du système de fichiers

Amazon a annoncé deux nouvelles fonctionnalités pour son service Bedrock AgentCore Runtime : le stockage de session persistant (en préversion publique) et l'exécution directe de commandes shell via InvokeAgentRuntimeCommand. Ces capacités répondent à deux problèmes concrets que rencontrent les équipes qui déploient des agents IA en production. Chaque session AgentCore Runtime tourne dans une microVM isolée avec son propre noyau, sa mémoire et son système de fichiers. Jusqu'ici, à l'arrêt de la session, tout ce que l'agent avait créé — dépendances installées, code généré, historique git local — disparaissait. Le stockage managé de session règle ce problème en offrant un répertoire persistant, configurable au moment de la création de l'agent via le paramètre filesystemConfiguration, qui survit aux cycles arrêt/reprise même lorsque l'environnement de calcul est remplacé. La seconde fonctionnalité, InvokeAgentRuntimeCommand, permet d'exécuter des commandes shell déterministes comme npm test ou git push directement dans la microVM associée à la session active, sans passer par le modèle de langage. L'impact est immédiat pour les équipes qui construisent des agents de développement. Avant ces ajouts, un agent de coding pouvait passer vingt minutes à scaffolder un projet — créer l'arborescence, installer les dépendances, configurer les outils de build — pour que tout disparaisse à la première pause. Au redémarrage, tout était à recommencer : vingt minutes de calcul brûlées avant de pouvoir reprendre un travail utile. De même, faire transiter une commande déterministe comme l'exécution de tests via le LLM ajoutait du coût en tokens, de la latence et une non-déterminisme inutile à une opération parfaitement prévisible. Les contournements existants, comme écrire une logique de checkpoint vers Amazon S3 avant chaque arrêt de session ou maintenir les sessions actives en permanence, fonctionnaient mais reportaient la complexité dans le code de l'agent plutôt que de résoudre le problème à la racine. Ces annonces s'inscrivent dans une évolution plus large du rôle des agents IA dans les workflows de développement. Le système de fichiers est devenu la mémoire de travail principale des agents, leur permettant de dépasser les limites du contexte des LLM. Amazon Bedrock AgentCore Runtime, en intégrant nativement la persistance et l'exécution de commandes shell au niveau de l'infrastructure, cherche à s'imposer comme runtime de référence pour les agents de production. Cette approche concurrence directement des solutions comme les environnements de sandbox de Modal, les DevContainers GitHub Codespaces, ou les outils d'orchestration d'agents open source comme LangGraph et AutoGen, qui proposent leurs propres mécanismes de gestion d'état. La disponibilité en préversion publique du stockage de session laisse anticiper une disponibilité générale dans les prochains mois, vraisemblablement accompagnée d'une tarification spécifique liée au volume de stockage persistant utilisé.

💬 C'est exactement le problème que personne ne veut admettre publiquement : un agent qui perd son contexte à chaque pause, c'est du calcul jeté à la poubelle. Amazon règle ça au niveau infrastructure plutôt qu'en laissant chaque équipe bricoler ses checkpoints S3, et c'est le bon endroit pour le faire. Reste la question du prix, parce que du stockage persistant managé sur AWS, ça ne va pas rester gratuit longtemps.