MiniCPM-V 4.7 35B-A3B vs PixelUMM：ベンチマークが決める前に、1つのライセンスがこれを決める

MiniCPM-V 4.7 35B-A3B と PixelUMM の間で、ベンチマークを1つも読まずに下せる判断があります。そしてそれは、おそらく最も重要な判断です。MiniCPM-V 4.7 35B-A3B は Apache-2.0 です。PixelUMM のモデルチェックポイントはそうではありません — NVIDIA の One-Way Noncommercial License の下で提供されており、これは研究と評価のみを許可し、しかも NVIDIA 自身が「本番環境や高リスク用途では検証されていない」と述べているチェックポイントに対するものです。販売するつもりのものを構築しているなら、この2つのモデルのうち片方は選択肢にならず、残りの比較は机上の空論です。研究を行っているなら、可能性は広がり、興味深い問いは、NVIDIA のエンコーダ不要設計が実際に何に対抗して賭けているのか、ということになります — なぜならそれは、まさに MiniCPM-V 4.7 が採用しているアーキテクチャに対抗して賭けているからです。

両モデルはひっそりとリリースされた。PixelUMMの重みは2026年10月1日21:40 UTCにHugging Face上に公開されたが、ブログ記事もプレスリリースも基調講演もなかった。プロジェクトページのURLは今も「preview」のままだ。MiniCPM-V 4.7も10月6日に同じ形で登場し、OpenBMBがモデルカード、ライセンス、主張セクションを掲載したのは10月12日になってからだった。どちらも誰によっても独立に評価されておらず、読者が引用できるベンチマーク表もない。PixelUMMのカードにはスコアが一切報告されておらず、MiniCPM-V 4.7の性能に関する主張はテキストではなくグラフ画像の中にある。以下では、リポジトリが述べていることと、2つのラボの外部でまだ誰も確認していないことを分けて示す。

PixelUMMとは何か、1段落で

PixelUMMは、反復的なピクセル生成ヘッドを備えた15,199,672,064パラメータのデコーダ専用Transformerであり、特定のリビジョンに固定されたQwen3-8Bバックボーン上に構築されている。その主張はモデルカードの最初の行に示されており、実に逆張り的だ。VAEもビジョンエンコーダも持たない。従来の統合モデルが2つの視覚インターフェース——理解のための意味的特徴を生成するビジョンTransformerと、生成のための再構成潜在変数を生成する変分オートエンコーダ——を備えているのに対し、PixelUMMはどちらも備えていない。画像は16×16ピクセルのパッチに、動画は4フレームの時空間チューブレットに分割され、どちらも単層の線形投影だけを通ってバックボーンに到達し、生成処理は反復的ノイズ除去が担う。論文ではこれを、共有アテンションとタスク固有のパラメータを組み合わせたMixture-of-Transformersとして説明している。テキストから画像、画像を条件としたテキスト生成、動画を条件とした理解と動画生成を処理し、96フレーム、24 fps、4秒のテキストから動画への生成も含む。

その周辺の痕跡は約4週間にわたり、その間はすべて静かだった。GitHubリポジトリnv-tlabs/PixelUMMは2026年9月4日にApache-2.0の下で作成され、月の大半は単一のコミットのままだった。9月28日から29日にかけて最初のコミットが行われ、arXivはプレプリント2609.38597を割り当てた。その著者リストはNVIDIAとウォータールー大学にまたがっている。モデルリポジトリ自体は10月1日21:40 UTCに現れた。論文の引用を追加する最後のGitHubコミットから8分後のことだった。論文には掲載先を示す行がない——学会名も、「accepted to」も——。これは製品発表というより、研究チームが成果物をライブで公開したように読める。ただし、それは証拠についての観察であり、意図についての主張ではない。

MiniCPM-V 4.7 35B-A3Bとは何か

