Kolibri 対 Granite 4.2 3B：78Bのスパース性への賭け、そして同じゲームをプレイすることを拒む3Bモデル

Put KolibriとGranite 4.2 3Bを並べてみると、まず率直に言えるのは、これは公平な勝負ではないということ、しかもその不公平さは、あなたが想定する方向とは逆だということだ。KolibriはAleph Alphaの781億パラメータのMixture-of-Expertsモデルで、2026年10月3日に公開され、トークンあたり34.6億パラメータを活性化する。Granite 4.2 3BはIBMの約30億パラメータのdense推論モデルで、その重みは2026年8月7日にHugging Faceに到達し、モデルカードと技術ブログは8月25日に続いた。一方は総パラメータ数で見て他方の26倍だ。この2つが同じ意思決定の場に並ぶ理由は、どちらもApache 2.0であり、どちらもテキスト専用であり、どちらも設計上セルフホスト前提であり、そしてどちらも同じ買い手を狙っていたからだ。すなわち、自分が管理するハードウェア上でドキュメントインテリジェンスを求め、調達レビューを生き残れる来歴を求めるチームである。興味深い問いは、どちらが優れているかではない。26倍のパラメータ予算が実際に何をもたらし、それを抱えるのに何がかかるのか、である。

不一致を、端的に言えば

Granite 4.2 3Bは、Granite-4.1-3B-BaseからポストトレーニングされたスタンドアロンのDenseモデルで、IBMが8月までに出荷したGranite 4.2ファミリーの一部です。グループ化クエリ注意を備えた40層、IBMが第5の事前学習フェーズで512Kに拡張する128Kのネイティブコンテキスト、そしてクエリごとの3つの思考モード（デフォルトの完全思考、低エフォートパス、非思考パス）を備えています。IBMのモデルカードは、3Bが何ではないかについて異例なほど率直です。8Bおよび30Bの兄弟モデルとは異なり、SWE-agent、ターミナル、検索環境で訓練された特化型エージェント強化学習ブロックを意図的に省略しており、そのためIBMはこのモデルについてSWE-benchの数値を一切掲載せず、エージェントではなく推論スペシャリストとして位置づけています。

Kolibriはあらゆる軸で逆を行く。50層で、そのすべてがMixture-of-Experts、各層384エキスパートで共有1個とルーティング6個、スパース性比は約22.6対1。コンテキストはネイティブで262,144トークン、検証済みで1,048,576トークンで、モデルカードではレイテンシに敏感な作業では262,144以下に留まることを推奨している。推論エフォートレベルは4段階。Hermesスタイルのツール呼び出しで、vLLMパーサーは重みと同じリポジトリに同梱されている。そしてFP8で約78 GBのフットプリントで、モデルカードの最小構成はA100 80 GB 2枚、H100 SXM5 2枚、H200 1枚、B200 1枚、またはB300 1枚。

• パラメータ — Kolibri：合計 78,103,074,560、トークンあたり 3,457,573,120 がアクティブ。Granite 4.2 3B：約 3B の密モデルで、すべてのパラメータが各トークンでアクティブ。

• コンテキスト — Kolibri: 16,384 学習済み、65,536 中間学習済み、262,144 ネイティブ、1,048,576 検証済み。Granite 4.2 3B: 128K ネイティブ、512K に拡張。

• 思考モード — Kolibri: なし、低、中、高（チャットテンプレートで設定）。Granite 4.2 3B: フル、低エフォート、非思考（クエリごと）。

• ツール呼び出し — Kolibri：Hermes スタイルで、同梱のパーサー付き。Granite 4.2 3B：対応しているが、より大きな兄弟モデルがたどったエージェントRL訓練済みの経路ではない。

• 言語 — Kolibri: 設計上、ドイツ語と英語のみで、それ以外はありません。Granite 4.2 3B: 英語優先で、その背後にはIBMのより広範な多言語トレーニングがあります。

• フットプリント — Kolibri：FP8で約78 GB、最低2基のGPU。Granite 4.2 3B：bfloat16でおよそ6～8 GB、量子化時は2 GB未満、ラップトップクラス。

