Moondream 3 対 MiniCPM-V 4.7：誰も言及しないMoEストレージの請求書

どちらもMoondream 3 PreviewとMiniCPM-V 4.7 Mixture-of-Experts 型の視覚言語モデルであり、どちらも小さなアクティブパラメータ数で宣伝されているため、控えめなハードウェアに収まりそうに聞こえる。Moondream 3 Preview は 9B のパラメータのうち 2B をトークンごとにアクティブ化する。MiniCPM-V 4.7 の主力バリアントである MiniCPM-V 4.7 35B-A3B は、35B のうち約 3B をアクティブ化する。これら2つの文を読めば、Moondream のチェックポイントのほうがデプロイが簡単だと期待するだろう。実際にそうかどうかは、どちらの発表記事も冒頭では触れていないある問いに完全にかかっている。眠っているエキスパートはどこにいるのか？

その問いこそ、この2つのモデルが真に分かれる点であり、その答えは、MiniCPM-V 4.7が今の形で存在している理由そのものです。そのリリース——OpenBMBによるMiniCPM-V 4.7 35B-A3BとMiniCPM-V 4.7 1Bで、2026年10月6日に公開——は、35B MoEを性能を落とさずスマートフォン上でスムーズに動かすことを中心に設計されています。Moondreamが2025年9月18日にリリースし、2026年10月の買収により現在はPrime Intellectの一部となっているMoondream 3 Previewは、逆の道を選びました。すなわち、MoEを小さく保ち、Moondream独自の推論エンジンであるPhotonを使ってGPU上で動かすという道です。どちらの選択も間違っていません。それらは異なる制約への答えであり、あなたが置かれている制約が、あなたにとっての比較を決めるのです。

アクティブパラメータは計算上の数値であり、ストレージ上の数値ではない

これはオンデバイスMoEを難しくする算術であり、OpenBMBは自社のモデルカードでそれを明示している。MoEモデルは、単一トークンに対して実際に活性化するパラメータ数よりもはるかに多くの総パラメータを持ち得るが、そのオンデバイスでのストレージ要件は、それらの活性化パラメータだけに限定されるわけではない。異なるトークンは異なる層で異なるエキスパートを選択し、デバイスのメモリはしばしばそれらすべてを保持できない。

• Moondream 3 Preview — 合計9B、アクティブ2B。24層、最初の4層はdense、残りは64エキスパートを持ちトークンごとに8エキスパートが活性化されるMoEフィードフォワードブロック。隠れ次元2048、GeGLUのinner/gate次元1024。

• MiniCPM-V 4.7 35B-A3B — 合計35B、アクティブはおよそ3B。MiniCPM-Vシリーズ初のMoEです。同じリリースの1BバリアントはMoEではなくdenseであり、この点は後述で重要になります。

• 食い違い — アクティブを総数で割ると、Moondream 3 Preview の方が圧倒的に軽いモデルに見える。バイトをバイトで割ると、4倍の重みを担っているのは MiniCPM-V 4.7 35B-A3B の方だ。

• なぜそれが何も解決しないのか — デバイスを制約するのは常駐セットであり、常駐セットはアクティブ数よりも総数に近い。ルーターが何を発火させようと、9B の MoE は 2B の Dense モデルが収まるメモリには収まらない。

つまり「2B active」は、トークンあたりの計算量に関する記述です。必要なメモリに関する記述ではなく、それを同じものとして扱うことが、チームがMoEデプロイメントのサイズを誤って見積もる最も一般的な原因です。

OpenBMBはストレージ問題に直接取り組んだ

MiniCPM-V 4.7の設計は、まさにそのギャップを狙った3つの技術として読むのが最も適切である。Lookahead Expert Schedulingは、層をまたぐルーティング予測を用いて、次の層が要求しそうなエキスパートを先読みし、実際のルーターが選択したもののうち先読みに成功したものを優先する——予測が導くのは先読みとスケジューリングのみであり、計算は依然としてモデル本来のトークンレベルのルーティングに従い、予測が外した必要なエキスパートは通常どおりロードして評価される。Fine-grained layer-wise quantisationは、エキスパート重みの保存フットプリントとメモリトラフィックを削減する。DSpark speculative samplingはオンデバイスの経路に統合され、その両者の上にさらにデコーディング効率を高める。

