LFM3-VL-2B vs MiniCPM-V 4.7 35B-A3B：モデルではない列

のベンチマーク表を開くとLFM3-VL-2BMiniCPMの列があるのがわかる。そこにはMiniCPM-V 4.7 1Bと記されている。それが小さい方の兄弟モデルだ。多くの人がMiniCPM-V 4.7と言うときに指すモデル——OpenBMBのMiniCPM-V 4.7 35B-A3B、MiniCPM-Vシリーズ初のMixture-of-Expertsチェックポイント——はLiquid AIの表には一切載っておらず、両社が公開しているベンチマーク上でも1Bモデルとは大きく差がある。つまり、実際に比較の俎上に載っている対決、LFM3-VL-2B対MiniCPM-V 4.7 35B-A3Bは、ベンチマーク名は共通でも評価ハーネスが異なる2つのベンダー表から手作業で組み立てるしかない。以下がその組み立てであり、継ぎ目は見えるままにしておく。

サイズの不一致は第二の驚きだ。一方のモデルは19.2億の密パラメータを持ち、数ギガバイトに収まる。もう一方は352.1億のパラメータを保持し、トークンあたりおよそ30億のパラメータに触れる。スペックシートとして読めば、それはまったく対決になどならない。同じ問い——自分が制御できないデバイスで何を動かせるのか——への二つの答えとして読むなら、そこに至る方法をめぐる、実に興味深い意見の相違なのだ。

2つのモデル、1つの名前

命名の衝突は、この比較の読まれ方に実害を及ぼしている。Liquid AI のカードはその点で厳密だ。欄には 1B と記されており、その 1B は 1.92B モデルにとって正当な比較対象である。しかし検索結果やアグリゲーター、気軽な言及では、いずれも「MiniCPM-V 4.7」が一つのものにまとめられてしまい、しかも人々の目を集めているのは 35B-A3B のほうだ——2026年10月28日時点で、Hugging Face におけるダウンロード数は 289,535、いいねは 1,095 であるのに対し、1B の兄弟モデルは 155,428 といくつかの百にとどまっている。

日付はその差の一部を説明するが、残りは説明しない。OpenBMBの35B-A3Bリポジトリは2026年10月7日に作成され、リリース日はプロジェクト自身の資料では10月12日となっている。Liquid AIのLFM3-VL-2Bリポジトリは10月19日に公開され、LFM3ファミリーは10月27日に発表された。LFM3-VL-2Bは公開されてから9日しか経っていないため、その255ダウンロードは暦上の事実であり、評価ではない。より興味深いのはいいねの比率の行だ。LFM3-VL-2Bが45、MiniCPMが1,095。後者をダウンロードした人々は、そう言いたくなるほど気に入ったのだ。

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

• パラメータ — LFM3-VL-2Bは1.92Bのデンスモデルです。内訳は1.73Bの言語バックボーン、164Mの自社製ビジョンエンコーダー、25Mのプロジェクターです。MiniCPM-V 4.7 35B-A3Bは、256個のエキスパートに35.21Bを格納し、トークンごとにそのうち8個をルーティングします。アクティブなパラメータは約3Bです。

• バックボーン — LFM3層24層（ゲート付き短畳み込み13層、スライディングウィンドウ注意5層、グローバル注意6層に分割）で、隠れサイズ2,048のトランスフォーマー層40層と対比。

• 視覚経路 — 2D回転埋め込みを用いた16×16パッチ上で、8つのゲート付き深度方向2D畳み込みと6つの双方向アテンション層からなる14層エンコーダ。これに対し、テキストスタックの第6層に挿入される、隠れサイズ1,152の27層タワーを備え、エンコーダ内での早期トークン圧縮と、切り替え可能な4×または16×の視覚ダウンサンプリングを伴う。

• コンテキスト — LFM3-VL-2Bでは128Kトークン、MiniCPMでは256K、いずれも入力と出力を合わせた値です。

・入力 — Liquidモデルではテキスト、画像、動画（毎秒2フレーム）、OpenBMBのモデルではテキスト、画像、動画。どちらも音声は聞き取れず、入力・出力のどちらにも対応していません。

• ディスク上の重み — BF16で約3.8 GB（対してBF16で約65.6 GiB）。

• ライセンス — LFM Open License v1.0。Liquidはこれを年間収益1,000万ドル未満の商用利用は無料と説明しており、収益条件のないApache 2.0と対比される。

