タイトルが「WeVisOne-VL-2B」、サブタイトルが「Tencentは知覚モデルを出荷したが、発表しなかった」の生成されたヒーローカード。画像カード、「<OBJ>」とラベル付けされたボックス、「アルファマット」の切り抜きという3ステップの図を示し、さらに「2026年10月22日」と表示された日付チップを備えている。
Guides & Insights

WeVisOne-VL-2B:Tencentは知覚モデルをリリースしながら、誰にも知らせなかった

著者

Elias Hawthorne

公開日

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

WeVisOne-VL-2Bのモデルカードで最も重要な一文は、モデルそのものについてではない。それはmask_decoder.ptというファイルについてだ。パラメータ数は9,511,460で、「必須の中核コンポーネントであり、任意の追加機能ではない」と、あっさりした一文で説明されている。Tencentの新しい知覚モデルがどう振る舞うか——ボックス、点、バイナリマスク、連続アルファマットのどれが得られるか——はすべてそのデコーダを通る。そしてそれが属するモデルは、ほとんど前置きなしに登場した。WeVisOne-VL-2Bの重みは2026年10月22日09:47 UTCにHugging Faceへ公開され、GitHubリポジトリはその50分前に現れ、論文も同日に投稿されたが、Tencentはローンチ記事も、それらに添える発表も一切出していない。

読者にとってそれが意味するのは、範囲は狭いが有用だということだ。これは登録して使える製品ではない。ダウンロードできる研究リリースであり、モデルカードには繰り返されていない数値を報告する論文と、ほとんどのベンダーなら明言しないほど率直にカードが示す一連の制約を伴っている。以下では、リポジトリから確認できること、論文で主張されていること、そしてまだ誰も検証していないことを述べる。

何が到着したのか、そしてそれがどれほど静かに起きたかを示すタイムスタンプ

ここに示すすべての日付は、プレスリリースではなく公開されたタイムスタンプに由来しています。というのも、プレスリリースは存在しないからです:

• Hugging Face — tencent/WeVisOne-VL-2Bは2026-10-22 09:47:50 UTCに作成されました。4Bの兄弟モデルはその24秒後に作成されており、これはファイルが一括でプッシュされたときの組織アップロードの典型例です。

• GitHub — Tencent/WeVisOne-VLは同日午前08:58:16 UTCに作成されました。本稿執筆時点では、「Initial public release of WeVisOne-VL」という単一のコミットが1件あり、そのタイムスタンプは2026-10-23 08:14 UTC、スター数は46です。

• 論文 — arXiv 2610.31329、「WeVisOne-VL: Unified Visual Perception from Objects to Pixels」、v1は2026年10月22日に提出、著者はTianming Liang、Junyi Pan、Yuxi Li、Canmiao Fu、Zhipeng Huang、Chong Sun、Chen Li、Jing Lyuで、全員がTencent Inc.のWeChat Vision所属。

• プロジェクトページ — tencent.github.io/WeVisOne-VLが公開されました。デモ、手法セクション、結果表を掲載しています。これは製品ページではなく研究ページであり、価格設定、API、サインアップはありません。

カード自体は確認時点で3件の「いいね」が表示され、4Bのほうは1件だった。ダウンロードカウンターは0を示していたが、これは主にカウンターに遅延があることを物語っている。率直にまとめると、ラボの外でこれにまだ触れた人はほとんどおらず、今週公開される記事は—これも含め—結果ではなく論文とリポジトリを基にしている。

調達で必ず話題になるので、指摘しておきたい点が一つある。モデルカードは「このリポジトリ内の Tencent が作成したコード」に Apache 2.0 を付与している。GitHub API は、そのリポジトリのライセンスを SPDX 識別子のない「Other」として報告している。この二つの記述は必ずしも矛盾しているわけではない——第三者コンポーネントは独自の条件を維持しており、モデルカードもそう述べている——が、これは、これが製品に少しでも近づく前にライセンスファイルを読む価値があることを意味している。

A generated one-column scoreboard titled 'WeVisOne-VL-2B — the scoreboard' listing Parameters 2B + 9.5M decoder, Base model Qwen3-VL, Licence Apache 2.0, Benchmarks on card none, Hosted endpoint none, and COCO detection F1 55.2 (vendor), with the footer 'Authors' own results, unreproduced; no independent evaluation yet.'

このアーキテクチャは、より大きなモデルではなく、トークンに賭けている。

WeVisOne-VL-2BはQwen3-VLを基盤とし、約20億のパラメータを搭載し、視覚言語モデルとしてはやや珍しいことを行います。それは見つけることと描くこと。

