MiniCPM-V 4.7 1B 対 UI-Venus 2 9B：片方はポケットに収まり、もう片方はラックを必要とする

MiniCPM-V 4.7 1B と UI-Venus 2 9B の比較は接戦とは言い難く、まさにそこが有用な点である。MiniCPM-V 4.7 1B は OpenBMB による15.5億パラメータの汎用視覚言語モデルで、2026年10月6日にアップロードされ、ベンダーのリリースノートでは10月12日付、Apache 2.0 ライセンスで、スマートフォンアプリ内で動作するほど小さい。UI-Venus 2 9B は inclusionAI による94.1億パラメータの GUI エージェントで、2026年8月26日にリリースされ、画面を見てどこをタップし、入力し、スワイプするかを判断するために特化して学習されており、その手前に vLLM サーバーを置いた GPU を前提としている。このようなリリースの背景にある、文書化された AI の障害やエージェントのインシデントはOrcaRouter AI Incident Archiveにまとめられており、各項目には独自の出典、重大度、信頼度グレード、異議ありフラグが付いている。

それらを同じ文に入れると、間違った問い——どちらが優れているか——を招いてしまう。正しい問いは、それぞれが何のためのものかだ。1.8 GBの量子化メモリに収まる汎用視覚モデルと、ScreenSpot-Proで73.0を記録するスクリーンエージェントは、代替品ではない。それらはモバイル自動化スタックの異なる2つの層であり、興味深いのはその層の境界が実際どこにあるかだ。

遠目には似て見える2つの仕事

両方のモデルはスクリーンショットを受け取り、それについてのテキストを返すことができます。似ているのはそこまでです。

MiniCPM-V 4.7 1Bは画像を読み取り、描写し、文字起こしし、抽出し、または回答します。レシートの合計金額は何か、フォームのフィールドには何が入っているか、グラフが上昇傾向にあるか、PDFのページに何が書かれているかを尋ねれば、回答を生成します。高解像度画像向けのスライス制御、切り替え可能な{{1}}4×/16×{{/1}}の視覚トークン圧縮率、動画向けのフレームサンプリングパラメータを備えています。そのドキュメントでは、単一画像チャット、複数画像チャット、動画、OCR、PDF解析、視覚的グラウンディングを扱っています — 文書と画面の読み取りワークロードです。

UI-Venus 2 9Bは画面を読み取り、アクションを出力します。そのモデルカードには閉ループが説明されています。インターフェースを観察し、タスク状態について推論し、アクションを実行し、環境からのフィードバックを次の意思決定に取り入れます。出力は文章ではなく、座標点とアクションシーケンスです。その周辺として、inclusionAIはモバイル、コンピューター、ブラウザ、グラウンディング、CAPTCHAタスク向けの参照プロンプト、アクションパーサー、実行可能な例を提供しています。モデルはポリシーであり、その周囲のハーネスが製品の半分を占めます。

その区別は、ベンチマークを参照するまでもなくアーキテクチャを決定づける。レシートを読み取る必要のあるスマートフォンアプリは前者を使う。アプリ内でタスクを完了する必要があるシステム——チェックアウトをタップで進め、フォームに入力し、スライダーCAPTCHAを解く——は後者を使い、そのOCRがどれほど優れていようと前者で代用することはできない。

ライセンスは最初のフィルターであり、ベンチマークではありません。

UI-Venus 2 9Bのモデルカードには、ほとんどの報道が飛ばしてきたリリース状況に関するセクションが含まれています。「モデルの重み」の項目では重みが含まれると記載され、「ライセンス」の項目では、モデルの重みのライセンスは最終確認待ちであり、一般公開前に追加される予定であること、また、上流の資料にライセンスに関する記述の矛盾が含まれているため、Apache-2.0の宣言は意図的に引き継がれなかったことが述べられています。

これを2回よく読んでください。重みはダウンロード可能で、ベンチマークは公開されており、技術報告書はarXivにありますが、ライセンスは未解決です。研究チームにとってはそれで問題ありません。商用製品にスクリーンエージェントを組み込んで出荷しようと計画している企業にとっては、法務レビューを完了できないことを意味します。モデルは最終的にApache 2.0になるかもしれませんし、ならないかもしれません。今日入手できる成果物からは、それを知るすべがありません。

MiniCPM-V 4.7 1BはApache 2.0の下で提供されており、そのような曖昧さはありません。そのたった一行が、商用利用の大きなカテゴリにおいて2つのモデルのうち一方を除外します — それが劣っているからではなく、保留中のライセンスは誰も予算に計上しないスケジュールリスクだからです。

