「WeVisOne-VL-2B vs UI-Venus-2-9B」というタイトル、サブタイトル「名前が隠すサイズの差」の生成ヒーローカード。左カードはWeVisOne-VL-2Bと表示され、「2Bパラメータ」バッジと、バウンディングボックス、セグメンテーションマスク、ソフトエッジのシルエットマットのアイコンがある。右カードはUI-Venus-2-9Bと表示され、「9Bパラメータ」バッジと、ボタン上のカーソルタップ、スクリーンショット枠のアイコンがある。中央のチップには「2B vs 9B」とある。フッター:「すべての数値はベンダー報告であり、どちらのモデルも独立評価は行われていない。」
Guides & Insights

WeVisOne-VL-2B 対 UI-Venus-2-9B:名前が隠すサイズの差

著者

Rowan Sterling

公開日

最新モデル · 20すべてのモデルを見る →
ベンチマーク:Artificial Analysis · 毎日更新
すべての記事に戻る

90億パラメータというのは、この対決の呼び名が示していることではない。多くの人が書くように「WeVisOne-VL-2B vs UI-Venus 2.9B」と記すと、この組み合わせは、ほぼ同じ重みの2つの小型視覚モデルによる公平な勝負、つまりTencentのWeChat Visionチームによる新しい2Bチェックポイントと、Ant GroupのinclusionAIによる少し大きめのモデルとの対戦に見える。その前提の後半は誤りだ。UI-Venus-2-9Bは、Qwen3.5-9Bから初期化された90億パラメータのUI-Venus 2であり、「2」はサイズではなく世代を表す。2026年10月22日にHugging Faceへ公開されたWeVisOne-VL-2Bは、Qwen3-VLをバックボーンとする20億パラメータのモデルだ。したがって本当の比較は、4.5分の1のサイズで、より古い世代のバックボーンを持ち、まったく異なる種類の答えを返すモデル同士のものになる。

これもまた、ローンチを伴わずに登場した。Hugging Faceのリポジトリ、初回コミットが1つだけのGitHubリポジトリ、arXivの論文、研究プロジェクトページがある一方で、それらを結びつけるベンダーの発表もブログ記事も価格ページも存在しない。このことが、本記事が誠実にできることの範囲を規定している。重み、アーキテクチャ、ライセンス条文、論文の表は今日確認できる。独立した評価、スループット、レイテンシ、価格は確認できない。まだどれも存在しないからだ。Tencentのモデルカードはベンチマーク数値を一切公開していない。以下でWeVisOne-VL-2Bに帰されるスコアはすべて、著者自身の7つのタスク表に由来するもので、その旨が明記されている。UI-Venus-2-9Bはより古く、資料も充実しているが、その数値はまさに自己申告のままである。

その2つの名前が実際に何を表しているのか

WeVisOne-VL-2Bは知覚モデルです。画像とフレーズを渡すと、ジオメトリを返します。バウンディングボックス、点、カウント、バイナリマスク、または連続的なアルファマットです。その言語側は、画像に正規化された<0>から<1000>までの専用トークンとして座標を出力し、高密度タスクでは各ボックスをID 152,678の特別な<OBJ>トークンで閉じます。これらのトークンは、mask_decoder.ptがその背後にある隠れ状態を読み取るまでは単なるマーカーにすぎません。これは必須の9,511,460パラメータの成果物で、2番目のファイルとして提供され、カードでは「必須のコアコンポーネントであり、オプションの追加機能ではない」と説明されています。これがないとボックスが得られます。これがあるとマスクとストライド1のアルファマットが得られます。

UI-Venus-2-9Bはエージェントです。スクリーンショットとタスクを渡すと、次のタップ、クリック、キーストロークと、それを生成した推論トークンを、閉じた観察・推論・行動ループの中で返します。スクリーンショットのみのインタラクションで、グラウンディング、CAPTCHA、モバイル、Web、コンピュータ操作にわたって訓練されており、公開されているvLLMレシピでは、推論トレースがすべてのアクションより前に出力されるため、最大モデル長262,144とQwen3推論パーサーを組み合わせています。

二つを並べてみれば、食い違いはすぐに明らかになる:

• 返されるもの — WeVisOne-VL-2B からのボックス、ポイント、カウント、OCR スパン、マスク、アルファマット;UI-Venus-2-9B からの 1 つの画面アクションとその推論トレース。

