MNN 开源轻量手机模型，部署包仅173MB
MNN 团队发布约 3 亿参数的 MNN-Pocket-0.3B，INT4 部署文件含权重与运行配置共 173MB，在指定 iPhone 测试中离线解码约 350 token/s。指定 iPad 测试下峰值 Metal 内存增量为 228MB，材料所述业务能力目标不能视为通用评测结论。
AI 深度解读
MNN-Pocket-0.3B 想解决的是：手机应用怎样在有限内存和电量里，装下一个能理解任务、响应足够快的本地模型。淘宝 MNN 团队给出的方案，是把约 3 亿参数的模型、词表、量化和推理引擎一起优化。
报道给出了 iPhone 18 Pro 离线解码约 350token/s 的成绩，但更值得程序员看的是它如何确定资源预算，以及这些数字能支持什么结论。部署轻量化有实测依据，特定业务达到 8B 级效果则仍是目标。
先定资源预算，再决定模型做多大
团队给「手机应用原生大模型」定了四项指标：指定配置下解码超过 200token/s，峰值内存低于 300MB，典型负载下单次增量能耗不超过参考电池能量的万分之一，以及指定业务场景达到 8B 级模型效果。
能耗目标对应输入 512~1024token、输出 128token，100 次推理不超过电池总能量的 1%。内存限制则考虑了手机的实际使用环境：即使有 8～16GB 内存，也要与系统和其他应用共享。假设模型模块预算约 500MB，推理控制在 300MB 以下，才能给上下文增长和集成开销留空间。
团队测试了约 50M 至 1.3B 参数的稠密模型。在 iPad Pro M5 的统一设置下，约 300M 是同时满足速度、内存两项约束的最大候选规模。
层数也不是越多越好。16 层增加到 28 层时能力提升，继续增加到 36 层，评测均分没有提高，解码却从 355token/s 降到 323token/s。最终采用 28 层和分组查询注意力（GQA），让多个查询头共享部分注意力数据，节省资源。这组架构实验与最终部署测速的配置不同，数字不能直接混比。
173MB 和 466token/s，分别在什么条件下成立
MNN-Pocket-0.3B 的 INT4 部署文件为 173MB，包含权重、分词器、计算图和推理配置。iPad Pro M5、Metal 后端、512token 配置下，加载与推理期间的峰值 Metal 驻留内存，相对加载前增加 228MB。
同一测试中，Qwen3-0.6B 的文件为 340MB，内存增量为 427MB，前者分别减少约 49% 和 47%。这里的 228MB 是特定内存指标的增量，不能当成整个 App 的总内存。
吞吐测试采用 MNN 3.6.2、INT4 和统一运行设置，每组预热一次、测量五次，取中位数，并分别测量 Prefill 和 Decode。前者处理输入，后者逐个生成 Token。
在 iPad Pro M5/Metal、512token 配置下，Prefill 达到 8,721token/s，Decode 为 466token/s；Qwen3-0.6B 的 Decode 为 286token/s，相差约 1.63 倍。Snapdragon 8 Gen 5 的 CPU 后端达到 251token/s。报道另称，iPhone 18 Pro 通过 MNN 完全离线运行，平均 Decode 约 350token/s。
解码吞吐不能直接代表用户等待完整答案的时间。
输入处理、输出长度和业务调用都会影响实际体验，原文没有给出完整请求的延迟数据。
小模型靠哪些取舍换来速度和能力
词表是一个直接的优化点。团队基于 Qwen3 分词器，将词表从约 151K 缩至 64K，减少约 57%，重点保障中文和英文，降低其他语言分词效率的优先级。这样既减少词嵌入与输出层的存储，也降低每生成一个 Token 时的输出计算开销。
能耗也有单独测量。一加 13（骁龙 8 至尊版）运行 4-bit 模型，在 CPU4 线程、输入 1024token、输出 128token 下，采集电池电流、电压并扣除闲置耗电，三轮平均增量能耗约 2.7J / 轮。按 6000mAh 电池折算，100 次同等任务约占总电量的 0.3%。
能力方面，报告中的英文 IFEval 为 73.20，团队构建的 IFEval-zh 为 74.59，在所比较模型中最高。覆盖知识、推理、数学、代码和指令遵循的 11 项评测均分为 50.00，高于报告列出的同规模模型及 MiniCPM4-0.5B、Qwen3-0.6B；MGSM-zh 为 51.20，HumanEval 为 53.66。
团队还提供预训练、后训练及部署阶段的入口。W4A16 QAT 端侧版本结合 MNN 优化，特定设备解码可达 466token/s；MNN-Pocket-0.3B-DFlash2 是投机解码草稿模型，先生成候选内容再验证，特定任务吞吐可达常规自回归解码的 2.06 倍。
我的判断
我认可先定资源预算、再选模型结构的路线。手机里的模型要与页面、图片、视频争资源，下载大小和持续耗电都影响能否真正上线。
但「指定场景达到 8B 级效果」不能理解成通用能力追平 8B。原文没有提供对应业务的对照结果；11 项评测均分也不能替代具体任务验收。中文指令测试由团队构建，仍需结合测试集和评测设置判断。
与更大的本地模型相比，它给出了更低资源占用的对照数据；与云端 API 相比，原文没有给出质量、完整延迟和成本对照。350token/s 也只是报道中的特定设备成绩，不能外推到普通手机，更不能据此认定它适合承担复杂编程任务。
能拿来做什么
- 如果准备在移动应用中集成本地模型，先明确模型下载、峰值内存和能耗预算，再选择候选模型，并单独记录模型内存增量与 App 总内存。
- 用实际业务指令验证中英文理解、格式遵循和任务完成率，不要只根据 HumanEval 53.66 判断它能否胜任日常 AI 编程。
- 复测时固定 MNN 版本、量化方式、后端和输入输出长度，分别测量 Prefill、Decode 与完整请求耗时；DFlash2 的收益也应在目标任务上单独验证。