SmolLM2-1.7B supera a modelos de 34B en generación de código MLIR sin ajuste fino

En julio de 2026, un grupo de investigadores presentó en arXiv un método que permite a un modelo de lenguaje como SmolLM2-1.7B generar código MLIR correcto a la par de modelos entre 15 y 34 veces más grandes. No requiere ajuste fino: se basa en restricciones de decodificación derivadas de forma mecánica de las especificaciones de los dialectos.

Por qué MLIR se les resiste a los modelos

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

La principal dificultad es la extensibilidad. MLIR está concebido para crecer con nuevos «dialectos» para cada dominio de aplicación, y ajustar un modelo distinto para cada dialecto no escala. Los autores se plantearon una pregunta: ¿pueden los priors en tiempo de inferencia, derivados de forma mecánica 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 las variantes inválidas ya durante la generación.

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

Según el resumen publicado 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 nuevo de restricciones: el esquema se deriva de la especificación de forma automática.

Hasta dónde llegó el modelo pequeño frente a los grandes

En los dialectos donde la semántica del verificador se define mediante restricciones estructurales, los priors de esquema permitieron a SmolLM2-1.7B igualar o superar a modelos de entre 15 y 34B parámetros. En el dialecto linalg, el modelo alcanzó un 80.0% de programas válidos (media de tres semillas, n=125).

• Ventaja sobre CodeLlama-34B, Granite-Code-34B y StarCoder2-15B: de 21 a 44 puntos porcentuales, con intervalos de confianza que no se solapan
• Velocidad de generación: de 8 a 25 veces superior a la de los modelos base de mayor tamaño
• Se publicaron 4 benchmarks NL-to-MLIR: MLIR-Spec-150, Linalg-Spec-30, StableHLO-Spec-30 y StableHLO-Held-Out-200, con un total de 410 pares «texto→MLIR»
• Los conjuntos de datos tienen licencia Apache-2.0, con datasheets según la metodología de Gebru y metadatos Croissant 1.0
• Se liberaron en abierto los benchmarks, el decodificador, todas las generaciones y una imagen Docker para reproducir los resultados

Pero el método no gana en todas partes. 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 al pequeño o lo superaron. Los autores señalan con honestidad estos casos como «non-win cells».

«Los priors de esquema permiten a

SmolLM2-1.7B igualar o superar a modelos de código de 15-34B con una velocidad de generación de 8 a 25 veces mayor», señala el resumen del estudio en arXiv.

Qué significa

Para lenguajes estrechos y de estructura estricta como MLIR, las restricciones derivadas de la especificación pueden sustituir al costoso ajuste fino: un modelo pequeño con los «raíles» adecuados supera a uno grande y funciona varias veces más rápido. Esto abarata la generación de código de compilador y elimina el problema de escalar el enfoque 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 de TensorFlow, JAX/StableHLO, PyTorch Inductor e IREE. Se amplía mediante «dialectos» para tareas concretas.

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

No se ajustó con datos adicionales: recibió restricciones de decodificación derivadas de la especificación del dialecto. En linalg, eso se tradujo en un 80.0% de programas válidos, entre 21 y 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 a SmolLM2-1.7B o lo superaron.