• パラメータ — WeVisOne-VL-2B は 2B に別個の 9.5M デコーダーを加えた構成、UI-Venus-2-9B は 9B の dense モデルで、重みは約 4.5 倍です。

• バックボーン — WeVisOne-VL-2B 用の Qwen3-VL は、隠れサイズ 2,048 の 28 テキスト層。UI-Venus-2-9B 用の Qwen3.5-9B。異なる世代、異なるテキストスタック。

• ディスク上の重み — 両方ともbfloat16ですが、2Bは約4GB、9Bは合計約18.8GBの4つのBF16シャードです。

• コンテキスト上限 — それぞれ262,144ポジション。WeVisOne-VL-2Bの設定とUI-Venus-2-9Bのサービングコマンドから読み取った。どちらのベンダーも、それに類するものを使っていることを示していない。

• 公開されている証拠 — Tencentの論文には7つのタスク表があるがモデルカードにはなく、inclusionAIのカードには長いベンダーベンチマーク一覧があるが論文の表はない。

• ライセンス — Tencent が作成したコードは Apache 2.0、UI-Venus-2-9B の重みについては{{1}}「最終確認待ち」{{/1}}。

A screenshot of the WeVisOne-VL-2B model card on Hugging Face, captured 23 October 2026. The metadata row shows a Model size tag of 2B params, tensor type F32, an Apache-2.0 licence tag and a qwen3_vl tag. The Inference Providers panel reads 'This model isn't deployed by any Inference Provider.' The card describes a 9.5M-parameter pixel decoder, coordinate tokens from <0> to <1000>, a None return when a target is absent, and an <OBJ> instance token at ID 152678. The collection panel shows 'Updated about 1 hour ago' and the downloads figure is blank.

実用上の帰結は、一方をもう一方の代わりにはできないということだ。どちらが勝者だと教えてくれる記事は、あなたが尋ねていない質問に答えているにすぎない。完璧なマットを返す知覚モデルでも、ボタンを押すことはできない。アプリを完璧に操作できるエージェントでも、商品撮影用に欲しかった切り抜きを渡すことはできない。

小型モデルを支持する根拠は、2B対9Bという比較から示唆される以上に強い。

2Bの隣に9Bを見ると、小さい方が予算に合わせた妥協作だと考えがちだ。それが訓練された作業に関しては、Tencentの論文はそうではないと主張しており、その論文自身の結果の一つは、自社のより大型のリリースに反論している。ここにある数値はすべて著者自身のもので、著者が実行したものであり、誰も再現していない。

• ゼロショット検出 — COCOで平均F1 55.2、LVISで53.3、Dense200で61.4、VisDroneで40.4。Qwen3-VL-2Bベースラインは同じ表で45.2、40.8、10.0、23.1を記録します。注目すべきはDense200の差です。混雑シーンではベースモデルの6倍です。

• 計数 — PixMo-Countの2つのスプリットでは90.9と88.1の完全一致だが、CLOCでは27.5と26.9、KubriCountでは29.5と32.4、CountQAでは47.9。計数は単一のスキルではなく、このばらつきこそが本論文で最も正直な点だ。

• OCRローカリゼーション — IoUしきい値0.5において、HierTextで平均F1 30.5、ICDAR2015で42.6、TotalTextで42.5、SROIEで62.1。これらは座標が付与されたローカリゼーションスコアであり、文字起こしの精度ではないため、コンシューマー向けVLMで通常引用されるOCRBenchの数値とは比較できません。

• 参照セグメンテーション — RefCOCO検証で累積IoU 79.7、RefCOCO+で73.1、RefCOCOgで74.4、ReasonSegでgIoU 60.9。

• プロンプト可能なマッティング — ボックスプロンプトを使用したP3M-500-NPでは平均絶対差6.6(SAM2-Mattingは15.4)、AM-2Kでは12.1に対して5.7、より難しいWeRefMat参照分割ではQwen3-VL-8B+SAM2-Mattingパイプラインの23.0に対して15.8。全体を通じて値が低いほど優れています。

マッティング結果では、サイズに関する議論が逆転する。同じ P3M-500-NP のボックスプロンプトテストで、2B は 6.6 を記録し、Tencent 自身の 4B の兄弟モデルは 7.3 を記録する。小さいモデルの方が2つの中でより良いマッティングを行い、Tencent はその理由を説明しておらず、論文はそれでもこの結果を掲載している。画像からオブジェクトを切り抜くのがあなたの仕事なら、ファミリー内で最も安価なバリアントはダウングレードではない — 現時点で測定上最良の選択肢だ。

