InternLumina-U2 vs Microsoft Mage-VL：ビジョントークンがより多くを担うべきだと静かに賭ける2つのラボ

Microsoft Mage-VLとInternLumina-U2は、どちらも研究ラボが「これはまだ製品だ」と確信できないままリリースするときのやり方で世に出た。つまり、静かに。Microsoftは2026年7月25日、何の発表もなくHugging Face上でMage-VLの重みとコードを公開した。上海AI研究所のInternLM組織も、2026年9月1日、何の発表もなくInternLumina-U2の推論コードをGitHub上で公開した。5週間の間隔を置いて、世界最大級の2つの研究所が、静かな確信——視覚をトークンに変換する方法こそがボトルネックだという確信——を共有するモデルを世に放ち、あとはコミュニティが気づくのを待った。そのうちの1つは、今日ダウンロードして実行できる。ぎこちなくではあるが。もう1つは、まったく実行できない。重みがまだ存在しないからだ。これはこの2つに関する正直な地図であり、「両者ともベンダー報告のみ、両者とも未検証」という一文が、両者にとって同じ文にならない理由の地図でもある。

5週間、表現効率への2つの賭け

この一貫した流れは、修辞ではなく実在する。Mage-VLはコーデックネイティブなビデオモデルである。すなわち、ストリームを一様にサンプリングされたフレームへとデコードし、密なパッチグリッドを凍結済みのウェブ事前学習ビジョントランスフォーマーに通すのではなく、最新のビデオコーデックの構造に従って、ストリームをアンカーフレームとその間にある圧縮モーションデータに分離し、そのコンパクトな表現を直接取り込む。Microsoftが報告する成果は、ビジュアルトークンの大幅な削減と、ストリーミング知覚経路の有意な高速化である。同社はこれを、ビデオ言語モデルにおける一種のモラベックのパラドックス——小さなリアルタイム知覚タスクが、難しいオフライン推論と同じだけの計算量を要するという問題——を修正するものとして位置づけている。Mage-VLは「観察者」である。動画を効率的に消費し、目にしたものについての質問にほぼリアルタイムで答える。

InternLumina-U2 は、同じボトルネックに対して別の方向から賭けるものだ。Mage-VL がコーデックに従って動画を圧縮するのに対し、InternLumina-U2 は同研究所が AToken と呼ぶトークナイザーを用いて、各位置を1つのコードではなく8つの相補的な離散コードで記述することで、あらゆる視覚入力を圧縮する。その賭けの核心は、単一のコードブックでは1つの視覚トークンが保持できる情報量に上限があるため、複数のコードブックによる語彙を使えば、16Bパラメータの拡散モデル1つで、理解と生成を同じインターフェースを介して行える——チャートを読む、動画の質問に答える、3Dアセットを記述する、テキストから画像を生成する、指示に応じて画像を編集する——しかも、別の生成スタックを必要としない、という点にある。Mage-VL はストリームを低コストで知覚したいと考えている。一方、InternLumina-U2 は1セットの重みで知覚と描画の両方を実現したいと考えている。

スコアボード

両モデルの数値はベンダー報告によるものであり、第三者による再現は行われていないため、スコアボードは各行に出典を明記している。

• 形状 — Mage-VL: Qwenテキストバックボーンを基盤とした、コンパクトなコーデックネイティブ視覚言語モデル（BF16で約5Bパラメータ）。画像・動画の理解向けに学習済み。InternLumina-U2: 16Bパラメータ中1BがアクティブなMoE（16B-A1B）で、理解・生成・編集に対応するスパース拡散型LLM。

• 視覚表現 — Mage-VL: ビデオコーデック構造（アンカー＋モーション）に従うコーデックネイティブトークン。ストリーミングビデオにおいて視覚トークンを75%以上削減と報告。InternLumina-U2: ATokenトークナイザーによる完全離散型8コードブックトークン。

• 機能 — Mage-VL: 画像と動画の入力を見て、テキストで回答。ストリーミング認識向けに構築されています。InternLumina-U2: テキスト、画像理解、テキストから画像生成、画像編集、動画理解、3D理解に対応しています。

• 重み — Mage-VL: 2026年7月25日よりHugging Faceで公開済み (microsoft/Mage-VL、Apache-2.0)。InternLumina-U2: 未公開 — Hugging Faceリポジトリは空のスタブであり、重みは「近日公開」と記載されている。

• 主要数値 — Mage-VL: Video-MME 64.0、NExT-QA 83.1、OVO-Bench 64.0（すべてMicrosoft報告）。InternLumina-U2: ChartQA 86.52、MathVision 33.22、VideoMME 51.26、GenEval 0.81（すべてラボ報告、予備的・部分的な結果）。

• サービングの現実 — Mage-VL: ダウンロードは可能だが、標準のvLLMやSGLangパスはない。コードはtrust_remote_codeを必要とし、現在このモデルをデプロイしている推論プロバイダーは存在しない。InternLumina-U2: 誰もサービス提供できない。重みは公開されておらず、公開されている推論ドライバーでさえ、リポジトリに存在しないチェックポイントファイルを前提としている。

「利用できるがぎこちない」は「利用できない」と同じではない。

