企业官网建设流程全解析

1. 端侧智能的现状与困局：为什么“跑得动”不等于“用得好”

做端侧大模型这行的朋友，多少都有过类似的体验：模型在服务器上跑得好好的，评测指标也不差，一搬到手机或者嵌入式设备上，不是内存爆掉就是延迟高到没法用。好不容易跑起来了，真机上一测，首 token 延迟三秒起步，用户早跑了。这个场景放在两三年前还算能接受，毕竟能端侧跑起来本身就是新闻。但到了现在，大家的预期早就不一样了，实时、全模态、自主决策，一个比一个难，一个比一个绕不开。

CNCC2026 这次请到清华刘知远、姚远等专家来聊端侧大模型，主题从前两年的“能不能跑”直接跳到“实时全模态交互”和“自主智能体”，这个信号本身就说明行业已经换了一个战场。端侧智能这四个字，正在从“模型能部署在端上”变成“端上能不能长出真正智能”。这篇文章我结合自己在这块的实际动手经验，把从实时交互到自主智能体这条路上的关键环节、技术选型和踩坑记录都拆开讲一讲，顺便聊聊去 CNCC2026 现场应该重点听什么。

1.1 端侧模型从“能跑”到“好用”还差什么

先说一个最容易忽略的认知差。很多人觉得端侧大模型的目标就是把云端的 Llama、Qwen 这类模型缩小一下塞进手机，跑个对话就完事。实际上端侧智能的核心诉求根本不是“跑对话”，而是“实时感知环境、快速做出反应、在无网或弱网环境下也保持可用”。这就牵扯到两件完全不一样的事：一个是把模型变小，另一个是把交互链路的延迟压到人无感的范围。

我自己的实测数据可以拿来说事。一台中端手机，跑 1.5B 参数量的量化模型，纯文本流式输出，每秒能吐 20 到 30 个 token，看起来还行。但一旦加上摄像头画面输入、语音输入流转录、上下文 history 拼接这些环节，整个端到端延迟很容易冲到 2 秒以上。注意，这里说的“端到端”是从用户说完话到设备做出第一个有效反馈的时间。2 秒在纯文本聊天里还能忍，放在全模态交互场景里就是灾难。你去想一个 AR 助手，用户指着面前的零件问“这个拆装步骤是什么”，设备要先拍照、识别、理解、检索、组织语言再输出，中间任何一个环节卡住，整个体验就垮了。

所以“好用”的底线，不是模型参数量多少，而是“感知—理解—决策—表达”这条链路能不能在端侧闭环。刘知远老师他们长期在提的一个观点我很认同：端侧智能的真正差异化在于模型对用户环境的持续建模能力，而不是单次问答的准确率。也就是说，设备知道你此刻在做什么、刚才看过什么、习惯怎么操作，这些上下文才是端侧相比云端的天然优势。

这里补一个我在项目里总结的经验：评估端侧模型能不能用，算法人员看的是 BLU 这类基准分数，但工程人员必须看 P99 延迟、内存峰值、功耗曲线和热降频行为。这四个指标不过关，分数再漂亮都是白搭。尤其是热降频，手机 SoC 在连续高负载下会主动降低频率，模型推理速度可能从 20 token/s 直接掉到 8 token/s，用户感受就是“越用越卡”。这个点很多评测室测不出来，因为标准测试都是短时跑分，真机长稳测试才是照妖镜。

1.2 实时全模态交互到底在解决什么问题

实时全模态交互这个词听起来很玄乎，拆开就是三件事：文本、语音、视觉或者其他传感输入能同时进模型，模型能跨模态地理解，并且在同一套系统里完成输出。真正的难点不在单模态识别，而在于多模态之间的时序对齐。举个例子，用户对着摄像头说“这个零件装反了”，语音转写出来是“零件装反了”，画面上是一个机械结构。模型要同时把语音流和视频流在时间轴上对齐，理解“这个”指的是画面中哪一个物体，再结合场景判断“装反了”是否成立。这需要视觉编码器和语音编码器产出的特征在统一的语义空间里对齐，而端侧模型因为参数量小，天然缺少冗余能力去掩盖对齐误差。

