AesCode-8B против MathForm-8B: обе — 8B-дообученные модели, вывод которых может проверить машина

AesCode-8B и MathForm-8B появились с разницей в восемь недель, оба — из репозиториев, а не из пресс-релизов, и это совпадение интереснее, чем кажется на первый взгляд. Оба стартуют с чекпойнта семейства Qwen3. Оба тратят весь свой тренировочный бюджет на узкую форму вывода. И оба построены вокруг проверяющего: MathForm-8B обучается по вердикту компилятора Lean 4, а AesCode-8B оценивается путём отрисовки каждой страницы-кандидата в песочнице браузера и считывания DOM, вычисленных стилей и скриншота. Ни тот, ни другой не является чат-ботом, и ни один из них не пытается им стать. Что их различает — это то, что машина может проверить, и то, что не может, — а в случае более нового из двух, что происходит, когда половина оценки приходит от судьи, которого никто не назвал.

Публикационные записи не симметричны. MathForm-8B была создана OpenBMB, и в её карточке модели указана дата выпуска 2026-08-14; она построена на Qwen3-8B и обучена на FormalVerse — корпусе из примерно 367 000 проверенных примеров на Lean 4, с контролируемой тонкой настройкой, за которой следует обучение с подкреплением, использующее компиляцию Lean и проверки семантической согласованности в качестве сигнала вознаграждения. AesCode-8B не содержит даты выпуска нигде в своих файлах. Microsoft создала репозиторий на Hugging Face 2026-09-29, зафиксировала веса в 03:35 UTC 2026-10-07 с сообщением "Release AesCode-8B" и опубликовала код обучения на GitHub 2026-10-08. Ни одно из этих событий не сопровождалось объявлением, в цитировании карточки модели указано "Under review, 2027", и на момент написания репозиторий показывал две загрузки. Она дообучена на основе Qwen3-VL-8B-Instruct, что стоит отметить, поскольку это не тот же предок, что у MathForm-8B.

Происхождение объясняет большую часть разделения

Qwen3-8B и Qwen3-VL-8B-Instruct принадлежат к одному поколению и одному семейству, но решают разные задачи. Qwen3-8B — это универсальная модель только для текста: примерно 8,2 млрд параметров всего, около 7 млрд из них — неэмбеддинговые, групповое внимание к запросам, нативный контекст на 32K токенов, расширяемый до 131K с помощью YaRN, и обучение на 119 языках и диалектах. Qwen3-VL-8B-Instruct — это её визуально-языковой собрат, и именно тот чекпойнт, с которого стартует AesCode-8B, — опубликованная конфигурация AesCode представляет собой чистый рецепт Qwen3-VL с 36 скрытыми слоями, размером скрытого слоя 4 096, 32 головами внимания с 8 головами для ключей и значений и словарём на 151 936 токенов.

Эта развилка определяет входную часть обоих специалистов ещё до того, как любой из них был обучен. MathForm-8B принимает текст и выдаёт текст в формальном синтаксисе. AesCode-8B принимает текст и, опционально, референсное изображение, а на выходе выдаёт документ.

• Базовые — MathForm-8B: Qwen3-8B, только текст. AesCode-8B: Qwen3-VL-8B-Instruct, изображение и текст на входе.

• Параметры — MathForm-8B: около 8,2 млрд. AesCode-8B: около 8,8 млрд в bf16 на четырёх шардах, что Hugging Face округляет до 9 млрд.

• Обучающие данные — MathForm-8B: FormalVerse, примерно 367 тыс. проверенных примеров Lean 4. AesCode-8B: 3 000 демонстраций холодного старта, затем обучение с подкреплением GDPO на 7 408 промптах в течение 400 шагов.

• Что проверяет выходные данные — MathForm-8B: компилятор Lean 4 плюс проверка семантической согласованности с исходной задачей. AesCode-8B: рендеринг в песочнице Playwright с шестью детерминированными верификаторами и одной рубрикой, оцениваемой моделью.

• Лицензия — обе под Apache 2.0, обе без ограничений доступа, обе унаследованы от базовой модели семейства Qwen3.

• Размещается где угодно — ни то, ни другое, насколько нам удалось выяснить.

Два разных значения слова «verifiable»

Вот в чём различие, с которым стоит не спешить, потому что «проверяемый машиной» используется для обоих, а это не одно и то же.

