35B 参数的 MoE 多模态模型被塞进手机 3GB 内存，13+ tokens/s，开源圈把端侧这条路走通了
一上来我得说句实话：MoE 模型能不能跑进手机，很多时候不是算力问题，是内存问题。一个 MoE 模型总参数几十 B，但单个 token 只激活几十分之一，算力其实没那么难。难在它的专家权重你得全存着，每一层 token 选哪几个专家是动态的，而手机内存根本塞不下全部专家。常见做法是让权重躺在 SSD 上，用的时候再往内存里搬，但来回加载的停顿会让解码慢到没法交互。另一条路是把专家池锁死，一次 prompt 只允许用固定那部分专家，加载是省了，可路由被砍掉一截，能力跟着缩水。所以端侧跑 MoE 一直是「要么卡死、要么阉割」。
OpenBMB 这次扔出来的 MiniCPM-V 4.7 35B-A3B，就是在跟这个问题较劲，官方给的结论很硬：这是第一个能在设备上流畅跑、又不损失性能的开源 MoE 模型，在 iPhone 17 Pro Max 上只占 3GB 内存，解码 13+ tokens/s。这个 35B-A3B 也是 MiniCPM-V 系列的第一个 MoE 模型。
拆开看，他们上的是三件套。第一是 Lookahead Expert Scheduling（LES），用跨层路由预测下一层大概率要用哪些专家，提前预加载，把「算」和「搬」重叠起来，预测错了就老实补加载，不影响最终的路由逻辑。第二是细粒度逐层量化，压缩专家权重的存储占用和内存搬运开销。第三是接上 DSpark 投机采样，跟专家调度和量化配合着提解码效率。技术名词听着密，落到日常就是：它没把专家锁死，也没让你干等 SSD 搬家。
视觉这边也攒了不少活。用了 LLaVA-UHD v4 的 intra-ViT 早期压缩，在视觉编码器里先把视觉 token 压掉，后面几层计算量直接降下来；同时支持 4x/16x 混合的可视 token 压缩，想要精细细节就上 4x 多留 token，追求省算力就 16x，具体任务自己平衡。图像、多图、视频理解都是从上一代带着走下来的能力，还单独铺了 OCR、PDF 解析、视觉 grounding 的任务指南。
性能这块官方给了一个挺提气的对比：Instruct 模式下，35B-A3B 在更短的推理时间内拿到了比 Qwen3.6 35B-A3B 更高的综合得分。这里我得提醒一句，这图是官方自己画的「性能-效率帕累托前沿」，单一 benchmark 永远只说明一部分问题，真上手跑多少还得自己验。不过方向是对的，同尺寸同结构的直接对比，至少说明它没有在效率上垫底。
部署面的诚意倒是拉得很满，或者说这次把它端侧定位的野心写得很具体。iOS、Android、HarmonyOS 全覆盖，瑞芯微、后摩智能、Intel、AMD、Arm 这些芯片平台给了 day-0 支持；推理框架支持 SGLang、vLLM、llama.cpp、Ollama，微调走 SWIFT 和 LLaMA-Factory，量化给了 GGUF、BNB、AWQ、GPTQ，还新增了 FP8。端侧仓库挂了 app 源码，官方 cookbook 把部署、微调、量化流程全铺开。对一个开源多模态模型来说，这不是「能用」，是「可落地」的味道贴到脸上。
连微调都给了新招。这次放的 Self-Replay Fine-Tuning（SRFT），说是低成本扩展模型能力、同时少遗忘已有能力，说白了就是给你自己往某个方向再打磨一遍的路子，不用全量重训。
说点存疑的地方。这个模型的语言主干用的是 Qwen3.5/3.6，视觉模块是 SigLIP2，这本身没啥毛病，但也说明它是站在别人的大模型肩膀上做的多模态封装，主干能力不是自己的。再有，13+ tokens/s 是手机端测出来的数字，实际跑真任务、长上下文、多轮对话，吞吐会怎么掉，官方 GIF 看着顺滑，但没人替你保证。我自己更想看它在消费级安卓机、不是顶配 iPhone 上的表现——3GB 内存这个数字很漂亮，可不同机型的可用内存和带宽差别大得离谱。
所以这条消息真正的意义不在「又发了个多模态模型」，而在「开源圈第一次把 MoE 多模态模型端侧化这条路走通」：参数 35B、激活 3B，能塞进手机还跑得动，这扇门一开，后面跟着的一批想做端侧多模态的人就有了现成的抄作业方向。至于它是不是真的「不损失性能」、SRFT 到底有没有效果，下星期盯着 GitHub 上的复现和实测就行。