企业官网建设流程全解析

1. 为什么要在MTK平台上跑Qwen2.5

把Qwen2.5这类大模型塞进MTK平台，很多人第一反应是"这不是自找麻烦吗"。毕竟MTK芯片的主战场一直是移动终端、智能座舱、边缘盒子这类功耗敏感、算力有限的场景，而Qwen2.5哪怕是0.5B的版本，参数量摆在那里，跟传统CNN模型完全不是一个量级。但实际项目做下来，我发现这条路不但走得通，而且在特定场景下比"上云"更划算——数据不出设备、响应延迟稳定、没有网络抖动，这些优势在工业质检、车载语音助手、离线翻译笔这类产品上是刚需。

我自己第一次接触这个需求，是给一个做智能会议终端的客户做方案。他们的设备用的是MTK Genio系列平台，原本只跑一些语音唤醒和降噪算法，后来产品经理拍脑袋要加"会议纪要自动生成"，要求本地推理、不联网。当时团队里没人相信MTK能扛得住，结果折腾了两个月，从模型转换到推理部署全流程跑通，实测Qwen2.5-0.5B-Instruct在Genio 1200上首token延迟控制在800ms以内，生成速度大概12 tokens/s，虽然不算快，但完全可用。

这篇文章就是把这套流程完整拆开讲。核心关键词是MTK平台、Qwen2.5、模型转换、推理部署，我会从模型格式转换、量化策略、推理引擎选型、内存与线程调优、实测性能数据这几个维度展开，适合正在做边缘AI部署的工程师、对端侧大模型感兴趣的开发者，以及需要给MTK平台选型做技术评估的架构师。文章里涉及的操作步骤和参数配置，都是我在实际项目中验证过的，不是纸上谈兵。

需要提前说明的是，MTK平台型号差异很大，从入门的Genio 350到高端的Genio 1200、天玑系列，NPU算力和内存带宽差了好几倍。我下面讲的方法论是通用的，但具体参数需要根据你手上的芯片型号做调整。另外，Qwen2.5有0.5B、1.5B、3B、7B等多个尺寸，MTK平台实际能跑得舒服的主要是0.5B和1.5B，3B以上就要看具体芯片的NPU能力了。

2. Qwen2.5模型转换的核心链路

2.1 从HuggingFace原始权重到可部署格式

Qwen2.5在HuggingFace上发布的是PyTorch格式的权重，包含config.json、model.safetensors、tokenizer.json等文件。MTK平台的推理引擎通常不直接吃PyTorch权重，需要先转成ONNX或者MTK自家的格式。这里有个关键决策点：走ONNX路线还是走MTK NeuroPilot路线。

ONNX路线的好处是通用性强，转换工具链成熟，torch.onnx.export或者optimum库都能干这活。缺点是ONNX Runtime在MTK平台上的NPU加速支持有限，很多时候只能跑CPU，性能上不去。MTK NeuroPilot路线是官方推荐的，能把模型编译成NPU能执行的格式，性能提升明显，但工具链相对封闭，文档也没那么友好。

我实际项目里两条路都走过。第一版用ONNX，在Genio 1200上CPU推理Qwen2.5-0.5B，生成速度只有3 tokens/s，基本没法用。后来切到NeuroPilot，用mtk_nn_stream工具链编译，速度提到12 tokens/s，翻了四倍。所以如果你的项目对性能有要求，强烈建议走NeuroPilot路线。

转换的第一步是导出ONNX。这里有个坑：Qwen2.5用了RoPE位置编码和GQA（分组查询注意力），直接torch.onnx.export可能会报错。我的做法是用HuggingFace的optimum库，它已经内置了对Qwen系列的支持：

from optimum.onnxruntime import ORTModelForCausalLM from transformers import AutoTokenizer model_id = "Qwen/Qwen2.5-0.5B-Instruct" model = ORTModelForCausalLM.from_pretrained(model_id, export=True) tokenizer = AutoTokenizer.from_pretrained(model_id) model.save_pretrained("./qwen2.5_onnx") tokenizer.save_pretrained("./qwen2.5_onnx")