Проверяльщик MathForm-8B — это ассистент доказательств. Lean 4 либо принимает утверждение, либо нет, и этот вердикт не вопрос мнения, рубрики или вкуса судьи. Обучающий цикл нацелен именно на этот сигнал: этап SFT на FormalVerse учит отображению неформальной задачи в формальную формулировку теоремы с заголовком imports и именованной теоремой, а этап RL оттачивает его, используя компиляцию плюс проверку согласованности, которая спрашивает, по-прежнему ли формализация говорит то, что говорила исходная задача. Компиляция бинарна и воспроизводима любым, у кого та же версия Lean. Проверка согласованности — более мягкая половина, и именно в ней приводимые числа становятся слабыми — что как раз и показывают опубликованные результаты.

Чекер AesCode-8B — это рендерер. Кандидаты рендерятся в изолированном браузере Playwright с блокировкой внешних запросов, а харнесс считывает DOM, вычисленные стили, ограничивающие рамки, состояние консоли и скриншот. Шесть детерминированных каналов оценивают разбираемые вещи — выполнение, точный текст, поведение на границах, данные таблиц и графиков, семантическую вёрстку, пробелы — а седьмой, Visual Graph Rubric, оценивает геометрию и размещение с помощью привязанных к графу вопросов с ответом «да/нет». Таблицы должны быть настоящими HTML-таблицами, а графики — спецификациями ECharts; это ограничение выполняет реальную работу: оно заставляет вывод принимать форму, которую может разобрать верификатор. Детерминированная половина действительно воспроизводима. Визуальная половина оценивается визуально-языковой моделью, чью личность документация не называет, а значит, никто за пределами лаборатории не может её воспроизвести.

Так что честное сравнение состоит не в том, что «одно проверено, а другое — нет». Оно в том, что основной сигнал MathForm-8B — это компилятор, а его вторичный сигнал — проверка согласованности, тогда как основной сигнал AesCode-8B — это набор детерминированных DOM-утверждений, а его вторичный сигнал — мнение модели, упакованное в тот же общий балл.

Что сообщает каждый из них и какова ценность этого

MathForm-8B сообщает о среднем Pass@8 в 88,06% при проверке синтаксиса и 72,37% при проверке согласованности на шести бенчмарках. Самое интересное — разброс по отдельным бенчмаркам: 95,06% согласованности на FormalIMATH и 94,83% на ProverBench, затем 63% на FATE-H и 37% на FATE-X. Последние два — это сложные, реалистичные утверждения, и падение с середины девяностых до середины тридцатых — это честная форма этой возможности. Все эти цифры заявлены производителем и не воспроизведены, а набор бенчмарков смещён в сторону более лёгких наборов.

AesCode-8B сообщает 82.94 Overall по 300-образцовой рубрике Microsoft для инфографики — Text 94.06, Boundary 88.36, Chart 87.79, Rule 90.07, Content 86.41, Layout 87.80, Style 53.21, Visual 75.80 — при трёх генерациях на промпт и без отбора. Microsoft также сообщает, что он превосходит обусловленный референсом GPT-5.5 с 81.28 и Claude Opus 4.8 с 80.39 по той же рубрике, что серьёзный сбой переполнения холста повторяется на 4.3% из 300 образцов, и что 22.4 балла Visual отделяют 32B-компаньона от его собственного бэкбона. Каждое число принадлежит вендору, на задаче вендора, оценено по каналам, которые спроектировал вендор.

Эти два набора чисел вообще нельзя сравнивать друг с другом. Нет ни общей задачи, ни общей метрики, ни общего судьи. Поставить 88,06% рядом с 82,94% означало бы сравнивать долю успешных прохождений формализации на Lean с общей оценкой за инфографику, и ни одну из моделей никогда не оценивали на том, что делает другая.

Стоит назвать одну асимметрию, потому что она говорит не в пользу более новой модели. У главной метрики MathForm-8B есть встроенный внешний арбитр: любой может установить Lean, загрузить те же бенчмарки и проверить, компилируются ли утверждения. У главной метрики AesCode-8B его нет — детерминированные верификаторы мог бы повторно запустить настойчивый сторонний проверяющий, но визуальная половина оценки зависит от судьи, которого в статье не назвали. Невоспроизведённая доля успешной компиляции — более слабое утверждение, чем таблица бенчмарков, и всё же более сильное, чем невоспроизведённая оценка по рубрике с анонимным оценщиком внутри неё.

Их выполнение — это отдельный вопрос, нежели любой из показателей

