Intern-Decision-0.8B、何の告知もなく登場：InternLMがHugging Faceに静かに公開したもの

モデルカードのGitHubリンクは404を返す。デモSpaceは401を返す。コレクションもブログ記事も技術レポートもなく、「Intern-Decision」という文字列についての検索結果も、インターンシップの求人以外にはどこにも存在しない——それなのに今、Hugging Face上にはIntern-Decision-0.8Bが、完全でダウンロード可能なApache-2.0チェックポイントとして存在しており、Qwen3.5-0.8Bからファインチューニングされ、2026年9月26日の未明に、同じ3分間に現れた2つのより大きな兄弟——Intern-Decision-2BとIntern-Decision-4B——とともにアップロードされている。InternLMは以前にもこの形でリリースしたことがあり、だからこそ以下はすべて、発表記事ではなくリポジトリ自体から組み立てられている。この区別はここではいつも以上に重要だ。リポジトリは何が存在するかを教えてくれるが、それが何のためのものかを教えられるのはベンダーだけだからだ。

リポジトリが実際に詳しく述べていることは、一読に値するほど異例だ。これらはチャットモデルではなく、通常の意味での小型言語モデルでもない。Intern-Decision-0.8B は、ある状態、事前に書いておく名前付き質問のスキーマ、そして任意で最大8枚の画像を受け取り、1回のフォワードパスで各質問に対する回答分布を返す。generate() を呼び出すことは一切なく、サンプリングも一切しない。解析すべきテキスト出力はなく、修復すべき JSON もなく、閉じない波括弧をめぐるリトライループもない。この狭さこそがアーキテクチャのすべてであり、それがこのモデルを、TypeSafe の Jev 1.13 や Convai の Laya と同じ小さなカテゴリに置く——InternLM が明らかに意図的にベンチマークしたカテゴリである。なぜなら Jevbench は TypeSafe 自身のベンチマークであり、表の最初の列だからだ。

チェックポイントから知り得ること、チェックポイントが主張しているにすぎないこと、そしてInternLMの外部の誰も現時点では一切言えないこと。

リポジトリには実際に何が含まれているのか

カードは短く、系譜について率直だ。Intern-Decision-0.8Bは「Qwen3.5-0.8Bからファインチューニングされたマルチモーダル構造化意思決定モデル」と説明されている——Qwenベースは2026年2月28日にリリースされた——そしてリポジトリにはApache-2.0条項と並んで2つ目のライセンスファイルLICENSE-QWENが含まれており、これは派生モデルが行うべきことであり、それ自体が小さな誠実さのシグナルだ。Hugging Faceのインデックスは、3つのシャードにまたがる852,985,920個のパラメータを報告している。1.50 GBの言語シャード、176 MBの視覚シャード、25 MBのプロジェクターだ。トークナイザーファイルを含むリポジトリの総ストレージは約1.73 GBで、これにより全体は単一のコンシューマー向けGPUや十分なスペックのラップトップに余裕で収まる。

そのconfigが示しているのは、Qwenが3.5世代を通じて投入してきたアーキテクチャであり、個別注文の決定ネットワークではない。これはQwen3_5ForConditionalGenerationで、24層が「線形アテンション3層につきフルアテンション1層」という反復パターンで配置され、隠れサイズ1,024、アテンションヘッド8に対してキー・バリューヘッド2、ヘッド次元256、最大位置埋め込み262,144トークンとなっている。マルチトークン予測層は1層だけ保持されている。ビジョン経路は実在する。カードのテキストは画像処理について述べており、プロセッサは画像を受け取り、チェックポイントはそれを提供するためのビジョンタワーとプロジェクターを同梱している——つまり、リポジトリのマルチモーダルタグは、単なるタグではなく重みによって裏付けられている。

ファミリーの全体像は注目に値する。なぜなら、それがほかのすべてをどう読み解くべきかを左右するからだ。InternLMは40秒で3つのサイズをアップロードした。0.8B、次に2B、そして4Bだ。パラメータ数は852,985,920、2,213,241,664、4,539,265,536。4Bモデルのカードには、0.8Bのカードにはない追加セクションがある——96ケースの既知分布キャリブレーション・パイロットで、実施前後のスコアが付いている。その非対称性は、小型モデルに欠陥がある証拠ではない。小型モデルのドキュメントがより短い予算で書かれたという証拠であり、それは静かなリリースが示す類のものだ。

