MiniCPM-V 4.7-35B-A3B-DSpark：OpenBMBの389Mドラフトが、そのベースモデルが決して得られなかったカードを携えて登場

MiniCPM-V-4.7-35B-A3B-DSpark は 389,223,169 パラメータのドラフトモデルです。質問に答えることも、画像を見ることもできず、単体では役に立ちません。その仕事は、次の15トークンを推測することだけにあり、それによって MiniCPM-V-4.7-35B-A3B は、1トークンずつ生成する代わりに、1回のフォワードパスでブロック全体を検証できます。これが投機的デコーディングであり、OpenBMB は新しい35B視覚言語モデル向けのドラフトを11日前にリリースしていたにもかかわらず、それについて公には一言も触れていませんでした。

一ページを割く価値があるのは、ドラフトのほうではない。付属してきた書類のほうだ。DSpark チェックポイントにはモデルカードがある。ライセンス、仕様表、学習レシピ、そして 7 つのタスクカテゴリ向けのアクセプタンス長表だ。その 350 億パラメータの親モデルには、登場した時点でそんなものは何もなかった。だから MiniCPM-V 4.7 のリリースには初めて実際の数値が付いている — しかもそれは親モデルについての数値で、より速く動かすことを目的と明記された 0.78 GB のファイルによって間接的に測定されたものだ。

以下では、カードに記載されていることと、カードが立証していないことを切り分ける。アクセプタンスの数値は OpenBMB 自身によるもので、ラボの外部でそれらを再現した者はいない。ベースモデルのベンチマーク表はまだ存在しない。

DSparkチェックポイントとは実際には何なのか

このリポジトリopenbmb/MiniCPM-V-4.7-35B-A3B-DSparkは2026年10月8日付です。これは単一ファイルのチェックポイント — model.safetensors、およびconfig.jsonとREADME — Apache-2.0 ライセンスの下で、英語と中国語向けにタグ付けされています。2つ目のドラフト、openbmb/MiniCPM-V-4.7-1B-DSparkは1秒早く作成されたため、両者は1つずつ発見されたのではなく、同じバッチでハブにプッシュされました。

各ドラフトは1つのターゲットの前段に置かれ、そのターゲットだけを対象とする。カードにははっきりとこう書かれている。このチェックポイントは「MiniCPM-V-4.7-35B-A3B とそのトークナイザーとの正確なペアリングのためにトレーニングされている」。語彙は親モデルのもので、248,144トークンすべてを備えている。これは最適化ではなく要件だ。トークンがターゲットのトークンに1対1で対応しないドラフトは、ターゲットが受け入れ得るものを何も提案できない。同じ制約があるからこそ、兄弟ドラフトは、1つのドラフトがファミリー全体を担うのではなく、別個に存在するのだ。

このアーキテクチャは親モデルの縮小コピーではない。5層のアテンションスタックで、隠れ幅は2,048、クエリヘッド8に対してキー/バリューヘッド2、中間サイズは6,144、RoPEのシータは10,000,000である。そのアーキテクチャフィールドにはQwen3DSparkModelと表示される — 親の言語スタックが由来するQwen3ファミリーのバックボーンと同じで、スタブにまで削ぎ落とされている。

興味深いのは、スタブがターゲットとどのように対話するかだ。スタブはターゲットの最終層を読まない。スタブは5つの中間層——[3, 11, 19, 27, 35]（親モデルの40層のうち）——から隠れ状態を取り出し、dspark型のプロジェクタを通して射影する。スタックの末尾ではなく中間から取り出すのは意図的だ。ネットワーク中間の状態のほうがアラインメントのコストが低く、最終層がすでに次トークンのロジットへ圧縮してしまった情報を保持している。この設定はまた、ランク256のマルコフ成分を備えた信頼度ヘッドを組み込んでおり、これは提案されたブロックのうちどれだけ検証する価値があるかを判断するための、DSpark論文の機構だ。

受入表はカードであって、測定ではない

