MiniCPM-V 4.7、35Bの視覚モデルを3GBに：100 tok/sという主張を解きほぐす

350億パラメータのモデルは3ギガバイトには収まりません。MiniCPM-V 4.7 35B-A3Bはそれでもおよそ3ギガバイトで動作し、どちらの記述も正しい——これが仕組みのすべてであり、このリリースについて出回っている数字を腰を据えて見る価値がある理由です。このモデルはOpenBMBによるMiniCPM-Vライン初のスパース混合エキスパートモデルで、保存パラメータ数は352億、トークンあたり約30億がアクティブ、Apache-2.0、重みはHugging Faceで公開されています。画像、複数画像セット、動画を読み取り、テキストで回答します。10月10日以降はアップストリームのllama.cppでも動作し、多くの人がそこでこのモデルに出会いました。以下では、誰もが繰り返している3つの数字——3GB、35B、100 tok/s——を切り分け、そのうちどれをOpenBMBが実際に公表したのかを示します。 200以上のホスト型モデル、1つのキー、プロバイダー定価を0%のマークアップでそのまま提供。 OrcaRouterがルーティングする内容を見る オープンウェイトのチェックポイントは手元のハードウェアに残り、ホスト型の代替手段は1つのエンドポイントです。 このようなリリースの背景にある、記録されたAI障害やエージェントインシデントは以下にまとめられています： OrcaRouter AI Incident Archive では、各エントリに独自の情報源、重大度、信頼度グレード、異議フラグが付いています。

3ギガバイト、350億パラメータ、そして矛盾なし

算術が不可能に見えるのは、「メモリ内」が「そのすべて」を意味すると仮定した場合だけだ。MiniCPM-V 4.7 35B-A3B は約30億パラメータを常駐させ、ルーターが要求するのに応じて残りのエキスパートをストリーミングする。モデルカード自身の表現では「Lookahead Expert Scheduling」、つまり次の層が必要としそうなエキスパートを先読みし、その読み込みをすでに進行中の計算とオーバーラップさせる、層をまたぐルーティング予測器だ。モデルカードは、予測が先読みとスケジューリングを駆動するだけだと慎重に述べている。トークンは依然としてモデルの実際のルーティングに従い、予測器が見逃したエキスパートも他のエキスパートと同様に読み込まれ評価される。

その違いには測定可能な結果が伴います。GGUFリポジトリは、すべての一般的な量子化形式でモデル全体を公開しており、これらのファイルはいずれも3ギガバイトではありません：

• Q4_K_M — ディスク上で 21.2 GB。

• Q8_0 — 36.9 GB。

• F16 — 69.4 GB.

• ビジョンプロジェクター — 4倍圧縮で0.9 GB、f16で1.1 GB。

「3 GB」はスマホでのエキスパートストリーミング時の常駐メモリの数値であり、ダウンロードサイズでも、デスクトップ向けのVRAM要件でもありません。導入を計画しているなら、ディスクと最初の読み込みを左右する数値はQ4_K_Mで21.2 GBであり、スマホでの定常状態のフットプリントを左右する数値はベンダーの約3 GBです。どちらもリリースに記載されています。これらは別々の問いに答えるものですが、ほとんどの報道はそれらを一つにまとめてしまっています。

100 tok/s がどこから来るのか、そしてどこからは来ないのか

率直に言うべき点はここだ。OpenBMBはMiniCPM-V 4.7について100 tok/sという数値を公表していない。モデルカードに載っている数値は、iPhone 17 Pro Max上、約3 GBのメモリで13+ tokens/sだ。これがこのリリースで示されているオンデバイススループットに関する唯一の主張であり、ラボ外の誰も再現していないハードウェア上でベンダーが測定したものだ。

より高い数値も実際に存在し、それは別の成果物に由来します。OpenBMBのllama.cpp-omniフォーク — オンデバイス最適化を担うリポジトリ — は、35B-A3Bターゲット向けに独自の表を公開しており、どの最適化が有効になっているかによって積み上げた形で示しています:

• iPhone 18 Pro Max、12 GB — ベースラインは 3.38 tok/s、Lookahead Expert Scheduling で 11.34、混合精度を追加して 17.16、DSpark ドラフトヘッドも併用して 20.51。

• iPad Pro 11インチ M4、16 GB — ベースライン2.97 tok/s、LESで9.81、混合精度で14.92、DSparkで17.39。

これらはこのモデルについて公開されているオンデバイスの最高値であり、その最上位は 20.51 tok/s で、100 の5分の1です。この差が重要なのは、モデルの用途が変わるからです。13 tok/s なら、スマホアプリは写真についての質問に数秒で答えます。100 tok/s なら、動画向けのストリーミング一次読み取り器として検討するでしょう。前者は現実の製品です。後者は出荷されたものではなく、ツイートの数値を前提に予算を組む人は、5倍の隔たりに失望するでしょう。

100 tok/s という主張を正直に読み解くと、それは3つの別々の事実——3 GB、ローカルで動作する、前世代よりはるかに速い——を、どの情報源にも含まれていない1つの数値に圧縮したものだ。世代間の改善は現実であり、かつ大きい。3.38から20.51 tok/sは同じクラスのデバイスでの6倍の進歩であり、より大きなチップによるのではなく、3つの技術を積み重ねることで達成された。

リリースは一日だけではなく、日付が重要です。

MiniCPM-V 4.7は、今の多くのオープンウェイト・リリースがたどるのと同じ形で登場した。まずファイルが公開され、説明は後から、フレームワーク対応はその間のどこかで、という具合だ。

・10月6日 17:40 UTC — 1BモデルとそのAWQ、GPTQ、int4バリアントがHugging Faceに登場、さらに18:05にはGGUFビルドも公開。

• 10月7日 07:07 UTC — 35B-A3B リポジトリが公開。モデルカードは依然としてなし。

• 10月8日 — 両サイズ向けの DSpark 投機的デコーディング用ヘッド、および 35B の FP8 ビルド。

• 10月10日 18:42 UTC — llama.cpp、モデルのサポートをマージ。

・10月12日 — OpenBMBがモデルカードをコミットし、Apache-2.0を宣言し、文書化された製品としてこのリリースを発表。

• 10月15日 — DSpark ヘッドはメインカードからリンクされており、両方のターゲット向けの GGUF ドラフトも用意されています。

その順序は、二次的な報道における多くの混乱をよく説明している。10月の第2週にllama.cppを通じてこのモデルに出会った人物は、公式にはまだ存在していなかったリリースを実行していたのであり、ライセンスタグもベンチマークチャートもなく、そのスループット数値はOpenBMBがベンチマークしたものではなく、フレームワーク自身の量子化の選択を反映したものだ。

llama.cpp サポート：マージ済みだが、まだ完全には終わっていない

MiniCPM-V 4.7を追加したアップストリームのプルリクエストは、何が変わったかについて異例なほど分かりやすく書かれており、その答えは、アーキテクチャ上はほとんど何も変わっていないというものだ。このモデルはMiniCPM-V 4.6とほぼ同一で、差分は3D RoPE、つまり多くの視覚言語モデルが使う単一のスカラーではなく、トークンごとに時間・行・列という3つの値の位置を持つことだ。サポートは既存の4.6の経路を拡張し、その追加次元を扱えるようにする。このPRは、9月25日に作成された時点でモデルを「upcoming」と記しており、重みがどれほど早い段階で出回っていたかを示す妥当な手がかりになっている。