論文が示していないことも、同じくらい知る価値がある。7つの表のどこにも、MMMU、MMBench、DocVQA、キャプション生成のベンチマークはない。制限事項のセクションでは、限られた汎用トレーニングデータが「ベースモデルと比較して汎用能力を損なう可能性がある」と認めている。これを知覚面で優れたものにしたファインチューニングが、汎用アシスタントとしては劣化させた可能性があるが、リリース時のテストではその点は何も検証されていない。また、チェーンオブソート出力、マルチターンの記憶、動画サポートも一切ない——ピクセルデコーダは動画グリッドを完全に拒否する。

これを決着させる唯一のベンチマークは存在しない

2つの評価スイートを並べてみると、比較不能性はもはや技術的な細部ではなくなる。UI-Venus-2-9Bの主要な結果は、ある環境における最終状態の成功率だ。AndroidWorld 80.2、OSWorld-Verified 70.8、WebVoyager 90.8、Online-Mind2Web 74.0、MobileWorldはカードのデフォルトステップ予算で65.8、100ステップで75.2。これらはタスクが完了したかどうかを測定し、知覚、計画、記憶、エラー回復を単一の数値にまとめ上げている。

共通の評価軸に最も近いのはGUIグラウンディングです。つまり、高解像度スクリーンショット内の小さなインターフェース要素を特定することです。UI-Venus-2-9BはScreenSpot-Proで73.0を記録しています。WeVisOne-VL-2Bは、モデルカード、論文、プロジェクトページのいずれにおいても、ScreenSpot-Proの結果もScreenSpot-V2の結果も、その他のGUIベンチマークも一切報告していません。逆に、WeVisOne-VL-2BはOCRローカリゼーションと密なポインティングを報告していますが、UI-Venus-2-9Bはどちらも報告していません。

A screenshot of the UI-Venus-2-9B model card on Hugging Face, captured 23 October 2026. Downloads last month reads 14,210. The Safetensors panel shows a Model size metadata label of 1.47M params and tensor type BF16, alongside tags including qwen3_5, multimodal, gui and agent. The model tree is rooted at Qwen/Qwen3.5-9B-Base, inherits Qwen/Qwen3.5-9B, and marks the current checkpoint, which is the visual evidence that the 9B in the name is the parameter count. A third-party Inference Provider is listed below the card.

見出しの組み合わせをいっそう奇妙に見せる、ちょっとした引っかかりがある。inclusionAIはすでにQwen3-VLを基にした2Bモデル——UI-Venus-1.5-2B——を提供しており、そのモデルカードにはScreenSpot-Proで57.7と記載されている。これに対し、8Bの兄弟モデルは68.4、30B-A3Bは69.6だ。これは、同じバックボーン系列に属し、両系列が重視する唯一のベンチマークで測定された、WeVisOne-VL-2Bに対する真のサイズ一致の対応モデルである。ただ、この対決で名指しされているモデルは、単にそれではないのだ。

正直な立場は限定的だ。公開された数値でWeVisOne-VL-2BとUI-Venus-2-9Bを任意のタスクで比較したものはなく、2B知覚モデルをGUIグラウンディング用データセットで実行した者もいない。ScreenSpot-ProでWeVisOne-VL-2Bを実行することが、この比較で最も有用な欠けている測定だ。それは2Bの知覚専門モデルが9Bエージェントよりもうまくインターフェース要素を見つけられるか、それとも劣るかを教えてくれるし、誰かが実行するまでは、この2つを「物を見つける」能力で順位付けする人はアーキテクチャからの外挿をしているにすぎない。

オブジェクトが存在しないとき、それぞれが何を行うか

物体が存在しないときの振る舞いは、知覚モデルが静かに失敗するポイントだ。消火器がない部屋で消火器を求めると、常に答えるモデルは自信満々にラジエーターをバウンディングボックスで囲む——そして自動パイプラインでは、それがアセットライブラリ内の幻覚オブジェクトや、エージェントループ内の誤ったタップになる。

WeVisOne-VL-2B は代わりに None と回答し、論文では棄却を精度とは別の独自指標として報告している。RefCOCOg では、存在しない物体に関するクエリに対して棄却率 50.2 を報告しており、同じ表で Rex-Omni-3B は 0.5、LocateAnything-3B は 0.6 である。これは再現率を最大化するのとは異なる設計目標であり、小規模モデルをコンポーネントとして使えるようにする数値である。すなわち、「存在しない」と言うジオメトリ側の処理はプランナーに安全に渡せるが、ボックスを捏造する処理はそれを静かに破壊する。

