Kolibri 対 MathForm-8B：これらの精度主張のうち、1つはコンパイラで検証できる

KolibriとMathForm-8Bはライセンスを共有しているが、それ以外にほとんど共通点はない。どちらもApache 2.0で、どちらもオープンウェイトで、どちらもここ3か月以内にリリースされた——Aleph AlphaのKolibriは2026年10月3日、OpenBMBのMathForm-8Bは2026年8月14日——そしてどちらもモデルカードの大部分を数学に費やしている。似ているのはそこまでだ。Kolibriは781億パラメータのドイツ語・英語のMixture-of-Expertsモデルで、トークンあたり34.6億パラメータを活性化し、規制されたドキュメントワークフローに収まることを想定している。MathForm-8BはQwen3-8Bからファインチューニングされた80億パラメータのdenseモデルで、仕事はただ1つ——普通の英語で書かれた数学の問題を受け取り、形式的に正しいLean 4の命題として出力することだ。どちらかを評価する人にとって重要な違いは、パラメータ数ではない。MathForm-8Bの精度の主張は実行可能だという点だ。その出力はコンパイラで確認できる。Kolibriの出力は、別のベンチマークを走らせる以外に確認する手段がない。

その非対称性こそがこの記事の主旨そのものであり、それはこれら2つのモデルをはるかに超えて広く一般化できる。ベンダーのベンチマーク表は主張である。証明支援系が形式化を受理することは結果である。モデルの出力空間全体が機械で検証できるものであるとき、マーケティングの層は消える——Leanコンパイラがその文を受理するか、しないかのどちらかであり、ローンチ記事の見せ方をどれだけ工夫してもそれは変わらない。

MathForm-8Bが実際に生成するもの

自動形式化は、狭く地味で、本当に難しいタスクであり、モデルカードはその設定について清々しいほど具体的に述べている。

• 入力と出力 — 自然言語の数学的命題を入力すると、定理ヘッダーを備えた Lean 4 形式化が出力されます。

• ベースモデル — Qwen/Qwen3-8B、ファインチューニング済み；Apache 2.0、OpenBMB のリリースの残りと同様。

• トレーニング — 教師ありファインチューニングに続いて、FormalVerse データセット上で強化学習を実施し、Lean のコンパイルと意味的一貫性のフィードバックが強化学習のシグナルを駆動します。

• データパイプライン — Mathlibの知識検索、コンパイルと意味検証、反復的な改良、そして軌跡の再構築。モデルカードのパイプライン図は、このリリースで最も情報量の多いものだ。

• 評価 — 2つの別個のチェック、Syntax Check と Consistency Check における Pass@8 合格率を、6つのベンチマークにわたって、行ごとに引用できる表としてではなく、カード上の図において等しく重み付けされたマクロ平均として報告。

• ツールチェーン — コンパイルチェック用の稼働中のKimina Lean Server、実験用のLean 4.21.0、および温度0.6・top-p 0.95の最大系列長16,384トークン。

• サービング — vLLM または SGLang を 16,384 トークンのコンテキストで実行し、OpenAI 互換のチャットインターフェース経由で公開する。この最後の点は見た目以上に重要である。なぜなら、モデルが通常のエンドポイントとして既存のパイプラインにそのまま組み込まれることを意味するからだ。

2つの別個のチェックに注意してください。構文チェックは、そのLean文がそもそもパースでき、型チェックを通過するかどうかです。整合性チェックは、その形式文が自然言語の問題と同じ意味を持つかどうかです。これははるかに難しい性質です。なぜなら、誤った定理を形式化した、構文的に妥当なLean文は、コンパイルエラーよりも悪いからです。OpenBMBはその両方を報告しており、これはまさに正しいやり方であり、このタスクが汎用推論にはない検証ストーリーを持つ理由でもあります。

コリブリが数学で果たすこと、そしてそれが異なる種類の数である理由

Kolibriはベンチマークの観点では数学が得意です。Aleph Alpha自身のポストトレーニングハーネスでは、推論努力度「高」で、AIME 2025の英語で96.9、ドイツ語で87.5、AIME 2026で96.0と90.0、数学スイート全体の英語平均で96.5（ドイツ語では88.8）を記録しています。同じ表での文脈として、KolibriのAIME 2025英語での96.9は、Nemotron 3 Super 120B-A12Bの91.7とQwen3.6 35B-A3Bの84.6を上回り、Qwen3.8 27Bの97.9のすぐ下に位置します。

それらの数値はすべてベンダーによる報告で、ベンダーのハーネス上で得られたものであり、独立した再現はなく、Kolibri については照合できる Artificial Analysis のページも存在しない。これは数値への批判ではない。それらがどういう種類の対象なのかを述べているだけだ。AIME スコアは、多肢選択式試験における最終解答の正答率だ。それはモデルが整数に到達できることを示す。それを生み出した推論が妥当だったかどうかについては何も示さず、第三者が検証できる痕跡も残らない。

MathForm-8B の出力と並べてみると、その違いは歴然としている。AIME の問題に対する Kolibri の答えは数値だ。MathForm-8B の出力は、Mathlib に対してコンパイルが通るか通らないかの Lean 4 定理ステートメントである。数学的主張が擁護可能でなければならないシステム——形式検証パイプライン、証明支援ワークフロー、監査証跡——を構築しているなら、2 番目の成果物は 1 番目よりはるかに価値があり、そのことを表すベンチマークの行は存在しない。

二つが実際に交わる場所

