Intern-Decision-2BはひっそりとHugging Faceに公開された。そのカード上のGitHubリンクが、ちょうど404を返さなくなったところだ

のモデルカードは今日の早い時間にinternlm/Intern-Decision-2Bより詳しい情報のために3つの場所を指し示していたが、そのうち2つは死んでいた：デモSpaceはHTTP 401を返し、github.com/internlm/Intern-Decisionはクリックした誰にでも404を返した。08:58 UTC現在、その2番目のリンクの背後にあるリポジトリは存在する — 公開され、3つのコミットがあり、トレーニングコード、2つの推論バックエンド、10,751件のテスト行を含む評価バンドル、96件のキャリブレーションベンチマーク、および再現ガイドを備えている。これが、2026年9月26日05:36 UTCにHugging Faceに登場して以来、このモデルについて変わった唯一のことである。そしてそれは、Intern-Decision-2Bを「アクセス不能なREADMEを持つチェックポイント」から「実際に検査し、再現し、議論できるチェックポイント」へと移すのに十分である。

重み自体は変わっておらず、曖昧さもない。Intern-Decision-2B は、Qwen/Qwen3.5-2Bからファインチューニングされた、2,213,241,664 パラメータのマルチモーダル構造化意思決定モデルである — 2026年2月28日の Alibaba のベース — Apache-2.0 の下で公開され、上流の Qwen ライセンスがその隣に保持された状態で、そのファイル名は LICENSE-QWEN。これは InternLM が40秒で投入した3つのサイズの中央にあたる。Intern-Decision-0.8B が 05:35:57、これが 05:36:19、Intern-Decision-4B が 05:36:37 である。それらの背後にはいまだにいかなる発表もない。

中間サイズが独自の記事に値するのは、ここでこのファミリーが予測可能な振る舞いをしなくなるからだ。InternLM自身の数値によれば、これは3つの中で最速であり、3つの中で最もキャリブレーションが悪い。そして、何であれ4.5ギガバイトをダウンロードする前に、どちらの事実も理解しておく価値がある。

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

二つのカテゴリーがあり、それらは区別しておく必要がある。

確認済み。ファイル一覧またはHTTPレスポンスであるため、以下が確認できる：パラメータ数（F32が2,592個、BF16重みが2,213,239,072個）、シャードマップ（3.76 GBの言語シャード、612.5 MBのビジョンタワー、50.3 MBのプロジェクタ、テンソルが約4.43 GB、リポジトリが約4.46 GB）、ライセンスの組み合わせ、ベースモデル、その下のアーキテクチャ（Qwen3_5ForConditionalGenerationは24層、隠れサイズ2,048、クエリヘッド8に対してキー・バリューヘッド2、ヘッド次元256、線形アテンション層3つに対してフルアテンション層1つという繰り返しパターン、保持されたマルチトークン予測層1つ、埋め込み上限262,144位置）、リポジトリの存在、そしてモデルコレクション（huggingface.co/collections/internlm/intern-decision）が現在解決され、3つのチェックポイントすべてを一覧表示するという事実。

ベンダーによる報告のみで未再現：すべての精度数値、すべてのレイテンシ値、そしてキャリブレーション温度。論文も arXiv エントリも、ローンチ投稿も、変更履歴も、独立評価も存在しない——「Intern-Decision」という文字列を検索しても、このモデルに関するものは何も出てこない。デモ Space は依然として 401 を返すが、それは公開されていないという意味であり、壊れているという意味ではない。2B チェックポイントにはいいねが 1 件、ダウンロードは 0 件。InternLM の外部で誰もこれを実行していない。

推論コントラクト、それが起こる順序で

リポジトリで最も情報量の多いファイルはカードではありません。それはsrc/inference/engine.pyと、Hub 上に同梱されているinference.pyです。この2つは、プロンプトではなく契約を文書化しているからです。

• あなたが提供するもの: 状態 — 判定対象の素材 —、質問スキーマ、そしてオプションで最大8枚の画像。1～16問、各最大62個の選択肢。

• 各質問の選択肢は単一トークン記号にマッピングされます：A–Z、次に a–z、次に 0–9。62 個の選択肢の上限は設計上の好みではなく、コントラクトがアドレス指定できる単一トークン記号の数そのものです。

