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

En julio de 2026, investigadores presentaron en arXiv un método que permitió al modelo de lenguaje SmolLM2-1.7B generar código MLIR correcto a la par de modelos 15-34 veces más grandes, sin ajuste fino, gracias a restricciones de decodificación derivadas mecánicamente de las especificaciones de los dialectos.

Por qué MLIR es difícil para los modelos

MLIR (Multi-Level Intermediate Representation) es la representación intermedia sobre la que se sostiene la infraestructura de los compiladores modernos de ML: TensorFlow, JAX/StableHLO, PyTorch Inductor e IREE. Sin embargo, en los corpus de entrenamiento de los modelos de lenguaje, MLIR aparece solo en cantidades ínfimas, por lo que los modelos lo generan mal.

La principal dificultad es la extensibilidad. MLIR está concebido para ampliarse con nuevos "dialectos" para cada dominio de aplicación, y ajustar un modelo distinto para cada dialecto no escala. Los autores plantearon la pregunta: ¿pueden los priors en tiempo de inferencia, derivados mecánicamente de la especificación de operaciones del dialecto (Operation Definition Specification, ODS), sustituir la adaptación mediante ajuste fino por gradiente?

Cómo funcionan las restricciones derivadas de la especificación

El método construye una pila de restricciones de tres capas directamente a partir del esquema del dialecto, sin entrenamiento. Cada capa descarta variantes no válidas ya en la etapa de generación.

• C1 — una gramática libre de contexto (CFG) sobre las firmas de las operaciones
• C2 — partición por tipos a partir de una red de tipos (type lattice) extraída del ODS
• C3 — un validador de ámbito de SSA con rejection sampling y cinco reintentos

Según la anotación en arXiv, trasladar la pila del conjunto de dialectos arith+func+memref+linalg a StableHLO no requirió ni una sola línea de código de restricciones nuevo: el esquema se deriva de la especificación de forma automática.

Cuánto superó un modelo pequeño a los grandes

En los dialectos donde la semántica del verificador está definida por restricciones estructurales, los priors basados en el esquema permitieron que SmolLM2-1.7B igualara o superara a modelos de 15-34B de parámetros. En el dialecto linalg, el modelo alcanzó un 80.0% de programas válidos (promedio de tres semillas, n=125).

• Ventaja frente a CodeLlama-34B, Granite-Code-34B y StarCoder2-15B: de 21 a 44 puntos porcentuales, con intervalos de confianza que no se superponen
• Velocidad de generación: de 8 a 25 veces mayor que la de los grandes modelos base
• Se publicaron 4 benchmarks de NL a MLIR: MLIR-Spec-150, Linalg-Spec-30, StableHLO-Spec-30 y StableHLO-Held-Out-200, en total 410 pares "texto → MLIR"
• Conjuntos de datos bajo licencia Apache-2.0, con datasheets según la metodología de Gebru y metadatos Croissant 1.0
• Se publicaron en acceso abierto los benchmarks, el decodificador, todas las generaciones y una imagen Docker para reproducir los resultados

Pero el método no gana en todos los casos. En arith+func y en el conjunto paramétrico StableHLO-Held-Out-200, donde la corrección depende de los valores de los atributos y no de la estructura del código, los modelos grandes igualaron o superaron al pequeño; los autores marcan honestamente estos casos como "non-win cells".

"Los priors del esquema permiten que

SmolLM2-1.7B iguale o supere a modelos de código de 15-34B con una velocidad de generación de 8 a 25 veces mayor", señala la anotación del estudio en arXiv.

Qué significa esto

Para lenguajes estrechos y estructuralmente rígidos como MLIR, las restricciones derivadas de la especificación pueden sustituir al costoso ajuste fino: un modelo pequeño con los "rieles" correctos supera a uno grande y funciona varias veces más rápido. Esto abarata la generación de código de compiladores y elimina el problema de escalar a cada nuevo dialecto.

Preguntas frecuentes

¿Qué es MLIR?

MLIR (Multi-Level Intermediate Representation) es una representación intermedia de código sobre la que funcionan los compiladores de ML TensorFlow, JAX/StableHLO, PyTorch Inductor e IREE. Se amplía con "dialectos" para tareas concretas.

¿Por qué un modelo de 1.7B superó a uno de 34B?

No recibió ajuste fino, sino restricciones de decodificación derivadas de la especificación del dialecto. En linalg esto produjo un 80.0% de programas válidos, de 21 a 44 puntos más que CodeLlama-34B, Granite-Code-34B y StarCoder2-15B.

¿Dónde no funcionó el método?

En los dialectos arith+func y en el conjunto StableHLO-Held-Out-200, donde la corrección depende de los valores de los atributos y no de la estructura del código. Allí los modelos grandes igualaron o superaron a SmolLM2-1.7B.