Microsoft-Decision-1 vs Intern-Decision-0.8B：ホストされた空白に対する、ほんの少しのジェイルブレイクの厄介事

ローンチ記事なら省略していたであろう列から始めよう。Intern-Decision-0.8B——InternLMの852,985,920パラメータの意思決定モデルで、Qwen3.5-0.8Bからファインチューニングされ、発表も論文もなく、いまだ404を返すGitHubリンクを添えて2026年9月26日にHugging Faceへアップロードされた——その測定値はWildJailBreakで64.48、これに対するTypeSafeのJev 1.13の参照値は96.29だ。これは丸め誤差ではない。入力を見極めることだけが仕事のモデルにおける拒否堅牢性の崩壊であり、しかもそれがベンダー自身のカード上、競合他社のベンチマークが載る表の中で公開されている。これを次と並べてみよう。Microsoft-Decision-1——こちらは2026年10月8日にMicrosoft Foundryで一般提供が開始された、Qwen3.5-9Bをベースにポストトレーニングされたテキスト専用スコアラーで、評価手法は文書化されているのに、その下には結果が一つも印刷されていない——そう並べれば、この対決の本当の姿が見えてくる。一方のモデルは、自分を悪く見せる数字を教えてくれる。もう一方は、自分が使うはずだった指標を教えてくれる。

その逆転は、スペックシートよりも価値がある。どちらのモデルも、状態と範囲の限定された質問セットを受け取り、あなたの選択肢に対する確率を返す。どちらもテキストを生成せず、その軸では同じ種類の道具である。重要な違いは、誰が運用しているか、どれだけ大きいか、どれだけ検証できるか、そして、より小さく、より地味で、完全にダウンロード可能なモデルがそれでも公表することを選んだ一つの安全性の欄である。

それぞれが実際に返すもの

Microsoft-Decision-1 はホスト型 API であり、これが最初の構造上の違いです。重みは配布されません — ダウンロードも、リポジトリも、ファインチューニングの手段もありません — そして統合とは、Azure の認証、課金、ガバナンスが付随する Foundry へのデプロイを意味します。最大32,768 トークンを 1 回のパスで処理し、はい/いいえ、多肢選択、評価、分類、ルーブリック形式の質問をサポートし、入力はテキストのみで出力は数値です。証拠が不十分な場合に「判断できない」といった棄権オプションを明示的にサポートしており、これがしきい値を意味のあるものにしています。

Intern-Decision-0.8B は逆の構成です。Apache 2.0 の重みで、上流の Qwen ライセンスが LICENSE-QWEN としてその隣に保持されており、約1.73 GBのリポジトリが3つのシャードに分かれています — 1.50 GB の言語シャード、176 MB のビジョンシャード、25 MB のプロジェクター — これは単一のコンシューマー向け GPU や、十分な構成のノート PC に収まります。状態、1〜16個の名前付き質問（それぞれ最大62個の選択肢）からなるスキーマ、そして任意で最大8枚の画像を受け取り、同梱のinference.pyは、ほとんどの公開モデルがわざわざ行わないほど詳細にその契約を記述しています。選択肢は単一トークンの記号 A–Z、次に a–z、次に 0–9 にマッピングされ、ロジットは事前レンダリングされたスケルトン内の各<decision>プレースホルダーの直前の位置で読み取られ、ソフトマックスはそのフィールドの正当な候補のみに対して取られ、フィット済みの温度が適用されます。

この2つのライセンスは同じ購入対象ではない。Microsoft-Decision-1 が提供するのはマネージドエンドポイントであり、あなたが所有する成果物はない。Intern-Decision-0.8B が提供するのはあなたが所有する成果物であり、エンドポイントもサポート契約も、リポジトリ自体以外のドキュメントもない。

上限、そして監査できるキャリブレーション

2つの数値が実際の統合のほとんどを決定づけており、そのどちらもが小さい方のモデルに属している。

