PixelUMM 対 Microsoft Mage-VL：一方は視覚トークナイザーを削除し、もう一方はそれを書き換える

はどちらもPixelUMM と Microsoft Mage-VLMage-VL は Microsoft のコーデックネイティブなストリーミングモデルで、トークナイザーを維持しつつ、それをはるかに攻撃的にする。現代のビデオコーデックの構造に従い、すべてのアンカーフレームと、コーデックがビットを費やす予測フレームのパッチだけを保持し、視覚トークンを75%以上削減しながら、均一なフレームサンプリングに対して最大3.5倍のウォールクロック高速化を実現したと報告している。PixelUMM は NVIDIA のエンコーダーフリーな統合モデルで、トークナイザーを完全に排除している。生ピクセルの16×16パッチがすべて、単一の線形射影を通ってバックボーンに到達し、VAE もビジョントランスフォーマーもどこにも存在しない。一方はより強く圧縮する。もう一方は圧縮をまったく拒む。そして、何かを生成できるのはそのうちの一方だけだ。

その最後の違いこそが、この組み合わせをスペック合戦よりも面白くしている。Mage-VLはウォッチャーだ — いつ話すかを決めるプロアクティブなゲートを備えたストリーミング知覚モデルである。PixelUMMは読むだけでなく描く：同じ重みが画像についての質問に答え、テキストプロンプトから新しい動画を生成する。これらは「統合ビジョンモデルとは何であるべきか」に対する相容れない二つの答えであり、各ラボの数値はそれぞれのものだ。

圧縮が行われる場所

Mage-VLの前提は、現代版モラベックのパラドックスである。視覚言語モデルは難しいオフライン推論は得意だが、単純なリアルタイム知覚は遅く、計算資源を大量に消費する。その解決策はコーデック整合だ。ストリームを一様にサンプリングされたフレームへデコードし、密なグリッドを凍結されたWeb事前学習済みViTに通す代わりに、Mage-VLはストリームをアンカー（I）フレームと予測（P）フレームに分離し、アンカーのパッチはすべて保持し、実際の動きや新しい細部を持つ予測フレームのパッチだけを保持する。エンコーダであるMage-ViTは、16×16パッチグリッド上で3D回転位置エンコーディングを用いてゼロから訓練され、明示的にコーデック非依存である。同じインターフェースが、H.264/AVCまたはHEVCの動きベクトルと残差エネルギー、あるいはニューラルコーデックの学習済みレートマップを受け入れ、アーキテクチャの変更も再学習も不要である。

PixelUMMの前提は、問題はエンコーダ自体にあり、その効率性にあるのではないというものだ。その論文は、BAGELのようなモデルが2つの視覚インターフェース——意味的特徴量のためのViTと、再構成潜在表現のためのVAE——を抱えており、これにより条件付け画像あたりの視覚コンテキストがほぼ倍増し、視覚言語事前学習パイプラインを第2のストリーム中心に再構築せざるを得なくなると主張する。PixelUMMはその両方を削除する。画像は16×16の空間パッチになり、動画は4フレームの時空間チューブレットになり、生ピクセルは単層の線形射影を通じてデコーダのみのTransformerに到達する。理解は自己回帰テキストであり、生成はピクセル空間のフローマッチングである。

• 圧縮戦略 — Mage-VL: 時間方向、コーデック由来。アンカーは保持し、予測フレームはスパース化。PixelUMM: なし。生ピクセルのパッチをすべて保持。

• ゼロから学習されるもの — Mage-VL：約1億枚のラベルなし画像と動画を用いて、視覚スタック全体を学習。PixelUMM：Qwen3-8Bの言語バックボーンの上に構築されたピクセルエンベッダーとデコーダーを学習。

• バックボーン — Mage-VL: 唯一の事前学習済みコンポーネントである Qwen3-4B-Instruct-2507 が、2層の MLP プロジェクターの背後に配置されています。PixelUMM: Qwen3-8B、合計パラメータ数は約 15.2B。

• ストリーミング動作 — Mage-VL: 認知ゲートが各ローリングウィンドウをスコアリングし、応答に値するイベントが完了するまで沈黙を保ち、その時点で初めてモデル全体を呼び出す。PixelUMM: ストリーミングモードなし。リクエストは生成または理解の呼び出しである。

それぞれがすること、そしてしないこと

Mage-VLは、画像と動画の理解、およびプロアクティブなストリーミングゲートを同時に提供する単一のチェックポイントです — 同じ重みがオフラインの質問に答え、イベントゲート型コメンタリーを駆動します。コーデックプロセッサ、ニューラルコーデックパッケージ、ゲートを同梱しています。2番目のリリース、microsoft/Mage-ViTは、ゼロからの事前学習段階で得られたスタンドアロンの視覚エンコーダであり、他のマルチモーダル学習向けのドロップイン・フロントエンドとして提供されます。Mage-VLが行わないのは生成です。読み取るのです。

PixelUMMは、テキストから画像生成、96フレーム・24fpsでのテキストから動画生成、そして画像および動画を条件とするテキストをカバーします。4つのチェックポイントを提供します — S8-F22-R05は既定で4つのタスクすべてをカバーし、S8-F18-R01は480pおよび720pでのテキストから動画生成を改善するように調整されていますが、動画理解はできません。さらに2つの中間ステージがあります。ストリーミング、編集、3Dはできません。ライブフィードを監視し、何かが起きたら話すモデルが必要なら、PixelUMMはまったく適した形ではなく、どのベンチマークの列もそのことを教えてはくれません。

導入ギャップは最初の正直なシグナルだ

2つのリリースは同じようには成熟しておらず、そのことはダウンロードカウンターがどのローンチ記事よりも率直に語っている。

