AesCode-8B 対 MathForm-8B：どちらも、出力を機械が検証できる8Bのファインチューニング

AesCode-8BとMathForm-8Bは、互いに8週間以内に登場した。どちらもプレスリリースではなくリポジトリから生まれ、この偶然は一見したよりも興味深い。どちらもQwen3ファミリーのチェックポイントから出発している。どちらも訓練予算のすべてを狭い出力形状に費やしている。そしてどちらもチェッカーを中心に作られている：MathForm-8BはLean 4コンパイラの判定に照らして訓練され、AesCode-8Bは、各候補ページをサンドボックス化されたブラウザでレンダリングし、DOM、計算済みスタイル、スクリーンショットを読み戻すことで採点される。どちらもチャットボットではなく、どちらもチャットボットになろうとしていない。両者を分けるのは、機械が検証できるものとできないもの——そして、より新しい方の場合、スコアの半分が誰も名前を明かしていない審判から届くときに何が起こるか、である。

公開記録は対称的ではない。MathForm-8BはOpenBMBによるもので、そのモデルカードにはリリース日が2026-08-14と記載されている。これはQwen3-8Bを基盤とし、約367,000件の検証済みLean 4サンプルからなるコーパスFormalVerseで学習されている。教師ありファインチューニングに続いて、Leanのコンパイルと意味的一貫性のチェックを報酬シグナルとする強化学習が行われている。AesCode-8Bは、そのファイルのどこにもリリース日が記載されていない。Microsoftは2026-09-29にHugging Faceリポジトリを作成し、2026-10-07の03:35 UTCに「Release AesCode-8B」というメッセージで重みをコミットし、2026-10-08にGitHubでトレーニングコードを公開した。どちらの出来事にも告知は伴わず、モデルカードの引用には「Under review, 2027」と記され、本稿執筆時点でリポジトリのダウンロード数は2件だった。これはQwen3-VL-8B-Instructからファインチューニングされており、MathForm-8Bの祖先とは異なるというまさにその点が注目に値する。

その系統が分裂の大部分を説明する

Qwen3-8BとQwen3-VL-8B-Instructは同じ世代とファミリー名を共有していますが、役割は異なります。Qwen3-8Bはテキスト専用の汎用モデルで、総パラメータ数は約82億、うち約70億が非埋め込みで、グループ化クエリ注意を採用し、ネイティブコンテキストは32KトークンでYaRNにより131Kまで拡張可能、119の言語と方言にわたって学習されています。Qwen3-VL-8B-Instructは視覚言語対応の兄弟モデルで、AesCode-8Bが開始点とするチェックポイントです。公開されているAesCodeの設定は、36の隠れ層、隠れサイズ4,096、8つのキー・バリューヘッドを備えた32の注意ヘッド、151,936トークンの語彙を持つ、純粋なQwen3-VLのレシピです。

その分岐が、どちらの専門モデルも訓練される前に、両者の入力側を決めている。MathForm-8Bはテキストを受け取り、形式的な構文でテキストを出力する。AesCode-8Bはテキストと任意の参照画像を受け取り、ドキュメントを出力する。

• ベース — MathForm-8B: Qwen3-8B、テキストのみ。AesCode-8B: Qwen3-VL-8B-Instruct、画像とテキストを入力。

• パラメータ — MathForm-8B：約82億。AesCode-8B：bf16で4つのシャードに分けて約88億で、Hugging Faceでは90億に丸められます。

• 学習データ — MathForm-8B: FormalVerse、約36.7万件の検証済みLean 4サンプル。AesCode-8B: 3,000件のコールドスタート実演を行った後、7,408件のプロンプトに対してGDPO強化学習を400ステップ実施。

• 出力を検証するもの — MathForm-8B：Lean 4 コンパイラ、および元の問題に対する意味的一貫性チェック。AesCode-8B：サンドボックス化された Playwright レンダリングと、6つの決定論的検証器および1つのモデル採点ルーブリック。

• ライセンスどちらも Apache 2.0、どちらもゲートなし、どちらも Qwen3 ファミリーのバックボーンを継承しています。

• どこでもホスト可能 — 私たちが調べた限り、どちらでもありません。

「検証可能」の2つの異なる意味

これはゆっくり考える価値のある区別だ。というのも、「機械的に検証可能」という言葉はその両方に使われるが、同じことを意味しているわけではないからだ。

MathForm-8Bのチェッカーは証明アシスタントです。Lean 4は命題を受理するか、そうでないかのどちらかであり、その判定は意見や評価基準、審査員の好みの問題ではありません。訓練ループはそのシグナルに照準を合わせています。FormalVerseでのSFT段階は、インフォーマルな問題から、インポートヘッダーと名前付き定理を伴う形式定理文へのマッピングを学習し、RL段階では、コンパイルと、形式化が依然として元の問題の述べていたことを述べているかどうかを問う整合性チェックを用いてそれを鋭くします。コンパイルは二値的で、同じLeanバージョンを持つ誰でも再現できます。整合性チェックはより軟らかい半分であり、報告される数値が弱くなる半分です——まさに公表された結果が示しているのはその点です。

