淘宝MNN团队开源0.3B手机模型，iPhone 18 Pro上离线跑出350 token/s

MNN团队 投稿
量子位 | 公众号QbitAI

把大模型运行在手机上，已经有了不少探索。

从1B、4B到27B量级的稠密模型，再到总参数约30B、激活参数约3B的MoE模型，不同规模与架构正在拓展端侧部署的可能性。

但对手机应用开发者来说，成功加载模型、完成一次对话，只是起点。

对于淘宝、闲鱼这类日常高频使用的应用，大模型必须与其自带业务共享算力、内存和带宽。同时，还得在持续调用与多任务并发下，兼顾响应时延、功耗和温升。

MNN团队将这一设计方向称为“手机应用原生大模型”。他们发布了MNN-Pocket-0.3B，面向手机应用的任务需求与资源预算，在有限算力、内存和能耗下，兼顾任务能力、响应速度与持续运行体验。

手机应用原生大模型背景介绍

围绕淘宝等综合型手机应用，团队将“手机应用原生大模型”落实为四个维度的设计目标：

• 速度上，在指定设备与上下文配置下，解码吞吐超过200token/s。这一目标参考高速云端模型服务的生成吞吐，力求在本地提供流畅的生成体验。
• 内存上，在指定测试条件下，峰值内存低于300MB。即使手机拥有8～16GB内存，也需要由系统与多个应用共享。以约500MB的模型模块预算为例，将推理峰值控制在300MB以下，可以为上下文增长和集成开销保留余量。
• 功耗上，在典型推理负载（输入512~1024token、输出128token）下，单次推理增量能耗目标不超过参考手机电池能量的万分之一，即100次推理耗能不超过电池能总量的1%，控制高频调用的续航开销。
• 能力上，以在指定业务场景上达到8B级模型的效果为目标，兼顾中英文理解、世界知识与数学、代码推理能力，重点强化指令遵循，并为长上下文与多步骤任务保留扩展空间。

这些目标还需要在持续调用中共同接受检验：在满足任务要求的同时，控制功耗与温升，保持整机流畅，才能融入应用的日常使用。

MNN-Pocket-0.3B正是这一设计方向的具体实践。MNN团队从零设计并训练了这个约3亿参数、重点支持中文与英文的轻量语言模型，将模型结构、词表、训练数据、预训练与后训练方法，以及量化和推理引擎纳入协同优化，为淘宝业务与开源社区开发者提供一个具备任务理解能力、响应迅速、易于适配和集成的模型底座。

△手机应用原生大模型象限：MNN-Pocket-0.3B兼顾速度、内存与能力（注：峰值内存不仅取决于总参数量，还受词表规模、量化参数及加载缓冲影响，详细指标与测试设置见技术报告。）

0.3B参数，如何做到轻量与高速？

先看MNN-Pocket-0.3B在iPhone 18 Pro上的真机表现。模型通过MNN推理引擎完全离线运行，平均解码（Decode）速度约为350token/s。录屏同步展示输入处理（Prefill）、逐Token生成（Decode）的速度与峰值内存占用，直观呈现模型的响应效率与资源开销。

部署体积与运行内存：MNN-Pocket-0.3B的INT4 MNN部署文件体积仅为173MB，包含模型权重、分词器、计算图和推理配置。在iPad Pro M5、Metal后端、512token测试配置下，模型加载与推理期间的峰值Metal驻留内存相对加载前基线增加228MB。同一测试中，Qwen3-0.6B的部署文件体积为340MB，峰值内存增量为427MB。相比之下，MNN-Pocket-0.3B的部署体积减少约49%，峰值内存增量减少约47%。对于手机应用原生大模型，较小的部署体积能够降低模型下载与更新成本，较低的运行内存则为页面、图片、视频等业务模块保留更多空间，降低应用集成的资源负担。

△端侧大模型在iPad Pro（M5）上的内存占用与部署体积（上下文长度为512token）

