Moonshot AI open-source FlashKDA : noyaux CUTLASS pour Kimi Delta Attention et benchmarks H20

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.

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.

Mixture-of-Kittens (MoK) : Cursor publie en open source un mégakernel d'entraînement MoE déterministe pour racks GB300 NVL72

Cursor Research a mis en open source Mixture-of-Kittens (MoK), le megakernel d'entraînement pour architectures mixture-of-experts (MoE) qui alimente ses modèles Composer. L'outil fusionne toutes les étapes de communication et de calcul MoE en un seul kernel déterministe. Selon l'équipe Cursor, il atteint jusqu'à 2,37 fois le débit du meilleur baseline public disponible, et il fait déjà tourner l'entraînement de Composer sur des dizaines de milliers de GPU. MoK est publié sous licence Apache-2.0 sur GitHub, mais son accès matériel reste très restrictif : il exige des GPU NVIDIA Blackwell SM100 ou SM103, donc des racks GB200 NVL72 ou GB300 NVL72, ainsi que Python 3.12 ou plus récent, PyTorch 2.10 ou plus récent et CUDA toolkit 13.0 ou plus récent, avec des tampons inter-GPU reposant sur la mémoire symétrique de PyTorch. Les benchmarks de couche ont été menés sur un seul rack NVL72 avec un degré de parallélisme d'experts de 64, chaque GPU traitant 2 048 tokens avant routage, face à quatre baselines (NCCL+PyTorch, DeepEP+PyTorch, DeepEP+TransformerEngine, HybridEP+Megatron) sur des architectures telles que Kimi K2.7 Code, GLM-5.2, Qwen3.5-397B-A17B et DeepSeek-V4-Pro. Cette barrière matérielle élevée signifie que seuls les laboratoires de pointe, les startups de modèles bien financées, les néoclouds GPU et les centres de calcul nationaux peuvent réellement déployer MoK ; les équipes travaillant sur un seul nœud ou huit GPU en sont exclues. Pour ceux qui possèdent la capacité NVL72, l'intérêt est concret : le préentraînement et le post-entraînement de modèles MoE de type DeepSeek-V3, mais aussi le renforcement par apprentissage on-policy et les ablations internes, domaines où le déterminisme du kernel devient un avantage direct pour la reproductibilité des résultats. Les secteurs concernés vont du développement de modèles d'IA à l'infrastructure cloud GPU, en passant par les outils de génération de code et la recherche quantitative. Ce projet prolonge des travaux antérieurs de Cursor sur la partie calcul, avec ses propres kernels d'entraînement MXFP8 et NVFP4 et un chemin d'inférence MoE dit "warp décodé", qui traitaient la communication inter-GPU séparément. En production, cette communication est devenue le vrai goulot d'étranglement, la couche MoE pouvant consommer plus de la moitié du temps total d'entraînement. Le passage aux racks GB300 NVL72, qui regroupent 72 GPU dans un même domaine NVLink mais s'appuient sur des CPU Grace relativement lents, a imposé de minimiser drastiquement les synchronisations CPU-GPU. MoK répond à ce défi par trois choix de conception : une direction de communication adaptée à chaque opération (dispatch en pull, combine en push, la signalisation en pull mesurant 18 microsecondes contre 103 pour le push), une granularité de chevauchement calibrée entre les approches Comet et DeepEP, et un tampon circulaire de tokens de quelques centaines de mégaoctets qui élimine le CPU de la boucle critique.

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.