OpenBMB が、このペアがどれほどうまく機能するかについて公開した数値はすべて次のとおりです。検証ステップあたりの受理トークン数として表され、自然な EOS 終了かつmax_new_tokens=8192：

• Vision、MMMU — ステップあたり5.098個の承認済みトークン。

• ビジョン、MathVista — 6.126。

• ビジョン、CharXiv 推論（検証）— 5.479。

• Vision、OCRBench — 5.407

• テキスト、数学 — 6.687。

• テキスト、コード — 7.387。

• テキスト、一般 — 3.501.

あの表については、声に出して言っておく価値のあることが3つある。第一に、それは自己申告だ。OpenBMB以外でこのチェックポイントを実行して数値を公開した者はいないし、リポジトリに記録されたダウンロードが1件だけである以上、OpenBMB以外でこれを実行した人はそもそも皆無だ。第二に、アクセプタンス長はモデルの性質ではなくペアの性質だ——それはMiniCPM-V-4.7-35B-A3Bの出力がどれだけ予測可能かを測るもので、その出力がどれだけ優れているかを測るものではない。自分自身を繰り返すターゲットは、ドラフターに楽な勝ちを与える。第三に、ばらつきこそが物語だ。コードでの7.387に対して一般テキストでの3.501は、最良カテゴリと最悪カテゴリの間に2倍の差があることを意味し、コードが最も簡単であることは、モデルたちの何らかの強みというより、コードの低エントロピーで反復の多い表層を反映している。

カードが暗黙のうちに残している、単純な算術による読み方もある。15トークンを提案し、そのうち5～7トークンが受理されるドラフターは、ターゲットのフォワードパス1回あたり依然として複数のトークンを進めている。したがって、ここでの上限は大きなスループット向上である——ただし、それは素朴な「5倍高速」という主張ではない。なぜなら、15トークンのブロックを検証するコストは1トークンを生成するコストよりも高く、拒否された提案にはコストを払ったうえで捨てられるからである。このギャップこそがDSpark論文の主題であり、設定に適応的検証をオフにするスイッチが用意されている理由でもある。

ドラフトがベースモデルについて偶然明かすこと

MiniCPM-V 4.7は、そのリリースを「静かに出荷」と位置づけた — 重みのみで、ローンチ投稿はなし。それが今、小さくも確かな形で変わった。親リポジトリはopenbmb/MiniCPM-V-4.7-35B-A3B、2026年10月7日に作成された。10月12日までには、README付きの完全なモデルカード、Hugging Face風のリリースページ、主張一覧、オンデバイス向けセクション、重み表を備えていた。その後、このリポジトリには量子化ファミリーが加わった — FP8、int4、AWQ、GPTQ、GGUFビルドで、それぞれ別リポジトリにあり、すべて10月12日に手が加えられている — そして166ダウンロードに対して27いいね。

つまり正確な全体像は、静かなリリースではなく、2段階のリリースだ。ウェイトは10月6日と7日に公開された。ドラフト版チェックポイントは10月8日に続いた。ドキュメント、量子化版、オンデバイスに関する説明は10月12日までに出そろった。OpenBMBは依然としてこのファミリー向けのブログ記事も技術レポートも発表しておらず、親カードにはベンチマーク表もまだない——性能に関する主張は、読者が引用できるテキストではなく、リンクされたチャート画像の中にある。

本文に実際に現れる主張は、見出しのそれだ。Lookahead Expert Scheduling、レイヤー単位の量子化、そして「DSpark speculative sampling integration」により、35B-A3Bモデルは、iPhone 17 Pro Max上で毎秒13トークン以上で快適にオンデバイス動作する初のオープンソースMoEモデルと説明されている。その数値はベンダー報告であり、再現されておらず、条件も明示されていない——量子化形式も、ビルドも、プロンプトも、測定方法もない。DSparkチェックポイントは、その主張が依拠する3つの技術のうちの1つであり、それゆえ3つのうちダウンロードして中身を確認できる唯一のものである。また、その証拠がタスクごとに未読のベンチマーク行1行だけというのも、この技術である。

実行するよ、よければ

