HarmonyOS端侧大模型部署：基于CANN LM Engine的量化

鸿蒙专家

在HDC 2026上，HarmonyOS正式进入Agent时代。针对隐私安全和无网场景下的零延迟响应需求，纯云端方案难以满足。本文以“情绪树洞”App为例，详解在HarmonyOS NEXT上利用CANN LM Engine将轻量级大模型（如Qwen2.5-1.5B）部署到Kirin X90本地NPU的完整流程，包括模型量化、ONNX导出、OMC转换以及NAPI异步工作流集成。

一、量化与模型转换流水线
CANN（Compute Architecture for Neural Networks）是华为端云一致的异构计算架构，其CANN LM Engine提供大模型推理加速方案。LLM Engine是大语言模型场景的具体实现，支持内存复用、KV Cache管理、Lora拓展等。

将1.5B模型塞入移动设备，核心是降低内存占用。CANN量化工具链（DDK_tools）支持16-4 bit group-linear量化，分三个阶段执行：

1. 权重量化：配置dataset.json（格式[{"text": "who you are?"}]），执行sh run.sh stage1。首次运行后生成dopt_config.json，需根据模型层类型修改量化策略。例如Qwen attention层采用4-bit生态量化：

2. "model.layers.0.self_attn.q_proj": {
3.   "type": "<class 'torch.nn.modules.linear.Linear'>",
4.   "quant_strategy": "Quant_act_weight_eco",
5.   "weight" : { "bit":4, "group_size": 64 },
6.   "input": { "bit": 16 },
7.   "output": { "bit": 16, "per_channel": true, "input_algo": "min_max" }
8. }

复制代码

修改后再次执行stage1，输出"weight quant done!!!"表示完成。

2. 激活量化：执行sh run.sh stage2，输出"quant done!!!"后生成trained.pth。

3. 量化参数提取：执行sh run.sh stage3，输出"build done!!!"后生成fake_quant_weight.pth和quant_params_file。

建议在PC上使用仿真验证量化精度：加载优化后的模型，加载trained.pth权重，设置量化状态并测试问答输出。

导出ONNX模型：进入npu_tuned_export目录，配置model_info_target.yaml指定model_arch为qwen2，运行export_model_single_qwen2.py生成NPU亲和化的ONNX文件。

转换为CANN模型（.omc）：使用omg工具结合量化参数，执行to_omc.sh，其中--dynamic_dims支持动态分档，--compress_conf导入量化系数。最终得到可直接放入HarmonyOS工程rawfile目录的.omc文件。

二、端侧集成：NAPI异步工作流
模型推理是耗时操作，若在ArkTS主线程同步调用会导致UI冻结。正确方案是通过C++ NAPI的AsyncWork机制将推理任务放到底层线程池。

CMakeLists配置：需要链接hiai_foundation（CANN Kit核心底座）、libace_napi.z.so、libhilog_ndk.z.so、librawfile.z.so及libneural_network_core.so。

核心代码逻辑：
- InitModelAndDevice：应用启动时执行，通过OH_NNCompilation_ConstructWithOfflineModelBuffer创建编译实例，遍历设备找到名称为"HIAI_F"的NPU，绑定并构建，生成执行器g_executor。
- ExecuteInference（工作线程）：构造输入Tensor（Token IDs、Attention Mask等），调用OH_NNExecutor_RunSync同步执行推理。由于运行在Worker线程池，阻塞不影响UI。输出Tensor后解码为字符串。
- CompleteInference（主线程回调）：将C++字符串转为JS字符串，通过napi_resolve_deferred解析Promise，唤醒ArkTS侧的await。

ArkTS侧使用@State和async/await实现响应式UI：

2. import llmEngine from 'libentry.so';
3. @Entry
4. @Component
5. struct EmotionDiaryPage {
6.   @State aiReply: string = "点击下方按钮倾诉心事...";
7.   @State isAnalyzing: boolean = false;
8.   build() {
9.     Column() {
10.       Text(this.aiReply).fontSize(18).padding(20);
11.       if (this.isAnalyzing) { LoadingProgress().width(50).height(50); }
12.       Button('发送心事：我今天真的好累...').onClick(async () => {
13.         this.isAnalyzing = true;
14.         this.aiReply = "模型思考中...";
15.         let result = await llmEngine.generateResponseAsync("我今天真的好累...");
16.         this.aiReply = result;
17.         this.isAnalyzing = false;
18.       })
19.     }
20.   }
21. }

复制代码

三、总结
借助CANN LM Engine的三段式量化工具和模型转换Pipeline，结合ArkTS与NAPI的高并发异步机制，可以在端侧实现物理级数据隔离和零延迟响应。这一方案为构建隐私安全、体验流畅的端侧Agent提供了完整技术路径。

热心网友2

这个技术分享非常详实，从量化到端侧集成的完整流程梳理得很清晰。特别是针对资源受限的移动设备，通过CANN工具链将1.5B模型压缩到4-bit并部署到NPU，确实解决了隐私和延迟的核心痛点。NAPI异步工作流的部分也很实用，对ArkTS开发者有直接参考价值。感谢分享！

热心网友2

感谢楼主的详细分享！这篇文章把HarmonyOS端侧大模型部署的完整链路梳理得非常清晰，尤其是三段式量化流程和NAPI异步集成部分，对正在尝试将模型落地到移动设备的开发者来说很有参考价值。 想请教一下，在实际测试中，Qwen2.5-1.5B经过4-bit量化后，在Kirin X90上的推理延迟和内存占用大概是什么水平？另外，动态分档（--dynamic_dims）在配置时有没有需要注意的踩坑点？期待进一步交流。

热心网友2

感谢楼主的详细分享！这个端侧大模型部署的流程整理得非常清晰，从量化到NAPI集成的每一步都有具体配置和代码示例，对于想尝试在HarmonyOS上跑本地推理的同学来说很有参考价值。 有几个点想请教一下：1.5B模型用4-bit量化后，在Kirin X90上的实际推理延迟和内存占用大概在什么水平？另外，“情绪树洞”这种对话场景下，端侧模型的回复质量跟云端版本相比差距明显吗？期待后续有更详细的性能数据或Demo展示。