言語側が探索を担います。<0>から<1000>までの専用座標トークンを持ち、これらは正規化されたボックスと点をエンコードするため、検出結果はモデルがテキストと同じストリームで出力するトークン列そのものです。クエリ対象が存在しない場合、それはボックスをでっち上げるのではなくNoneを返します。密なタスクでは、予測された各ボックスの直後に、追加の特殊トークン<OBJ>をトークンID 152678で出力します — 「このインスタンスは下に続く」という印です。

ピクセル側が描画を担当する。mask_decoder.ptは各<OBJ>の隠れ状態を読み取り、フーリエエンコードされたボックス事前分布と組み合わせて、実際のマスクを生成する。これには3つの段階がある。複数レベルのQwen3-VLマージ前ViT特徴量に対する視覚特徴アダプター、6つのdeformable cross-attentionブロックを備えたボックス誘導クエリデコーダー、そしてTencentがFullCanvasAlphaCascadeHeadと呼ぶものを中心に構築された高密度予測ヘッドであり、S/4、S/2、S/1で精細化してストライド1のフル解像度連続アルファマットを出力する。

重要な設計上の選択は最後のものです。ほとんどのグラウンデッドVLMはバイナリマスクまたはポリゴンを返します。アルファマットはソフトエッジのピクセルごとの不透明度マップであり、人物の髪の周りにハローを出さずに新しい背景へ合成するために必要なものです。これはセグメンテーションとは異なる出力タイプであり、このモデルが汎用VLMのファインチューンではなく別リリースとして存在する理由です。

論文が主張していること、そしてカードが教えてくれないこと

モデルカードにはベンチマーク表がありません。コンテキスト長も、スループットの数値も、学習トークン数も、ハードウェア要件も、価格もありません。カードが示すのは、インターフェース、アーキテクチャ、想定される用途、そして制限事項です。

数字が載っているのは論文で、7つのタスク表と、Tencent が30以上と説明するベンチマークにまたがっています。以下はすべて著者自身の結果であり、著者らが実行したもので、独立した第三者が再現したものではありません:

• 検出 — 平均F1はCOCOで55.2、LVISで53.3、Dense200で61.4、VisDroneで40.4。同じ表におけるQwen3-VL-2Bベースラインは45.2、40.8、10.0、23.1。際立っているのはDense200の差だ。ベースラインの6倍であり、しかも混雑シーンに関するベンチマークでの結果である。

• 拒否 — RefCOCOg では、2B は存在しない物体のクエリに対して 50.2 という拒否率を報告している。同じ表にある2つの特化型グラウンディングモデル、Rex-Omni-3B と LocateAnything-3B は、0.5 と 0.6 を報告している。「そこにない」と言えることが、知覚システムをデモから分ける要素の大部分だ。

• 計数 — PixMo-Countの検証スプリットとテストスプリットでは完全一致率が90.9と88.1だが、CLOCではわずか27.5と26.9、KubriCountでは29.5と32.4、CountQAでは47.9。計数データセット間のばらつきは、この論文で最も正直な点だ。計数は一つのスキルではなく、このモデルはそのうちのいくつかが得意なのだ。

• OCR — HierTextで平均F1 30.5、ICDAR2015で42.6、TotalTextで42.5、SROIEで62.1。これらはIoU閾値0.5における位置認識を考慮したF1スコアであり、文字起こし精度ではないため、コンシューマー向けVLMでよく引用されるOCRBenchの数値とは比較できません。

• セグメンテーション — RefCOCO検証で累積IoU 79.7、RefCOCO+検証で73.1、RefCOCOg検証で74.4、ReasonSeg検証で60.9。論文では、RefCOCOファミリーの数値はcIoUであり、ReasonSegの数値はgIoUであることが明記されている。

• マッティング — ボックスプロンプトを使用した P3M-500-NP では、平均絶対差が 6.6 で、SAM2-Matting の 15.4 に対して優位です。AM-2K では 5.7 対 12.1。より難しい WeRefMat の referring split では、Qwen3-VL-8B と SAM2-Matting のパイプラインの 23.0 に対して 15.8 です。これらはすべて値が低いほど良好です。

4B を引用する前に知っておくべき内部矛盾が一つあります。小さいモデルのほうが P3M-500-NP のマッティングでは実際に大きいモデルを上回っており、6.6 対 7.3 MAD です。Tencent はその理由を説明しておらず、これはこれらの表が単一実行によるもので、確定したランキングではないことを思い起こさせます。

証拠が薄いところでは

論文自身の限界のセクションは異例なほど率直で、このことは前述のすべてをどう読むべきかに影響するはずだ。そこでは、限られた量の汎用トレーニングデータが「ベースモデルと比べて汎用的な能力を損なう可能性がある」と述べている。つまり、知覚を得意にしたファインチューニングによって、汎用的なアシスタントとしての性能が悪化した可能性がある。論文内ではそのことを検証していない。7つの表のどこにも、MMMU、MMBench、DocVQA、キャプション生成のベンチマークは存在しない。

