UI-Venus-2-9B vs Microsoft Mage-VL: スクリーンショットエージェント vs コーデックストリームウォッチャー

UI-Venus-2-9BとMicrosoft Mage-VLは、互いに1か月以内の間隔でひっそりとリリースされた。Mage-VLのリポジトリは2026年7月26日、UI-Venus-2-9Bは2026年8月26日に登場した。両者ともApache-2.0のオープンウェイトであり、Qwenファミリーのバックボーンを基盤としている。類似点はおおよそそのあたりで終わりである。その違いは程度の問題ではなく、各モデルが画面のどちらの側に存在するかという問題だ。Microsoft Mage-VLはコーデックネイティブなストリーミング知覚モデルであり、圧縮ビデオを監視し、通常の映像には沈黙を保ち、イベントが完了したときにテキストを出力する。UI-Venus-2-9BはGUIエージェントであり、静止スクリーンショットを取り込み、その状態について推論し、構造化されたアクションを出力する。一方は画面を見てそれを記述し、もう一方は画面を見てそれを操作する。この2つの選択はベンチマークによるものではない。両者が共通のベンチマークを共有していないからだ。それは、自動化が「答え」で終わるのか「アクション」で終わるのかという選択なのである。

各モデルの正体

Microsoft Mage-VLは、正式な発表なしにmicrosoft/Mage-VLリポジトリで公開された、約40億パラメータのマルチモーダルモデルであり、Qwen3-4B-Instruct-2507言語デコーダ、Mage-ViTと呼ばれるゼロから構築されたビジュアルエンコーダ、そして別個の約5億パラメータのストリーミングゲートから構成されています。その設計はビデオコーデックネイティブです。フレームを一様にサンプリングする代わりに、アンカー（I）フレームは完全に保持し、予測（P）フレームの動きに関連する重要なパッチのみを保持します。これにより、マイクロソフトは視覚トークン消費を75%以上削減し、一様サンプリングと比較して最大3.5倍のウォールクロック推論高速化を実現すると報告しています。2プロセス設計（システム1の認知ゲートが各ローリングコーデックウィンドウを監視し、システム2のVLMは応答する価値のあるイベントがある場合にのみ作動する）により、これは常時稼働のビデオウォッチャーであり、ほとんどが沈黙しているからこそ低コストです。

{{1}}UI-Venus-2-9B{{/1}}は、{{3}}VenusチームのAnt Groupラボ{{/3}}である{{2}}inclusionAIによってリリースされ{{/2}}、{{5}}Qwen3.5-9Bから初期化された{{/5}}{{4}}9B汎用GUIエージェント{{/4}}です。{{6}}インターフェースを観察し、タスクの状態を推論し、アクションを実行し、フィードバックを組み込む{{/6}}という{{7}}閉じた観察・推論・行動・フィードバックループ{{/7}}を形成しており、{{8}}そのカードは、モバイルアプリ、Webプラットフォーム、デスクトップOSを1つのチェックポイントでカバーするトレーニングを謳っています{{/8}}。{{9}}自身のモデルカードでは、AndroidWorld 80.2、OSWorld-Verified 70.8、WebVoyager 90.8、ScreenSpot-Pro 73.0を報告していますが、いずれもベンダー報告であり、独立に再現されたものはありません。{{/9}}

入力ギャップ：取得するピクセルと保持するストリーム

最も示唆に富む違いは、各モデルが何を食べるかだ。UI-Venus-2-9Bはスクリーンショットエージェントである。入力は現在の画面で、一度に1フレームずつ。256Kトークンのコンテキストウィンドウにより、長いタスクにわたってフレームの履歴を保持する。Mage-VLはストリームエージェントである。入力は圧縮動画で、その効率性はフレーム間の動きをデータとして扱うことから生まれる。従来型コーデックなら動きベクトルと残差エネルギー、ニューラル型コーデックなら学習されたレートマップがそれにあたる。これは、瞬間を見るモデルと、連続したタイムラインを見るモデルの違いだ。スクリーンショットエージェントは、キャプチャとキャプチャの間の100ミリ秒に対して構造的に盲目である——スピナー、読み込み中の画面遷移、画面上に一瞬だけ存在するホバー状態。ストリームを見るモデルは、その隙間の中で生きている。これはどちらの設計の欠陥でもない。ライブ画面上でアクションを起こす必要があるGUIエージェントと、フィードを要約する必要がある知覚モデルが、異なる入力契約を持つ異なる製品である理由が、まさにここにある。

アウトプットギャップ：行動と発言

出力側こそ、両者が比較できなくなる点です。UI-Venus-2-9Bの出力は、定義されたアクション空間における構造化されたアクション（マウス、キーボード、スクロール、ナビゲーション）であり、Qwen3スタイルの推論トークンの後に発行されます。そのトレーニングは、視覚的なノイズの中での正確な要素位置特定を促進するグラウンディングおよびCAPTCHAタスクを中心に構築されています。Mage-VLの出力はテキスト、つまり見ているものに対するイベントゲート式のコメントです。アクション空間も、関数呼び出しも、エージェントループもありません。2つのモデルカードを並べて読むと、知覚と行動の境界線の正反対の側面が見えてきます。Mage-VLは記述で終わり、UI-Venus-2-9Bはクリックで終わります。

