Ember-1 vs MathForm-8B：借用したベースモデルを絞り込むことで構築された2つのモデル

Ember-1とMathForm-8Bは、どちらの研究室も戦略として公言していない共通点を抱えている。どちらも、他者が訓練したモデルを狭く特化させたものだ。Ember-1は、Fireworks ResearchによるMoonshot AIのKimi K3の特化派生モデルで、2026年9月23日に公開され、およそ40%少ないトークンでK3の精度に到達するよう再訓練された。MathForm-8BはOpenBMBの8B自動形式化モデルで、2026年8月14日にひっそり公開された、AlibabaのQwen3-8BをApache-2.0でファインチューニングしたもので、非形式数学をコンパイラが検査できるLean 4定理文に変換する。一方の特化は無駄な熟考を取り除き、汎用能力を損なわずに保った。もう一方はほぼすべての汎用能力を削り、代わりに検証可能性を手に入れた。この2つを並べることは、特化が実際に何を犠牲にするのかを見る最も明快な方法だ。なぜなら、2つのモデルは訓練予算をその台帳の反対側に費やしたからだ。

2種類の絞り込み

Fireworks Researchの介入は行動面に関するものです。Ember-1はKimi K3のアーキテクチャとその広範さ——数学、コーディング、指示追従、会話、検索、ツール使用、ソフトウェアエンジニアリングがすべて学習ミックスに含まれる——を維持し、回答前にモデルがどれだけ熟考するかだけを変えます。報告されている結果は、7つのベンチマークと2件の顧客本番A/Bテストで精度を損なわずに推論長が35～50%減少したというもので、ある本番コーディングワークロードでは出力トークンが49.3Kから29.9Kに減少し、スコアは0.751に対して0.753を維持しました。すべての数値はベンダー報告であり、再現されていません。

OpenBMBの介入は契約に基づくものである。MathForm-8BはQwen3-8Bを基にし、学習予算のすべてを単一の出力形態に注ぎ込む。すなわち、importsヘッダーと名前付き定理を備えたLean 4ステートメントだ。パイプラインは、OpenBMBが構築しモデルと同時に公開した、約36万7000件の検証済みLean 4例からなるコーパスFormalVerseに対する教師ありファインチューニングと、それに続く強化学習から成る。この強化学習では、Leanのコンパイルと意味的一貫性のフィードバックを報酬信号として用いる。このモデルは証明を解かない。証明器が完成させるステートメントを書くのであり、論文自身の位置づけでは、6つのベンチマークによる評価がこの取り組みの主眼であると説明されている。

それぞれが諦めたもの

Ember-1は数字の上ではほとんど何も譲っていない。それこそが主張のすべてだ。公開されている成績表では、Terminal Bench 2.1で82.0%対Kimi K3 Maxの80.9%、DeepSWE 1.1で75.2%対66.4%と勝利し、SWE-bench Verifiedでは92.2%対93.2%、SWE-Interactでは20.0%対21.3%と僅差で敗れている。これらはベンダーが選んだセットにおけるベンダー発表の数字だが、その形は一貫している。能力を失ったというより、力を注ぐ先を変えたモデルだ。ただし、トークン削減幅はTerminal Benchの51.9%からτ-2 Bench Airlineの5.9%まで幅があり、したがって「約40%」は非常に広いばらつきにまたがる平均値だ。

MathForm-8B は、Qwen3-8B が知られている機能のほとんどを放棄しました。一般的な会話を行わず、Qwen3-8B がトレーニングされた 119 の言語と方言をカバーせず、画像や音声も受け付けません。その生成バジェットは Lean 出力向けに調整されており、拡張された混合推論向けではありません。維持したのは、寛容なライセンスと小さなフットプリントです。BF16 の 4 つの safetensors シャードで、OpenAI 互換エンドポイントの背後で Transformers、vLLM、または SGLang の下で動作し、Lean 4.21.0 上の Kimina Lean Server を想定するコンパイルパスを備えています。

その数字はそれぞれ別のものを測っており、その差こそが要点だ

Ember-1 の代表的な数値は、エージェントが正しく完了したタスクの割合です — Terminal Bench 2.1、89 サンプル、82.0%。MathForm-8B の代表的な数値は、6 つの自動形式化ベンチマークにわたる平均 Pass@8 スコアで、構文チェックでは 88.06%、より厳格な一貫性チェックでは 72.37% です。これらは同じ軸上にはありません。一方はエージェントがターミナルでジョブを完了したかどうかを測り、もう一方は生成された定理文が構文解析できるか、そしてそれが元になった非形式的な問題と同じ意味を持つかどうかを測ります。

MathForm自身の結果内にある88.06対72.37という広がりこそ、より示唆に富む数字だ。「これはコンパイルが通る」と「これはコンパイルが通り、かつ自分の意図したことを述べている」の間の隔たりはおよそ16ポイントであり、これが自動形式化を難しくする失敗モードだ。型検査は通るのに元の主張を静かに弱めている文は、明らかな誤りよりも悪い。なぜなら、下流でそれを指摘するものがないからだ。最も難しいセットでは、整合性チェックはFATE-Hで63%、FATE-Xで37%まで下がる一方、FormalIMATHのような易しいセットは95.06%、ProverBenchは94.83%にとどまる。それは、専門家が専門家の弱い点について正直に述べていることであり、単一の平均より役に立つ。

次元ごとの対比