这段代码跑完，你会得到一个ONNX模型文件，通常是model.onnx加上model.onnx_data（外部权重）。注意Qwen2.5-0.5B的ONNX文件大概1GB左右，1.5B版本大概3GB，转换过程中需要保证磁盘空间充足。

2.2 量化策略：INT8还是INT4

ONNX模型直接部署到MTK平台，内存占用和带宽压力都很大。量化是必须的。MTK NeuroPilot支持INT8和INT4两种量化精度，选择哪个要看你的场景。

INT8量化的精度损失很小，Qwen2.5-0.5B量化后模型大小从1GB降到500MB左右，实测生成质量几乎无损。INT4量化后模型只有250MB，但精度损失明显，尤其是长文本生成时容易出现重复、逻辑断裂的问题。我的经验是：如果内存够用，优先INT8；如果内存紧张且对生成质量要求不高，再考虑INT4。

MTK的量化工具是mtk_quantize，基本用法：

mtk_quantize --input_model qwen2.5_onnx/model.onnx \ --output_model qwen2.5_int8.onnx \ --quant_type int8 \ --calibration_dataset calibration_data.txt

这里的关键是校准数据集。量化不是简单地把FP32截断成INT8，而是需要一批代表性数据来统计激活值的分布范围。校准数据选得不好，量化后的模型精度会崩。我的做法是从实际业务场景里抽200-500条文本，覆盖各种长度和主题，作为校准集。别用随机生成的文本，那样统计出来的分布跟真实推理差太远。

2.3 编译成MTK NPU可执行格式

量化完的ONNX模型还不能直接在NPU上跑，需要用MTK的编译器转成.dlc或者.nb格式。这一步用的是NeuroPilot SDK里的mtk_nn_compiler：

mtk_nn_compiler --model qwen2.5_int8.onnx \ --target genio1200 \ --output qwen2.5_int8.dlc \ --optimize_level 3

--target参数指定目标芯片型号，不同芯片的NPU指令集不一样，编译出来的格式不通用。--optimize_level控制优化等级，3是最高，编译时间会长一些，但推理性能最好。

编译过程中最常见的报错是"unsupported operator"。Qwen2.5里有些算子MTK NPU不支持，比如某些变体的LayerNorm或者自定义的激活函数。遇到这种情况，有两个解法：一是用MTK提供的算子替换工具，把不支持的算子映射到支持的实现；二是把不支持的层切出来放到CPU上跑，其余部分在NPU上跑。第二种方案性能会打折扣，但胜在简单。

3. 推理引擎选型与集成

3.1 MTK NeuroPilot Runtime的接入方式

模型编译成.dlc之后，下一步是在应用层调用MTK的推理Runtime。NeuroPilot提供了C++和Python两套API，实际产品里用C++居多，因为要跟Android或者Linux应用集成。

C++接入的核心流程是：加载模型、创建推理上下文、准备输入输出Tensor、执行推理、解析结果。下面是一个简化版的代码框架：

#include <mtk_nn_runtime.h> // 加载模型 MtkModel* model = mtkModelCreate("qwen2.5_int8.dlc"); MtkContext* ctx = mtkContextCreate(model); // 准备输入 MtkTensor* input_ids = mtkTensorCreate(ctx, "input_ids", MTK_INT32, {1, seq_len}); MtkTensor* attention_mask = mtkTensorCreate(ctx, "attention_mask", MTK_INT32, {1, seq_len}); // 执行推理 mtkContextSetInput(ctx, input_ids, 0); mtkContextSetInput(ctx, attention_mask, 1); mtkContextRun(ctx); // 获取输出 MtkTensor* logits = mtkContextGetOutput(ctx, 0);

