Kolibri 対 Intern-Decision 4B：一方は文書を書くが、もう一方は何も書くことを拒否する

最も有益な点は、KolibriとIntern-Decision-4Bが同じ種類の対象ではないということであり、これをモデル対モデルの比較として扱うのはカテゴリー錯誤だということに気づくことだ。KolibriはAleph Alphaの781億パラメータの混合エキスパート言語モデルで、2026年10月3日に公開され、トークンあたり34.6億パラメータを活性化し、ドイツ語と英語のテキストを書く。Intern-Decision-4BはInternLMチームによる45.4億パラメータのマルチモーダル構造化意思決定モデルで、2026年9月26日にHugging Faceへアップロードされ、そのモデルカードには、generate()を呼び出したり自由形式のテキストをサンプリングしたりすることは一切ない、と明記されている。一方は文章を生成する。他方は、あなたが与えた選択肢に対する確率分布を単一のフォワードパスで出力し、文を書く能力は一切ない。両者が競合相手になるのはごく限られた一つの状況だけであり、それが具体的にどの状況なのかを正確に知ることこそ、どちらのリリースにおいても最も有益な点なのである。

2つのリリース、2つの全く異なる簡潔な主張

Kolibri のカードは、大規模スパース言語モデルの仕様である。50 層で、そのすべてが Mixture-of-Experts、各層 384 エキスパート（共有 1 個、ルーティング 6 個）、ネイティブコンテキストは 262,144 トークンで 1,048,576 まで検証済み、4 段階の推論エフォートレベル、vLLM パーサーを同梱した Hermes 形式のツール呼び出し、128×128 ブロックの FP8 重み、Apache 2.0 条件。そのトレーニングは、768 台の NVIDIA B200 上で 21 日間にわたり 20 兆トークンを実行した — 報告された 6.4×10²³ FLOPs で 392,000 GPU 時間、データセンターのオーバーヘッドを含めて推定 9.5×10² MWh（教師ありファインチューニングと強化学習を除く）。このカードの最小サービング構成は、A100 80 GB カード 2 枚、H100 SXM5 2 台、H200 1 台、B200 1 台または B300 1 台で、FP8 フットプリントは約 78 GB である。これは本格的なインフラの一部であり、テキストを生成して質問に答える。

Intern-Decision-4Bは逆の種類のオブジェクトであり、カードはそれについて爽快なほど率直だ。これはQwen3.5-4Bのファインチューンで、ビジョンタワーとプロジェクターは凍結され、言語バックボーンのみがトレーニングされる。状態、名前付き質問のスキーマ、そしてオプションで最大8枚の画像を渡すと、すべての質問に対する候補回答の分布を一度に返す。メカニズムは独特で、正確に述べる価値がある：オプションはAからZ、aからz、0から9にまたがる単一トークン記号にマップされる——62の候補なので、質問あたり最大62のオプション——プロンプトはフィールドごとに1つのプレースホルダーでレンダリングされ、モデルは各プレースホルダーの直前の位置でロジットを読む。Softmaxはそのフィールドの許可された記号ロジットのみに対して実行され、チェックポイント固有の温度が結果を調整し、記号は型付きJSONとして元のオプション値にマップし戻される。デコーディングループも、サンプリングも、散文もない。

• 出力 — Kolibri：自由に生成されたドイツ語または英語のテキスト、ツール呼び出し、推論トレース。Intern-Decision-4B：各選択肢の確率を伴う型付きJSON回答。

• パラメータ — Kolibri: 総78,103,074,560、アクティブ3,457,573,120。Intern-Decision-4B: bfloat16の4つのsafetensorsシャードにまたがる45.4億、凍結されたビジョンタワー付き。

• 入力 — Kolibri: テキストのみ。Intern-Decision-4B: テキストと最大8枚の画像。

• 質問容量 — Intern-Decision-4B: フィールドあたり最大62個の選択肢を、1回のフォワードパスで処理でき、'choice'、'score'、'noul'（はい/いいえ）の質問タイプに対応。Kolibri: 原理上は無制限だが、実際には1トークンずつ。

• 言語 — Kolibri：設計上、ドイツ語と英語。Intern-Decision-4B：Qwen3.5-4B が備えているものは何であれ、公開されている評価スイートはすべて英語。

• レイテンシー — Intern-Decision-4B：単一のRTX 4090上で、自身の測定によれば、クエリあたり平均44.16 ms、中央値44.03 ms、P95は44.60 ms。Kolibri：クエリあたりの公表された数値は一切ない。