我去年带着团队做的一个设备端质检助手项目，就卡在这个问题上。我们最初的做法是简单粗暴地把 ASR 文本和单帧图像拼起来送进模型做多模态推理，结果经常闹笑话：用户说“右上角那个螺丝松了”，模型却盯着画面左下方的卡扣回答。后来我们换成了流式对齐方案，把语音片段的语义嵌入和视频滑窗特征在时间维度做对齐，准确率一下子从 67% 提到 89%。代价是内存占用多了大概 180MB，延迟多了约 120ms，但这笔账是值得的。

再往深一层说，实时全模态交互对端侧算力的挑战不只是推理，还有并发。端上要同时跑音频采集和特征提取、摄像头帧处理、语言模型推理，这些任务共享同一块 SoC，谁抢到多少算力全靠调度。我见过很多团队在原型阶段用开发板，板子上资源充裕，一上手机就露馅。所以真做全模态时，最好从第一天就把资源预算表列出来：视觉编码多少毫秒、音频编码多少毫秒、语言模型预填充多少毫秒、解码每 token 多少毫秒、中间缓存多大，每一项都写清楚。这个表就是后面做软硬协同优化的作战地图，没有它，团队大概率会在项目后期陷入无休止的性能调优。

2. 从实时交互到自主智能体：端侧智能要跨越的三个台阶

如果说实时全模态交互解决的是“设备能不能准确理解当下”，那自主智能体要解决的则是“设备能不能连续地为目标行动”。这两者之间有本质区别：交互是被动的，用户触发一次，系统响应一次；智能体是主动的，它需要根据长期目标拆解任务、在多个步骤间做出决策、并在中途遇到异常时修正策略。从行业实践来看，这条路大致要跨三个台阶。

2.1 第一台阶：端侧记忆与上下文管理

自主智能体跟聊天机器人的最大分水岭，就是有没有“记忆”。聊天的上下文通常在会话结束后就丢弃了，而智能体必须持续保留用户偏好、历史行为、任务状态。这一块在云端可以用向量数据库做大容量存储，检索时把 top-k 拿回来交给大模型就行。但在端侧，存储、检索、重排这些动作全部要在有限的内存和算力下完成，难度完全不是一个量级。

我自己的做法是先把记忆分成两层：短期记忆放在一个环状缓冲区里，只保留最近 20 轮对话和最近 5 分钟的环境感知结果，直接塞进模型上下文；长期记忆则抽取成结构化的摘要存入一个轻量级的本地向量索引，每隔一段时间用一次“反思式压缩”把旧的对话总结成几条关键信息。这样做的内存开销极小，实测 5000 条长期记忆的索引文件只有大概 15MB。但如果好大喜功，一上来就搞完整的向量数据库方案，光加载索引就可能占用 500MB 以上，中低端手机直接没法玩。

姚远老师的团队在端侧记忆这块做过不少有价值的探索，核心思路我理解下来就是“让记忆真正被模型用到，而不是存了就行”。很多团队做了记忆系统，但模型生成回复时根本没检索到有用的历史信息，检索质量太差导致记忆形同虚设。要解决这个问题，我的经验是在端上跑一个小型的 embedding 模型专门做召回，而不是直接用大模型自带注意力去“回忆”，召回准确率能提升 15 个百分点以上。

2.2 第二台阶：动作规划与工具调用

有了记忆之后，智能体要做出“下一步做什么”的决策。在端侧环境里，动作空间通常是受限的：打开某个应用、翻到某个界面、点击某个按钮、发送一条消息、调节某个设备参数。自主智能体的核心能力，就是把用户模糊的目标翻译成一系列具体的工具调用。这要求在端侧运行一个足够强的模型来理解工具文档和约束条件。

我们团队做的一个端侧自动化助手里，工具数量控制在 15 个左右，但每个工具的描述都写得很具体，包括入参格式、返回类型、失败模式。实测下来，模型能否准确调用工具，很大程度上取决于工具描述写得清不清楚，而不是模型脸有多大。有一次我们只是把工具描述里的“设备状态”改成“设备当前温度（单位：摄氏度）”，调用准确率就从 74% 跳到了 83%。这个提升量看起来很玄学，但细想是有道理的：模型是在用有限的容量做匹配，信息越明确，猜测成本越低。

规划环节真正难的地方在“长程任务”。比如用户说“帮我整理今天的工作日报”，智能体需要先拉日历、再看邮件、再读聊天记录、最后汇总成文档。每一步都会消耗时间和算力，还会出错。端侧模型如果规划能力不足，很容易在中途忘记目标，陷入局部执行。这个问题的缓解手段，我推荐一个笨办法：把任务拆解成显式的中间状态，并且每完成一个子步骤就把状态写入短期记忆，让模型随时可以“回看进度”。这个方法不需要提升模型本身的规划能力，却能让系统的可执行性和容错能力明显改善。