• ライセンス — いずれも Apache 2.0 で、どちらも許容利用に関する付帯条項や月間アクティブユーザー数の閾値はない。

• サービング — Kolibri: aleph-alpha-inference vLLM プラグインまたは公開コンテナイメージ。Granite 4.2 3B: vLLM、SGLang、Transformers、GGUF、Ollama を granite4.2:3b で。

追加の750億パラメータがもたらすもの

三つの事柄がある。そのうちどれが確立されたもので、どれが主張にとどまるものかを正確に見きわめることには価値がある。

最初の点はドイツ語だ。これが両モデル間の最も鮮明な実質的違いであり、ベンチマークの1行ではない。Aleph AlphaはKolibriをドイツ語・英語のバイリンガルコーパスを中心に構築し、20兆トークンの事前学習実行でドイツ語をおよそ20パーセント含めることを目標とし、最終的に2.4兆トークンのドイツ語プールを得た。その80パーセントは同ラボが自らキュレーションまたは生成したものだった。カードは、それに手間がかかった理由を説明している。重複排除されたオープンなドイツ語データセットは3900億トークンしか供給しておらず、一桁足りなかった。そのためラボはCommon Crawlのフィルターをドイツ語専用に再調整し、既存のドイツ語文書を百科事典の項目、対話、段落に言い換えた。覚えておくべきはフィルターの詳細である。標準的な言語データパイプラインは、長い単語が多すぎる文書を落とす。そしてドイツ語の行政散文は、平均語長に関する英語の上限を日常的に超えている——そのためデフォルト設定は、公的行政が書き記す文体を静かに削除してしまう。IBMはGraniteをそのコーパス向けに構築しなかった。Granite 4.2 3Bはドイツ語を扱うだろう。しかしドイツ語の法務・行政文体を中心に設計されたものではなく、その違いを教えてくれるリーダーボードは存在しない。

2つ目は、実際の文書でも通用する長いコンテキストです。Graniteの512Kという上限は確かに大きいですが、両モデルがそこに至った道筋は異なり、Kolibriの位置設計はより従来型の長文コンテキストの論拠です。IBMのRULERの数値——4.2ファミリーの公開資料にある64Kで67.52、128Kで55.30——は、128Kまでに検索品質がどれほど劣化するかを正直に開示したものとして扱い、Kolibriには同等の公表された劣化曲線がないことを覚えておいてください。

第三は生の推論の伸びしろであり、ここで正直な答えは「パラメータ比が示唆するほどではない」になる。Kolibriの学習パイプラインは、768台のNVIDIA B200上で21日間かけた20兆トークンの事前学習を実現し、Aleph Alpha自身の比較表でも、Kolibriを推論エフォート「high」に設定した場合、14モデル比較の英語平均で75.5、ドイツ語平均で70.8となり、大半の行でAlibabaの高密度270億パラメータモデルに負けている。Granite 4.2 3Bの主要な主張は同モデル自身のもので、AIME 2025で78.33、GPQAで54.80、LiveCodeBench v6で69.71、MMLU-Proで67.84。すべてIBMの報告であり、再現されていない。スイートもハーネスもベンダーも異なる。この組み合わせについて同一ハーネスの数値はどこにも存在せず、我々がそれをでっち上げるつもりもない。

それぞれが実際に優位に立つ点

マシンが制約条件なら、Granite 4.2 3Bを動かそう。bfloat16で6～8 GB、量子化すれば2 GB未満で、ノートPCにも、ワークステーション1台のGPUにも、H100を2枚なんて永遠に見ることのないエアギャップのエッジボックスにも収まる。OllamaやGGUFを含む5種類のランタイムで提供される。これは配備先が自分のラックではなく誰か他人のノートPCであるときに効いてくる。そしてそのモデルカードが並外れて信頼できるのは、まさにIBMが何を省いたかを書き記しているからだ。3BモデルについてSWE-benchの結果を主張しようとしないベンダーは、そのモデルがどこで止まるかを教えてくれている。

