Mémoire KV virtualisée sur GPU grand public, MoE allégés sans entraînement, code en une étape : l’inférence 2026 joue sur tous les fronts

💡 En résumé

• KVMem virtualise l’historique des agents : l’état KV qui déborde de la fenêtre de contexte n’est plus résumé ni re-préfillé, mais paginé à travers mémoire GPU, RAM hôte et NVMe — un espace de travail d’un million de tokens sur un GPU grand public.
• PlaidQ, un modèle de diffusion continu de 0,7B, écrit du code en une seule étape de débruitage — la génération séquentielle token par token n’est plus la seule voie.
• Les MoE se passent d’entraînement pour être allégés : réduire le nombre d’experts activés de Qwen3.6-35B-A3B à l’inférence sans rien réentraîner, et un avertissement sur le pruning d’experts quand le load-balancing a trop bien réparti les routes.
• MaxKernel délègue l’écriture de kernels TPU à un système multi-agents avec retour compilateur temps réel ; SharedSAE partage un dictionnaire de features entre plusieurs modèles ; Mitra-v2, fondation tabulaire 100 % synthétique, monte sur le podium de TabArena.

Le batch cs.LG du lundi 7 septembre 2026 est un condensé de la bataille d’inférence : la même semaine où les labos annoncent des datacenters toujours plus vastes, la recherche publique attaque l’autre bout de la chaîne — faire tenir des charges de travail d’agents sur du matériel modeste, tailler les modèles sans les réentraîner, et compresser la trajectoire de génération elle-même.

🔥 Tendances

KVMem : la mémoire des agents s’affranchit de la fenêtre de contexte

KVMem (arXiv:2609.04852) s’attaque au problème le plus concret de l’agentique en production : les agents travaillent dans des espaces persistants dont l’historique accumulé dépasse à la fois la capacité KV du GPU et la fenêtre de contexte native du modèle. Les solutions actuelles compactent l’ancien contexte en résumés ou le re-requêtent plus tard sous forme de texte — perdant des preuves d’exécution fines, ou re-préfillant sans cesse du contenu déjà traité.

L’approche de KVMem est la virtualisation : l’historique débordant est conservé comme état KV paginé, réparti entre mémoire GPU, mémoire hôte et NVMe. Un index léger, natif au modèle et basé sur l’espace d’attention, sélectionne l’historique pertinent quand l’agent en a besoin — sans jamais re-préfiller le contenu déjà vu. L’effet annoncé est un espace de travail d’un million de tokens sur un GPU consommateur, ce qui change la donne pour l’agentique locale : un agent ne devrait plus avoir à choisir entre oublier ce qu’il a fait et posséder un datacenter. C’est, avec des moyens différents, la même philosophie que les systèmes de gestion mémoire des OS — la pagination appliquée aux états d’attention.

PlaidQ : la génération de code en une étape de débruitage

PlaidQ (arXiv:2609.04531) appartient à la famille des modèles de langue à diffusion continue, qui remplacent l’émission séquentielle de tokens par une trajectoire de raffinements itératifs. La nouveauté : un modèle de 0,7B pour la génération de code dont la trajectoire peut être distillée jusqu’à quelques étapes de débruitage — ou une seule. PlaidQ recycle un modèle autorégressif pré-entraîné en débruteur bidirectionnel sur des embeddings continus, puis distille la trajectoire. La génération de code cesse d’être fondamentalement séquentielle : le parallélisme par lots d’étapes de débruitage indépendantes ouvre la voie à des latences et des débits que l’autorégression ne peut pas atteindre. À 0,7B, l’ambition affichée est l’inférence edge et temps réel — et la confirmation que la diffusion, longtemps cantonnée aux gros modèles, descend en gamme de paramètres.

🤖 Nouveaux outils

Les MoE se taillent à l’inférence, sans entraînement

Deux papiers complémentaires redéfinissent la flexibilité des Mixtures of Experts. Le premier, Training-Free Halving of Activated Experts (arXiv:2609.04575), part d’une observation fine : quand un MoE fine-grained route chaque token vers un petit nombre d’experts puis renormalise les probabilités du routeur, cette renormalisation calibre implicitement le gain de sortie des experts sur le top-k d’entraînement. Réduire k à l’inférence ne change donc pas seulement quels experts sont utilisés — il change la force de la branche experte. Les auteurs séparent les deux effets en activant les top-k₁ experts tout en normalisant par la masse de probabilité des top-k₂ : un seul entier, sans paramètre, sans entraînement, sans surcoût de calcul mesurable. Sur Qwen3.6-35B-A3B, réduire de moitié les experts activés… tient la qualité tout en allégeant le service. Une technique de mise à l’échelle élastique à la volée — précieuse pour adapter un modèle à la charge du moment.

Le second, When Load-Balancing Goes Too Far (arXiv:2609.04453), est un avertissement sur le pruning d’experts. La pratique courante retire les experts « de faible importance » identifiés par le routeur — en supposant que les probabilités du routeur sont un signal d’importance fiable. Or ce postulat casse sous routage over-dispersé, le régime associé au load-balancing agressif pendant l’entraînement : les tokens sont répartis presque uniformément et les signaux d’importance s’effondrent. Le résultat le plus piégeux : dans ce régime, la perplexité ne prédit pas la qualité sur tâche — sur gpt-oss-20B, la configuration de pruning à la meilleure perplexité donne les pires performances en aval. Le load-balancing, fait pour l’entraînement, devient un piège pour la compression : à mesure que les MoE fine-grained se généralisent, l’industrie va devoir réapprendre quels signaux font foi pour tailler un modèle.