AesCode-8Bのチェッカーはレンダラーです。候補は、外部リクエストがブロックされたサンドボックス化されたPlaywrightブラウザでレンダリングされ、ハーネスはDOM、計算済みスタイル、バウンディングボックス、コンソールの状態、スクリーンショットを読み戻します。6つの決定論的チャネルが解析可能な項目を採点します — 実行、正確なテキスト、境界動作、表とチャートのデータ、セマンティックレイアウト、ホワイトスペース — そして7つ目のVisual Graph Rubricが、グラフに基づくはい/いいえの質問を通じて幾何形状と配置を採点します。表は本物のHTMLテーブルでなければならず、チャートはECharts仕様でなければなりません。これは実際に機能する制約です。つまり、出力を検証器が解析できる形に強制します。決定論的な半分は真に再現可能です。視覚的な半分は、ドキュメントがその正体を明記していない視覚言語モデルによって判定されるため、研究所の外の誰もそれを再現できません。

つまり正直な比較は「一方は検証済みで、もう一方はそうではない」ということではない。MathForm-8Bの主要なシグナルはコンパイラであり、副次的なシグナルは一貫性チェックである一方、AesCode-8Bの主要なシグナルは決定論的なDOMアサーションの集合であり、副次的なシグナルはモデルの意見であり、それが同じ総合スコアの中にまとめられている、ということだ。

それぞれが何を報告するか、そしてそれがどれほどの価値があるか

MathForm-8Bは、6つのベンチマーク全体で、構文チェック下の平均Pass@8が88.06%、一貫性チェック下では72.37%だと報告している。興味深いのはベンチマークごとのばらつきだ。FormalIMATHでは一貫性95.06%、ProverBenchでは94.83%なのに対し、FATE-Hでは63%、FATE-Xでは37%になる。この最後の2つは難しく現実的なステートメントであり、90%台半ばから30%台半ばへの落ち込みこそ、この能力の正直な形である。これらの数値はすべてベンダー報告で未再現であり、ベンチマークの構成もより易しいセットに偏っている。

AesCode-8Bは、Microsoftの300サンプルのインフォグラフィック評価基準において総合82.94を報告している——テキスト94.06、境界88.36、チャート87.79、ルール90.07、コンテンツ86.41、レイアウト87.80、スタイル53.21、ビジュアル75.80——プロンプトごとに3回生成し、選択は行っていない。Microsoftはまた、同じ評価基準で、参照条件付きのGPT-5.5の81.28、Claude Opus 4.8の80.39を上回ると報告しており、300サンプルの4.3%で深刻なキャンバスオーバーフロー障害が繰り返し発生すること、22.4のビジュアルポイントが32Bのコンパニオンをそれ自身のバックボーンから隔てていることも報告している。すべての数値はベンダーのものであり、ベンダーのタスク上で、ベンダーが設計したチャネルに対して採点されている。

この2組の数値はまったく比較できない。共通のタスクも、共通の指標も、共通の評価者も存在しない。88.06%を82.94%の隣に並べることは、Leanの形式化の合格率とインフォグラフィックの総合スコアを比較することであり、どちらのモデルも、もう一方が行っていることについて評価されたことは一度もない。

ひとつの非対称性は、名指しする価値がある。それはより新しいモデルに不利に働くからだ。MathForm-8B の主要指標には外部の審判が組み込まれている。誰でも Lean をインストールし、同じベンチマークを読み込み、そのステートメントがコンパイルできるかどうかを確認できる。AesCode-8B の主要指標にはそれが備わっていない。決定論的検証器なら、やる気のある部外者でも再実行できるかもしれないが、スコアの視覚的な半分は、論文が特定していない審査員に依存している。再現されていないコンパイラ通過率は、ベンチマーク表より弱い主張であり、それでもなお、内部に匿名の採点者を抱えた再現されていないルーブリックスコアよりは強い主張である。

それらを実行することは、どちらのスコアとも別問題だ

現時点では、どちらもセルフホストするかどうかの判断になります。MathForm-8B のほうが大幅に安価です。約 8.2B のテキスト専用チェックポイントで、Lean 出力の生成予算は約 16K トークンであり、量子化すると単一のミッドレンジカードに収まります。AesCode-8B は 8.8B の視覚言語モデルで、そのサービング経路はテキストだけでなく画像も扱います。カード自体のコマンドはvllm serve microsoft/AesCode-8B --limit-mm-per-prompt image=2 --max-model-len 24576であり、17.5 GB の bf16 重みに加え、24,576 トークンと 2 枚の画像分の KV キャッシュを考えると、24 GB カードではぎりぎりで、40～48 GB が現実的な下限です。自分で出力を採点したい場合は、レンダリングスタックも予算に入れてください。モデルに関するあらゆる品質上の主張は、そうやってなされたものですから。