跨平台推理速度：团队在Apple与Android设备上，使用Metal、OpenCL和CPU后端评估推理吞吐。测试采用MNN 3.6.2、INT4量化及统一运行设置，每组配置预热一次、测量五次，取吞吐中位数，Prefill与Decode分别测量。在iPad Pro M5/Metal、512token测试配置下，MNN-Pocket-0.3B的Prefill吞吐达到8,721token/s，Decode吞吐达到466token/s，约为同条件下Qwen3-0.6B（286token/s）的1.63倍。在Snapdragon 8 Gen 5的CPU后端，Decode吞吐达到251token/s。

△不同平台上端侧大模型的推理速度（上下文长度为512token，单位：token/s）

Prefill影响输入处理耗时，Decode影响后续生成速度。上述结果基于报告规定的量化、上下文与测量条件，实际表现会随设备、后端及输入输出长度变化，完整配置可参考技术报告第5节。

这些结果来自三个层面的协同：参数规模与结构控制整体开销，词表设计减少存储与输出计算，推理引擎提高硬件执行效率。

从手机应用的资源预算确定模型结构

面向手机应用原生大模型，团队将峰值内存低于300MB、解码吞吐高于200token/s作为架构选型目标，在资源预算内尽可能保留模型容量。围绕这一目标，团队构建了覆盖约50M至1.3B参数的稠密（Dense）模型配置，在iPad Pro M5、统一推理设置下进行测试。约300M是该组实验中同时满足两项约束的最大候选规模。

确定规模后，团队进一步在相近参数预算内，联合调整模型深度、隐藏层宽度、前馈网络与注意力配置。从16层增加到28层带来了能力提升；继续增加到36层，评测均分没有进一步提高，解码吞吐却从355token/s降至323token/s。这里的吞吐用于架构选型对比，与前述最终部署版本的测试配置不同。

最终，MNN-Pocket-0.3B采用28层结构，结合分组查询注意力（GQA）等配置，在模型能力、运行内存与推理效率之间取得平衡。

△MNN-Pocket文本模型架构和参数量选型

精简词表，降低存储与输出计算开销

对于0.3B模型，词嵌入与输出层会占用相当一部分参数。更大的词表通常有助于压缩文本长度，也会增加存储、访存和输出投影开销，因此需要结合目标语言与任务设计。

面向中文互联网手机应用，MNN-Pocket-0.3B将中文与英文作为重点支持语言，降低对其他语言分词效率的优先级。基于Qwen3分词器，团队将词表从约151K精简至64K，词条数量缩减约57%，减少词嵌入与输出层的参数和存储需求，并降低逐Token生成时的输出投影开销。

裁剪过程中，团队使用覆盖中英文、代码、数学和指令格式的语料筛选词条，同时保留特殊Token、字节回退Token与必要的BPE合并依赖。通过兼顾词表规模和编码效率，模型能够保留常用表达的高效编码，避免过度裁剪造成序列变长，抵消部署收益。

模型与引擎协同，加速端侧推理

MNN-Pocket-0.3B的端侧效率，来自模型设计与推理引擎的协同。MNN在CPU侧针对Arm点积与矩阵指令定制低比特内核，在GPU侧根据不同架构优化缓存访问、计算分块和线程配置，并提供面向高通Hexagon的专用后端。同时，为Prefill、Decode选择合适的执行路径，通过QKV、FFN算子融合与GPU命令复用，减少访存和调度开销。在常规自回归解码之外，MNN还支持投机解码，并针对8-draft配置实现专用GPU内核，优化多Token的并行计算。

团队在搭载骁龙8 Gen 5的设备上，分别评估MNN-Pocket-0.3B在CPU、GPU和NPU上的推理性能，并与llama.cpp对比。在4bit量化下测试MNN的性能Prefill性能是llama.cpp的1.51~2.90倍，Decode性能是llama.cpp的1.43~1.82倍，MNN性能具有明显优势。

