日常使いのiPhoneでMiniCPM-V 4.7 1Bを動かす——「Pro Maxを超えて動作する」とは実際に何を意味するのか

MiniCPM-V 4.7 1B は、OpenBMB が 2026年10月6日に Hugging Face へアップロードし、自身のリリースノートでは10月12日付とした、15.5億パラメータの視覚言語モデルである。モデルカード、11個の量子化された兄弟モデル、Ollama タグ、オンデバイスのデモアプリを備えている。備えていないのは、ハードウェアの価格を考えると筋が通る説明だ。開発者界隈に出回っている主張——このモデルが今や12GBのPro Maxだけでなく、一般のiPhone上のOnDeviceLLMアプリで動くという主張——こそ、詳しく検証する価値がある部分だ。なぜなら「スマホで動く」と「あなたのスマホで動く」の間には、ほとんどのiPhoneが持ち合わせていない約3GBのメモリ余裕があるからだ。 このようなリリースの背後にある、文書化されたAIの障害やエージェントのインシデントは、OrcaRouter AI Incident Archiveに集められており、各項目には独自の情報源、重大度、信頼度グレード、異議申し立てフラグが付いている。

ここに、継ぎ目が露わになった現状を示します。以下の内容はすべて、重みファイルから直接読み取ったもの、OpenBMB 自身のドキュメントによるもの、または Apple が公開した仕様によるものです。数値が再現可能な成果物ではなく開発者の投稿に由来する場合は、本記事でその旨を明記します。

実際に何が分かっていて、何が単に主張されているにすぎないのか

このモデルは実在し、ダウンロード可能です。BF16チェックポイントは1,554,476,272パラメータで、ディスク上ではおよそ3.1 GBになります。リポジトリには完全なモデルカードが付属しており——このファミリーの最近の歴史では珍しいことです——Qwen3.5テキストバックボーン、1152隠れ幅・27層のSigLIP2ビジョンタワー、980ピクセル入力タイル、262,144トークンのコンテキストウィンドウ、Apache 2.0ライセンスを明記しています。OpenBMB自身のREADMEエントリではリリース日を2026-10-12としています。Hugging Faceリポジトリが作成されたのは2026-10-06です。この6日間の差は、このファミリーで知られるアップロードと発表のタイムラグであり、10月の記事が6日前のリポジトリを依然として「静かなリリース」と呼べる理由でもあります。

何が証明されていないかといえば、どの成果物によっても裏付けられていない具体的な主張は、1B が OnDeviceLLM 上で「12GB Pro Max を超える日常的な iPhone」で動作するというものです。その枠づけの出所は開発者の投稿です。OnDeviceLLM プロジェクトの公開リポジトリ——オフラインのチャットおよび翻訳アプリ向けのスターターキットであり、App Store で提供中の製品ではありません——はスターがゼロで、最後にプッシュされたのは 2026 年 7 月 27 日です。これは MiniCPM-V 4.7 の重みより 10 週間前のもので、したがってリポジトリ内のこのモデルへの対応は最近のものであり、文書化されていません。「すでに OnDeviceLLM で動作している」は、実際にそれをやった人からの報告として扱い、ベンダーがサポートするデプロイ経路として扱わないでください。

その区別が重要なのは、ベンダー自身のオンデバイス数値が1Bに関するものではまったくないからだ。

3 GBという数字は1Bではなく35Bのものです。

OpenBMBの目玉の主張——「iPhone 17 Pro Maxでわずか3GBのメモリで13+トークン/秒」——は、35B-A3BのMixture-of-Expertsバリアントに結びついている。このバリアントは、Appleが販売する最大のiPhoneで動作する。その背後にある技術であるLookahead Expert Schedulingは、ほとんどのエキスパートの重みをSSDに保持し、次の層が必要になりそうなものをプリフェッチする。これは印象的なシステムエンジニアリングの成果であり、35Bという名前がスマートフォン関連の報道にたびたび登場する理由でもある。