スコアが付く前の、ハードウェア演算

• 重み — 1.55B の dense、約 3.1 GB（BF16）、Q4_K_M で 0.67 GB、加えて 0.90～1.11 GB のビジョンプロジェクタ vs 9.41B、4 つの safetensors シャードにまたがる約 18.8 GB（BF16） • 実行環境 — iOS、Android、HarmonyOS アプリ；Rockchip、Houmo、Intel、AMD、Arm による day-0 のチップサポート vs GPU サービング経路。vLLM で --max-model-len 262144 および --reasoning-parser q​wen3 として文書化 • コンテキスト — スペック上 262,144 トークン。完全長では KV キャッシュが重みよりもコストが高い vs 262,144 トークン（Qwen3.5-9B ベースから継承） • ビジョンスタック — 980 ピクセルタイル上の 27 層・隠れ次元 1152 のエンコーダで、エンコーダ内トークン圧縮を備える vs Qwen3.5-9B のビジョンタワー（ベースモデルから引き継ぎ） • ライセンス — Apache 2.0 vs 確認待ち。Apache-2.0 の宣言は明示的に留保 • 評価スタイル — 5 つの文章形式の図表に加え、グラフのみの比較 vs モバイル、コンピュータ、ウェブ、グラウンディング、CAPTCHA、安全性にわたる完全な数値付録 • 独立評価 — 本稿執筆時点ではどちらのモデルにもなし vs なし。ただし arXiv 2609.00028 の技術レポートは、第三者による検証が可能な実質的な成果物

ここでの差はメモリでおおよそ1桁分です。量子化すると1.8 GB、BF16では18.8 GB、4ビットに量子化すれば約5 GBになります。これはアプリとサービスの違いです。また、2つのモデルが通常別々の記事で取り上げられる理由でもあります。一方はエッジ展開の課題であり、もう一方は推論コストの課題だからです。

9Bがそのサイズに見合うのはどこか

UI-Venus 2 9Bの数値は、いずれもそのモデルカードと技術レポートでベンダーが報告したもので、サブ10B GUIクラスの最上位付近に位置づける。高解像度のプロフェッショナルソフトウェア上での要素ローカライゼーションを測るScreenSpot-Proでは73.0を報告している。VenusBench-GDでは77.1。OSWorld-G-Rでは78.5。AndroidWorldでは80.2。WebVoyagerの刷新された595タスク分割では90.8。OSWorld-Verifiedでは70.8。独自のVenusBench-CAPTCHAでは、8種類のインタラクションタイプ全体でpass@1が78.1。

それは1Bの汎用モデルが出すような数値ではなく、そうなることを意図したものでもない。それが装飾的ではなく信頼できるものになっているのは、学習の説明による。170以上の多言語アプリからなるモバイルプール、19カテゴリにまたがる4,000以上のドメインからなるWebプール、3段階の学習（マルチモーダル中間学習、5つのタスクファミリーにわたるオフラインRL、マルチティーチャーによるオンポリシー蒸留）、そして最終画面を見る単一のジャッジではなく、タスクに関連する視覚的キーポイントと複数モデルによる投票に基づく検証スキームである。カードは安全性の結果も報告している——OSHarmで攻撃成功率11.3%、OSBlindで48.8%であり、Qwen3.5-9Bベースの25.3%と79.4%に対する値だ——そしてそれを、絶対的な堅牢性の主張としてではなく、そのベースとの比較として位置づけている。これは正しい位置づけだ。

これらのどれも1Bモデルには転移しない。GUIエージェンシーは訓練されるものであり、一般的な視覚能力から自然に創発するものではない。また、どれほどOCR精度が高くても、「次へ」ボタンが何をするかを知っているポリシーの代わりにはならない。

それでも1Bが勝つ場面

3つの順位、しかもそれらは残念賞ではない。

レイテンシと可用性。ローカルの1Bモデルにはネットワークの往復も、キューも、プロバイダーの障害も、リクエストごとのコストもありません。1日に50回使われるスキャン機能にとって、それこそがプロダクト体験のすべてです。vLLMサーバーの背後の9Bモデルは高速です。しかしそれは、あらゆるホスト型モデルが高速であるのと同じ意味での高速であり、接続が切れた時点で高速ではなくなります。