推論パスは実際にどのように動作するのか

同梱の inference.py はリポジトリ内で最も情報量の多いファイルだ。なぜなら、それはプロンプトではなく契約を記述しているからだ。シーケンスは次のようになる：

• state（判定対象）、questions（スキーマ）、および任意で画像を含むリクエストを提供します。

• 各質問の選択肢は単一トークンの記号にマッピングされます — AからZ、次に小文字、次に数字、1つの質問につき最大62個の選択肢。

• システム、状態、スキーマ、および完全なアシスタントJSONスケルトンは、フィールドごとに1つの<decision>プレースホルダーを使用してレンダリングされます。

• 因果的フォワードパスを1回実行する。ロジットは、各プレースホルダーの直前の位置で読み取られる。

• そのフィールドで許可されている候補記号のみに対してソフトマックスが適用され、チェックポイントのキャリブレーションが適用され、記号は元のオプション値にマッピングし直されます。

エンジンは3つの質問タイプを公開しています。choice は、オプション値を説明にマッピングする順序付きオブジェクトを受け取ります。score はリスト — これは文字列値「0」「1」「2」などになります — または有限の数値文字列キーを持つ順序付きオブジェクトを受け取り、モデルがカテゴリだけでなく確率で重み付けされた期待値を返せるようにします。noul は、「いいえ」が「はい」より前に来る二値決定です。レスポンスは、フィールドごとに、較正された確率分布、最大候補確率に等しい信頼度、字句順のタイブレークによる argmax 決定を返し、score の質問については期待される数値と凡例を返します。制限は明示されています。1リクエストあたり1～16件の質問、それぞれ最大62個のオプション、切り詰められるのではなく拒否される既定の入力上限 8,192 トークン、およびその上限にトークンが算入される最大8枚の画像です。

そのリストには、出力を信頼できるかどうかを左右するため、注目に値する2つの詳細があります。1つ目は、プロンプトに正解が一切挿入されないことです — モデルは、答えを見せられていない候補を採点しています。2つ目は、usage.output_tokens はテキストトークンの数ではなく、採点されたフィールドを数えているということです。これを既存のトークン予算計算に組み込む人は、その点に驚くでしょう。そしてカードは、それが発見されるままに任せるのではなく、そのことを明記しています。

ベンチマーク表と、それをどこまで信じるべきか

このセクションは読者注意：以下の数値はすべてベンダー報告であり、再現されていない。InternLMはベンチマークを選び、比較モデルを選び、評価を実施し、表を公開した。公開リーダーボードのいずれにもIntern-Decision-0.8Bの独立した実行はなく、Artificial Analysisを検索してもこのモデルに関する結果は一切出てこない。だからといって、この表が虚偽というわけではない。監査されていないということであり、各列は結果の水準よりも、結果の形を読むのに最も役立つということだ。

• Jevbench、3つのスプリット — Intern-Decision-0.8BはEasyで97.92、Originalで80.56、Hardで52.25を記録。TypeSafeのJevは同じスプリットで100.00、98.61、72.07となっている。

• 型付き決定 — 0.8B は Jev の 73.35 に対して 77.35 を記録します。これは、この分野で最小のモデルが、ベンチマークの名前の由来となったモデルを上回る唯一の列です。

• ToolACE — 0.8Bの94.52対Jevの91.29。ToolACEは関数呼び出しベンチマークであり、ツール選択でJevを上回る決定ヘッドは、この表で最も実質的な主張である。

• AG News — 88.61 対 Jev の 89.57。4分類のトピック分類において、このカテゴリーの最先端と実質的に同等。

• WildJailBreak — Jev の 96.29 に対して 64.48。これが崩壊だ。おそらく、信頼できない入力に向けるようなモデルにとって最も重要な列であり、0.8B が参照から最もかけ離れている列でもある。