• Mage-VL — 2026年7月25日にApache-2.0の下でHugging Faceに公開され、併せて技術レポートとarXiv識別子が付属している。10月初旬までに約13,800ダウンロード、414件のいいねを記録し、その周辺には小規模なコミュニティによる取り組みのエコシステムが形成されていた。

•PixelUMM — 2026年10月1日に非商用チェックポイントライセンスの下でHugging Faceで公開された。これを執筆した時点で、ダウンロード数は0、いいね数は3だった。公開からまだ数日しか経っていない。

それぞれのリリースについて、どちらのラボからもまだ発表はない——Mage-VLは7月に発表なしでリリースされ、PixelUMMは10月に発表なしでリリースされた。その対称性は確かに本物だが、それを両者が同等の成果物だ reading as? と読むのは誤りだろう。Mage-VLは10週間にわたってコミュニティの注目を集めてきたが、PixelUMMはまだ数日しか経っていない。ラボの外で誰も動かしたことのないモデルは、数千人がダウンロードしたモデルとは別物であり、この二つのうち後者のカテゴリーに入るのは片方だけだ。

スコアボード、来歴付き

すべての数値は開発元のラボ自身によるものである。Mage-VLのものはMicrosoftのモデルカードと技術レポートから、PixelUMMのものはそのプレプリントから取られている。どちらも第三者による独立した再現はなされていない。

• 視覚トークン — Mage-VL：密なフレームサンプリングと比較して75%以上の削減を報告。PixelUMM：削減なし。その主張は、生パッチが最初のエンコーディングを縮小するのではなく、2つ目のエンコーディングを排除するというものである。

• 実時間速度 — Mage-VL: 同等の精度で均一フレームサンプリングより最大3.5倍高速（Microsoftによる報告）。PixelUMM: 論文内に比較速度に関する主張はない。

• エンコーダ品質 — Mage-VL：Mage-ViTは、約1億件のラベルなしメディアから、256トークンのバジェットでCIFAR-10が99.33%、ImageNetが85.69%と報告しています。PixelUMM：ベンチマークすべきエンコーダが存在しないため、同等のエンコーダベンチマークはありません。

• 動画理解 — Mage-VL：報告されているすべての動画および時間的グラウンディングのベンチマークにおいて、Qwen3-VL-4Bを上回る改善を報告。QVHighlightで+22.5、ActivityNetで+17.1を含む。PixelUMM：MVBench 70.53、字幕なしのVideo-MME 57.33、LongVideoBench 59.61、LVBench 40.41。

• 画像理解 — Mage-VL：静的画像においてQwen3-VL-4Bと同等（マイクロソフトの報告による）。PixelUMM：MMMU 41.67、AI2D 80.12、DocVQA 90.42、ChartQA 82.96。

• 生成 — Mage-VL: なし。PixelUMM: プロンプトリライター使用時、GenEval総合0.83、DPG-Bench 85.74、VBench Part 1品質84.10。

• ストリーミング — Mage-VL: プロアクティブなイベントゲーティング。SoccerNetストリーミングにおいて、報告されている最高のTimVal、F1、ROC-AUC、PR-AUC。PixelUMM: 非対応。

• ライセンス — Mage-VL: Apache-2.0、コードおよび重み。PixelUMM: Apache-2.0のコード、チェックポイントにはNVIDIA One-Way Noncommercial Licenseが適用されます。

2つの列はランク付けできるほど十分に重なっていない。Mage-VLは、同規模の競合を上回る効率的なエンコーダを報告しており、PixelUMMは、15Bモデルが周囲の専門システムと同じ帯域に収まることを報告し、自論文で、トレーニングデータが異なるためその結果では「どのアーキテクチャが優れているかを確立できない」と明言している。

実用的な分割

スコアではなく、仕事内容で選べ。リアルタイムの動画知覚——ストリームを監視し、何かが起きたときにコメントするモニターで、トークンコストが拘束的な制約になる場合——を構築しているなら、二つの中でそれを実現するのは Mage-VL だけで、これは Apache-2.0 であり、その 4B クラスの規模ゆえに単一ノードで提供できる。画像と動画を読み取り、さらにそれらを生成もする単一モデルが必要なら、二つの中でそれを実現するのは PixelUMM だけだが、これは非商用ライセンスの研究用成果物であり、その重みは隠されたインデックスの背後にある 128 個の分散チェックポイントシャードで、テキストから動画へはデフォルトで Cosmos のガードレールを実行し、ゲート用に別途 Python 環境を必要とする。

両方の機能を必要とするチームにとって、それらを2つの直接統合ではなく1つのルーティングレイヤー経由で利用するという主張は明白です。今日はいずれもホストされていませんが、単一のキー、0%のマークアップでそのまま渡されるプロバイダーのリスト価格、そして、トラフィックの一部を新たに公開された Apache-2.0 モデルに振り向け、実績のあるモデルに残りを任せられるようにするフェイルオーバールールです。OrcaRouter は、そうした形の問題のために作られています — そして明言すると、現在、PixelUMM も Mage-VL もルーティングしていません、したがってこれはワークフローの説明であり、一覧ではありません。

それを解決するものは何だろう

重要な出来事が2つある。1つ目は、Mage-ViTのエンコーダ数値またはMage-VLの動画結果を、それらに利害関係のない誰かが独立に再実行することだ。10週間のダウンロードでも、まだそれは1件も生まれていない。2つ目は、PixelUMMのチェックポイントライセンスに対する何らかの変更だ。これは現在、研究用の成果物とデプロイ可能なものを分ける唯一の事実である。どちらかが実現するまでは、この2つについて言える有益なことといえば、Microsoftは視覚インターフェースをより安価にすることに賭け、NVIDIAはそれを取り除くことに賭けた、ということであり、どちらの賭けも、それを張った研究室の外の誰によっても評価されていない。