“把大模型塞进手机浏览器”这句话，常被理解成把所有推理都搬回设备端，这其实是误读。真正可落地的方案，是让三层各干各最擅长的事：端侧管隐私和秒级响应，边缘节点管中等算力和就近调度，云端管重推理与知识更新。协同的重点不在“端”，而在“协”。
架构上，第一道关卡是一个跑在设备里的请求路由器。它综合四个信号决定任务去向：任务复杂度、当前网络质量、设备电量和温度、数据的隐私等级。简单高频的请求留在本地，中等任务发给离用户最近的边缘节点，只有真正的硬骨头才回源到中心云。这个路由器本身要足够轻，判断逻辑宁可保守，切错一次的代价远小于多等一次网络往返。
端侧放什么模型，决定了这套架构的成色。经验区间是0.5B到2B参数的量化小模型，专职三类高频任务：输入补全和润色、敏感信息的本地脱敏、意图分类与路由。不要指望端侧模型聪明，它只需要“知道自己不知道”——把输出置信度的阈值校准好，低置信就上交，分类错误就不会演变成体验事故。
边缘层通常挂7B到13B级别的模型，处理摘要、改写、常规问答这类中等难度任务。这一层的工程价值在于延迟：就近节点把网络往返压到几十毫秒，同时避免了端侧的显存焦虑。云端则专注干重活：长上下文、复杂推理、全库检索增强，以及承担模型版本的持续更新。
四个工程细节最容易踩坑。一是模型分发：端侧模型要做版本管理和差量下载，配合Cache API与IndexedDB缓存，绝不能让用户重复下载几十兆的权重。二是一致性：同一类任务在三层之间输出的语气和质量要有可比较的评测基线，否则用户会觉得产品人格分裂。三是降级链路：断网或低功耗模式下，端侧必须能独立交付一个基本可用的体验，而不是转圈报错。四是配额与计费：边缘和云端的调用要在网关处统一计量，防止路由器判断失误时成本失控。
拿一个智能助手的真实拆法举例：用户输入先过端侧小模型，意图分类的P95延迟在200毫秒以内，涉及证件号的文本在本地完成脱敏；常规问题命中边缘节点的中等模型直接流式返回；只有需要翻知识库或做多步推理的，才回源云端大模型。这样跑下来，大约七成流量停留在端侧和边缘，云端GPU的账单肉眼可见地下来了，首字延迟则从一次跨国往返，变成了接近本地读取的手感。
随着设备神经网络处理器通过WebNN之类的接口逐步开放给浏览器，端和边的算力界限还会继续模糊。但无论硬件怎么变，这套架构的骨架不会过时：按任务的复杂度、隐私和延迟三个维度分流，让每一层只承担自己付得起的成本。
申请创业报道，分享创业好点子。点击此处，共同探讨创业新机遇！