最初のものは8,192トークンです。Intern-Decision-0.8B の推論エンジンは、大きすぎる入力を切り詰めるのではなく拒否します。これはスコアラーにとって正しい挙動であり、同時に堅い壁でもあります。状態、スキーマ、スケルトンのすべてを 1 回のパスで処理しなければならないため、契約を維持できるチャンキング戦略は存在しないからです。Microsoft-Decision-1 の上限はその 4 倍の 32,768 で、これは Python ファイル内の定数ではなく、プロビジョニングを変えることで引き上げられるホスト側の制限です。

第二はキャリブレーションであり、ここでは方向が逆転する。InternLMは、適合させた温度2.747760550703を0.8B向けに公開しており、これは1,728件の指定されたキャリブレーションケース（うち1,693件は検証用に保持）にわたるNLL最小化によって選択されたもので、モデルカードには、その選択にテストスイートのラベルを使用していないことが明記されている。適用される変換は、そのフィールドの候補ロジットに対するsoftmaxに続いて、その分布の対数を温度で割ったものに対する2度目のsoftmaxである。この変換は最初のsoftmaxの後に実行され、順序を保持するため、argmaxをまったく変えることができない。変わるのは信頼度、yes確率、スコア質問の期待値であり、ラベルは同一のままである。パイプラインがラベルを読むなら、温度は何ももたらさない。確率を読み取り、しきい値を適用し、あるいは期待値計算に投入するなら、温度は、意味のある数値とそうでない数値の違いとなる。temperature=1を渡すと、自分でフィットしたい場合には未キャリブレーションの分布が返される。

Microsoft-Decision-1 には同等の成果物が存在しない。その Benchmarks タブには、精度、キャリブレーション誤差、安全リコール、偽陽性率、公平性の一貫性が、公開およびコミュニティの意思決定ベンチマークに加えてホールドアウトされた社内テストセットで測定されたこと、選択肢の順序を変えたこと、対応のある統計検定を適用したこと、そしてこのモデルが「同じ方法論で評価された主要な意思決定モデルと同等の性能を示し、他のオープンな意思決定モデルを上回る」ことが記載されている。印刷されたキャリブレーション誤差はなく、確認できる温度パラメータもなく、説明された検証分割もない。確率を有用にする唯一の性質——0.8 が 0.8 を意味するかどうか——は主張されているだけで、定量化されていない。

この2つの段落を読み比べれば、比較はもはやサイズの話ではなくなる。キャリブレーションを検査でき、ソフトウェアを実行できる8億パラメータのチェックポイントは、評価チームにとって、キャリブレーションが一文で済まされるホステッドAPIよりも扱いやすい対象だ。小さいモデルのほうにはレイテンシの数値も記録に残っている——InternLM自身の測定によると、単一のRTX 4090上でローカルのHugging Face経路を通した場合、クエリあたり平均33.98 ms、中央値33.44 ms、p95が37.50 ms——一方、Microsoftのそれは自前のデプロイを通じて測るもので、そこではサーバーレスとプロビジョニング済みスループットのどちらを選ぶかが、モデルそのものよりも数値を大きく動かす。

小さなモデルが負けるところ

上記のいずれも、Intern-Decision-0.8B が安全な選択である理由にはならない。そして同じ公開表がその理由を示している。WildJailBreak における 64.48対する Jev の 96.29 は、スコアラーが信頼できない入力に直面するまさにそのカテゴリにおいて、拒否堅牢性に30ポイントの差があることを意味する。意思決定モデルは、提案されたアクションを許可するかどうかを決める構成要素であることが多く、そうした立場では、言い逃れが容易なモデルは負債となる。この不足分が Qwen3.5-0.8B ベースに由来するのか、意思決定チューニングの目的関数に由来するのか、それともパラメータ数の少なさに由来するのかは、リポジトリからは分からないし、それを明らかにする論文も、学習レシピも、データの開示も存在しない。

