Microsoft-Decision-1 対 Ind-Decision-2B の生成タイトルカード。サブタイトルは「最も素早く答えるが、どれだけ確信があるかを言うのが最も苦手な中間チェックポイント」、チップには 2,213,241,664 パラメータ、temperature 2.100509348278、ECE 0.100、4090 で 33.28 ms、8,192 トークンの上限が表示されている。
Engineering & Research

Microsoft-Decision-1 対 Intern-Decision-2B:9ミリ秒高速で、測定可能なほどキャリブレーションが悪化

著者

Elias Hawthorne

公開日

最新モデル · 20すべてのモデルを見る →
ベンチマーク:Artificial Analysis · 毎日更新
すべての記事に戻る

InternLM自身の表には存在するはずのない数字が一つあり、それこそがこの比較をスペックシート以上の価値あるものにしている理由である。Intern-Decision-2B — 2,213,241,664パラメータ、Qwen/Qwen3.5-2Bからファインチューニングされ、2026年9月26日05:36:19 UTCに予告なしでHugging Faceにアップロードされた — は、単一のRTX 4090上でクエリあたり平均レイテンシ33.28 msを記録しており、これは8億5200万パラメータの兄弟モデルの33.98 msよりわずかに速い。また、ファミリー内で最悪のキャリブレーションも記録している。期待キャリブレーション誤差は0.100で、0.8Bの0.066に対してであり、フィットされた温度は2.100509348278で、0.8Bの2.747760550703に対してである。一方、Microsoft-Decision-1は、2026年10月8日よりMicrosoft Foundryで一般提供されているが、レイテンシの数値もキャリブレーション誤差も一切公表していない — あるのは、両者がどのように測定されたかを説明する方法論の段落だけである。したがって、この対決が本当に問いかけているのは、二つのうちどちらが優れているかではない。何かのミドルサイズを買うとき、あなたは何を買っているのか、ということである。

両モデルは意思決定スコアラーです。状態を入力し、限定された質問セットを入力し、較正済み確率を出力します。生成テキストはなく、解析すべきトークンもありません。その共通契約があるからこそ、違いが読み取れるものになります。Microsoft-Decision-1 は Qwen3.5-9B ベースのホスト型テキスト専用 Foundry API で、32,768トークンのウィンドウを持ち、分散重みもファインチューニング経路もありません。Intern-Decision-2B は Apache-2.0 チェックポイントで、上流の Qwen ライセンスを LICENSE-QWEN として保持し、リポジトリは約 4.46 GB、独自の推論コードを備え、どこにもホスト型エンドポイントはありません。

ミディアムサイズは実際何のためなのか

InternLMは40秒で3つのチェックポイントを公開した。0.8Bが05:35:57、これが05:36:19、4Bが05:36:37。ベンダー自身の7スイート平均では、ファミリーは期待どおりの順序で上昇する——79.38、84.68、90.02——。2Bが妥当な買い物に見えるのは、まさにここだけだ。それ以外では、誰も選ばなかっただろうサイズに見える。

プロンプト処理が意思決定呼び出しを支配しており、それがレイテンシ逆転の機械的な説明であって、謎ではない。スコアラーは、状態、スキーマ、選択肢の説明によって長さが決まるプロンプトに対して、ちょうど1回のフォワードパスを行うだけだ。モデルが書くものによって決まることは決してない。なぜならモデルは何も書かないからだ。その状況ではパラメータ数は二次的なコストなので、最小のチェックポイントに手を伸ばす通常の理由は当てはまらない。時間を節約しているのではなく、メモリを節約しているのだ。0.8Bのリポジトリ全体は約1.73 GBで、このモデルの4.46 GBと比べており、それがこれを好む正直な理由だ。2Bの唯一の実際の主張は、たまたま最速の速いものであるということで、その差はノイズと言えるほど小さい。

Microsoft-Decision-1 と比べると、その主張はほとんど無関係に近い。両モデルは同じレイテンシーの領域にはないからだ。ホスト型エンドポイントの速度は、同じ標準 SKU 上のサーバーレスかプロビジョニング済みスループットかというデプロイ形態の関数であり、モデルの関数になるのはその後の話だ。しかも Microsoft は比較対象となる呼び出しごとの数値を公表していない。Microsoft が公表しているのは、逆方向に作用する厳しい運用上の制約、すなわちバッチ推論が無効化されていることだ。大量スコアリング実行を償却できるオフラインチャネルが存在しないため、Microsoft-Decision-1 のパイプラインはあらゆる意思決定で対話型のコストを支払うことになる。一方、セルフホストのチェックポイントは、スコアリング中かどうかに関係なく GPU 時間で支払う。

中央が負けるキャリブレーション列

