SmolLM2-1.7B supera modelos de 34B na geração de código MLIR sem ajuste fino

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 nível de modelos de 15 a 34 vezes maiores. O método dispensa ajuste fino e se apoia em 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 que sustenta a infraestrutura dos compiladores de ML modernos: TensorFlow, JAX/StableHLO, PyTorch Inductor e IREE. Nos corpora de treinamento dos modelos de linguagem, porém, o MLIR aparece apenas em quantidades residuais, e por isso os modelos o geram mal.

O principal obstáculo é a extensibilidade. Por projeto, o MLIR cresce com novos "dialetos" para cada domínio de aplicação, e ajustar um modelo separado para cada dialeto não escala. Os autores levantaram uma questão: priors em tempo de inferência, derivados mecanicamente da especificação das operações do dialeto (Operation Definition Specification, ODS), podem substituir a adaptação por ajuste fino com 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 elimina variantes inválidas já na etapa de geração.

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

Segundo o resumo no arXiv, a migração da pilha do conjunto de dialetos arith+func+memref+linalg para o StableHLO não exigiu nenhuma linha de código novo de restrições, pois o esquema é derivado automaticamente da especificação.

Quanto o modelo pequeno superou os grandes

Nos dialetos em que a semântica do verificador é definida por restrições estruturais, os priors de esquema permitiram ao SmolLM2-1.7B igualar ou superar modelos de 15B a 34B parâmetros. No dialeto linalg, o modelo alcançou 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 modelos base grandes
• Foram lançados 4 benchmarks NL-to-MLIR: MLIR-Spec-150, Linalg-Spec-30, StableHLO-Spec-30 e StableHLO-Held-Out-200, somando 410 pares "texto→MLIR"
• Datasets sob licença Apache-2.0, com datasheets segundo a metodologia de Gebru e metadados Croissant 1.0
• Benchmarks, decodificador, todas as gerações e uma imagem Docker para reprodução foram abertos ao público

Mas o método não vence em todos os cenários. Em arith+func e no conjunto paramétrico StableHLO-Held-Out-200, em que a correção depende dos valores dos atributos e não da estrutura do código, os modelos grandes empataram com o pequeno ou o superaram. Os autores assinalam esses casos com franqueza como "non-win cells".

"Os priors de esquema permitem ao

SmolLM2-1.7B igualar ou superar modelos de código de 15B a 34B com velocidade de geração de 8 a 25 vezes maior", diz o resumo 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 ajuste fino: um modelo pequeno, com os "trilhos" certos, supera um grande e roda várias vezes mais rápido. Isso barateia a geração de código de compilador e elimina o problema de escalar o ajuste para cada novo dialeto.

Perguntas frequentes

O que é MLIR?

O MLIR (Multi-Level Intermediate Representation) é uma representação intermediária de código usada pelos compiladores de ML TensorFlow, JAX/StableHLO, PyTorch Inductor e IREE. Ele é estendido por "dialetos" voltados a tarefas específicas.

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

Ele não passou por ajuste fino: recebeu restrições de decodificação derivadas da especificação do dialeto. No linalg, isso rendeu 80.0% de programas válidos, de 21 a 44 pontos a mais 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, em que a correção depende dos valores dos atributos e não da estrutura do código. Ali, os modelos grandes empataram com o SmolLM2-1.7B ou o superaram.