設計段階からプライバシーを確保。 レシート、身分証明書、医療用書式、あるいは私的な会話のスクリーンショットは、端末上にとどめておけます。これはマーケティング上の文言ではありません。規制産業で出荷できる機能と、そうでない機能を分ける違いです。UI-Venus 2 9B 自体の安全性評価は、モデルがサーバー側で不適切な動作をすることに関するものです。1B のプライバシー特性は、画像がスマートフォンから決して外に出ないことです。

限界費用の話。ホスト型の9Bモデルでスクリーンショットを読むと、リクエストごとに、毎回、永遠にコストがかかる。ローカルの1Bモデルで読むコストはバッテリーだけだ。少量ならホスト型の方が安いが、大量の場合——現場アプリのスキャナー、アクセシビリティツール、1万件のレシートのバッチ——限界費用がゼロに近づくのはローカルモデルだけだ。

ほとんどのチームが結局実際に構築することになるスタック

この2つのどちらかを選ぶことではない。それらを重ね合わせることだ。

オンデバイスの1Bが知覚を担当する。画面を読み、テキストを抽出し、フィールドを見つけ、そこに何があるかを説明する。ほとんどの場合それで十分で、リクエストがスマートフォンの外に出ることはない。タスクがアクションを必要とする場合——ここをタップする、そこをスワイプする、このフローを完了する——その仕事はエージェントに渡され、エージェントにはアクション語彙を備えたより大きなモデルが必要になる。

その引き継ぎこそがルーティング層の真価を発揮する場面であり、それが何をし、何をしないのかを正確に述べておく価値がある。OrcaRouterは200以上...のホスト型モデルを、0%のマークアップでOpenAI互換の単一エンドポイント経由で公開し、各プロバイダーの定価をそのまま通し、自動フェイルオーバーと、1回の呼び出しでプライマリとフォールバックを保持できるルーティングDSLを備えている。これが可能にするパターンは地味だが有用だ。スマートフォンはローカルの1Bを試し、アプリは難しいケースを、ほかすべてに使っているのと同じキーでホスト型のビジョンモデルへエスカレーションし、プロバイダーが調子を崩している午後は障害ではなくフェイルオーバーイベントになる。MiniCPM-V 4.7 1BもUI-Venus 2 9Bもそのカタログには含まれていない。どちらも自分で実行するチェックポイントである。したがってルーターはスタックの周囲にある層であり、どちらのモデルを呼び出すための手段ではない。

計画しておく価値のある2つの障害モード

1つ目はエージェントとして使われる1Bの汎用モデルです。画面を正しく読み取れても、その後にどうすればよいか分からなくなります。製品がフローを説明するのではなく完了させる必要があるなら、1Bは間違ったツールであり、プロンプトでどうにかなるものではありません。

2つ目は、モデルカードのライセンス状況に基づいて出荷された9Bエージェントです。UI-Venus 2 9Bのカードには、ライセンスは保留中で、Apache-2.0の宣言は意図的に控えられたと書かれています。それが解決するまで、ScreenSpot-Proの数値がどれほど良くても、このモデルは商用目的では研究用の成果物です。「おそらくApache 2.0になるだろう」を前提に計画するチームは、値付けしていないスケジュールリスクを負っています。

結局のところ、その選択は何にかかっているのか

「このスクリーンショットを、スマホで、オフラインで、無料で、出荷可能なライセンスで読めるか」という問いなら——MiniCPM-V 4.7 1B の答えは「はい」だ。量子化で約1.8 GB、Apache 2.0 の下で、確認すべき唯一のことは、自分の端末のメモリ余裕だけである。

「このモデルはインターフェースを説明するのではなく操作できるのか」という問いであれば、UI-Venus 2 9B は学習・ベンチマーク・ハーネスを備えたモデルであり、他の何よりも先に GPU とライセンスに関する判断を必要とします。

もし問いが「両方、1つの製品で」なら、あなたは2層システムを構築している。1Bがデバイス上で知覚を行い、エージェントがサーバー上で行動を行い、エンジニアリングの仕事は両者の間の選択ではなく、両者間の引き継ぎにある。

比較が不公平に見えるのは、実際に不公平だからだ。1Bの汎用モデルと9BのGUI特化モデルは、同じ重量級でも、同じデプロイクラスでも、同じライセンス条件でもない。それを「一方が優れている」と読むのは誤りだ。両者は異なる問いに答えている。選ぶための最速の方法は、自分が実際にどの問いを立てているかを書き出すことだ。