3枚のIntern-Decisionカードをまとめて読むと、このファミリーは予測可能な振る舞いをしなくなる。精度はサイズに対して単調だが、キャリブレーションはそうではない。2BはECE 0.100を備え、これは3つの中で最も弱い——そしてフィットされた温度は2.100509348278で、0.8Bの2.747760550703をはるかに下回る。カードは、ダウンロードしたサイズに同梱されている推論モジュールを使うよう指示している。デフォルトのキャリブレーションはチェックポイントごとに異なるため、ある兄弟モデルから別の兄弟モデルへラッパーをコピーする人は、気づかないうちに誤った温度を適用してしまう。

その変換自体は、あの0.100を重みに対する評決として扱う前に、理解しておく価値がある。それはフィールドの候補ロジットに対するsoftmaxであり、続いてその分布の対数をtemperatureで割ったものに対する2度目のsoftmaxである。最初のsoftmaxの後に実行され、順序を保持するため、argmaxをまったく変えることができない。それは信頼度、yesの確率、スコアを問う質問の期待値を動かし、ラベルは同じままにする。パイプラインがラベルを読むなら、temperatureは無操作であり、ECEは物珍しいだけだ。パイプラインが確率を読むなら——閾値処理し、それで順位付けし、期待値計算に投入するなら——0.100のECEは、あなたが書いた通りの意味を持つ閾値と、そうでない閾値との差である。正しい対応は、自分のラベル付きケースで自分のtemperatureをフィットさせることであり、重みが悪いと結論付けることではない。

Microsoft-Decision-1 は、まったく同じ作業を求めているが、出発点として与えられるものはより少ない。その Benchmarks タブには、精度、校正誤差、安全性の再現率、偽陽性率、公平性の一貫性が、公開およびコミュニティの意思決定ベンチマークに加えて、社内のホールドアウトテストセットで測定されたこと、選択肢の順序を変化させたこと、対応のある統計検定を適用したこと、そしてこのモデルは「主要な意思決定モデルと同等の性能を発揮し、同じ方法論で評価された他のオープンな意思決定モデルを上回る」と記載されている。ECE はない。Brier はない。temperature はない。精度表もない。価値提案の全体が信頼できる確率であるモデルこそ、この比較において、公表されたキャリブレーション数値をまったく持たないモデルである。

A two-column generated scoreboard titled Microsoft-Decision-1 vs Intern-Decision-2B. Left column Microsoft-Decision-1 rows read: availability Foundry GA, October 8, 2026; context 32,768 tokens; modalities text only; batch inference disabled; calibration error not published; latency not published. Right column Intern-Decision-2B rows read: availability uploaded September 26, 2026; context 8,192 tokens with oversize input rejected; modalities text plus up to eight images; batch inference not applicable, self-hosted; ECE 0.100, the worst of its three siblings; 33.28 ms mean on a single RTX 4090, the fastest of the three. A footer line reads that the InternLM figures are vendor-reported and the 2B's fitted temperature is 2.100509348278.

契約の境界:ホスト型モデルがやらない4つのこと

2つのモデルは一見同じ呼び出しを受け取るが、その相違はその周縁部に潜んでいる。

• モダリティ — Microsoft-Decision-1 は明示的にテキスト専用であり、画像、音声、映像を一切受け付けません。Intern-Decision-2B は状態とともに最大 8 枚の画像を受け付けるため、ホスト型 API ではどの精度でも対応できないスクリーンショットのトリアージやレイアウト検査の候補となります。

• 入力上限と障害モード — Microsoft-Decision-1 は最大 32,768 トークンに対する単一の呼び出しを実行します。Intern-Decision-2B は宣言します:DecisionEngine(max_length=8192)そして、過大な入力を切り詰めるのではなく拒否します。これはスコアラーにとって正しい動作であり、また、状態、スキーマ、スケルトンがすべて 1 回のパスで存在しなければならないため、硬い壁でもあります。どのようなチャンク戦略もこの契約を保持しません。

• 質問の形式 — InternLM は、1回の呼び出しにつき1~16個の質問、各質問につき最大62個の選択肢を、3つのフィールド型(choice、score、noul)にわたってドキュメント化している。ここで noul は確率を返す二値の yes/no であり、score は指定した尺度上で確率で重み付けした期待値を返す。Microsoft はその形式 — yes/no、多肢選択、評価、分類、ルーブリック — をドキュメント化しており、さらに、証拠が不十分な場合に「cannot tell」のような明示的にサポートされた棄権オプションも挙げている。これは、エスカレーション ロジックを書くあらゆる人にとって、このページで最も有用な一行である。

• 価格 — Microsoft-Decision-1 のモデルページには料金が記載されていません。料金は Microsoft の価格ページへの外部リンクになっており、決定あたりのコストは Azure または請求書から読み取るものになります。出力トークンは存在しないため、そのコストのうち出力トークンに帰属する割合は 0% です。Intern-Decision-2B は呼び出しごとのコストがゼロで、コストはすべて GPU 時間にかかり、ホスト型プロバイダーもありません。そのストレージは約 4.46 GB で、内訳は 3.76 GB の言語シャード、612.5 MB のビジョンタワー、50.3 MB のプロジェクターです。