2.3 第三台阶：端云协同与自适应学习

大多数谈端侧智能体的人会忽略一个问题：端侧模型的更新和进化从哪里来？如果模型参数终身不变，那它永远只是一个断网的固定能力包，谈不上“不断变懂你”。这里需要的是端云协同架构。具体的流程是：端侧持续记录用户的交互样本，在本地先做一个隐私过滤，再选择用户显式允许共享的高价值数据送到云端做小规模微调，最后把更新后的模型差分下发到端上。这个闭环看起来流畅，实际落地却遍地是坑。

最明显的坑是数据分布漂移。端上采集到的交互数据，和云端精心整理的训练数据分布差异非常大，直接用在线数据微调很容易导致模型在部分能力上退化，连之前会做的题目都不会了。我经历过一次灾难性遗忘事故：我们给一个家居场景的端侧模型做了 7 次局部微调后，它的基础问答能力掉了近四成，最后不得不回滚。后来我们的策略是每次微调都混入 20% 的重放数据，并且把微调的 learning rate 压到原来的四分之一，这套组合拳下来，遗忘问题基本被压住了。

另外一个被很多资料忽略的真实问题是差分下发的兼容性。端侧环境碎片化严重，不同手机、不同 SoC、不同系统版本的推理结果本身就存在微小的随机差异。模型更新后，用户 A 觉得变聪明了，用户 B 却觉得行为怪异，往往不是模型问题，而是推理引擎的算子实现差异。我们现在的做法是灰度发布时按“机型分组”而不是“用户分组”，确保同一机型的反馈是一致的。这个细节我们曾经花了一周才排查出来，每次想起来都觉得应该早点写进工程手册。

3. 关键技术与工程取舍：从模型选型到推理优化的可行路线

前面讲了理念和架构，现在聊聊实打实的选型和优化。端侧大模型的项目，80% 的精力其实都花在工程上，算法反而是相对确定的环节。我把模型选择、压缩落点和推理引擎这几个方向的实战经验铺开讲一下。

3.1 模型选型：不要唯参数论，要看任务结构的匹配度

端侧大模型的选型，首先必须明确：你做的产品是“通用助手”还是“专用工具”。通用助手需要 7B 甚至更大幅面的模型才能勉强维持对话质量，专用工具用 1.5B 甚至 0.5B 就能做得非常出色。很多团队一上来就选大参数模型，结果内存和功耗双双超预算，只能折返重来。

我在一个工业维修辅助项目里最终选的是 1.5B 的模型。这个任务只需要识别设备状态、加载维修手册、按步骤描述操作，语言能力要求不高，但对视觉理解有硬性要求，需要看清楚设备的接口类型和零件大孝。通用大模型在这个任务上浪费了大量参数在文学创作、代码生成这些无关能力上，反而在设备相关的实体识别上不够精。专门的 1.5B 模型加上针对性的视觉对齐训练，整体效果超过了盲目选用 7B 通用模型的对照组。所以我的建议是：先画出任务能力需求雷达图，再倒推模型参数量，别被“越大越强”的惯性思维绑架。

还要提醒一点，选模型时要同步查清楚它的 License 和商用条款。端侧产品是要进商业渠道的，很多高性能开源模型其实带有附加限制，等到集成完了才发现不能商用，那种返工成本不是钱能衡量的。这点虽然听着像废话，但我确实见过不止一个团队栽在上面。

3.2 模型压缩：量化、剪枝、蒸馏的优先级怎么排

端侧模型压缩，性价比最高的一定是量化。用 GPTQ 或者 AWQ 这类工具做 4-bit 量化，模型体积直接砍到三分之一左右，精度损失在大多数任务上小到可以忽略。我做过的几个项目里，4-bit 量化后的模型在文本生成任务上的困惑度退化控制在 2% 以内。更低比特的 3-bit 甚至 2-bit 我也试过，说实话在纯文本任务上还能玩，但一旦涉及视觉特征或者复杂推理，输出质量就明显劣化，不建议上。

