北京时间 10 月 13 日,面壁智能联合 OpenBMB 开源了新一代端侧多模态模型 MiniCPM-V 4.7。发布当天各路标题都盯着同一个数字:35B 的模型,3GB 内存就在手机上跑起来。这个数字是真的,但被读歪的概率也很高——3GB 是推理时的运行内存,不是存储;而它手机端默认跑的那份权重,光下载就要约 16.6GB。下面按四件事讲:它是什么、那个 3GB 到底指什么、能力有没有打折、你要动手该怎么装。
一、这事是什么:三句话讲清
- 两档一起发。35B-A3B 是 MoE 架构,总参数 350 亿、每次推理只激活约 30 亿,也是 MiniCPM-V 系列的第一个 MoE 模型;另一个是稠密的 1B 档。两档权重都按 Apache-2.0 放出,官方在 Hugging Face 与魔搭社区都有镜像。
- 官方主推的那句话。面壁智能称 35B-A3B 是首个可在端侧无损流畅运行的开源 MoE 模型:iPhone 17 Pro Max 上只用约 3GB 内存,解码速度 13+ token/s;iPad Pro 上的官称数字是 15+ token/s。
- 支持面铺得很开。发布当天就支持 iOS、安卓、鸿蒙三个系统,芯片侧 day-0 覆盖瑞芯微、后摩、Intel、AMD、Arm;推理框架支持 llama.cpp、vLLM、SGLang、Ollama;量化格式有 GGUF、AWQ、GPTQ、BNB 并新增 FP8;微调侧给了 SWIFT 与 LLaMA-Factory,另开源自研的 SRFT 微调方案与 DSpark 投机解码草稿模型。
顺手记一个家族数字:MiniCPM 系列覆盖文本、视觉、语音全模态,官方口径是累计下载量已过 6000 万次。上一代 MiniCPM-V 4.6 是今年 6 月进的 Ollama 官方模型库,4.7 两天前已经跟上。官方 35B 档在魔搭上架两天,下载计数是 1575 次——这个量级说明它还在开发者手里,没到大面积普及。
二、先分清:那个 3GB 到底是什么
最容易误读的三句话,逐条拆开。
| 流传的说法 | 实际是什么 |
|---|---|
| 35B 模型只要 3GB 内存 | 3GB 是推理时的运行内存占用。专家权重留在 SSD 上按需读入,不常驻内存 |
| 3GB 内存的手机就能跑 | 官方端侧文档建议设备内存 ≥12GB,并在 12GB 的 iPhone 17 Pro Max 上验证;内存更小的设备会自动退回更小的专家缓存,能跑,但明显变慢 |
| 下载 3GB 就够 | 手机端 35B-A3B 实际要下约 16.6GB:主文件 + 40 个专家分片 + 视觉投影 mmproj,官方建议按约 17GB 空闲存储准备,还要求快的内置存储 |
可以逐项核对的实锤躺在官方模型仓库里。35B-A3B 的 GGUF 一路发了 12 个量化档:F16 是 69.38GB、Q4_K_M 21.17GB、Q4_K_S 19.89GB、Q5_K_M 24.73GB、Q6_K 28.51GB、Q8_0 36.90GB,另有一份专供端侧的 mix_q3gud_im 是 15.50GB;视觉投影 mmproj 有 0.91GB(4x 压缩)与 1.12GB 两个版本,DSpark 草稿模型 0.79GB。1B 档小得多:F16 2.02GB、Q4_K_M 0.67GB。官方在 GGUF 之外还发了 FP8、int4、AWQ、GPTQ 四套量化版本。同一批数字可以用 Ollama 库交叉验证——minicpm-v4.7:latest 登记 22GB、minicpm-v4.7:1b 登记 1.8GB,登记的上下文窗口是 256K。
一条我们自己的取数备注:Hugging Face 从我们这台机器直连是连接超时,文中的体积数字取自官方魔搭镜像与官方仓库文档。能访问 Hugging Face 的读者可以拿同名仓库自行核对,两边是同一套文件。
“无损”要按官方的定义读。官方对无损的界定是:不固定专家子集、计算仍然走模型原本的 token 级路由,预测只用于提前加载与调度。它不等于“跑分和云端旗舰一样”。第三方 Artificial Analysis 目前还没把这颗模型纳入统一榜单,所以眼下能引用的对比都是官方自测口径。
三、它凭什么能跑起来:LES 和官方那份提速表
端侧跑 MoE 的难点从来不是能不能跑,而是跑起来之后能不能用。专家权重可以留在 SSD 上按需加载,但一搬一停就会卡顿;另一种做法是固定一个专家子集,加载次数是少了,代价是后续每个 token 只能在这个子集里挑专家,能力会掉。面壁智能的解法是自研的 LES(前瞻专家调度):
- 跨层路由预测预取:提前把下一层可能要用到的专家读进来。官方强调预测只影响预取与调度,计算仍然照模型原本的路由走,预测漏掉的专家照常加载——因此不需要额外训练。
- 已就位的先算:实际路由选中、并且已经加载好的专家优先计算,其余必需专家并行加载,把等待时间压掉。
- 权重访问优化:把专家权重重排成连续存储,减少随机读、提升闪存顺序读效率,再叠加分层混合精度量化压缩体积与传输开销。
- 再叠一层 DSpark 投机解码,把解码效率往上再推一档。
官方在 iPad Pro 11 英寸 M4(16GB)上给了逐级叠加的实测表,基线是不做任何优化的 SSD 加载:
| 优化阶段 | 解码速度 | 相对上一级 | 相对基线 |
|---|---|---|---|
| 基线:专家权重从 SSD 加载 | 2.97 token/s | — | 1.00x |
| 加上 LES 调度与权重访问优化 | 9.81 token/s | 3.30x | 3.30x |
| 再叠加分层混合精度量化 | 14.92 token/s | 1.52x | 5.02x |
| 完整 LES + DSpark 投机采样 | 17.39 token/s | 1.17x | 5.86x |
这张表是全篇最值得看的东西。所谓“5 倍提速”是 5.86 倍的逐级累计值,拆开看:调度与访问优化一项就贡献了 3.3 倍,量化再加五成,投机解码再加两成。
这条路子我们九月见过一次。当时写的 colibri 用同一套“把磁盘当内存”的逻辑,让 744B 的 MoE 在 25GB 内存的笔记本上跑了起来(那篇在这里)。区别在面向的形态:colibri 是纯文本大模型,这次是给手机端多模态做的定制版——专家从 SSD 流式读、视觉塔单独处理,整条链子塞进移动端的内存预算里。
四、能力账:官方把谁当对手
- 综合能力:官方口径是 35B-A3B 在 Instruct 模式下,以更短的推理时间取得了比 Qwen3.6 35B-A3B 更高的综合得分;1B 档相比上一代 MiniCPM-V 4.6 继续提升,并在综合得分与推理效率上均优于 Qwen3.5 0.8B。
- 视觉侧:沿用 LLaVA-UHD v4 的 ViT 内早期压缩,支持 4x/16x 混合视觉 token 压缩,开发者可以按任务在细节与算力之间取舍。
- 第三方看到的样子:智东西在发布当天用在线演示平台试了一轮,观感是推理速度快、单任务基本维持在秒级,图像识别与图文分析结果准确、回答完整;同时也碰到演示平台对 token 输出长度有上限,部分复杂问题答不完整。那是在线演示环境的限制,不等于手机端的表现,但它提醒了一件事:端侧模型的实际产出长度会被部署方式牵制。
- 别读过头:官方对比的对象是同级别的开源模型,不是云端旗舰。手机端那份权重用的是 Q3_K 专家量化,和桌面上的 Q4、Q8 是两笔不同的买卖。
五、怎么用起来:三条路,一条比一条省事
路径一:直接装现成 App,这是普通人唯一合理的起点。 官方端侧仓库把三个平台的包都放出来了:iOS/iPadOS 走 TestFlight 公开链接(要求 iOS 16.6 起),安卓下 GitHub Releases 里的 APK,鸿蒙下 HAP。装完首次启动,进应用内的模型管理点下载——35B-A3B 那份约 16.6GB——下完点“Use This Model”激活。官方明确建议在 App 内下载,因为它会把每个文件、每个分片的大小都校验一遍,自己拼目录很容易拼错。
路径二:Ollama,桌面和服务器上最省事。 一条命令跑起来:ollama run minicpm-v4.7:1b(1.8GB)或者 ollama run minicpm-v4.7:latest(22GB)。这两个档是给有内存的机器用的,登记上下文 256K,和手机端默认的 4K 完全是两个世界。
路径三:自己编译,或把模型接进自己的程序。 推理侧用 llama.cpp、vLLM、SGLang;五套量化各有官方指南。端上要自己编的话,iOS 侧得先用仓库脚本产一份约 189MB 的 llama.xcframework(M 系 Mac 上约 2 到 3 分钟),拉子模块记得用 shallow 模式,那个 llama.cpp fork 完整克隆接近 350MB;安卓侧要 NDK 27 加 arm64 真机;鸿蒙侧要 DevEco 5 以上加 API 12 以上的真机。iOS 自己编还额外需要开发者模式和自己的签名团队。
六、六个坑,按踩到的概率排序
- 官方仓库的 35B GGUF,手机端其实载不进去。 那份
mix_q3gud_im把路由专家内联在同一个文件里,手机要么把整块约 15.5GB 当一次缓冲映射、要么让它常驻内存,两种都会被系统直接杀掉。手机端必须用 demo 专用的-les拆分版:主文件加一个experts/目录(40 个分片加清单),专家才会被按需从 SSD 分页读入。 experts/必须和主文件配套。-les主文件本身不含路由专家权重,配错一套就过不了磁盘一致性检查,模型直接拒载。稳妥办法只有一个:在 App 内下载。- 别忘了 mmproj 那 1.1GB。 视觉塔与投影层一直发 f16,官方解释是量化视觉塔对感知质量的伤害明显大于量化语言部分。1B 档更极端:主体 Q4_K_M 只有 0.67GB,mmproj 却有 1.1GB,比模型本身还大。
- 手机端默认上下文只有 4K。 官方三个 demo 都默认 4K,开大是线性吃 KV cache 的,边缘设备上很可能得往回收。想要长上下文,那是桌面侧的玩法。
- 存储容量和读速都是门票。 约 17GB 空闲存储之外,官方特别点了“快的内置存储”——专家按需从 SSD 读,慢存储会直接把吞吐拖下来。
- 磁盘上的那个“35B”是 Q3 级。 端侧那份用的是 Q3_K 专家量化,不是桌面常见的 Q4。想要更高精度就换 Q4_K_M(21.17GB)或 Q8_0(36.90GB),代价是体积与内存需求同步上涨。
七、我的判断:谁该上、谁再等等、谁别碰
该上的
- 手上是 12GB 内存 iPhone 17 Pro Max、iPad M4 这类设备的人。一次性下约 17GB,换来的是永久离线、零 API 费用、资料不出设备。处理证件、合同、病例这类不想上传的照片与文档,这是目前少数能在手机上跑 35B 级多模态的开源选项。
- 做端侧产品、想验证“手机本地多模态”可行性的开发者。Apache-2.0、权重可下、五套量化格式齐全、三个系统都有可编译的适配代码,该铺的路官方都铺了。
- 已经在用本地小模型做 OCR 或 PDF 解析的人。这条路原本的瓶颈是模型太小、认字不准,35B-A3B 把天花板抬了一档,而部署方式和以前没有本质区别。
再等等的
- 8GB 及以下内存的手机。官方说法很实在:内存不够时会自动退回更小的专家缓存,能跑,但明显变慢。这个落差下,本地跑不如先用云端。
- 想要接近云端旗舰质量的人。手机端是 Q3 专家量化加 4K 默认上下文,对标的是同级开源模型,不是云端顶配。
- 个人小内存服务器的玩家。1B 档 1.8GB 下载、官方建议 ≥4GB 内存,对于常年在 2GB 上下挣扎的机器依然是紧的。这条线留给桌面和笔记本更划算。
别碰的
- 既没有 12GB 内存、也没有快内置存储的设备。省下的那点 API 钱,换不回等待时间。
- 指望它现在就替代云端 API 的人。离线是它最大的卖点,同时也是它的上限。
面壁智能这次真正证明的不是“手机能跑 35B”,而是MoE 的专家可以被当成虚拟内存来调度——把闪存当内存池,用预测式预取替代真内存。这个思路一旦跑通,后面会有更多大参数模型从同一条路走下来。对普通人来说,值得记住的不是今天这个 13 token/s,而是再过一两代,你现在手上这台手机的本地 AI 能力会到什么位置。
顺带一提:如果你更关心内存小到 2GB 的设备还能跑什么,这份1.6 GiB 内存服务器的实测清单里的取舍逻辑和端侧是同一套。
本文由拾光札记编辑部整理,勘误请联系我们