手机跑大模型这件事，过去两年的说法一直很含糊：能跑，但跑的大多是十亿参数以内的小模型，或者把参数砍到没法用的程度。10 月 12 日，面壁智能联合 OpenBMB 放出 MiniCPM-V 4.7，给了一个更大的数字——总参数约 350 亿的 35B-A3B 版本，在 iPhone 17 Pro Max 上每秒解码 13 个 token 以上，官方口径是「约 3GB 运行内存」。
数字很漂亮，但里面藏着三个容易被混在一起的概念。这篇不急着下结论，先把账拆开。
这次真正的新东西，不在模型里
MiniCPM-V 4.7 有两个版本：35B-A3B 和 1B，两个都是 Apache 2.0 协议，发布当天权重、量化文件、推理代码和评测图一起上齐，这在端侧模型里算少见的完整交付。
但模型本身没什么悬念。语言底座来自 Qwen3.5 和 Qwen3.6，视觉编码器是 SigLIP2，配置表写得很清楚：40 层、256 个专家、每个 token 只挑 8 个，上下文窗口 262144。这是一次基于开源组件的重训与整合，不是从零设计。
真正新的是「怎么让它在手机上跑起来」这部分工程。
MoE 的老问题：参数不用，权重还得存着
MoE 的好处是每次推理只激活一部分专家——35B-A3B 每次大约只走三十亿参数的计算量。但这里有个反直觉的地方：算得少不等于存得少。模型永远得把 256 个专家的权重都放在手边，因为下一步该叫谁，是路由器当场决定的，事前并不知道。
服务器上这不是问题，显存和内存够宽，读取延迟可以用硬件堆过去。手机不一样，运行内存就那几个 G，专家权重只能沉在闪存里，用一次搬一次。搬的时候算不了，算的时候搬不了，卡顿就出在这里。这也是国内开源 MoE 这几轮迭代绕不开的一道坎，从 Beam 把激活参数压到两百三十亿 到这次的端侧调度，解决的其实是同一类问题。
面壁这次的解法叫 LES（前瞻专家调度，Lookahead Expert Scheduling）：提前预测下一层可能要用到的专家，在当前这轮计算还没结束的时候就把权重往内存里搬，让加载和计算并行起来。
官方技术资料里有一句话很关键——预测只用来决定预取哪些权重，最终用谁还是路由器说了算，预测落空就照常等加载。这就是「无损」三个字的技术根据：它改的是排队顺序，不是数学计算，所以输出理论上不变。
「约 3GB 内存」指的是哪三个数字中的哪一个
这是整篇最容易看错的地方。官方口径的「约 3GB」，指的是特定部署方案下的运行内存占用，不是模型体积，也不是下载体积。
把三个数字分开看就清楚了：
- BF16 完整权重约 70.4GB，这是「350 亿参数」的真实体量。
- 最小的 GGUF 量化文件约 15.5GB，这是你真正要下载、要占存储的那一份。
- 约 3GB，是跑起来以后常驻在内存里的那一小块工作集。
三个数字差了二十多倍，背后是同一件事：权重的大部分留在闪存，需要谁就把谁搬进来。面壁自己的材料也解释了为什么必须这么做——如果硬要把全部专家权重常驻内存，那「每次只用三十亿参数」的计算优势，会立刻被完整模型的体积吃掉。
还有一处细节值得留意：官方说的「每次激活约三十亿参数」，是从模型名里的 A3B 后缀推出来的，而模型卡、README 和发布贴里都没有把这个后缀换算成一个具体数值。有人按权重实际量过，结果在 24.4 亿到 40.1 亿之间浮动，差别在于要不要把嵌入表和输出头算进去——在一个每 token 只走几十亿参数的稀疏模型里，这两项加起来能占到五分之一，已经不是可以忽略的误差。
一句话：A3B 是个标签，不是一份可以拿来算内存的说明书。
四步阶梯，把每秒 2.97 个 token 提到 17.39
官方在 11 英寸 iPad Pro（M4，16GB 内存）上给了一条清晰的阶梯，这也是判断「加速约五倍」成色最好的入口：
- 未优化的存储加载基线：每秒 2.97 个 token
- 加上调度与加载优化：9.81
- 再加上逐层混合精度量化：14.92
- 最后加上 DSpark 投机采样：17.39
整体约 5.86 倍，其中光是调度这一层大约贡献 3.3 倍。把整个提升都算成「调度的功劳」并不准确——量化和投机采样各自都占了一块。
这里要提醒一句：这组数字是 16GB 的 iPad Pro 上的开发者测量值，不是 iPhone 的。官方 iPhone 战报是每秒 13 个 token 以上，设备、存储、内存余量和推理配置都不同，两组数字不能互相替换。
而所有关于端侧速度的说法，目前都是厂商自测，看不到第三方在固定测试环境下的复现。
跑分：赢了 24 项、输了 9 项，而且全是自测
官方放出 34 项跑分对照，在 4 倍视觉 token 压缩的设置下，相对 Qwen3.6-35B-A3B：赢 24 项、平 1 项、输 9 项。
赢的方面包括 MMBench 91.72、OCRBench 91.20、OmniDocBench v1.6 的 94.24、MMMU 80.22、MathVista 88.00、TextVQA 84.99、CCOCR 81.14。输的集中在 MMMU-Pro、MathVision、SimpleVQA 和 ScreenSpot 这四项。
把这些数字当营销材料读更稳妥，能信的只有内部逻辑：厂商自己的态度是「持平或更好」，不是「确实更好」。顺带一提，发布帖里说 OCRBench 领先 5.2 分，官方表格里算出来是 4.4 分。
1B 版本同样只有厂商图表：MMBench 83.17、OCRBench 86.10、OmniDocBench 85.39，相对上一代同尺寸模型各涨两三个点。它的命名也有点乱——仓库叫 1B，Hugging Face 侧栏写 2B，权重元数据是 15.5 亿参数，厂商图表里那行又标成 1.3B。四个来源四个数字，最小那个偏偏出现在营销图上。要给内存留预算，按 3.11GB 的文件大小算，别按标签算。
35B-A3B 还是 1B，先想清楚约束是什么
如果你的约束是手机、平板、笔记本或者一块小显卡，那 1B 才是那个能落地的答案：它在几 GB 内存里塞下一个 26 万 token 上下文的多模态模型，Apache 2.0 可商用，量化生态齐——GGUF、AWQ、GPTQ、int4、FP8 都有，首日就有瑞芯微、后摩、Intel、AMD、Arm 的适配。做端侧 OCR、截图理解、文档解析，选它。
35B-A3B 回答的是另一个问题：它不是在端侧复刻一个更强的小模型，而是在验证「大专家库能不能按需到场」。真想在手机上跑起来，官方那套组合拳（调度预测、逐层量化、投机采样、缓存管理）得同时到位，少一环速度就掉回去。
上手之前，先把运行时定下来
想自己试，有两条路，区别不小：
- GGUF 路线：官方有 GGUF 版本，引擎是 llama.cpp-omni 那个仓库。关键是把运行时版本、量化方案、投影文件、调度配置一起记下来——装好一个应用，不等于加速特性都开了。
- Transformers 路线：官方要求 Transformers 5.18 或更新。另外文档里标了一个视频解码的兼容问题（TorchCodec 和 CUDA 相关），可以用 PyAV 绕开。这个问题属于视频输入处理，和专家路由、模型质量无关。
要拿它做正经事，测试方法也得规范一点：固定文档集、固定分辨率、固定要求的输出格式，把下载体积和峰值内存分开记，把首 token 延迟和完整响应时间分开测，冷启动和热启动各跑一遍，OCR 拿一张标准答案对漏字和错字。别用一个短视频的解码速度去推算连续干活的吞吐。
优点
- 协议干净：两个版本都是 Apache 2.0，可商用，没有「研究用途」这类绊脚线。
- 交付完整：权重、量化、推理代码、评测素材首日齐发，这在端侧模型里不常见。
- 思路可复用：LES 解决的是「大专家库按需到场」的通用问题，代码开源在 llama.cpp-omni 里，别的 MoE 也用得上。
- 选择面宽：从 1B 到 35B-A3B，加上 GGUF、AWQ、GPTQ、int4、FP8，能匹配的硬件档位比较多。
- 多模态完整：图片、多图、视频、文档都能吃，26 万 token 上下文对整份文档友好。
缺点
- 「3GB」的表述容易被误读成模型体积，实际下载体积差了五倍以上。
- 全部跑分与速度都是自测，没有第三方复现，也没有公开说明 3GB 对应哪一档量化。
- 「无损」只在「保留了专家路由机制」这个意义上成立，换设备、换上下文长度、换输入类型都可能不一样。
- 激活参数口径混乱：A3B 是标签，实际区间横跨 24 亿到 40 亿。
- 1B 版本的参数命名四个来源四个说法，做预算时容易踩坑。
适合谁，谁可以先等等
适合：做端侧应用的开发者、想在自己机器上跑多模态理解的人、需要一个可商用开源视觉模型的小团队、正在评估「要不要上端侧」的产品负责人。
可以先等等：只想体验一下手机跑大模型的普通用户（官方演示和真机长期体验是两回事）、需要稳定吞吐做批量任务的人（自测数据不足以下投资决策）、对中文长文档抽取精度要求极高的场景（4 倍压缩下的精度损失需要自己验）。
这类端侧模型的选型，和买本地算力是同一道题。前面写过 一台 4999 美元的 DGX Spark 能本地跑多大的模型，结论同样落在「先看清约束，再谈参数」上。
替代方案
- 只要文本、要极致小体积：1B 版本自己就能当替代，不用上 35B-A3B。
- 要云端多模态检索、不想碰硬件：可以直接用云端方案，把端侧这部分省掉。此前 谷歌把多模态搜索塞进手机 走的是另一条路——把嵌入模型压到端侧做检索，不生成内容，思路可以对照着看。
- 要在本地跑更大的模型：这类需求更适合放到带独显的小主机上，端侧模型不是唯一解。
- 要中文文档抽取：可以拿它的 OCR 路线和更长上下文方案做一次对照测试，再决定压不压到端侧。
老达点评
第一，这次最值得学的不是跑分，是那句「预测只影响预取」。很多端侧宣称的加速，本质是砍能力换速度；它选择改调度不改数学，才算把「无损」两个字站住了。工程上的价值比数字大。
第二，「3GB」这个说法迟早要被误读。它没撒谎，但也没主动把「运行内存」和「模型体积」分开写进标题。做技术传播的人该知道，最容易被传播的那个数字，恰恰是最需要说清楚前提的那个。
第三，把跑分和速度都标注成「厂商自测」，是这次难得的好习惯。没有第三方复现之前，别拿它当采购依据。
第四，对做应用的人来说，真正的变化是「端侧能装的模型档位往上抬了一格」。以前端侧基本等于小参数模型，现在多了「专家库在闪存、工作集在内存」这条路线。这条路走通的收益不只属于面壁一家，更多端侧方向的实测和拆解，都收在 AI 工具评测专题 和 老达AI实践专题 里。
