鸿蒙生态的设备形态覆盖手机、平板、车机、穿戴、智慧屏乃至 IoT 传感器——一端跑大模型不现实，纯云端又扛不住离线场景。团队在鸿蒙端做 AI 功能前，第一件该做的事不是选模型，而是定架构范式。本文把三种主流范式拆开，附框架级对比表，帮你避开最常见的坑。
一、三种基础范式：一张图看清边界
鸿蒙端 AI 应用的架构决策，本质上是在「算力在哪里执行推理」和「模型如何管理」两个轴上做取舍。目前可行的范式有三类：
- 纯端侧推理——模型直接跑在设备上，零网络依赖。典型场景：实时 OCR、人脸核验、语音唤醒。
- 云侧协同——端侧采集输入，云端执行推理，结果回传。典型场景：复杂 NLP 对话、大模型问答、图像生成。
- 混合架构——端侧做预处理 + 轻量推理，云端做重计算，中间有降级策略。典型场景：智能相册搜索（端侧向量化 + 云端语义匹配）、语音助手（端侧唤醒 + 云端 NLU）。
选哪种，取决于你的业务对延迟、隐私、成本和离线可用性的权重分配。下面展开讲。关于鸿蒙端 AI 的具体落地案例（包括 Agent 架构在车机和穿戴设备上的实践），可参见我们对 HDC 2026 现场两家企业鸿蒙 Agent 落地拆解 的分析。
二、端侧推理框架对比
如果你确认至少一部分推理要在端侧完成，接下来会面对框架选型。鸿蒙端目前三条主流路径：
| 维度 | MindSpore Lite | HiAI Foundation | 第三方引擎 (ONNX Runtime / ncnn) |
|---|---|---|---|
| 模型格式 | MindIR（原生）；支持 ONNX / TF Lite 转换 | 华为私有格式（需通过 HiAI IDE 转换） | ONNX / 自有格式 |
| 硬件加速 | NPU（昇腾）、CPU、GPU 异构调度 | NPU 优先，深度绑定麒麟/昇腾 | CPU 为主，NPU 需 NAPI 桥接 |
| 鸿蒙集成方式 | ArkTS 通过 NAPI 调用 C/C++ 推理库 | Java/ArkTS SDK 直调 | NAPI 封装 C++ 推理引擎 |
| 模型管理 | 随应用打包或动态下发 | 随应用打包；模型需预注册 | 自行管理版本与分发 |
| 成熟度 | 华为主力维护，配套工具链完整 | 功能聚焦、接口简洁 | 社区依赖，适配成本需自行消化 |
| 适用场景 | CV / NLP / 推荐等通用端侧推理 | 图像超分、视频增强等算子级加速 | 跨平台迁移需求、已有 ONNX 模型资产 |
MindSpore Lite 是目前官方投入最大的端侧推理方案，工具链覆盖模型转换、量化、性能调优全流程。HiAI Foundation 则更适合对特定硬件算子有极致性能要求的场景——代价是可移植性差。第三方引擎的优势在跨平台一致性，如果你的模型需要在 iOS / Android / 鸿蒙三端跑，ONNX Runtime + NAPI 封装可以最大化复用。对跨平台 AI 工具链选型有进一步兴趣，可以看 跨平台 AICoding 选型：三类方案对比与落地决策。
三、架构决策的关键维度
抛开框架细节，从架构视角看，以下四个维度的权重排序直接决定方案：
3.1 延迟敏感度
低于 50ms 的交互（如相机实时滤镜、语音端点检测）必须走端侧推理。云端往返 RTT 在 4G 下轻松破 100ms，5G 也做不到端侧的确定性延迟。
3.2 隐私与合规
金融、政务、医疗等场景中，用户数据不允许离开设备。鸿蒙系统级安全能力（如关键资产存储）可以与端侧推理配合，在设备内闭环处理敏感数据。此时纯端侧范式几乎是唯一选择。
3.3 模型体积与更新频率
端侧模型的体积直接影响应用包大小和首次加载体验。鸿蒙应用包（HAP）对体积敏感，超过一定阈值会影响下载转化。如果模型需要按周迭代（如推荐模型），纯端侧方案的持续部署成本会显著上升——此时混合架构中「端侧跑固定特征提取 + 云端跑可变模型」是更务实的路径。
3.4 离线场景覆盖率
车机、智能家居、户外巡检等场景中，网络不可达是常态。架构设计阶段就必须明确：无网络时功能降级到什么程度？是完全不可用，还是保留核心能力？这决定了端侧模型的容量下限。
四、混合架构的工程落地要点
混合架构听起来美好，但工程上最容易踩坑的是端云模型一致性和降级策略。我们在 企业 AI 应用鸿蒙端落地实践 中记录了多个真实项目的架构演进过程，这里提炼几个通用要点：
- NAPI 桥接开销：ArkTS 调用 C/C++ 推理库需要经过 NAPI 层，频繁的跨语言调用会引入额外延迟。推荐做法是批量传参，减少调用次数。
- 模型版本管理：端侧模型与云侧模型必须保证同版本兼容——端侧输出的特征向量维度一旦改变，云端推理结果会直接错误。建议在推理请求中附带端侧模型版本号，云端做版本校验。
- 降级策略：网络超时后，不能简单地让功能报错。需要预设「离线模式」——例如端侧跑一个精度稍低的模型，或返回缓存推理结果并标注置信度。
- 模型下发机制：避免在应用启动时全量下载模型。利用鸿蒙的按需分发能力，首次使用时异步拉取，同时展示占位 UI。
五、常见问题
问：HarmonyOS NEXT 对 AI 开发有哪些关键变化？
HarmonyOS NEXT 去除了 AOSP 兼容层，不再支持 Android 生态的 AI 框架（如 TFLite 直接调用）。所有端侧推理必须通过原生 ArkTS / NAPI 路径接入，这对已有 Android AI 资产的团队意味着额外的迁移成本。但华为在 NEXT 上强化了 MindSpore Lite 与系统的整合深度，NPU 调度效率有明显提升。详细能力清单参见华为开发者文档 - AI 能力概述。
问：模型转换 MindIR 格式有什么坑？
从 PyTorch/TensorFlow 转 MindIR 时，算子兼容性是最大的拦路虎。不是所有算子都有 MindSpore Lite 的等价实现，尤其是一些自定义算子或较新的 attention 变体。建议在选型阶段先跑一遍 MindSpore 的模型转换工具链，确认核心算子可转换后再锁定方案。
问：纯端侧推理适合跑多大模型？
受限于移动端 NPU/CPU 算力和内存，当前主流方案中，端侧可稳定运行的模型参数量通常在 100M~2B 之间（量化后）。具体上限取决于目标设备档次——旗舰机 NPU 可跑到 4-7B 量化模型，中低端设备则建议控制在 500M 以内。
问：如何评估 NPU 加速的实际收益？
不要只看厂商标称的 TOPS。用你自己的模型跑一遍端到端延迟测试：在目标设备（尤其是中低端机型）上，对比 CPU 推理、NPU 推理和 CPU+NPU 异构调度的实际耗时。不少场景中 NPU 调度开销抵消了算力优势——小模型跑 CPU 反而更快。
六、决策框架：三问定方案
总结一个可操作的决策流：
- 能不能离线？ 必须离线 → 纯端侧；可以联网 → 进入第 2 问。
- 模型是否频繁更新？ 周级迭代 → 混合架构（端侧固定特征 + 云端可变模型）；月级或更慢 → 纯端侧也可行。
- 是否有跨平台需求？ 需要同时跑 iOS/Android → 优先 ONNX Runtime + NAPI；仅鸿蒙 → MindSpore Lite 或 HiAI 按场景选。
没有「最佳方案」，只有当前约束下代价最小的方案。在鸿蒙端做 AI，比选框架更重要的，是先把这四个问题在团队内部对齐。如果你正在评估鸿蒙端 AI 编程工具链的整体选型，鸿蒙端 AI 编程选型：CodeGenie vs 通用工具 这篇也提供了互补视角。