实际项目里，这段代码要封装成一个类，管理模型生命周期、处理多轮对话的KV Cache、做tokenizer的编解码。KV Cache这块特别重要，Qwen2.5是自回归生成，每生成一个token都要重新计算注意力，如果不缓存KV，生成100个token就要算100次完整的前向，性能会差到没法用。

3.2 Tokenizer的端侧适配

Qwen2.5用的是BPE tokenizer，词表大小15万左右。在MTK平台上跑tokenizer，有两个选择：用HuggingFace的tokenizers库（C++版本），或者用MTK提供的轻量级tokenizer实现。

tokenizers库功能全，但依赖Rust运行时，在嵌入式环境里编译比较麻烦。MTK的轻量级实现只支持基本的BPE编码，特殊token的处理需要自己补。我实际项目里用的是后者，因为编译简单、内存占用小。代价是要自己处理Qwen2.5的chat template，把对话历史拼成模型期望的格式：

<|im_start|>system You are a helpful assistant.<|im_end|> <|im_start|>user 你好<|im_end|> <|im_start|>assistant

这个模板如果拼错了，模型输出会完全乱掉。我踩过一次坑，把<|im_end|>写成了<|endoftext|>，结果模型一直重复输出用户的问题，排查了半天才发现是模板问题。

3.3 多线程与NPU核心调度

MTK平台的NPU通常有多个核心，比如Genio 1200的NPU有4个核心。推理时怎么调度这些核心，对性能影响很大。NeuroPilot Runtime默认是单核心推理，要开多核心需要显式设置：

mtkContextSetNumCores(ctx, 4);

但多核心不是越多越好。Qwen2.5的推理是串行的，每个token的生成依赖前一个token的结果，多核心并行只能加速单个token内部的计算。实测下来，4核心比单核心大概快2.5倍，不是线性的4倍，因为核心间的同步有开销。

另外，CPU和NPU的协同也很关键。tokenizer的编解码、采样策略（top-k、top-p）这些操作是在CPU上跑的，如果CPU线程数不够，会成为瓶颈。我的配置是：NPU用4核心跑模型推理，CPU开2个线程做tokenizer和采样，整体吞吐能提升30%左右。

4. 内存与性能调优实战

4.1 内存占用分析与优化

Qwen2.5-0.5B INT8量化后模型文件250MB，但实际运行时内存占用远不止这些。推理过程中需要分配输入输出Tensor、KV Cache、中间激活值。实测下来，Genio 1200上跑Qwen2.5-0.5B，峰值内存占用大概600MB。

KV Cache是大头。Qwen2.5-0.5B有24层，每层KV Cache大小是2 * hidden_size * seq_len * batch_size * sizeof(dtype)。假设hidden_size是896，seq_len是512，batch_size是1，INT8存储，那KV Cache就是2 * 896 * 512 * 1 * 1 = 917KB每层，24层就是22MB。看起来不大，但如果seq_len拉到2048，就是88MB，内存压力就上来了。

优化KV Cache有几个方向：一是限制最大生成长度，别让模型无限生成；二是用PagedAttention之类的技术做内存分页，但MTK平台支持有限；三是INT4存储KV Cache，精度损失可接受。我实际项目里用的是第一种，把max_new_tokens限制在256，配合业务场景足够用。

4.2 首token延迟与生成速度的平衡

首token延迟（TTFT）和生成速度（TPS）是两个关键指标，但它们的优化方向有时候是矛盾的。TTFT主要受prefill阶段影响，输入prompt越长，TTFT越大。TPS受decode阶段影响，跟模型大小、NPU算力、内存带宽都相关。

实测数据：Genio 1200上Qwen2.5-0.5B INT8，prompt长度128，TTFT约800ms，TPS约12 tokens/s。如果把prompt长度拉到512，TTFT会涨到2.5s左右，TPS基本不变。

优化TTFT的手段：一是用chunked prefill，把长prompt切成小块分批处理，降低单次计算量；二是用NPU的并行能力加速prefill阶段的矩阵运算。优化TPS的手段：一是减少采样开销，用greedy search代替top-p采样；二是用投机解码（speculative decoding），用小模型预测、大模型验证，但MTK平台对投机解码的支持还在完善中。