アーキテクチャ上の対立こそがすべてだ。Liquidは、小規模な高密度モデルと専用設計の視覚エンコーダーが、画像1枚あたりの計算量でSigLIP型のタワーを上回ると賭け、それを証明するカテゴリー表を公開した。OpenBMBは、35Bモデルの能力を維持しながら、高コストな部分を常駐させるのではなくストリーミングさせることで、スマートフォン上でも動かせると賭けた。どちらもメモリをめぐる賭けであり、相反する方向を向いている。

そのギャップは現実に存在し、枠組みが示すよりも狭い。

適切な行を横に並べると、2つのベンダー表はこう述べています。すべてラボによる自己申告であり、ハーネスに関する注意事項はその後に続きます。

• MMMU — LFM3-VL-2B は思考オンで55.7、オフで48.6。MiniCPM-V 4.7 35B-A3B は4×の視覚圧縮で80.22、16×で80.00。

• MMStar — 4×で80.67、16×で80.13に対して74.4。

• OCRBench v1 — 86.3（4×では91.20、16×では90.40に対して）

• MathVista — 思考ありで84.2、思考なしで68.5、4×で88.00、16×で87.30に対して。

• CharXiv推論 — 4×では75.60に対して70.2、16×では69.20。

MMMUは、35Bがその規模に見合う実力を見せる場だ。思考設定に対して24.5ポイント、非思考設定に対して31.6ポイントの差をつけている。これは大学レベルのマルチモーダル推論ベンチマークであり、その差はハーネスの違いに関する妥当な反論にも耐えうるほど大きい。

その他のすべては、この枠組みが示唆するよりも接近している。OCRBenchは4.9ポイント差。LFM3-VL-2Bが思考する場合、MathVistaは3.8ポイント差だ。CharXiv推論では、Liquidモデルは思考モードで5.4ポイント負けている——そして35Bの16×の数値を1ポイント上回る。文書OCRとチャートで2Bモデルが35Bから5ポイント以内に収まっていることは、MMMUの見出し以上に注目されるべき発見だ。

では注意点です。これらは重要だからです。Liquid の数値は、vLLM 0.27.1 上で 62 個のベンチマークを単一実行した結果から得られたもので、0〜100 に正規化されており、別途明記された構成を除くすべてのモデルで推論モードが有効になっています。OpenBMB の 5 つの数値は数値表ではなくチャート画像として公開されており、ここでは第三者アグリゲーターがそれらのチャートを読み取った内容から転記したため、小数値は概算として扱ってください。両ラボは視覚トークン予算、プロンプト設定、デコード設定について一致しておらず、OpenBMB 側の 4× と 16× の区分だけでもそのスコアは最大 6 ポイント変化します。これは対照実験ではなく、2 組の主張を並べたものにすぎません。

小型モデルには数値があるが、大型モデルはそれを公表していない

Liquidは62行を公開した。OpenBMBは5行だ。この非対称性はこの比較で最も報じられていない事実であり、小さい方のモデルをよく見せる方向に働いている。

• 視覚グラウンディング — LFM3-VL-2B では RefCOCO-avg 90.5、RefCOCO-M 95.2、Point-Bench 73.8、RefSpatial-Bench 49.8。MiniCPM-V 4.7 35B-A3B の公開評価には同等の行は見当たりません。

• GUI理解 — ScreenSpot-Pro 55.5、ScreenSpot-v2はデスクトップ94.6、モバイル92.2、Web 89.9。繰り返しになるが、OpenBMB側では何も公開されていない。

• 身体化推論 — EmbSpatial-Bench 82.9、RoboSpatial-Home 63.4、Where2Place 44.9。同じ欠如。

• 動画 — 字幕なしの Video-MME 62.8、MVBench 69.4、MLVU 71.3、ActivityNet-QA 71.2。MiniCPM-V 4.7 は動画をサポートしており、カードではこの点が詳しく論じられていますが、数値表には検証可能な動画の行が含まれていません。

これは証拠の不在であり、既定の勝利ではありません。ロボティクスやスクリーンエージェントのパイプラインを構築しているなら、正直な立場としては、それらのタスクにおける35Bの能力は弱いのではなく不明だということです。しかし「不明」はそれ自体が調達上の問題です。誰も公表していない数値を前提に展開を計画することはできませんし、LFM3-VL-2Bは、ダウンロード前にグラウンディングとGUIの性能を確認できる、2つのうち唯一のものです。