実際に何かを構築しようとしているなら、これが最も重要な違いである。Mage-VLは、まず第一に肝心な点で本物である。ウェイトはHugging Face上にあり、モデルカードは7月下旬以降、大きなダウンロードトラフィックを記録しており、その周りにはコミュニティによる量子化版の小さなエコシステムが生まれている。{{1}}「本物」は「簡単」を意味しない。{{/1}}モデルカードにはcustom-codeタグが表示されている。ビジュアルエンコーダも、既存のサービングスタックが前提とする標準的な凍結済みViTではないし、Microsoft自身のリポジトリにも実用的な帰結が記されている——実行にはtrust_remote_codeが必要であり、ターンキー型のプロバイダ展開は存在しない、と。しかし、GPUを手にした覚悟のあるチームは、モデルをロードし、ビデオストリームを入力として与え、コーデックネイティブという仮説が自分たちのデータでも成り立つかを確認できる。InternLumina-U2とはここで大きな違いがある。同じ文はInternLumina-U2では別の結末を迎える。すなわち、覚悟のあるチームは推論コードを読むことまではできるが、そこで止まる。ロードできるウェイトが存在しないからだ。

microsoft/Mage-VL Hugging Face カード（2026年8月27日キャプチャ）— コーデックネイティブのストリーミング説明、Apache-2.0ライセンス、arXivタグ、そして現在どのプロバイダーもモデルをデプロイしていないことを示す推論プロバイダーセクション。

ベンチマークの非対称性も同じ線上にある。両モデルの数値はベンダーによる主張であり、独立した再実行はまだ行われていない。しかし、Mage-VLの主張は少なくともダウンロード可能な成果物に基づいており、主張と検証のギャップは誰かがそれを実行するかどうかだけの問題だ。一方、InternLumina-U2の主張はロードマップ上の項目に基づいている——「完全な比較表は近日公開予定のテクニカルレポートに掲載される」——そしてそれを検証できる成果物は存在しない。この研究室自身の部分的な表でさえ、同モデルが凌駕すると主張する少なくとも1つの競合相手に遅れを取っていることを示している（GenEval 0.81に対しLLaDA2.0-Uniは0.89）。これは「予備的・部分的」というラベルを文字通りに読むべき有用な注意喚起となる。

競い合うのではなく、創作できる場所

この2つを最も有意義に捉えるには、同じ仕事を競うライバルではなく、はしごの隣り合う段と見なすのがよい。Mage-VLのようなコーデックネイティブな監視役が興味深いのは、まさに常時稼働できるほど低コストだからだ。つまり、ストリームの全フレームを監視し、より大きなモデルの注目に値する何かが現れた時だけエスカレーションする存在である。そのエスカレーション先となる大きなモデルは、原理的には、InternLumina-U2が謳うような統合モデルであり得る。すなわち、何を見るかを決める常時オンのゲートであると同時に、実際にチャートを読み取り、3Dシーンを追跡し、編集済み画像を生成する深層モデルでもある。両者とも未実証だ(Mage-VLは未実証だが実行可能、InternLumina-U2は未実証で未公開)。したがって、正直な見方をすれば、これは今日実行できる直接対決ではなく、それぞれの側が独立に検証された後に構築できる合成(コンポジション)なのだ。

InternLM/InternLumina-U2 GitHubリポジトリ、2026年9月2日取得 — リポジトリのランディングページには、マルチコードブック拡散の説明、Apache-2.0ライセンスバッジ、そして公開リリースを構成する推論エントリポイントスクリプトが表示されており、重みはツリーの外に保持されています。

ルーティング層が未検証のチェックポイントをどう扱うか

これらのモデルはどちらもOrcaRouter上ではホストされておらず、その逆をほのめかすつもりもありません。Mage-VLにはどこにも標準的なサービング経路がなく、InternLumina-U2には重みがありません。この状況でルーティングDSLが本当に役立つのは、上記の構成を、個別のつなぎ込みコードではなく1回の呼び出しとして表現できる点にあります。つまり、安価で常時稼働する知覚モデルがより深いモデルへ情報を渡し、安価なモデルが何らかの変化を検知した場合にのみ高価なモデルが実行される、という連鎖です。そして、未検証のチェックポイントという問題——これは両モデルのリスクプロファイルの全体を占める問題ですが——に対しては、自動フェイルオーバーこそが、チームがMage-VLのようなモデルを、経路全体を賭けることなく実際の経路で試すことを可能にする仕組みです。新しいチェックポイントが最初に停止したり、無意味な出力を返したり、例外をスローしたりした時点で、呼び出しは自動的に実績のあるモデルへフォールバックするため、エンジニアがスイッチを切り替えるために起こされる必要はありません。200以上のモデルをカバーする単一のAPI、プロバイダーのリスト価格を0%マークアップでそのまま適用し、新しいモデルは本番環境の前面ではなくセーフティネットの背後で試されるのです。

結論

今日コーデックネイティブ動画という仮説を検証しようと思えば、Mage-VLしか存在しない。ただし「存在する」にも、独自コードやDIYでのセルフホスティングに関する但し書きが付いて回る。マルチコードブック統合モデルという仮説を検証したい場合、それは今はできない。InternLumina-U2はまだ重みを待っている仕様書にすぎないからだ。今できることは、そのアーキテクチャを読んで準備しておくことだけであり、そうすればHugging Faceのスタブが埋まった瞬間に動き出せる。Microsoftのモデルは不格好だが実在する成果物として扱い、上海AIラボのモデルは十分に文書化された約束として扱うのがよい。そしてこの対決では「ベンダー報告の未再現」という言葉が両者に当てはまることを忘れてはならない。ただ、ダウンロードできるファイルがある場合とない場合では、その言葉の意味は異なる。