UI-Venus-2-9Bは同じ問題に行動側から取り組み、UI-Venusシリーズから拒否を意識したグラウンディングを受け継いでいる。要求された要素が画面にない場合には、もっともらしい座標を推測するのではなく、拒否するよう訓練されている。その安全表は主張する効果を示しており、OSHarmでの攻撃成功率は11.3%で、Qwen3.5-9Bベースの25.3%に対して低い。OSBlindでは48.8%で、79.4%に対して低い。モデルカードはまた、これが有害行動のリスクを排除するものではないと明記し、人間による確認とアプリケーションレベルの保護策を推奨している。両チームともカバレッジよりも棄権を選んだが、その選択が独立に測定されたことはない。

2B を 9B の隣で実行する

これら2つのモデルの率直な関係は、競争ではなく順序です。一方は幾何情報を返し、もう一方はそれに基づいて動作します。画面自動化システムを構築しているなら、もっともらしいアーキテクチャは、WeVisOne-VL-2Bを、何がどこにあるかを報告するもの——ボックス、OCRスパン、マスク——として前に置き、UI-Venus-2-9Bを、何を行うかを決めるものとしてその後ろに置きます。それは競争ではなく構成であり、この組み合わせが運用上意味を持つ唯一の枠組みです。

メモリのおかげで、その構成は1台のマシン上で低コストに収まる。bfloat16では、2Bバックボーンはデコーダより前の重みが約4GB、9Bは4つのシャードに分けて約18.8GBになる。どちらも1枚の24GBカードに収まり、コンテキスト用の余裕も残る。2Bだけなら8GBカードに収まるという点のほうが興味深い。コンテキストの上限はどちらも262,144ポジションで一致するが、意味は異なる。エージェントは長いコンテキストをエピソード記憶として使い、スクリーンショットの履歴を保持する。一方、知覚モデルの公開評価では画像1枚あたり約1,960ビジュアルトークンで実行される。単一ターンで画像のみを扱うモデルにおける256Kウィンドウは上限であり、実証された能力ではない。

コストこそが、両者の形が分かれる点だ。どちらのベンダーもトークン単価を公表していないため、両者にとって実際のコストは、レンタルまたは自社保有のハードウェアにおけるGPU時間である。エージェントは、各ステップで9Bのフォワードパスに加えて推論トークン分を支払い、1エピソードは多くのステップにわたる——カードから予測できる数字ではない。知覚モデルは、画像ごとに2Bのパスに加えてデコーダのフォワードパス分を支払い、1画像が1回の呼び出しである。10万枚の商品写真は画像ごとの計算として予測可能だが、ブラウザタスクはそうではない。

ルーティング層が単なるスローガンではなく、その存在意義を発揮するのもここです。現時点でどちらのモデルもOrcaRouter上にはありません。209モデルのライブカタログを確認しましたが、WeVisOne-VL-2Bのカードには、どの推論プロバイダーによってもデプロイされていないと明記されています。実際に提供しているモデルについては、有用な特性はOpenAI互換の単一エンドポイント、プロバイダーの定価をそのまま反映した0%のマークアップ、複数のモデル呼び出しを1つのインターフェースの背後で組み合わせるルーティングDSL、そして自動フェイルオーバーです。上記のような2レッグ構成では、DSLが組み合わせのロジックを担う場所であり、呼び出し元を書き換えることなくどちらのレッグも差し替えられる場所です。この2つのいずれかがプロバイダー上で利用可能になった時点で、それが自分のスタックに適しているかどうかを確かめる最も安価な方法となります。

ライセンス、価格、そして誰も確認していないこと

WeVisOne-VL-2Bのカードは、「このリポジトリ内のTencentが著作したコード」にApache 2.0を付与しており、これはほとんどのチームが求める寛容な答えです。ただし、1つの詳細が事態を複雑にします。GitHub APIは、このリポジトリのライセンスをSPDX識別子のない「Other」として報告しています。これらの記述は必ずしも矛盾しているわけではありません — 第三者コンポーネントは独自の条件を維持します — しかし、それはバッジを額面通りに受け取るのではなく、これが製品に近づく前にライセンスファイルを読む価値があることを意味します。