記憶に関する議論は諸刃の剣だ

35Bモデルではなく2Bモデルを選ぶ通常の理由は、2Bモデルなら収まるからだ。LFM3-VL-2Bは実際に、完全かつ予測どおりに収まる。BF16で約3.8 GB、常駐し、ページングはなく、デバイスに負荷がかかっていても予期せぬ事態は起きない。これは、自社で制御できないハードウェア向けに出荷する製品にとって、確かに強力な特性だ。

MiniCPM-V 4.7 35B-A3B は 65.6 GiB もあり、スマートフォンには到底収まりません。OpenBMB の設計全体は、まさにそのために存在しています。Lookahead Expert Scheduling は次レイヤーのルーティングを予測し、必要になると見込まれるエキスパートをプリフェッチします。きめ細かなレイヤー単位の量子化はそれらのエキスパートを縮小し、より高速に移動できるようにします。DSpark の投機的サンプリングはデコーディング時の停滞を補います。ベンダーの主張では、約 3 GB のメモリを使用する iPhone 17 Pro Max で毎秒 13 トークン以上、16 GB の iPad Pro M4 で毎秒 17 トークン以上です。

つまり、オンデバイスに関する主張は「35Bは小さい」ということではない。「35Bはストリーミングされ、そのストリーミングは実用できるほど滑らかだ」ということだ。これらは異なる賭けであり、失敗の仕方も異なる。常駐する3.8 GBのモデルは緩やかに劣化する——ロードされているか、いないかのどちらかだ。ストリーミングする65.6 GiBのモデルは、フラッシュ帯域、サーマルスロットリング、コールドスタートのレイテンシによって劣化し、これらはいずれも、1台のiPhoneでのベンチマークでは捉えきれない形でデバイスごとに異なる。

実用的な使い分けはこうだ。ストレージ速度も熱設計の許容範囲も自分で制御できないなら、常駐型がよりリスクの低い道だ。最新のフラッグシップハードウェアに搭載し、精度を求めるなら、OpenBMBのアプローチはもはや理論上の話ではない——動作するフォークを伴う、リリース済みのモデルなのだ。

初日から使えるツールは互角ではない

LFM3-VL-2Bは、transformers 5.21以降を必要とするBF16ウェイトを提供しており、さらに量子化対応蒸留されたQ4_0チェックポイントを含むGGUF、MLX 4ビットビルド、ONNXエクスポートも提供しています。サーバー対応は完了していません。vLLMは進行中と説明されており、SGLangはプルリクエスト46858でレビュー中、llama.cppはプルリクエスト31252でレビュー中で、動画入力はまだサポートされていないという明示的な注記があります。このカードはまた、vLLMとSGLang向けにqwen3推論パーサーとqwen3_coderツール呼び出しパーサーを推奨しており、この詳細から、これがごく最近組み込まれたものであることが分かります。

MiniCPM-V 4.7 35B-A3B は SGLang、vLLM、llama.cpp、Ollama をサポートし、ファインチューニングには SWIFT と LLaMA-Factory、ビルドには GGUF、BitsAndBytes、AWQ、GPTQ、FP8、int4 を用意し、Rockchip、Houmo、Intel、AMD、Arm のチッププラットフォームを iOS、Android、HarmonyOS にわたって day-zero サポートします。オンデバイス経路は、上流の llama.cpp ではなく OpenBMB 独自の llama.cpp-omni フォークを経由します。

今月の本番デプロイなら、それは判断に迷う話ではありません。研究用のスパイク、ラップトップでのデモ、あるいは自分で管理するつもりのファインチューニングなら、LFM3-VL-2B は今日から transformers 経由で動作し、ビルドフラグに一週間を費やすことはありません。

より多くのチームがつまずくライセンス条項

Apache 2.0 と LFM Open License v1.0 の比較は、MMMU の差よりも実務上の違いが大きい。なぜなら、それは難しいケースだけでなく、あらゆるデプロイに適用されるからだ。Apache 2.0 には収益条件も、利用分野の制限も、量子化または蒸留された派生物が条項を継承するかどうかに関する曖昧さもない。LFM Open License v1.0 は、Liquid 自身の説明によれば年間収益1000万ドル未満なら商用利用が無料であり、つまりそのラインを超える企業は、出荷後にではなく出荷前にライセンスについて話し合うことになる。

