企业官网建设流程全解析

鸿蒙应用开发这两年最明显的变化，就是端侧算力终于能撑起一些真正有意思的场景了。以前在手机上跑个稍微像样的模型，要么发热掉帧，要么内存直接爆掉，用户用两次就卸载。HarmonyOS NEXT 出来之后，ArkTS 的运行时效率、系统级的资源调度、还有 NPU 的开放程度，让端侧大模型这件事从"能跑个 Demo"变成了"可以认真做产品"。但问题也随之而来：开源大模型那么多，量化方案五花八门，推理框架怎么选，模型放哪、怎么加载、怎么和 UI 线程和平共处，这些工程决策一旦选错，后面返工的成本高得吓人。

我自己在几个鸿蒙项目里踩过不少坑，从最开始把模型硬塞进主线程导致界面卡成 PPT，到后来为了省内存把量化等级调太低、结果回答质量惨不忍睹。这篇文章不打算讲什么"大模型原理入门"，而是把接入开源大模型过程中真正需要拍板的几个工程决策摊开来讲——每个决策背后的取舍逻辑、我实际测试下来的数据、以及那些文档里不会写的注意事项。不管你是刚接触 HarmonyOS NEXT 的开发者，还是已经在做端侧 AI 应用、想看看别人怎么处理这些问题的老手，应该都能从里面找到点有用的东西。

1. 先想清楚模型到底跑在哪：端侧、云侧还是混合

这是所有决策里最上游的一个，也是最容易被忽略的。很多人一上来就纠结"用哪个模型"，其实应该先问自己：这个模型必须跑在设备上吗？

1.1 端侧推理的真实收益与代价

端侧跑模型最直接的好处是隐私和离线可用。用户的数据不出设备，对于输入法、笔记、个人助理这类场景，这是硬需求。另一个好处是延迟可控，没有网络往返，首 token 的响应可以做到很低。但代价也很实在：模型体积受限于设备存储和内存，量化之后 1B 到 3B 参数的模型是比较现实的选择，再大就要看设备档次了。

我实测过一组数据，在一台 12GB 内存的旗舰机上，加载一个 2B 参数的 INT4 量化模型，光模型文件就占了大约 1.2GB，运行时峰值内存会冲到 2.5GB 左右。这意味着如果你的应用还有其他内存大户，很容易触发系统的内存回收。所以端侧方案的第一条铁律是：先算内存账，再谈模型选型。

1.2 云侧调用的适用边界

云侧方案的优势是模型能力强、设备零负担。但它的短板也很明显：网络依赖、隐私顾虑、以及调用成本。如果你的场景是"偶尔用一次、要求高质量输出"，比如帮用户写一段文案、做一次复杂总结，云侧是合理的。但如果是高频交互、每次输入都要过一遍模型，云侧的成本和延迟都会成为问题。

这里有个容易被忽视的点：云侧调用在鸿蒙上要考虑网络状态切换。用户从 WiFi 切到蜂窝、或者进电梯断网，你的应用得有降级策略，不能直接白屏或者转圈转到天荒地老。

1.3 混合架构才是大多数产品的答案

我现在的做法基本都偏向混合：轻量任务走端侧，重任务走云侧。比如意图识别、关键词提取、简单问答这些，端侧的小模型完全够用，响应快还省流量；遇到需要长文本生成、复杂推理的，再走云侧。这样既保证了基础体验的流畅，又在需要的时候能拿到更强的能力。

具体怎么切分，我一般按两个维度判断：任务复杂度和隐私敏感度。隐私敏感且复杂度低的，坚决端侧；复杂度高且不敏感的，可以云侧；两者都高的，那就得考虑端侧能不能通过模型微调或者提示词工程来逼近效果。

2. 模型选型：参数量、量化等级和推理框架的三角平衡

确定了跑在哪，接下来才是选模型。这一步的坑最多，因为网上的教程往往只告诉你"下载这个模型就能跑"，但没人告诉你为什么选它、以及跑起来之后会遇到什么。

2.1 参数量不是越大越好

