ボクセルパゴダ、10%少ないトークン、そしてOpenBMBが実際に支持するたった一文

今週、MiniCPM-V 4.7 35B-A3Bについて最も引用された文は、そのモデルカードには載っていない。それは2026年10月13日に投稿されたツイートで、次のように書かれている。「MiniCPM-V 4.7 35B-A3Bはトークン使用量が少なかっただけでなく、Qwen 3.6 35B-A3よりも優れたボクセル五重塔を生成した」。それが指し示すデモは、2つの言語モデルがそれぞれ3Dボクセルの日本式五重塔のコードを書き、横に並べてレンダリングされた動画だ。これは本当に興味深い成果物である——画像プロンプトから、視覚言語モデルが建造物を三次元で再現する様子を示しており、これはその建造物にキャプションを付けるよりも難しい課題だ。しかし、そのツイートが何であるかと何でないかを切り分ける価値はある。というのも、3つの異なる主張が1行に融合されており、それらには3つの異なる裏付けの度合いがあるからだ。MiniCPM-V 4.7 35B-A3BはOpenBMBの実在するチェックポイントで、およそ1週間前に登場した。Qwen3.6-35B-A3Bは9か月前のオープンウェイトの競合で、同じくApache-2.0であり、同じく同じ公称サイズのスパースな混合専門家モデルでもある。以下では、それらをめぐる効率性の主張のうち、どれが検証可能で、どれがグラフのJPEGにすぎないのかを述べる。

1つの文をまとった3つの主張

そのツイートは切り離せる3つの事柄を一つに束ねており、そのうち1つしか文書化されていないのだから、それらは分けて論じるに値する。

• 「使用トークン数が少ない」 — これは1つのタスクにおけるトークン消費量に関する測定可能な記述です。デモとともに流れている数値は、Qwen3.6 35B-A3Bより10%少ないトークン数です。その数値は比較を実行した第三者作成者によるもので、OpenBMBの評価によるものではなく、また単一のプロンプトペアであり、ベンチマークではありません。

•「より良いボクセル仏塔を生成した」——これは、レンダリングされた2つの仏塔を見て下される判断である。評価基準も、採点用ハーネスも、独立した第三者も存在しない。これは、人間なら3秒で口にするが、ベンチマークにはまったくできない種類の主張である。なぜなら、「より良い仏塔」には正解（グラウンドトゥルース）が存在しないからだ。

•「効率と品質の両立こそが本当の主戦場だ」——この部分は一つのテーゼであり、しかもOpenBMBがモデルカードで数字を添えて文書として実際に主張しているテーゼでもある。ただ、流布した一文がそれだったわけではない。

これが重要なのは、最初の2つの主張は記憶に残りやすいものだが、3つ目は擁護できるものだからだ。チェックポイントに70GBのダウンロードを費やすかどうかを決めているなら、必要なのは3つ目だ。

OpenBMBが実際に書いたもの、そしてそれを書いた時期

まずタイムラインから。というのも、それは語り直されるうちに圧縮されてしまっているからだ。重みは静かに公開された：openbmb/MiniCPM-V-4.7-1Bは2026年10月6日17:40 UTCに作成され、openbmb/MiniCPM-V-4.7-35B-A3Bは10月7日07:07 UTCに作成された。この時点ではどちらにもモデルカード、ライセンスタグ、ベンチマークがなかった——当時ここで取り上げたとおりで、350億パラメータのアップロードとしては奇妙な状況だった。6日後の2026年10月12日、OpenBMBはドキュメントを一気にコミットした。モデルカード、Apache-2.0ライセンス、評価チャート、新しいシリーズを冒頭に掲げた書き直し済みのリポジトリREADME、そして発表。その日、パラメータは変わらなかった。変わったのは説明だ。

ですから、正直な言い方は「MiniCPM-V 4.7 35B-A3Bが今週ローンチされた」ではありません。「MiniCPM-V 4.7 35B-A3Bが今週、読めるようになった」です。今や引用可能なそのあらゆる要素は、6日と7日にアップロードされたが文書化されていなかったものか、12日に書かれたベンダー主張かのどちらかです。

モデルカードが実際にする主張

カードからそのまま引用した文は次のとおりで、ツイートより狭い内容です。Instructモードでは、35B-A3Bバリアントは「Qwen3.6 35B-A3Bよりも短い推論時間でより高い総合スコアを達成する」と述べています。それだけです。トークン数も、差も、各ベンチマークの内訳を文章で示したものもありません。その根拠は散布図です — 縦軸に平均評価スコア、横軸に対数スケールで推論時間（秒）をとり、その上でMiniCPM-V 4.7 35B-A3BがQwen3.6-35B-A3Bの上方かつ左方に位置しています。グラフ自体の脚注では、平均を5つのベンチマーク（MMStar、MMMU-Pro、CharXiv reasoning、BLINK、MathVista）の平均と定義しています。円はInstructモードを、ひし形はThinkingモードを表します。

