LFM3-Omni-2B vs MiniCPM-V 4.7 1B：小さいモデルの方がよく読み取れる場合

紙の上では、これは公平な勝負ではない。LFM3-Omni-2Bは21.7億パラメータを持ち、MiniCPM-V 4.7 1Bは1Bモデルとして売り出されている。大きいモデルの方が視覚ベンチマークで勝つはずだ。しかし勝っていない。MiniCPMはOCRBenchで86.1対80.6、MMStarで69.5対55.67、MMMUで56.9対42.44、MathVistaで74.3対62.5を記録する。両カードが共通して掲載するすべての視覚ベンチマークで、名前が小さい方のモデルが有利で、たいていは大差をつけており、さらにMiniCPMは8倍のコンテキストウィンドウも備えている。Fusionは単一モデルへのルーティングよりも呼び出しあたりのコストが高く、料金はプロバイダーの定価で、マークアップは一切加算されない。

それを説明する3つの事実があり、いずれもどちらのモデルの欠陥ではありません。MiniCPM-V 4.7 1Bは、パラメータ予算のすべてを「見る」ことに費やしたスペシャリストです。LFM3-Omni-2Bは、予算を「見る」「聞く」「話す」ことに費やしたジェネラリストです。そして最も重要なMiniCPMの数値、OCRBenchでの86.1は、4倍の視覚トークン設定で測定されたものです。これは、画像あたり2,048トークンという上限ではできない形で、計算量と引き換えに詳細を得る設定です。このトレードオフを理解することが、判断のすべてです。

なぜ小さいモデルのほうがよく読めるのか

MiniCPM-V 4.7 1B は、視覚トークンを早い段階で圧縮し、どれだけ強く圧縮するかをユーザーが選べるようにするという、単一のアイデアに基づいて構築されています。このモデルは、言語モデルが何かを目にする前に、視覚エンコーダー内で 4× または 16× のトークン圧縮を適用します。16× では安価で高速であり、キャプション生成やシーン記述に適しています。4× では 4 倍多くのトークンが保持され、これが文書 OCR や高密度なグラフ読み取りに必要なものです。OpenBMB の主要な数値は 4× 設定で報告されています。

LFM3-Omni-2Bは逆のアプローチを取る。画像をネイティブ解像度で処理するが、視覚予算を画像あたり2,048トークンに制限し、その上限は2.17Bの密なネットワーク内で音声エンコーダー、動画経路、音声デコーダーと共有される。2,048トークンの上限は、他に3つのモダリティを備えつつスマートフォンに収まる必要があるモデルにとって妥当な選択だ。これは言語モデルに届けられるページ詳細量の厳しい上限であり、DocVQA 92.47はモデルがそこから多くのものを引き出していることを示唆するが、OCRBench 80.6は、同じページに4倍のトークンを使える特化モデルを打ち負かすには十分ではないことを示している。

もう一つ、より目立たない要素がある。MiniCPM のコンテキストウィンドウは 262,144 トークン、LFM3-Omni-2B は 32,768 トークンだ。スクリーンショット1枚なら、どちらも問題にならない。40ページのPDF、長尺の動画、あるいは文書をめぐる複数ターンの会話となると、その差はベンチマークの1行ではなく、そのタスクがそもそも可能かどうかに関わる。

マーケティング的な丸めなしの仕様

比較を行う前に、訂正が必要な数値がひとつあります。MiniCPM-V 4.7 1B は1Bモデルと呼ばれていますが、ビジョンタワーをどう数えるかによって、その密なパラメータ数はおよそ13億から15.5億になります。Hugging Faceのサイドバーではこれが「2B params」に丸められており、そのせいで1Bモデルがカタログ上では2Bモデルのように見えてしまうのです。正直な指標となるのはファイルサイズです。BF16で約3.1GBであるのに対し、LFM3-Omni-2Bは4.3GBです。

• パラメータ — LFM3-Omni-2B の2.17B denseに対し、MiniCPM-V 4.7 1B は約1.3B～1.55B dense。

• 入力 — テキスト、画像、音声付き動画、16 kHz音声 vs テキスト、画像、マルチ画像、動画。

• 出力 — テキストと24 kHz音声 対 テキストのみ。

• コンテキスト — 32,768トークン対262,144トークン。

• Visual tokens — 画像あたり最大2,048に制限され、エンコーダー内では4倍または16倍の圧縮に切り替え可能です。

• ライセンス — LFM Open License v1.0 と Apache-2.0 の比較。

• リリース — 2026年10月27日 vs 2026年10月12日。

• フットプリント — BF16で約4.3 GB 対 BF16で約3.1 GB、サービングには約5 GBのVRAMが必要。

2枚のカードが共有するすべての行

この比較は、異なる研究室間の表としては異例なほどクリーンです。なぜなら、両ベンダーが同じ4つの視覚データセットについて報告しており、どちらもinstructモードで評価された非推論モデルだからです。とはいえ、依然として2つのベンダーによる評価であり、どちらも独立に再現されてはいません。

• OCRBench — LFM3-Omni-2B は 80.6（1,000 件中 806 件）、MiniCPM-V 4.7 1B は 86.1。文書テキスト認識において 5.5 ポイントの差。

• MMStar — 55.67 対 69.5。13.8ポイントの差で、このセット内で最大です。

• MMMU検証 — 42.44 対 56.9。大学レベルのマルチモーダル推論における14.5ポイントの差。

• MathVista mini — 62.50 対 74.3。視覚的数学における 11.8 ポイントの差。