示されている結果は、iPhone 17 Pro Max上で毎秒13トークン以上、メモリ約3GBであり、OpenBMBはこれを、性能を損なわずにオンデバイスでスムーズに動作する初のオープンソースMoEモデルだと説明している。その比較は明示的で、その性質を踏まえても注目に値する。Instructモードでは、MiniCPM-V 4.7 35B-A3BがQwen3.6 35B-A3Bよりも短い推論時間でより高い総合スコアに達する。これはベンダー報告による同規模クラスの主張であり、両モデルが同じハーネスで測定されているため、より有用な種類の主張だ。

デプロイメントの残りの部分は異例なほど広範だ。iOS、Android、HarmonyOS をサポートし、Rockchip、Houmo、Intel、AMD、Arm のチッププラットフォームを day-0 でサポートする。推論は SGLang、vLLM、llama.cpp、Ollama 上で動作し、ファインチューニングは SWIFT と LLaMA-Factory で行える。GGUF、BNB、AWQ、GPTQ の量子化が提供され、さらに FP8 も利用できる。1B モデルはまた別の話だ。dense であり MoE ではなく、OpenBMB はこれを、MiniCPM-V 4.6 をさらに改良し続けつつ、総合スコアと推論効率の両方で Qwen3.5 0.8B を大幅に上回るものと位置づけている。これは 1B 未満のモデルにとって誠実な比較だ。

Moondreamの答えは、重みではなくハードウェアを動かすことだった

Moondreamは9B MoEをスマートフォンに収めようとはしなかった。アーキテクチャは維持したまま、実行場所を変えた。その推論エンジンであるPhotonは、各モデルをカスタムカーネル付きの単一のGPUプログラムにコンパイルし、Ampere以降のNVIDIA GPUとApple Silicon Mac上でローカルに実行する。APIはMoondream Cloudと同じだ。

これは擁護可能な戦略であり、Prime Intellect の買収発表は、それがなぜ魅力的だったのかを説明している。Moondream のチームは Photon とその背後にある megakernel コンパイラを作り上げ、Prime が同社を買収する根拠は、モデルの有用性を決めるのはアーキテクチャではなくサービングだという点にある。その投稿にあるスループットの数値——単一の H100 で毎秒 60 回を超える Moondream 推論、数十ミリ秒での回答、Moondream 3.1 で毎秒 34 リクエスト——は Prime 自身によるもので、今では販売資料になっている。したがって、その点を踏まえて扱うべきだ。しかし方向性は明白だ。Moondream の賭けは、スマートフォンサイズのモデルよりも、GPU に支えられた高速なモデルのほうが欲しいというものだった。

2つ目の違いがありますが、それはモデルカードには一切書かれていません。Moondream 3 Previewのホスト型エンドポイントであるMoondream Cloudは、買収に伴い2026年11月13日にサービス終了となり、未使用の購入済みクレジットは返金されます。MiniCPM-V 4.7にはそのような依存はありません。そもそも主たる製品としてホスト型だったことはなく、幅広いオンデバイス展開の話が付随する重みのセットだからです。もしあなたの評価にエンドポイントを呼び出す手軽さが含まれていたなら、その手軽さはこの比較の片側で失われようとしています。

タスク能力：2枚のカードは、それぞれ異なる事柄について正直である

Moondream 3 Previewの4つのネイティブスキルは、query、caption、point、detectで、すべて構造化出力を返し、ローンチ記事では検出とポインティングが前面に出されています。queryスキルはデフォルトで推論モードで動作し、簡単な質問用にreasoning=Falseフラグが文書化されており、推論トレースはグラウンディングされています — 画像の特定の部分を参照するため、Moondreamはそれを一般的な推論ではなく、グラウンディング付きの視覚的推論と呼んでいます。コンテキストは32Kトークンで、前世代の約2Kから増加し、カスタムSuperBPEトークナイザーを使用しています。ローンチ記事は、ポストトレーニングが長いウィンドウを完全に活用しておらず、32Kの全体は主にファインチューニング用であると率直に述べています。

