MiniCPM-V 4.7：OpenBMBがモデルカードなし、ライセンスなし、ベンチマークなしで35B-A3B視覚言語モデルをアップロード

MiniCPM-V 4.7 は、2026年10月6日の夜、Hugging Face 上に、リポジトリopenbmb/MiniCPM-V-4.7-35B-A3B として登場した——そしてこれは、MiniCPM シリーズがこれまでに世に出した中で最も奇妙なものの一つだ。なぜなら、ほぼ何も一緒に提供されていないからである。モデルカードはない。README もない。宣言されたライセンスもない。ベンチマーク表も、発表投稿も、技術レポートも、OpenBMB 自身の GitHub ドキュメント内の記載もない。今週時点でも、そこでは依然として MiniCPM-V 4.6 が「MiniCPM-V シリーズで最新かつ最も効率的なモデル」とされている。存在するのは、bfloat16 重みの16個のシャード、合計70.4 GB であり、256K コンテキストウィンドウと、異例なほど積極的なハイブリッドアテンション設計を備えた352億パラメータの Mixture-of-Experts 視覚言語モデルを記述している。それだけで、そのモデルが何であるかまだ、それが何に優れているかを言うには十分ではない。そして、この記事ではその2つを厳密に分けて扱う。

実際に反映されたもの、バイト単位で

リポジトリは2026年10月6日18:36 UTCに作成され、最後のコミットは12分後の18:48 UTCにありました。その間に、アップロードした人は重みファイルと、Transformersローダーに必要な設定をプッシュし、そこで止まりました。完全なファイル一覧は18項目です：

• 重み — 16 個の safetensors シャードがあり、名前は model-00001-of-00016 から model-00016-of-00016 です。インデックスファイル model.safetensors.index.json はテンソルの合計サイズが 70,425,751,648 バイトであると報告しています。

• パラメータ数 — Hugging Face APIは35,212,875,824個のパラメータを読み取っており、すべてBF16です。これは合計数であり、スパースMoEの場合、任意のトークンで有効なパラメータ数ではないことに注意してください。

• 設定 — config.json（2,984バイト）、generation_config.json（186バイト）、preprocessor_config.json、processor_config.json。

• トークナイザー — tokenizer.json（20 MB）、tokenizer_config.json、および chat_template.jinja（7,250 バイト）。

• 欠落 — README.md。rawファイルを直接取得するとHTTP 404が返されます。Hugging Faceでは、READMEが存在しないということはモデルカードがないということであり、それはライセンスフィールドがないということであり、つまりそのリポジトリにはlicense:タグが一切付与されていないということです。

このリポジトリには「いいね」が3件、ダウンロードは0件、ディスカッションタブは空のままだ。70 GBのチェックポイントがコミュニティによってアップロードされると、通常は数時間以内にコメントが寄せられる——量子化について、サービングについて、ライセンスは何かといった質問だ。今回はそうなっていない。これは、誰かに告知されたのではなく、openbmb組織をウォッチしている少数の人々の目に留まっただけであることと整合する。

アーキテクチャは、config.jsonからそのまま読み取ったものです

言い換えるべきカードが存在しないため、設定ファイルが主要な情報源であり、異例なほど情報量が多い。クラスはMiniCPMV4_7ForConditionalGeneration、モデルタイプはminicpmv4_7、Transformers 5.2.0で保存されている——これらすべては、これが主流のMiniCPM-V系統におけるOpenBMBのファーストパーティのチェックポイントであり、名前を借りたコミュニティのファインチューンではないことを示している。

• 言語バックボーン — model_type: qwen3_5_moe_text。Qwen3.5 由来のスパース MoE で、MiniCPM-V シリーズが、MiniCPM-V 4.5 と 4.6 を支えた密な小型 Qwen バリアントではなく Qwen-MoE テキストスタックを採用するのは初めてです。

• スパース性 — 256 エキスパート、トークンごとに 8 個を選択、エキスパートの中間サイズは 512、同じサイズの共有エキスパートを備える。8-of-256 のルーティングパターンにおける合計 35B のチェックポイントは、フォワードパスごとにそのごく一部のみをアクティブ化する。まさにこれが A3B という名前の狙いだ。重みは大きいが、計算量は大きくない。

• 深さと幅 — 隠れ層40層、隠れサイズ2048、アテンションヘッド16個（キー/バリューヘッド2個、ヘッド次元256）。

• ハイブリッドアテンション — layer_types 配列は長さ 40 エントリで、linear_attention 層を full_attention 層 1 つにつき 3 つ、固定間隔 4 で実行します。40 層のうち 10 層は従来型のアテンションを行い、残りの 30 層はカーネルサイズ 4 の畳み込みを伴う Mamba スタイルの線形パスを使用します。これはこのファイルで最も影響の大きい単一の設計上の選択であり、2026 年にかけてより広い分野が進んだ方向と同じです。