在能耗方面，团队还在一加13（骁龙8至尊版）上，使用MNN对MNN-Pocket-0.3B的4-bit模型进行了功耗测试。在CPU4线程、输入1024和输出128基准负载下，通过采集电池电流与电压，并扣除闲置基准耗电，三轮测试折算的平均增量能耗约为2.7J/轮。以该手机电池容量6000mAh计算，执行100次同等负载任务累计增量能耗约占电池总电量的0.3%。

MNN-LLM通过统一的模型转换与推理接口，降低跨芯片、跨操作系统的集成成本。MNN已积累16K GitHub Star，MNN-LLM支持200+款大模型，相关模型累计下载超过百万次，为MNN-Pocket-0.3B进入实际应用提供了工程基础。

部署效率决定了模型进入手机应用的成本。接下来要验证的，是它能否在有限参数下准确理解输入，并按要求完成任务。

0.3B参数，任务表现同样出色

手机应用原生大模型的能力，需要体现在业务流程能够使用的结果上。评论抽取要求忠实复现原文，标签判断需要限定在候选集合内，结构化输出则必须遵守字段与格式。内容遗漏、无依据补充或类别越界，都可能影响后续处理。

因此，MNN-Pocket-0.3B在建设中英文理解、数学推理与代码能力的同时，重点强化指令遵循与受约束输出，为不同业务任务的适配提供基础。

模型的能力表现：在技术报告采用的评测设置下，MNN-Pocket-0.3B的英文IFEval得分为73.20，团队构建的中文指令遵循IFEval-zh得分为74.59，在所比较模型中均取得最高分。在覆盖中英文知识、推理、数学、代码与指令遵循的11项评测中，模型平均得分达到50.00，高于报告列出的同规模模型，以及MiniCPM4-0.5B、Qwen3-0.6B等更大规模的对比模型。其中，中文数学MGSM-zh得分为51.20，代码生成HumanEval得分为53.66。这些结果为应用适配提供了基础能力参考，具体业务仍需通过任务数据和验收标准验证。知识密集型任务与复杂推理，也仍是模型需要继续提升的方向。

△MNN-Pocket-0.3B与其他基线模型在11项基准测试上的精度指标对比

在固定参数规模下，团队通过多阶段预训练建立基础、SFT迭代补足短板、多教师蒸馏整合能力，再通过量化感知训练保留部署效果。

△MNN-Pocket-0.3B完整训练流程

多阶段预训练：让数据更适合小模型学习

小模型对数据质量与配比更为敏感。MNN-Pocket-0.3B将预训练数据按领域、文本形式、知识密度、难度和质量五个维度进行标注与分级，为不同训练阶段制定更精细的配方。

数据是否值得学？在清洗、去重的基础上，分别评估质量与知识密度：质量关注内容的准确性、连贯性与完整性，知识密度关注有效信息含量及冗余程度。两者各划分为低、中、高三级，分别对应Q1–Q3、D1–D3，区分“内容干净”和“信息充实”，提高筛选与配比的精度。

数据是否适合学？将难度划分为H1–H3三级，结合领域与文本形式，控制不同复杂度样本的分布。同时，对问答、表格和列表进行结构化整理，在部分数学与代码样本中补充概念、推理步骤或解释，增强可学习性。

数据应该何时学？将上述维度组合成数据分桶，通过候选配方试验与实际混合训练，联合调整各阶段的采样比例。例如，提高数学数据占比时，也同步考虑其中的质量、知识密度和难度构成，让领域配比与模型当前的学习阶段相匹配。

基于这套分级体系，MNN-Pocket-0.3B完成约4.1Ttoken、四阶段预训练：建立语言与知识基础，强化中文、数学与代码，通过高质量数据退火巩固能力，最后将上下文支持扩展至32K。

△MNN-Pocket-0.3B前三个预训练阶段，更精细的数据分级提高学习效率

SFT Loop Engine：围绕能力短板自主迭代训练