UI-Venus-2-9Bのカードは未解決のものだ。そこには、モデルウェイトのライセンスは最終確認待ちであり、公開リリース前に追加される予定であること、また、上流の資料に矛盾するライセンス記述が含まれているため、以前のApache-2.0宣言は意図的に引き継がれなかったことが記されている。その文は8月からカードにあり、変わっていない。それは評価やほとんどの内部利用を妨げないが、それらのウェイト上に構築された外部製品は未解決の問いの上に構築されており、どんなベンチマークスコアもそれを解決しない。

どちらのモデルにもベンダー設定価格はありません。WeVisOne-VL-2Bには推論プロバイダーも料金表も存在しません。UI-Venus-2-9Bにはファーストパーティのエンドポイントがなく、inclusionAIによる価格の公開もないため、サードパーティのホストが請求する金額はそのホストの数値であり、チームの数値ではありません。

A generated two-column scoreboard titled 'WeVisOne-VL-2B vs UI-Venus-2-9B — the scoreboard'. WeVisOne-VL-2B column: Parameters 2B + 9.5M decoder; Base model Qwen3-VL; Output masks and mattes; Context 262,144; Published evals paper tables only; Licence Apache 2.0 code. UI-Venus-2-9B column: Parameters 9B dense; Base model Qwen3.5-9B; Output one screen action; Context 262,144; Published evals card benchmarks only; Licence pending confirmation. Footer: 'All figures vendor-reported; no benchmark is shared by both models.'

どちらを選ぶべきですか

その決定は順位づけではなく職務記述だ。

• 必要な答えが幾何学的情報なら、WeVisOne-VL-2B を選んでください。アノテーションパイプラインに渡すボックス、編集ツール用のマスク、商品画像用のアルファマット、密集したフレーム内のカウント、座標付きの OCR などであり、とくに小型ハードウェア上で必要ならなおさらです。これはここにあるモデルの中で、テキストプロンプトからマットを返す唯一のモデルであり、マッティングでは同シリーズのより大型のモデルをも上回り、ライセンスも確定済みのものです。

• 必要な答えが完了済みのタスク、つまりフォームの入力、アプリの操作、CAPTCHAの解決、デスクトップワークフローの実行であるなら、UI-Venus-2-9Bを選んでください。あなたが買うのはエージェントループであり、ライセンスが未解決で、このサイズでは長期的なデスクトップ作業は解決されていないことを承知の上で臨むべきです — カード自体のOSWorld 2.0の数値は、partialが7.5、binaryが0.0です。

• 実際に求めていたのが小型のGUIグラウンダーだったなら、代わりにUI-Venus-1.5-2Bを選んでください。これはinclusionAIのラインにおける2BのQwen3-VLベースモデルで、ScreenSpot-Proで57.7を報告しており、この対戦名が示唆していながら名指ししていない、サイズを揃えた比較対象です。

• 正確に見てから行動する必要がある画面自動化を構築する場合は、両方を順番に実行してください — まずジオメトリの処理、次にエージェントの処理、GPU は 1 台で。

• 待って。もしWeVisOne-VL-2BのGUIグラウンディングの数値があなたの判断を左右するなら、それはまだ存在しないし、パラメータ数から推測するのは方法ではない。

何がこの回答を変えるでしょうか

有用な順に4つ。WeVisOne-VL-2BをScreenSpot-ProまたはScreenSpot-V2で実行すれば、本稿の中心的な空白が比較へと変わる。モデルは公開から1日でApache 2.0なので、GPUと評価ハーネスを持つ人なら週末の作業だ。UI-Venus-2-9Bのライセンス解決は、どんな精度数値でも反論できない唯一の障壁を取り除く。どちらかのモデルを推論プロバイダが掲載すれば、GPU時間の計算を実際の価格に置き換えられる。そして、小さいモデルがなぜより良い結果を出すのかを説明する4B対2Bの比較は、このファミリーの命名に意味があるのかどうかを購入者に伝えるだろう。

それまでは、この2つをリーダーボード上のライバルとしてではなく、異なる道具として捉えるのが有用だ。一方は画像を測定し、もう一方は画面上で行動する。この対決の名称は、ほぼ同等の小型モデルの中から選ぶことを示唆している。しかし実際には、2Bのスペシャリストと9Bのエージェントの間で選んでいるのであり、両者が真に共有しているのは「ノー」と言う癖だけだ。