4.3 温度控制与功耗管理

MTK平台大多是功耗敏感设备，大模型推理会让NPU和CPU满载，发热明显。Genio 1200在持续推理时，芯片温度能到70度以上，如果不做温控，会触发降频，性能直接腰斩。

我的做法是：在推理循环里加温度检测，超过阈值就降低推理频率或者暂停推理。MTK提供了mtk_thermal_get_temp接口，可以读取芯片温度。另外，NPU的频率也可以动态调整，mtk_npu_set_freq可以设置NPU工作频率，低频省电但性能下降，高频性能好但发热大。实际项目里我设的是中档频率，平衡性能和功耗。

还有一个容易被忽略的点：内存带宽。大模型推理是内存带宽密集型任务，NPU算力再强，如果内存带宽不够，也会成为瓶颈。MTK平台的LPDDR带宽有限，跑大模型时要尽量减少内存拷贝，输入输出Tensor尽量复用，避免频繁分配释放。

5. 实测性能数据与场景适配

5.1 不同MTK芯片的实测对比

我在三款MTK芯片上跑过Qwen2.5-0.5B INT8，数据如下：

Genio 350跑起来比较吃力，TTFT超过3秒，用户体验不好，适合对实时性要求不高的场景，比如离线文档摘要。Genio 700是甜点级，TTFT 1.5秒，TPS 7，能满足大部分语音助手场景。Genio 1200性能最好，但成本也最高，适合高端会议终端、车载座舱这类产品。

5.2 Qwen2.5-1.5B的可行性评估

Qwen2.5-1.5B参数量是0.5B的三倍，INT8量化后模型大小约1.5GB，内存占用峰值大概1.8GB。Genio 1200的NPU算力够，但内存带宽是瓶颈。实测TTFT约2.5s，TPS约5 tokens/s，比0.5B慢了一倍多。

如果业务场景对生成质量要求高，1.5B是值得的，它的逻辑推理和长文本生成能力明显强于0.5B。但如果只是做简单的意图识别、槽位填充，0.5B完全够用，没必要上1.5B。我的建议是：先用0.5B跑通流程，验证业务价值，再根据效果决定是否升级到1.5B。

5.3 典型应用场景的配置建议

不同场景对延迟、吞吐、精度的要求不一样，配置策略也要调整：

• 语音助手：要求低延迟，TTFT控制在1秒内，TPS 8以上。建议用Genio 700以上芯片，Qwen2.5-0.5B INT8，max_new_tokens限制在128。
• 会议纪要：对延迟不敏感，但要求生成质量高。可以用Genio 1200，Qwen2.5-1.5B INT8，max_new_tokens放到512。
• 离线翻译：要求双向翻译，输入输出都比较长。建议用Genio 1200，Qwen2.5-1.5B INT8，配合chunked prefill优化TTFT。
• 工业质检报告生成：输入是结构化数据，输出是固定格式文本。Qwen2.5-0.5B足够，重点优化TPS，用greedy search减少采样开销。

6. 踩过的坑与排查经验

6.1 模型转换时的算子不兼容

第一次转换Qwen2.5-0.5B到MTK格式时，编译器报了一堆"unsupported operator"，主要集中在RoPE位置编码和GQA注意力上。MTK NPU对这两个算子的支持是分芯片的，Genio 1200支持，Genio 350不支持。

排查方法：先用mtk_nn_compiler --list_ops查看目标芯片支持的算子列表，然后对照ONNX模型的算子清单，找出不支持的。对于不支持的算子，要么用MTK提供的替换工具改写，要么把相关层切到CPU上。我当时的做法是把RoPE层切到CPU，其余部分在NPU上跑，性能损失大概15%，但至少能跑起来。

6.2 量化后精度崩塌的定位

