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

Em julho de 2026, pesquisadores apresentaram no arXiv um método que permitiu ao modelo de linguagem SmolLM2-1.7B gerar código MLIR correto no mesmo nível de modelos 15-34 vezes maiores — sem fine-tuning, graças a restrições de decodificação derivadas mecanicamente das especificações dos dialetos.

Por que o MLIR é difícil para os modelos

O MLIR (Multi-Level Intermediate Representation) é a representação intermediária sobre a qual se apoia a infraestrutura dos compiladores modernos de ML: TensorFlow, JAX/StableHLO, PyTorch Inductor e IREE. No entanto, nos corpora de treinamento dos modelos de linguagem, o MLIR aparece apenas em quantidades ínfimas, por isso os modelos o geram mal.

A principal dificuldade é a extensibilidade. O MLIR foi concebido para ser expandido com novos "dialetos" para cada domínio de aplicação, e fazer fine-tuning de um modelo separado para cada dialeto não escala. Os autores levantaram a pergunta: os priors em tempo de inferência, derivados mecanicamente da especificação de operações do dialeto (Operation Definition Specification, ODS), podem substituir a adaptação via fine-tuning por gradiente?

Como funcionam as restrições derivadas da especificação

O método constrói uma pilha de restrições em três camadas diretamente a partir do esquema do dialeto, sem treinamento. Cada camada descarta variantes inválidas já na etapa de geração.

• C1 — uma gramática livre de contexto (CFG) sobre as assinaturas das operações
• C2 — particionamento por tipos a partir de uma rede de tipos (type lattice) extraída do ODS
• C3 — um validador de escopo SSA com rejection sampling e cinco novas tentativas

Segundo a anotação no arXiv, transferir a pilha do conjunto de dialetos arith+func+memref+linalg para o StableHLO não exigiu nenhuma linha de código de restrição nova — o esquema é derivado automaticamente da especificação.

O quanto um modelo pequeno superou os grandes

Nos dialetos em que a semântica do verificador é definida por restrições estruturais, os priors baseados em esquema permitiram que o SmolLM2-1.7B igualasse ou superasse modelos com 15-34B de parâmetros. No dialeto linalg, o modelo atingiu 80.0% de programas válidos (média de três seeds, n=125).

• Vantagem sobre CodeLlama-34B, Granite-Code-34B e StarCoder2-15B — de 21 a 44 pontos percentuais, com intervalos de confiança que não se sobrepõem
• Velocidade de geração — de 8 a 25 vezes maior que a dos grandes modelos de base
• Foram lançados 4 benchmarks de NL para MLIR: MLIR-Spec-150, Linalg-Spec-30, StableHLO-Spec-30 e StableHLO-Held-Out-200 — 410 pares "texto → MLIR" no total
• Datasets sob licença Apache-2.0, com datasheets seguindo a metodologia de Gebru e metadados Croissant 1.0
• Foram disponibilizados em acesso aberto os benchmarks, o decodificador, todas as gerações e uma imagem Docker para reprodução

Mas o método não vence em todos os casos. Em arith+func e no conjunto paramétrico StableHLO-Held-Out-200, onde a corretude depende dos valores dos atributos, e não da estrutura do código, os modelos grandes igualaram ou superaram o pequeno — os autores marcam honestamente esses casos como "non-win cells".

"Os priors de esquema permitem que o

SmolLM2-1.7B iguale ou supere modelos de código de 15-34B com velocidade de geração 8-25 vezes maior", afirma a anotação do estudo no arXiv.

O que isso significa

Para linguagens estreitas e estruturalmente rígidas como o MLIR, restrições derivadas da especificação podem substituir o caro fine-tuning: um modelo pequeno com os "trilhos" certos supera um modelo grande e funciona muitas vezes mais rápido. Isso barateia a geração de código de compiladores e elimina o problema de escalar para cada novo dialeto.

Perguntas frequentes

O que é o MLIR?

O MLIR (Multi-Level Intermediate Representation) é uma representação intermediária de código sobre a qual funcionam os compiladores de ML TensorFlow, JAX/StableHLO, PyTorch Inductor e IREE. Ele é expandido com "dialetos" para tarefas específicas.

Por que um modelo de 1.7B superou um modelo de 34B?

Ele não passou por fine-tuning — em vez disso, recebeu restrições de decodificação derivadas da especificação do dialeto. No linalg, isso gerou 80.0% de programas válidos — de 21 a 44 pontos a mais do que CodeLlama-34B, Granite-Code-34B e StarCoder2-15B.

Onde o método não funcionou?

Nos dialetos arith+func e no conjunto StableHLO-Held-Out-200, onde a corretude depende dos valores dos atributos, e não da estrutura do código. Ali, os modelos grandes igualaram ou superaram o SmolLM2-1.7B.