• ジョブ — UI-Venus-2-9B: GUIエージェント、インターフェースを操作します。Microsoft Mage-VL: ストリーミング認識、インターフェースを説明します。

• 入力 — UI-Venus-2-9B: 静止スクリーンショット、256Kトークンの履歴。Microsoft Mage-VL: 圧縮動画コーデックストリーム、動きに重要なトークンのスパース性。

• 出力 — UI-Venus-2-9B：構造化されたマウス/キーボード/ナビゲーション操作。Microsoft Mage-VL：イベントゲート式テキスト解説。

• サイズ — UI-Venus-2-9B: 9B。Microsoft Mage-VL: ~4B + ~0.5B ストリーミングゲート。

• バックボーン — UI-Venus-2-9B: Qwen3.5-9B。Microsoft Mage-VL: Qwen3-4B-Instruct-2507 に加え、スクラッチから構築した Mage-ViT。

• ライセンス — 両方ともApache-2.0です（Mage-VLのカードには、リポジトリ内で研究目的のみと記載されています）。

サービスギャップ

ここでは、より新しく巨大なモデルの方が実行が容易です。UI-Venus-2-9Bは、256Kコンテキストウィンドウと標準のOpenAI互換APIを備えた単一のvLLMコマンドを文書化しています。Mage-VLは、trust_remote_codeを必要とします。これはMicrosoftのカスタムPythonを実行するためで、さらにFFmpeg、ビデオ用ニューラルコーデックパス、mamba-ssmのような依存関係も必要です。また、vLLMやSGLangのサービングスタックはまだなく、ページングアテンションも本番サービングパスもありません。MicrosoftはBF16パラメータが合計約10.6GBであると報告しており、画像作業には16GB GPUが現実的な下限で、長時間動画には24GB以上が必要です。今日本番に何かを投入したいチームにとって、UI-Venus-2-9Bの方が導入しやすい入口です。常時稼働の監視や要約パイプラインを構築するチームにとっては、Mage-VLのサービングスタックは、カスタムPythonも含めて、結局は背負うことになるものです。

存在しないスコアボード

これらの2つのモデルには共通のベンチマークが存在せず、新たに作るのは不誠実でしょう。UI-Venus-2-9Bの数値は、GUI接地・モバイル・ウェブ・コンピューター操作のベンチマーク群（ScreenSpot-Pro 73.0、AndroidWorld 80.2、WebVoyager 90.8、OSWorld-Verified 70.8、すべてベンダー報告値）に基づいています。Mage-VLの数値は、ビデオ理解・空間認識のベンチマーク群（Video-MME 64.0、NExT-QA 83.1、OVO-Bench 64.0、VSI-BenchではQwen3-VL-4Bを+11.0上回る、すべてベンダー報告値）に基づいています。この対決を正しく読む方法は、岐路として捉えることです。すなわち、タスクが「この画面上で時間とともに何が起きているかを理解する」ことであれば、Mage-VLが適切なツールであり、UI-Venus-2-9Bはその用途には作られていません。タスクが「この画面に何かを実行させる」ことであれば、その逆が当てはまります。

二人が作曲するところ

この比較の興味深いバージョンは、二者択一ではない。稼働中のアプリケーションを操作するGUIエージェントには真の盲点がある——スクリーンショットとスクリーンショットの間の時間、そして静止フレームに落ち着くことのない状態変化だ——そして、コーデックネイティブなストリーム監視モデルこそ、まさにそのギャップにおいて知覚レイヤーとして機能し得る種類のモデルであり、エージェントの次のグラウンディングパスの前に、ページの読み込みが完了したことやモーダルのアニメーションが終了したことを検出できる。Microsoftはその仕事のためにMage-VLを構築したわけではなく、Ant GroupもUI-Venus-2-9Bを第二のモデルによって操縦されるように構築したわけではない。しかし、その適合性は本物だ。このようなスタックのうち、すでに本番グレードである部分——タスクを分解するプランナーLLM、画面状態を検証するビジョンモデル、エージェントのセッションを記録する文字起こしモデル——にとって、パススルー価格設定と自動フェイルオーバーを備えた単一のAPIこそが実験を安価にするものであり、それがルーターの役割だ。UI-Venus-2-9BもMicrosoft Mage-VLも、現在OrcaRouterを通じて提供されてはいない。両者はオープンウェイトのセルフホストプロジェクトであり、もしルーティング対象のプロバイダーに到達すれば、プロバイダーの定価で表示されるだろう。

誰がどれを選ぶべきか

課題が継続的な認識なら、Microsoft Mage-VL を選びましょう。カメラ映像、画面録画、リアルタイムで要約や監視が必要なストリームを、低コストで稼働し続けられます。課題が制御なら、UI-Venus-2-9B を選びましょう。完了したアクション、入力済みフォーム、ナビゲーション済みフロー、操作済みアプリケーションで終わるタスクに適しています。そして、自動化に本当に両方が必要な場合——ストリームを知覚してから静止画に働きかける場合——この2つをペアで実行し、ストリーム監視役をイベント検出器として扱い、行動に値する瞬間をスクリーンショットエージェントに渡しましょう。両者は同じ画面の2つの半分であり、同じ仕事を奪い合う競争相手ではありません。