端侧大模型的部署正在从理想走向现实。过去一年里，行业里密集释放了多个关键信号：面壁智能的MiniCPM-V2.6、Qwen2-VL 2B、Qwen2.5 0.5B到3B系列、LLaMA 3.2 1B/3B——这些模型无一例外都瞄准了端侧场景。与此同时，苹果在iPhone 16上正式集成端侧大模型，实现智能回复、辅助撰写、图片擦除等功能，国内厂商也纷纷跟进。

大模型之所以能走向端侧，核心驱动力来自三个层面：实时交互的强需求（本地推理消除网络延迟）、隐私保护的硬约束（数据不出设备），以及个性化服务的吸引力（通过微调/LoRA实现定制）。而端侧设备的算力、内存和存储能力逐步提升，也让这一切变得可行。目前主流的部署载体集中在手机、PC和智能汽车——这些设备拥有相对充裕的计算和存储资源。

在这些设备上运行的推理场景已经相当丰富：聊天对话、代码补全、文生图……每一种都对延迟、内存和功耗提出了严苛的约束。正是在这样的背景下，阿里巴巴的MNN引擎在端侧大模型部署上做了一系列技术创新，下面逐一展开。

MNN框架：定位与核心能力

MNN是一个开源的轻量级深度学习推理引擎，核心目标很明确——让AI模型在各种设备（尤其是移动设备）上高效部署运行。它涵盖了从模型图优化、转化到高效运行的完整链路。

从流程上看，训练好的模型经过MNN的转换器，完成一系列图优化操作后输出MNN格式模型，最终在端侧设备上运行。目前，MNN已在阿里系的淘宝、闲鱼、钉钉以及集团外20多个APP中落地应用。

MNN的大模型能力

针对大模型，MNN目前主要聚焦LLM和Diffusion模型这两类Transformer结构。整套能力可以拆解为四个部分：

导出工具：将各类大模型转化为MNN模型格式；
量化工具：压缩模型体积、降低运行内存、提升推理速度；
插件和引擎：提供tokenizer、embedding、LoRA等运行大模型必需的组件；
MNN主库：负责底层运算和内存分配，底层支持CPU、GPU、NPU。

针对不同模型类型，流程略有差异。以LLM为例：输入文本先经过tokenize的encode操作转成整型数组，再做embedding向量化，随后在模型中进行多轮迭代推理，最终将输出结果decode成文本。Diffusion模型则是在tokenize和embedding之后，经过多轮扩散迭代（20到50次），最后解码生成图像。

模型转换：从原始模型到高效端侧模型

模型转换是端侧部署的第一道关卡。MNN支持Qwen、LLaMA、DeepSeek等众多主流模型。从Huggingface或ModelScope下载原始模型后，经过tokenizer标准化（支持Sentencepiece、Tiktoken、Bert等）、embedding导出、LoRA导出、量化操作，以及针对Transformer的Plugin Fusion图优化，最终生成量化的MNN模型。

这里特别值得关注的是Attention算子的优化。Transformer模型由连续block组成，Attention是每个block的计算核心，其优化效果直接影响整体性能。

上图左侧是一个ONNX模型图中的Attention操作——它被拆分成了16个算子，其中12个是形状变化算子，4个是计算型算子，存在大量访存冗余。右侧则是LLM中的Attention，由于引入了past key/value缓存，涉及大量Cache重复读写。通过Attention Fusion可以消除这些访存冗余，同时让KV-Cache的管理更方便。

除了Attention，Transformer中还有不少常用插件值得融合。

比如Transformer ResnetBlock，包含BroadCast Binary+GroupNorm+SiLU结构，在ONNX模型图中包含13个算子，融合为FuseGroupNorm后大幅简化计算。再比如Feed-Forward模块中的GEGLU结构，可融合为SpiltGeLU。这些Transformer-Plugin Fusion的核心意义是消除访存冗余，简化计算图。