• 位置エンコーディング — theta が 10,000,000 の RoPE と、partial_rotary_factor: 0.25、つまり各ヘッドの次元の 4 分の 1 のみが回転されることを意味します。マルチモーダル RoPE は次の設定で有効になっています: mrope_interleaved: true、セクション分割は [11, 11, 10]、およびmrope_mode: canvas。

• コンテキスト — max_position_embeddings: 262144、およびトークナイザーのmodel_max_lengthも一致しています。256Kトークン。

• マルチトークン予測 — mtp_num_hidden_layers: 1、単一の投機的デコーディングヘッドで、MiniCPM-V 4.6 が採用していたのと同じ手法です。

• ビジョンタワー — minicpmv4_7_vision、隠れサイズ 1152、27 層、GELU-tanh 活性化、パッチサイズ 14、image_size は 980、そして insert_layer_id は 6。ここで視覚埋め込みが言語スタックに接合される。タワーの形状は MiniCPM-V 4.6 のものに近く、そのため視覚側は再構築ではなく進化である。

• ビジョン圧縮 — downsample_mode: "16x" および max_slice_nums: 9（画像プロセッサ内）。MiniCPM-V 4.6 では切り替え可能な 4x/16x トークン圧縮スキームが導入されました。4.7 の設定では 16x 設定がデフォルトとして示されており、スライサーは高解像度入力に対して最大 9 枚のサブ画像を許可します。

• 語彙 — 248,144トークン。<|image_pad|>はID 248,056、<|video_pad|>はID 248,057に配置されています。動画はMiniCPM-V 4.5以来と同様、ファーストクラスの入力です。

• 興味深い名残 — トークナイザー設定は依然として <|audio_start|>、<|audio_end|>、<|audio_pad|>を宣言している。これはほぼ間違いなく、MiniCPM-V 4.7 が音声を扱えるというより、語彙が omni MiniCPM-o ブランチと共有されていることを意味する。これを音声機能と解釈するのは、設定だけでは否定できない誤りだろう。

家族が教えてくれること、このリポジトリが教えてくれないこと

4.6世代が基準点であり、その対比こそが物語だ。MiniCPM-V 4.6は2026年5月11日に、SigLIP2-400MビジョンエンコーダーとQwen3.5-0.8B言語モデルを基盤とする13億パラメータモデルとして、Apache-2.0のもとでリリースされ、明確な売り文句を掲げていた。Artificial Analysis Intelligence Indexで13を記録し——これはベンダー報告の数値だが——同等の小型モデルより劇的に少ないトークン数で動作し、iOS、Android、HarmonyOSで動作し、エッジ適応コードはオープンソース化されている。そのアイデンティティ全体は「小型、効率的、オンデバイス」だった。

MiniCPM-V 4.7は、1.3Bの約27倍だ。35B-A3Bという名前は、それを携帯電話ではなく、スパースなフラッグシップが占めるクラスに位置づける。OpenBMBがこれをエッジ向けラインのサーバーサイド・コンパニオンとして意図しているのか、将来の小型モデルの教師としてなのか、それとも能力の上限テストとしてなのかは、どこにも述べられておらず、リポジトリにもどちらかを示すヒントはない。

本当に新しく、このシリーズを追っている人なら誰にでも注目を促す価値があるのは、Qwen-MoEバックボーンと、線形アテンション対フルアテンションの3:1比率です。どちらも従来からの脱却です。OpenBMBがこのファミリーについて公開しているものはすべて、依然として4.6を中心に書かれているため、このチェックポイントは自身のドキュメントより先を行っています。

まだ知り得ないこと — そして、なぜそのリストが重要なのか

ここにある穴の大きさについては、率直に言っておく価値がある。70 GBのチェックポイントを前にすると、もっともらしい推論でそれを埋めてしまいたくなるからだ。

• ライセンスなし。これは形式上の問題ではない。MiniCPM-V 4.6 は Apache-2.0 であり、コミュニティはこのシリーズにそれを当然のこととして期待するようになっている。license:タグのないリポジトリは、ほとんどの法域においてデフォルトで全権利留保とみなされる——タグが現れるまで、それを安全に基盤として利用することはできない。そのたった一つの欠けたファイルが、このリポジトリにおける最も重大な不在である。

• ベンチマークはありません。ベンダー報告であれ、そうでなくとも。議論の余地のある数字は一つもありません。今日、MiniCPM-V 4.7 の MMMU や OCRBench のスコアを引用している人は、ソースに存在しないものを引用しています。

• 独立した評価は行われません。Artificial Analysis や同様のトラッカーはモデルを名前でインデックス化しており、カードも発表もないチェックポイントは通常、しばらくの間未評価のままになります。

