35B模型塞进3GB内存，手机本地跑多模态成真
35B参数的多模态模型，在手机上只占 3GB 内存，解码速度跑到 13+ tokens/s 。OpenBMB发布的MiniCPM-V 4.7，把这两个数字同时摆了出来。 它被定义为首个能在手机本地流畅运行、且不牺牲性能的开源MoE多模态模型。参数规格是 35B-A3B ，测试设备是iPhone 17 Pro Max。 3GB是什么概念？放在手机内存里，这是一个普通应用级别的占用。而35B的模型体量，按常规思路根本装不进去。中间这道墙是怎么被拆掉的，答案藏在两项技术里。 把专家权重挪到闪存里 第一项叫LES，前瞻专家调度。它的思路是：MoE模型的专家权重不必全部驻留内存，可以放在闪存里按需加载。 但按需加载有个副作用——随机加载会造成明显卡顿。LES的做法是跨层路由预测，预判下一层会用到哪些专家并提前加载，同时优先计算已经在内存中的专家。 这套机制把加载停顿大幅压低，配合量化和存储布局优化，在真实设备上取得约 5倍 加速。 它的本质是把瓶颈从"内存容量"转移到了"闪存带宽+预测命中率"。属于系统层面的创新，不是模型结构创新。 微调时别把通用能力弄丢 第二项叫SRFT，自回放微调，面向开发者，解决的是定制化时的灾难性遗忘。 思路是：微调窄任务之前，先让模型自己为一批覆盖原有能力的通用prompt生成回答，经拒绝采样筛选后，以 Task:Replay = 4:1 混入任务数据做普通SFT。 训练流程完全不变，只改数据。关键洞察在于标签必须on-policy，也就是来自模型自身的分布。 消融实验给出了对比：同样的数据量，自生成标签把通用能力退化压到 1.58分 ，外部标签只能压到 5.58分 。 跨四个模型验证，遗忘降低 80%–99% ，任务性能基本无损。 两项技术指向同一个方向：让大模型在真实设备上跑起来，靠的不只是把模型做小，还有调度和训练数据层面的工程处理。 特别