コーパスが主眼で、ハードウェアが存在するなら、Kolibriを実行してください。ドイツ語の契約書、技術文書、行政提出書類を抱え、既存の2基のGPUノードがあり、重みを建物の外に出さないことが要件であるチームこそ、このリリースが設計対象としたまさにその相手です。262,144トークンのネイティブウィンドウ、FP8 KVキャッシュ、4段階のエフォートレベル、Hermesのツール呼び出しパスは、いずれもチャットではなく文書ワークフローを指し示しています。バイリンガル・トークナイザーも同じ論拠の一部です。Aleph Alphaによれば、ドイツ語のウェブテキストでトークンあたり平均4.90バイト、GPT-5では4.35、Kimi K3では3.28であり、いずれもベンダーが自社コーパスで測定したもので、トークンあたりの文字数が多いことはスコアではなく推論コストに直接効く効果です。それが成り立つなら、処理するすべてのページで複利的に積み重なります。

誰も宣伝しない非対称性、それはデータだ。IBMはGranite 4.2 3Bの重みと、そのモデルがどのように構築されたかについての詳細な技術的説明を公開したが、学習データは公開しなかった。Aleph Alphaはパイプライン、データの来歴、そしてエネルギー数値をKolibriの重みとともに公開した——20兆の事前学習トークン、データセンターのオーバーヘッドを含み、教師あり微調整と強化学習を除く9.5×10² MWh。 「このモデルのテキストはどこから来たのか」に答えなければならないチームにとって、その違いは見た目だけのものではない。

両者にとってのルーティングの現実

どちらのモデルも現在、ホスト型カタログには存在しない。KolibriにはベンダーAPIのSKUが一切ない——リリースは重みと技術レポートのみ——そしてGranite 4.2 3Bは5つのランタイムスタック向けの重みとして提供され、IBMによるホスト型エンドポイントはない。どちらもセルフホスト型の提案であり、ほとんどのチームにとって実務上の問いは、どちらを採用するかではなく、そのワークロードがどちらかを自前で持つことを正当化するかどうかである。

たとえそれが扱っていないモデルであっても、ルーティング層が存在価値を持つのはまさにそういう場面だ。われわれは OrcaRouter のカタログを、両モデル名のあらゆる綴りで調べたが、Kolibri も Granite 4.2 3B もそこにはない。だからそうでないふりはしない。OrcaRouter が実際に与えてくれるのは、ハードウェアの判断が正当化されるかどうかを、それを下す前に安く確かめる方法だ。テスト経路を、すでにルーティングされている小規模な mixture-of-experts 層——Gemma 4 26B-A4B のバリアント、入力100万トークンあたり $0.06、出力100万トークンあたり $0.33、262,144トークンのウィンドウ——に向け、あなたのドイツ語文書ワークロードが本当に Kolibri の提供するものを必要としているかどうかを、1つの OpenAI 互換キーで、プロバイダーの定価で何も上乗せなしに確認する。もし本当に必要なら、勘ではなく証拠をもって GPU を買う。必要でなければ、ハードウェアの発注を1件節約できたことになる。

評決、そしてそれを変えるもの

これは勝者を決める対決ではない。KolibriとGranite 4.2 3Bは、異なる価格帯で異なる問いに答えている。そして唯一誠実な順位付けは制約による。制約がハードウェアなら、Granite 4.2 3Bが二者のうち唯一条件を満たす。制約がオンプレミスでのドイツの規制文体の文書作業なら、Granite 4.2 3Bはそもそも候補にすら入っておらず、Kolibriのほうがより興味深い成果物だ——正規の78Bオープンウェイト公開であり、Apache 2.0で、データパイプラインとトークナイザーが重みと並んで公開されている。

比較に決着をつけるものは2つある。ドイツ語の文書QAタスクでKolibriを独立に実行すれば、このリリースが本来立証しようとしていた主張を検証できる——現在それを測定しているリーダーボードは存在しないからだ。そしてGranite 4.2 3Bの推論スコアを独立に再現できれば、そもそも780億パラメータを必要としなかったワークロードの一部分で、ラップトップ級のマシンが互角に渡り合えるかどうかが分かる。そのどちらかが実現するまでは、パラメータ数ではなく制約で選べ。