SmolLM2-1.7B обгоняет модели на 34B в генерации MLIR-кода без дообучения

En juillet 2026, des chercheurs ont présenté sur arXiv une méthode qui a permis au modèle de langage SmolLM2-1.7B de générer du code MLIR correct au même niveau que des modèles 15 à 34 fois plus grands — sans fine-tuning, grâce à des contraintes de décodage dérivées mécaniquement des spécifications des dialectes.

Pourquoi 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, dans les corpus d'entraînement des modèles de langage, MLIR n'apparaît qu'en quantités infimes, si bien que les modèles le génèrent mal.

La principale difficulté est l'extensibilité. MLIR est conçu pour être étendu par de nouveaux « dialectes » pour chaque domaine d'application, et faire du fine-tuning d'un modèle distinct pour chaque dialecte ne passe pas à l'échelle. Les auteurs ont posé la question : des priors en temps d'inférence, dérivés mécaniquement de la spécification des opérations du dialecte (Operation Definition Specification, ODS), peuvent-ils remplacer l'adaptation par fine-tuning par gradient ?

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 élimine les variantes invalides dès l'étape de génération.

• C1 — une grammaire hors contexte (CFG) sur les signatures des 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 l'annotation sur arXiv, le portage de la pile de l'ensemble de dialectes arith+func+memref+linalg vers StableHLO n'a nécessité aucune ligne de code de contrainte supplémentaire — le schéma est dérivé automatiquement de la spécification.

Dans quelle mesure un petit modèle a devancé les grands

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

• Avantage 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 — de 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 — 410 paires « texte → MLIR » au total
• Jeux de données sous licence Apache-2.0, avec des datasheets suivant la méthodologie de Gebru et des métadonnées Croissant 1.0
• Les benchmarks, le décodeur, toutes les générations et une image Docker pour la reproduction ont été publiés en accès libre

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 et non de la structure du code, les grands modèles ont égalé ou dépassé le petit — les auteurs signalent honnêtement ces cas comme des « non-win cells ».

«

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

Ce que cela signifie

Pour des langages étroits et structurellement stricts comme MLIR, les contraintes issues de la spécification peuvent remplacer un fine-tuning coûteux : un petit modèle doté des bons « rails » devance un grand modèle et fonctionne plusieurs fois plus vite. Cela réduit le coût de la génération de code de compilateur et supprime le problème de mise à l'échelle pour chaque nouveau dialecte.

Questions fréquentes

Qu'est-ce que MLIR ?

MLIR (Multi-Level Intermediate Representation) est une représentation intermédiaire de code sur laquelle fonctionnent les compilateurs ML TensorFlow, JAX/StableHLO, PyTorch Inductor et IREE. Il s'étend par des « dialectes » pour des tâches spécifiques.

Pourquoi un modèle de 1.7B a-t-il devancé un modèle de 34B ?

Il n'a pas été fine-tuné, mais 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 — de 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 et non de la structure du code. Là, les grands modèles ont égalé ou dépassé SmolLM2-1.7B.