それは2次元のトレードオフに関する、現実的かつ具体的な主張であり、今回の発表の中で最も強力な点です。また、このチャートからは読み取れないことも指摘しておく価値があります。プロットされた点には数値ラベルが付いていないため、スコアや時間を読み取ることはできず、わかるのは方向性だけです。描かれている方向性は、両方の軸において同時にMiniCPMを支持しています。

そしてそれはベンダーによって測定された。そのカードの評価数値には「結果は公開レポートおよび公式チェックポイントを用いた当社のローカル評価によるものです」という一文が添えられている。ローカル評価とは、OpenBMBのハードウェア、OpenBMBのハーネス、OpenBMBのモード選択を意味する。それはモデルカードが行うこととしては普通のことだが、それを事実に仕立て上げるのは異常なことだ。独立した第三者がこれら2つのチェックポイントを共通のハーネスで実行したことはない。どちらの結果もリーダーボードに収載されていない。これを書いている時点で、この主張の出所はただ一つしかなく、その出所はモデルを販売している。

トークン効率はどこから来るはずなのか

効率性の主張は、ベンチマークチャートに依拠しているわけではない。それは3つのエンジニアリング上の選択に依拠しており、それらは、この優位性があなたのハードウェアにも移るかどうかを左右するため、理解する価値がある。

• Lookahead Expert Scheduling（LES）——看板技術。スパースな mixture-of-experts は、トークンごとに活性化するよりもはるかに多くのパラメータを保持しており、すべてのエキスパートをメモリに載せられないデバイスでは、重みがページインとページアウトを繰り返してデコーディングが止まってしまう。LES は層をまたぐルーティング予測を用いて、次の層で必要になる可能性が高いエキスパートを事前ロードし、実際のルーターが選択したエキスパートのうち、たまたますでにロード済みのものの計算を優先する。OpenBMB は、予測があくまでプリフェッチとスケジューリングを駆動するだけであり、モデルのトークン単位のルーティングは変わらず、予測器が取りこぼしたエキスパートも依然としてロードされ評価されると慎重に明言している。このカードは、これによって実機で5倍の高速化が達成され、能力の損失はないと主張している。

• 細粒度のレイヤー単位量子化 — エキスパートの重みの占有領域とメモリトラフィックを削減し、オンデバイスのロードパターンを適合させるためのもう半分を担います。

• DSpark投機的サンプリング — 対になるドラフトモデルの経路であり、openbmb/MiniCPM-V-4.7-35B-A3B-DSparkとして別途公開され、スケジューリングおよび量子化の取り組みと並んで統合されています。

積み重ねると、これらはリリースの目玉となる数値を生み出す。iPhone 17 Pro Max上で約3 GBのメモリを使いながら、毎秒13トークン以上。それはベンダーの公称値であり、ベンダーのハードウェア上で、ベンダーのソフトウェア——OpenBMBが書いたアプリ——によるものだ。これは、製品のすべてか、さもなければ何もないかのどちらかになる類の主張であり、現時点で社外の誰もそれを検証する方法はない。なぜなら、それを再現するには、そのスマホのデモが動かしているオンデバイススタックが必要だからだ。

トークン効率は確かに重要だが、ここではそれはスカラーではなく行列だ

このリリースには、そのあらゆる要約においてならされて消えてしまった細部が一つあり、それこそがトークンエコノミクスを実際に規定しているものだ。

• MiniCPM-V 4.7 35B-A3B は、リクエストごとに選択可能な 4x と 16x のビジュアルトークン圧縮に対応しています。16x 設定は速度のためにビジュアルトークンを統合し、4x は 4 倍のトークンを保持して詳細を保ちます。カードのデフォルトは 16x で、パラメータはチャットテンプレートと generate 呼び出しの両方に渡す必要があります。そうしないと、プレースホルダー数とビジョンエンコーダーが一致しません。

• ベンダー自身の視覚言語比較表には、各モデルの行に使用された圧縮設定が記録されている。その表では、MiniCPM-V 4.7 35B-A3Bの行は4x — 詳細保持設定、つまり高コストな方 — であり、Qwen3.6 35B-A3Bの行は16xである。31B Gemma 4の行は9x、2つの27B Qwenの行は4xと記載されている。

• 脚注には、MiniCPM-V 4.7 はいずれの設定もサポートする一方、表内の他のモデルは固定の圧縮率のみをサポートすると明記されている。

それを合わせて読むと、全体像が変わる。MiniCPMの行がトークンを多く消費する設定で視覚言語スコアを出している一方、Qwenの行がトークンを節約する設定でスコアを出しているなら、この2つの列は異なる量の視覚的詳細を比較していることになり、効率の話は「同じ入力で、より少ないトークン」ではなく、「調整可能な入力で、品質で勝つのはこちらの列だ」ということになる。それはツイートの主張よりも興味深く、より誠実な主張であり、OpenBMBはそれを前面に出すのではなく脚注で公表した。