剪枝是另一个看着美好但实际坑很多的方案。结构化剪枝可以直接减少计算量，但端侧推理引擎对稀疏结构的支持普遍很差，剪完发现根本跑不出加速效果的情况很常见。我在一个项目里做 20% 的宽度剪枝，理论上推理速度应该提升 20%，实测只有 5%，后来一查发现是引擎把稀疏张量全部转回稠密格式了。所以剪枝一定要先确认目标引擎的算子支持，再决定要不要做。蒸馏是效果最好的方案，但成本也最高，需要准备大量的教师模型推理结果作为训练数据，人力投入可能要按周计算。优先级我的结论是：先把量化吃透，再看需要不需要蒸馏，剪枝放在最后插队。

3.3 推理引擎选型和算子调优的实战记录

端侧推理引擎的选型，直接决定了你的优化天花板。目前可选的无非这么几类：MNN、TNN、NCNN 这类老牌端侧推理框架，MLC-LLM 这类大模型后起之秀，以及各芯片厂商自家出的 SDK。我的建议是根据目标硬件来定：如果只服务某一家的芯片，直接用原厂 SDK 往往能得到最激进的计算图优化；如果产品要跨平台，那就必须选通用性强的引擎，哪怕跑分上稍微吃亏一点。

我印象最深的一次调优经历发生在某国产 SoC 上。我们用 MLC-LLM 跑 4-bit 量化的端侧模型，默认配置下首 token 延迟 800ms，逐 token 35ms。反复检查后发现瓶颈居然在权重重排，GPU 的矩阵乘单元没能吃到连续显存，大量时间花在地址跳转上。解决方案很粗暴：在模型加载阶段把权重预先按 GPU 的共享内存分块重排存储，推理阶段直接读连续块。改完之后首 token 延迟降到 420ms，逐 token 降到 22ms。这种层面的优化，不逐个算子去看汇编层输出根本发现不了，但它带来的收益是实打实的。

另外强烈建议在剖面工具上投入一些时间。端侧推理的每一个算子都可能是潜在的瓶颈，时不我待地猜还不如花一个下午把整条链路的数据跑一遍。像 QNN、Core ML 这些工具都有详细的逐层耗时输出，一眼就能看出哪一层异常，这比凭经验猜效率高太多。真到发布前的性能冲刺阶段，这份剖面报告就是团队的作战地图。

4. 工具链与调试环境：快速验证端侧智能原型的必要配置

很多人觉得端侧大模型开发跟普通后端开发差不多，写代码、部署、测试三步走。实际上完全不一样，端侧环境的资源极度受限，调试手段也远不如云端丰富。我现在走一套相对成熟的原型验证流程，从仿真到真机，每一步都有对应的工具和检查点。

4.1 原型阶段：用服务器模拟端侧约束

拿到一个新需求时，别急着往手机上装。先在服务器上把模型、输入流水线搭起来，但要刻意给这套环境加约束：把内存限制在 4G，把 CPU 限制在 4 个核，同时把模型加载时间计入总延迟。这样开发阶段就能及时发现哪些模块对资源不友好，而不是等到真机阶段才暴露。我们用这个方法把后期的真机调试时间压缩了将近一半。

模拟环境里还要重点测“冷启动”场景，也就是应用从零启动到模型加载完成，再到首个推理输出为止的完整链路。冷启动的优化空间经常被忽略，但用户的第一印象就来自它。我们有一次把模型的文件读取改成了 mmap 方式，冷启动时间从 2.1 秒砍到 0.8 秒，代价仅仅是磁盘占用多了几百 MB。很多时候你不需要在算法上做惊天动地的改动，工程细节里就藏着大把的性能。

4.2 真机阶段：需要随身携带的调试清单

真机调试是整个链路里最折磨人的阶段，因为手机并不是一个可靠的计算设备，它随时可能因为温控策略给你来一个意料之外的降频。我总结了一份随身清单，每次上真机测试都照着跑一遍。

第一项，用 3DMark 或者 Geekbench 这类基准工具确认手机 SoC 的当前性能状态，排除后台进程干扰。第二项，用 PerfDog 或类似工具记录功耗曲线，观察模型推理时的平均功耗有没有超出热设计功耗的容忍范围。第三项，连续跑 30 分钟压力测试，重点观察 token 生成速度是否出现明显衰减，这个衰减通常对应着热降频，是产品体验的大杀手。第四项，检查网络切换场景：从 WiFi 切到蜂窝网络再切回来，确认推理链路不会因为网络状态变化而出现卡顿或崩溃。