4行、4敗、差は5〜15ポイント。オムニモデルが勝つ行は一つもなく、これはLFM3対LFM2.5の比較が出した結果よりも明快で、言い逃れしにくい結果だ。最も擁護できる解釈は、256Kコンテキストと4倍のトークン予算を持つ1.4Bのスペシャリストは、32Kコンテキストと2,048トークンの画像上限を持つ2.17Bの汎用モデルよりも、単純により優れた読み手だということだ。この規模では、1つのモダリティに投じた容量は、4つに分割した容量を上回る。

2つの注意点は同時に述べておくべきだ。どちらのカードも自ら進んで明示していないからだ。MiniCPMの86.1は4倍圧縮で測定されており、同じモデルをデフォルトの16倍設定で動かせばスコアは下がり、実行コストは安くなるが、カードはその数値を公開していない。またOpenBMBのモデルカードにはベンチマーク表が一切なく、数値は製品ページの文章とチャート画像として示されている。これは手法の注記付きの表よりも弱い公開形態だ。どちらの数値もベンダーの主張だ。差の方向性は十分に一貫しているので、独立したテストでもおそらく維持されるだろう。正確な大きさはおそらく維持されない。

コンテキストは、実際のワークロードを左右する行です。

32Kコンテキストは、画像1枚には余裕があり、ドキュメントには窮屈です。画像1枚あたり約2,048視覚トークンだと、LFM3-Omni-2Bは会話履歴が場所を奪い始めるまでに、ウィンドウ内におよそ12枚の画像全体を保持できます。MiniCPM-V 4.7 1Bの262,144トークンは小幅な改善ではなく、扱えるワークロードのクラスが異なります。長いPDF、複数ページのフォーム、1時間に及ぶ動画の要約、スクリーンショットをコンテキストに保持し続けるエージェントループは、256Kならすべて実現可能で、32Kではすべて制約を受けます。

これこそ、2つのモデル間で最も議論されておらず、最も重大な違いです。ベンチマークの表は単一画像の精度を評価しますが、実際のドキュメントパイプラインは14ページ目で失敗します。会話ごとに画像が数枚を超えるユースケースなら、32Kウィンドウは上記の4つのベンチマーク差よりも厳しい制約です。

MiniCPMにできないこと

音を聞くことはできません。音声入力経路も、音声出力も、動画のサウンドトラック処理もありません。アプリケーションが、カメラが見ているものについて人がデバイスに話しかけるようなものである場合、MiniCPM-V 4.7 1B はパイプラインの一構成要素にすぎず、少なくともさらに2つのモデル——ASRシステムとTTSシステム——に加えて、それらの間でテキストを受け渡すための接着役が必要です。

LFM3-Omni-2Bは、そのパイプラインを単一の4.3 GBチェックポイントに集約する。音声スコアは専用の音声モデルと比べると目立たない——英語ASRの単語誤り率6.36、VoiceBench 64.73——が、それらは視覚経路と同じフォワードパス内に存在する。つまり、文字起こしが一度も書かれることなく、画像についての音声質問にモデルが答えられる。ハンズフリーの現場ツールやキオスクにとっては、それが利点だ。文書パイプラインにとっては、パラメータ予算上の無駄な重荷である。

OrcaRouterのモデルフュージョンは、両方の挙動を手に入れるもうひとつの方法です。ドキュメント特化モデルとオムニモデルが同じプロンプトに回答し、その応答を両方から構成するパネルです。これはこれら2つのチェックポイントについての主張ではなく製品機能です——どちらも現在当社のカタログにはありません——が、各モデルが職務の異なる半分で明らかに優れているという対決に対するアーキテクチャ上の答えです。フュージョンは1つのモデルへのルーティングより呼び出しあたりのコストが高く、誤った回答のコストがトークンのコストを上回るまさにその場面でこそ価値があります。

決定

作業が読み取り——OCR、請求書、フォーム、グラフ、スクリーンショット、長いPDF、高密度なUI——であるなら、MiniCPM-V 4.7 1B は公開されているあらゆる指標で優れたモデルであり、コンテキストは8倍、ライセンスは収益閾値付きの独自ライセンスではなく Apache-2.0 で、ディスク上でもより小さい。これは僅差ではなく、1Bモデルと呼ばれているという事実によってそれを曖昧にすべきではない。

用途がカメラとマイクを備えたデバイスとの会話であるなら、LFM3-Omni-2B は2つのうち参加できる唯一のものです。読解性能は劣り、保持できるコンテキストも少なく、より厳しい条件で提供されていますが、代替案に3つのモデルとパイプラインが必要なら、そんなことは問題になりません。

第3のケースにも名前を付ける価値があります。両方を必要とする製品で、ドキュメント経路と音声経路が別々の機能になっている場合です。その場合の正しいアーキテクチャは1つのモデルではなく2つで、リクエストの種類によってルーティングします。ドキュメントにはリーダー、音声にはオムニモデルです。唯一の問いは、両方を動かすのか、単一のエンドポイントに判断させるのかです。これは、この一連の比較が何度も行き着く問いであり、そして正しい問いです。両モデルはフットプリントが十分に近いため、両方を動かすことは現実的な選択肢です。一方で能力の差は十分に大きいため、どちらを選んでも1つだけ動かすのは妥協になります。

判定を変えるのは、どちらかのモデルの独立評価であり、特にMiniCPMを、見出しの数値が使っている4×設定ではなく既定の16×圧縮でテストする評価だ。その一つの数値がギャップの大部分を埋めるかもしれない——あるいは広げるかもしれない。誰かがそれを公開するまでは、ベンダー公表の表が手元にある唯一のものであり、それは一方向を指している。