何が確認済みで、何が単なるベンダーの話にすぎないのか

それら二つのカテゴリーを切り分けておくことこそが、このファミリーにおける規律のすべてだ。ファイル一覧または HTTP レスポンスで確認できる——パラメータ数、シャードマップ、ライセンスの対、ベースモデル、その根底にあるアーキテクチャ:24 層、隠れサイズ 2,048、クエリヘッド 8 対キー・バリューヘッド 2、ヘッド次元 256、線形アテンション層 3 につきフルアテンション層 1 という繰り返しパターン、保持されたマルチトークン予測層 1 つ、そして、8,192 トークンのエンジン上限によって事実上無意味となる 262,144 位置の埋め込み上限を備えた Qwen3_5ForConditionalGeneration。

A screenshot of the Hugging Face model card for internlm/Intern-Decision-2B, showing the internlm organisation, the image-text-to-text, Transformers, Safetensors, qwen3_5, decision-making and multimodal tags, the Demo, Model Weights and GitHub links, and the opening description of Intern-Decision-2B as a multimodal structured decision model fine-tuned from Qwen3.5-2B that accepts a shared state, a schema of named questions and optional images.

ベンダー報告であり、未再現:あらゆる精度の数値、あらゆるレイテンシの数値、そして温度。論文も、arXiv エントリも、ローンチ記事も、変更履歴も、独立した評価も存在しない。デモ Space は 401 を返す。これは壊れているのではなく、公開されていないことを意味する。モデルの後に現れた GitHub リポジトリ——3 つのコミット、学習コード、2 つの推論バックエンド、10,751 件のテスト行を含む評価バンドル、96 ケースのキャリブレーション ベンチマーク、再現ガイド——は、ほとんどの静かなリリースが得るよりも多くのドキュメントを備えているが、重みも学習データもコード ライセンスも同梱していない。マイクロソフトは異なるが隣接する立場にある。その方法論は本物で、その主張は定性的であり、どちらの企業も現在、その中心となる数値をあなた以外の誰かに検証してもらえる立場にはない。

このようなパイプラインの中でOrcaRouterがどこに位置するのか

どちらのモデルも当社のカタログにはなく、ここに書かれている内容は可用性に関する主張として読まれるべきものではありません。テキストではなく確率を返すモデルは、チャット補完をルーティングする先になるものではなく、それはこの両方に当てはまります。当社が実際に取り扱っているのは、そうしたスコアラーが奉仕するために存在するループの生成側の半分です。つまり、1つのOpenAI互換キーの背後にある200を超えるモデルが、ルーブリックを書き、候補となる回答を起草し、スコアラーが実行前に採点するツール呼び出しを発行します。プロバイダーの定価は 0%のマークアップでそのまま適用されるため、生成側でのベンダーの値下げは当日中に当社側でも反映されます。また、しきい値を1つのジャッジに賭けたくない場合、ルーティングDSLが複数のモデルを1回の呼び出しにまとめ、モデルフュージョンがそれらの一致度をスコアリングできるフィールドとして報告します。単一のプロバイダーが劣化したときも自動フェイルオーバーがその側を維持します。これは、時折ユーザーに応答するループよりも、目にするものすべてを採点するループにおいて、より重要です。

A screenshot of OrcaRouter's own model page for google/gemma-4-31b-it, showing the Google breadcrumb, the model name Gemma 4 31B, a release date of 2026-04-02, the description of it as a 30.78B dense multimodal model with text and image input, a 256K token context window and configurable thinking mode, list pricing of $0.13 per million input tokens and $0.38 per million output tokens, and a P50 time to first token figure.

結論

Microsoft-Decision-1 は 2026年10月8日から Microsoft Foundry で一般提供されています。ホスト型、テキスト専用、32,768 トークン、Microsoft がポストトレーニングした Qwen3.5-9B ベース、分散重みなし、そしてベンチマークセクションは手法を文書化していますが数値を掲載していません — レイテンシも含めて、バッチ推論はオフになっています。Intern-Decision-2B は、2026年9月26日付の 2,213,241,664 パラメータの Apache-2.0 チェックポイントで、3 つの兄弟の中で最速の 4090 上 33.28 ms であり、ECE 0.100 で最もキャリブレーションが悪く、フィットされた温度 2.100509348278 を持ちます。これはラベルを変えることはできませんが、しきい値を設定するすべての信頼度を変えます。中間サイズが欲しいなら、それに対する正直な根拠は薄いです。4B の精度のために追加の 2.7 GB を払うか、0.8B のフットプリントを受け入れるかであり、どちらの世界でも、しきい値が本番環境に近づく前に独自のキャリブレーションをフィットさせてください。

私たちが担っているのは、そうしたスコアラーが仕えるために存在するループの生成側の半分、すなわち1つのOpenAI互換キーの背後にある200を超えるモデルです。これらのモデルがルーブリックを書き、候補回答を起草し、スコアラーが実行前に採点するツール呼び出しを発行します。