1Bモデルはそうしたものを一切必要としない。メモリにそのまま収まる高密度モデルだ。理屈の上では、それがこの2つのうちより民主的なものにし、「日常使いのiPhone」という切り口に説得力を持たせている。しかし、計算はその枠組みが示唆するほど優しくはない：

• BF16 ウェイト — ディスク上で 3.1 GB、読み込み後の常駐量も KV キャッシュやビジョン活性化を除けばほぼ同じ • Q8_0 GGUF — ウェイト 1.08 GB、加えて 4× 圧縮設定で 0.90 GB のビジョンプロジェクター、16× では 1.11 GB • Q4_K_M GGUF — ウェイト 0.67 GB、プロジェクターのオーバーヘッドは同じ • ビジョンプロジェクター — ここが忘れられがちな部分です。言語モデルの量子化では縮小せず、読み込んだモデルごとに 1 回計上されます • コンテキスト — 公称最大 262,144 トークン。KV キャッシュの各トークンは、モデルカードが予算に入れていない追加メモリです

16×プロジェクターを備えたQ4ビルドでは、重みが約1.8 GBになります。ここに、数千トークン分の会話と画像プレースホルダーに対応する実用的なKVキャッシュを加えると、アプリには2.2～2.8 GB程度のメモリが必要になります。12GBのPro Maxなら余裕があります。しかし8GBのiPhoneでは、OSと常駐する他のすべてのアプリがすでに同じメモリプールを奪い合っているため、2.5 GBを要求するアプリは、残りの大部分を要求していることになります。iOSはそれを許可するか、メモリ負荷が高い状況でそのアプリをjetsamするかのどちらかです。

iPhoneのRAM欄こそが本当のスペックである理由

AppleはiPhoneのRAMをマーケティング仕様として公表しておらず、開発者にスマートフォンをメモリアドレス指定が可能なコンピューターとして扱うよう促したことも一度もない。これが「12GB Pro Maxを超える」という主張が突き当たる制約だ。Pro Max層は数世代にわたり標準モデルより多くのメモリを搭載しており、「レビュー動画の中のスマートフォン」と「読者のポケットの中のスマートフォン」の間のギャップこそ、このモデルのオンデバイスに関する話が依存するギャップそのものである。

この主張を正直に言えば、より狭くはなるが、それでも興味深い内容になる：かつてノートPCやハイエンドスマートフォンを必要とした10億パラメータの視覚モデルが、今ではミドルレンジのスマートフォンのメモリ予算に収まるのだ、もし4ビット量子化を使い、より短いコンテキストを受け入れるなら。これはハードウェアのクラスが確実に一段下がったことを意味する。「すべてのiPhoneで動く」ということではなく、その違いは率直に述べておく価値がある。なぜなら、それが読者にとってその製品を出荷できるかどうかを左右するからだ。

モデルカードだけでは決着しません。そこにはiOS、Android、HarmonyOSへの対応、Rockchip、Houmo、Intel、AMD、Armによる初日からのチップ対応が記載され、アプリとソースコードを備えたエッジ展開リポジトリへのリンクもあります。しかし、最小デバイスメモリ、テスト済みデバイスマトリクス、1Bのデバイスごとのトークンレートはどこにも記載されていません。1B自体のデモ素材で名前が挙がっている唯一のデバイスはiPhone 17 Pro Maxであり、これは35Bの見出しと同じデバイスです。

1Bでモデルが実際に得意なこと

このメモリ計算に価値がある理由は、スマートフォン上で文書や画面を理解する1Bモデルが、チャットボットとは別の製品カテゴリだからだ。つまり、レシート、フォーム、メニュー、ラベル、スクリーンショットを、ネットワーク往復なしで構造化テキストに変換できる——アップロード不要、画像ごとのコストなし、基地局によって決まるレイテンシの下限もない。

