35B模型跑上手机：MiniCPM-V的“3GB内存”意味着什么？

官方模型卡说，35B模型在手机上运行时约占3GB内存；端侧部署文档却建议预留约17GB储存。两个数字并不矛盾：前者说运行占用，后者说文件放在哪里。它们描述相关但不保证完全相同的配置，不能混成一个“模型只有3GB”的结论。35B模型卡、Apps部署说明

OpenBMB于10月12日发布MiniCPM-V 4.7，提供35B-A3B与1B两个规格，15日补充DSpark推测解码组件。官方报告的手机成绩，是35B-A3B在iPhone 17 Pro Max上以约3GB内存实现13+ tok/s解码。官方发布记录

对想在本地看图、读截图的人，更大的视觉模型有了手机入口。不过，文件装得下、模型跑得动，与一份文档能否顺利处理完，仍是几件不同的事。

眼下用到的专家进内存，其余权重留在储存里

35B-A3B是混合专家模型：总参数约35B，每个token只激活约3B。不同输入可能选中不同专家，因此，暂时不参与计算的权重仍需保留，不能只下载激活部分。官方模型说明

手机端的做法，是把专家按需从内部储存读入。难点也由此出现：如果每一步都停下来等读取，模型虽然装得下，回答仍可能慢得难用。

这次的LES，即前瞻专家调度，尝试提前预测下一层要用的专家，在当前计算时预先加载，尽量重叠读取和计算。预测没覆盖的必要专家仍按原始路由加载。这个调度原则解释了作者所说的保留原有路由，不代表同一路线里的量化也对所有任务绝对无损。LES与配套优化

层级量化与DSpark也参与优化，手机储存速度因而成为体验的一部分。所谓“3GB运行”，背后是一套文件格式、缓存和调度的协作，而不是把一份35B模型简单压成3GB。

图：官方五项基准的平均成绩与推理时间，上下分别为35B与1B；横轴为对数刻度，星形和圆形是Instruct模式，菱形是Thinking模式。图中结果不是手机文档处理总耗时。图表来源

这张图表达的是作者对能力与计算时间的取舍，两个规格要分开看。它与“iPhone上13+ tok/s”的解码报告，也不是同一个计量项目。

截图可以交给模型，PDF还要接一段处理流程

MiniCPM-V 4.7支持单图、多图和视频理解，并允许调整视觉压缩，在细节与计算开销之间取舍。官方能力说明

产品、设计和运营用户可以先从小任务试起：整理一张界面截图的可见文字，比较几张素材的差异，或把一页文档提取成便于编辑的文本。中文密集小字和表格仍应对着原图复核，不能只看回答是否通顺。

PDF尤其容易被想得太简单。官方模型卡链接的示例，先用工具把PDF逐页渲染成图片，再让模型按原排版提取Markdown。模型接收的是页面图像，文件转换发生在外围程序中。PDF Parse使用示例

所以，这份代码给出了文档处理路径，却不能证明手机App已经具备完整的PDF导入、批量识别和导出界面。若目标是生成Excel，后面还要有字段校验和表格写入；若目标是检查原型，识别页面内容也不等于能直接操作软件。

模型读懂一页材料之后，往往还要整理文件、处理格式、人工确认。这些步骤都要算进完成一份工作的时间，不能只看它有没有答出一句正确描述。

先核对手机与文件版本，再看13+ tok/s

Apps部署说明给出了比宣传数字更具体的条件：

以上来自官方Apps说明。物理内存12GB不表示模型必须占满12GB；约3GB的简述也不足以承诺任意输入与上下文下的峰值。资源更少的设备可能需要缩小专家缓存，速度会受到影响。

13+ tok/s则是解码速度，不是中文每秒字数，也没有包含首次加载、图片编码和全部处理时间。长文档、多图或视频改变了输入规模，不能仅凭这个数推算一份工作几分钟交付。

目前，iOS有TestFlight入口，Android和HarmonyOS有对应安装包；下载页仍将这些Demo定位为研究、预览用途，而非完整优化的成品应用。资源有限时可以关注1B规格，但要分别看它的质量与性能，不能直接继承35B的成绩。官方下载说明

开发者隐私政策声明推理在设备上完成，下载模型仍要访问公开仓库。处理敏感截图前，也要确认相册权限，以及原图和识别结果如何在本地留存。开发者隐私政策，标注2026年4月更新

已有合适手机、希望减少图片上传的人，可以从小型视觉任务试起。只偶尔读图，或者希望文件导入、识别、导出一步到位，现有工具可能更省事，不必只为这组数字更换硬件。

这套方案把部分权重留在储存里，通过调度，让手机能使用更大规模的视觉模型。约3GB是特定条件下的运行占用；安装文件仍要占据更多储存，图片和文档的处理时间也要另算。