対決として捉えるなら、この組み合わせは面白くない。8Bの専門特化モデルは数学の形式化では78Bの汎用モデルを打ち負かすが、それ以外のすべて——ドイツ語の行政文章、長文脈の文書推論、100ステップのエージェント軌跡を通じたツール呼び出し——では負ける。しかし両者は代替物ではなく、有用な問いは、両方から組み立てたパイプラインがどのような形になるかである。

自然な構成はルーティングによるものだ。強力な推論とツール呼び出しを備えた汎用モデルが、取り込み、曖昧性解消、検索を担い、正式な成果物を必要とする2パーセントのケースには専門モデルが呼び出される。これを手作業で行うには、2つのベンダー、2つの契約、2つのSDK、2つの資格情報、そして誰かが保守するディスパッチ層が必要になる。これは単一のエンドポイントが元を取れるケースだ：OpenAI互換のキー1つ、数学的な形のリクエストを形式化エンドポイントに送り、それ以外を汎用モデルに送るルーティングルール、そして一方が遅い場合のフェイルオーバー。それがルーティングDSLの仕事である — 開発時に選択をハードワイヤリングするのではなく、複数のモデルを1回の呼び出しに構成すること — そして、複数のモデルが一緒に答えるパネルが有用な場合には、モデル融合がそれをカバーする。KolibriもMathForm-8Bも現在のOrcaRouterには存在しない；両方をあらゆるベンダー名とモデル表記でカタログを調査したが、どちらもそこにはない。構成の議論は、これら2つの特定のエンドポイントについてではなく、問題の形についてのものだ。

カタログに載っているのは、そのパターンの汎用型の半分であり、測定可能な価格だ。Qwen3.8-27Bは、100万入力トークンあたり$0.33、出力$2.40、262,144トークンのウィンドウで掲載されており、Qwen3.8-Maxは$2.00と$6.00、100万トークンのウィンドウだ。文書パイプラインに形式化ステップを追加する価値がそもそもあるかどうかを探っているチームにとって、安上がりな実験は、汎用作業をそこにルーティングし、本当にLean成果物を必要とするリクエストの量を測定し、そのうえで初めて、16,384トークンの専門エンドポイントをプロビジョニングする価値があるかどうかを決めることだ。プロバイダーの定価はトークンごとに何も上乗せされずそのまま渡されるので、ベンダーが価格を動かしたその日にこの数字も動く。

ライセンスは、それらが同一である唯一の行です

両者とも Apache 2.0 であり、オーダーメイドの研究用ライセンスや許容利用に関する付帯条項が当たり前となっているこのカテゴリーにおいて、これは明言する価値のある真の同等性のポイントです——つまり、どちらのモデルも、商用利用や改変、再配布を行う前に法務レビューを必要としません。

義務は別の点で分かれる。Kolibri は約78 GBの重みフットプリントと、ハードウェア最低要件として A100 80 GBカード2枚、H100 SXM5 2基、H200 1基、B200 1基または B300 1基を伴い、さらにベンダーの aleph-alpha-inference パッケージと vLLM プラグインが必要だ。bfloat16 の MathForm-8B は約16 GBの重みで、16,384トークンのコンテキストで単一の最新アクセラレータ上で動作する。その依存関係は Lean ツールチェーンと、評価パイプライン用には稼働中の Kimina Lean Server である。これらのデプロイの一方はワークステーションに収まる。もう一方は収まらない。

コンテキストの数値は逆方向に、しかも大差で作用する。Kolibri のネイティブウィンドウは 262,144 トークンで、1,048,576 まで検証済みであり、これが同モデルをドキュメントモデルたらしめている。ドイツの規制当局提出書類一式や航空宇宙整備マニュアルが 1 回の呼び出しに収まるのだ。MathForm-8B は設計上 16,384 トークンに上限が設けられている。形式化リクエストは単一の問題文であり、それより長くなる理由がないからだ。どちらの数値も欠陥ではない。単に異なる用途を表しているだけだ。

選択、およびその下の確認の質問

• 出力が検証可能でなければならないなら、MathForm-8B を選んでください。下流システムが Lean 4 を利用する場合、あるいは証明支援系が結果を承認することが目的そのものである場合、汎用モデルではそれに代われません。そして精査すべきなのは、AIME のどの行でもなく、Syntax Check と Consistency Check における Pass@8 の数値です。

• 長いコンテキストでドイツ語と英語の文書を読み、それらを横断して推論し、ツールを呼び出し、コンテキストが答えを支持しない場合には回答を控え、一行で説明できるライセンスの下で自社の境界内にデプロイできる、一つのモデルが必要なら、Kolibriを選んでください。数学はそれが持つ能力であり、それが製品であるわけではありません。

• 形式化パイプラインを構築するのであれば、両方を検討してください。二者択一としてではなく、1つのルーティングルールの背後にある2つのエンドポイントとして捉え、それを必要とする狭い範囲のリクエストに対してはスペシャリストを呼び出すのです。

そして、どちらかをベンチマークの数値の強さだけで評価しているなら、まず一つのテストを適用してください。その数値が何の成果物を残すのかを尋ねるのです。MathForm-8B の場合、Lean ファイルと、それを受け入れるか受け入れないかのどちらかであるコンパイラがあり、どちらも今日の午後には自分で実行できます。Kolibri の場合、ローンチ表にあるパーセンテージが一つあるだけで、ベンダー報告であり、再現されておらず、照合できる独立したインデックスページもありません — そして、それを反証する唯一の方法は、78 GB の重みをダウンロードし、ハードウェアを借り、ハーネスを再実行することです。本番環境に何を投入するかを決めるとき、その非対称性はスコアそのものよりも価値があります。