OpenBMBが公表した1Bの数値は、執筆時点ではすべてベンダー報告によるもので、独立に再現されたものは一つもないが、OCRBench 86.1、MathVista 74.3、CharXiv Reasoning 48.8、LongVideoBench 53.4、MotionBench 54.55としている。ベンダーが前面に出す比較は、総合スコアと推論効率の両方で上回るとするQ​wen3.5 0.8Bとの比較、および主要能力全般で改善したとするMiniCPM-V 4.6との比較である。これらはベンダー自身のベンチマークで、ベンダーが実行したものであり、モデルカードではハーネスの詳細を備えた表としてではなくグラフとして提示されている。

実際にこれをデプロイする人にとっては、スコアよりも2つのアーキテクチャ上の詳細のほうが重要です：

• 4×/16×の混在ビジュアルトークン圧縮 — 呼び出し元がリクエストごとに、画像を詳細なトークン列にするか低コストなものにするかを選択できるため、レシートスキャンとサムネイルが同じデプロイを共有できる • LLaVA-UHD v4から借用したViT内部での早期圧縮 — ビジュアルトークンはビジョンエンコーダの後ではなく内部で削減される。これがそもそも4×パスを低コストにしている理由である • スライシング — 高解像度画像を448×448のタイルと低解像度の全体像に分割し、スライス数を実行時パラメータとする（カードでは画像に36、動画に1を推奨） • 動画サンプリング — max_num_framesはデフォルトで128、stack_framesはサブフレームをグリッドに合成する。これにより、スマートフォンはすべてのフレームをメモリに保持することなく画面録画を処理できる

プロンプトで言及されているレシートのユースケースでは、パイプラインは次のとおりです。撮影し、長辺が約980ピクセルになるまでダウンスケールし、高いスライス数で4×で実行し、構造化出力を要求します。36スライスの4×パスは高コストな設定です。16×パスはトークン数がおよそ4分の1で、スマートフォンの応答性が保たれるのはこちらです。16×が感熱レシートを読むのに十分かどうかは、自分の画像でしか答えられない問いであり、カード内の公開ベンチマークはいずれもダウンサンプルモード別のOCR精度を報告していません。

「デモ」と「アプリ」の間のギャップ

動作するデモと出荷可能なiOSアプリの間には3つの障壁があり、そのどれもがモデルの重みではありません。

1つ目はパッケージングです。モデルはTransformers、GGUF、AWQ、GPTQ、int4形式で提供されています。iOS上で成熟したオンデバイスランナーがあるのはGGUFだけであり——llama.cppとその関連実装です——また、マルチモーダル経路が必要とする別個のビジョンプロジェクター（mmproj）ファイルを同梱しているリポジトリもGGUFだけです。BF16チェックポイントから始めて単一ファイルのドロップインを期待すると、プロジェクターがそれ自体のサイズを持つ2つ目のアーティファクトであることに気づくでしょう。

第二は熱予算です。10億パラメータのモデルが数百トークンを生成するのはバースト的なワークロードですが、同じモデルが36スライスのページをOCRするのは持続的なワークロードです。ベンダーのデモGIFは画面録画であり、熱のトレースではありません。スペックカードに公表されている数値の中に、どのスマートフォンにおいても持続的な1秒あたりのトークン数を示すものはありません。そしてその数値こそが、スキャンアプリが3冊目の書類でも30冊目でも即座に感じられるかどうかを決めるのです。