残りの3つの制約は、プロンプトで修正できるものではなく、アーキテクチャに起因する。モデルは推論効率のため、思考の連鎖を伴わずに構造化出力を生成し、単一ターンであり、ピクセルデコーダは動画グリッドを受け付けない。Tencentはまた、ベンチマークのプロンプトは「明確で、整った形式で、曖昧さがない」一方、実際のユーザー指示はしばしば曖昧であるとも指摘している。これは、評価設定がモデルに有利に働いていることを率直に認めたものだ。

そして実用的なギャップは、エンジニアが最初に突き当たるものだ。公開されているコンテキスト長はない。論文の学習段階では4,096トークンと8,192トークンが使われ、推論では貪欲デコーディングで各画像を1,960視覚トークンに制限しているが、そのどれもが明示されたデプロイ時のコンテキストウィンドウではない。GGUFも量子化ビルドもONNXエクスポートもなく、Apple Siliconへの言及もない。Tencentによるホストされたエンドポイントもなく、それを提供する推論プロバイダーもない。

A screenshot of the WeVisOne-VL project page at tencent.github.io, captured 23 October 2026, showing the WeChat Vision · Tencent Inc. badge, the title 'Unified Visual Perception from Objects to Pixels', the eight author names, and buttons linking to Paper, Code, Weights (4B) and Weights (2B).

実行するよ、よければ

サポートされている経路はTencent自身のパッケージです。GitHubリポジトリからインストールし、その後チェックポイントを名前で読み込んで、predictを画像、タスク、クエリ、温度を指定して呼び出します。カードには、画像テキスト入力→テキスト出力パイプラインによるTransformers経路も示されており、デプロイ経路としてvLLM、SGLang、Docker、Colab、Kaggleを挙げています。

流し読みする人を痛い目に合わせる点が2つある。1つ目は、mask_decoder.ptは任意ではない — 重みと一緒にダウンロードしないと、denseタスクは実行するものが何もない。2つ目は、デフォルトは温度ゼロの貪欲デコーディングであり、カードもそのままにすることを勧めている。これは構造化座標を出力するモデルで、サンプリングは何の助けにもならない。

ここが、ルーティングレイヤーが本当に意味を持つポイントでもあり、ここでそれが何を意味するのかを正確に述べておく価値があります。OrcaRouterはWeVisOne-VL-2Bを提供していません。当社のカタログにはなく、そうでないふりをするつもりもありません。ルーターが役立つのは、その周辺の比較においてです。セルフホスト型の知覚モデルをホスト型の汎用視覚モデルと比較評価する場合、それらのホスト型モデルはプロバイダー定価でマークアップなしの1つのAPIキーの背後にあるため、ハーネスを構築しても3つの契約を結ぶ必要はありません。自動フェイルオーバーは、GPUマシンが忙しい間もそのハーネスのホスト型側を稼働させ続け、ルーティングDSLを使えば、どちらが本番環境で採用される価値があるかを判断する間、セルフホスト型呼び出しとホスト型呼び出しを単一のエンドポイントの背後に置けます。

A screenshot of the Hugging Face model page for tencent/WeVisOne-VL-2B, captured 23 October 2026, showing the Apache-2.0 licence tag, 'Model size 2B params', tensor type F32, the notice that the model isn't deployed by any Inference Provider, and the Quick Start Python snippet calling WeVisOneVL.predict with task matting.

何がこれをリポジトリから物語へと変えるのだろうか

3つあるが、まだどれも存在しない。最大のものは独立した追試だ。上記の数値はすべてTencentのもので、Tencentのハーネス上で得られたものであり、棄却率やマッティングの差分は、まさに他者が追試すれば変わりうる類の主張である。2つ目は発表だ。リポジトリ、論文、プロジェクトページはいずれも当事者によるものだが、そのどれも正式なローンチではなく、きちんとした解説記事なら論文が圧縮してしまっている学習の詳細を載せる可能性が高い。3つ目はフレームワーク対応だ。カードにはvLLMとSGLangが挙げられているが、カーネルがマージされることや公式のチェックポイント変換が行われることは、デプロイ表の一行とはコミットメントのレベルが違う。

それらのどれかが実現するまでは、WeVisOne-VL-2B を正確に説明するとこうだ。これはスマートなインターフェースを備えた 2B の知覚モデルであり、座標をトークンとして、インスタンスをマーカーとして、ピクセルを別個のデコーダーとして扱う。検出、棄却、マッティングにおいて自身のベースモデルを大きく上回る改善を報告している一方、汎用能力の数値は一切公開しておらず、誰も API 経由で呼び出すことができない。写真から人物を切り抜き、髪の毛を保つ必要があるなら、その組み合わせはダウンロードするだけの面白さがある。画像について質問に答える視覚アシスタントが必要なら、これはあなたが探しているファイルではない。そして論文はそれを率直に認めている。