端侧大模型的话题现在已经从“能不能跑”变成了“跑了之后到底能产生多少真正的端侧智能”。CNCC2026把“从实时全模态交互到自主智能体”这个命题摆上台面清华的刘知远、姚远等专家牵头去拆背后其实是一个非常现实的问题当大模型真的住进手机、汽车、眼镜、耳机里它能不能从“回答问题”变成“替你办事”我的答案倾向于能但路径绝对不是把云端那套东西压缩一下塞进设备那么简单。这篇文章我想结合自己的部署经验和观察把端侧智能这条链路上的关键节点拆开聊实时全模态输入怎么做自主智能体在本地怎么跑以及我们在实际落地中踩过的那些内存、功耗、算力碎片化的坑。1. 端侧大模型为什么会成为智能化的下一个主战场1.1 算力与成本逻辑为什么不能只靠云端先说一个很直接的驱动力成本。云端大模型每次调用都在消耗算力和带宽一次两次无所谓但一旦变成高频的实时交互成本是指数级上升的。比如一个带语音助手的设备如果用户每天要和它对话几十次每次都把音频传到云端再等结果回来先不说服务端要烧多少钱光用户等待的这段时间就足以让产品体验崩掉。实时性是第二个大问题。大家可能都有体会手机上的语音助手问一句“天气怎么样”如果网络不好转圈就要转好几秒。而真正端侧智能的典型场景是“一抬手就要有反馈”这种毫秒级的响应在弱网环境下靠云端根本指望不上。地下车库、隧道、飞机上、地铁里这些断网场景恰恰是用户最需要本地智能的时候。然后是隐私。医疗对话、家庭监控画面、驾驶行为数据、相册里的照片这些高度敏感的内容送到云端处理用户心理上很难接受合规上也很麻烦。端侧推理天然把数据锁在设备里这个优势在健康、办公、家居等场景里是刚需。还有一个被低估的维度是个性化。云端的通用模型不了解你它不知道你的习惯、你的日程、你常去的地方。端侧模型可以长期驻留在设备上读取本地数据慢慢形成一本“私人档案”。这跟“把模型跑在设备上”是两回事后者只是换了个执行位置前者才是真正的智能升级。1.2 “端侧智能”和“在端上跑模型”差了多远现在很多人把“能在手机上跑个7B模型”当作端侧智能这是一个典型的误解。在端上跑模型本质上是把一个推理引擎塞进设备它该不认识你还是不认识你该答错还是答错顶多省了点流量费。真正的端侧智能要求设备具备一个完整的闭环感知环境、理解上下文、做出决策、执行动作、根据反馈修正。模型只是这个闭环里的“大脑”不是全部。打一个不太严谨的比方把大模型部署到端上相当于往包里塞了一本百科全书而端侧智能是让这本书自己知道你现在要查什么、去哪查、查完之后下一步该干什么。所以你会发现衡量端侧智能的标准不该是“能不能跑”而是“离线状态下能完成多少件完整的事”。在这个标准下实时全模态交互和自主智能体就成了两个必须跨越的台阶前者解决设备怎么“看懂现场”后者解决设备怎么“办成事情”。这也是CNCC2026这个讨论主题的递进逻辑。2. 实时全模态交互让设备真正“看懂”现场2.1 多模态在端侧要怎么组合“全模态”这个词听起来很玄但在端侧落地上它要处理的输入无非是这几类文本键盘输入、语音、视觉图像/视频、传感器数据加速度计、陀螺仪、GPS、心率、麦克风阵列。其中文本和语音是用户主动发起的而图像和传感器很多时候是设备被动感知的。关键变化在于交互的发起方变了。以前是人先说话AI再回答现在可能是设备先“感觉到”发生了什么事再主动介入。举个例子车载系统通过麦克风阵列和加速度计同时感知到剧烈碰撞和玻璃破碎声这时候哪怕乘客没有喊救命车机也会自动进入应急流程。这就是全模态交互和单纯“语音助手”的本质区别。在端侧做多模态不能像云端那样暴力堆token。云端可以把5秒视频拆成几百帧逐帧分析端侧不行内存和算力不允许。我的习惯是给每种模态设定一个“优先级”和“采样策略”语音通常用VAD语音活动检测切出有效片段再送识别视觉先抽关键帧再走轻量编码器传感器则用滑动窗口做事件检测有异常才唤醒大模型。说白了端侧多模态不是把所有数据都喂给模型而是让模型只在需要的时候看到关键的那一口。2.2 流式处理是实时性的第一道关实时性在工程上最直接的体现就是流式处理。端侧交互不能是“录音结束再处理”的批处理模式用户体验要求“边说边出结果”这就要解决流式语音识别、流式解码和打断机制三个问题。流式语音识别目前比较成熟的做法是分块处理把音频切成25毫秒到1秒不等的小块边接收边解码。第一个字的延迟可以压到几百毫秒整句话说完时文本通常已经完整呈现。这里有一个容易忽略的细节意图识别不一定要等整句话结束。比如用户说“帮我关掉客厅的灯”在“关掉”这个词出来之后大模型就可以提前判断这是一个设备控制意图先锁定“灯”这个设备和“客厅”这个空间等指令完整后再执行。这种“半句级意图预判”对时延的改善非常明显。视觉流式处理更讲究策略。视频不是每一帧都值得处理我的方案是结合运动检测和场景变化率动态调整抽帧频率画面静止时每秒只看1帧画面剧烈变化时提高到每秒4到6帧。处理后还要对视觉token做压缩因为一帧224x224的图像在ViT下会产生196个token5秒视频如果每秒抽4帧就是将近4000个token这在小模型的上下文窗口里是很奢侈的。常见的做法是用感知编码器把整段视频压成几百个token的摘要再用文本token去引导模型聚焦关键帧。2.3 端侧性能工程量化、投机采样与内存预算这一节是实操中最核心的部分。先说内存预算公式其实很简单以7B模型为例FP16精度下模型权重大约占 7×10^9×2字节 14GB这显然超出了多数设备的可用内存换成INT4量化后只有约3.5GB基本就可以在旗舰手机和PC上落脚了。但权重装得下只是第一步推理延迟还受内存带宽约束。以目前主流移动平台LPDDR5X的带宽大约68GB/s来算INT4模型每生成一个token至少要读取一遍全部权重理论下界是 3.5GB÷68GB/s ≈ 51ms。听起来还行但加上计算、调度和缓存miss的损耗实测通常在70到90ms左右一个token也就是每秒11到14个token。如果是FP16精度单token延迟直接翻到200ms以上对话时那种“一字一字往外蹦”的感觉就出来了。KV Cache的膨胀也要提前算。以7B模型、GQA配置为8个KV头、注意力头维度128、共32层来举例每个token的KV Cache大约是 2×32×8×128×2字节 128KB。上下文长度到4K时KV Cache要吃掉512MB内存这在端侧是灾难级别的。所以端侧做长上下文一定要配合KV Cache量化INT8可以压到一半和上下文压缩策略。再说投机采样。这个技术非常适合端侧思路是先用一个小模型比如1B到2B快速草拟接下来几个token然后让大模型一次性验证这些草稿。因为验证是并行打分所以实际生成速度会远高于大模型单干的速度。我把这个过程类比成“先让实习生起草再让主编快速过一眼”大多数草稿能被批量放行只有少数需要修改。在旗舰SoC上7B主模型加1.5B草稿模型生成速度可以做到15到30 token/s交互感受完全不同。下面这张表总结了我常用的端侧多模态优化手段方案解决什么问题成本注意点INT4/INT8量化权重瘦身降低内存占用和带宽瓶颈低比特下推理质量可能退化需实测KV Cache量化与压缩控制长对话/长上下文的显存膨胀压缩过度会损失细节记忆流式ASR与VAD降低语音交互首字延迟和无效算力消耗需要处理断句和识别错误的兜底动态抽帧与视觉token压缩抑制视觉输入带来的token爆炸关键帧漏检会直接影响理解效果投机采样用草稿模型加速自回归生成草稿模型与主模型分布偏差大时收益下降3. 自主智能体从“回答问题”到“完成事情”3.1 云端智能体与端侧智能体的分界大模型圈子里“Agent”已经快被说烂了但端侧智能体跟云端Agent有一个很实际的分界线云端Agent默认网络畅通、算力充裕可以把任务拆成几百步慢慢规划端侧Agent必须接受现实——设备可能离线、算力有限、你不能把用户的隐私数据全部搬走。所以端侧智能体的设计原则是“离线能跑在线更强”而不是“离了云就瘫”。另一个差别在工具范围。云端Agent调用的工具通常是网页搜索、代码解释器、第三方API而端侧Agent直接面对的是系统级操作打开应用、读取日历、发消息、控制蓝牙设备、修改系统设置。这意味着端侧智能体的权限边界和操作风险比云端高一个量级它不再是“给你一段建议文本”而是“真的替你点了那个按钮”。数据隐私在这里变成了一个结构性优势。端侧Agent可以合法地访问本机短信、相册、健康记录、位置历史因为这一切都不出设备。云端Agent想做到同样的个性化必须先把这些数据传上去那用户基本不会同意。可以说端侧智能体是唯一一种既能深度了解用户、又不过度索取用户数据的产品形态。3.2 端侧智能体的运行架构我在实际项目里常用的架构分五层基本可以覆盖大多数端侧Agent需求感知层负责把前面说的多模态原始输入转成结构化事件记忆层负责短期窗口记忆和长期向量检索短期记忆就是当前任务的上下文窗口长期记忆则用一个本地的向量数据库把用户的历史偏好、日程事实、设备状态索引起来规划层由轻量大模型承担把当前任务拆成步骤但这里有个关键心得——不要让小模型一次性规划太长的链路控制在3到5步以内最稳定执行层通过统一的工具协议去调用日历、地图、短信这些系统能力工具的输入输出全部走规范化的JSON Schema反思层在任务完成后做一次性校验比如检查是否真的修改了设置、是否漏掉了用户要求的附加条件。这套架构特别像人的工作方式大脑负责判断手脚负责执行备忘录负责记忆。值得强调的是端侧Agent的执行层往往不只是调API它可能还要通过无障碍服务或系统意图去操作第三方应用界面这时候稳定性会差很多所以要格外强调“执行后验证”而不是“执行后结束”。3.3 一个完整的本地任务闭环示例拿一个最常见的场景来拆解用户说“我明天上午开会之前顺路买杯咖啡”。端侧Agent的处理流程大概是这样先解析意图确认这是一个包含时间、地点、购买动作的复合任务。然后查日历确认会议时间和地点查地图数据估算出发路径搜索沿途或会议地点附近的咖啡店。接着向用户确认选哪家、选什么口味调用下单服务完成支付。整个过程用户只做两三次轻量确认大部分中间步骤都在本机完成网络波动时这些步骤照样能跑。这里面有两个安全设计我觉得是底线所有涉及支付、消息发送、删除数据的动作必须经过用户显式确认不能“全自动”所有Agent动作都要写入本地审计日志用户任何时候都可以回看“它刚才到底干了什么”。主动行为的例子也很好理解系统检测到用户明天早上9点有航班结合当前时间和定位数据判断再不出发就要赶不上了于是主动弹出一条提醒。这在传统交互范式里叫“推送”但在端侧智能体里它叫“基于环境感知的自主触发”因为它背后经历了完整的感知、推理、决策链路而不是一条预先配置的规则。4. 通往端侧智能路上的四堵墙4.1 内存墙模型装得下上下文放不下现阶段端侧智能最大的敌人不是算力是内存。模型权重、KV Cache、多模态输入缓冲区、工具定义集合全部挤在有限的几GB内存里还要给操作系统和其他应用留位子。我见过不少项目模型缩到3GB以内但上下文一拉长就内存崩溃最后只能把上下文砍到1024 token智能程度大打折扣。在这种约束下我的做法有三个一是长对话滚动摘要连续对话超过一定长度后把前面的细节压缩成摘要只保留关键实体和意图二是在任务不需要全局历史时把KV Cache清零重算省下大量常驻内存三是把大模型拆分成Prefill和Decode两个阶段分别调度Prefill用高带宽短爆发Decode用低功耗长运转峰值内存能被削掉不少。4.2 功耗墙持续智能与续航的矛盾端侧智能要“随时在线”但设备电池经不起大模型一直耗电。旗舰SoC的NPU在峰值功耗下能达到5W以上连续跑几分钟就开始发热降频性能曲线直接断崖。这事不解决谈再多智能都是空话。我的标准做法是分级唤醒最低功耗层由DSP协处理器常驻监听只做VAD和环境事件检测功耗控制在毫瓦级当检测到语音唤醒词或异常事件时再拉起NPU跑小模型做粗分类确需大模型介入时才加载主模型。相当于幼儿园阿姨不是24小时站在门口但门铃响了她一定会醒。另外要控制推理频率很多场景不需要持续生成用一次推理缓存结果就能顶好几次发热问题会缓解很多。4.3 碎片化墙同一个模型在不同NPU上的命运端侧芯片厂商的NPU指令集、内存布局、算子支持各自为战同一个ONNX模型在A家芯片上跑得飞快到B家可能因为缺某个算子直接回退到CPU性能跌到没法看。这堵墙非常磨人。我的经验是不要把“部署”寄托在单一框架上。先用ONNX Runtime做通用推理加上各厂商的NPU适配层类似NNAPI的抽象兜底同时把所有算子里列一个“白名单”只使用各平台都支持较好的算子遇到不支持的算子就改模型结构去绕开比如用标准卷积替换动态卷积。还要重视量化校准的逐设备验证——同一套校准数据在不同芯片上产出的量化模型精度表现可能差不少必须用真实任务回归。4.4 能力墙小模型怎样“够用”7B也好甚至3B也好端侧模型在复杂推理、世界知识、多步规划上和云端大模型确实有差距。但端侧智能没必要硬刚这个短板。我的认知是把工具当长板把模型当胶水。复杂计算交给设备上的计算器、复杂搜索交给按需联网的云端搜索接口、稳定流程交给规则引擎大模型只负责理解意图、拆分任务、拼接结果。这就像一个小团队不需要每个人都精通所有能力但需要一个能看懂全局、知道找谁干活的人。端侧模型的定位就是这个召集人。借助外部工具7B模型也能完成95%以上的日常任务反而硬逼它在本地用残缺知识组织长回答才是最容易翻车的做法。5. 真正的端侧智能怎么衡量不少团队还在用MMLU、GSM8K这类通用基准来验收端侧模型我建议抛开这些跑分因为它们衡量的是语言能力不是设备智能。真正贴近端侧的评测应该看下面这些维度维度我的衡量方式为什么重要任务闭环率断网状态下发起10个高频复合任务成功完成的比例这是端侧智能和云端助手的分水岭P95时延从用户说完话到动作完成取95分位时延避免被平均时延掩盖的长尾卡顿能耗表现完成相同任务消耗的电量占比持续智能不能以续航崩盘为代价隐私边界敏感数据是否完全留在本地决定用户敢不敢把设备当成私人助理个性化记忆模型能否记住用户偏好并直接影响行为区分“通用模型”和“个人智能体”故障可回溯是否有完整日志描述感知、决策、执行全过程出事时能快速定位这是工程信任的底线我尤其推荐把“断网任务闭环率”列为第一指标。一个端侧智能产品如果能做到离线完成日程管理、本地信息查询、设备控制、简单购物流程里的多数任务它才是真正把智能装进了设备如果只是联网时能用断网就变傻那它本质上还是云端产品只是换了个入口。另外评测最好建立在影子模式上用真实用户的设备操作日志回放驱动模型决策而不是拿干净整洁的测试用例。真实日志里有打断、有噪声、有歧义只有在这类数据上跑出高成功率才算经受住了实战检验。6. 给想入局的人五件能立刻开始的事第一件事选一个7B到8B的开源模型量化到INT4在你目标设备上跑通本地对话。重点不是体验对话效果而是测三件事内存占用、生成延迟、发热曲线。先搞清楚硬件底盘的水位后面所有功能设计都要受它约束。第二件事把本机数据源抽象成工具API。不要一上来就做大而全的框架先挑日历、相册、定位、系统设置四个数据源每个封装成带JSON Schema的函数接口。这个动作能让你想清楚“模型如何操作现实世界”比空谈Agent架构有用得多。第三件事搭一条流式语音管线。从VAD开始做再到流式ASR最后接上本地大模型用P95延迟而不是平均延迟来验收。这一步会把你从“模型评估者”变成“系统工程师”很多端侧的隐性问题只有在流式链路里才会暴露。第四件事做一个小而完整的任务闭环Demo。选“一句话触发一个多步骤动作”的简单场景比如用户说“帮我记一下明天下午3点去银行”Agent自动解析时间、创建日历事件、设置了提前一小时提醒然后通过设备通知把结果反馈给用户。不要接支付、不要碰高权限动作先把闭环跑通。第五件事从第一天就建立日志系统。每一轮交互都要记录感知输入、意图分析、规划结果、工具调用、用户反馈的时间线。端侧问题最大的麻烦是“偶发不可复现”没有完整日志你会被这类问题拖死。经验上还有几个提醒。第一开发阶段尽早用整机而非开发板因为散热和功耗表现会直接影响NPU的持续性能散件上的数据往往在整机上对不上账。第二不要只看量化前后的困惑度指标要跑真实任务回归因为有些能力的退化和困惑度无关。第三别试图把模型塑造成全能体做好“本地模型、云端大模型、规则引擎”三者之间的路由该上云的上云该本地的绝不出去。第四产品设计要容忍一定程度的“不完美”端侧模型一定会犯错关键是错的时候能快速止损把控制权交还给用户。我个人做了这么久端侧项目最大的体会是端侧智能的成败不在模型参数的大小而在系统工程的精细程度。多模态输入怎么取舍、工具调用怎么组织、上下文怎么精简、功耗怎么平衡这些琐碎但决定生死的细节才是从“端侧大模型”迈向“端侧智能”真正的门槛。