Оба сегодня — это решения в пользу самостоятельного развёртывания. MathForm-8B обходится заметно дешевле: текстовый чекпоинт примерно на 8,2 млрд параметров с бюджетом генерации около 16K токенов вывода Lean, который в квантованном виде помещается на одну видеокарту среднего уровня. AesCode-8B — это визуально-языковая модель на 8,8 млрд параметров, чей путь обслуживания несёт изображения наравне с текстом; собственная команда для этой карты — vllm serve microsoft/AesCode-8B --limit-mm-per-prompt image=2 --max-model-len 24576, а 17,5 ГБ весов в bf16 плюс KV-кэш на 24 576 токенов и два изображения означают, что 24 ГБ видеопамяти — это впритык, а 40–48 ГБ — реалистичный минимум. Заложите в бюджет также стек рендеринга, если хотите оценивать собственные результаты, потому что именно так делалось каждое утверждение о качестве модели.

Более серьёзная скрытая издержка заключается в том, что обе модели — это специалисты, которых вы внедряете навсегда. Команда, которой нужны формализация и генерация документов, теперь обслуживает два пути инференса 8B, два набора форматов промптов, два профиля отказов, и ни одна из моделей не может взять на себя работу другой. Именно для такого случая и существует слой маршрутизации: оставьте специалистов там, где экономика и работа с данными оправдывают владение GPU, а общий трафик отправляйте туда, что размещено за той же конечной точкой. Конкретно, универсальные «собратья» этих двух базовых моделей доступны для вызова — Qwen3-VL-8B-Instruct по цене $0,18 за миллион входных и $0,70 за миллион выходных токенов при контексте 131 072 токена, наряду с семейством Qwen 3.8 и другими открытыми чекпойнтами — всё через единый API OrcaRouter, охватывающий более 200 моделей, с передачей прайс-листовой цены провайдера без наценки (0%) и автоматическим переключением при сбое между провайдерами. Ни один из специалистов не маршрутизируется здесь или где-либо ещё, где нам удалось такое найти; маршрутизируется тот универсал, к которому вы обращаетесь, когда узкая задача выполнена, — и это и есть разница между тестированием исследовательского чекпойнта и превращением его в несущую зависимость.

Выбор между ними, если уж действительно придётся

Выбирайте MathForm-8B, когда артефакт должен компилироваться. Конвертация банков задач, формальные корпуса для прувера, предварительное форматирование утверждений для инструментов на основе Lean — вот и всё описание работы, и это единственная из двух, которую обучали для неё. Относитесь серьёзно к числам FATE, когда оцениваете масштаб: на самых сложных реалистичных утверждениях примерно треть оказывается согласованной, и вам в любом случае придётся добавить этап проверки человеком.

Выбирайте AesCode-8B, когда артефакт должен отрендериться. На входе — бриф, на выходе — редактируемый HTML-документ, таблицы остаются таблицами, а графики — спецификациями графиков, и всё это диффится в Git. Примите потолок Style — 53.21, измерение, определённое как не требующее дальнейшей визуальной доработки перед сдачей, — как честную меру того, сколько правок ещё осталось, и примите, что контекст в 24 576 токенов проверялся только на одиночных страницах инфографики, а не на многослайдовых презентациях, которые людям на самом деле нужны.

Однако выбор, с которым реально столкнётся большинство команд, — ни то, ни другое. Он в том, стоит ли вообще развёртывать одного из этих узких специалистов или же универсальная модель за ним, вызываемая через API, достаточно близка по качеству для вашего объёма. Это полдня тестирования промптов, а не покупки GPU, и собственные цифры обеих карточек дают основание это сделать: согласованность MathForm-8B на сложном наборе составляет 37%, а оценка Style у AesCode-8B — 53%, так что ни одну из этих моделей вы не поместили бы в пайплайн без присмотра.

Что оба релиза говорят о том, как сейчас выпускаются модели

Две дообученные модели на 8B, с разницей в восемь недель, из двух разных лабораторий, выпущены без анонса, без страницы продукта и без независимой оценки, обе построены вокруг цикла верификации, обе под Apache 2.0, и ни одну из них никто не предоставляет как сервис. Эта закономерность — и есть главная история, в большей степени, чем любая из моделей. Метод исследования перекочевал в функцию вознаграждения — сигнал компилятора от OpenBMB, разъединённые кросс-модальные каналы Microsoft — а публикуемые артефакты стали рецептом обучения плюс весами, причём статья выходит позже, если вообще выходит.

Это означает, что для любого, кто читает подобное сравнение, на какое-то время всё, что у вас есть, — это собственные цифры вендора, и полезный вопрос не в том, насколько они высоки, а в том, насколько их можно проверить. Частота переполнения AesCode-8B и его потолок Style — это проверяемые утверждения, поданные как неудачи. Показатель согласованности FATE-X у MathForm-8B — то же самое. Именно эти числа стоит читать, и именно их нужно вернуться и прогнать самостоятельно заново, как только средства проверки станут воспроизводимыми от начала до конца.