MiniCPM-V 4.7のカードが主眼を置くのは、むしろ効率と守備範囲の広さだ。単一画像・複数画像・動画の理解に対応し、4x/16xの混在ビジュアルトークン圧縮によって、タスクごとに視覚的ディテールと推論コストをトレードオフできる。さらに、LLaVA-UHD v4由来のViT内部での早期圧縮により、エンコーダ後段の計算量を削減する。加えて、ファインチューニング手法も搭載している。Self-Replay Fine-Tuningと名付けられたこの手法は、モデルがすでに知っていた事柄の忘却を抑えつつ、低コストで能力を拡張することを狙ったものだ。

• グラウンディングされた検出とポインティング — Moondream 3 Preview：アーキテクチャにネイティブなスキル、構造化座標、グラウンディングされた推論トレース。MiniCPM-V 4.7：マルチ画像および動画理解が明言された強みで、このカードはオープンボキャブラリ検出を前面に押し出していない。

• 動画 — MiniCPM-V 4.7 は動画入力に対応しており、128 フレームを使用した例が文書化されています。Moondream 3 Preview のカードには、同じ画像に対する繰り返しクエリのための画像エンコーディングキャッシュを備えた画像スキルが記載されています。

• 制御可能なディテール — MiniCPM-V 4.7：downsample_mode パラメータ。デフォルトは 16x、より細かいディテールには 4x で、呼び出しごとに選択されます。Moondream 3 Preview：ビジョンエンコーダーにおけるマルチクロップのチャネル連結。発表記事では、エンコーダーが非常に小さいフォントにつまずく可能性があると指摘されています。

• ライセンス — MiniCPM-V 4.7：Apache 2.0、両バリアントとも。Moondream 3 Preview：Additional Use Grant 付きの Business Source License 1.1。これは商用利用および本番利用を許可する一方、汎用目的のホスト型 Moondream の提供を禁じている。Moondream 3.1 は Moondream Model License 1.0 に移行し、同じ中核的制限がより明確に記載されている。

ライセンス条項は、この比較において脚注ではない。もしあなたが他の人向けにこのモデルをホストするつもりなら、Apache 2.0 と Moondream のソース公開型条件は、出発点としてまったく同じではない。そしてそれは、あなたのタスクでどちらのベンチマーク結果が良くても変わりない。

ファインチューニングこそ、両方のカードが正反対の理由で向かう先だ

両ベンダーとも、ベースモデルは製品そのものではないと説明する。それは清々しく、同時に価値がどこにあるかを示すヒントでもある。

Moondreamのローンチ記事は、学習可能性を4つの目標の一つに挙げている。その根拠は、実際のビジョンタスクには専門化が必要だという点——X線写真を読む、群衆の中で苦しんでいる人を見つける——そして、それらについては人間でさえ訓練を必要とするという点にある。同社はそのためにLensを出荷し、Moondream 3.1のローンチはさらに踏み込んだ。公開された3.1のベンチマークスコアは、Lensを通じて各ベンチマーク自身の訓練用分割上でタスクごとのLoRAをファインチューニングし、その後、オン・ポリシー蒸留によって学習内容をベース重みに折り込むことで生成されたもので、ダウンロード可能なチェックポイントがチューニングなしで良いスコアを出すようになっている。これは二度読む価値がある。正当なワークフローであり、異例なほど透明な開示でもあるが、それはまた、これらの数値が箱から出したままの冷たい数字ではないということも意味する——問題のタスクは、その訓練用分割をモデルに与えられているのだ。

OpenBMBの相当するものはSelf-Replay Fine-Tuningで、別の問題を対象としている。すなわち、既存の能力を忘れることなく、低コストで能力を追加することだ。その目玉となる主張は、ピークスコアではなく保持についてのものだ。