より大きな隠れたコストは、どちらのモデルも恒久的に採用することになる専門特化型モデルだという点にある。文書の正式化とドキュメント生成を必要とするチームは、今や2つの8Bサービング経路、2セットのプロンプト形式、2つの障害プロファイルを抱え込むことになり、どちらのモデルももう一方の仕事を吸収できない。まさにこれがルーティングレイヤーの存在意義だ。経済性とデータの扱いの面で自前のGPUを持つことが正当化される領域には専門特化型モデルを残し、一般的なトラフィックは同じエンドポイントの背後でホストされている何かに送ればよい。具体的には、これら2つのベースモデルの汎用版の兄弟は呼び出し可能だ——Qwen3-VL-8B-Instructは131,072トークンのコンテキストで入力100万トークンあたり$0.18、出力100万トークンあたり$0.70、Qwen 3.8ファミリーやその他のオープンチェックポイントと並んで——それらすべては200以上のモデルをカバーするOrcaRouterの単一APIを通じて利用でき、プロバイダーの表示価格を0%のマークアップでそのまま渡し、プロバイダー間で自動フェイルオーバーも行う。どちらの専門特化型モデルも、ここでも、他に探せるどこでもルーティング可能ではない。ルーティング可能なのは、狭い用途の仕事が終わったときにフォールバックする汎用モデルのほうであり、これが研究用チェックポイントを試用することと、それをシステムを支える依存先にすることの違いだ。

どうしても選ばなければならないのなら、それらのどちらかを選ぶことになる

成果物をコンパイルしなければならないときは MathForm-8B を選べ。問題バンクの変換、証明器向けの形式コーパス、Lean ベースのツール向けに文を事前整形すること — それが仕事内容のすべてであり、2つのうちそれ向けに訓練されているのはこれだけだ。範囲を見積もるときは FATE の数値を真剣に受け止めろ。最も難しい現実的な文では、およそ3分の1が整合する程度で、いずれにせよ人手によるレビュー工程を組み込むことになる。

成果物をレンダリングする必要があるときは、AesCode-8Bを選びましょう。ブリーフを入れると、編集可能なHTMLドキュメントが出てきて、表は表のまま、チャートはチャート仕様のまま、全体はGitで差分を取れます。Style ceiling — 53.21、納品前にこれ以上の視覚的修正を必要としないと定義された評価軸 — を、どれだけ編集が残っているかの正直な尺度として受け入れ、24,576トークンのコンテキストは、人々が実際に求めているマルチスライドのデッキではなく、単一のインフォグラフィックページでのみ検証されていることも受け入れましょう。

とはいえ、ほとんどのチームが実際に直面する選択は、これらのどちらでもありません。それは、こうした狭い専門分野のモデルの一方をそもそもデプロイする価値があるのか、それともその背後にある汎用モデルを API 経由で呼び出せば、手元の処理量に対して十分近いのか、という点です。それは GPU の購入ではなく、午後いっぱいのプロンプトテストであり、両モデルカード自体の数値がそれを試す理由になります。MathForm-8B のハードセット一貫性は 37%、AesCode-8B の Style スコアは 53% なので、どちらも監視なしでパイプラインに投入するようなモデルではありません。

両方のリリースから分かる、今モデルがどのように世に出るか

8Bのファインチューニング2件が、8週間違いで、異なる2つのラボから、発表も製品ページも独立評価もなしにリリースされた。どちらも検証ループを中心に構築され、どちらもApache 2.0で、どちらも誰からもサービス提供されていない。そのパターンこそが、どちらのモデルよりも語るべき物語なのだ。研究手法は報酬関数へと移行した——OpenBMBのコンパイラ信号、Microsoftの分離型クロスモーダルチャネル——そして公開される成果物は、訓練レシピと重みになり、論文は、出るとしても後からになる。

このような比較を読む人にとって、それが意味するのは、しばらくの間はベンダー自身の数値しか手に入らないということだ。そして有用な問いは、それらがどれほど高いかではなく、どれほど検証可能かである。AesCode-8B のオーバーフロー率とその Style 上限は、失敗の装いをした検証可能な主張だ。MathForm-8B の FATE-X 一貫性の数値も同じことだ。読むべきなのはこれらの数値であり、チェッカーがエンドツーエンドで再現可能になったその瞬間に、自分で戻って再実行すべきなのもこれらの数値だ。