• 平均 — 0.8Bでは79.38、同じシリーズの2Bモデルでは84.68、4Bでは90.02。このファミリーは急勾配で性能が伸びており、これはまさに予想されるとおりで、それ自体が、この表がフラッグシップを持ち上げるために逆算されたものではないというささやかな根拠になっている。

• キャリブレーション — 0.8B では Brier 0.530、expected calibration error 0.066。Jev は 0.358 と 0.095 を報告している。この2つを合わせて読むと、どちらか一方の数値だけから得られるよりも明確な像が見えてくる。0.8B は ECE の意味では Jev よりキャリブレーションが良い — 申告された信頼度がその精度をより密接に追跡している — 一方で、全体的な精度は有意に低い。これは、意図的にフィットさせた温度を持つ小規模モデルとしてもっともらしいプロファイルであり、偶然に公表するには嬉しくない組み合わせだ。

比較セットにはひとつ際立った特徴がある。それは決定モデルによって占められている。Jev、Laya、SemIf、Kev、JevK5 がすべて登場し、表自体のベンチマークは TypeSafe のものだ。InternLM は、競合の土俵で、競合のハーネスを使って測定されることを選び、そのうえで自社の最小モデルが負ける列を公開した。これは、リリースに合わせてマーケティングキャンペーンを計画していないチームがする類の決断だ——そしてそれは、これがどのように出荷されたかについての他のすべてと一致している。

校正温度は最も興味深い数値です

Intern-Decision-0.8B は、デフォルト温度2.747760550703を、1,728件の指定されたキャリブレーションケースと1,693件の別個の検証ケースにわたるNLL最小化によって適合させています。カードには、それを選択するためにテストスイートのラベルが使用されなかったことが明記されています。適用される変換は、p = softmax(candidate_logits.float()) に続いて calibrated_p = softmax(log(p) / T) です。

それはサンプリング温度ではなく、候補確率のキャリブレーションであり、この区別は細かすぎる話ではない。この変換は softmax の後に適用され、順序を保つため、argmax の決定をまったく変えることができない。それは信頼度、noul yes 確率、およびスコア質問の期待値を動かし、主要な判断は同一のままにする。ワークフローがラベルを読むなら、temperature は何の効果もない。ワークフローが確率を読むなら——それにしきい値を適用する、それで順位付けする、あるいは下流の期待値計算に渡す——temperature は、意味のある数値と意味のない数値の違いである。temperature=1 を渡すと未キャリブレーションの分布が返る。これは、独自のキャリブレーションをその上に適用したい人にとって有用な逃げ道だ。

温度は共有されるのではなく、チェックポイントごとにフィッティングされます。4B モデルは別の値 1.99241824 を使用しており、モデルカードには、ダウンロードしたサイズに付属する推論モジュールを使用して、そのデフォルトのキャリブレーションが一致するようにするよう指示されています。ある兄弟モデルから別の兄弟モデルへ推論ラッパーをコピーする人は、気づかないうちに誤った温度を適用してしまいます。

34ミリ秒、そして本来あり得ないはずの結果

InternLMは、ローカルのHugging Faceパスを使用して、単一のRTX 4090上でクエリごとのエンドツーエンドレイテンシを測定した。これは実際の測定値ではあるが、同時に可能な限り最も遅いサービング構成でもある。本番環境へのデプロイでは、コンパイル済みまたはバッチ処理ランタイムを使用するだろうからだ。Jevは平均109.70 ms、中央値106.30 ms、p95は146.70 msと記載されている。Intern-Decision-0.8Bは33.98 / 33.44 / 37.50 msとなっている。

注目に値する数値は 2B の兄弟モデルのほうだ。平均 33.28 ms、中央値 33.15 ms。2B は高速。0.8B と比べると、その差はノイズと言えるほど小さいが、パラメータ数が予測する方向とは逆である。これは表の誤りではなく、実際にはモデルそのものの話でもない。意思決定モデルは、長さが状態・スキーマ・選択肢の説明によって決まるプロンプトに対して、ちょうど 1 回の順伝播を行う——モデルが何かを書くことによってではない。何も書かないからだ。そのような領域のプロンプトでは、プロンプト処理が支配的で、パラメータ数は二次的なコストにすぎない。実用的な帰結は、最小のチェックポイントに手を伸ばす通常の理由——トークンごとに支払う——がここには当てはまらないということだ。0.8B を 2B より選ぶ本当の理由は、メモリフットプリントと、そのリポジトリ全体が 1.73 GB に収まるという事実であり、スループットではない。