どちらのモデルをファインチューニングする場合でも、実用上の違いは、この比較全体を貫くものと同じです。Moondream の道筋は、GPU とホスト型サービスを前提としています。MiniCPM-V 4.7 の道筋は、すでに運用しているフレームワーク上でファインチューニングし、そのまま、すでにターゲットとしているデバイスへデプロイできること、そしてそこへ運ぶための公開されたオンデバイス量子化のストーリーがあることを前提としています。

ルーティング層が真価を発揮する場面

ここにあるどちらのモデルも、OrcaRouterを通じて提供されているわけではない——どちらも自分でホストするオープンウェイトのチェックポイントで、その一方は来月、ホスト型エンドポイントを失う。だからこそ興味深い問いは、両方のカードが避けているあの問いになる。つまり、選んだモデルがうまく処理できないリクエストはどうなるのか？

標準的な答えは2つ目のモデルであり、2つ目のモデルの標準的なコストは統合です。別のSDK、別の認証方式、別のリトライポリシー。それは、静かに1スプリントを食いつぶし、その後は恒久的なメンテナンスになる類の作業です。OrcaRouterのモデルフュージョンは、その問題のより限定的な版のために存在します——1つのモデルの回答だけでは十分に信頼できない呼び出しで、複数のモデルが一緒に答えるパネル——そして、より広い版のためにはルーティングDSLが存在し、複数のモデルを1回の呼び出しに構成できるようにして、安価なローカルモデルが簡単な大多数を処理し、より大きなモデルが残りを引き受けます。

1つのキーで、プロバイダー定価のまま、上乗せなしで200以上のモデルを利用できます。つまり、ベンダーの値下げは次の請求サイクルを待たず当日に反映され、上流が劣化した際にはプロバイダー間のフェイルオーバーが自動で行われます。セルフホスト型VLMにとって、ルーティングレイヤーはモデルを置き換えるのではなく、その上に位置します。これがこの比較における位置づけの正直な説明であり、MiniCPM-V 4.7 35B-A3Bがデバイス上にあり、ホスト型モデルが取りこぼしをカバーするシステムにおいては、二者が二つの別個のシステムになってしまうのを防ぐ部分なのです。

どちらになるかは、実際にあなたが抱えている制約によって決まります

モデルをデバイス上で動かさなければならないなら、MiniCPM-V 4.7 35B-A3Bが答えであり、それ以外は問題にならない。OpenBMBは、35BのMoEをスマートフォンで動かすことを妨げるストレージ問題を中心にリリース全体を組み立てた——エキスパートのスケジューリング、レイヤー単位の量子化、投機的デコーディング——そしてそこから導かれる数字を公表した。約3GBで毎秒13トークン以上。Moondream 3 Previewには、その問題に対処するものは何もない。Moondreamは、そもそもその問題を抱えないことを選んだのだから。

GPU が視野に入っていて、グラウンデッド検出がタスクなら、Moondream 3 Previewはより専門化されたツールです。構造化座標によるネイティブな detect と point、そして検査可能なグラウンデッド推論トレースは、画像内のテキストも読む汎用マルチモーダルモデルとは別物であり、人間が出力を確認するなら、トレースこそが売りです。

2つのどちらにするか迷っているなら、ベンチマーク表で判断しないでください。自分の画像を自分のプロンプトで両方に通し、その出力を採点してください。この比較で、あなたのワークロードに触れても生き残る唯一の数値は、あなた自身が生み出すものだからです。そして、モデルを検討する前にライセンスを確認してください。Apache 2.0 と、ホステッドサービス制限付きのソース公開ライセンスは、まったく別の判断だからです。そのうちの一方は、精度の数字が問題になる前に評価を終わらせてしまうかもしれません。

このような比較は、失敗モードが表面化する場でもあります。このクラスのモデルの背後にある、記録されたAIインシデントやエージェントの障害は、OrcaRouter AI Incident Archiveにまとめられており、各エントリには独自の情報源、重大度、信頼度グレード、異議フラグが付いています。