LFM3-VL-2B 対 WeVisOne-VL-4B：パラメータ数が2.5倍であることで実際に何が得られるのか

Tencent自身のベンチマーク表は、明白な購入判断に反対する論拠を示している。 WeVisOne-VL-4Bは、WeChat Visionチームが2026年10月22日に公開した2つの知覚モデルのうち大きい方だが、ボックスプロンプトによるアルファマッティングでは自身の2B兄弟モデルよりも劣る。P3M-500-NPでの平均絶対差は7.3で、2Bの6.6に対して悪く、低いほどよい。とはいえ、多くの購入者が実際に比較検討するモデルは、その兄弟モデルではなくLFM3-VL-2B——Liquid AIの1.92Bオンデバイス視覚モデルで、重みは10月19日に公開され、10月27日にLFM3ファミリーの残りとともに発表された——である。

その2つを並べてみると、興味深い問いはどちらがより賢いかではない。パラメータが2.5倍あることで何が得られ、それが何を犠牲にするかだ。ベンダー自身の表から短く答えるなら、得られるのは高密度な検出、参照精度、そして対象がそこに存在しない場合に回答を拒否する割合の大幅な改善だ。得られないのは汎用モデルであり、動画であり、スマートフォンに載せられるモデルだ。以下の内容はすべて、継ぎ目を残したまま公開された2つの表に基づいている——どちらのモデルの数値も、独立した評価ハーネスによって再現されていない。

それぞれが実際に何なのか

LFM3-VL-2Bは1.92Bの密パラメータを備える。内訳は1.73Bの言語バックボーン、164Mの社内製ビジョンエンコーダー、25Mのプロジェクターである。バックボーンはLiquidのトライハイブリッドスタックで、24層は13層のゲート付きショート畳み込み、256トークンウィンドウの5層のスライディングウィンドウアテンション、6層のグローバルアテンションに分割されている。ネイティブ解像度でテキスト、画像、動画を入力でき、動画は毎秒2フレームでサンプリングし、128Kトークンのコンテキストを保持し、16言語をカバーし、回答前に推論パスを生成するオプションの思考モードを備える。その出力は散文である。

WeVisOne-VL-4BはQwen3-VLをバックボーンとして構築され、4Bと名付けられていますが、Hugging Faceのメタデータでは5Bに丸められており、第三者による記事では実際のパラメータ数は約4.83Bとされています。文章で答えるというより、むしろ幾何情報を出力します。すなわち、0から1000までの正規化された座標トークンとしてのボックスとポイント、各予測ボックスの後のOBJマーカー（トークンID 152678）、対象が存在しない場合のリテラル文字列Noneです。マスクとアルファマットには、2つ目のアーティファクトであるmask_decoder.ptが必要です。これは9.6Mパラメータのピクセルデコーダで、各OBJトークンの隠れ状態と予測ボックスを受け取り、ストライド1でフル解像度のアルファを返します。単一ターンかつ画像専用であり、chain-of-thoughtなしで構造化出力を直接生成します。

1回のパスでコントラスト：

• サイズ — LFM3-VL-2B は 1.92B の dense モデル、WeVisOne-VL-4B は約 4.83B、さらにマスクに必須の 9.6M デコーダーを含む

• 入力 — テキスト、画像、2 fpsの動画 対 テキストと単一画像

• 出力 — 散文と思考パス vs 座標トークン、ボックス、マスク、マット、または明示的な None

• コンテキスト — 128Kトークン 対 カードに公開された推論制限なし；論文では4,096トークンと8,192トークンでのトレーニングについて説明されている

• 対応言語 — 16言語の明記あり 対 明記なし

• ライセンス — LFM Open License v1.0 は年間収益1,000万ドル未満なら商用利用無料、一方 Tencent が作成したコードには Apache 2.0 を適用

• ランタイム — GGUF/llama.cpp、MLX 4-bit、ONNX、および Transformers、vLLM、SGLang 経由の BF16 対 BF16

アップグレードは均一ではなく、どこに偏りがあるかを論文が示している。

WeVisOne-VL-2BとWeVisOne-VL-4Bは同一アーキテクチャを2つの規模で展開したもので、同じ約1億枚の画像を用いて同じ3段階のカリキュラムで学習され、同じ表で評価されている。そのため、この同系列比較は、追加のパラメータが何をもたらすかについて得られる最も明快な証拠となる——そしてそれは一方向に動くわけではない。

Tencentの数値で見れば、4Bが明らかに勝るのは次の点です：