在预训练基础上，团队构建了约316万条样本的SFT数据配方，覆盖知识问答、数学、编程、中文任务与开放式生成，将基础能力转化为按指令完成任务的能力。

为提高迭代效率，团队开发了SFT Loop Engine，通过Agent编排训练、评测与数据改进，形成闭环：

训练→评测→失败归因→分配数据配额→合成与筛查→再训练。

流程将失败回答映射到细粒度任务类别，结合历史训练数据分布，确定需要补充的类别、语言与样本数量。合成环节不直接读取原始评测题，并执行去重和泄漏检查，再将筛选后的数据用于下一轮训练。

这一机制让训练改进对应到具体问题，同时通过回归评测检查新增数据带来的收益与其他能力的变化。对于需要覆盖多种业务任务的手机应用原生大模型，这有助于持续补足短板、维护能力平衡。

△MNN-Pocket-0.3B模型SFT Loop Engine流程图

MOPD：把多领域能力整合进同一个模型

完成SFT后，团队进一步解决有限容量下的多领域能力协调问题。数学、代码、知识和指令遵循各有优化目标，混合训练需要处理目标之间的相互影响，顺序训练也可能造成已有能力退步。

MNN-Pocket-0.3B采用多教师On-Policy蒸馏（MOPD），构建四条经过领域强化学习优化的教师路线，按样本所属领域选择教师，共同监督一个学生模型。

其中，On-Policy的关键是由学生先生成。教师读取学生实际产生的上下文，并在这些位置提供Token分布监督，使训练覆盖学生自身容易遇到的生成状态。团队采用分布匹配目标，为小模型提供更密集的学习信号，提升训练稳定性。

经过MOPD，模型在11项评测上的平均得分从35.79提升至50.00，其中10项提升、1项持平。中文数学、中文指令遵循和数学推理等任务取得了较明显的改善。

多教师承担训练阶段的能力指导，部署时只保留一个0.3B学生模型，使能力提升无需增加端侧教师模型的存储与推理开销。

QAT：让训练效果保留到部署版本

在手机应用中最终使用的低精度模型，同样需要接受能力检验。团队将量化纳入后训练流程，通过Self-OPD与量化感知训练（QAT），让W4A16学生在自身生成的上下文上，对齐冻结的BF16模型，缓解量化带来的能力损失。

在同一组11项评测中，INT4版本平均得分达到49.59，较BF16版本的50.00下降0.41分。这使前一章展示的部署效率与本章的任务能力，最终能够在同一个INT4版本上交付。

△MNN-Pocket-0.3B模型MOPD和QAT流程图

从基础训练到低精度部署，MNN-Pocket-0.3B的目标始终是形成可供应用使用的能力。接下来，通过不同阶段的模型开放与具体任务验证，让研究者和开发者能够继续适配、部署和检验。

0.3B模型开放多阶段权重，从任务微调走向应用实战

手机应用原生大模型的价值，还需要通过任务适配与应用集成来验证。为此，MNN-Pocket-0.3B提供从预训练、后训练到端侧部署的多个版本，让研究者与开发者能够选择合适的起点，继续训练、评测和构建应用。

从研究到部署，MNN团队开源不同阶段的模型入口：

对于学生和研究者，Base与SFT检查点分别提供了基础训练与后训练的实验入口，便于探索数据配方、强化学习和蒸馏方法。0.3B的参数规模有助于降低单次微调与评测开销，支持更高效的多轮实验。

对于应用开发者，最终指令模型可用于业务适配，MNN版本提供对应推理生态的部署资产。此外，Dec版本面向分类与候选选择任务，通过决策头在一次前向计算中完成候选打分；DFlash2草稿模型则面向生成加速，一次提出8个候选Token，由目标模型统一验证，减少逐Token生成的串行开销。

围绕业务适配与交互体验，团队进一步选择了电商评论观点挖掘和全端侧语音对话两条链路，检验模型在具体任务与完整应用中的表现。