• システムプロンプト、状態、スキーマ、および完全なアシスタントJSONスケルトンは、<decision>プレースホルダーをフィールドごとに1つ使ってレンダリングされます。チェックポイントのチャットテンプレートと空のthinkingブロックはそのまま保持されます。

• 因果的フォワードパスが1回実行される。ロジットは各プレースホルダーの直前の位置で読み取られる — 直後ではなく、生成されたトークンの位置でもない。

• ソフトマックスはそのフィールドの正当な候補シンボルのみに対して計算され、チェックポイントのキャリブレーションが適用され、シンボルは元のオプション値にマッピングし直されます。

このカードは、これが何であるかについて率直に述べている。「このAPIは構造化された候補スコアリングを実行する。generate()を呼び出したり、自由形式のテキストをサンプリングしたりすることはない。」DecisionEngine(max_length=8192)は、大きすぎる入力を切り詰めるのではなく拒否するため、収まらないリクエストは最後の段落を静かに失うのではなく、はっきりと失敗する。バックエンドの一覧も正直である——backend="hf"がデフォルトであり、Hugging Faceリポジトリで実装されている唯一のものである。これは知っておく価値がある。というのも、GitHubリリースにはXTunerバックエンドも同梱されており、両者は数値的に同一ではないからだ。InternLM自身の評価ガイドもこう述べている。「カーネルとBF16の違いは確率を、時にはラベルを変え得る。」

真ん中の異常

InternLM自身の表で3つのチェックポイントを横に並べてみると、その形はそれだけで記事になるほど奇妙だ。

• 7つのスイートの平均 — Intern-Decision-0.8B 79.38、Intern-Decision-2B 84.68、Intern-Decision-4B 90.02。重みを大きくするにつれて予想されるように、順序よく並んでいます。

• 単一の RTX 4090 でのレイテンシ — 0.8B では平均 33.98 ms、2B では 33.28 ms、4B では 44.16 ms。中間サイズは3つの中で最速であり、その差は単一 GPU 上ではノイズと言えるほど小さいが、平均、中央値（33.15 ms）、P95（33.55 ms）を通じて一貫している。

• Brierスコア、低いほど良い — 0.530、0.437、0.347。適切なスコアリングルールが通常そうであるように、サイズとともに単調。

• 期待キャリブレーション誤差、低いほど良い — 0.8Bは0.066、この2Bは0.100、4Bは0.065。中間サイズが最悪で、その半分のサイズのモデルよりも悪い。

その最後の行が興味深く、フィットされた温度はそれを説明するというよりむしろ裏付けている。各チェックポイントはそれぞれ自身のNLLフィット温度を持つ：0.8Bでは2.747760550703、2Bでは2.100509348278、4Bでは1.992418。いずれも、1,728件の指定キャリブレーションケースでフィットされ、1,693件をホールドアウトし、[0.01, 100] での逆温度探索にわたって負の対数尤度を最小化することによって行われ、テストスイートのラベルは意図的にフィットから除外された。2Bの温度は兄弟2つの間に位置しており、異常がフィッティング上の産物であるなら予想されるとおりだ。しかしそうではない。フィット値はサイズに対して単調だが、キャリブレーション後の誤差はそうではない。InternLM自身の測定では、22億パラメータのチェックポイントは、どれだけ自信があるかを示すとき、3つの中で最も信頼できない。

これが結論になる前に、2つの注意点がある。等幅10ビンのECEと最大確率の信頼度は、この表が使う小規模スイート（Jevbench-Hard、111項目）ではノイズの多い統計量だ。つまりECE列全体が100数十問とビンの分割方法にかかっている。そしてinternlm/Intern-Decision-2Bは3枚のカードのうち、4Bカードが持つ追加のキャリブレーションセクションを備えていない唯一のカードであり、したがってここではドキュメントがより少ないのであって、より多いのではない。0.100は重みに対する判定としてではなく、自分自身の温度をフィットする理由として読むべきだ。

リポジトリが何を加え、何を依然として伏せているか