有一次量化完Qwen2.5-0.5B，模型输出全是乱码，重复同一个词。排查了半天，发现是校准数据集的问题。我当时图省事，用了一段英文技术文档做校准，结果模型对中文的激活值分布统计完全偏了，量化后中文生成能力直接崩掉。

教训：校准数据集必须覆盖实际业务场景的语言和主题分布。如果是中英混合场景，校准集里中英文比例要跟实际使用一致。另外，校准集的数量也有讲究，太少统计不准，太多浪费时间，200-500条是比较合适的范围。

6.3 推理时的内存泄漏

在Android应用里集成MTK推理Runtime时，遇到了内存泄漏问题。每轮对话结束后，内存占用都会涨一点，跑几十轮之后OOM。用valgrind排查，发现是KV Cache没有正确释放。

MTK的Runtime API里，mtkTensorDestroy和mtkContextDestroy要成对调用，而且顺序不能错。我当时的代码是先销毁Context再销毁Tensor，结果Tensor的引用计数没减到零，内存一直不释放。改成先销毁Tensor再销毁Context，问题解决。

6.4 多轮对话的上下文管理

Qwen2.5支持多轮对话，但MTK平台内存有限，不能无限累积上下文。我的做法是维护一个滑动窗口，保留最近N轮对话，超过就丢弃最早的。N的取值要看内存预算，Genio 1200上N=5比较安全，Genio 350上N=2。

另外，system prompt也会占用上下文长度。如果system prompt很长，留给对话历史的空间就少了。建议把system prompt精简到100字以内，把关键指令放在user message里。

7. 从Demo到产品的工程化建议

7.1 模型版本管理与OTA升级

产品化之后，模型不可能一成不变。业务需求变了、Qwen发布了新版本、量化策略优化了，都需要更新模型。MTK平台的模型文件通常放在/vendor/etc/或者应用私有目录，OTA升级时要考虑模型文件的版本管理和回滚机制。

我的做法是：模型文件带版本号，应用启动时检查版本，不匹配就触发下载。下载用差分更新，只传变化的权重，减少流量。回滚机制是保留上一个版本的模型文件，新版本加载失败时自动切回旧版本。

7.2 推理服务的稳定性保障

端侧推理不像云端有完善的监控和容错，出问题了只能靠本地日志。建议在推理Runtime里加详细的日志，记录每次推理的输入长度、输出长度、耗时、内存占用。出问题时能快速定位。

另外，要加超时机制。如果某次推理超过预期时间（比如TTFT超过5秒），直接中断，返回兜底结果。别让用户对着卡死的界面等。

7.3 与云端方案的混合部署

纯端侧推理有局限性，模型能力受限于芯片算力。实际产品里，我建议做混合部署：简单任务端侧处理，复杂任务上云。比如语音助手，唤醒词识别、简单指令在端侧跑Qwen2.5-0.5B，复杂的知识问答上云跑更大的模型。

混合部署的关键是任务路由。可以根据输入长度、任务类型、网络状态来决定走端侧还是云端。网络不好时全走端侧，保证基本可用；网络好时复杂任务上云，提升体验。

7.4 性能监控与持续优化

产品上线后，要持续监控端侧推理的性能数据。MTK平台可以通过mtk_perf接口采集NPU利用率、内存带宽、功耗等指标。这些数据回传后，能帮你发现性能瓶颈，指导后续优化。

我实际项目里，上线第一个月就发现Genio 350机型上TTFT波动很大，有时候3秒有时候5秒。排查后发现是后台有其他进程占用NPU，导致推理排队。后来加了NPU资源锁，保证推理进程优先，问题解决。

这套流程走下来，MTK平台跑Qwen2.5从技术验证到产品落地，大概需要2-3个月。难点不在单点技术，而在工程化的细节：模型转换的算子兼容、量化的精度保持、推理的内存管理、多场景的性能调优。每个环节都有坑，但踩过之后回头看，这条路是通的，而且随着MTK NPU算力的提升和工具链的完善，端侧大模型的门槛会越来越低。