MiniCPM-V 4.7 35B-A3B は、OpenBMB による MiniCPM-V シリーズ初の MoE モデルです。256 個のエキスパートを持ち、トークンあたり 8 個がアクティブで、40 層、262,144 トークンのコンテキストウィンドウ、248,144 トークンの語彙を備え、総パラメータ 35.2B のうち約 3B がアクティブパラメータです。視覚処理は SigLIP2 モジュールを通じて実行され、LLaVA-UHD v4 の intra-ViT 早期圧縮と、選択可能な 4x/16x 混合視覚トークン圧縮モードを備えています。スループット重視の場合はデフォルトで 16x、細部が重要な場合は 4x です。単一画像、複数画像、動画を理解し、テキストで回答します。画像生成は行いません。

このカードの目玉となる主張は、これが初のオープンソースMoEモデルであり、ロスレスで滑らかなオンデバイス推論を実現するというものだ。それを支えるのは、Lookahead Expert Scheduling、細粒度のレイヤー単位量子化、そして別個のDSparkドラフトによる投機的サンプリングであり、iPhone 17 Pro Max上で毎秒13トークン以上（報告値）とされている。この数値はベンダーによる報告であり、再現されておらず、条件も明示されていない。このカードはまた、Qwen3.6 35B-A3Bよりも短い推論時間でInstructモードの総合スコアが高いとも主張している。これはグラフ画像の中に現れる主張であり、つまり引用可能な数値ではなく、そのように扱うべきではない。

MiniCPM-V 4.7 が紛れもなく先行しているのは、どのスコアボードの上でもなく、周辺の布陣においてだ。それらはすべて実在し、ダウンロード可能である。base、FP8、int4、AWQ、GPTQ、GGUF の重み；SGLang、vLLM、llama.cpp、Ollama、OpenVINO にまたがるサポート；iOS、Android、HarmonyOS アプリ；そして day-zero シリコン対応として挙げられている Rockchip、Houmo、Intel、AMD、Arm だ。6週間前、このモデルに対する正直な批判は、それがドキュメント化されていないチェックポイントだというものだった。それはもはや当てはまらない — ドキュメント化された、ベンチマークのないチェックポイントである。別の問題であり、より小さな問題だ。

比較の陰に隠れたアーキテクチャ論争

2つのモデルは何か根本的なことについて意見を異にしている。そして、それには名前を付ける価値がある。なぜなら、それはこの対決のなかで、どちらのモデルよりも長い寿命をもつ部分だからだ。

• 視覚が言語モデルに届く仕組み — PixelUMM は生のピクセルと単一の線形投影を使用し、スタック内のどこにも事前学習済みの視覚エンコーダーを持ちません。MiniCPM-V 4.7 は SigLIP2 エンコーダーを使用し、ViT 内での早期圧縮と設定可能なダウンサンプリング比を備えています。

• 生成の仕組み — PixelUMM は、自己回帰テキスト予測と共同で学習されたフローマッチングヘッドを通じて、ピクセルを反復的に予測します。MiniCPM-V 4.7 はテキストのみを生成し、それ以外は生成しません。

• それによって得られるもの — PixelUMM は、画像を記述し、かつ画像を生成する単一の重みセットを得る。その代償は研究専用ライセンスであり、本番環境での検証はない； MiniCPM-V 4.7 は、小型で量子化可能、スマートフォンに配備できるモデルを得る。それは世界を読むことはできるが、描き直すことはできない。

• パラメータ数 — 15.2Bのdense寄りモデルに対し、合計35.2Bでアクティブ3B。推論コストを予測するのはアクティブパラメータ数であり、その軸で見ると、MiniCPMモデルは2つのうち小さい方で、しかも1桁小さい。

• ディスク上の重み — PixelUMM のリポジトリには 4 つのチェックポイントバリアントにまたがる 491 個のファイルが含まれており、MiniCPM-V 4.7 のベースビルドは約 70 GB の 16 個の BF16 シャードです。