まだ確立できないこと

これは、ローンチ記事なら答えてくれたであろう部分であり、リポジトリには答えられない部分です。

公表されたリリース日はなく、発表もなく、InternLMの公開チャネルにもこのファミリーについて説明したものは何もない。モデルカードに記載されたGitHub URLは解決しない。カードで参照されているデモSpaceは公開で閲覧できない。3つのチェックポイントをまとめたコレクションは存在しない。つまり、2Bや4Bを見つける唯一の方法は、組織のモデル一覧を見ることだ。論文は存在しない。そのため、訓練データ、チューニングのレシピ、訓練ステップ数、そして「decision tuning」が重みの何を変更したのかは、すべて明示されていない。独立した評価はなく、第三者によるレイテンシ再現もなく、InternLM以外の誰かがこのチェックポイントを実行したという証拠はまだない。

また、このカードが答えずに提起している問いが2つある。1つ目は、WildJailBreakギャップが実際には何を意味するのかである。その規模の拒否堅牢性の不足はファインチューニングの特性であり、それがベースモデル、意思決定チューニングの目的、あるいはパラメータの小ささを反映しているのかどうかは、リポジトリからは分からない。2つ目は、入力上限で何が起こるかである。8,192トークンを超えるリクエストは切り詰められるのではなく拒否される。これはスコアリングモデルにとって正しい挙動だが、それは実用的なコンテキストウィンドウが設定のうたう262,144ではないことを意味する——状態、スキーマ、オプション、画像パッチを合わせて8,192トークンに収まる分だけである。豊富なスキーマを持つ長い文書では、その上限はアーキテクチャ図が示唆するよりも早く訪れる。

これがどこに位置づけられるのか、そしてそれに賭けずに試す方法

正直に言えば、Intern-Decision-0.8 は公開済みのチェックポイントであり、その主張は監査を受けておらず、裏付けとなる文書もない。とはいえ、その組み合わせは無視する理由にはならない — 午後にはダウンロードして測定できる Apache-2.0 の重み公開は、ウェイトリスト式の API より良い状況だ — ただし、検証の負担が自分にかかるという意味ではある。エンジンはローカルディレクトリから読み込み、4090 クラスかそれ以下の GPU で動作し、モデルカードにはそのまま貼り付けられる実例リクエストが用意されている。自分のラベル付きケースに対して一日評価すれば、ベンダーの表よりも WildJailBreak の列について多くのことを教えてくれるだろう。

評価しているのが意思決定層なのであれば、有用な比較対象はホスト型のものだ。TypeSafeのJev 1.13は、InternLMがベンチマーク比較したモデルであり、今日ではOpenAI互換の単一エンドポイントを通じて、100万入力トークンあたり$0.042、出力はゼロ請求で呼び出せる——これはベンダーが公表しているのと同じ価格だ。なぜならOrcaRouterはプロバイダーの定価をマークアップなしでそのまま通しており、上乗せのマージンを加えたりはしないからだ。自己ホストの0.8B意思決定ヘッドとホスト型の意思決定APIを同じキーで、同じ午後に試すことは、同じ問いに答えるために別々の契約を2つ結線するよりも、かなり安上がりな実験だ。

これを変えるのはベンチマークではない。GitHubリポジトリが現れるか、InternLMがチューニングレシピを公開するか、そのチェックポイントの最初の独立した実行がリーダーボードに載ることだ。そのどれかが起こるまで、Intern-Decision-0.8Bを正確に説明すると、狭く、不格好で、そして完全にこのモデルに有利な内容になる。重みは本物で、推論契約はほとんどの公開済みモデルができている以上にしっかり文書化されており、マーケティングはまだ始まっていない。