つまり、本当に気にすべき数値——視覚的ディテールの単位あたりのトークン数——は、この表からはまったく読み取れないということでもある。それを得るには両方のモデルを同じ設定で動かす必要があるが、そんなデータは誰も公開していない。

注意事項が添付されたその表

このカードはベンダーによる表を2つ同梱している。1つは視覚言語用、もう1つは言語用で、どちらもInstructモードであり、どちらも35B-A3BクラスのQwenモデル2つ、31BのGemma、27BのQwen 2つを含むモデル群を対象としている。以下の数値はベンダー自身のPNGチャートから読み取ったもので、注意点は構造的なものだ。つまり、数値はそのチャート内にピクセルとしてのみ存在し、表として存在するわけではない。そのため、以下は機械読み取りによって抽出されたものであり、小さな転記ミスが生じている可能性がある。

• OCRBench — MiniCPM-V 4.7 35B-A3B が 91.20、Qwen3.6 35B-A3B が 90.40。ベンダー自身の実行で 0.8 ポイント差。

• OmniDocBench v1.6 — MiniCPMは約98.2、Qwenモデルは約93.3で、これは表の中で最大の単一の差であり、再現された場合に最も重要になるものだ。文書解析は通常トークン予算が費やされる領域だからである。

• MMMU — 約80.2 対 80.0、チャート画像の解像度では互角の勝負。

• MMMU-Pro — 約69.7 対 67.7、27BのQwenがその両方よりも上位に位置する行において。

• 言語表 — 同じ形で、より際立つセルは指示追従とコードにある。IFBench は 47.7 対 35.3 あたり、LiveCodeBench-v6 は 97.0 対 54.3 あたりに記載されている。これら二つは十分に大きく、他の誰かがそれらを実行するまでは、このリリースで最も信頼性の低いセルとして扱うべきだ。同程度の規模のオープン MoE モデル間で、コードベンチマークに 43 ポイントの差があり、しかも二者のうち一方によって測定されたというのは、第二の計器を必要とする主張である。

ベンダー報告、ベンダー製ハーネスによる測定、未再現。それがすべてだ。もしこれらの数値が独立したハーネスで持ちこたえるなら、パレートフロンティアの主張は正しく、パゴダの動画は脚注にすぎない。そうでなければ、パゴダの動画だけが残る。

導入数が語ることは、品質については何も語っていない。

この比較のなかで一つの数字だけは誰も異を唱えておらず、しかもそれはベンチマークではない。2026年10月13日に読んだHugging Faceのダウンロードカウンターは、openbmb/MiniCPM-V-4.7-35B-A3Bが630であるのに対し、Qwen/Qwen3.6-35B-A3Bはおよそ360万を示している——2026年4月15日に作成されたリポジトリであり、したがって採用曲線において約9か月先を行っている。この差が測っているのは時間であって優劣ではなく、まさにこれが、効率性の問いがそもそもこの方向で問われる理由である。新参者は、デフォルトになるための9か月を持たなかったからこそ、トークンあたりで論じなければならないのだ。

このリスティングには、指摘しておく価値のある小さな内部矛盾も存在する。リポジトリはファミリーの他のモデルから受け継いだ「On-Device Model」タグを備えているが、70.4 GB の BF16 重みに収められた 352 億パラメータのスパース MoE は、ダウンロードする者が認識するいかなる意味でもオンデバイスではない。オンデバイスの話自体は本物だが、それはチェックポイントそのものではなく、チェックポイント上での量子化とエキスパートストリーミングを通じて成り立っている。予算はタグではなく、量子化ビルドとアプリを基準に立てること。

今週それについてどうするか

実用的な立場は狭く、明確だ。効率性の主張を検証したいのなら、まだ検証できるものは何もない — それは一つのベンダーのグラフであり、タスクごとの数値が添えられた唯一の数字（トークンが10%少ない、パゴダ1つ）は、第三者の単一のデモに由来する。モデルを実行したいのなら、重みはApache-2.0で、アーキテクチャは文書化されており、ダウンサンプリング設定は自分で選べる。これは本物で、過小評価されているレバーだ。スループットが重要なら16x、そのグラフが文書を表示しているときは4x。

この比較の片方は今すぐホスト型API経由で利用でき、もう片方はそうではありません。どちらがどちらなのかは正確に押さえておく価値があります。 qwen/qwen3.6-35b-a3bはOrcaRouter上のホスト型モデルです——単一のキーの背後にあるカタログに並び、Qwen自身の定価のままで上乗せは一切ありません、固定したプロバイダーではなく健全なプロバイダーへと振り分けられます。MiniCPM-V 4.7 は当社がホストしているものではなく、ご自身で運用するオープンウェイトのチェックポイントです。この非対称性こそがここでの役立つポイントです。この比較のQwen側は今日の午後にもベースラインへ組み込めますし、OpenBMBのハーネスを自社データに対して実行し、ベンダーのチャートは答えではなく仮説として扱えます。

議論全体があなたのハードウェア上での効率性をめぐるものだった以上、それを決着させられる唯一の測定値はそれだけだった。