そのたった一つの条項が、多くの購入者にとって比較の構図を変える。基準を下回るスタートアップは、グラウンディングに関する文書がより充実した、より小さく高速なモデルを無償で手に入れる。基準を上回る企業は、署名が必要なモデルを手に入れる——その時点で、35BのApache 2.0は注目に値する特徴になる。

どちらのベンダーも教えてくれないこと

独立した直接対決は存在しない。第三者のラボが両モデルを同じ評価環境で実行したことはなく、中立的なスコアボードに最も近いもの——Liquid自身の表——は、LFM3-VL-2Bを35Bではなく1Bと比較している。この記事のすべての数値は、記事が扱うモデルを開発したラボに由来する。

他にも名指しすべきギャップが2つある。どちらのモデルにも検証可能なトークン単価がないため、ここでコスト比較をすれば捏造になってしまう。また、どちらもOrcaRouterカタログには2026年10月28日時点で存在しない——minicpmで検索しても一致するモデルは返らず、LFM3-VL-2Bも掲載されていない。このため現時点では、これはルーティングの判断ではなく、セルフホスティングかベンダーAPIかの判断となる。

どちらを選ぶべきですか

• 文書、チャート、密度の高いテキスト、難しいマルチモーダル推論を、自分で管理できるサービングスタックで — MiniCPM-V 4.7 35B-A3B。MMMUのマージンは、ハーネスに関する注意点を踏まえても十分に大きい唯一の結果であり、Apache 2.0はライセンスの問題を完全に解消します。

• 管理下にないデバイス、固定のメモリ予算、ストリーミング遅延を一切許容できない環境 — LFM3-VL-2B。常駐メモリは3.8 GBで、2つのうち、計画の基準にできる公開済みのグラウンディング、GUI、エンボディド数値を備える唯一のモデルです。

• スクリーンエージェント、ロボティクス、空間タスク — デフォルトではLFM3-VL-2B。公開された証拠があるのはこちら側だけだから。35Bはそこで弱いのではなく、未証明として扱うこと。

• 今月は最小限の統合作業で本番稼働 — MiniCPM-V 4.7 35B-A3B。SGLang、vLLM、llama.cpp、Ollama のサポートは、3件の「レビュー中」または「進行中」の注記に対応しています。

• 年間売上が1,000万ドルを超える企業 — MiniCPM-V 4.7 35B-A3B。ただし、オンデバイス上の制約がライセンス交渉を正当化するほど厳しい場合を除く。

OrcaRouterがどこに当てはまるのか、正直なところ

まだ適合していませんし、そうでないと言うのは、ブログ記事が無視される類のことです。どちらのモデルも現在OrcaRouterのカタログにはないため、お渡しできるキーも、提示できる価格もありません。

真実なのは、ビジョンモデルが実際にそこに登場したときに何が起きるかだ。200以上の人モデルに対応する単一のOpenAI互換エンドポイント、プロバイダーの定価を0%のマークアップでそのまま適用することでベンダーの価格変更が同日に反映される仕組み、そして自動フェイルオーバーにより単一プロバイダーの障害でルートが停止しないことだ。このような比較、つまりメモリについて意見が分かれる2つのモデルがあり、それを決着させる独立したベンチマークがない場合に有用なパターンは、両方を1つのエンドポイントの背後で実行し、どちらのグラフが正しいかを論じるのではなく、自分の画像で測定することだ。

何を観るべきか

この記事を変える4つのポイントがある。動画サポートを伴ってマージされるプルリクエスト31252——これによりLFM3-VL-2Bの動画パスが標準のllama.cpp上に載る。vLLMサポートが「進行中」から脱すること——これによりデモではなく本格的なサービングの選択肢になる。両モデルを1つのハーネスで実行する独立評価——この比較で最も価値のある、欠けている成果物。そしてLiquid AIが35Bを自社の比較表に加えること——これにより同ラボがそれを真の同格と見なしていることがわかる。

それらのどれかが実現するまでは、擁護できる要約はどちらのベンダーの枠組みよりも狭い。35Bは重要な推論ベンチマークで勝ち、OCRでは何も失わない。2Bは根拠となる証拠と予測可能性で勝り、そして導入の可否を決めるのはベンチマークよりもライセンスのほうが多い。