另一个关键环节是权重量化。对于端侧部署而言，低比特量化几乎是必选项。一个7B模型如果用float32存储需要25GB+内存，而int4量化版仅需3.5GB；1.8B模型int4量化版不到1GB。MNN目前支持4比特/8比特的无输入数据校验Weight量化，支持对称/非对称量化、Channel block量化，以及GPTQ/AWQ权重的导入和对接。

推理优化技术：内存、速度与精度之间的平衡术

推理侧的优化涉及更多细节，以下四个维度是MNN重点发力的方向。

动态量化

动态量化是在运行时对实时输入数据进行量化。在CPU上，将输入的浮点数据计算量化信息，量化为int8后与已经量化为int4/int8的权重进行计算。ARM有int8域特定的加速指令集，这不仅能降低内存占用，还能获得直接的速度增益。同时采用PerBatch量化来保证精度。

在GPU上情况不同——int8域计算相对于浮点域没有优势，所以端侧GPU不做动态量化，而是在浮点域进行矩阵乘运算。对于内存瓶颈的矩阵乘，在kernel内部对权重在线反量化成浮点再计算；对于计算密集型算子，则插入额外算子提前反量化。

KV-Cache量化

长文本场景下KV-Cache的大小增长很快，量化是减少存储和访存量的有效手段。具体做法上：Key Cache采用per-token量化成int8，在int8域和经过动态量化后的Query做矩阵乘累加。Value与QK结果在kv_seq_len方向上累加，如果也采用per-token int8量化，需要在K_Loop内每个元素读取scale并反量化，性能损失太大，因此Value Cache改用fp8（e5m2）量化方式。

DRAM-Flash混用

端侧运行内存有限，多个应用抢占内存容易导致OOM。解决思路有两个：一是利用磁盘映射技术（mmap接口），将运行内存映射到磁盘，避免其他应用抢占内存导致崩溃；二是针对长文本KV-Cache存储过大的情况，采用磁盘存储，同时通过提前预取的方式掩盖磁盘读取的延迟开销。

硬件特性驱动的加速

针对不同硬件平台，MNN做了细致的优化：

• ARM CPU：多核负载均衡方面，对算力瓶颈的算子按核心频率比例分配任务，对带宽瓶颈的算子则平均分配任务。指令集层面，利用Armv8.2的sdot指令（2个4×4 int8数据乘累加输出一个4×1 int32数据）和Armv8.6的smmla指令（2×8和8×2 int8数据做gemm输出2×2 int32数据）提升吞吐。此外还在集成ARM KleidiAI算子加速库，支持SME指令。
• Qualcomm GPU：支持Recordable queue将多个kernel放在一起提交，减少kernel launch耗时；支持On-chip memory获得更快的访存速度。
• Apple GPU：A14和M1 GPU支持Simdgroup——组内所有thread间寄存器数据共享，无需同步或threadgroup memory共享。同时利用Simdgroup_reduce和Simdgroup_matrix指令进行优化。

性能表现与Demo

在小米14（8 Gen3）上的LLM性能测试中，MNN-LLM在prefill阶段无论是CPU还是GPU都处于领先水平，decode阶段相比其他框架也有明显优势。在Stable Diffusion测评中，Android Mi 14和Apple Mac M3上的表现同样优于竞品。

运行MNN LLM或Diffusion模型的核心步骤很简单：从Huggingface/ModelScope下载模型资源（torch模型及其他资源）→ 下载MNN源码并编译 → 使用MNN转换工具将torch模型转为MNN模型 → 运行Demo。详细教程可参考MNN官方文档的LLM和Diffusion章节。

在手机端实测中，MNN-LLM的响应速度和回答质量完全满足日常需求。多模态任务（文生图、图生文、语音生文）也都有流畅表现。

以上就是MNN在端侧大模型部署方面的主要技术实践。从模型转换、量化到推理优化，每个环节都在端侧资源受限的条件下寻找最优解。随着端侧设备算力持续提升，以及模型本身朝着更高效的方向演进，端侧大模型的应用空间值得持续关注。