TinyLoRA : une méthode d'affinage à 13 paramètres qui atteint 91,8 % sur GSM8K avec Qwen2.5-7B

Nous Research publie une méthode d'entraînement par superposition de tokens qui accélère le pré-entraînement des LLM jusqu'à 2,5x pour des modèles de 270M à 10B paramètres

Nous Research vient de publier Token Superposition Training (TST), une méthode qui réduit significativement le temps de pré-entraînement des grands modèles de langage sans toucher à leur architecture, leur optimiseur, leur tokenizer ni leur stratégie de parallélisme. Les gains mesurés sont substantiels : à l'échelle d'un modèle MoE (mixture d'experts) de 10 milliards de paramètres avec 1 milliard actifs, TST atteint une perte d'entraînement finale inférieure à celle d'une baseline équivalente en FLOPs, tout en consommant 4 768 heures-GPU B200 contre 12 311 pour la baseline, soit une réduction d'environ 2,5x du temps total. La méthode a été validée à quatre échelles : 270 millions et 600 millions de paramètres denses, 3 milliards (architecture SmolLM3), et le MoE 10B-A1B de la famille Qwen3. Toutes les expériences ont été conduites sur 64 GPU NVIDIA B200 via TorchTitan, en utilisant les jeux de données DCLM et FineWeb-Edu. TST fonctionne en deux phases séquentielles. Durant la première phase dite de superposition, qui représente entre 20 % et 40 % du total des étapes d'entraînement, le modèle ne traite pas des tokens individuels mais des groupes de tokens contigus. Dans la couche d'embedding, chaque groupe de s tokens est fusionné en un unique vecteur latent par moyennage des embeddings, permettant au transformer de traiter une séquence s fois plus courte et d'ingérer ainsi s fois plus de texte par unité de calcul. Une fonction de perte spécifique, la multi-hot cross-entropy, remplace la cross-entropy standard pour prédire simultanément le groupe de tokens suivant, et peut s'implémenter avec les noyaux de calcul déjà présents dans les bibliothèques d'entraînement existantes, sans écrire de code CUDA personnalisé. Dans la seconde phase de récupération, l'entraînement reprend avec la prédiction classique token par token. Un pic de perte transitoire de 1 à 2 nats apparaît à la transition mais se résorbe en quelques milliers de pas. Le modèle produit est architecturalement identique à un modèle entraîné de façon conventionnelle. L'enjeu derrière cette publication est considérable : le pré-entraînement des LLMs représente l'un des postes de coût les plus lourds de l'industrie, et les régimes actuels poussent déjà bien au-delà des estimations compute-optimales. Réduire ce coût d'un facteur 2,5 sans dégrader la qualité finale du modèle ouvre des perspectives importantes, notamment pour les laboratoires aux ressources limitées. TST s'inscrit dans une tendance plus large visant à améliorer le débit de données par FLOP dépensé, dans la lignée des tokenizers sous-mots BPE qui compressent déjà les séquences. Nous Research, connu pour ses modèles Hermes et ses travaux sur l'alignement et le fine-tuning, signe ici une contribution orientée fondations, avec une implémentation conçue pour s'intégrer directement dans les pipelines de pré-entraînement existants. Le papier accompagnant la publication est disponible sur arXiv (2605.06546).

MiniMax Sparse Attention (MSA) : attention block-sparse à deux branches pour un MoE de 109 milliards de paramètres

MiniMax a publié MSA (MiniMax Sparse Attention), une nouvelle méthode d'attention parcimonieuse construite sur la base de l'architecture Grouped Query Attention (GQA). L'équipe de recherche l'a intégrée et testée dans un modèle Mixture-of-Experts de 109 milliards de paramètres, entraîné sur un budget de 3 000 milliards de tokens avec des données multimodales natives. Le résultat concret est MiniMax-M3, un modèle de production désormais disponible, accompagné d'un noyau d'inférence publié en open source. Le principe de MSA repose sur deux étapes : une branche Index qui sélectionne les blocs de tokens clé-valeur pertinents pour chaque requête, et une branche Principale qui applique l'attention softmax exacte uniquement sur ces blocs sélectionnés. Chaque requête consulte 16 blocs de 128 tokens, soit un budget fixe de 2 048 tokens clé-valeur, quelle que soit la longueur du contexte. Un noyau optimisé rend cette sélection 5,1 fois plus rapide que torch.topk à 128 000 tokens de contexte, et 3,7 fois plus rapide que le noyau radix-select de TileLang. L'enjeu technique est direct : l'attention standard en softmax a un coût quadratique par rapport à la longueur du contexte, ce qui signifie que doubler la fenêtre de contexte quadruple le coût de calcul. MSA court-circuite ce problème en fixant le coût par requête à O(kBk), indépendamment de la taille du contexte, là où l'attention GQA dense maintient un coût en O(N). Pour les modèles qui traitent des documents longs, du code étendu ou des corpus multimodaux, cela représente un gain concret en vitesse et en coût d'inférence. La méthode préserve par construction le contexte local immédiat de chaque requête, un bloc local étant toujours inclus dans la sélection, tout en permettant aux différents groupes d'attention de couvrir des régions éloignées du contexte de manière indépendante. La course aux longues fenêtres de contexte est l'un des fronts les plus actifs du développement des grands modèles de langage en 2025 et 2026. Plusieurs laboratoires, dont Anthropic, Google DeepMind et Meta, ont publié des travaux sur des architectures d'attention efficaces pour dépasser les 100 000 tokens. MiniMax, entreprise chinoise fondée en 2021 et valorisée à plusieurs milliards de dollars, s'impose ici avec une approche originale : plutôt que de remplacer l'attention, MSA la raffine de l'intérieur en greffant la sélection parcimonieuse sur GQA sans modifier l'architecture principale. Deux modes d'entraînement sont proposés, soit un départ depuis zéro (MSA-PT, après 40 milliards de tokens de préchauffage), soit une conversion d'un checkpoint dense entraîné sur 2 600 milliards de tokens (MSA-CPT, suivi de 400 milliards de tokens supplémentaires), ce qui facilite l'adoption par des équipes disposant déjà de modèles en production.

Optimiser la sélection des modules cibles LoRA pour un affinage efficace

Le fine-tuning de grands modèles de langage consomme des ressources GPU considérables, mais une technique appelée LoRA (Low-Rank Adaptation) permet de réduire drastiquement ces coûts. Plutôt que de mettre à jour l'ensemble des paramètres d'un modèle, LoRA gèle les poids d'origine et insère de petites matrices légères, appelées adaptateurs, dans des sous-couches spécifiques. Une nouvelle étude d'ablation publiée par des chercheurs d'Amazon apporte des réponses concrètes à une question centrale : où exactement placer ces adaptateurs pour maximiser l'efficacité sans sacrifier la précision ? L'enjeu est loin d'être théorique. Le choix des modules cibles influence directement la latence d'inférence, la consommation mémoire et les coûts d'entraînement. Cibler trop de modules améliore les performances mais alourdit le système ; en choisir trop peu risque de brider la capacité d'adaptation du modèle. Trouver le bon équilibre est donc critique pour les entreprises qui déploient des modèles personnalisés à grande échelle, notamment dans des contextes de serving à la demande ou de partage de modèle de base entre plusieurs GPU. En utilisant le modèle multimodal Amazon Nova 2.0 Lite comme base, les chercheurs Rushil Anirudh, Anjie Fang et Bhoomit Vasani ont mené une étude systématique de l'impact de chaque module de l'architecture Transformer. Leur conclusion est nette : le module o_proj, une transformation linéaire qui fusionne les représentations issues des différentes têtes d'attention en une forme cohérente pour le reste du modèle, offre le meilleur compromis efficacité/précision lorsqu'un seul adaptateur est utilisé. Ce module s'avère donc être le point d'insertion optimal pour la grande majorité des cas d'usage clients. Ces résultats ouvrent la voie à des configurations standardisées de LoRA qui pourraient s'appliquer sans ajustement manuel à un large spectre de tâches. Pour les équipes ML déployant des dizaines de modèles spécialisés, disposer d'une configuration par défaut validée empiriquement représente un gain opérationnel significatif, réduisant à la fois le temps de configuration et les coûts d'infrastructure liés à l'entraînement et à l'inférence.

Trajectory publie une pile d'entraînement Multi-LoRA concurrent pour l'apprentissage continu, avec un gain de débit de 2,81x

Trajectory, en collaboration avec le UC Berkeley Sky Lab et Anyscale, a publié un rapport technique détaillant une nouvelle infrastructure d'entraînement baptisée C-LoRA (Continuous Multi-LoRA Training), dont le code est entièrement disponible dans le dépôt GitHub NovaSky-AI/SkyRL. Le système permet de faire tourner plusieurs expériences d'entraînement en parallèle sur un même moteur d'inférence, chaque expérience disposant de son propre adaptateur LoRA dédié. Les résultats annoncés sont significatifs : un gain de débit expérimental de 2,81x par rapport à un framework d'entraînement classique à locataire unique, sans régression observée sur les récompenses d'entraînement. Les tests ont été conduits sur un nœud H200 unique avec le modèle Qwen3-4B-Instruct-2507, appliqué à des tâches d'apprentissage par renforcement sur GSM8K reformulées en usage d'outils. Ce gain de performance cible un problème structurel de l'industrie : la quasi-totalité des infrastructures d'entraînement actuelles repose encore sur un cycle linéaire, collecte de données, entraînement, déploiement, qui prend des mois et produit des sauts discontinus de comportement pour les utilisateurs. C-LoRA vise à remplacer ce cycle par un apprentissage continu nourri des interactions de production en temps réel. L'architecture s'attaque concrètement à quatre inefficacités identifiées : les démarrages à froid coûteux (pouvant dépasser 30 minutes pour les grands modèles), la consommation mémoire excessive de l'apprentissage par renforcement sur des modèles de plus de 100 milliards de paramètres comme Qwen3.5-397B (qui peut nécessiter jusqu'à huit nœuds H200), la limitation à une seule expérience à la fois des stacks traditionnels, et la faible utilisation des GPU due aux temps d'attente mutuels entre le module d'entraînement et le moteur d'inférence. L'intérêt plus large de ce travail s'inscrit dans une tendance de fond : rendre les modèles de langage capables d'apprendre en continu à partir de corrections humaines, de patterns observés en production, ou de retours d'opérateurs, sans nécessiter un cycle de réentraînement complet. La technique LoRA, qui gèle les poids du modèle de base et n'entraîne que de petits adaptateurs, réduit la consommation mémoire d'un ordre de grandeur tout en permettant la coexistence de plusieurs expériences simultanées. Côté inférence, le noyau SGMV de vLLM fusionne les opérations par adaptateur en un seul lancement GPU par étape de décodage, ce qui permet de mixer des tokens issus d'adaptateurs différents dans un même batch. Côté entraînement, la concurrence reste encore limitée à un adaptateur actif à la fois, les autres résidant en mémoire CPU, une limitation que Trajectory reconnaît et qui constitue la prochaine frontière technique pour l'équipe.

💬 2,81x de débit en plus sur un nœud H200, c'est pas rien. Ce qui m'intéresse surtout, c'est pas le chiffre, c'est l'architecture : faire tourner plusieurs expériences LoRA en parallèle sur le même moteur d'inférence, ça s'attaque enfin au vrai problème, ce cycle collect-train-deploy qui prend des mois et rend les mises à jour du modèle quasi invisibles pour les utilisateurs. Bon, sur le papier, parce que l'entraînement reste limité à un seul adaptateur actif à la fois pour l'instant, ce qui relativise un peu le "continu" dans le nom.