这套清单看起来基础，但每次跑完都能找到新问题。有一次我们发现，个别机型在全模态输入时会出现内存申请失败的偶发问题，最终定位到是图像编码器的输出缓存没有正确释放，运行七八次后内存碎片化导致申请大块内存失败。这类问题在短时间里根本测不出来，没有长稳测试的习惯，就只能等着线上用户来骂了。

5. 常见问题与排查经验：做端侧智能踩过的坑，能避一个是一个

做端侧大模型这么长时间，我把踩过的坑和常用排查路径整理成了一份速查表，分享出来供大家参考。

这里额外提一个非常隐蔽的坑：端侧模型的随机性。很多团队在调试时发现同样的输入，两次输出的结果不一样，就怀疑模型坏了。实际上这是采样参数和硬件浮点差异共同作用的结果。调试阶段建议把采样温度设为 0、关闭随机数种子，用确定性模式去排查问题。等核心逻辑稳定后，再放开采样做体验优化。不然你永远分不清一个 bug 到底是逻辑错误还是随机波动，排查效率会大打折扣。

另外一个经验是，端侧智能要从第一天就建立“隐私边界”意识。别等产品做大了再考虑，因为架构一旦定型，把敏感数据做本地隔离的成本会指数级上升。我们的策略很简单：所有包含人脸、地理位置、通话记录的特征信息一律只在端侧闭环使用，模型微调用到的样本必须在本地完成匿名化。这个原则写进代码评审的标准流程里，比什么宣传都有用。

6. 去 CNCC2026 现场，重点应该听什么

最后回到 CNCC2026 这个论坛本身。刘知远、姚远这些专家的研究方向，恰好覆盖了端侧大模型从底层能力到上层形态的几个关键维度。如果你打算去现场听，建议带着下面这几个问题去，听的过程中主动找答案。

6.1 关注“端侧记忆”和“持续学习”的落地框架

姚远老师的很多工作都围绕端侧智能体的“记忆”和“持续学习”展开。在现场听报告时，可以重点留意：他们是如何解决端侧数据非独立同分布问题的？用什么方法缓解灾难性遗忘？长期记忆的存储结构是向量化索引还是符号化摘要？这些方法论层面的答案，远比我上面分享的工程经验要系统。如果你自己也做智能体，建议现场多记笔记，回来后在最新开源方案基础上做二次验证。

6.2 关注“全模态交互”的评测方法

多模态交互目前最大的问题是没有公认的端侧评测基准，大多数团队只能拿自建集凑合评估。如果论坛上有专家提出新的评测方案或者开放数据集，那很可能是未来一年行业内可以对齐的标准。听会时重点看他们的评测任务设计、指标定义和端侧约束条件怎么加进去，这些东西对建立自己的评测体系直接有用。

6.3 多跟做实际产品的人交换意见

学术报告能给你提供方法论，但真正让项目活下来的往往是那些不成文的工程实践。CNCC 这类会议的价值之一，就是场内报告之外的大量交流。我每次参加完都能带回来至少两三个新的工程思路，比如某团队是怎么处理低内存下的全模态并发输入、某团队又是如何设计端云协同的灰度策略。这些交流信息通常是公开资料里找不到的。如果条件允许，多找几位做端侧推理的工程师聊聊，收获绝对不会比听报告少。

6.4 端侧智能的发展趋势：未来一年三个值得押注的方向

结合自己的实践和对行业动态的观察，我认为未来一年端侧智能有几个方向值得投入。第一个是新的人机交互形态，不是简单的语音助手或问答，而是集视觉、语音、动作理解为一体的事前主动型助手，比如自动识别用户正在做的事情并提供辅助信息。第二个是推理成本的进一步下降，随着 3-bit 量化、算子融合和端侧训练技术的成熟，中等端侧设备也能运行带基本推理能力的智能体，这会让更多产品形态成为可能。第三个是端云协同架构成为标配，纯端侧或纯云端的方案都会遇到天花板，混合架构会逐渐成为新项目的默认选择。

我个人在实际项目中感受最深的一点是，端侧智能从来不缺概念和想象空间，缺的是把每一个环节都做扎实的耐心。从一点点延迟的压缩、到一次遗忘的规避、到一次真机崩溃的修复，这些小事的累积，才真正决定了一个产品能不能从演示走到日常使用。如果你也正在做端侧大模型的落地，希望这篇文章里的经验能帮你省掉几个月的弯路。