开源模型现在从 0.5B 到 70B 都有，端侧能碰的基本在 0.5B 到 3B 这个区间。我的经验是：1B 到 2B 是端侧的甜点区。0.5B 的模型虽然小，但在中文理解和指令遵循上经常掉链子，回答容易跑偏；3B 以上的模型效果确实好一些，但对内存和算力的要求陡增，中低端设备直接劝退。

选参数量的时候，别只看"效果好不好"，要结合你的目标设备分布。如果你的应用要覆盖三年前的机型，那 1B 可能就是上限；如果只面向旗舰机，2B 甚至 3B 可以试试。

2.2 量化等级：省内存和保效果的拉锯战

量化是端侧部署绕不开的一步。常见的量化等级有 FP16、INT8、INT4，甚至更激进的 INT3。量化等级越低，模型体积越小、推理越快，但效果损失也越明显。

我做过一组对比测试，同一个 2B 模型，在不同量化等级下的表现差异很大：

从这张表能看出来，INT4 是性价比最高的选择。INT8 的效果虽然更稳，但体积和内存占用对端侧来说还是偏重。INT3 我一般不推荐，除非你的场景对回答质量要求极低，比如只做简单的分类或关键词匹配。

注意：量化等级不是唯一变量，不同模型对量化的敏感度不一样。有些模型 INT4 之后效果掉得厉害，有些则几乎无损。选模型的时候一定要自己跑一遍量化后的效果，别只看论文里的数据。

2.3 推理框架怎么选

鸿蒙端侧推理目前主要有几条路：用系统提供的 AI 能力、用第三方的推理框架、或者自己基于 NAPI 封装底层推理库。系统能力的好处是集成度高、和鸿蒙的调度配合好，但灵活性和模型支持范围可能受限；第三方框架灵活，但需要自己处理内存管理和线程调度。

我的建议是：优先看系统能力能不能满足，不行再考虑第三方。因为端侧推理最麻烦的不是"能不能跑"，而是"跑得稳不稳"。系统级的调度能帮你处理很多底层问题，自己封装的话，光是内存对齐和线程安全就够折腾一阵子。

选框架的时候重点看三个指标：首 token 延迟、持续推理的稳定性、内存占用曲线。前两个决定用户体验，第三个决定你的应用会不会被系统杀掉。

3. ArkTS 层的工程化：模型加载、线程调度与内存管理

模型选好了，接下来是把它接进 ArkTS 应用里。这一步是纯工程活，但也是最容易出问题的地方。我见过太多 Demo 跑得好好的，一集成到真实应用就各种卡顿和崩溃。

3.1 模型加载不能放在主线程

这是最基础但也最容易被忽略的一条。模型加载是个重 IO 操作，动辄几百毫秒到几秒，放在主线程直接卡死 UI。鸿蒙提供了 TaskPool 和 Worker 两种多线程方案，我的选择是：模型加载和推理都放在 TaskPool 里。

TaskPool 的好处是任务粒度清晰、系统自动管理线程池，适合这种"提交任务、等待结果"的场景。Worker 更适合需要长期驻留、频繁通信的场景。如果你的推理是持续性的、需要和主线程频繁交换数据，Worker 可能更合适；如果是一次性任务，TaskPool 更省心。