残渣は、その上にグラウンディング機能を構築する前に知っておく価値がある。あのマージ以来、上流の llama.cpp は MiniCPM-V 4.7 のプロンプトにおいて画像マーカートークンに誤った位置を割り当てている。画像トークン自体は正しく配置されるが、<slice>、</slice>、および行末マーカーは、参照実装である get_rope_index が行うようにタイルの隅の座標を与えられるのではなく、通常のテキストとして番号付けされる。目に見える症状は、画像内のどこに何があるかを尋ねたときに、返される座標が体系的に低く出ることだ。単体テスト付きの修正は10月14日付のオープンプルリクエストとして存在し、10月20日時点でもまだオープンのままだ。あなたの作業が「これを説明して」なら気づかないだろう。「バウンディングボックスをくれ」なら気づくはずで、マージを待つか、修正済みのパスを持つフォークを使うべきだ。

往復変換でもう1つ残るものがある。1Bモデルでは、視覚プロジェクターのほうが大きいダウンロードだ。Q4_K_Mの重みは672 MB、f16プロジェクターは1.11 GB。したがって、最小限の実用的な1Bデプロイは約1.8 GBのファイルになり、その大半は言語ではなく「目」だ — 「1Bは1 GBを意味する」という期待が間違っているとわかる細部である。

何を、何の上で実行するか

今週試すのが目的なら、最も手間が少ないのは llama.cpp か Ollama で GGUF リポジトリを使い、マルチモーダルクライアントを対応する mmproj ファイルに向ける方法です。24 GB GPU では、Q4_K_M が 21.2 GB なのでコンテキスト用の余裕がほとんどありません。8K トークンウィンドウに画像タイルも加えると快適には収まらないため、長いプロンプトも使いたいなら Q4_K_S かより小さい量子化を前提にしてください。32 GB 以上の Mac なら Q8_0 が現実的で、参照動作に最も近いものです。スマートフォンでは、ベンダー自身のアプリと llama.cpp-omni フォークだけがエキスパートスケジューリングの作業を実装しています。標準の llama.cpp では正しさは得られても 20 tok/s は出ません。

ここでルーティング層が真価を発揮するのは、ローカル呼び出しの向こう側です。スマートフォン上の3Bアクティブモデルは定型的なフレーム——このレシートを読む、この棚は在庫があるように見えるか、この看板は何と書いてあるか——に優れており、たまに仕上げられないページに遭遇します。OrcaRouterは200以上のホスト型モデルを1つのキーの背後にまとめ、各プロバイダーの定価を0%のマークアップでそのまま通すため、ベンダーの価格変更は当日に反映され、上流が劣化すれば自動でフェイルオーバーします。うまく機能するパターンは、ローカル専用ではなく、ローカルファーストにホスト型のエスケープハッチを組み合わせる形です。オープンウェイトのチェックポイントは自分の手元でホストし続け、ルーターはスマートフォンが引き渡すすべてを処理します。

MiniCPM-V 4.7はOrcaRouterでは提供されておらず、そうであるかのように示唆するつもりもありません。これはご自身で実行するチェックポイントです。

3つの数字を確定させるには何が必要でしょうか

特定のスマートフォン上で、アプリと量子化方式を明記したうえでの35Bモデルの独立した測定があれば、スループットの疑問は決着する——20.51 tok/sが第三者のストップウォッチでも成立するかを含めて。3 GBという数値について、常駐セットなのか、ピーク割り当てなのか、それとも別の何かなのかという公表された定義があれば、メモリの疑問は決着する。そして、カードが現在提供している5つのリンク付きグラフではなく、実際のスコアを載せたベンチマーク別の表があれば、「Qwen3.6 35B-A3Bより短時間で優れる」という主張を、OpenBMBが選んだ重み付けに対して検証できる。それらのどれもまだ存在しない。それらが存在するまでは、正確な文は退屈なものだ。つまり、電話上で約3 GBで報告されている毎秒13トークン以上で動作する35Bスパースモデルであり、21 GBのダウンロードと、まだ1つの未解決の座標バグを抱える統合済みフレームワーク経路を伴う、という文である。