Qwen模型部署到骁龙Hexagon NPU：从微调量化到QNN转换全流程

1. 为什么要在手机端折腾大模型推理把Qwen这类模型塞进手机里跑最早我是拒绝的。2023年那会儿试过用CPU硬扛7B模型结果就是手机烫得能煎蛋输出速度慢到像在用2G网络刷视频。后来换到GPU速度上来了但功耗依然感人打两局游戏的功夫电量就掉一大截。直到我开始认真研究骁龙芯片里的Hexagon NPU才发现这条路其实早就铺好了只是坑比较多文档散落在各个角落。这篇内容就是把我从Qwen模型微调、量化、转换到最终部署到骁龙Hexagon NPU的完整流程梳理一遍。涉及的核心关键词包括Qwen、骁龙Hexagon NPU、QNN、NPU、量化。适合谁看如果你手上有搭载骁龙8 Gen 2/Gen 3或者骁龙X Elite的设备想让大模型在本地跑起来又不想被CPU和GPU的功耗问题折磨那这篇就是写给你的。如果你只是想了解NPU部署的基本原理也能从中拿到可复现的步骤。先说清楚一个前提手机端部署大模型核心矛盾永远是内存带宽和功耗。NPU之所以值得折腾是因为它在处理矩阵乘加这类操作时能效比远超CPU和GPU。但代价是工具链复杂、算子支持有限、量化要求苛刻。下面我按实际操作的顺序从模型准备到最终跑通一步步拆开讲。2. 整体方案设计与技术选型考量2.1 为什么选Qwen而不是其他模型Qwen系列在开源社区里的生态算是比较完整的。我选它主要看中三点第一官方提供了不同参数规模的版本从0.5B到72B都有手机端部署通常选1.8B或4B这个量级参数量再大内存扛不住第二Qwen的tokenizer和模型结构相对规整没有太多花哨的自定义算子这对NPU部署很关键第三社区里已经有Qwen转ONNX再转QNN的案例虽然不完整但至少证明这条路走得通。对比过Llama和Phi系列Llama的算子兼容性在QNN上问题更多Phi虽然小但中文能力偏弱。Qwen在中文场景下的表现明显更稳尤其是Qwen2.5系列之后1.8B的模型在常识问答和简单代码生成上已经能用了。2.2 骁龙Hexagon NPU的能力边界骁龙8 Gen 3里的Hexagon NPU官方标称算力是45 TOPSINT8。这个数字看着漂亮但实际能跑什么模型、跑多快取决于几个硬约束内存带宽NPU和CPU/GPU共享LPDDR5X内存带宽大概在60-70 GB/s。大模型推理是典型的memory-bound任务权重加载速度直接决定token生成速度。算子支持QNN SDK对Transformer结构的支持在逐步完善但像RoPE旋转位置编码、KV Cache的动态更新这些早期版本需要手动拆解或替换。量化精度NPU对INT8支持最好INT4也能跑但精度损失需要评估。FP16在部分骁龙芯片上支持但功耗和带宽占用会翻倍。我实测下来1.8B的Qwen模型经过INT8量化后模型文件大概1.8GB左右推理时内存占用峰值在2.5GB上下。这个量级在12GB内存的手机上跑是安全的8GB内存的设备会有点紧张。2.3 工具链选型QNN还是ONNX Runtime高通官方主推的是QNN SDK它能把模型编译成NPU能执行的二进制。但QNN的模型转换链路比较长PyTorch → ONNX → QNN。每一步都可能出问题。另一条路是ONNX Runtime with QNN Execution Provider它允许你直接加载ONNX模型由Runtime自动切分哪些算子给NPU、哪些给CPU。这种方式上手快但性能不如纯QNN编译的版本因为算子切分和内存拷贝有额外开销。我的建议是如果你只是想快速验证效果用ONNX Runtime QNN EP如果要追求极致性能和功耗老老实实走QNN SDK的完整编译流程。下面我主要讲QNN这条线因为这才是真正发挥NPU能力的方式。3. 模型微调与量化实操细节3.1 LoRA微调让Qwen适应你的场景直接拿Qwen的预训练权重去部署也能用但如果你想让它干特定的事比如客服问答、代码补全或者特定领域的文本生成微调是绕不开的。全量微调1.8B模型需要至少24GB显存普通开发者没这个条件。LoRA是更现实的选择。LoRA的核心思路是在原始权重旁边挂两个低秩矩阵训练时只更新这两个小矩阵。以Qwen2.5-1.8B为例我用的配置是from peft import LoraConfig, get_peft_model lora_config LoraConfig( r8, lora_alpha16, target_modules[q_proj, k_proj, v_proj, o_proj], lora_dropout0.05, biasnone, task_typeCAUSAL_LM )r8是秩的大小这个值越大LoRA矩阵的表达能力越强但参数量也越多。1.8B模型用r8到r16就够了再大容易过拟合。target_modules选的是注意力层的四个投影矩阵这是最常见的做法。如果你想让模型学得更细可以把MLP层的gate_proj、up_proj、down_proj也加进去但训练时间会明显增加。训练数据我用的格式是Alpaca风格的JSON每条包含instruction、input、output三个字段。数据量不用太大500到1000条高质量样本就能看到明显效果。训练参数方面batch size设4gradient accumulation steps设8学习率2e-4跑3个epoch。在单张RTX 4090上1.8B模型的LoRA微调大概2小时能完成。注意LoRA微调后的权重是单独保存的部署前需要和原始模型合并。合并命令用peft库的merge_and_unload()就行合并后的模型结构和原始Qwen完全一致方便后续转换。3.2 量化从FP16到INT8的关键一步量化是NPU部署的核心环节。FP16的1.8B模型大概3.6GBINT8量化后直接砍半到1.8GB内存带宽压力小了一半推理速度也能提升30%到50%。但量化不是简单的数据类型转换它涉及到校准和精度补偿。我用的量化工具是llm-awq和auto-gptq两者各有优劣。AWQActivation-aware Weight Quantization在保护重要权重通道方面做得更好精度损失更小GPTQ的量化速度更快适合快速迭代。对于Qwen系列我推荐用AWQ因为它的per-channel scaling策略对中文token的激活值分布更友好。量化命令示例python -m awq.entry --model_path ./qwen2.5-1.8b-merged \ --w_bit 8 --q_group_size 128 \ --calib_data ./calib_data.json \ --output_path ./qwen2.5-1.8b-int8q_group_size设128是常见选择它决定了量化时每组权重的粒度。设得太小量化参数增多模型文件变大设得太大精度损失明显。128是在精度和体积之间比较平衡的值。校准数据很关键。我用的是从训练集里随机抽的128条样本覆盖了模型实际会遇到的输入分布。校准数据太少会导致量化后的模型在某些输入上表现异常太多则浪费时间。128到256条是比较合理的范围。量化完成后一定要做精度对比。我通常用困惑度Perplexity和实际生成样例来评估。INT8量化后的Qwen2.5-1.8B困惑度上升通常在0.1到0.3之间实际生成质量肉眼几乎看不出差异。但如果困惑度上升超过0.5就要检查校准数据是否覆盖了足够的场景。3.3 量化后的模型结构检查量化完的模型不能直接扔给QNN需要先转成ONNX格式再检查算子兼容性。这一步最容易出问题。import torch from transformers import AutoModelForCausalLM model AutoModelForCausalLM.from_pretrained(./qwen2.5-1.8b-int8) dummy_input torch.randint(0, 32000, (1, 128)) torch.onnx.export( model, dummy_input, qwen2.5-1.8b.onnx, opset_version17, input_names[input_ids, attention_mask], output_names[logits], dynamic_axes{ input_ids: {0: batch, 1: sequence}, attention_mask: {0: batch, 1: sequence}, logits: {0: batch, 1: sequence} } )导出ONNX时opset_version建议用17或更高因为QNN对高版本opset的支持更好。dynamic_axes必须设置否则模型只能处理固定长度的输入实际使用中完全没法用。导出完成后用onnxruntime加载模型跑一遍确认输出和PyTorch版本一致。然后重点检查ONNX图里有没有QNN不支持的算子。常见的坑包括RotaryEmbeddingQNN早期版本不支持需要手动拆解成Sin、Cos、Mul、Add等基础算子。DynamicQuantizeLinear如果量化时用了动态量化这个算子可能不被支持需要改成静态量化。LayerNormalization部分QNN版本对LayerNorm的epsilon参数有要求需要确认是否匹配。我一般用onnxruntime的get_available_providers()和session.get_providers()来确认QNN EP是否加载成功再用Netron可视化ONNX图逐个检查可疑算子。4. QNN转换与NPU部署全流程4.1 QNN SDK环境搭建QNN SDK的安装是个体力活。高通官网下载需要注册账号下载下来的包大概2GB左右。解压后设置环境变量export QNN_SDK_ROOT/path/to/qnn-sdk export PATH$QNN_SDK_ROOT/bin/x86_64-linux-clang:$PATH export LD_LIBRARY_PATH$QNN_SDK_ROOT/lib/x86_64-linux-clang:$LD_LIBRARY_PATH注意QNN SDK分x86和ARM两个版本。模型转换在x86主机上做最终部署到手机时需要ARM版本的库。两个版本都要下载别搞混了。环境搭好后用qnn-onnx-converter把ONNX转成QNN的模型文件qnn-onnx-converter \ --input_network qwen2.5-1.8b.onnx \ --output_path qwen2.5-1.8b.cpp \ --input_dim input_ids 1,128 \ --input_dim attention_mask 1,128 \ --out_node logits \ --quantization_overrides quant_overrides.jsonquant_overrides.json是量化覆盖文件用来指定哪些层用INT8、哪些层保持FP16。对于Qwen模型我通常把注意力层的q_proj和v_proj保持FP16因为这两个投影对精度更敏感其他层用INT8。这个策略能把精度损失控制在可接受范围内同时模型体积只增加10%左右。转换完成后会生成一个.cpp文件和一个.bin文件。.cpp文件里是模型结构的描述.bin是权重数据。接下来用qnn-model-lib-generator编译成共享库qnn-model-lib-generator \ -c qwen2.5-1.8b.cpp \ -b qwen2.5-1.8b.bin \ -o libqwen2.5-1.8b.so \ -t x86_64-linux-clang这一步会调用Clang编译器把模型编译成能在x86上跑的共享库。编译过程可能报错常见原因是算子不支持或维度不匹配。报错信息会指出具体是哪个算子回到ONNX图里修改后重新导出。4.2 在手机上加载和运行QNN模型x86上验证通过后把.so文件和QNN的ARM库一起推到手机上。Android设备上QNN库通常放在/vendor/lib64/或/data/local/tmp/下。我一般用adb push推到/data/local/tmp/qnn/然后设置LD_LIBRARY_PATH。加载模型的代码用C写核心逻辑是QnnBackend_registerOpPackage(); QnnDevice_create(); QnnContext_create(); QnnGraph_create(); QnnGraph_addNode(); QnnGraph_finalize(); QnnGraph_execute();每一步都有对应的错误码出错时用QnnBackend_getError查具体原因。我遇到最多的问题是QNN_GRAPH_ERROR_UNSUPPORTED_OP说明某个算子在当前NPU上不支持。解决办法是在ONNX阶段就把这个算子替换成等价的基础算子组合。推理时的输入输出用Qnn_Tensor_t结构体管理。输入是token IDs和attention mask输出是logits。注意NPU的输入输出内存需要对齐通常要求128字节对齐。不对齐会导致推理结果错误或者直接崩溃。4.3 性能实测与调优在骁龙8 Gen 3上跑Qwen2.5-1.8B INT8我实测的数据是指标数值首token延迟180-220ms后续token生成速度12-15 tokens/s推理功耗2.8-3.2W内存占用峰值2.3GB这个速度比CPU快3倍左右比GPU快1.5倍功耗只有GPU的60%。对于手机端对话场景12 tokens/s已经能用了基本感觉不到明显卡顿。调优的方向主要有两个一是调整KV Cache的管理策略减少重复计算二是优化内存布局让权重加载更连续。QNN提供了QnnContext_setConfig接口可以设置QNN_CONTEXT_CONFIG_OPTIMIZATION_LEVEL我一般设成QNN_CONTEXT_OPTIMIZATION_LEVEL_HIGH编译时间会长一些但推理速度能提升10%左右。5. 常见问题与排查技巧实录5.1 模型转换阶段的典型报错问题一ONNX导出时提示Unsupported operator: RotaryEmbedding这是Qwen模型转换最常见的坑。QNN的ONNX解析器不认识RotaryEmbedding这个复合算子。解决办法是在导出ONNX之前把模型里的RotaryEmbedding模块替换成手动实现的版本class ManualRotaryEmbedding(nn.Module): def forward(self, x, position_ids): # 手动计算sin和cos inv_freq 1.0 / (10000 ** (torch.arange(0, dim, 2) / dim)) freqs torch.outer(position_ids, inv_freq) emb torch.cat((freqs, freqs), dim-1) return x * emb.cos() rotate_half(x) * emb.sin()替换后重新导出ONNX图里就只有Sin、Cos、Mul、Add这些基础算子了。问题二量化后模型输出乱码这通常是校准数据的问题。校准数据如果只覆盖了英文中文输入的激活值分布就会偏离导致量化参数不准确。解决办法是校准数据里中英文比例至少1:1并且要包含实际使用场景的典型输入。我一般会从训练集里分层抽样确保各种类型的输入都有代表。问题三QNN编译时报QNN_GRAPH_ERROR_INVALID_TENSOR_DIM这是维度不匹配导致的。QNN对动态维度的支持有限如果ONNX里某个算子的输入维度是动态的QNN可能推断不出来。解决办法是在导出ONNX时尽量固定维度或者用--input_dim参数显式指定所有输入的形状。5.2 部署运行阶段的排查思路问题模型加载成功但推理结果全为0先检查输入数据是否正确。NPU对输入数据的类型和布局有严格要求比如INT8输入必须是int8类型不能是uint8。另外检查内存对齐QNN要求输入输出buffer按128字节对齐不对齐会导致数据读取错误。问题推理速度远低于预期用qnn-profile-viewer工具分析每一层的耗时。如果发现某一层特别慢可能是这个层被切到了CPU上执行。检查QNN日志里的QNN_OP_PACKAGE信息确认所有层都在NPU上。如果有层回退到CPU需要调整量化策略或替换算子。问题手机发热严重NPU虽然能效比高但持续满载运行还是会发热。我通常会在推理循环里加一个小的sleep比如每生成10个token休息5ms让NPU有机会降频。另外把KV Cache放在NPU的专用内存里减少和CPU之间的数据拷贝也能降低功耗。5.3 常见问题速查表问题现象可能原因排查方法解决方案ONNX导出失败不支持的算子查看报错信息中的算子名替换为等价基础算子量化后精度下降明显校准数据不匹配对比量化前后的困惑度增加校准数据多样性QNN编译报错维度不匹配检查ONNX图的输入维度固定维度或显式指定推理结果异常内存未对齐检查buffer地址按128字节对齐速度慢算子回退CPU查看QNN日志调整量化策略发热严重持续满载监控NPU频率加入推理间隔提示QNN SDK的版本更新比较频繁不同版本对算子的支持差异很大。建议锁定一个稳定版本不要频繁升级。我目前用的是2.24版本对Transformer结构的支持比较完善。6. 个人实操体会与后续扩展方向这套流程走下来最深的体会是手机端NPU部署大模型难点不在模型本身而在工具链的成熟度。QNN SDK的文档比较零散很多问题需要靠日志和实验来定位。但一旦跑通收益是明显的——功耗和速度的平衡是CPU和GPU方案给不了的。后续如果想进一步优化有两个方向值得尝试。一是用QNN的混合精度模式把部分层保持FP16在精度和速度之间找更好的平衡点。二是探索多模型并行比如把Qwen和一个小型的embedding模型同时部署到NPU上利用NPU的多核并行能力。不过这些都需要对QNN的底层接口有更深入的了解我目前还在摸索阶段。另外提醒一句不同骁龙芯片的NPU架构差异不小。骁龙8 Gen 2和Gen 3的Hexagon NPU在算子支持和内存布局上就有区别8 Gen 3的NPU对Transformer结构的优化更好。如果你用的是更早的芯片可能需要额外处理一些兼容性问题。