做AI硬件产品这些年被问到最多的一句话就是“端侧模型和云端API到底哪个更适合跑在硬件上”问的人有做AI眼镜的、做智能音箱的也有做扫地机器人、智能门锁想加语音助手的。每次我都很难给出一个二选一的答案因为真正把设备量产过一遍就会明白这不是一道单选题而是一道分配题。最近圈子里被反复拿出来讨论的“端云协同”思路恰好就是在回答这个怎么分配的问题。我今天准备拿自己实际参与过的项目当例子把端侧和云端这笔账彻底算清楚也聊聊内外网流行的“方舟方案”背后那套路由逻辑替AI硬件团队把魂儿找回来。1. 这个问题为什么在最近一年突然变得尖锐起来1.1 端侧芯片的“甜点算力”和智能交互的需求错位先说个很多人忽略的事实市面上绝大多数端侧AI芯片真正的“甜点算力区”其实很窄。做语音唤醒、活动检测、简单场景识别这些活儿端侧芯片干得很漂亮功耗只有几毫瓦到几十毫瓦效果稳定省心。但一旦把任务从“唤醒”升级到“连续对话”“开放语义理解”“多模态问答”算力需求会瞬间跳两个数量级内存需求也跟着起飞。这不是芯片厂商不努力而是物理约束摆在那里。一个跑在设备端的大语言模型哪怕只有1B参数量化到2bit光权重就需要500MB左右运行时要再加激活值、KV Cache、临时缓冲整体内存占用能到1GB以上。而普通消费级AI硬件比如一台智能台灯、一个门铃整机物料成本可能才几十元你让它为“更聪明”多掏出几十元的内存和NPU预算产品根本做不下去。所以端侧芯片真正舒服的区间是“规则明确、输出受限、时延敏感”的任务。这类任务用端侧模型做得又快又稳几乎不耗什么电比如关键词识别、人体存在检测、异常声音判断。可一旦越过这道线想让设备真正“懂”用户端侧那点算力就很难支撑了。需求错位带来的直接结果就是很多产品嘴上说着端侧为主身体却很诚实地把所有智能逻辑全塞进了云里。1.2 模型能力迭代太快端侧存储成了新的瓶颈另一个被低估的问题是模型更新。云端API的好处是模型升级跟你完全无关今天你在调用的接口可能三天前已经换了底模效果悄悄变好了。但端侧模型不行它烧进固件里、跑在内存里、被量化到特定精度每一版升级都意味着研发、测试、灰度、OTA推送一整套流程。最难受的是带宽和整机存储。一个几百MB的模型升级包推给在线设备要好几天才能全覆盖还会产生不低的CDN流量成本。如果用户设备长期离线他只能用旧模型体验和新设备出现明显割裂。很多团队为了省事干脆把“大模型能力”全部放云端让端侧只跑一些很难变动的轻量规则这样一来端侧模型倒是好维护了可产品也会因此变得很“笨”很多本可以在本地解决的交互非要绕一圈上云。我见过一个做儿童故事机的团队早期把故事理解、语音合成全放在端侧后来想引入“开放式问答”功能发现现有芯片根本跑不动新模型整机存储也不够。最后他们选择在端侧保留“聆听和打断检测”把问答能力切到云端API才把功能上线。这个案例很典型不是他们不想端侧而是端侧更新的速度和成本让他们耗不起。1.3 为什么“网上都说端侧好”很多产品最后还是上了云这里有个很割裂的现象。你去逛开发者社区几乎人人都在喊端侧推理是未来隐私好、延迟低、离线可用说得头头是道。可真正去看那些已经量产的硬件产品你会发现大量交互逻辑还是依赖云端API。原因不复杂。第一上云最快。接入一个大模型API一两天就能让设备“能聊会道”而端侧部署要从模型裁剪、量化、算子适配一路干到多芯片平台兼容没有两三个月下不来。第二上云效果最好。云端跑的是10B、100B级别的模型理解能力、生成质量、上下文长度端侧模型很难比得上。第三上云的成本虽然是持续的但单品研发费用被压得很低对急于出货的团队来说“先上云把功能落地再慢慢优化”是唯一现实的选择。但这些选择背后埋了一颗雷一旦用户量起来云端调用费用、并发压力、断网体验都会集中爆发。之前有个做智能门锁的项目第一版全部逻辑走云端结果物业区域网络一抖动门锁就“思考”很久用户直接投诉退款。到这一步大家才会回头去算端侧那笔账才会愿意认真研究端云协同到底怎么做。2. 把端侧和云端的账本摊开算力、成本、隐私、体验2.1 端侧模型的真实成本不是免费而是钱花在了物料清单上很多人觉得端侧模型“不花钱”这是最大的误解。端侧模型确实不产生按次计费的费用但它的成本藏在了硬件物料清单里。最直观的就是内存和算力芯片。我们当时评估过在一款AI眼镜上跑一个精简版多模态模型需要额外增加2GB LPDDR4X内存量产采购成本大约是7到10美元NPU推理单元也要用更好一档的否则无法在30毫秒内完成一帧画面的理解。这一加整机成本立刻上升15%以上。对于定价在千元以下的消费电子产品10美元足以决定这个产品是盈利还是亏本。这还没算研发成本。把一个开放模型移植到某个特定芯片平台上要做算子对齐、逐层验证、量化误差评估一套流程下来通常要两个月的人工。如果芯片平台不止一个——比如高通的平台、瑞芯微的平台、全志的平台——每个平台都要单独适配维护成本按倍数上涨。所以端侧模型的真实成本是“一次性研发成本每台物料成本持续OTA成本”的叠加它不等于零只是它的边际成本不随使用次数变化。2.2 云端API的真实成本账面很便宜叠加后很惊悚云端API的计价方式通常是按token算市面主流大模型接口输入侧大概是每百万token几元输出侧每百万token十几二十元。单看单价会觉得很便宜可只要把用户真实使用场景叠加进来数字就会变得很惊悚。以AI眼镜的“识物问答”功能为例。用户对着一盆植物拍照云端要接收图像编码后的信息加上用户语音转成的文字再生成一段回答。一次完整交互大概消耗500到1500个token。假设一个重度用户每天触发50次一个月就是约5.1万次调用总token消耗可能在2000万到4000万之间。再乘以设备出货量哪怕只有一万台活跃设备每月的云端账单就是六位数人民币。这还只是单功能如果同时开语音助手、视觉问答、闲聊这多个能力成本还要翻几倍。更麻烦的是成本结构不是线性的。为了保障用户体验你得做并发预留高峰时段的GPU实例费用、内容安全检测的额外调用、语音识别与合成费用全部会叠加到同一个账单里。很多团队做完一轮小规模公测就开始焦虑了因为他们发现新增一个用户的边际成本已经接近甚至超过了硬件毛利。2.3 隐私不是口号谁能真正不碰用户数据隐私问题在技术圈经常被当成“合规话术”但在AI硬件场景里它是非常现实的工程约束。智能门锁要处理门口的访客画面AI眼镜要持续观察用户眼前的世界智能录音笔要保存对话内容。这些数据一旦出了设备就要面临传输加密、云端存储、访问审计等一系列问题任何一个环节出纰漏都可能变成公关事故。端侧模型天然有隐私优势数据不出设备处理完就丢从源头上避免了“把原始录音传到服务器”这种操作。但端侧模型也有一个容易被忽视的问题为了在有限资源下识别意图它往往需要把原始音频或图像压缩、量化这个压缩过程本身就可能丢信息甚至产生误判。如果想既保护隐私又保证理解质量就必须做“先在端侧做结构化只把非敏感的语义信息上云”这类折中设计而这就是端云协同的雏形。2.4 体验维度延迟、流畅度、离线兜底从体验指标看端侧和云端的分水岭非常清晰。端侧推理延迟极低语音唤醒通常几十毫秒内完成画面识别也是百毫秒级别而且完全不受网络影响。云端API的延迟则受链路影响很大正常4G/5G网络下一个简单问答也要600毫秒起步加上生成时间整体响应往往在1.5到3秒之间。如果是弱网环境五秒开外都很正常。这意味着纯云端方案的用户体验是一条“敏感的折线”网络好时还算顺滑网络稍差就卡顿断网就彻底瘫痪。纯端侧方案则是“稳定的直线”响应快但天花板低复杂问题直接不会。把这两个方案放在一起对比你会发现它们根本不是“哪个更强”而是各自覆盖了不同区间的用户诉求。选择端云协同恰恰是为了把直线的稳定和曲线的高上限合并起来让体验变成“网络好时更聪明网络差时也基本可用”。3. 拆解一套端云协同分配方案以“方舟方案”为例3.1 一个典型AI硬件的工作流拆分全链路我以自己参与过的AI眼镜项目为例把一条完整交互流水线拆给你看。用户戴着眼镜说了句“前面那栋楼是什么风格”这条链路至少要经过六个环节本地唤醒、本地声音断句、语音识别、语义理解、知识/视觉检索、答案生成。我们调研后发现这六个环节对算力和网络的要求完全不同。本地唤醒用约3M参数的小模型就够了在NPU上跑一次不超过10毫秒功耗极低这个必须留在端侧。声音断句也是个轻量活儿训练一个端到端的VAD稳定且不费资源。语音识别则处于中间地带如果只识别几十个高频指令端侧就能做但要识别自由语音、人名、地名还是得上云借助云端声学模型和语言模型来提升准确率。语义理解这道环节最纠结端侧轻量模型能分出“问天气、问百科、控制设备”这种粗粒度意图但无法处理长上下文和模糊指代所以适合用端侧做初筛云端做精排。知识检索和开放生成则几乎只能依赖云端因为要拼接上下文、检索知识库、生成自然语言段落这不是端侧小模型能完成的任务。最终我们把这六个环节分成三组A组必须端侧唤醒、断句、B组必须云端知识检索、开放生成、C组按网络和预算动态调度语音识别、语义理解。这就是端云协同最核心的设计思想不是什么都上云也不是什么都本地做而是按任务特性分配。3.2 路由策略什么流量本地算什么流量上云光分类还不够得有一套能在运行时做决定的路由策略。我们参考了“方舟方案”公开分享里的一些思路最终实现了一个轻量的决策器它在端侧常驻持有每个任务的预算表和当前网络状态。决策器的输入信号主要有四个当前网络往返时延、最近一次云端调用的成功率、本机剩余算力和内存水位、任务的置信度阈值。输出则是三个动作本地执行、上云执行、双路并行后合并。举个例子。唤醒后的语音识别决策器先查网络RTT如果小于300毫秒且最近成功率高于95%直接上云识别换取更高准确率如果网络抖动明显就切到端侧离线词表先做一轮粗识别同时不再等云端结果。语义理解则更激进一些端侧轻量模型先产出一个结构化意图和若干个候选槽位如果整体置信度超过0.85就允许云端模型在“这个意图框架内”补全细节如果端侧置信度偏低就让云端完全接管理解。这种“端侧搭骨架、云端填血肉”的方式把两边长处都用了起来。3.3 断网降级和切换机制用户体验的最后防线端云协同方案里断网降级是最容易被忽略、但最要命的部分。很多团队把“上云”设计成唯一路径断网就等于功能停摆。我们当时的做法是分三级降级。第一级网络变差RTT超过1秒云端响应的超时窗口从3秒放宽到5秒同时端侧小模型开始并行产出结果谁先出就先用谁。第二级网络完全不可用所有C组任务全部切到端侧离线模板设备只能理解预先配置好的几十条短指令比如“打开灯”“播放下一首”“提醒我喝水”这些指令集内置在固件里不依赖任何云端能力。第三级设备检测到网络长时间不可用直接主动提示用户“当前为离线模式”同时把用户的高频请求记录在本地队列等网络恢复后一次性同步处理。这套降级策略上线前我们最担心的是用户觉得离线模式“太蠢”。实际上线后发现离线模式下设备能完成的高频控制动作已经覆盖了日常使用率最高的那批操作用户反馈出奇的好——因为在真正没网的场景里能响应总比“转圈圈”强得多。3.4 结果融合置信度裁决与安全兜底端云协同不光是“流量分配”还有“结果融合”的问题。端侧模型和云端模型同时返回结果时听谁的这需要一套裁决规则。我们的做法是优先信云端高置信度结果但加了三个约束第一云端结果必须匹配端侧识别出的粗粒度意图如果端侧认为是“控制类”云端却生成了一整段故事这个结果直接丢弃第二输出内容要做本地敏感词过滤防止开放生成带来违规内容第三凡是涉及设备控制类指令必须落在端侧预置的控制白名单里云端只能生成参数值不能生成动作本身。这个设计相当于是给云端模型戴上了一个缰绳它依然能跑得快但不会跑到界外去。这轮改造花了我们大概六周时间代码量并不大真正的复杂度来自规则梳理和异常场景枚举。但上线后的效果非常直接端到端的首响延迟从纯云方案的2.1秒降到了0.8秒以内断网场景的可服务率从0提升到了68%云端调用量则下降了约35%。4. 端云协同的踩坑实录从故障链路到最终修复4.1 坑一会话状态不同步导致的“失忆”困境第一个坑在端云协同改造的早期就暴露了。设备接入端云协同后用户和助手对话时端侧会先识别本轮意图再带着上下文去云上生成。但云端维护的会话状态和端侧本地记忆经常脱节用户说“刚才我说要记住的那个地址”云端根本不知道“刚才”指的是什么。排查了很久才发现问题出在状态分片上端侧只记录了自己处理过的控制指令云端则单独维护了一份自由对话的上下文两边没有同步机制。修复方式是引入状态快照机制每轮交互结束时端侧把对话摘要和关键槽位打包写进一个轻量状态文件云端每次调用都带着这份状态文件云端生成结束后再回传新的摘要。这样一来“失忆”问题基本消失代价只是每次请求多带几百字节的状态信息完全可以接受。这件事让我印象很深因为端云协同不是简单的“两边都要”而是两套系统要共用同一个记忆空间任何一边单方面记东西另一边都会掉链子。4.2 坑二多层重试叠加造成的超时雪崩第二个坑更隐蔽。我们最初在设计超时策略时给端侧、云端SDK、业务逻辑层各设了一套重试机制。三套机制彼此独立结果某次云服务节点抖动端侧先重试了一次云端SDK又自动重试了一次业务逻辑层看到超时又发起第三次请求最终用户等了整整9秒才收到失败提示体验直接崩溃。我们后来用分段埋点复盘定位到链路里叠加了三层重试总耗时等于三次独立的超时等待之和。这有点像高速上连环追尾不是某个环节出大问题而是每个环节都多等了一拍叠在一起就成了事故。最终修复方案是全局统一超时预算端到端总预算4.5秒分配给网络请求2秒、云端生成2秒、本地处理0.5秒任何一层用完预算都立即返回且只允许最外层做一次重试。改造后P95首响耗时从7.8秒降到了2.1秒效果立竿见影。4.3 坑三端侧小模型丢意图云端大模型“不敢抢答”第三个坑来自意图冲突。我们端侧的意图分类模型大约只有50M量级它能识别“开灯”“查天气”这种刻板指令但遇到“把灯调成适合看书的样子”这种模糊表达时它分不出是控制类还是问答类最后给云端传了一个错误意图。云端模型虽然理解能力很强但看到端侧已经填了结构化指令反而倾向于“服从”这个错误框架于是生成了一堆“灯”相关的没意义文案。这个坑的根子在于我们给云端模型灌了太多端侧约束。端侧模型置信度不高的时候不应该把自己的猜测强加给云端。修复方式也很直接端侧输出的意图必须附置信度低于阈值的意图不传给云端让云端重新理解云端模型收到的端侧信息如果和用户问题在语义上明显不一致也必须有权忽略。简单说就是让云端既“有约束”也“有主见”不能让它在错误的框架里将错就错。4.4 改造前后的数据对比自己骗不了自己这轮端云协同改造做完后我们整理了一份内部对比数据几个核心指标的变化非常直观。指标纯云端方案端云协同方案变化端到端首响延迟平均2.1s0.8s下降62%端到端首响延迟P957.8s2.1s下降73%云端调用量单日单设备约86次约56次下降35%断网场景可服务率0%68%显著提升单设备月度云成本估算约28元约18元下降36%复杂语义理解准确率94.2%93.1%基本持平复杂语义准确率略降了1个百分点原因是少量请求在弱网时走了端侧重规则损失了一些灵活度。但这是我们会主动接受的代价——毕竟准确率从94%降到93%用户几乎感知不到而延迟、成本、可服务率这些维度的改善是全方位的。好的端云协同从来不是追求每一项指标都最优而是在用户最在意的几个指标之间取得平衡。5. 给硬件团队的选择决策清单5.1 三类任务分类法先别谈架构先给任务分类如果你现在正要做一个AI硬件我的第一条建议是别急着选端侧还是云端先把产品要做的任务列出来全部分成三类。第一类是“必须端侧”的任务包括唤醒词检测、物理安全事件判断、低延迟控制指令、人脸/人体本地检测。这类任务的特点是对时延极度敏感或者涉及核心隐私数据根本不该离开设备。第二类是“必须云端”的任务包括开放领域问答、长文本生成、跨语种翻译、复杂知识检索。这类任务需要大模型能力端侧无论如何也顶不上来。第三类是“可调度”的任务包括语音识别中的自由句式转写、多模态场景理解、意图槽位抽取。它们的特征是端侧能做但效果一般云端效果好但有成本需要按网络质量动态分配。分类完成后你大概率会发现真正需要纠结的只有第三类。第一类直接上端侧第二类直接上云这是不需要争议的。把精力集中在第三类任务的调度策略上才是端云协同的用武之地。5.2 四种产品画像的参考配置不同价位、不同形态的AI硬件端云协同的侧重完全不同。我按自己做过的项目经验整理了几类典型产品的参考配置。低功耗纽扣设备比如智能胸牌、老人定位卡整机电池小、算力弱最合理的方式是“全端侧模板”预设指令词表云端只做日志回传不参与实时交互。百元级智能家居设备比如台灯、插座、闹钟端侧负责控制类指令和本地自动化规则云端只承担开放问答和知识型对话且必须做离线降级。千元级AI眼镜、AI耳机这是端云协同的主战场按第三节的路由策略做分层调度端侧管唤醒、断句、粗意图云上管生成和检索还要把状态同步和超时预算做扎实。纯云端IPC比如摄像头监测设备绝大多数计算上云但本地必须保留一个移动侦测和离线录像的兜底开关否则网络一断就变成摆设。5.3 我个人的几条经验最后分享几条做端云协同的实际体会。第一端云协同不是架构师用来秀肌肉的而是以“用户最不能忍受的失败”为起点。把它当起点你会发现你自然会选择在某几个环节放端侧模型来兜底而不是为了情怀把什么能力都塞到本地。第二云成本一定要做实时监控仪表盘按设备维度、功能维度、时间段维度拆开看。很多团队是月底收到账单才傻眼但那时候已经晚了。实时看数据的好处是能尽早发现异常路由比如某个场景的请求异常走高通常是路由规则写错了。第三端侧模型别指望一次部署永远不更新。我建议至少按季度做一次微调把上一季度用户交互中置信度偏低、误判较高的case收集起来做增量训练后重新量化再OTA上去。这个节奏能让端侧小模型逐渐跟上用户真实使用习惯比一次性投入一个大模型划算得多。如果你只记住一句话那就是端侧模型和云端API本来就不该是对立关系它们只是一个任务的两头哪个能解决主要矛盾就用哪个而端云协同就是说服它们分工合作的那层胶水。做AI硬件最忌讳的不是算力不够而是脑子里只有“二选一”这一个选项。 
长河君 · 2026/10/10 7:17:31 · 阅读 1.2k 端云协同实战指南：AI硬件端侧模型与云端API的分配策略
做AI硬件产品这些年被问到最多的一句话就是“端侧模型和云端API到底哪个更适合跑在硬件上”问的人有做AI眼镜的、做智能音箱的也有做扫地机器人、智能门锁想加语音助手的。每次我都很难给出一个二选一的答案因为真正把设备量产过一遍就会明白这不是一道单选题而是一道分配题。最近圈子里被反复拿出来讨论的“端云协同”思路恰好就是在回答这个怎么分配的问题。我今天准备拿自己实际参与过的项目当例子把端侧和云端这笔账彻底算清楚也聊聊内外网流行的“方舟方案”背后那套路由逻辑替AI硬件团队把魂儿找回来。1. 这个问题为什么在最近一年突然变得尖锐起来1.1 端侧芯片的“甜点算力”和智能交互的需求错位先说个很多人忽略的事实市面上绝大多数端侧AI芯片真正的“甜点算力区”其实很窄。做语音唤醒、活动检测、简单场景识别这些活儿端侧芯片干得很漂亮功耗只有几毫瓦到几十毫瓦效果稳定省心。但一旦把任务从“唤醒”升级到“连续对话”“开放语义理解”“多模态问答”算力需求会瞬间跳两个数量级内存需求也跟着起飞。这不是芯片厂商不努力而是物理约束摆在那里。一个跑在设备端的大语言模型哪怕只有1B参数量化到2bit光权重就需要500MB左右运行时要再加激活值、KV Cache、临时缓冲整体内存占用能到1GB以上。而普通消费级AI硬件比如一台智能台灯、一个门铃整机物料成本可能才几十元你让它为“更聪明”多掏出几十元的内存和NPU预算产品根本做不下去。所以端侧芯片真正舒服的区间是“规则明确、输出受限、时延敏感”的任务。这类任务用端侧模型做得又快又稳几乎不耗什么电比如关键词识别、人体存在检测、异常声音判断。可一旦越过这道线想让设备真正“懂”用户端侧那点算力就很难支撑了。需求错位带来的直接结果就是很多产品嘴上说着端侧为主身体却很诚实地把所有智能逻辑全塞进了云里。1.2 模型能力迭代太快端侧存储成了新的瓶颈另一个被低估的问题是模型更新。云端API的好处是模型升级跟你完全无关今天你在调用的接口可能三天前已经换了底模效果悄悄变好了。但端侧模型不行它烧进固件里、跑在内存里、被量化到特定精度每一版升级都意味着研发、测试、灰度、OTA推送一整套流程。最难受的是带宽和整机存储。一个几百MB的模型升级包推给在线设备要好几天才能全覆盖还会产生不低的CDN流量成本。如果用户设备长期离线他只能用旧模型体验和新设备出现明显割裂。很多团队为了省事干脆把“大模型能力”全部放云端让端侧只跑一些很难变动的轻量规则这样一来端侧模型倒是好维护了可产品也会因此变得很“笨”很多本可以在本地解决的交互非要绕一圈上云。我见过一个做儿童故事机的团队早期把故事理解、语音合成全放在端侧后来想引入“开放式问答”功能发现现有芯片根本跑不动新模型整机存储也不够。最后他们选择在端侧保留“聆听和打断检测”把问答能力切到云端API才把功能上线。这个案例很典型不是他们不想端侧而是端侧更新的速度和成本让他们耗不起。1.3 为什么“网上都说端侧好”很多产品最后还是上了云这里有个很割裂的现象。你去逛开发者社区几乎人人都在喊端侧推理是未来隐私好、延迟低、离线可用说得头头是道。可真正去看那些已经量产的硬件产品你会发现大量交互逻辑还是依赖云端API。原因不复杂。第一上云最快。接入一个大模型API一两天就能让设备“能聊会道”而端侧部署要从模型裁剪、量化、算子适配一路干到多芯片平台兼容没有两三个月下不来。第二上云效果最好。云端跑的是10B、100B级别的模型理解能力、生成质量、上下文长度端侧模型很难比得上。第三上云的成本虽然是持续的但单品研发费用被压得很低对急于出货的团队来说“先上云把功能落地再慢慢优化”是唯一现实的选择。但这些选择背后埋了一颗雷一旦用户量起来云端调用费用、并发压力、断网体验都会集中爆发。之前有个做智能门锁的项目第一版全部逻辑走云端结果物业区域网络一抖动门锁就“思考”很久用户直接投诉退款。到这一步大家才会回头去算端侧那笔账才会愿意认真研究端云协同到底怎么做。2. 把端侧和云端的账本摊开算力、成本、隐私、体验2.1 端侧模型的真实成本不是免费而是钱花在了物料清单上很多人觉得端侧模型“不花钱”这是最大的误解。端侧模型确实不产生按次计费的费用但它的成本藏在了硬件物料清单里。最直观的就是内存和算力芯片。我们当时评估过在一款AI眼镜上跑一个精简版多模态模型需要额外增加2GB LPDDR4X内存量产采购成本大约是7到10美元NPU推理单元也要用更好一档的否则无法在30毫秒内完成一帧画面的理解。这一加整机成本立刻上升15%以上。对于定价在千元以下的消费电子产品10美元足以决定这个产品是盈利还是亏本。这还没算研发成本。把一个开放模型移植到某个特定芯片平台上要做算子对齐、逐层验证、量化误差评估一套流程下来通常要两个月的人工。如果芯片平台不止一个——比如高通的平台、瑞芯微的平台、全志的平台——每个平台都要单独适配维护成本按倍数上涨。所以端侧模型的真实成本是“一次性研发成本每台物料成本持续OTA成本”的叠加它不等于零只是它的边际成本不随使用次数变化。2.2 云端API的真实成本账面很便宜叠加后很惊悚云端API的计价方式通常是按token算市面主流大模型接口输入侧大概是每百万token几元输出侧每百万token十几二十元。单看单价会觉得很便宜可只要把用户真实使用场景叠加进来数字就会变得很惊悚。以AI眼镜的“识物问答”功能为例。用户对着一盆植物拍照云端要接收图像编码后的信息加上用户语音转成的文字再生成一段回答。一次完整交互大概消耗500到1500个token。假设一个重度用户每天触发50次一个月就是约5.1万次调用总token消耗可能在2000万到4000万之间。再乘以设备出货量哪怕只有一万台活跃设备每月的云端账单就是六位数人民币。这还只是单功能如果同时开语音助手、视觉问答、闲聊这多个能力成本还要翻几倍。更麻烦的是成本结构不是线性的。为了保障用户体验你得做并发预留高峰时段的GPU实例费用、内容安全检测的额外调用、语音识别与合成费用全部会叠加到同一个账单里。很多团队做完一轮小规模公测就开始焦虑了因为他们发现新增一个用户的边际成本已经接近甚至超过了硬件毛利。2.3 隐私不是口号谁能真正不碰用户数据隐私问题在技术圈经常被当成“合规话术”但在AI硬件场景里它是非常现实的工程约束。智能门锁要处理门口的访客画面AI眼镜要持续观察用户眼前的世界智能录音笔要保存对话内容。这些数据一旦出了设备就要面临传输加密、云端存储、访问审计等一系列问题任何一个环节出纰漏都可能变成公关事故。端侧模型天然有隐私优势数据不出设备处理完就丢从源头上避免了“把原始录音传到服务器”这种操作。但端侧模型也有一个容易被忽视的问题为了在有限资源下识别意图它往往需要把原始音频或图像压缩、量化这个压缩过程本身就可能丢信息甚至产生误判。如果想既保护隐私又保证理解质量就必须做“先在端侧做结构化只把非敏感的语义信息上云”这类折中设计而这就是端云协同的雏形。2.4 体验维度延迟、流畅度、离线兜底从体验指标看端侧和云端的分水岭非常清晰。端侧推理延迟极低语音唤醒通常几十毫秒内完成画面识别也是百毫秒级别而且完全不受网络影响。云端API的延迟则受链路影响很大正常4G/5G网络下一个简单问答也要600毫秒起步加上生成时间整体响应往往在1.5到3秒之间。如果是弱网环境五秒开外都很正常。这意味着纯云端方案的用户体验是一条“敏感的折线”网络好时还算顺滑网络稍差就卡顿断网就彻底瘫痪。纯端侧方案则是“稳定的直线”响应快但天花板低复杂问题直接不会。把这两个方案放在一起对比你会发现它们根本不是“哪个更强”而是各自覆盖了不同区间的用户诉求。选择端云协同恰恰是为了把直线的稳定和曲线的高上限合并起来让体验变成“网络好时更聪明网络差时也基本可用”。3. 拆解一套端云协同分配方案以“方舟方案”为例3.1 一个典型AI硬件的工作流拆分全链路我以自己参与过的AI眼镜项目为例把一条完整交互流水线拆给你看。用户戴着眼镜说了句“前面那栋楼是什么风格”这条链路至少要经过六个环节本地唤醒、本地声音断句、语音识别、语义理解、知识/视觉检索、答案生成。我们调研后发现这六个环节对算力和网络的要求完全不同。本地唤醒用约3M参数的小模型就够了在NPU上跑一次不超过10毫秒功耗极低这个必须留在端侧。声音断句也是个轻量活儿训练一个端到端的VAD稳定且不费资源。语音识别则处于中间地带如果只识别几十个高频指令端侧就能做但要识别自由语音、人名、地名还是得上云借助云端声学模型和语言模型来提升准确率。语义理解这道环节最纠结端侧轻量模型能分出“问天气、问百科、控制设备”这种粗粒度意图但无法处理长上下文和模糊指代所以适合用端侧做初筛云端做精排。知识检索和开放生成则几乎只能依赖云端因为要拼接上下文、检索知识库、生成自然语言段落这不是端侧小模型能完成的任务。最终我们把这六个环节分成三组A组必须端侧唤醒、断句、B组必须云端知识检索、开放生成、C组按网络和预算动态调度语音识别、语义理解。这就是端云协同最核心的设计思想不是什么都上云也不是什么都本地做而是按任务特性分配。3.2 路由策略什么流量本地算什么流量上云光分类还不够得有一套能在运行时做决定的路由策略。我们参考了“方舟方案”公开分享里的一些思路最终实现了一个轻量的决策器它在端侧常驻持有每个任务的预算表和当前网络状态。决策器的输入信号主要有四个当前网络往返时延、最近一次云端调用的成功率、本机剩余算力和内存水位、任务的置信度阈值。输出则是三个动作本地执行、上云执行、双路并行后合并。举个例子。唤醒后的语音识别决策器先查网络RTT如果小于300毫秒且最近成功率高于95%直接上云识别换取更高准确率如果网络抖动明显就切到端侧离线词表先做一轮粗识别同时不再等云端结果。语义理解则更激进一些端侧轻量模型先产出一个结构化意图和若干个候选槽位如果整体置信度超过0.85就允许云端模型在“这个意图框架内”补全细节如果端侧置信度偏低就让云端完全接管理解。这种“端侧搭骨架、云端填血肉”的方式把两边长处都用了起来。3.3 断网降级和切换机制用户体验的最后防线端云协同方案里断网降级是最容易被忽略、但最要命的部分。很多团队把“上云”设计成唯一路径断网就等于功能停摆。我们当时的做法是分三级降级。第一级网络变差RTT超过1秒云端响应的超时窗口从3秒放宽到5秒同时端侧小模型开始并行产出结果谁先出就先用谁。第二级网络完全不可用所有C组任务全部切到端侧离线模板设备只能理解预先配置好的几十条短指令比如“打开灯”“播放下一首”“提醒我喝水”这些指令集内置在固件里不依赖任何云端能力。第三级设备检测到网络长时间不可用直接主动提示用户“当前为离线模式”同时把用户的高频请求记录在本地队列等网络恢复后一次性同步处理。这套降级策略上线前我们最担心的是用户觉得离线模式“太蠢”。实际上线后发现离线模式下设备能完成的高频控制动作已经覆盖了日常使用率最高的那批操作用户反馈出奇的好——因为在真正没网的场景里能响应总比“转圈圈”强得多。3.4 结果融合置信度裁决与安全兜底端云协同不光是“流量分配”还有“结果融合”的问题。端侧模型和云端模型同时返回结果时听谁的这需要一套裁决规则。我们的做法是优先信云端高置信度结果但加了三个约束第一云端结果必须匹配端侧识别出的粗粒度意图如果端侧认为是“控制类”云端却生成了一整段故事这个结果直接丢弃第二输出内容要做本地敏感词过滤防止开放生成带来违规内容第三凡是涉及设备控制类指令必须落在端侧预置的控制白名单里云端只能生成参数值不能生成动作本身。这个设计相当于是给云端模型戴上了一个缰绳它依然能跑得快但不会跑到界外去。这轮改造花了我们大概六周时间代码量并不大真正的复杂度来自规则梳理和异常场景枚举。但上线后的效果非常直接端到端的首响延迟从纯云方案的2.1秒降到了0.8秒以内断网场景的可服务率从0提升到了68%云端调用量则下降了约35%。4. 端云协同的踩坑实录从故障链路到最终修复4.1 坑一会话状态不同步导致的“失忆”困境第一个坑在端云协同改造的早期就暴露了。设备接入端云协同后用户和助手对话时端侧会先识别本轮意图再带着上下文去云上生成。但云端维护的会话状态和端侧本地记忆经常脱节用户说“刚才我说要记住的那个地址”云端根本不知道“刚才”指的是什么。排查了很久才发现问题出在状态分片上端侧只记录了自己处理过的控制指令云端则单独维护了一份自由对话的上下文两边没有同步机制。修复方式是引入状态快照机制每轮交互结束时端侧把对话摘要和关键槽位打包写进一个轻量状态文件云端每次调用都带着这份状态文件云端生成结束后再回传新的摘要。这样一来“失忆”问题基本消失代价只是每次请求多带几百字节的状态信息完全可以接受。这件事让我印象很深因为端云协同不是简单的“两边都要”而是两套系统要共用同一个记忆空间任何一边单方面记东西另一边都会掉链子。4.2 坑二多层重试叠加造成的超时雪崩第二个坑更隐蔽。我们最初在设计超时策略时给端侧、云端SDK、业务逻辑层各设了一套重试机制。三套机制彼此独立结果某次云服务节点抖动端侧先重试了一次云端SDK又自动重试了一次业务逻辑层看到超时又发起第三次请求最终用户等了整整9秒才收到失败提示体验直接崩溃。我们后来用分段埋点复盘定位到链路里叠加了三层重试总耗时等于三次独立的超时等待之和。这有点像高速上连环追尾不是某个环节出大问题而是每个环节都多等了一拍叠在一起就成了事故。最终修复方案是全局统一超时预算端到端总预算4.5秒分配给网络请求2秒、云端生成2秒、本地处理0.5秒任何一层用完预算都立即返回且只允许最外层做一次重试。改造后P95首响耗时从7.8秒降到了2.1秒效果立竿见影。4.3 坑三端侧小模型丢意图云端大模型“不敢抢答”第三个坑来自意图冲突。我们端侧的意图分类模型大约只有50M量级它能识别“开灯”“查天气”这种刻板指令但遇到“把灯调成适合看书的样子”这种模糊表达时它分不出是控制类还是问答类最后给云端传了一个错误意图。云端模型虽然理解能力很强但看到端侧已经填了结构化指令反而倾向于“服从”这个错误框架于是生成了一堆“灯”相关的没意义文案。这个坑的根子在于我们给云端模型灌了太多端侧约束。端侧模型置信度不高的时候不应该把自己的猜测强加给云端。修复方式也很直接端侧输出的意图必须附置信度低于阈值的意图不传给云端让云端重新理解云端模型收到的端侧信息如果和用户问题在语义上明显不一致也必须有权忽略。简单说就是让云端既“有约束”也“有主见”不能让它在错误的框架里将错就错。4.4 改造前后的数据对比自己骗不了自己这轮端云协同改造做完后我们整理了一份内部对比数据几个核心指标的变化非常直观。指标纯云端方案端云协同方案变化端到端首响延迟平均2.1s0.8s下降62%端到端首响延迟P957.8s2.1s下降73%云端调用量单日单设备约86次约56次下降35%断网场景可服务率0%68%显著提升单设备月度云成本估算约28元约18元下降36%复杂语义理解准确率94.2%93.1%基本持平复杂语义准确率略降了1个百分点原因是少量请求在弱网时走了端侧重规则损失了一些灵活度。但这是我们会主动接受的代价——毕竟准确率从94%降到93%用户几乎感知不到而延迟、成本、可服务率这些维度的改善是全方位的。好的端云协同从来不是追求每一项指标都最优而是在用户最在意的几个指标之间取得平衡。5. 给硬件团队的选择决策清单5.1 三类任务分类法先别谈架构先给任务分类如果你现在正要做一个AI硬件我的第一条建议是别急着选端侧还是云端先把产品要做的任务列出来全部分成三类。第一类是“必须端侧”的任务包括唤醒词检测、物理安全事件判断、低延迟控制指令、人脸/人体本地检测。这类任务的特点是对时延极度敏感或者涉及核心隐私数据根本不该离开设备。第二类是“必须云端”的任务包括开放领域问答、长文本生成、跨语种翻译、复杂知识检索。这类任务需要大模型能力端侧无论如何也顶不上来。第三类是“可调度”的任务包括语音识别中的自由句式转写、多模态场景理解、意图槽位抽取。它们的特征是端侧能做但效果一般云端效果好但有成本需要按网络质量动态分配。分类完成后你大概率会发现真正需要纠结的只有第三类。第一类直接上端侧第二类直接上云这是不需要争议的。把精力集中在第三类任务的调度策略上才是端云协同的用武之地。5.2 四种产品画像的参考配置不同价位、不同形态的AI硬件端云协同的侧重完全不同。我按自己做过的项目经验整理了几类典型产品的参考配置。低功耗纽扣设备比如智能胸牌、老人定位卡整机电池小、算力弱最合理的方式是“全端侧模板”预设指令词表云端只做日志回传不参与实时交互。百元级智能家居设备比如台灯、插座、闹钟端侧负责控制类指令和本地自动化规则云端只承担开放问答和知识型对话且必须做离线降级。千元级AI眼镜、AI耳机这是端云协同的主战场按第三节的路由策略做分层调度端侧管唤醒、断句、粗意图云上管生成和检索还要把状态同步和超时预算做扎实。纯云端IPC比如摄像头监测设备绝大多数计算上云但本地必须保留一个移动侦测和离线录像的兜底开关否则网络一断就变成摆设。5.3 我个人的几条经验最后分享几条做端云协同的实际体会。第一端云协同不是架构师用来秀肌肉的而是以“用户最不能忍受的失败”为起点。把它当起点你会发现你自然会选择在某几个环节放端侧模型来兜底而不是为了情怀把什么能力都塞到本地。第二云成本一定要做实时监控仪表盘按设备维度、功能维度、时间段维度拆开看。很多团队是月底收到账单才傻眼但那时候已经晚了。实时看数据的好处是能尽早发现异常路由比如某个场景的请求异常走高通常是路由规则写错了。第三端侧模型别指望一次部署永远不更新。我建议至少按季度做一次微调把上一季度用户交互中置信度偏低、误判较高的case收集起来做增量训练后重新量化再OTA上去。这个节奏能让端侧小模型逐渐跟上用户真实使用习惯比一次性投入一个大模型划算得多。如果你只记住一句话那就是端侧模型和云端API本来就不该是对立关系它们只是一个任务的两头哪个能解决主要矛盾就用哪个而端云协同就是说服它们分工合作的那层胶水。做AI硬件最忌讳的不是算力不够而是脑子里只有“二选一”这一个选项。