MiniCPM-V 4.7 1B 在普通 iPhone 上：所谓“超越 Pro Max”究竟意味着什么

MiniCPM-V 4.7 1B 是一个 15.5 亿参数的视觉语言模型，OpenBMB 于 2026 年 10 月 6 日将其上传到 Hugging Face，并在其自己的发布说明中标注日期为 10 月 12 日。它有一个模型卡、十一个量化衍生版本、一个 Ollama 标签，以及一个端侧演示应用。它没有的，是在把硬件成本算进去后仍然站得住脚的那版说法。开发者圈子里流传的说法——该模型现在能在普通 iPhone 上的 OnDeviceLLM 应用中运行，而不只是在 12GB 的 Pro Max 上——正是值得仔细审视的部分，因为“能在手机上运行”和“能在你的手机上运行”之间，隔着大约 3 GB 的内存余量，而大多数 iPhone 并没有这么多余量。像这次发布背后的那些有记录的 AI 故障和智能体事件，都收录在 OrcaRouter AI Incident Archive 中，其中每条记录都带有各自的来源、严重程度、置信等级和争议标记。

以下是当前情况，接缝清晰可见。下文内容要么直接读取自权重文件，要么来自 OpenBMB 的官方文档，要么来自 Apple 公布的规范。若某个数字来自开发者的帖子而非可复现的制品，本文会予以说明。

哪些是实际已知的，哪些只是声称的

该模型真实存在且可下载。BF16 检查点包含 1,554,476,272 个参数，在磁盘上约占 3.1 GB。该仓库附有完整的模型卡——这在该系列近期历史中实属罕见——其中标明 Q​wen3.5 文本主干、一个具有 27 层、隐藏宽度为 1152 的 SigLIP2 视觉塔、980 像素输入图块、262,144 token 的上下文窗口，以及 Apache 2.0 许可。OpenBMB 自己的 README 条目将发布日期定为 2026-10-12；Hugging Face 仓库创建于 2026-10-06。这六天的间隔正是该系列为人熟知的“上传与公告之间的滞后”，也正是为何一篇十月的文章仍能把一个已创建六天的仓库称为悄然上线。

什么未由任何产物确立，正是这样一项具体主张：1B 模型能在 OnDeviceLLM 中、于“12GB Pro Max 之外的日常 iPhone”上运行。这一说法源自一篇开发者帖子。OnDeviceLLM 项目的公开仓库——它是离线聊天和翻译应用的入门套件，而非已上架的 App Store 产品——星标数为零，最后一次推送是在 2026 年 7 月 27 日。它比 MiniCPM-V 4.7 的权重早十周，因此其中对该模型的任何支持都是近期添加且无文档说明的。请把“已在 OnDeviceLLM 中运行”视为某人亲自完成后的报告，而不是厂商支持的部署路径。

这种区分很重要，因为厂商自己给出的端侧数据根本不是针对 1B 的。

3 GB 这个数字属于 35B，而不是 1B

OpenBMB 的核心宣称——“在 iPhone 17 Pro Max 上仅用 3 GB 内存即可达到 13+ tokens/s”——对应的是35B-A3B 混合专家（Mixture-of-Experts）变体，运行在 Apple 所售最大尺寸的 iPhone 上。其背后的技术 Lookahead Expert Scheduling 将大多数专家权重保留在 SSD 上，并预取下一层可能需要的权重。这是一项令人印象深刻的系统工程成果，也正是 35B 这个名字不断出现在手机相关报道中的原因。

1B 并不需要其中任何一项。它是一个能直接装进内存的稠密模型。理论上，这使它成为两者中更“民主”的那个，也正是“日常 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，投影器开销相同 • 视觉投影器——这是人们容易忘记的部分；它不会随语言模型量化而缩小，并且每加载一个模型计一次 • 上下文——纸面上最高 262,144 个 token；KV 缓存的每个 token 都是模型卡未预留预算的额外内存

