LIMe économise 15 % de calcul, un LLM vocal de NVIDIA perd 57,5 Go

LIMe : le calcul perdu vient de l'attention

À EMNLP 2026, en Hongrie, des chercheurs de T-Tech ont présenté LIMe. Leur point de départ n'est pas une astuce d'optimisation mais un constat architectural : dans un Transformer classique, chaque couche ne dépend que de l'état caché de la couche précédente. Cette dépendance en chaîne a un effet secondaire — elle pousse les tokens à se ressembler, ce qui dégrade le modèle.

La réponse de LIMe tient dans une extension du mécanisme d'attention, à laquelle les chercheurs ajoutent des poids de routage. Le gain annoncé : environ 15 % de calcul d'entraînement en moins, sans compromettre la qualité du modèle. Rapporté à l'échelle d'un run d'entraînement, 15 % ne sont pas une décimale : c'est de la durée de calcul, de la mémoire et des heures de grappe en moins.

La dépêche ne précise ni la taille des modèles testés, ni le protocole de mesure du gain. Le résultat est donc à prendre pour ce qu'il est : une annonce de conférence, avec les questions qui vont avec.

Élaguer plutôt que réentraîner : 67,5 Go ramenés à 10 Go

Sur r/LocalLLaMA, un utilisateur indique avoir élagué le nouveau LLM vocal 30B de NVIDIA de 67,5 Go à 10 Go, sans réentraînement. Le modèle compressé transcrit avec un WER de 5,16 %, contre 4,12 % pour le modèle enseignant. Autrement dit : la taille fond de près de 57,5 Go, et le taux d'erreur sur les mots augmente d'un peu plus d'un point.

Le point intéressant n'est pas la compression en soi, mais le fait qu'elle se passe de réentraînement. On garde les poids, on en retire une partie, et le modèle continue de transcrire. Le prix est connu et mesuré : un WER qui passe de 4,12 % à 5,16 %.

Il s'agit d'un retour d'utilisateur publié sur un forum, pas d'un résultat de conférence. Les conditions du test — jeu de données, langue, matériel — ne figurent pas dans la dépêche.

Hermes Agent : deux canary en deux jours, sans note de version

Le projet Hermes Agent, porté par NousResearch, a mis en ligne deux builds canary estampillées v0.22.5. La première est datée du 28 octobre 2026 à 06:48 UTC (v0.22.5+canary.20261028T064834Z), la seconde du 29 octobre 2026 (v0.22.5+canary.20261029T064840Z).

Le canal canary correspond aux versions de test diffusées avant une publication stable. Sur les deux publications, la note de version ne détaille aucun changement : ni correctif, ni fonctionnalité, ni liste de commits. Seul l'horodatage distingue les deux builds.

Pour qui suit le projet, l'information se limite donc au rythme de publication : deux canary consécutives sur la même version mineure, à vingt-quatre heures d'intervalle.

Trois signaux, trois niveaux de confiance

Les trois dépêches ont un point commun — réduire le coût d'un modèle — mais elles ne pèsent pas pareil.

• LIMe : un résultat présenté à EMNLP 2026, avec un chiffre unique (environ 15 %) et un mécanisme décrit.
• L'élagage du 30B vocal : un retour d'utilisateur sur un forum, avec deux WER comparés et une méthode.
• Hermes Agent : deux publications de suivi sur un dépôt GitHub, sans contenu technique associé.

Relier ces trois items serait tentant, mais artificiel : aucun ne cite l'autre, et rien n'indique qu'ils partagent une méthode ou un code. Ce qui les rapproche est ailleurs, dans la question qu'ils posent tous les trois : combien de calcul et de gigaoctets peut-on retirer avant que la qualité ne suive la pente ?

Et maintenant ?

Deux familles d'économies se dessinent : jouer sur l'architecture et l'entraînement en amont, ou compresser un modèle déjà entraîné en aval. LIMe attaque la première, l'élagage du modèle vocal de NVIDIA illustre la seconde, et les deux annoncent un coût mesuré — 15 % de calcul d'un côté, un point de WER de l'autre. Reste à savoir ce que valent ces chiffres hors de leur contexte d'annonce : ni le protocole de LIMe ni les conditions du test d'élagage ne sont détaillés dans les dépêches.