MaxKernel : des kernels TPU écrits par des agents

MaxKernel (arXiv:2609.04523) pousse la génération de kernels à un niveau supérieur : un système multi-agents qui implémente trois paradigmes de développement de kernels pour TPU — un agent human-in-the-loop pour la conception collaborative pas à pas, un agent autonome qui exécute une boucle d’optimisation entièrement automatisée pilotée par métriques et traces, et un paradigme basé graphe. Le retour du compilateur en temps réel est utilisé comme signal d’apprentissage — la même boucle « écrire, compiler, mesurer, corriger » qui a fait le succès des agents de kernels GPU s’applique aux TPU, dont l’écosystème d’outillage est plus jeune. Pour les équipes MLOps, la promesse est double : démocratiser l’écriture de kernels haute performance sans expertise hardware profonde, et automatiser l’optimisation de code bas niveau qui restait un métier d’artisan.

SharedSAE : un dictionnaire de features pour tous les modèles

SharedSAE (arXiv:2609.04344) répond à un gaspillage de l’interprétabilité : les auto-encodeurs sparse (SAE) sont entraînés et leurs features labellisées séparément pour chaque modèle. SharedSAE montre qu’un dictionnaire partagé unique peut remplacer la collection de SAE dédiés, en combinant le dictionnaire commun avec des paires encodeur-décodeur spécifiques à chaque modèle. La différence clé avec la méthode la plus proche : SharedSAE préserve les magnitudes d’activation (au lieu de les jeter) et utilise le model dropout pour l’inférence mono-modèle. Un dictionnaire de features universel, labellisé une fois, ouvrirait la voie à des atlas de features comparables entre générations de modèles — l’interprétabilité comme bien commun plutôt que comme artefact par modèle.

Mitra-v2 : le fondation tabulaire 100 % synthétique

Mitra-v2 (arXiv:2609.04540) consolide la tendance des fondations tabulaires : entraîné uniquement sur données synthétiques, avec une distribution de pré-entraînement bien plus large et diverse que Mitra-v1, ce petit Transformer 2D à backbone supporte des contextes plus longs et de plus grands espaces de features. Les domaines visés sont ceux où les données sont rares et sensibles — score de crédit, prédiction clinique, détection de panne d’équipement, estimation de prix immobilier — et les résultats annoncés le placent en tête de TabArena sur la classification et la régression réelles. L’entraînement synthétique comme parade aux données tabulaires sensibles (médical, finance) est une thèse qui prend de l’épaisseur run après run.

📊 Analyse

La mémoire est devenue le goulot — et la cible

Le fil rouge du run est la mémoire, sous toutes ses formes : la mémoire KV des agents (KVMem), la mémoire d’état récurrente sous quantification (arXiv:2609.04490 — le write-back d’état récurrent en inférence temporelle basse précision montre que la règle de stockage de l’état quantifié peut altérer les calculs suivants), la mémoire des optimiseurs (Muon et SOAP contre AdamW sur l’axe du sur-entraînement, arXiv:2609.04577). Cette convergence dit quelque chose de simple : la génération suivante de gains d’inférence ne viendra plus des FLOPs, mais de la gestion de ce que le modèle doit retenir — et de la décision de ce qu’il peut oublier.

Le papier sur les optimiseurs mérite une mention : sur l’axe du sur-entraînement (overtraining), les performances relatives des optimiseurs et leurs hyperparamètres optimaux changent substantiellement avec l’horizon d’entraînement — jusqu’à inverser la schedule de learning rate préférée. Alors que l’industrie sur-entraîne ses modèles de plus en plus longtemps, les recettes d’optimisation apprises sur des entraînements courts pourraient ne plus s’appliquer — un sujet discret mais coûteux.

La bataille des paradigmes de génération s’intensifie

PlaidQ n’est pas isolé : la diffusion de langage « distillé en peu d’étapes » attaque l’autorégression sur son terrain le plus rentable, la génération de code. Combinée aux MoE élastiques et aux kernels agentiques, elle dessine une inférence moins séquentielle, plus parallélisable et plus adaptable à la charge — exactement les propriétés que recherchent les serveurs d’inférence qui facturent à la latence. Les prochains runs diront si la diffusion passe le cap des petits modèles de code vers les modèles généraux ; la direction, elle, est prise.

🎯 À retenir

• KVMem virtualise l’état KV des agents (GPU + RAM + NVMe, index natif au modèle) : un million de tokens d’historique sur GPU grand public, sans résumé ni re-prefill — un levier direct pour l’agentique locale.
• PlaidQ (0,7B) distille la diffusion de langage jusqu’à une seule étape pour le code : la génération séquentielle n’est plus une fatalité.
• MoE élastiques sans entraînement : diviser par deux les experts activés de Qwen3.6-35B-A3B tient la qualité ; mais gare au pruning quand le load-balancing a trop uniformisé les routes (la perplexité ne prédit plus rien sur gpt-oss-20B).
• MaxKernel (kernels TPU par agents), SharedSAE (dictionnaire de features partagé) et Mitra-v2 (fondation tabulaire synthétique) confirment : l’inférence et l’interprétabilité s’industrialisent couche par couche.
• À surveiller : la mémoire comme prochaine frontière d’optimisation — état KV, état récurrent quantifié, mémoire des optimiseurs — et l’inversion des recettes d’optimisation quand les entraînements s’allongent.