import { taskpool } from '@kit.ArkTS'; @Concurrent function loadModel(modelPath: string): boolean { // 在子线程中执行模型加载 // 具体加载逻辑依赖所选推理框架 return true; } async function initModel() { const task = new taskpool.Task(loadModel, '/data/model.bin'); const result = await taskpool.execute(task); return result; }

这段代码的关键点是@Concurrent装饰器，它标记的函数会在子线程执行。注意，子线程里不能直接操作 UI，所有需要更新界面的结果都要通过返回值传回主线程。

3.2 推理任务的排队与取消

用户输入是连续的，如果每次输入都触发一次推理，很容易造成任务堆积。我的做法是加一个任务队列，并且支持取消。具体来说，当用户还在输入的时候，前一次的推理如果还没完成，就直接取消掉，只保留最后一次。

这个逻辑听起来简单，但实现的时候要注意：推理任务的取消不是"说停就停"的，底层推理库可能不支持中断。所以更实际的做法是在任务开始前检查是否已过期，如果过期就直接跳过，不浪费算力。

class InferenceQueue { private currentTaskId: number = 0; async submit(input: string): Promise<string> { const taskId = ++this.currentTaskId; // 模拟推理前的检查 if (taskId !== this.currentTaskId) { return ''; } const result = await this.runInference(input); // 推理完成后再次检查，过期结果直接丢弃 if (taskId !== this.currentTaskId) { return ''; } return result; } private async runInference(input: string): Promise<string> { // 实际推理逻辑 return ''; } }

3.3 内存管理的几个实操要点

端侧推理最怕的就是内存问题。我总结了几条经验：

第一，模型加载后不要频繁卸载重载。有些开发者为了省内存，用完就卸载，下次用再加载，结果加载耗时把体验拖垮了。正确的做法是保持模型常驻，通过系统的内存回收机制来管理。

第二，控制并发推理的数量。同时跑多个推理任务，内存直接翻倍。我的做法是全局只允许一个推理任务在跑，其他的排队。

第三，关注内存警告回调。鸿蒙提供了内存警告的监听能力，收到警告时要主动释放非必要的缓存，比如历史对话的中间结果。

提示：在真机上测试内存的时候，别只看应用自己的内存占用，要看系统整体的内存压力。有时候你的应用只占了 2GB，但系统已经快撑不住了，照样会被杀。

4. 提示词工程与上下文管理：端侧模型的"效果放大器"

端侧模型参数量小，能力天然有限。但这不代表做不出好体验，关键在于提示词工程和上下文管理。这两件事做得好，1B 的模型也能有不错的表现。

4.1 系统提示词要"窄而深"

端侧模型不适合处理开放式任务，你让它"随便聊聊"，它很容易胡说八道。正确的做法是把任务收窄，用系统提示词把模型的行为框死。比如你要做一个笔记摘要功能，系统提示词就应该明确告诉它：只做摘要、不回答问题、输出格式是什么、长度限制是多少。

我对比过两种提示词写法，效果差异很明显：

• 宽泛写法："你是一个智能助手，请帮助用户处理文本。"——模型经常跑偏，回答里夹杂无关内容。
• 收窄写法："你是一个文本摘要工具。用户会给你一段笔记，你只需要输出不超过 50 字的摘要，不要添加任何解释或额外内容。"——输出稳定得多。

端侧模型的指令遵循能力弱，提示词越具体、约束越明确，效果越好。

4.2 上下文窗口的取舍

端侧模型支持的上下文长度通常比云侧小，常见的是 2K 到 8K token。这意味着你不能把整篇文档都塞进去。我的处理方式是分层截断：优先保留最近的对话和系统提示词，历史内容做摘要压缩。

具体实现上，我会维护一个 token 计数器，每次拼接上下文的时候估算 token 数，超过阈值就把最早的内容替换成摘要。这个摘要可以用模型自己生成，也可以用简单的规则提取关键句。

4.3 少样本示例比长篇解释更有效

对于端侧小模型，给几个示例比写一大段说明管用得多。比如做意图分类，与其解释"什么是查询意图、什么是操作意图"，不如直接给三五个标注好的例子。模型会通过示例来理解任务边界，这比抽象描述有效。

const systemPrompt = `你是一个意图分类器。根据用户输入判断意图，只输出意图标签。 示例： 输入：今天天气怎么样 -> 查询 输入：帮我定个闹钟 -> 操作 输入：打开设置 -> 操作 输入：介绍一下鸿蒙 -> 查询 现在开始分类：`;

这种写法在 1B 模型上实测准确率能到 85% 以上，比纯描述式的提示词高出不少。

5. 性能与体验的平衡：那些上线后才暴露的问题

前面讲的都是开发阶段能想到的，但真正的问题往往在上线后才暴露。这一节聊聊我在真实项目里遇到过的、以及从同行那里听来的坑。

5.1 首屏加载与模型预热的时机

用户第一次打开应用，如果这时候才开始加载模型，等待时间会很长。我的做法是在应用启动后、用户还没触发 AI 功能的时候，就在后台预热模型。这样等用户真正用的时候，模型已经加载好了。

但预热也要看时机，不能在应用刚启动、系统资源最紧张的时候去抢资源。我一般会延迟几秒，等首屏渲染完成后再开始预热。鸿蒙的 Ability 生命周期里有合适的回调点可以做这件事。

5.2 发热与降频：端侧推理的隐形杀手

端侧推理是计算密集型任务，跑久了设备会发热，发热之后系统会降频，推理速度断崖式下跌。这个问题在夏天或者边充电边用的时候特别明显。

我的应对策略是控制单次推理的时长，把长任务拆成多个短任务，中间给设备喘息的机会。另外，避免在充电时做重推理，可以通过系统 API 检测充电状态，如果是充电中且温度偏高，就降低推理频率或者提示用户。

5.3 模型更新与版本管理

开源模型迭代很快，你可能需要在不发新版应用的情况下更新模型。我的做法是把模型文件和应用包分离，模型放在可更新的目录里，通过版本号管理。应用启动时检查模型版本，如果有更新就后台下载。

这里要注意的是模型文件的完整性校验，下载过程中断或者文件损坏都会导致加载失败。我一般会做 MD5 校验，校验不通过就重新下载。

5.4 降级方案必须要有

不管你的端侧方案做得多好，总会有设备跑不动、或者模型加载失败的情况。这时候必须有降级方案：要么切到云侧，要么提供一个简化版的功能。最忌讳的就是直接报错或者白屏，用户不知道发生了什么，只会觉得你的应用烂。

我的做法是准备一个能力检测流程：应用启动时检测设备的内存、算力、存储空间，判断能不能跑端侧模型。如果不能，就自动切到云侧或者轻量规则方案。这个检测要在用户无感知的情况下完成，不能弹一堆提示吓唬用户。

6. 从 Demo 到产品：我踩过的三个真实坑

最后这部分不讲理论，就讲三个我实际踩过的坑，每个都让我返工了不少时间。

6.1 坑一：低估了模型加载对启动速度的影响

最开始我把模型加载放在了首页的 aboutToAppear 里，想着"反正用户进来就要用"。结果首页白屏时间从 300ms 涨到了 2 秒多，用户以为应用卡死了。后来改成延迟加载加骨架屏，体验才回来。

教训是：模型加载永远不要阻塞首屏。哪怕用户进来就要用 AI 功能，也要先把界面渲染出来，再在后台加载模型，用 loading 状态告诉用户"正在准备"。

6.2 坑二：量化后的模型效果和预期差太多

有一次我选了一个在榜单上表现很好的模型，直接用了社区提供的 INT4 量化版本，结果中文回答质量惨不忍睹，经常答非所问。后来自己重新做了一遍量化，效果才正常。

教训是：别直接用别人量化好的模型，除非你验证过效果。不同工具、不同参数做出来的量化版本，效果差异可能很大。自己跑一遍量化流程，虽然麻烦，但可控。

6.3 坑三：忽略了多设备适配

我在旗舰机上测得好好的，结果用户反馈在中端机上经常崩溃。排查后发现是中端机内存小，模型加载时直接 OOM。后来加了设备能力检测和分级策略，低端机用更小的模型或者走云侧，问题才解决。

教训是：端侧 AI 应用必须做设备分级。不能假设所有用户都用旗舰机，中低端设备的占比往往比你想的高。

6.4 一个实用的小技巧

如果你也在做端侧模型接入，建议在开发阶段加一个性能面板，实时显示推理耗时、内存占用、token 速度这些指标。这个面板不用给用户看，但能帮你在调试的时候快速定位问题。我现在的项目里都保留了这个面板，通过一个隐藏手势触发，排查问题的时候特别方便。

端侧大模型在鸿蒙上的落地，技术本身不是最大的障碍，真正的难点在于工程上的取舍和细节处理。模型选型、线程调度、内存管理、提示词设计、降级方案，每一个环节都需要结合具体场景去权衡。我自己的体会是，不要追求"最强模型"，而要追求"最稳体验"。一个 1B 的模型如果调教得好，在特定任务上完全能打；一个 7B 的模型如果跑不稳，反而会毁掉整个产品。先把一个窄场景做透，再考虑扩展，这条路走下来会踏实很多。