GitHubリリースはモデルカードよりもはるかに充実しており、そのモデルカード自体も示唆に富んでいる——論文用の成果物を意図した研究室が、学習ランチャーと併せて決定論的キャリブレーション生成器やハッシュ検証付き評価バンドルを通常同梱することはない。

今や公開されているもの：学習コードとマスク付き次トークン目的関数（正解の答え記号はラベルにのみ現れ、入力には決して現れない。各フィールドの答えは、そのマーカーの直前のロジットによって予測され、すべてのフィールドは1回のフォワードパスを共有する）；SHA-256で検証済みのハッシュと行数を持つ7つの精度スイート；スコアリングコード；温度フィッティングとリプレイのスクリプト（リプレイはゼロ件の判断を変えると主張されている）；生成器とオフラインスコアラーを備えた96ケースの分布キャリブレーションベンチマーク；およびループバック上で提供されるブラウザデモ（POST /v1/decisions、別名/v1/jev）。

リポジトリ自身の言葉で、明示的に除外されているものは何か：「トレーニングデータ、非公開のキャリブレーション/検証記録、画像、準備パイプライン、およびモデルの重みは含まれていません。」リポジトリにはライセンスファイルが一切存在しないため、重みはApache-2.0であっても、コードの条件は明記されていません。そして、キャリブレーション分割の構成——どの1,728件のケースが、どこから来たのか——は依然として非公開であり、これがECE数値をどこまで検証できるかを制限する唯一の欠落です。

私たちがルーティングするサイズ、そして唯一ルーティングしないサイズ

Intern-Decision-2BはOrcaRouter上にはありません。これに関する当社のモデルページは404を返し、ホストされたエンドポイントはどこを探しても見つかりませんでした。また、ここにある内容は可用性を主張するものとして受け取られるべきではありません。今日これを呼び出す唯一の方法は、チェックポイントをダウンロードし、inference.pyを重みの隣で実行することです。

そのことは、この記事が本当に扱っている意思決定にとって重要です。なぜなら、誰もサービングしていないスコアラーは、自分で運用しなければならないスコアラーだからです。あなたが下そうとしているクローズドセットの意思決定が、このファミリーが行うこと — 状態、型付きの質問、較正済みの確率 — と形が近いなら、ホスト型の比較対象は TypeSafe's Jev 1.13です。これは InternLM が意図的にベンチマーク対象としたモデルで、OrcaRouter 上で 100 万入力トークンあたり $0.042、65K コンテキスト、time-to-first-token の P50 は 178 ms です。

2.2億パラメータのチェックポイントをローカルで実行することと、ホスト型の分類器を呼び出すことは、同じ買い物ではありませんが、同じ問題です。そして、プロバイダーの定価を0%のマークアップでそのまま通す一つのキーで両方を使えることこそ、どちらか一方にアーキテクチャを賭けてしまうのではなく、比較の余地を残しておく理由なのです。

何がこの状況を変えるでしょうか

三つ、順番に。

InternLMの外部の誰かが、84.68という平均と0.100というECEを再現する必要があり、今やそれを可能にしているのがこのリポジトリだ——ここが本当のニュースである。試験は公開され、ハッシュで検証されている。欠けているのは解答用紙だけであり、その解答用紙こそ、今や誰もがダウンロードできるチェックポイントなのだ。

ベンダーは、これが何のためのものなのかを明言する必要がある。動作するトレーニングスタックと公開された評価バンドルを備えながら、告知もなく、コードにライセンスもなく、ホストされたエンドポイントもないモデルは、まだ製品として確定していない研究リリースであるかのように読める。Apache-2.0 の重みは一方の解釈を支持し、コードライセンスの欠如と 401 の Space はもう一方の解釈を支持している。

ミドルサイズには存在理由が必要だ。2Bの0.8Bに対する速度上の優位が本物であっても限定的であり、InternLMが公開したあらゆる指標でそのキャリブレーションが3つの中で最も弱いのであれば、多くの読者にとって正直な推奨は、4Bのためにディスク容量を2.6倍支払うか、より小さいモデルの劣る精度を受け入れるかである。2Bを支持する根拠は、たまたま最も速い「速いモデル」であるという点に尽きる――そしてそれは、このファミリーのマーケティング的な枠組みが示唆するよりも薄い根拠でしかない。