SmolLM2-1.7B surpasse des modèles de 34B pour générer du code MLIR, sans fine-tuning

En juillet 2026, des chercheurs ont présenté sur arXiv une méthode qui permet au modèle de langage SmolLM2-1.7B de générer du code MLIR correct, à égalité avec des modèles 15 à 34 fois plus gros. Elle fonctionne sans fine-tuning, grâce à des contraintes de décodage dérivées mécaniquement des spécifications de dialectes.

Pourquoi le MLIR est difficile pour les modèles

MLIR (Multi-Level Intermediate Representation) est la représentation intermédiaire sur laquelle repose l'infrastructure des compilateurs ML modernes : TensorFlow, JAX/StableHLO, PyTorch Inductor et IREE. Or le MLIR n'apparaît qu'à l'état de traces dans les corpus d'entraînement des modèles de langage, ce qui explique leur faiblesse pour le générer.

La principale difficulté tient à son extensibilité. Par conception, MLIR s'enrichit de nouveaux « dialectes » pour chaque domaine d'application, et fine-tuner un modèle distinct pour chaque dialecte ne passe pas à l'échelle. Les auteurs ont posé la question suivante : des priors d'inférence, dérivés mécaniquement de la spécification des opérations d'un dialecte (Operation Definition Specification, ODS), peuvent-ils remplacer l'adaptation par fine-tuning à base de gradients ?

Comment fonctionnent les contraintes issues de la spécification

La méthode construit une pile de contraintes à trois couches directement à partir du schéma du dialecte, sans entraînement. Chaque couche écarte les variantes invalides dès la phase de génération.

• C1 — une grammaire non contextuelle (CFG) portant sur les signatures d'opérations
• C2 — un partitionnement par types à partir d'un treillis de types extrait de l'ODS
• C3 — un validateur de portée SSA, avec rejection sampling et cinq nouvelles tentatives

Selon le résumé publié sur arXiv, le passage de la pile de l'ensemble de dialectes arith+func+memref+linalg à StableHLO n'a pas nécessité une seule ligne de code de contraintes supplémentaire : le schéma est dérivé automatiquement de la spécification.

Dans quelle mesure le petit modèle a battu les grands

Sur les dialectes dont la sémantique du vérificateur repose sur des contraintes structurelles, les priors issus du schéma ont permis à SmolLM2-1.7B d'égaler des modèles de 15 à 34B paramètres, voire de les dépasser. Sur le dialecte linalg, le modèle atteint 80.0 % de programmes valides (moyenne sur trois seeds, n=125).

• Avance sur CodeLlama-34B, Granite-Code-34B et StarCoder2-15B : de 21 à 44 points de pourcentage, avec des intervalles de confiance qui ne se chevauchent pas
• Vitesse de génération : 8 à 25 fois supérieure à celle des grands modèles de base
• 4 benchmarks NL-to-MLIR publiés : MLIR-Spec-150, Linalg-Spec-30, StableHLO-Spec-30 et StableHLO-Held-Out-200, soit 410 paires « texte→MLIR » au total
• Jeux de données sous licence Apache-2.0, avec des datasheets selon la méthodologie de Gebru et des métadonnées Croissant 1.0
• Sont mis en accès libre : les benchmarks, le décodeur, toutes les générations et une image Docker pour la reproduction

Mais la méthode ne l'emporte pas partout. Sur arith+func et sur l'ensemble paramétrique StableHLO-Held-Out-200, où la correction dépend des valeurs des attributs plutôt que de la structure du code, les grands modèles ont égalé le petit ou l'ont devancé. Les auteurs signalent honnêtement ces cas comme des « non-win cells ».

«

Les priors issus du schéma permettent à SmolLM2-1.7B d'égaler des modèles de code de 15 à 34B, voire de les dépasser, avec une vitesse de génération 8 à 25 fois supérieure », indique le résumé de l'étude sur arXiv.

Ce que cela signifie

Pour les langages étroits et structurellement stricts comme MLIR, des contraintes tirées de la spécification peuvent remplacer un fine-tuning coûteux : un petit modèle muni des bons « rails » devance un grand modèle et tourne plusieurs fois plus vite. La génération de code de compilateur devient moins chère, et le problème du passage à l'échelle pour chaque nouveau dialecte disparaît.

Questions fréquentes

Qu'est-ce que MLIR ?

MLIR (Multi-Level Intermediate Representation) est une représentation intermédiaire de code sur laquelle reposent les compilateurs ML TensorFlow, JAX/StableHLO, PyTorch Inductor et IREE. Elle s'étend au moyen de « dialectes » dédiés à des tâches précises.

Pourquoi un modèle de 1.7B a-t-il battu des modèles de 34B ?

Il n'a pas été fine-tuné : il a reçu des contraintes de décodage dérivées de la spécification du dialecte. Sur linalg, cela a donné 80.0 % de programmes valides, soit 21 à 44 points de plus que CodeLlama-34B, Granite-Code-34B et StarCoder2-15B.

Où la méthode n'a-t-elle pas fonctionné ?

Sur les dialectes arith+func et sur l'ensemble StableHLO-Held-Out-200, où la correction dépend des valeurs des attributs plutôt que de la structure du code. Dans ces cas, les grands modèles ont égalé SmolLM2-1.7B ou l'ont devancé.