一、前言思考

1.1 为什么端侧 AI 是鸿蒙的"必答题"

传统 AI 能力几乎全部依赖云端：App 把图片、语音、文本上传到服务器，推理完成后回传结果。这个模式有三个致命问题：

• 隐私风险：用户照片、录音、聊天记录都要离开设备，一旦服务端被拖库就是灾难；
• 网络依赖：地铁、电梯、飞机上没网，AI 功能直接不可用；
• 成本失控：海量用户并发推理，GPU 成本随用户规模线性增长。

HarmonyOS 6.1.0 把 AI 能力下沉到端侧，通过 NPU 推理引擎 + 模型管理服务 + 意图框架 三位一体架构，让智能能力"不出设备"即可完成。

1.2 端云协同才是终局

端侧 AI 不是要取代云端，而是分层协作：

维度	端侧	云端
延迟	毫秒级（无网络开销）	百毫秒级 + 网络 RTT
隐私	数据不出设备	数据需脱敏上传
可用性	离线可用	依赖网络
模型规模	小模型（量化后 ≤ 200MB）	大模型（数 GB ~ 数百 GB）
典型任务	唤醒词、OCR、分类、检测	对话生成、语义理解、长文本

设计原则：能端侧就端侧，端侧不够再上云。

1.3 本文结构

围绕"NPU 调度 → 模型管理 → 意图框架"三条主线，先讲底层原理，再讲工程落地，最后给出调优清单。

二、底层原理

2.1 端侧 AI 三位一体架构

┌─────────────────────────────────────────────────┐
│                  应用层 (App)                     │
│  拍照翻译 │ 语音助手 │ 智慧推荐 │ 文档扫描         │
└──────────────────────┬──────────────────────────┘
┌──────────────────────▼──────────────────────────┐
│              意图框架 IntentKit                   │
│  意图解析 → 场景识别 → 服务匹配 → 能力编排         │
└──────────────────────┬──────────────────────────┘
┌──────────────────────▼──────────────────────────┐
│              模型管理服务 ModelManager            │
│  模型安装/卸载 │ 版本管理 │ 内存驻留 │ 资源配额    │
└──────────────────────┬──────────────────────────┘
┌──────────────────────▼──────────────────────────┐
│          NPU 推理引擎 (HiAI Foundation)          │
│  算子图优化 │ NPU/CPU 异构调度 │ 内存复用 │ 量化  │
└──────────────────────┬──────────────────────────┘
┌──────────────────────▼──────────────────────────┐
│              硬件层: NPU / GPU / CPU             │
└─────────────────────────────────────────────────┘

四层职责清晰：硬件层提供算力，NPU 推理引擎把模型算子映射到算力，模型管理服务负责模型生命周期，意图框架把 AI 能力暴露给业务。

2.2 NPU 推理引擎：为什么比 CPU 快

NPU（神经网络处理单元）针对矩阵乘法和卷积做了硬件级优化：

维度	CPU	NPU
计算模式	通用标量指令	专用矩阵 MAC 阵列
数据精度	FP32 为主	FP16 / INT8 原生支持
能效比	1×	10~50×
典型延迟（MobileNet）	~50ms	~5ms

NPU 推理引擎的工作流：

输入张量 → 算子调度(图优化) → 算子编译(NPU指令) → 内存规划 → 硬件执行 → 输出张量
                │                                    │
                └─ 无法 NPU 化的算子回退 CPU 执行 ─────┘

关键点：图优化阶段会把 Conv + BN + ReLU 融合成一个算子，减少内存读写；异构调度让不支持的算子（如某些动态形状算子）自动回退 CPU，保证正确性优先。

2.3 模型管理服务：AI 能力的"应用商店"

模型管理服务解决三个工程问题：

• 模型从哪来：随应用分发（打进 HAP）或动态下载（OTA 更新）；
• 模型怎么活着：内存驻留管理、冷热加载、引用计数；
• 模型何时卸载：应用退出、内存压力、长期未用。

核心状态机：

未安装 ──下载/安装──▶ 已安装 ──加载──▶ 已加载(驻留NPU内存)
  ▲                    │                │
  └────卸载────────────┴──释放───◀──────┘

2.4 意图框架：从"能力 API"到"意图即服务"

传统 API 是"人找能力"：开发者调用 textRecognition()、faceDetect()。意图框架升级为"能力找人"：

用户行为/上下文 → 意图识别(Intent) → 服务匹配(Service) → 能力执行 → 结果反馈

三、实战落地

3.1 NPU 推理引擎接入（MindSpore Lite）

import { mindSporeLite } from '@kit.MindSporeLite';

// 1. 加载模型（同步加载到 NPU 内存池）
let context: mindSporeLite.Context = new mindSporeLite.Context();
context.arch = mindSporeLite.ARCH_TYPE.NPU;  // 优先 NPU
context.deviceList = [mindSporeLite.DeviceType.NPU, mindSporeLite.DeviceType.CPU];