このカードにはレシピが1つ同梱されており、それはvLLMのコマンドであって、漠然とした説明ではありません。ターゲットをテンソル並列サイズ2、最大モデル長40,960で提供し、言語側とマルチモーダルエンコーダ側の両方のアテンションバックエンドでFLASH_ATTNを有効にし、ビジュアルダウンサンプルモードを4xに設定し、enable_thinkingをfalseに設定し、投機的構成をDSparkチェックポイントに向けて投機トークン数15、適応的検証はオフにしています。この行には単独でも注目に値する2つの細部があります。--max-num-seqs 1は、公開されたセットアップが一度に1つのシーケンスを処理することを意味し、--disable-custom-all-reduceとall-reduce融合パスの無効化は、これが最大限の速度ではなく動作するようにチューニングされた構成であることを意味します。このレシピは、OpenBMBが動作させた出発点として扱うべきであり、スループットの主張として受け取るべきではありません。

ハードウェアの許容範囲こそが本当の障壁だ。目標はKVキャッシュ前でおよそ70GBのBF16重みであり、ドラフトがさらに約0.78GBを上乗せする。2基のアクセラレータが明言されている最小構成で、これでは同ファミリーのマーケティングが頼りにしているスマートフォンを大きく超えてしまう——35B-A3Bモデルのオンデバイス配備は、積極的な量子化とオフロードを意味し、まさにそのためにLESとレイヤー単位の量子化の取り組みがあるのだが、それらのどちらも上記のvLLMレシピには含まれていない。

その非対称性は、ほとんどのチームにとって現実的な判断だ。MiniCPM-V 4.7 を提供するには、自社で所有する GPU が2基必要になる。同等のホスト型マルチモーダル MoE を呼び出すなら、初期費用はかからない。Qwen3.6 35B A3B が最も近い直接比較対象で、同じ 35B 総パラメータ・3B アクティブという構成、同じ 262K コンテキスト、画像と動画入力を持ち、OrcaRouter 経由で、プロバイダのルートに応じて入力100万トークンあたり $0.248 から、出力100万トークンあたり $1.485 で提供され、これらのルートのいずれかが劣化した場合の自動フェイルオーバーも備えている。MiniCPM-V 4.7 は OrcaRouter 上のホスト型モデルではなく、この記事はそうでないふりをするつもりはない。正直に言えば、この2つは意思決定の分岐点における選択肢であり、ホスト型のほうは今日の午後にでも測定できるものだ。

これをチェック可能にするには何が必要でしょうか

DSpark チェックポイントは Apache-2.0 で、1ギガバイト未満であり、GPU を2基持っている人なら今日ターミナルに貼り付けられるサービングコマンドが付属している。この組み合わせにより、MiniCPM-V 4.7 で独立した数値を得るための最も安価な経路になる。それはベンチマークスコアではなく、ほぼ同じくらい有用なもの、すなわち再現された受理長である。外部の第三者が MMMU で 5.1、一般テキストで 3.5 を一致させれば、そのカードは信頼でき、このファミリーの効率に関する話は最初の外部データ点を得る。受理長が実質的に低く出れば、公開された表はそのレシピでは再現できない条件で測定されたことになり、毎秒13トークンという主張もその疑念を引き継ぐ。

まだ欠けているのは、モデルカードが通常果たすべき役割そのものだ。MMMUスコアも、OCRBenchスコアも、文書理解の結果も、グラウンディングの数値も、MiniCPM-V 4.7自体のレイテンシ値もない——このモデルが優れているかどうかに答えるものは何もない。ドラフトモデルの表はその代わりにはならず、高い受理長を品質のシグナルとして読むことこそ、まさにこの数値が招く誤りだ。ChatGPT型の予測はドラフターにとって容易であり、その予測が正しかったかどうかについては何も語らない。

つまり、本物の成果物、本物のライセンス、これまで何もなかったモデルについて公表された、真に新しい証拠が一片——そして、10月7日とまったく同じ幅のまま残っている評価ギャップ。次に更新すべきファイルは、依然として親のモデルカードだ。