• Dense200検出 — 平均F1 71.3 対 61.4、単一の改善としては最大

• LVIS — 55.3 対 53.3、控えめな2ポイントの改善

• RefCOCOg 参照検出 — テスト 81.8 対 78.2

• RefCOCO 指示対象セグメンテーション — testA で 84.5 cIoU（対 82.9）

• ReasonSeg — val で 71.2 cIoU（60.9 対比）、推論セグメンテーションで 10 ポイントの向上

• PointBench ポインティング — 71.9 対 62.9

• WeRefMat の referring matting — referring 分割における平均絶対差は 9.8 対 15.8 で、誤差が 38% 削減

そうでない場合は：

• P3M-500-NP のボックスマッティング — 2B の 6.6 に対して 7.3 で、より悪い

• PPM-100 ボックスマット — 6.1 対 5.3、悪化

• Ref-ZOM cIoU — テストでは72.2 対 73.4、またも2Bがリード

パターンは読み取れる。原因が公表されていなくてもだ。4B は難しく言語条件付きのタスク——参照セグメンテーション、推論セグメンテーション、実シーンでの参照マッティング——で先行し、より簡単なボックス指定マッティングのセットでは何も見返りがない。そこでは両モデルともすでに天井に近く、9.6M デコーダが作業の大半を担っている可能性がある。ボックス指定マッティングのベンチマーク3つのうち2つは逆方向に動く。供給されたボックスに対するアルファマッティングだけがタスクなら、4B はアップグレードではない。同じ答えをより高コストで、わずかに悪く得る方法だ。

存在しないオブジェクト：改善したが、まだ解決していない

論文で最も有用な列は、ほとんどどの視覚モデルカードにも掲載されていないものです。RefCOCOg-Rej は、すべての表現が、画像内に一致する物体が存在しないように変更された変種です。「いいえ」と言えないモデルはボックスをでっち上げ、その後のすべてのクロップ、カウント、マスクがその捏造を引き継ぎます。

WeVisOne-VL-4Bは67.4%の割合で正しく棄却するのに対し、2Bは50.2%です。これは17ポイントの実質的かつ大きな改善であり、パイプラインの失敗モードをコイントス（五分五分）から3回中2回へと変えます。ただし、それは4Bが物体の存在しないクエリのおよそ3件に1件で、依然として確信度の高いボックスを返すことも意味します。Tencentの社内製WeRef-Benchでは棄却率は96.4%と表示されますが、このベンチマークは同社が自ら構築した2,880件の英語および中国語クエリであるため、公開ベンチマークより有利な分布を測っていることになります。正直にまとめると、このモデルは実用的な棄却行動を備えているものの、問題を解決したわけではありません。アプリケーションがハルシネーションされた領域を許容できない場合、どのモデルを選んでも、その上にしきい値または追加チェックが必要です。

比較可能に見えてそうではない数字

LFM3-VL-2B の RefCOCO-avg 90.5 を WeVisOne-VL-4B の RefCOCOg 81.8 の隣に置いて、小さいモデルが 8.7 ポイント勝ちだと宣言したくなる。だが、そうしてはいけない。それらは異なるデータ分割と異なる指標だ。Liquid は RefCOCO ファミリー全体の平均を報告しており、Tencent は参照検出における RefCOCOg テスト F1 を報告している。両者を引き算すると、参照対象を持たない数値が出来上がる。

同じ罠がOCRにも潜んでいます。LFM3-VL-2Bは、テキスト認識・スポッティング・推論を組み合わせたOCRBench v1で86.3を記録します。WeVisOne-VL-4Bは、シーンテキストのローカリゼーション・ベンチマークであるTotalTextで平均F1 52.0を記録します。一方は広範な試験であり、もう一方は密な予測タスクです。これらは同じ技能を二度測ったものではありません。

つまり、2つのベンダー表は、同一条件で比較できる単一の数値では交わりません。正直に比較できるのは機能とコストであり、だからこそこの比較の残りは順位ではなく適合性についてです。この2つの表から勝者を公表する人は、勝者をでっち上げているのです。

記憶こそが本当の代償だ

2026年10月28日時点で、どちらのモデルにも公開されたトークン単価はない。Liquidのカードにはコンソール経由のAPIおよびPlaygroundアクセスへのリンクがあるが、LFM3-VL-2B向けの料金表は公開されていない。Liquidのテキストモデル料金を掲載している第三者トラッカーも、このビジョンモデルは対象にしていない。Tencentにはホスト型エンドポイントが一切ない。したがって比較はセルフホスティング同士の比較となり、請求額はメモリ建てになる。