采用 16× 投影器的 Q4 构建版本，权重接近 1.8 GB。再为几千个 token 的对话和图像占位符加入可用的 KV 缓存，你就是在向应用索取 2.2–2.8 GB 的内存。在 12GB 的 Pro Max 上，这很宽裕。在 8GB 的 iPhone 上，操作系统和其他所有常驻应用已经在争抢同一个内存池，一个索取 2.5 GB 的应用，等于要占走剩余内存的很大一部分。iOS 要么批准，要么在内存压力下用 jetsam 终止该应用。

为什么 iPhone 上的 RAM 那一行才是真正的规格

苹果不在其营销规格中公布 iPhone 的 RAM，也从未鼓励开发者把这款手机当作一台可按内存寻址的计算机来对待。这正是“超越 12GB Pro Max”这一说法所遭遇的约束。Pro Max 这一层级已经连续几代比标准机型配备更多内存，而“评测视频里的手机”与“读者口袋里的手机”之间的差距，恰恰就是该机型的端侧叙事所依赖的差距。

更诚实地讲，这个说法范围更窄，但仍然有趣：一个曾经需要笔记本电脑或旗舰手机的 1B 视觉模型，现在能装进中端手机的内存预算之内，如果你使用 4 位量化并接受更短的上下文。这确实是硬件档次上的一次真正下探。它并不等同于“能在每台 iPhone 上运行”，而这个差别值得直说，因为它决定读者能否把东西发布出去。

模型卡并未给出定论。它记录了对 iOS、Android 和 HarmonyOS 的支持，对 Rockchip、Houmo、Intel、AMD 和 Arm 芯片的首日支持，并链接到一个包含应用和源代码的边缘部署代码仓库。但它在任何地方都没有列出最低设备内存、经过测试的设备矩阵，或 1B 模型在各设备上的 token 速率。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，称其在核心能力上全面优于后者。这些都是厂商自己的基准测试，由厂商自行运行，而模型卡将其以图表形式呈现，而非附有测试框架细节的表格。

对于真正要部署它的人来说，有两个架构细节比得分更重要：

• 混合 4×/16× 视觉 token 压缩——调用方按请求选择图像变成详细 token 序列还是廉价 token 序列，因此收据扫描件和缩略图可以共用同一套部署 • ViT 内部早期压缩，借鉴自 LLaVA-UHD v4——视觉 token 在视觉编码器内部就被裁剪，而不是在编码器之后，这正是 4× 路径首先能负担得起的原因 • 切片——高分辨率图像被切成 448×448 的图块，外加一张低分辨率概览图，切片数量作为运行时参数（该卡片建议图像用 36，视频用 1） • 视频采样——max_num_frames 默认为 128，stack_frames 将子帧合成为网格，这就是手机在处理屏幕录制时无需把每一帧都留在内存中的方式

对于提示词提到的小票使用场景，流程是：拍摄，将长边缩小到接近 980 像素，以 4× 和较高的切片数运行，并要求结构化输出。36 个切片的 4× 路径是开销较高的设置；16× 路径的 token 数大约只有四分之一，也是手机保持流畅的所在。16× 是否足以读取热敏小票，只有你自己的图像能回答，而且卡片中没有任何已发布基准按降采样模式报告 OCR 准确率。

“demo”与“app”之间的差距

从一个能跑通的演示，到一款可以上架的 iOS 应用，中间隔着三件事，而这三件事都不是模型的权重。

第一个是打包分发。该模型以 Transformers、GGUF、AWQ、GPTQ 和 int4 格式发布。只有 GGUF 在 iOS 上拥有成熟的端侧运行器——llama.cpp 及其同类——而且只有 GGUF 仓库附带多模态路径所需的独立视觉投影器（mmproj）文件。如果你从 BF16 检查点出发，指望得到一个可直接替换的单文件，就会发现投影器是另一个独立的产物，有着自己的体积。