垂类任务适配：0.3B模型的电商评论理解能力

“很好，遮瑕功能差一些”——一句简短评论，同时包含整体正向评价和对具体功效的负向评价。模型需要识别两者的对应关系，并区分明确表达与隐含信息。在天池电商评论观点挖掘任务中，输出由属性词、观点词、类别、情感极性四个字段组成。属性词与观点词必须来自原文，类别与情感必须限定在预定义集合内，未明确表达的字段按规则置空。一条评论中的多个观点，也需要完整抽取。

团队使用天池任务提供的3,229条评论，对各模型进行相同配方的LoRA微调，再提交平台对隐藏测试标签评分。评测要求四元组的四个字段全部匹配，才计为正确，因此同时考察原文抽取、细粒度分类与格式遵循能力。实验中，MNN-Pocket-0.3B的F1达到80.15，高于同一设置下的Qwen3-0.6B（77.47）和Qwen3-1.7B（78.59）。以不到后者五分之一的参数规模，取得了高出1.56个百分点的任务成绩。

△MNN-Pocket-0.3B模型在电商评论理解上的能力验证

这一结果验证了模型在该任务中的微调适配能力：通过领域数据与LoRA训练，0.3B模型能够将通用理解和指令遵循能力，转化为符合业务要求的结构化输出，为手机应用内的文本分析任务提供轻量实现路径。

全端侧语音对话：把速度与能力放进完整交互

语音交互进一步检验了模型在完整应用链路中的响应效率与协作能力。团队搭建了全端侧流式语音系统，串联语音识别、MNN-Pocket文本生成与语音合成，并集成语音活动检测、语义断句和打断控制，所有神经网络模块均通过MNN在设备本地运行。系统采用流式处理缩短等待时间：语音转为文本后，MNN-Pocket开始生成回答，文本增量分段送入TTS，随后逐段播放，无需等待完整回答生成。用户再次开口时，系统停止当前生成、合成与播放，进入新一轮交互。详细流程可参考技术报告第7.2节。

在报告的暖机测试条件下，系统实测首音频时延P50分别为：

• iPad Pro M5：600ms；
• Snapdragon 8 Gen 5设备：935ms；
• iPhone 13 Pro：1,055ms。

在统一ASR前端与评测设置下，采用MNN-Pocket的系统在九项VoiceBench任务上的总分达到45.44，为报告所比较语言底座中的最高分，展示了模型在语音输入条件下的综合任务能力。

△MNN-Pocket-0.3B模型结合语音对话场景的能力验证

这条链路验证了MNN-Pocket作为语言处理底座，与语音感知、合成及交互控制协同构建端侧应用的可行性。完整系统包含额外的ASR、TTS等模块，其整体存储与内存需求需结合具体应用单独评估。

让真实应用继续定义模型的下一步

手机应用原生大模型的价值，最终要在真实业务、真实设备与日常交互中体现。

MNN-Pocket-0.3B围绕应用需求，将模型结构、数据与训练方法、量化和推理引擎协同设计，在0.3B参数规模下兼顾任务能力、响应速度与部署成本，为应用开发提供可训练、可适配、可集成的模型底座。

接下来，团队将持续推进端侧模型研发，围绕淘宝等业务中的需求理解、搜索推荐与智能交互，提升模型可靠性、设备覆盖与端到端效率，并探索AI眼镜等设备上的应用。

通过开放不同阶段的模型与部署版本，团队期待与研究者和开发者一起，让模型在更多具体任务中得到验证与改进，让智能自然融入日常应用。

GitHub:https://github.com/alibaba/mnn
Hugging Face:https://huggingface.co/taobao-mnn/MNN-Pocket-0.3B
ModelScope:https://modelscope.cn/models/MNN/MNN-Pocket-0.3B
Technical Report:https://modelscope.cn/models/MNN/MNN-Pocket-0.3B/resolve/master/MNN-Pocket-0.3B-Technical-Report.pdf