• ベースモデル — Ember-1: Kimi K3。MathForm-8B: Qwen3-8B。

• トレーニングが変えたもの — Ember-1：能力を一定に保ちつつ、モデルがどれだけ長く推論するか。MathForm-8B：汎用性を大部分放棄しつつ、モデルが何を出力するか。

• パラメータ — Ember-1: 非公開。MathForm-8B: 約8B、高密度、BF16。

• 出力契約 — Ember-1: 通常のテキストとツール呼び出し、K3レベルの品質。MathForm-8B: ヘッダーと名前付き定理を備えた Lean 4 ステートメント。

• ライセンスとウェイト — Ember-1: 公開なし。ベンダー独自のプラットフォームを通じたリサーチプレビュー。MathForm-8B: Apache 2.0、ウェイトとデータセットの両方がダウンロード可能。

• 報告されたヘッドライン — Ember-1：Terminal Bench 2.1で82.0%、トークン数は51.9%削減。MathForm-8B：構文チェック下での平均Pass@8は88.06%、一貫性チェック下では72.37%。

• 独立検証 — どちらも該当せず。両方ともベンダー報告であり、再現されていない。

ライセンス条項はベンチマークよりも多くを決める

数値上の違いはともかく、これら2つのリリースの実用的な違いは配布形態にある。MathForm-8Bはファイルだ。OpenBMBは重み、FormalVerseデータセット、論文を同じ日にApache 2.0で公開し、告知もホスト型APIもなかった——モデルカードがそのローンチだ。今日の午後にダウンロードして単一GPUで動かせるし、誰にも取り上げられない。Ember-1はサービスだ。重みはなく、価格も公表されておらず、アクセス可能な期間は、継続が需要次第である2週間のサーバーレス期間として説明されている。今日は呼び出せるが、11月にも呼び出せるとは確信できない。

その違いはまた、各モデルを何に使えるかも決める。形式化コンポーネントは、自分で管理するパイプラインの内側に置くべきもので、バージョンを固定し、Lean ツールチェーンを同じマシン上に持つ——だからこそ、ゲートなしの Apache-2.0 チェックポイントが MathForm-8B の役割に適した形であり、その README に GitHub コードリンクがないこと（執筆時点ではまだプレースホルダー）が、どのベンチマーク数値よりも厄介な欠落である理由でもある。推論コストモデルは API の背後に置くべきもので、そこではトークン課金こそが最適化対象であり、ベンダーは価格とレイテンシで競争する。Ember-1 の形もその役割に合っている。ただ、それは依存関係が技術的ではなく商業的であることを意味するだけだ。

パイプラインが両方を使用する場合

これら2つのモデルは競合するものではなく補完し合う関係にあり、その組み合わせは簡単に説明できます。形式化のスペシャリストが問題を検証可能な命題へと変換し、推論モデルがその命題、あるいはその周辺のエンジニアリングに取り組みます。どちらもOrcaRouter上にはありません — MathForm-8Bはセルフホスト専用で、Ember-1はベンダー自身のプレビュー上にあります — しかし、この組み合わせ自体は、私たちのルーティングDSLが存在する理由となるパターンです。複数のモデルを1回の呼び出しに組み合わせることは、2つの統合経路と2つの契約を維持することなく、パイプラインにスペシャリストとジェネラリストを手に入れる方法であり、モデルフュージョンはさらに一歩進んで、モデルのパネルが一斉に回答することを可能にします。単一のモデルの故障モードが高コストになる場合に。

特に形式化スタックでは、コンポジションを支持する根拠は通常より強い。目に見える失敗モードは、コンパイルは通るが意味が少しだけ異なる文であり、サイレントエラーに対する最も安価な防御策は、同じ問題を読む2つ目のモデルだ。これはトレーニングの決定ではなく、ルーティングの決定である。

どちらの方がお買い得ですか

機械検証可能な数学が必要なら、2つのうち何かしらを生成するのは MathForm-8B だけで、その主な代償は、このタスクではそもそも使うつもりのなかった汎用性だ。ダウンロードし、Lean サーバー用の予算を確保し、独自の評価を構築せよ — OpenBMB の論文は、あなたの分布でそれがどう性能を発揮するかまでは教えてくれない。

トークンコストを抑えつつ汎用推論モデルが必要なら、Ember-1 はあなたに向いています。次に取るべき正しいステップは、ベンチマーク比較ではなく、現在運用しているものに対してシャドウトラフィックを流すことです。そのリスクは能力ではなく可用性にあり、アプリケーションとモデルの間にルーティング層を維持することでヘッジできるリスクです。

これらのどちらかがこの問題に決着をつけてくれることを望む人にとって、不快な結論は、どちらも独立に評価されていないということだ。MathForm-8Bは公開から6週間が経ち、第三者が再現結果を公表していない。Ember-1は公開から1日しか経っていない。どちらもあなたに評価者になることを求めており、それは2026年に特化型モデルを選ぶ際の通常の状況だ。

それらが実際に証明しているのは、絞り込み戦略が双方向に機能するということだ。フロンティアモデルは、性能を悪化させずにより安くできる。また、小さなベースモデルも、その学習をコンパイラに向けることで厳密にできる。興味深い問いは、これら二つのアプローチのどちらが勝つかではなく、それらに含まれる技法が標準的な実践になった後、どちらがどれだけ長く必要とされ続けるかである。