第二点是热预算。一个 1B 模型生成几百个 token 属于突发型负载；而一个 1B 模型对 36 层切片页面做 OCR 则属于持续型负载。厂商的演示 GIF 是屏幕录制，不是热轨迹。规格卡中没有任何已公布的数据给出在任何手机上的持续每秒 token 数，而这个数字才决定扫描应用在处理第 3 份还是第 30 份文档时是否感觉即时。

第三部分是你技术栈的其余部分。设备端推理负责处理图像。它不处理以下环节：将提取出的收据与账本进行核对，把有歧义的条目升级给更大的模型，或者在手机过于老旧、应用拒绝加载权重时进行回退。这正是路由器能够占有一席之地而非取代任何东西的边界：OrcaRouter 将200 多个托管模型置于一个兼容 OpenAI 的端点之后，以 0% 的加价，将各提供商的标价原样透传，并提供自动故障转移和用于主备配置的路由 DSL。手机端提取器可以将其不确定的案例交给托管视觉模型，而同一个密钥可承载这两条路径。MiniCPM-V 4.7 1B 本身不在该目录中——它是你自行运行的检查点——因此路由器是升级路径，而不是调用该模型的方式。

静默发布模式，以及它为何不断造成这种困惑

MiniCPM-V 4.7 没有举办发布会就悄然上线。35B-A3B 仓库于 2026 年 10 月 6 日出现，当时完全没有模型卡——六天后，模型卡才与标注日期的发布说明一同发布。1B 也遵循了同样的模式：仓库先行，文档随后，整个过程由社区逐步发现。在这段空档期，相关报道只能依据现有材料进行补充，这也是为什么早期文章描述的是一个 35B MoE 模型，随后又不得不在 1B 及其模型卡出现后进行修正。

这不是对 OpenBMB 工程工作的批评。它描述的是关于该模型的信息如何传播，也正是为什么诸如“可在日常 iPhone 上运行”这样的说法，会比限定这一说法的内存数据传播得更快。代码仓库是一手来源。模型卡是一手来源。开发者在自己手机上运行某个应用的截图只是一个数据点，而不是规格说明。

具体来说，这个该怎么处理？

如果你有 Pro Max 或一台 iPad。下载 Q8_0 GGUF 和 16× 投影器，通过 llama.cpp 或 Ollama 运行，并在两种下采样设置下测试你自己的文档。一个下午之内，你就能得到一条可用的本地 OCR 与图像问答路径，而且 1B 足够小，可以与其他应用一同常驻内存。

如果你使用的是标准版 iPhone。从 Q4_K_M 和 16× projector 开始，将切片数量限制在适中的水平，然后进行实测。内存算术表明它应该能装得下；持续使用下的热行为和 jetsam 行为是尚无人发表过的部分。要在你打算支持的最旧设备上测试，而不是最新设备。

如果你正在开发一款产品。把端侧模型视为快速路径，把托管模型视为正确性路径。升级处理是一项路由决策，从第一天就把它构建进去，比在收到第一张关于手机误读收据的支持工单之后再去补建更划算。

让这篇文章开篇的那个说法——一个 1B 多模态模型如今能在低于 Pro Max 级别的手机上运行——从内存用量推算来看是合理的，但在公开记录上尚未得到证实。对于这么年轻的模型来说，这是正常状态，也正是应当去测试而不是等待的理由。权重采用 Apache 2.0，量化版本已经存在，而你与答案之间唯一的障碍，就是花一个下午用自己的硬件试一试。

结论：MiniCPM-V 4.7 1B 是一个真实存在、有文档记录、采用 Apache-2.0 许可的视觉模型，在 Q4 量化下连同其视觉投影器仅占约 1.8 GB——小到足以让中端手机成为可信的目标设备，而不只是 12GB 的 Pro Max。厂商并未公布设备适配矩阵或最低内存要求，而“日常 iPhone”这一说法源自一位开发者的报告，而非模型卡。在据此做规划之前，请先在您自己的设备上测试。