• LFM3-VL-2B — パラメータ数から計算するとBF16で約3.84 GB。4ビットのMLX、GGUF、ONNXビルドも併せて公開されています

• WeVisOne-VL-4B — 第三者による推定では、BF16で約9.7 GB、F32で約19 GB、さらに必須のmask_decoder.ptが加わります。

その2.5×の差は、単にGPUが大きいという話ではありません。デバイスのクラスが違うのです。LFM3-VL-2Bのモデルカードには、このモデルがオンデバイスでの作業向けに作られていることが明記されています。動画、文書、グラフ、アプリ画面に関する質問、物体検出、ロボット向けの空間推論などです。そしてMLX 4-bitビルドとGGUFビルドが、その約束を守る手段です。ノートPC、スマートフォン、ロボットのシャーシです。WeVisOne-VL-4Bで記載されている実行経路は、BF16上のTransformers、vLLM、SGLangであり、公式の量子化ビルドもオンデバイスランタイムもありません。サーバーGPUを必要とします。

フレームワークの対応状況は、表ではなく自分の実際の経路に照らして確認する価値があります。LFM3-VL-2Bでは2 fpsの動画がモデルの能力ですが、特定のランタイムが動画グリッドを受け入れるかどうかは別問題であり、モデルカード、移植版、上流のPRの間でその点が常に一致していたわけではありません。出荷予定の正確な組み合わせをテストしてください。

OrcaRouterはどちらのモデルもホストしていません。これは推測ではなく、2026年10月28日のカタログに対して確認済みです。LiquidのLFM3シリーズもTencentのWeVisOneもモデル一覧に現れないため、ここにある内容をどちらかへの経路と解釈すべきではありません。OrcaRouterのモデルカタログに掲載されているのはQwen3-VL-8Bで、instruct版とthinking版があり、実際の要件がセルフホストのチェックポイントではなく、今日公開されている価格付きのホスト型視覚モデルであるなら、これは現実的な選択肢です。1つのキーで、プロバイダーの定価・マークアップなしでそのすべてにアクセスできます。また、まだ実績のないオープンウェイトモデルでプロトタイピングしているなら、フェイルオーバー付きのルーター経由で実行する方が、独立した評価をまだ受けていないチェックポイントに本番経路を配線するより優れています。

どちらを選ぶべきですか

• 成果物がジオメトリ（マスク、アルファマット、密なボックス、カウント、ポインティング）であり、静止画像上で、クエリがボックスプロンプトではなく言語条件付けされている場合、かつGPUに余裕がある場合は、WeVisOne-VL-4Bを選びましょう

• 通常のシーンでボックスプロンプトによるマッティングを行うタスクなら、4BではなくWeVisOne-VL-2Bを選んでください。公開されている数値では、小さいモデルの方がこのタスクに優れ、メモリ消費は半分未満です

• 入力に動画が含まれる場合、ドキュメントが長い場合、回答がポリゴンではなく文である必要がある場合、またはデバイスがサーバーでない場合は、LFM3-VL-2B を選択してください。

• 今週、公開されたトークンあたりの価格付きのホステッドエンドポイントが必要なら、どちらも選ばないでください — どちらのベンダーもそれを提供しておらず、どれだけベンチマークしてもその差は埋まりません

• 両方とも選ぶのは、2つの出力スキーマと2つの統合パスを受け入れる場合に限られます。共通の「約2B～5B」というパラメータ帯域が、2つの異なる製品を覆い隠しています

何がこれを変えるでしょうか

三点あります。両方のモデルを同じ画像と同じプロンプトで実行する独立したハーネス。それまでは、上記はすべて注意深く読んだベンダーの表であり、不注意に読んだベンダーの表よりはましですが、品質の証拠ではありません。量子化されたWeVisOneビルド、またはオンデバイスランタイム。これがあれば、メモリに関する議論は決定的なものから交渉の余地があるものへと変わります。そして、どちらかの陣営から公表されるトークンあたりの価格。これがあれば、ギガバイトについての計算を、予算を立てる際に当てにできる数値に置き換えられます。

この特定の組み合わせで最も重要になるのは、3つのうちで最も可能性が低いものだ。WeVisOneのピクセルデコーダーにおける動画サポートである。現時点では、2Bの汎用モデルは動画を扱えるが、4Bの計測器モデルは扱えず、学習されなかったモダリティはパラメータ数では補えない。