InternLM自身の表の残りの部分は、あの列よりも好意的であり、それでもなお控えめだ。7つのスイートの平均は、0.8Bが79.38、同社自身の2Bの兄弟モデルが84.68、4Bが90.02である — このファミリーはサイズとともに急峻に上昇しており、これはこの表がフラッグシップをよく見せるために逆算されたものではないという軽度のシグナルだ。AG Newsは88.61で、Jevの89.57に対して、4クラスのトピック分類では実質的に同等だ。キャリブレーションでは、0.8Bはブライアスコア0.530、期待キャリブレーション誤差0.066を報告しており、Jevの0.358と0.095と対比される — ECEは良好だが、精度は明確に悪い。これは、意図的にフィットさせた温度を持つ小規模モデルとしてはもっともらしいプロファイルであり、マーケティングチームが偶然に公表しようと選ぶような組み合わせではない。

また、リリース日も、告知も、3つのチェックポイントをまとめたコレクションも、どこにもホストされたエンドポイントも、いかなる種類の独立した評価も存在しない。デモSpaceは401を返す。Intern-Decision-0.8Bを正しく説明するなら、未監査の主張を伴う公開済みチェックポイントである——これはウェイトリスト制のAPIよりも良い状況だ。なぜなら午後ひとつで測定できるからだ。しかし、それは検証の負担が完全にあなた側にあることを意味する。

選択と、OrcaRouterの位置づけ

Microsoft-Decision-1 を選びなさい。阻害要因が調達または規模にあるなら：何かが本番環境に到達する前に Azure 認証、統合請求、Responsible AI 評価が必要であり、32K コンテキストが必要であり、自分では運用しないエンドポイントが必要であり、あるいは手作りではなく設計に組み込まれた棄権パスが必要だからです。その代わりに、自分ではそれを実行できず、ファインチューニングもできず、そのキャリブレーションを検査できず、その中核的な主張を自分で測定することになる、という点を受け入れなさい。

コスト、メモリ、制御のいずれかが障害なら、Intern-Decision-0.8B を選べ。1.73 GB に収まり、すでに所有しているハードウェアで動作し、毎回同じラベルを生成し、チェックポイントパスを変更するだけで 2B または 4B の兄弟モデルに差し替えられる Apache-2.0 スコアラーが欲しいのだ。その代償として、8,192 トークンの壁、WildJailBreak 列、そして InternLM の外部の誰もそのカード上で何も再現していないという事実を受け入れよ。

正直な推奨は、両方を実行することです。というのも、どちらも十分に安価で、その議論はほとんど意味がないほどだからです。スコアリング呼び出し自体は、当社がルーティングするものではありません — テキストではなく確率を返すモデルはチャット補完ではなく、これらのどちらも当社のカタログにはありません。OrcaRouterが担うのは、このループのもう半分です。つまり、1つのOpenAI互換キーの背後にある200以上のモデルが、ルーブリックを起草し、候補回答を生成し、あるいはあなたのスコアラーがこれから採点しようとしているツール呼び出しを発行します。プロバイダーの定価のまま、0%のマークアップで提供され、そのため生成側のベンダー価格の引き下げは、当社側でも同日に反映されます。自動フェイルオーバーはここでは通常以上に重要です。というのも、目にするすべてを採点するパイプラインには、停滞した呼び出しを再試行する余裕がなく、ルーティングDSLを使えば、1つの判定プロンプトを複数のライターに送り、単一のものを信頼するのではなく、それらの一致を融合させることができます。

結論

Microsoft-Decision-1は、2026年10月8日にMicrosoft Foundryで一般提供を開始した。ホスト型でテキスト専用、32,768トークン、Qwen3.5-9Bを基盤とし、ベンチマーク表の代わりに方法論の段落を備えている。Intern-Decision-0.8Bは、2026年9月26日にアップロードされた1.73 GBのApache-2.0チェックポイントで、Brier 0.530、ECE 0.066、フィットされた温度 2.747760550703、4090上で33.98 msを公開している——しかも、誰も出力を求めていないWildJailBreakスコア64.48まで。どちらを採用する前に検証できることが1つだけなら、自分たちのラベル付きケースでキャリブレーションを検証することだ。それこそ、両ベンダーがあなたに見つけさせるために残した数字である。