• ライセンス — チェックポイントには Apache-2.0 と NVIDIA One-Way Noncommercial のどちらかが適用され、Apache-2.0 は PixelUMM のソースコードにのみ適用され、Qwen3-8B ベースは別途 Apache-2.0 です。PixelUMM のカードには、BAGEL に由来する改変コードが含まれているとも記載されているため、上流の条件がさらに適用されます。

• 公開評価 — 双方ともなし。MiniCPM-V 4.7 は少なくとも性能に関する主張はあるが、PixelUMM のカードにはベンチマーク数値が一切記載されていない。

どちらを実際にユーザーの前に出せますか？

ライセンスとデプロイの事情を一緒に追っていけば、選択はおのずと見えてくる。

PixelUMMは、研究上の成果物としてはより興味深く、製品としてはより使い物にならない。非商用チェックポイントは明白な商用利用を完全に阻み、モデルカードにはサービング用レシピも、量子化ビルドも、コンテキスト長の数値もなく、83件のいいねに対して記録されたダウンロードがゼロということは、著者以外には事実上誰もこれを実行していないことを意味する。現時点でのその価値は、統合モデルにおいて視覚エンコーダが不要かもしれないという、強力で公表された主張としてのものだ。その主張は、重みをロードするかどうかにかかわらず、追い続ける価値がある。

本番投入への道筋があるのは MiniCPM-V 4.7 であり、その道は狭いが確かなものだ。Apache-2.0 がライセンス上の疑問を解消する。6 種類の量子化フォーマットと 5 つの推論ランタイムがあれば、独自カーネルを書く必要はない。非量子化ビルドには GPU が 2 基以上必要であることが壁であり、量子化ビルドとオンデバイス向けの話がその回避策だ。そして、オンデバイスでの主張こそ、独立した検証がなされていないまさにその点である。今日実行できるモデルとして、そしてまだ当てにできない性能上の主張として扱うべきだ。

「どちらでもない、別のものを呼び出す」という答えを出すチームにとって、MiniCPMの形状に最も近いホスト型の相当品はQwen3.6 35B A3Bです — 総パラメータ35B、アクティブ3B、コンテキスト262K、テキスト・画像・動画の入力も同じ — そしてそれはOrcaRouter経由で、プロバイダーの定価のままマークアップなしで提供され、入力トークン100万あたり$0.25、出力トークン100万あたり$1.48で、プロバイダーのルートが劣化した場合には自動フェイルオーバーも行われます。これは本記事のどちらのモデルの代替ではありません。70 GBのスパースなマルチモーダルMoEをセルフホストすることが実際に何をもたらすのかを教えてくれる対照群なのです。

これがどこに着地するか

アーキテクチャを除いてしまえば、正反対の方向を向く2つの静かなリリースが残る。NVIDIAは、ほとんどの人の利用を妨げるライセンスの下で論文級の成果物を、そしてレシピもベンチマークもダウンロードもないリポジトリを公開した。OpenBMBは、文書化され、寛容なライセンスのマルチランタイムモデルを公開した。説得力のある効率性の主張を掲げつつ、それを裏付ける評価表はない。

それぞれに決着をつける唯一のものは：PixelUMMについては、独立した再現がどのような形であれ存在すること——ダウンロード数が0ということは、外部のデータ点が一切存在しないことを意味し、エンコーダ不要論は、2つ目の実装に触れた途端に持ちこたえるか崩れ去るかのどちらかになる、まさにそういう種類の主張だ。MiniCPM-V 4.7については、ベンチマーク表、あるいはDSparkドラフト上で再現されたアクセプタンス長——これはこのファミリーで公表された数値を持つ唯一の部分だ。どちらもまだ存在しない。両方とも、これらの2つのモデルが片付けてしまうのではなく、依然として注目に値する理由である——両者は世に出てからの歩みが報道が示唆するよりも早い段階にあり、どちらもそれを作ったラボによってローンチとは呼ばれていない。