• ライセンス — 両方とも Apache 2.0。Intern-Decision-4B には、Qwen のライセンスファイルがそのまま一緒に同梱されています。

なぜ4Bスコアラーがそもそも存在するのか

Intern-Decision-4Bが支持される理由は、それが小さいからではない。大規模生成モデルに確率を尋ねることは、それを測定することと同じではなく、その違いは測定可能だという点にある。

そのカード自身のベンチマーク表は、異例なほど多くの自己開示を伴ってこの主張を裏付けている。7つの精度スイートを通じて、Intern-Decision-4B は平均 90.02 を記録し、自身が比較対象とする最強のベースラインである Jev というモデルの 88.74 に対抗する。しかし、精度は面白くない方の半分にすぎない。この表は Brier スコアと期待キャリブレーション誤差も報告しており、そこでは様相がより厳しいものになる。4B は Brier 0.347、ECE 0.065 を記録し、Jev は 0.358 と 0.095 である。より小型の兄弟モデルたちのところで、キャリブレーションの話は本当に有益なものになる。Intern-Decision-2B は平均 84.68 で、0.8B の 79.38 を大きく上回る。それにもかかわらず、その ECE 0.100 は 0.8B の 0.066 より悪く、4B の 0.065 よりも悪い。Brier は 0.437 で、0.8B の 0.530 に対してである。2つの小規模モデルのうち最も精度が高い方こそ、自身の確信度について最も正直でない。キャリブレーションが精度とともに、あるいはパラメータ数とともに改善すると仮定していたなら、この表はその両方の点で反例である。

2つ目の別個の診断は、サンプリングされたハードラベルではなく正確な参照分布で構築された96のケースをカバーしている——ランダム抽選、合成イベント、条件付き履歴、確率パズル。そのパイロットにおける4Bモデルの誤差は、報告された指標で0.628から0.550に低下したが、比較モデルは0.595だった。カードは、このパイロットが公開された温度のフィットや選択に使用されなかったことを明示している。4Bの温度1.992418は、キャリブレーションセット上で別途フィットされた。InternLMチームはまた、ベンチマーク自体をGitHubリポジトリに投入した——決定論的生成器、参照、オフラインスコアラー——これは、キャリブレーションの主張が、第三者が信じるのではなく実際に再実行できる稀な種類であることを意味する。

Kolibriのリリースには、同等のものは何もない。その比較表は、1つのベンダーのハーネス上で14モデルのタスク精度を報告しており、生成モデルについて測定できるのは精度である。資料のどこにもキャリブレーションの数値はなく、BrierやECEもなく、「この契約条項が執行可能である確率」を、文をサンプリングして読むことなしに尋ねる方法もない。

彼らが実際に交わる唯一の継ぎ目

実際のパイプラインで両者を並べてみれば、それぞれの形はおのずと明らかになる。ドイツ語の文書ワークフローには両方の半分が必要であり、どちらのツールも相手の半分をカバーしてはいない。

Kolibriは読み書きを担う半分です。ドイツ語の契約書や技術文書を扱うチームには、262,144トークンのネイティブウィンドウ、FP8 KVキャッシュ、ドイツ語のウェブテキストで1トークンあたり平均4.90バイトとAleph Alphaが報告するバイリンガルトークナイザー、そしてHermesツール呼び出しが提供されます——つまり、申請書を要約し、返信を起草し、ツールループを駆動できるモデルです。できないのは、監査可能な形で自身の確信度を伝えることです。なぜなら、それが出力するものはすべてサンプリングされた文字列だからです。

Intern-Decision-4Bは判断を下す側の半分だ。ドイツ語のテキスト1ページと固定された選択肢の集合が与えられると、単一のコンシューマー向けGPU上で44ミリ秒で較正済みの分布を返す。生成ステップがなく、したがってサンプリング分散がまったくない。それができないのは、そもそもドイツ語のテキストを生成することであり、また公開されている評価スイートは英語である——そのドイツ語の挙動はQwen3.5-4Bベースから継承されたもので、ドイツ語向けに訓練されたものではない。これはドイツ語での展開にとって現実的な制約であり、誰も評価していないものである。

