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

Исследователи в июле 2026 года представили на arXiv метод, который позволил языковой модели SmolLM2-1.7B генерировать корректный код MLIR наравне с моделями в 15-34 раза крупнее — без дообучения, за счёт ограничений декодирования, механически выведенных из спецификаций диалектов.

Почему MLIR трудно даётся моделям

MLIR (Multi-Level Intermediate Representation) — промежуточное представление, на котором держится инфраструктура современных ML-компиляторов: TensorFlow, JAX/StableHLO, PyTorch Inductor и IREE. При этом в обучающих корпусах языковых моделей MLIR встречается лишь в следовых количествах, поэтому модели плохо его генерируют.

Главная сложность — расширяемость. MLIR по замыслу наращивается новыми «диалектами» под каждый прикладной домен, и дообучать отдельную модель под каждый диалект не масштабируется. Авторы поставили вопрос: могут ли inference-time приоры, выведенные механически из спецификации операций диалекта (Operation Definition Specification, ODS), заменить адаптацию через градиентное дообучение.

Как работают ограничения из спецификации

Метод строит трёхслойный стек ограничений прямо из схемы диалекта, без обучения. Каждый слой отсекает невалидные варианты уже на этапе генерации.

• C1 — контекстно-свободная грамматика (CFG) над сигнатурами операций
• C2 — разбиение по типам из решётки типов, извлечённой из ODS
• C3 — валидатор области видимости SSA с rejection sampling и пятью повторными попытками

По данным аннотации на arXiv, перенос стека с набора диалектов arith+func+memref+linalg на StableHLO не потребовал ни строки нового кода ограничений — схема выводится из спецификации автоматически.

Насколько маленькая модель обошла большие

На диалектах, где семантика верификатора определяется структурными ограничениями, схемные приоры позволили SmolLM2-1.7B сравняться с моделями на 15-34B параметров или превзойти их. На диалекте linalg модель достигла 80.0% валидных программ (среднее по трём сидам, n=125).

• Преимущество над CodeLlama-34B, Granite-Code-34B и StarCoder2-15B — от 21 до 44 процентных пунктов, доверительные интервалы не пересекаются
• Скорость генерации — в 8-25 раз выше, чем у крупных базовых моделей
• Выпущено 4 бенчмарка NL-to-MLIR: MLIR-Spec-150, Linalg-Spec-30, StableHLO-Spec-30 и StableHLO-Held-Out-200 — всего 410 пар «текст→MLIR»
• Датасеты под лицензией Apache-2.0, с datasheets по методике Gebru и метаданными Croissant 1.0
• В открытый доступ выложены бенчмарки, декодер, все генерации и Docker-образ для воспроизведения

Но не везде метод выигрывает. На arith+func и на параметрическом наборе StableHLO-Held-Out-200, где корректность зависит от значений атрибутов, а не от структуры кода, крупные модели сравнялись с маленькой или обошли её — авторы честно помечают эти случаи как «non-win cells».

«Схемные приоры позволяют

SmolLM2-1.7B сравняться с code-моделями на 15-34B или превзойти их при 8-25-кратной скорости генерации», — говорится в аннотации исследования на arXiv.

Что это значит

Для узких, структурно-строгих языков вроде MLIR ограничения из спецификации могут заменить дорогое дообучение: маленькая модель с правильными «рельсами» обгоняет крупную и работает в разы быстрее. Это удешевляет генерацию компиляторного кода и снимает проблему масштабирования на каждый новый диалект.

Частые вопросы

Что такое MLIR?

MLIR (Multi-Level Intermediate Representation) — промежуточное представление кода, на котором работают ML-компиляторы TensorFlow, JAX/StableHLO, PyTorch Inductor и IREE. Оно расширяется «диалектами» под конкретные задачи.

Почему модель на 1.7B обошла модели на 34B?

Она не дообучалась, а получила ограничения декодирования, выведенные из спецификации диалекта. На linalg это дало 80.0% валидных программ — на 21-44 пункта больше, чем у CodeLlama-34B, Granite-Code-34B и StarCoder2-15B.

Где метод не сработал?

На диалектах arith+func и наборе StableHLO-Held-Out-200, где корректность зависит от значений атрибутов, а не от структуры кода. Там крупные модели сравнялись с SmolLM2-1.7B или обошли её.