手机跑 35B 大模型只要 3GB？先别急着腾内存，MiniCPM-V 4.7 的真实门槛在后面
MiniCPM-V 4.7 把 35B-A3B 多模态 MoE 搬上手机：“约 3GB”指的是运行时内存，真实门槛还有约 16.6GB 存储和 12GB 以上内存。
01
这两天，标题里带着“3GB”的新闻刷了好几轮。
35B 的多模态大模型，在手机上约 3GB 内存，每秒 13 个 token 以上。
我第一反应是，这不对吧。
35B 的模型，3GB 就装下了？
那我手机里那堆聊天记录，是不是也能压一压？
然后我去翻了它自己的仓库和文档。
冒昧了，是我理解错了，不少转发的人可能也理解错了。
3GB 是真的。
但 3GB 不是你以为的那个 3GB。
02
先把事情说清楚。
OpenBMB，也就是面壁智能 ModelBest，发布了 MiniCPM-V 4.7。
有两个版本，一个 35B-A3B，是这个系列第一个 MoE 模型，另一个是 1B 的小版本。
GitHub 上写的发布日期是 10 月 12 日，PR Newswire 的新闻稿是 10 月 15 日。
官方的说法是：35B-A3B 在 iPhone 17 Pro Max 上，约 3GB 内存，解码 13+ tokens/s，是“首个在端侧流畅运行且不损失性能的开源 MoE”。
注意，这是官方自己的说法。
那么问题来了，这 3GB 到底是什么？
OpenBMB 知识库里有一句原话，我觉得应该贴在每一条转发的最上面：
约 3GB，既不是完整模型文件的大小，也不是把全部权重常驻 GPU 所需的显存。
翻译成人话就是：
3GB 是它跑起来的时候，占着的那块内存。
不是你要下载的东西。
也不是你手机需要有的全部条件。
03
那真实门槛是多少？
答案藏在另一个仓库 MiniCPM-V-Apps 里。
我直接搬过来。
35B-A3B 用 Q3_K 专家量化，专家被拆到单独的 experts/ 目录里，一共 40 个分片。
主文件、全部专家、再加上 mmproj，合起来约 16.6GB。
官方建议留约 17GB 空间，而且要快速的内部存储。
内存方面，推荐 12GB 及以上的设备，官方是在 12GB 的 iPhone 17 Pro Max 上验证的。
内存更小的设备呢？
会自动退到更小的专家缓存。
能用，但明显更慢。
还有一个坑：手机上要用单独的 -les 版 GGUF，配上 experts/ 分片。官方那个完整 GGUF 是专家内联的，不适合拿来做手机 demo。
所以，真实的账是这样的：
存储约 16.6GB，建议留约 17GB。
内存推荐 12GB 起步。
跑起来的时候，约 3GB。
这几个数字，说的是同一件事的不同侧面。
只报最好看的那个，当然也不算撒谎。
只是你看完以后，会以为自己那台老手机也能跑。
04
那它到底是怎么做到只占 3GB 的？
这就要说到它的看家本事：Lookahead Expert Scheduling，简称 LES，前瞻专家调度。
MoE 模型的特点是，肚子里有很多专家，但每次只叫一部分出来干活。
问题是，手机内存装不下全部专家。
怎么办？
我用一个大家熟悉的东西来打比方：前置仓。
全部专家，放在存储里，这是大仓库。
内存，是门口那个小小的前置仓。
模型每算一层，路由器就会决定这次要叫哪几位专家。
LES 干的事情是，跨层预测下一层大概率会用到哪些专家，提前把他们从大仓库调到前置仓。
加载和计算同时进行，你这边还在算这一层，那边下一层的专家已经在路上了。
（这个比方是我自己打的，原理以官方说明为准。）
关键在于，它保留路由器本来选中的专家，不强行限定一个专家子集。
为什么不直接固定一个子集？那样不是更省事吗？
能省事，少加载。
但官方说了，那样会把模型本来要选的专家排除在外，能力会下降。
说白了，就是前置仓只放你最常买的那几样，你要买别的，对不起，没有。
省是省了，但你买到的东西也不是你想要的了。
LES 的思路是，前置仓小一点没关系，但你要的东西我都得能送到，只是靠预测提前调货。
除了 LES，官方还提了细粒度逐层量化和 DSpark 投机采样。
这也解释了为什么存储要快。
前置仓模式，拼的就是调货速度。
仓库离得远、路不好走，预测得再准也白搭。
内存不够的手机会自动缩小前置仓，所以能用，但会慢（这是我按官方“更小的专家缓存、明显更慢”做的理解）。
05
说完门槛，说点它确实有意思的地方。
视觉这边，基于 LLaVA-UHD v4，在 ViT 内部就做早期压缩，支持 4x 和 16x 混合视觉 token 压缩。
平台覆盖 iOS、Android、鸿蒙。
芯片 day-0 支持瑞芯微（Rockchip）、后摩（Houmo）、Intel、AMD、Arm。
推理框架支持 SGLang、vLLM、llama.cpp、Ollama。微调支持 SWIFT、LLaMA-Factory。
量化版本有 GGUF、BNB、AWQ、GPTQ，新增了 FP8。
还开源了一个 Self-Replay Fine-Tuning（SRFT），用来低成本扩展能力、减少遗忘。
成绩方面，官方自报：Instruct 模式下，35B-A3B 总分高于 Qwen3.6 35B-A3B，推理时间更短。1B 版在总分和效率上，明显超过 Qwen3.5 0.8B。
再说一遍，这是官方自己报的。
X 上也有用户晒测试，比如拿它读昏暗光线下加湿器的面板，在波普风海报里认出爱因斯坦。
这些是 X 用户自己的测试，没有经过核实，看个乐就行。
06
所以，普通人到底该怎么看这件事？
如果你想在手机上试 35B-A3B，先看下面几样东西。
手机内存是不是 12GB 起步。
存储是不是还能腾出约 17GB。
下载的是不是带 -les 的那个 GGUF 加 experts/ 分片。
如果其中有一样不满足，那你看到的“3GB 跑 35B”，跟你大概率没什么关系。
那 1B 版呢？
Q4_K_M 约 1.8GB 下载，推荐 4GB 以上内存。
这个门槛，才是真正“大部分手机都够得着”的那一档（这句是我的判断，官方没有这么说）。
下次再看到“手机跑多大模型只要多少内存”这种标题，不妨多问几句。
这个数字，是运行时占用，还是下载大小？
存储要留多少空间？
官方是在多大内存的设备上验证的？
内存不够的时候，是跑不起来，还是变慢？
问完这几句，标题背后的真实门槛也就清楚了。
说实话，我觉得 MiniCPM-V 4.7 做的事情是真本事。
把专家放在存储里按需调度，同时不砍模型本来的选择，这比“固定一个子集、跑分好看”要老实得多。
问题不在技术。
问题在于，一个工程上很漂亮的数字，被转发成了一个营销上很好听的数字。
技术团队在文档里老老实实写了 16.6GB 和 12GB。
转发的人只记住了 3GB。
只能说，我爱这个魔幻的世界。
来源：GitHub：openbmb/MiniCPM-V；Hugging Face 模型卡；OpenBMB 知识库；MiniCPM-V-Apps；PR Newswire 新闻稿。“约 3GB”为官方运行时内存说法，既不是模型文件大小，也不是全部权重常驻所需内存；对比成绩为官方自报；X 用户实测未核实。