第三は、スタックの残りの部分です。オンデバイス推論は画像を処理しますが、抽出したレシートを台帳と突き合わせる部分や、曖昧な行をより大きなモデルへエスカレーションする部分、あるいはスマートフォンが古すぎてアプリが重みを読み込めない場合のフォールバックまでは処理しません。そこが、ルーターが何かを置き換えるのではなく、その存在価値を発揮する境界です。OrcaRouterは200以上ものホスト型モデルを、0%のマークアップで単一のOpenAI互換エンドポイントの背後にまとめ、各プロバイダーの定価をそのまま透過させ、自動フェイルオーバーと、プライマリ／フォールバック構成のためのルーティングDSLを備えています。スマートフォン側の抽出器は、不確実なケースをホスト型のビジョンモデルに渡すことができ、同じキーが両方の経路を担います。MiniCPM-V 4.7 1B自体はそのカタログには含まれていません——これは自分で実行するチェックポイントです——したがって、ルーターはエスカレーション経路であり、このモデルを呼び出すための手段ではありません。

「クワイエット・リリース」パターンと、それがなぜこの混乱を生み続けるのか

MiniCPM-V 4.7は発表イベントなしで登場した。35B-A3Bのリポジトリは2026年10月6日に現れたが、モデルカードは一切なかった——カードは6日後に、日付入りのリリースノートとともに公開された。1Bも同じパターンをたどった。まずリポジトリ、次にドキュメント、そしてその間ずっとコミュニティによる発見だった。その空白期間には、存在する成果物だけを頼りに報道が補完される。だからこそ初期の記事は35B MoEモデルについて書いていたが、1Bとそのカードが現れた時点で修正を余儀なくされた。

これはOpenBMBのエンジニアリングに対する批判ではありません。これは、このモデルに関する情報がどのように伝播するかを説明したものであり、「日常使いのiPhoneで動く」といった主張が、それを条件づけるメモリ数値よりも速く広まりうる理由でもあります。リポジトリが一次情報源です。モデルカードが一次情報源です。開発者が自分のスマートフォンでアプリが動作しているのを撮ったスクリーンショットは、仕様ではなく一つのデータポイントにすぎません。

これを具体的にどうするか

Pro Max または iPad をお持ちなら。 Q8_0 GGUF と 16× プロジェクターをダウンロードし、llama.cpp または Ollama で実行して、両方のダウンサンプル設定で自身のドキュメントをテストしてください。午後ひとつで実用的なローカル OCR と画像 QA の経路が手に入りますし、1B は他のアプリと並行して常駐させられるほど小さいです。

標準的なiPhoneをお持ちなら。まずはQ4_K_Mと16×プロジェクターから始め、スライス数は控えめな値に制限して、計測してください。メモリの計算上は収まるはずです。持続使用時の熱とjetsamの挙動こそ、誰も公表していない部分です。テストは最新の端末ではなく、サポート対象の中で最も古い端末で行ってください。

もし製品を作っているなら。オンデバイスモデルを高速経路、ホスト型モデルを正確性経路として扱うこと。エスカレーションはルーティングの判断であり、初日から組み込む方が、スマートフォンがレシートを誤読したという最初のサポートチケットの後から後付けするよりも安く済む。

この記事の発端となった主張、つまり10億パラメータのマルチモーダルモデルが今やPro Max未満の階層のスマートフォンで動くという主張は、メモリ計算の上ではもっともらしいが、公表された記録の上では未証明だ。これはこれほど新しいモデルにとっては普通の状態であり、待つのではなく試すべき理由でもある。重みはApache 2.0で、量子化版も存在し、あなたと答えの間に立ちはだかるのは、自分のハードウェアで午後を一つ費やすことだけだ。

要点:MiniCPM-V 4.7 1B は、実際に存在し文書化された Apache-2.0 のビジョンモデルで、ビジョンプロジェクター込みの Q4 でも約 1.8 GB に収まります。ミッドレンジのスマートフォンでも現実的なターゲットになり、12GB の Pro Max だけに限らないほど小さいということです。ただし、ベンダーはデバイスマトリクスや最小メモリの数値を公開しておらず、「日常使いの iPhone」という主張はモデルカードではなく開発者による報告に由来します。これを前提に計画を立てる前に、ご自身のデバイスでテストしてください。