規制されたドイツ語ワークフローに対する誠実な工学的答えは、これらは一つのパイプラインの二つの段階であって、一つの枠を争う二つの候補ではない、ということです。実務上の問いは、それぞれがどこで動くかです。Kolibri には H100 が二枚、または B200 が一枚と、およそ 78 GB が必要です。Intern-Decision-4B には RTX 4090 が一枚あればよく、クエリを 45 ミリ秒未満で処理します。コストの非対称性はハードウェアでおよそ二桁であり、それは、小さなスコアラーがすべてのケースで継続的に動き、大きな生成器はケースが実際に文章を必要とするときにだけ呼び出される設計を指し示しています。これは、すべてのケースを 78B モデルに通して、その後で解釈しなければならない答えを得るよりも、安価で監査しやすい形です。

両者にとってのホスティングの実情、そしてそのレイヤーの目的

どちらのモデルもホスト型APIとしては提供されていません。私たちは思い込まずに確認しました。Intern-Decision-4Bにはベンダーのエンドポイントがありません。リリースされているのは重み、GitHubリポジトリ、Hugging Face Spaceです。そのダウンロード数といいね数は週の半ば以降動いており、人々が使い始めていることがうかがえますが、私たちが名指しするような有料の呼び出し可能ルートは、どこにもまだありません。

Kolibriも同様にAleph Alpha API SKUを持っていない——今回のリリースはウェイト、テクニカルレポート、そしてghcr.io/aleph-alpha/aleph-alpha-inferenceにあるコンテナイメージだ。また、OrcaRouterには掲載されていない。ベンダープレフィックスとモデル名のあらゆる表記でカタログを調べたが、not foundが返ってくる。我々は、そうではないかのようにほのめかすより、はっきりそう言いたい。

ここでルーティング層が変えるのは、これら2つのモデルへのアクセスではなく、どちらかのハードウェアを購入すべきかどうかを判断する際の経済性だ。生成側についての誠実な購入前テストは、すでにルーティングされた小規模なmixture-of-expertsティア——Gemma 4 26B-A4Bバリアント、入力トークン100万あたり$0.06、出力トークン100万あたり$0.33、262,144トークンのウィンドウ、テキスト・画像・動画入力対応——に対してワークロードを実行し、1つのOpenAI互換キー プロバイダーの定価で何も追加せずに、GPUを発注する前にドイツ語文書のワークロードが本当に780億パラメータを必要とするのかを確かめることだ。判断側にはそのような近道はない。なぜなら、キャリブレーションされた分布の挙動こそがこのモデルの本質であり、ルーティングされたティアにはそれができないからだ。しかし、それ自体が発見だ。つまり、4Bスコアラーこそが本当にセルフホストすることになる部分であり、生成器は今日の午後に借りられる何かに対して再テストする価値のある部分だということだ。

それを解決するものは何だろう

2つの測定値、そしてどちらもまだ存在しない。

最初は、ドイツ語入力に対するIntern-Decision-4Bです。公開されているスイートはすべて英語で、このモデルは多言語ベースをファインチューニングしたものなので、そのドイツ語でのキャリブレーションは不明です — そしてキャリブレーションこそ、言語をまたいで無償で移転する性質ではありません。96ケースの分布パイロットのドイツ語版は、誰かがこのモデルについて公開できる中で、最も情報量の多い成果物になるでしょう。

第二は、Kolibri の意思決定あたりのコストである。そのサービング経済性に関する主張は、品質と GPU あたり毎秒のデコードトークン数とのパレートフロンティアであるが、Kolibri には Artificial Analysis のページがなく、ハーネスを第三者が再現したものも存在しない。誰かが実際に実行するまでは、「780億パラメータ」はコストではなく仕様であり、その手前に 44 ミリ秒のスコアラーを置くべきだという論拠は、実測に基づくものではなく設計上の主張にとどまる。

それまでは、この組み合わせを読む正しい方法は、競争として見ることではない。Intern-Decision-4B はこの2つのうち技術的により興味深いリリースだ。なぜなら、キャリブレーション対応の構造化出力は、ほとんどどの生成モデルも提供していない能力であり、そのカードで主張を確認できるからだ。Kolibri はより重大なリリースだ。なぜなら、欧州のラボが Apache 2.0 モデルを780億パラメータで提供し、データパイプラインも併せて公開していることは、モデルの出来事というよりもサプライチェーンの出来事だからだ。どちらも他方を置き換えるものではない。両方が必要なチームは、両方を見据えて計画し、それに応じてハードウェアを見積もるべきであり、実際にエンジニアリングの労力が注がれるのは、それらを囲むハーネスである。