Aller au contenu principal
LightSeek Foundation publie TokenSpeed, moteur d'inférence LLM open source visant TensorRT-LLM pour agents autonomes
InfrastructureMarkTechPost · 2 min de lecture

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

Source originale ↗·

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.

Impact France/UE

La 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.

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

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

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.

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

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

Together AI vient de publier en open source OSCAR (Offline Spectral Covariance-Aware Rotation), un système de quantification du cache KV à 2 bits conçu pour réduire drastiquement la mémoire GPU nécessaire à l'inférence de grands modèles de langage sur de longs contextes. Le problème visé est concret : lors de l'inférence en mode autorégressif, le cache KV croît avec la longueur du contexte, la taille des lots et la profondeur du modèle. À 100 000 tokens traités par dizaines de requêtes simultanées, ce cache peut accaparer la majorité de la mémoire GPU disponible. La quantification à INT2, qui ne représente les valeurs qu'avec 4 niveaux distincts, était jusqu'ici largement inutilisable : soit elle dégradait trop la précision, soit elle était incompatible avec les architectures de cache paginé utilisées en production. OSCAR surmonte ces deux obstacles grâce à une rotation des activations fondée non pas sur leur distribution brute, mais sur les statistiques d'attention elles-mêmes. L'innovation centrale d'OSCAR réside dans le choix de la base de rotation. Pour les clés (keys), ce qui compte n'est pas l'erreur de reconstruction euclidienne, mais l'erreur sur les logits d'attention, pondérée par la covariance des requêtes. Pour les valeurs (values), c'est la covariance pondérée par les scores d'attention qui détermine quelles directions d'erreur se propagent réellement dans la sortie du modèle. OSCAR estime ces covariances sur un jeu de calibration, les décompose en vecteurs propres, et les utilise comme base de rotation optimale. La rotation finale se compose de trois éléments : l'alignement sur les directions importantes pour l'attention, une transformation de Hadamard qui uniformise les canaux, et un réordonnancement par inversion de bits qui garantit que chaque groupe de quantification reçoit un représentant de chaque niveau hiérarchique. Le système s'intègre dans la pile de serving production de SGLang comme mode INT2 natif du cache KV. Ce travail s'inscrit dans une course intense à l'efficacité mémoire pour les LLM en production. La quantification du cache KV est un levier direct sur la taille des lots traitables et donc sur le coût par requête. Les approches INT4 existantes, comme QuIP# ou QuaRot, fonctionnaient déjà correctement, mais INT2 représentait une frontière difficile à franchir sans perte de qualité rédhibitoire. En publiant OSCAR en open source avec une intégration SGLang, Together AI met cet outil à disposition de l'ensemble de la communauté de déploiement de modèles. L'enjeu est considérable : multiplier par deux la compression du cache KV peut doubler la capacité de traitement parallèle d'un serveur sans changer le matériel. Les prochaines étapes naturelles concernent la validation sur des modèles de très grande taille et l'extension à d'autres architectures d'attention.

UELes laboratoires et startups IA européens déployant des LLM peuvent adopter cette technique open source pour réduire leurs coûts d'inférence GPU et doubler leur capacité de traitement parallèle sans changer de matériel.

InfrastructureOpinion
1 source
NVIDIA Blackwell domine le premier benchmark d'infrastructure pour agents autonomes d'IA
3NVIDIA AI Blog 

NVIDIA Blackwell domine le premier benchmark d'infrastructure pour agents autonomes d'IA

Artificial Analysis a publié AgentPerf, le premier benchmark sectoriel conçu spécifiquement pour évaluer les infrastructures d'IA agentique. Dans ce premier tour de résultats, la plateforme NVIDIA GB300 NVL72, basée sur l'architecture Blackwell Ultra, s'impose comme le système le plus performant : elle peut faire tourner jusqu'à 20 fois plus d'agents par mégawatt que l'ancienne génération HGX H200 (Hopper), quel que soit le seuil de qualité de service retenu (20 ou 60 tokens par seconde par agent). Le modèle de référence utilisé pour ce test est DeepSeek V4 Pro, un grand modèle de type mixture-of-experts représentatif des LLM qui propulsent aujourd'hui les agents les plus capables. La distinction entre IA conversationnelle et IA agentique est au coeur de cette initiative. Un chatbot classique réalise un seul appel LLM par échange : c'est un sprint. Un agent, lui, enchaîne des dizaines voire des centaines d'appels LLM entrelacés d'appels à des outils externes, compilation de code, recherche en base de données, navigation web, en transmettant à chaque étape un contexte de plus en plus long. La complexité n'est pas additive, elle est multiplicative. Les benchmarks d'inférence existants ne mesuraient qu'un seul appel LLM isolé et n'avaient pas été conçus pour capturer cette réalité. Pour une entreprise qui déploie des agents à grande échelle, les métriques pertinentes sont la réactivité des agents, le nombre d'instances simultanées supportées, et surtout le volume de travail utile produit par dollar et par watt investis. La performance du GB300 NVL72 repose sur une co-conception poussée de l'ensemble de la pile logicielle et matérielle. Le système interconnecte 72 GPU en une seule unité rack, ce qui permet aux grands modèles MoE comme DeepSeek V4 Pro de distribuer leur exécution efficacement. Les noyaux CUDA chevauchent communication et calcul pour absorber la latence de coordination entre experts. TensorRT-LLM sépare le traitement des entrées de la génération des sorties afin d'optimiser chaque phase indépendamment. AgentPerf lui-même est construit à partir de trajectoires réelles d'agents de codage opérant sur des dépôts publics couvrant plus de 12 langages de programmation, avec des longueurs de séquences, des délais d'appels d'outils et des patterns représentatifs de la production. Ce benchmark arrive à un moment où l'industrie bascule massivement vers des architectures agentiques, et où le choix d'infrastructure devient un avantage concurrentiel direct pour quiconque déploie ces systèmes à l'échelle.