let model: mindSporeLite.Model = new mindSporeLite.Model();
// 2. 编译模型
model.loadModelFromFile({ context: context, modelPath: '/data/app/el1/mobilenet.ms' });

// 3. 构造输入
let input: mindSporeLite.MSTensor = model.getInputs()[0];
// ... 把图像数据填充进 input

// 4. 推理
const outputs = model.predict([input]);

// 5. 解析 top5 结果
let probs = outputs[0].getData();

3.2 模型管理：动态下载 + 版本切换

import { modelManager } from '@kit.AiKit';

// 检查本地模型版本
let localVersion = modelManager.getModelVersion('com.demo.ocr');
// 服务端下发最新版本号
let remoteVersion = fetchVersionFromServer();

if (localVersion !== remoteVersion) {
  // 增量下载并热切换
  modelManager.installModel({
    modelId: 'com.demo.ocr',
    version: remoteVersion,
    url: 'https://cdn.demo.com/models/ocr_v2.diff'
  });
}

// 推理时指定版本
modelManager.runWithModel('com.demo.ocr', { version: remoteVersion }, inputData);

3.3 意图框架：声明一个端侧意图能力

// 在应用配置中声明可提供的端侧能力
export default {
  // 意图注册：识别到"扫描文档"意图时回调本应用
  intents: [{
    action: 'action.scan.document',
    describe: '文档扫描',
    input: 'image',
    output: 'pdf'
  }]
};

四、性能排查与优化

排查点	手段	优化方向
推理延迟高	HiTrace 打点耗时	图优化、量化 INT8、算子融合
NPU 利用率低	NPU Profiler	检查算子是否回退 CPU、批处理
内存占用高	SmartPerf 内存快照	模型驻留策略、输入复用、输出流式
模型加载慢	启动链路分析	冷启动异步预加载、模型预热
意图识别不准	意图命中率统计	补充样本、调整场景优先级

4.1 典型问题：NPU 没吃满

现象：MobileNet 在 NPU 上只比 CPU 快 3 倍（理论 10 倍）。
根因：模型里有 20% 算子（如 resize）NPU 不支持，回退 CPU 导致数据反复拷贝。

解法：

1. 用 mindSporeLite 的转换工具把模型转成含融合算子的 .ms 格式；
2. 检查 context.arch = NPU 是否被显式指定；
3. 对回退算子做"图内融合"，把 resize 提到预处理阶段（用 CPU 预处理，不进推理图）。

4.2 模型驻留策略

场景	策略
高频使用（OCR/分类）	常驻 NPU 内存，App 生命周期内不卸载
中频使用（语音识别）	懒加载 + LRU 驻留，30 分钟未用释放
低频使用（大模型）	用完即释放，每次按需加载

五、总结

1. 端侧 AI 的三大支柱：NPU 推理引擎（算力底座）、模型管理服务（生命周期）、意图框架（能力编排），三者缺一不可。
2. NPU 不是万能的：算子回退、内存拷贝、图优化质量直接决定真实加速比。
3. 模型管理是工程化关键：版本、驻留、热切换决定了 AI 功能能否持续迭代。
4. 意图框架让 AI 能力从"API 调用"升级为"服务编排"，是鸿蒙 AI 生态的差异化优势。

一句话记住：算力在 NPU，生命在 ModelManager，入口在 IntentKit。

---

🚀 演示功能优化（随项目同步更新）

本文对应的 ArkTS 演示页面已随项目整体优化，主要改进：

1. 独立主题风格：深空霓虹紫 · 发光卡片，与其余章节演示页明显区分，不再千篇一律。
2. 步骤回放动画：点击演示按钮后，结果行按 260~320ms/步 逐步展示，模拟真实推理过程。
3. 运行态保护：演示过程中按钮置灰防重复触发，页面退出自动清理定时器。
4. 结果摘要：演示结束后自动给出「一句话结论」，并 Toast 提示完成。
5. AI 对话演示：新增 AiChatDemo（根目录 main.py 的 ArkTS 移植），真实 SSE 流式大模型请求，首页「★ AI Chat 流式对话演示」可进入。

对应页面：entry/src/main/ets/pages/AiCoreDemo.ets

---

🧪 演示优化：真实 AI 推理接入（v3）

本演示页顶部新增 AI 云端推理主卡，点击即真实调用云端大模型（SSE 流式），不再是纯模拟回放：

• 请求链路：utils/AiClient.ets（ArkTS 封装 OpenAI 兼容接口）→ POST https://api-ai.gitcode.com/v1/chat/completions，模型 deepseek-ai/DeepSeek-V4-Flash，流式 stream: true
• 演示场景：图像分类 Top-K / 目标检测 / OCR 文字识别 / 人脸识别+活体 —— 每个场景绑定不同专家 System Prompt，返回内容各有差异
• 交互体验：进入页面自动触发一次真实推理；点场景标签切换并重新请求；按钮手动触发；输出区打字机流式展示
• 真实标识：卡片右上角 LIVE 徽标 + 端点/模型名水印，保证"所见即所调"