鸿蒙应用开发这两年最明显的变化就是“端侧智能”从一个宣传词变成了真需求。以前做 HarmonyOS 应用大家关心的是分布式软总线、原子化服务、卡片这些能力现在越来越多的项目在立项阶段就会问一句能不能在设备本地跑一个开源大模型把对话、摘要、意图识别这类能力做进去而不是所有请求都往云端丢。这个问题的答案不是简单的“能”或“不能”而是一连串工程决策的叠加——模型选多大、推理框架怎么选、ArkTS 侧怎么调用、内存和发热怎么控、离线体验和联网兜底怎么平衡。这篇内容就是围绕 HarmonyOS NEXT 接入开源大模型这条链路把我在实际项目里反复权衡过的 5 个工程决策拆开讲清楚适合已经在做鸿蒙应用、准备把大模型能力落到端侧的开发者参考也适合刚接触 ArkTS、想搞清楚端侧推理到底怎么落地的人。1. 先想清楚端侧大模型到底要解决什么问题1.1 端侧推理不是“把云端模型搬下来”很多人第一次接触端侧大模型直觉就是把云端那套模型直接下载到设备上跑。这个思路在工程上几乎必然翻车。云端模型动辄几十 GB推理时依赖高带宽显存和并行计算而手机、平板、车机这类设备的可用内存、持续算力和散热预算都是有限的。端侧大模型真正要解决的不是“复刻云端能力”而是在受限资源下提供低延迟、可离线、隐私不出端的局部智能。我在一个会议记录类应用里做过对比同样一段 300 字的会议纪要云端大模型接口往返加排队大约 1.2 到 2 秒端侧 1.5B 量化模型首次加载后单次推理约 800 毫秒到 1.5 秒虽然绝对速度不一定赢但胜在断网可用、内容不出设备。这个差异决定了端侧模型的定位——它更像一个“常驻的轻量助手”而不是“万能的知识库”。所以第一个工程决策不是选哪个模型而是先明确端侧要承担哪些任务。常见可落地的场景包括意图识别与指令解析把用户自然语言转成结构化动作比如“把这条消息标记为待办”。文本摘要与改写对本地笔记、聊天记录做压缩和润色。离线问答基于本地知识库做检索增强回答设备使用类问题。多模态轻量任务图像分类、简单 OCR 后处理等通常配合专用小模型而非通用大模型。把这些任务列清楚之后你会发现很多需求其实不需要 7B 以上的模型1B 到 3B 的量化模型就能覆盖大部分场景。这一步想不清楚后面选型一定摇摆。1.2 端侧和云端的边界应该画在哪里我见过两种极端做法。一种是全部放端侧结果模型太大、体验卡顿另一种是全部走云端端侧只做 UI结果离线场景直接不可用。比较稳妥的边界画法是按“任务敏感度”和“算力需求”两个维度切分。任务类型建议位置理由隐私敏感文本处理端侧内容不出设备合规压力小高频短指令解析端侧延迟低省流量复杂长文本生成云端端侧算力和内存吃紧需要最新知识的问答云端端侧模型知识截止且更新成本高离线兜底对话端侧无网可用是核心卖点这张表不是标准答案但它能帮你在评审会上快速说清楚“为什么这个功能放端侧”。我个人的经验是端侧优先承接高频、短输入、隐私敏感的任务云端承接低频、长输出、知识密集的任务两者用统一的接口抽象层隔开后续替换模型或调整边界时改动最小。1.3 为什么“能不能跑”不是第一个问题新手最容易陷入的误区是先问“这个模型能不能在鸿蒙上跑”。能跑只是最低门槛真正决定项目成败的是跑起来之后体验是否可接受。一个 3B 模型在旗舰机上能跑在中端机上可能加载就要十几秒推理时手机发烫、掉帧用户直接卸载。所以我在做技术预研时第一件事不是跑通 Demo而是定义验收指标冷启动加载时间不超过多少秒单次推理首 token 延迟上限连续推理 10 次后的内存增长是否可控设备表面温度上升是否在可接受范围断网状态下功能是否完整。这些指标定下来后面的模型选型、量化方案、线程调度才有判断依据。没有指标的技术预研最后往往变成“Demo 很惊艳上线很灾难”。2. 模型选型参数量、量化格式与鸿蒙设备算力的匹配2.1 参数量不是越大越好要看设备内存天花板端侧模型选型的第一约束是内存。模型加载后占用的内存大致由三部分组成权重、KV Cache、运行时开销。以常见的 1.5B 模型为例FP16 权重约 3GBINT8 量化后约 1.5GBINT4 量化后约 0.8GB。再加上 KV Cache 和推理框架本身的开销实际占用还要往上浮。鸿蒙设备的内存规格跨度很大旗舰手机 12GB 到 16GB 比较常见中端机 8GB 居多车机和部分 IoT 设备可能只有 4GB 甚至更低。我的经验做法是8GB 及以上设备可以尝试 1.5B 到 3B 的 INT4 量化模型但要留足系统和其他应用的内存。6GB 到 8GB 设备优先 1B 以下模型或者把模型做成按需加载、用完释放。4GB 及以下设备建议只做云端调用端侧最多放一个极小的意图分类模型。这里有个容易被忽略的点鸿蒙的应用沙箱对单进程内存是有限制的模型加载过大可能直接触发 OOM 被杀。所以选型时不能只看设备总内存还要看应用可用的内存预算。我一般会在真机上用内存分析工具跑一遍确认峰值占用在安全线以内再继续。2.2 量化格式怎么选INT8、INT4 还是混合量化量化是端侧大模型绕不开的一步。它的本质是用更低的数值精度表示权重换取更小的体积和更快的推理速度代价是精度损失。常见选项有 INT8、INT4以及针对部分层保留高精度的混合量化。INT8 的精度损失通常很小多数任务上几乎感知不到体积是 FP16 的一半。INT4 体积进一步减半但精度损失开始明显尤其是对生成质量要求高的任务可能出现重复、跑题、格式错乱。混合量化则是对敏感层比如注意力输出层保留 INT8其余用 INT4在体积和精度之间找平衡。我的实操建议是如果任务是分类、意图识别这类判别式任务INT4 通常够用优先换体积和速度。如果任务是文本生成、摘要优先 INT8或者混合量化别一上来就 INT4。量化后一定要做任务级评测不能只看困惑度指标。我遇到过 INT4 模型困惑度只涨了一点但生成 JSON 格式时错误率翻倍的情况。量化工具链方面主流做法是先在桌面端完成量化导出成端侧推理框架支持的格式再集成到鸿蒙工程里。量化过程本身不建议在设备上做太耗资源。2.3 开源模型和鸿蒙生态的适配成本选开源模型时除了看参数量和量化支持还要看它的算子兼容性。端侧推理框架对算子的支持是有限的某些模型用了特殊激活函数或自定义算子转换时可能失败或者退化成低效实现。我在选型时会优先考虑结构规整、社区端侧部署案例多的模型系列这样遇到问题更容易找到参考。另外要注意模型的许可证。商用项目要确认许可证允许商用和再分发尤其是量化后的权重文件。这一步经常被拖到后期才处理结果发现不能用返工成本很高。考量维度优先选择需要谨慎参数量1B 到 3B7B 以上量化支持官方或社区有 INT8/INT4 方案只有 FP16算子兼容结构规整、案例多自定义算子多许可证明确允许商用限制再分发社区活跃度文档和 issue 丰富长期无人维护这张表可以当作选型 checklist逐项打分后再决定。别只看模型榜单排名端侧部署的坑大多不在模型效果上而在工程适配上。3. 推理框架与 ArkTS 调用链路的工程取舍3.1 端侧推理框架的几种路线鸿蒙端侧跑大模型推理框架的选择直接决定开发量和性能上限。目前常见的路线有几类一类是通用的端侧推理引擎支持多种模型格式跨平台能力好一类是面向特定硬件优化的推理库性能强但绑定硬件还有一类是直接把推理逻辑用 Native 代码实现通过 NAPI 暴露给 ArkTS。通用推理引擎的优点是生态成熟、文档多、模型转换工具链完整适合快速验证。缺点是针对鸿蒙特定芯片的优化可能不够深入性能榨不干。硬件优化库性能好但适配成本高换设备可能要重做。Native 自研灵活度最高但开发和维护成本也最高一般团队不建议走这条路。我的建议是预研阶段用通用推理引擎快速跑通验证体验指标量产阶段再评估是否需要针对主力机型做硬件优化。一上来就追求极致性能很容易在适配阶段耗尽时间。3.2 ArkTS 与 Native 的边界怎么划ArkTS 是鸿蒙应用的主力开发语言但大模型推理这种计算密集型任务不适合放在 ArkTS 层做。合理的做法是把推理放在 Native 层C/C通过 NAPI 暴露少量接口给 ArkTS 调用。这样做的理由有三点性能Native 层可以直接管理内存和线程避免 ArkTS 运行时的额外开销。复用推理框架大多是 C/C 实现Native 集成最自然。隔离推理崩溃不会直接拖垮 UI 线程便于做降级处理。接口设计上要尽量粗粒度避免频繁跨语言调用。比如不要每生成一个 token 就回调一次 ArkTS而是攒一批再回传或者用回调加缓冲的方式。跨语言调用本身有开销高频调用会明显拖慢推理。一个典型的调用链路是这样的ArkTS 侧收集用户输入做预处理后调用 NAPI 接口Native 侧加载模型、执行推理把结果写回缓冲区ArkTS 侧读取结果并渲染。中间的状态管理、错误码传递要提前约定好否则调试时很难定位问题。3.3 线程模型与 UI 流畅度的平衡大模型推理是长耗时任务如果放在主线程UI 必然卡死。鸿蒙提供了多线程能力可以把推理放到独立线程或线程池里执行。但线程不是越多越好推理本身会吃满 CPU开太多线程反而增加调度开销和发热。我的做法是推理固定用一个工作线程UI 线程只负责交互和渲染。如果同时有多个推理请求用队列串行处理避免并发抢资源。对于流式输出场景Native 侧生成 token 后通过事件机制通知 ArkTS 更新 UI更新频率要节流比如每 50 毫秒或每积累几个 token 刷新一次否则频繁刷新也会导致掉帧。还有一个细节是推理优先级。当应用切到后台时应该暂停或降低推理频率把资源让给前台应用。鸿蒙的生命周期回调里可以处理这个逻辑别让后台推理把设备电量悄悄耗光。4. 内存、发热与耗电端侧推理的体验红线4.1 内存峰值控制的几个手段端侧推理最怕的就是内存峰值超标导致应用被杀。控制内存的手段主要有几个模型量化减小权重体积、按需加载减少常驻内存、及时释放 KV Cache、限制并发推理数量。按需加载是个很实用的策略。如果模型只在特定页面使用就不要在应用启动时就加载而是进入页面时加载、离开页面时释放。代价是每次进入都要重新加载所以要在加载速度和内存占用之间权衡。我的经验是如果加载时间超过 3 秒用户会明显感知这时候可以考虑常驻但用低优先级内存或者做预加载。KV Cache 是另一个内存大户尤其是长上下文场景。要设置合理的上下文长度上限超出部分做截断或摘要别让 Cache 无限增长。推理结束后及时释放不要留着占内存。4.2 发热和降频的现实处理持续推理会让设备发热发热到一定程度系统会降频推理速度随之下降形成恶性循环。这个问题没有银弹只能通过策略缓解限制单次推理时长长任务拆成多段中间让设备喘口气。动态调整模型精度高温时切换到更小的模型或更低精度。监听温度状态鸿蒙提供了设备状态相关的能力可以在温度过高时暂停推理并提示用户。避免后台推理后台推理既耗电又发热收益还低。我在实测中发现连续推理 5 到 10 次后中端机就会出现明显发热推理延迟上升 30% 以上。所以产品设计上要避免让用户连续触发大量推理比如加个节流提示或者把批量任务放到充电时执行。4.3 耗电优化与用户预期管理端侧推理的耗电是用户能直接感知的。如果应用在后台偷偷跑模型用户看到电量曲线陡降评价一定不好。优化方向包括减少不必要的推理、合并请求、用缓存避免重复计算、在充电或 Wi-Fi 环境下才执行重任务。同时要做好用户预期管理。端侧模型能力有限回答质量不如云端是正常的产品文案上不要过度承诺。可以在设置里提供“优先端侧”和“优先云端”的选项让用户自己权衡隐私、速度和效果。体验维度常见问题缓解策略内存峰值超标被杀量化、按需加载、限制并发发热持续推理降频分段执行、动态降精度、温度监听耗电后台推理耗电快避免后台推理、合并请求、缓存结果延迟首 token 慢预加载、流式输出、节流刷新这张表建议在测试阶段逐项验证别等上线后靠用户反馈来发现问题。5. 离线能力、模型更新与上线后的持续运营5.1 离线兜底与联网增强怎么配合端侧大模型最大的卖点之一是离线可用但离线能力不等于完全不要网络。合理的架构是端侧兜底、云端增强无网或弱网时走端侧模型保证基础功能可用有网时根据任务类型决定走端侧还是云端兼顾效果和成本。实现上需要一个统一的路由层根据网络状态、任务类型、用户设置来决定调用哪一侧。路由逻辑要可配置方便后续调整策略而不用发版。比如新模型上线后可以把更多任务切到端侧减少云端调用成本。这里有个容易踩的坑端侧和云端的输出格式要统一否则上层业务代码要写两套解析逻辑。建议在路由层做一次归一化把两侧结果转成统一结构再返回给业务层。5.2 模型更新的工程方案端侧模型不可能一成不变后续会有新版本、新量化方案、新能力。模型文件通常比较大更新方案要考虑下载、校验、替换、回滚几个环节。我的做法是模型文件放在独立的资源目录用版本号管理更新时先下载到临时目录校验完整性后再替换替换失败要能回滚到旧版本下载过程支持断点续传避免大文件下载中断后重来。鸿蒙的网络和文件能力可以支撑这套流程但要注意存储空间检查别把用户设备塞满。另外模型更新要和推理框架版本兼容。框架升级后旧模型格式可能不兼容所以更新策略里要包含兼容性检查必要时提示用户更新应用。5.3 上线后的效果监控与迭代端侧模型上线后效果监控比云端更难因为数据不出端不能直接把用户输入上传分析。可行的做法是采集脱敏后的指标比如推理耗时、成功率、崩溃率、内存峰值、用户主动重试率通过这些间接指标判断模型表现。如果发现某类任务效果差可以在后续版本里调整模型或路由策略。用户反馈也是重要来源可以在应用内提供反馈入口让用户主动上报问题。注意隐私合规任何数据采集都要明确告知并获得同意。迭代节奏上端侧模型更新不宜太频繁因为每次更新都要下载大文件用户流量和存储成本高。建议按季度或半年做一次大版本更新中间用小版本修 bug。6. 几个我在实际项目里踩过的坑6.1 模型转换成功不等于推理正确有一次模型转换工具报告成功但推理结果全是乱码。排查后发现是量化时的校准数据分布和实际输入差异太大导致部分层数值溢出。这类问题不会在转换阶段报错只有实际推理才暴露。所以转换后一定要用真实场景的输入做验证别只看工具的成功提示。6.2 跨语言调用的错误码丢失NAPI 调用出错时如果错误码没有正确传递到 ArkTS 侧上层只能看到一个笼统的失败排查非常困难。后来我们约定了一套错误码规范Native 侧每个失败路径都返回明确错误码ArkTS 侧统一处理并记录日志定位效率提升很多。6.3 忽略设备差异导致中端机翻车预研时用旗舰机跑得很顺上线后中端机用户反馈卡顿、发热。原因是旗舰机内存和算力充裕掩盖了模型过大的问题。后来我们按设备档位做了分级策略高端机用大模型中端机用小模型低端机走云端体验才稳定下来。6.4 上下文长度设置过长拖垮性能为了支持长对话一开始把上下文长度设得很大结果 KV Cache 占用飙升推理速度断崖式下降。后来改成滑动窗口加摘要的方式只保留最近若干轮对话和一份历史摘要内存和速度都回到可接受范围。7. 给准备入场的团队的一点个人体会端侧大模型在鸿蒙上的落地技术难度不在“跑通”而在“跑稳”。我见过太多项目在 Demo 阶段很兴奋到了量产阶段被内存、发热、设备差异拖垮。真正决定成败的是那些看起来不性感的工作量化评测、内存分析、线程调度、降级策略、更新机制。如果让我给一个刚起步的团队排优先级我会建议先把任务边界和验收指标定清楚再用通用推理框架快速验证确认体验达标后再投入精力做硬件优化和模型更新体系。别一上来就追求最大模型和最强性能端侧场景里稳定和可预期比参数规模重要得多。另外端侧和云端不是二选一而是配合关系。把路由层设计好后续无论模型怎么迭代、设备怎么升级业务层都不用大改。这个抽象层的价值往往在项目后期才会体现出来但前期不做后期补的成本会高得多。
HarmonyOS NEXT端侧大模型落地：5个关键工程决策与ArkTS推理实践
鸿蒙应用开发这两年最明显的变化就是“端侧智能”从一个宣传词变成了真需求。以前做 HarmonyOS 应用大家关心的是分布式软总线、原子化服务、卡片这些能力现在越来越多的项目在立项阶段就会问一句能不能在设备本地跑一个开源大模型把对话、摘要、意图识别这类能力做进去而不是所有请求都往云端丢。这个问题的答案不是简单的“能”或“不能”而是一连串工程决策的叠加——模型选多大、推理框架怎么选、ArkTS 侧怎么调用、内存和发热怎么控、离线体验和联网兜底怎么平衡。这篇内容就是围绕 HarmonyOS NEXT 接入开源大模型这条链路把我在实际项目里反复权衡过的 5 个工程决策拆开讲清楚适合已经在做鸿蒙应用、准备把大模型能力落到端侧的开发者参考也适合刚接触 ArkTS、想搞清楚端侧推理到底怎么落地的人。1. 先想清楚端侧大模型到底要解决什么问题1.1 端侧推理不是“把云端模型搬下来”很多人第一次接触端侧大模型直觉就是把云端那套模型直接下载到设备上跑。这个思路在工程上几乎必然翻车。云端模型动辄几十 GB推理时依赖高带宽显存和并行计算而手机、平板、车机这类设备的可用内存、持续算力和散热预算都是有限的。端侧大模型真正要解决的不是“复刻云端能力”而是在受限资源下提供低延迟、可离线、隐私不出端的局部智能。我在一个会议记录类应用里做过对比同样一段 300 字的会议纪要云端大模型接口往返加排队大约 1.2 到 2 秒端侧 1.5B 量化模型首次加载后单次推理约 800 毫秒到 1.5 秒虽然绝对速度不一定赢但胜在断网可用、内容不出设备。这个差异决定了端侧模型的定位——它更像一个“常驻的轻量助手”而不是“万能的知识库”。所以第一个工程决策不是选哪个模型而是先明确端侧要承担哪些任务。常见可落地的场景包括意图识别与指令解析把用户自然语言转成结构化动作比如“把这条消息标记为待办”。文本摘要与改写对本地笔记、聊天记录做压缩和润色。离线问答基于本地知识库做检索增强回答设备使用类问题。多模态轻量任务图像分类、简单 OCR 后处理等通常配合专用小模型而非通用大模型。把这些任务列清楚之后你会发现很多需求其实不需要 7B 以上的模型1B 到 3B 的量化模型就能覆盖大部分场景。这一步想不清楚后面选型一定摇摆。1.2 端侧和云端的边界应该画在哪里我见过两种极端做法。一种是全部放端侧结果模型太大、体验卡顿另一种是全部走云端端侧只做 UI结果离线场景直接不可用。比较稳妥的边界画法是按“任务敏感度”和“算力需求”两个维度切分。任务类型建议位置理由隐私敏感文本处理端侧内容不出设备合规压力小高频短指令解析端侧延迟低省流量复杂长文本生成云端端侧算力和内存吃紧需要最新知识的问答云端端侧模型知识截止且更新成本高离线兜底对话端侧无网可用是核心卖点这张表不是标准答案但它能帮你在评审会上快速说清楚“为什么这个功能放端侧”。我个人的经验是端侧优先承接高频、短输入、隐私敏感的任务云端承接低频、长输出、知识密集的任务两者用统一的接口抽象层隔开后续替换模型或调整边界时改动最小。1.3 为什么“能不能跑”不是第一个问题新手最容易陷入的误区是先问“这个模型能不能在鸿蒙上跑”。能跑只是最低门槛真正决定项目成败的是跑起来之后体验是否可接受。一个 3B 模型在旗舰机上能跑在中端机上可能加载就要十几秒推理时手机发烫、掉帧用户直接卸载。所以我在做技术预研时第一件事不是跑通 Demo而是定义验收指标冷启动加载时间不超过多少秒单次推理首 token 延迟上限连续推理 10 次后的内存增长是否可控设备表面温度上升是否在可接受范围断网状态下功能是否完整。这些指标定下来后面的模型选型、量化方案、线程调度才有判断依据。没有指标的技术预研最后往往变成“Demo 很惊艳上线很灾难”。2. 模型选型参数量、量化格式与鸿蒙设备算力的匹配2.1 参数量不是越大越好要看设备内存天花板端侧模型选型的第一约束是内存。模型加载后占用的内存大致由三部分组成权重、KV Cache、运行时开销。以常见的 1.5B 模型为例FP16 权重约 3GBINT8 量化后约 1.5GBINT4 量化后约 0.8GB。再加上 KV Cache 和推理框架本身的开销实际占用还要往上浮。鸿蒙设备的内存规格跨度很大旗舰手机 12GB 到 16GB 比较常见中端机 8GB 居多车机和部分 IoT 设备可能只有 4GB 甚至更低。我的经验做法是8GB 及以上设备可以尝试 1.5B 到 3B 的 INT4 量化模型但要留足系统和其他应用的内存。6GB 到 8GB 设备优先 1B 以下模型或者把模型做成按需加载、用完释放。4GB 及以下设备建议只做云端调用端侧最多放一个极小的意图分类模型。这里有个容易被忽略的点鸿蒙的应用沙箱对单进程内存是有限制的模型加载过大可能直接触发 OOM 被杀。所以选型时不能只看设备总内存还要看应用可用的内存预算。我一般会在真机上用内存分析工具跑一遍确认峰值占用在安全线以内再继续。2.2 量化格式怎么选INT8、INT4 还是混合量化量化是端侧大模型绕不开的一步。它的本质是用更低的数值精度表示权重换取更小的体积和更快的推理速度代价是精度损失。常见选项有 INT8、INT4以及针对部分层保留高精度的混合量化。INT8 的精度损失通常很小多数任务上几乎感知不到体积是 FP16 的一半。INT4 体积进一步减半但精度损失开始明显尤其是对生成质量要求高的任务可能出现重复、跑题、格式错乱。混合量化则是对敏感层比如注意力输出层保留 INT8其余用 INT4在体积和精度之间找平衡。我的实操建议是如果任务是分类、意图识别这类判别式任务INT4 通常够用优先换体积和速度。如果任务是文本生成、摘要优先 INT8或者混合量化别一上来就 INT4。量化后一定要做任务级评测不能只看困惑度指标。我遇到过 INT4 模型困惑度只涨了一点但生成 JSON 格式时错误率翻倍的情况。量化工具链方面主流做法是先在桌面端完成量化导出成端侧推理框架支持的格式再集成到鸿蒙工程里。量化过程本身不建议在设备上做太耗资源。2.3 开源模型和鸿蒙生态的适配成本选开源模型时除了看参数量和量化支持还要看它的算子兼容性。端侧推理框架对算子的支持是有限的某些模型用了特殊激活函数或自定义算子转换时可能失败或者退化成低效实现。我在选型时会优先考虑结构规整、社区端侧部署案例多的模型系列这样遇到问题更容易找到参考。另外要注意模型的许可证。商用项目要确认许可证允许商用和再分发尤其是量化后的权重文件。这一步经常被拖到后期才处理结果发现不能用返工成本很高。考量维度优先选择需要谨慎参数量1B 到 3B7B 以上量化支持官方或社区有 INT8/INT4 方案只有 FP16算子兼容结构规整、案例多自定义算子多许可证明确允许商用限制再分发社区活跃度文档和 issue 丰富长期无人维护这张表可以当作选型 checklist逐项打分后再决定。别只看模型榜单排名端侧部署的坑大多不在模型效果上而在工程适配上。3. 推理框架与 ArkTS 调用链路的工程取舍3.1 端侧推理框架的几种路线鸿蒙端侧跑大模型推理框架的选择直接决定开发量和性能上限。目前常见的路线有几类一类是通用的端侧推理引擎支持多种模型格式跨平台能力好一类是面向特定硬件优化的推理库性能强但绑定硬件还有一类是直接把推理逻辑用 Native 代码实现通过 NAPI 暴露给 ArkTS。通用推理引擎的优点是生态成熟、文档多、模型转换工具链完整适合快速验证。缺点是针对鸿蒙特定芯片的优化可能不够深入性能榨不干。硬件优化库性能好但适配成本高换设备可能要重做。Native 自研灵活度最高但开发和维护成本也最高一般团队不建议走这条路。我的建议是预研阶段用通用推理引擎快速跑通验证体验指标量产阶段再评估是否需要针对主力机型做硬件优化。一上来就追求极致性能很容易在适配阶段耗尽时间。3.2 ArkTS 与 Native 的边界怎么划ArkTS 是鸿蒙应用的主力开发语言但大模型推理这种计算密集型任务不适合放在 ArkTS 层做。合理的做法是把推理放在 Native 层C/C通过 NAPI 暴露少量接口给 ArkTS 调用。这样做的理由有三点性能Native 层可以直接管理内存和线程避免 ArkTS 运行时的额外开销。复用推理框架大多是 C/C 实现Native 集成最自然。隔离推理崩溃不会直接拖垮 UI 线程便于做降级处理。接口设计上要尽量粗粒度避免频繁跨语言调用。比如不要每生成一个 token 就回调一次 ArkTS而是攒一批再回传或者用回调加缓冲的方式。跨语言调用本身有开销高频调用会明显拖慢推理。一个典型的调用链路是这样的ArkTS 侧收集用户输入做预处理后调用 NAPI 接口Native 侧加载模型、执行推理把结果写回缓冲区ArkTS 侧读取结果并渲染。中间的状态管理、错误码传递要提前约定好否则调试时很难定位问题。3.3 线程模型与 UI 流畅度的平衡大模型推理是长耗时任务如果放在主线程UI 必然卡死。鸿蒙提供了多线程能力可以把推理放到独立线程或线程池里执行。但线程不是越多越好推理本身会吃满 CPU开太多线程反而增加调度开销和发热。我的做法是推理固定用一个工作线程UI 线程只负责交互和渲染。如果同时有多个推理请求用队列串行处理避免并发抢资源。对于流式输出场景Native 侧生成 token 后通过事件机制通知 ArkTS 更新 UI更新频率要节流比如每 50 毫秒或每积累几个 token 刷新一次否则频繁刷新也会导致掉帧。还有一个细节是推理优先级。当应用切到后台时应该暂停或降低推理频率把资源让给前台应用。鸿蒙的生命周期回调里可以处理这个逻辑别让后台推理把设备电量悄悄耗光。4. 内存、发热与耗电端侧推理的体验红线4.1 内存峰值控制的几个手段端侧推理最怕的就是内存峰值超标导致应用被杀。控制内存的手段主要有几个模型量化减小权重体积、按需加载减少常驻内存、及时释放 KV Cache、限制并发推理数量。按需加载是个很实用的策略。如果模型只在特定页面使用就不要在应用启动时就加载而是进入页面时加载、离开页面时释放。代价是每次进入都要重新加载所以要在加载速度和内存占用之间权衡。我的经验是如果加载时间超过 3 秒用户会明显感知这时候可以考虑常驻但用低优先级内存或者做预加载。KV Cache 是另一个内存大户尤其是长上下文场景。要设置合理的上下文长度上限超出部分做截断或摘要别让 Cache 无限增长。推理结束后及时释放不要留着占内存。4.2 发热和降频的现实处理持续推理会让设备发热发热到一定程度系统会降频推理速度随之下降形成恶性循环。这个问题没有银弹只能通过策略缓解限制单次推理时长长任务拆成多段中间让设备喘口气。动态调整模型精度高温时切换到更小的模型或更低精度。监听温度状态鸿蒙提供了设备状态相关的能力可以在温度过高时暂停推理并提示用户。避免后台推理后台推理既耗电又发热收益还低。我在实测中发现连续推理 5 到 10 次后中端机就会出现明显发热推理延迟上升 30% 以上。所以产品设计上要避免让用户连续触发大量推理比如加个节流提示或者把批量任务放到充电时执行。4.3 耗电优化与用户预期管理端侧推理的耗电是用户能直接感知的。如果应用在后台偷偷跑模型用户看到电量曲线陡降评价一定不好。优化方向包括减少不必要的推理、合并请求、用缓存避免重复计算、在充电或 Wi-Fi 环境下才执行重任务。同时要做好用户预期管理。端侧模型能力有限回答质量不如云端是正常的产品文案上不要过度承诺。可以在设置里提供“优先端侧”和“优先云端”的选项让用户自己权衡隐私、速度和效果。体验维度常见问题缓解策略内存峰值超标被杀量化、按需加载、限制并发发热持续推理降频分段执行、动态降精度、温度监听耗电后台推理耗电快避免后台推理、合并请求、缓存结果延迟首 token 慢预加载、流式输出、节流刷新这张表建议在测试阶段逐项验证别等上线后靠用户反馈来发现问题。5. 离线能力、模型更新与上线后的持续运营5.1 离线兜底与联网增强怎么配合端侧大模型最大的卖点之一是离线可用但离线能力不等于完全不要网络。合理的架构是端侧兜底、云端增强无网或弱网时走端侧模型保证基础功能可用有网时根据任务类型决定走端侧还是云端兼顾效果和成本。实现上需要一个统一的路由层根据网络状态、任务类型、用户设置来决定调用哪一侧。路由逻辑要可配置方便后续调整策略而不用发版。比如新模型上线后可以把更多任务切到端侧减少云端调用成本。这里有个容易踩的坑端侧和云端的输出格式要统一否则上层业务代码要写两套解析逻辑。建议在路由层做一次归一化把两侧结果转成统一结构再返回给业务层。5.2 模型更新的工程方案端侧模型不可能一成不变后续会有新版本、新量化方案、新能力。模型文件通常比较大更新方案要考虑下载、校验、替换、回滚几个环节。我的做法是模型文件放在独立的资源目录用版本号管理更新时先下载到临时目录校验完整性后再替换替换失败要能回滚到旧版本下载过程支持断点续传避免大文件下载中断后重来。鸿蒙的网络和文件能力可以支撑这套流程但要注意存储空间检查别把用户设备塞满。另外模型更新要和推理框架版本兼容。框架升级后旧模型格式可能不兼容所以更新策略里要包含兼容性检查必要时提示用户更新应用。5.3 上线后的效果监控与迭代端侧模型上线后效果监控比云端更难因为数据不出端不能直接把用户输入上传分析。可行的做法是采集脱敏后的指标比如推理耗时、成功率、崩溃率、内存峰值、用户主动重试率通过这些间接指标判断模型表现。如果发现某类任务效果差可以在后续版本里调整模型或路由策略。用户反馈也是重要来源可以在应用内提供反馈入口让用户主动上报问题。注意隐私合规任何数据采集都要明确告知并获得同意。迭代节奏上端侧模型更新不宜太频繁因为每次更新都要下载大文件用户流量和存储成本高。建议按季度或半年做一次大版本更新中间用小版本修 bug。6. 几个我在实际项目里踩过的坑6.1 模型转换成功不等于推理正确有一次模型转换工具报告成功但推理结果全是乱码。排查后发现是量化时的校准数据分布和实际输入差异太大导致部分层数值溢出。这类问题不会在转换阶段报错只有实际推理才暴露。所以转换后一定要用真实场景的输入做验证别只看工具的成功提示。6.2 跨语言调用的错误码丢失NAPI 调用出错时如果错误码没有正确传递到 ArkTS 侧上层只能看到一个笼统的失败排查非常困难。后来我们约定了一套错误码规范Native 侧每个失败路径都返回明确错误码ArkTS 侧统一处理并记录日志定位效率提升很多。6.3 忽略设备差异导致中端机翻车预研时用旗舰机跑得很顺上线后中端机用户反馈卡顿、发热。原因是旗舰机内存和算力充裕掩盖了模型过大的问题。后来我们按设备档位做了分级策略高端机用大模型中端机用小模型低端机走云端体验才稳定下来。6.4 上下文长度设置过长拖垮性能为了支持长对话一开始把上下文长度设得很大结果 KV Cache 占用飙升推理速度断崖式下降。后来改成滑动窗口加摘要的方式只保留最近若干轮对话和一份历史摘要内存和速度都回到可接受范围。7. 给准备入场的团队的一点个人体会端侧大模型在鸿蒙上的落地技术难度不在“跑通”而在“跑稳”。我见过太多项目在 Demo 阶段很兴奋到了量产阶段被内存、发热、设备差异拖垮。真正决定成败的是那些看起来不性感的工作量化评测、内存分析、线程调度、降级策略、更新机制。如果让我给一个刚起步的团队排优先级我会建议先把任务边界和验收指标定清楚再用通用推理框架快速验证确认体验达标后再投入精力做硬件优化和模型更新体系。别一上来就追求最大模型和最强性能端侧场景里稳定和可预期比参数规模重要得多。另外端侧和云端不是二选一而是配合关系。把路由层设计好后续无论模型怎么迭代、设备怎么升级业务层都不用大改。这个抽象层的价值往往在项目后期才会体现出来但前期不做后期补的成本会高得多。