• サービングレシピなし。公開された重みが vLLM、SGLang、llama.cpp でそのまま動くかどうかは、OpenBMB 以外の誰も検証していない。カスタムコードパス（MiniCPMV4_7ForConditionalGeneration、MiniCPMV4_7Processor、MiniCPMV4_7ImageProcessor、MiniCPMV4_7VideoProcessor）はいずれも trust_remote_codeが必要で、MoE と線形アテンションの組み合わせは、どの推論エンジンにもカーネルがあるような形状ではない。

• 量子化なし。MiniCPM-V 4.6はGGUF、AWQ、GPTQ、BNBの各バリアントを提供し、2026年6月にOllamaのライブラリに登場しました。4.7にはいずれも存在しません。35Bモデルにとって、これはノートPCとクラスタの違いです。

• 4.6との関係性は述べられていない。OpenBMBはエッジラインを置き換えている、拡張している、あるいは直交する何かをテストしている可能性がある。リポジトリには記載がなく、GitHub READMEにも記載がない。GitHub READMEは、2026年9月8日のコミット時点でも4.6を最新リリースとして依然として記載している。

タイムラインには、もっともらしいが未確認の解釈も存在する。リポジトリの作成から最終コミットまでの12分の空白、カードの不在、そして投稿が一切ないことは、ローンチ後にではなくローンチに向けて仕込まれたときのチェックポイントが示す姿だ、という解釈である。これは意図に関する仮説であり、成果物に関する事実ではない。そのように扱うべきである。

実行するものがあるときに、実際にそれをどう実行するか

ここにはまだ、サポートされる経路として引用できるものは何もないが、設定が選択肢を制約しているのは確かだ。35BパラメータのBF16チェックポイントは、KVキャッシュを別にしても約70GBのアクセラレータメモリを必要とするため、量子化が登場するまで単一GPUでのホビイスト向けデプロイは選択肢に入らない。256Kコンテキストと3:1の線形アテンション比は、KVキャッシュが同じ深さの従来型トランスフォーマーよりもはるかにゆっくり増大することを意味しており、まさにそれゆえ、このアーキテクチャは複雑さに見合う価値がある。長コンテキストのマルチモーダル作業こそ、この設計がコストを回収できる領域だ。カードが登場したら、最初に確認すべきはライセンス、公式のvLLMまたはSGLangレシピが公開されているかどうか、そして16xダウンサンプルのデフォルトを、4.6が明らかにした4x設定に切り替えられるかどうかだ。

このようなモデルが使えるようになった瞬間に評価したいチームにとって、実務上の課題は重みではなく、その周辺の配管部分にあります。自前のGPU上で動くモデルであっても、その周りにはあらゆるものが必要です — 200を超えるホスト型モデルを1つのキーの背後にまとめ、各プロバイダーの定価（当社が上乗せするマークアップなし）で利用でき、プロバイダーが劣化した際には自動でフェイルオーバーするルーターです。それが OrcaRouter の役割です。そしてはっきり言っておくべきですが、MiniCPM-V 4.7 自体はホスト型モデルではありません。自分でホストするオープンウェイトのチェックポイントです。ここでルーターが重要になるのは、アーキテクチャのもう半分としてだからです — つまり、あなたの 4.7 のマシンが難易度の高いケースを引き渡す先のフロンティアモデルであり、すでに書いたのと同じクライアントから到達できます。

現状と、更新すべき1つのファイル

MiniCPM-V 4.7は存在する。その重みは今日ダウンロード可能で、重みの数は正確であり、学習当時の設計上の選択——スパースMoE、3:1の線形アテンション、256Kコンテキスト、16倍の視覚圧縮——はすべて設定ファイルから読み取れる。存在しないのは、このモデルが何をするのか、実際に動かすのにどれほどのコストがかかるのか、何をしてよいのかについてのOpenBMBからの説明だ。最後のビジョンモデルが完全な比較表を備えた1.3BのApache-2.0エッジリリースだったラボにとって、これは違和感のあるギャップであり、妥当な姿勢は言説ではなくリポジトリを注視することだ。更新し続けるべき唯一のファイルはREADME.mdだ。それが現れた瞬間、ライセンス、ベンチマーク、そしておそらく、小型モデルを基盤に築かれたシリーズにおいて35BのMiniCPM-Vが何をしているのかという説明を載せるだろう。

それまでは、正直な要約ほど退屈なものはない。これは実際のラボから出た本物のチェックポイントで、ひっそりとアップロードされた。そして興味深い問い——それは良いものなのか——に対する公表された答えは、まだない。

OrcaRouterは、1つのキーで200以上のホステッドモデルに到達でき、各プロバイダーの定価を0%のマークアップでそのまま適用し、プロバイダー間で自動フェイルオーバーします。 プロバイダーの定価を0%のマークアップでそのまま適用 MiniCPM-V 4.7 はその一つではありません。これは自分で提供するオープンウェイトのチェックポイントであり、ルーターは受け渡しの向こう側に位置するものです。