UELes entreprises et cloud providers européens déployant des agents IA à grande échelle peuvent utiliser ce benchmark pour orienter leurs décisions d'achat de matériel.

💬 Vingt fois plus d'agents par mégawatt, c'est pas anodin. Ce qui m'intéresse surtout dans ce benchmark, c'est qu'il mesure enfin ce qui compte vraiment : pas un seul appel LLM en isolation, mais des chaînes complètes avec des dizaines d'appels et du contexte qui s'accumule à chaque étape. Reste à voir si ça se confirme sur des tâches moins lisses que du code sur des dépôts publics.

InfrastructureActu
1 source
Kimi AI et kvcache-ai publient AgentENV en open source, un systeme distribue pour l'entrainement par renforcement des agents de Kimi K3
4MarkTechPost 

Kimi AI et kvcache-ai publient AgentENV en open source, un systeme distribue pour l'entrainement par renforcement des agents de Kimi K3

Moonshot AI, l'équipe derrière le modèle Kimi, et la société kvcache-ai ont ouvert le code source d'AgentENV (AENV), une plateforme distribuée conçue pour faire tourner des environnements d'agents à grande échelle, sous licence MIT. Ce système alimente l'entraînement par apprentissage par renforcement (RL) agentique de Kimi K3, le modèle Mixture-of-Experts de Moonshot doté de 2 800 milliards de paramètres. Techniquement, AgentENV repose sur des micro-VM Firecracker, chacune dotée de son propre noyau Linux, système de fichiers et espace réseau isolé. Les requêtes passent par une API HTTP Axum reliée à un orchestrateur qui gère le cycle de vie des sandboxes. Le stockage utilise un dispositif bloc en espace utilisateur (ublk) appuyé sur des images en couches overlaybd, avec des couches de base en lecture seule partagées entre sandboxes. À l'intérieur de chaque machine virtuelle, un démon nommé envd exécute les commandes et surveille l'état de santé sur le port 49983. Les chiffres annoncés sont significatifs : démarrage ou reprise d'un environnement en moins de 50 millisecondes, mise en pause en moins de 100 millisecondes, et capture d'un instantané incrémental également sous la barre des 100 millisecondes, même en cas de forte modification du disque. Cette architecture répond à un problème concret de l'entraînement agentique par renforcement : chaque étape d'apprentissage exige que le modèle agisse dans un véritable environnement informatique complet, avec système de fichiers, réseau et processus actifs, ce qui crée un arbitrage difficile entre conteneurs rapides mais peu isolés et machines virtuelles complètes mais lentes à démarrer. La fonctionnalité de fork est ici centrale : un sandbox actif peut se cloner en jusqu'à 16 sandboxes enfants indépendants sur un même nœud, chacun héritant du système de fichiers, de la mémoire et de la configuration du parent. Concrètement, une équipe peut installer des dépendances, cloner un dépôt et atteindre un état de tâche donné une seule fois, puis faire diverger cet état en plusieurs déploiements parallèles pour l'entraînement. Cela réduit drastiquement le coût de préparation répétitive et permet de faire tourner un grand nombre de rollouts simultanés, un enjeu clé pour rendre l'entraînement RL des grands modèles économiquement viable à l'échelle. Le système intègre aussi des mécanismes de densité mémoire, comme le partage du cache de pages hôte et le ballooning mémoire, qui permettent de maintenir un fort taux de suroccupation des ressources à mesure que les environnements divergent. Les instantanés sont persistés vers un stockage compatible S3 ou un système de fichiers distribué partagé, organisés en trois couches : un espace de travail de build, un dépôt d'instantanés validés et un cache local par nœud. Par défaut, chaque sandbox expire par mise en pause plutôt que par suppression, sauf paramétrage explicite contraire. Un transport pair-à-pair optionnel basé sur iroh, désactivé par défaut, peut aussi diffuser les artefacts validés entre nœuds sans modifier le modèle de gestion des instantanés.

💬 Bon, la vraie info ici c'est pas le modèle, c'est l'infra en dessous. Démarrer un environnement complet en moins de 50ms et forker jusqu'à 16 sandboxes isolés à partir d'un seul état préparé, ça règle le vrai goulot d'étranglement du RL agentique : préparer l'environnement coûte plus cher que d'y faire tourner l'agent. Reste à voir si ça tient face à des milliers de rollouts en parallèle sur la durée, mais le fait que Moonshot l'ouvre en MIT plutôt que de le garder pour Kimi K3 en dit long : ils savent que c'est l'infra RL, pas le modèle, qui va devenir le vrai avantage compétitif chez les labs chinois.

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