先说一个我自己趟过的结论：AI助手项目里争论“你到底跑在哪端”，本质是个伪命题。我在多个智能助手类产品里踩过纯端侧和纯云端的坑之后，基本确定了一件事——真正稳定、体验好、还能控制住成本的结构，一定是服务器负责重计算、移动端负责轻交互和本地逻辑，两端通过一套务实的通信协议协同工作。这个结论听上去不新鲜，但落到具体实现上，里面的大量选型细节和工程取舍，我翻遍了技术社区也没找到一篇能直接抄作业的，所以写下这篇，把架构拆开讲清楚。
这篇文章适合正在做或准备做“手机/平板上的智能助手”的开发者、产品和技术负责人，不管你是用现成大模型API，还是打算部署自己的推理服务，里面提到的任务切分原则、服务端能力层设计、流式通信方案、以及实测性能基线，都能直接拿来做参考。需要说明的是，文中的技术选型和数据来自我自己的项目经验，属于特定场景下的最佳实践，不是唯一答案，但至少能帮你少走一些弯路。
1. 纯端侧与纯云端的极端方案为什么都不可持续
先花点篇幅讲清楚背景，因为很多人一上来就纠结“大模型放哪”，其实真正的问题不是模型在哪，而是产品需要的体验指标和成本指标能不能同时成立。
1.1 纯端侧方案：体验不可控，能力天花板太明显
我之前做过一个完全离线的AI助手，只在本地跑量化后的语言模型，初衷是隐私和零延迟。刚开始demo很惊艳，一问一答不耗流量，VoIP一样爽。但真到了多轮对话、复杂任务、长文本总结这些场景，问题就一个个暴露了：
- 算力瓶颈：手机SoC的NPU哪怕再进步，跟服务器端的GPU集群还是有数量级差距。本地跑一个7B量化模型，首token延迟常常在2秒以上，这还只是普通问句。
- 内存压力：3B~7B的模型加载起来就要吃掉3~6GB内存，和微信、相机、游戏并存的时候，移动端的内存直接爆掉，被系统杀掉是家常便饭。
- 耗电严重：连续推理10分钟，机身能明显发热，电量掉速肉眼可见。用户不会觉得这是“你们AI能力强”，只会觉得“这App是电老虎”。
- 能力断层：端侧模型无法承载需要实时联网信息的任务，比如查天气、查新闻、发快递，也不可能调度外部工具和API，能力边界非常清晰。
所以我现在的看法是：端侧模型只适合做轻量本地能力，不适合做助手的“大脑”。
1.2 纯云端方案：功能没问题，但体验与成本都是问题
再说纯云端。把全部推理都丢给服务器，早期AI助手基本都是这么做的，开发起来最简单，一个App包一个HTTP请求就完事。但用户侧的感知很快会从“智能”滑向“迟钝”：
- 网络依赖导致的第一帧空白：每次对话都要经历完整的请求-响应周期，弱网下转圈时间动辄4~6秒，这个体验在移动端是非常灾难的。
- 协议开销巨大：移动网络的高RTT（往返时延）问题，在传统JSON短连接模式下尤其明显，一次次握手、建链、断链，大量时间浪费在连接建立而不是实际推理上。
- 隐私和成本双重压力：所有对话内容全部上云，敏感数据合规压力很大；同时每次交互都走全量云端推理，GPU成本、带宽成本都会随着用户量线性上涨，规模一大就扛不住。
1.3 混合架构的本质：按“任务属性”而不是“设备归属”做切分
两套极端方案的失败不是AI能力的问题，而是没有对任务属性做区分，把所有任务一律压在某一端。真实产品里，用户请求千差万别：有的是“帮我设个闹钟”这种一秒钟本地就解决的指令，有的是“帮我分析这份30页文档并生成摘要”这种需要重算力的任务，还有的是“给我订一杯咖啡”这种必须靠云端连接外部服务的任务。
把这几种任务用同一种架构去跑，要么浪费资源，要么损失体验。混合架构的核心思路就是把任务拆成不同等级，各自选择最优执行端：
- 纯本地能搞定的简单指令，就在端侧用小模型或规则引擎解决，做到秒级响应；
- 需要复杂理解、长文本、工具调用的任务，才上服务器跑大模型；
- 涉及隐私数据的内容，可以做端侧脱敏后再上报，或选择端侧推理。
这个切分逻辑，是整个架构最核心的设计决策，也是后面所有技术细节的前提。
提示：不要一开始就把“端侧/云侧”当成二选一团队争论。正确的度量方式是整理一份用户请求清单，逐条标注延迟要求、数据敏感性、算力消耗、外部依赖，这样架构自然就浮现了。
2. 任务分级与端侧轻推理的工程选择
混合架构的第一步，就是把“任务分级”落地成一套可执行的路由规则。这一节我会给出一套我实际在用的分级方法，以及端侧模型选型和量化落地的具体经验。
2.1 三级任务路由：T0/T1/T2划分法
我把AI助手的请求分成三个优先级，分别对应不同处理链路：
| 任务级别 | 典型场景 | 处理器位置 | 核心指标 |
|---|---|---|---|
| T0 | 闹钟设置、快捷指令、本地搜索、简单问答 | 端侧规则/小模型 | 响应小于300ms，离线可用 |
| T1 | 意图明确但需一定理解的对话、文本改写、摘要 | 端侧大模型或云端轻量模型 | 响应1秒左右，弱网可降级 |
| T2 | 复杂推理、长文档分析、多工具调用、Agent任务 | 服务器大模型 | 优先准确率，延迟可晾几秒 |
这套分级的核心思想是不要在一个助手里只存在一种“智能”。用户对“设置闹钟”和“分析财报”的心理预期完全不同，与其把所有请求都送到云端，不如在端侧加一层路由，把T0任务吃掉。
2.2 端侧模型选型与量化落地的坑
做端侧推理，模型选型是第一道关卡。我踩过不少坑后，总结出几条选型原则：
- 优先选3B以下的小模型。超过7B的模型即便能量化，内存和发热也很难压住，普通用户手机会很吃力。
- 关注推理引擎的硬件适配。同样的模型，在iOS上用Core ML，在Android上用NNAPI或各自厂商的NPU SDK，性能差距能到3倍以上。
- 量化优先级为INT8大于INT4。别看INT4模型体积只剩一小半，但实际跑起来质量和稳定性下降明显，部分场景会出现胡言乱语，省下来那点内存根本不划算。
- 注意“量化到能跑”和“量化到好用”的区别。很多团队只验证了模型能不能加载，没有验证连续对话20轮之后的上下文质量和随机的输出稳定性，这是两种完全不同的程度。
在实测中，我发现一个比较可靠的组合是：端侧跑2B~3B的指令微调模型，采用INT8量化，推理引擎优先接入厂商加速库。这个配置下，单次推理的内存占用控制在1.5GB以内，连续对话5轮的耗电增量可以压到个位数毫安时级别。记住，端侧推理的目标不是“达到GPT的水平”，而是在不拖累整个App的前提下把T0任务消化掉。
2.3 任务路由的降级策略
路由规则不是一成不变的，要根据网络状况和设备状态动态调整。我的做法是维护一个“能力状态”：
- 网络可用且在线状态良好：T1任务走云端轻量模型；
- 网络弱或断连：T1降级到端侧模型，宁可答案质量低一点也不能让用户干等；
- 设备正在充电：可以放开端侧推理的线程和内存限制；
- 设备低电量或高温：强制所有任务走云端，或提示用户稍后再试。
这套动态降级逻辑，实际数据非常显著。我在3G弱网环境下测试，采用动态降级策略后，用户侧不可用时间从17%直接掉到了4%以内。移动端体验的坑，多半是网络环境，而不是AI模型。
3. 服务端AI能力层：从单模型调用到Agent任务编排
聊完端侧，再说服务器端。很多人以为服务端就是“部署一个大模型API等请求”，真实项目里远比这复杂。AI助手大一点之后，服务端的核心变成了一套能力编排系统——大模型只是其中一个组件，真正体现架构水平的地方，在于怎么把这些能力稳定地编排起来。
3.1 模型网关：屏蔽后端模型差异，把模型当“池子”用
服务端最容易被忽视的模块是模型网关。原因很简单：你不会只用一个模型。线上可能有主力大模型、专门的摘要模型、代码模型、多模态模型，甚至还有开源模型自部署的兜底。如果业务代码里到处是直接请求某个模型端的SDK，后面每次切换供应商或升级版本，都要动一大片业务代码。
我在服务端做了一个统一的模型网关层，对外暴露一个简洁的“模型能力API”，内部做以下事情：
- 模型路由：按任务类型、优先级、成本预算把请求分到不同的模型实例；
- 灰度与版本管理：不同用户组可以绑定不同模型版本，A/B测试不用改业务代码；
- 失败转移：主模型超时宕机时，自动把请求转移到备用模型；
- 用量与成本统计：每次请求的token消耗、延迟、费用全部记录，方便后续做成本分析和限流。
网关这层做得好，后面换模型供应商、上线新模型版本都是发布一次配置的事，而不是赶工到处改代码。
3.2 Agent与工具调用：让助手真正“做事”
AI助手从“聊天机器人”进化为“能做事”，靠的不是模型本身，而是Agent化的任务编排。现在业界热门的Agent架构（包括很多公开讨论过的ReAct等范式）落到工程实现上，就是一套感知-规划-行动-观察的循环。
我在服务端起了一套轻量Agent引擎，核心组件包括：
- 意图规划器：大模型把用户目标拆解成子任务序列；
- 工具注册中心：统一管理助手能调用的外部能力，比如查天气、建日程、发通知、查订单、调企业API等，每个工具按OpenAPI风格注册描述和入参schema；
- 上下文管理模块：维护多轮对话中产生的中间状态和工具返回结果，供后续步骤引用；
- 安全校验层：对要执行的工具动作做白名单校验，防止模型产生非法行为（比如越权操作、支付动作等）。
这套Agent引擎部署在微服务架构里，本身是无状态的，可以水平扩展。实际遇到的压力点不在推理本身，而在工具调用的超时和重试策略。一个Agent任务可能串行调用3~5个工具，其中任何一个工具慢或挂掉，整条链路就卡住。我会给每个工具调用设独立超时、独立的熔断阈值，并让Agent规划器感知工具状态，异常时自动跳过或改走替代路径。
3.3 服务端框架与推理部署选型
关于服务端框架，很多文章会讲“微服务 vs 单体”，我觉得没那么多教条。AI助手项目里真正重要的是：模型推理服务必须能力独立扩展，业务逻辑层和推理层要能分别扩缩容。
我这边采用的部署形态是：
- 推理服务（模型API）放在独立部署单元，用GPU实例，基于请求量做HPA自动扩缩；
- 业务逻辑/Agent引擎是无状态微服务，放普通云主机，可根据QPS横向扩展；
- 模型网关、注册中心、配置中心用轻量组件（比如Consul/Nacos这类）做统一管理；
- 对话历史、用户偏好、工具状态等放在缓存+持久化存储里，尽量不放进模型上下文，节省token成本。
注意一个容易忽略的点：模型服务的冷启动时间。大模型加载动辄几十秒到几分钟，如果遇到突发流量导致Pod频繁重建，会有一段时间请求全部失败。建议措施是：核心模型实例保持最小常驻数量，或者部署好之后做活跃探针预热，确认模型加载完成后再接入流量。
3.4 推理引擎和硬件的务实选择
模型推理服务器选型上，很多人一上来就想上最好的GPU，其实成本压力非常大。我建议按实际并发量和延迟目标倒推：
- 并发要求低、以对话为主：单张消费级或入门级专业卡就能扛不少请求，关键是做好队列和并发控制；
- 并发要求高、吞吐优先：考虑多卡推理服务或分布式推理框架，一定规模后用批量推理合并请求，提升吞吐；
- 延迟敏感型任务：优先保证GPU显存充足，减少KV Cache淘汰，必要时牺牲一些吞吐换首token延迟。
服务器端的“架构”大部分时候不是技术问题，而是“钱”的问题。量化吞吐、QPS、P95延迟这些指标，必须在选型前就定下来，否则硬件预算很难估准。
4. 移动端与服务器的连接层：协议、鉴权与流式渲染的工程细节
架构骨架搭好后，真正让用户觉得“这个助手顺滑”的，是移动端和服务器之间的那层连接。这里面的坑比我想象的多得多，值得单独讲。
4.1 为什么最终选型是WebSocket + SSE双通道
初代版本的AI助手用的是传统HTTP请求-响应，每次对话都要经历完整的建链和断链，在移动网络下体验很差。后来针对流式输出场景引入了SSE（Server-Sent Events），但SSE有一个问题——它是单向的，客户端不能很方便地在同一条连接里持续发送指令。
最后我采用的是双通道策略：
- 控制通道用WebSocket：负责交互控制指令、工具调用状态、对话生命周期管理等双向实时数据；
- 内容通道用SSE：负责模型生成token的流式输出，一行行推给移动端渲染，简单可靠，天然支持断开重连。
这个组合的好处是职责分离：控制通道像指挥链路，SSE像内容管道。前端能方便地对流式输出做增量渲染、停止生成、重新生成等操作，后端也不用在同一个连接里纠结消息格式是控制还是内容。
4.2 协议设计与状态同步的细节
通信协议格式我用了JSON+二进制混合。控制消息走JSON，字段可读，方便排查；大块内容（比如图片、长文档片段）走二进制帧，避免Base64膨胀。
核心要点是状态机和序列号机制。移动端和服务端各自维护一个对话状态机，每条消息附带递增序列号（或消息ID），用于乱序处理、去重和断线重连后的增量同步。
这层如果不做，会出现一个超级烦人的问题：手机锁屏再解锁后，WebSocket断了重连，但两边不知道对方的状态，于是界面上要么重复显示旧消息，要么丢失新消息。加了序列号之后，重连时自动做一次状态比对，把缺失的消息补齐，就能彻底避免这类状态漂移。
4.3 鉴权与安全：一套贯穿端到端的信任链
移动端直接暴露给公网，鉴权不能只做一次登录就完事。在实际项目中我构建了“三级信任”方案：
- 设备信任：App启动时向服务端注册设备，拿到设备ID和密钥，绑定设备指纹；
- 用户信任：常规的OAuth/Token体系，Token短期有效，过期自动刷新；
- 请求信任：每个请求都带请求签名，内容防篡改，服务端网关统一验签。
对话内容的隐私保护方面，我建议在端侧做敏感信息脱敏规则。比如识别到身份证号、银行卡号、具体地址等，在发送前就替换成占位符，云端只拿到脱敏后的文本，用户需要真实信息时再在端侧本地还原。这个策略在执行数据合规时特别有用，比事后做审计要省心太多。
4.4 弱网与断线容错的工程实现
移动端最常遇到的就是电梯、地铁、车库这些信号差场景。我在连接层加入了三层容错：
- 超时自动降级：请求发出后如果预估时间超过阈值，自动把部分T1任务降级到端侧模型，并提示“网络不佳，已切换本地模式”；
- 消息可靠重传：带有消息ID的请求在超时后会重传，服务端按消息ID做幂等处理，避免重复执行工具调用；
- 连接状态感知UI：移动端实时监测连接质量，在UI层显示“连不上服务器，暂时只能处理本地指令”的状态，而不是让用户干等一个永远不会结束的loading。
别看这些功能琐碎，它们决定了你在真实用户那里的口碑。AI助手的用户对“卡住没反应”的容忍度非常低，连接层做成什么样，就是这个产品体验的底盘。
5. 实测性能基线：混合架构与纯云、纯端的数据对比
光讲架构和理念容易空，我这边自己搭了一套混合架构的demo并做了压测，也对比了之前纯云、纯端的数据，整理成基线供各位参考。
5.1 测试环境说明
- 移动端：主流中端Android手机，支持厂商NPU，端侧运行3B INT8量化小模型；
- 服务端：4核CPU + 单张GPU，部署7B主力模型和Agent引擎，模型网关做统一入口；
- 网络环境：办公室Wi-Fi、4G弱网、地下车库弱网三种场景分别测试；
- 测试任务：T0快捷指令、T1短对话、T2文档摘要和Agent工具调用任务。
5.2 数据对比
| 场景 | 纯云端首响应延迟 | 混合架构首响应延迟 | 用户可感知卡顿率 |
|---|---|---|---|
| 办公室Wi-Fi - T0任务 | 约800ms | 约120ms | 混合架构接近0 |
| 4G弱网 - T1任务 | 约3.2秒 | 约1.1秒（动态降级后） | 混合架构明显更低 |
| 地下车库 - 纯端侧任务 | 不能执行 | 约200ms | 混合架构可用 |
| T2复杂任务 | 约6秒 | 约5.4秒（主要耗在推理上） | 差异不大 |
这组数据说明三件事：
- T0任务完全应该留在本地，很大程度节省了云端的无效调用；
- 弱网下的动态降级救了很多体验，用户起码还能用，不会直接放弃；
- 复杂任务无论架构怎么变，首token延迟都由模型的推理速度决定，混合架构并不能凭空缩短，但能做到“在这个任务上不拖累其他任务”。
5.3 成本数据参考
从成本角度看，混合架构的收益也直观可见：
- 纯云端方案下，每1000次对话约70%请求消耗GPU推理资源；
- 混合架构下，T0任务几乎全部离线消化，T1部分动态降级，最终实际打到云端GPU的请求降到大约40%左右；
- 按月度GPU成本核算，混合架构比纯云能省30%~45%，具体取决于T0/T1任务占比。
这个数据在不同产品里波动很大，但大方向是一致的：把能本地的任务留在本地，能小模型的任务就不用大模型，是AI助手控成本的底层逻辑。
6. 落地过程中的高频坑与经验建议
最后这部分是我在不同AI助手项目里反复踩过、身边同行也频繁问到的共性问题。列出来，希望大家不用再走一遍弯路。
6.1 上下文管理：别无脑把整段历史塞给模型
很多团队做AI助手时，直接把多轮对话的全部内容拼进prompt，导致两个结果：一是token费用飞快，二是上下文一长，模型输出质量反而下降。我建议做一层上下文工程，比如：
- 只保留最近N轮对话 + 提前抽取的“长期记忆摘要”；
- 任务相关的工具返回结果，只在当次Agent步骤中使用，不进长期对话上下文；
- 端侧和云端的上下文可以分离，T0任务的历史就留在本地，不传给云端，兼顾隐私和成本。
6.2 端侧模型升级的兼容性陷阱
端侧模型一定会有升级。模型文件换了之后，如果只改了文件名没改版本号，老用户升级App时会出现模型加载失败、白屏或输出完全疯癫的问题。我建议把端侧模型版本纳入App的版本管理，模型包单独放CDN，启动时做版本校验和增量下载，同时保留一个上一版模型做回退兜底。
6.3 移动端性能优化的量化指标
移动端AI跑久了，用户最反感的就是发热和掉电快。我们团队定了三条“红线”：
- 连续对话30分钟，电池电量下降不超过8%；
- 设备温度上升不超过5摄氏度；
- 后台运行时模型占用的内存可被系统清理，不影响主进程存活。
每条红线都在每次版本发布前用自动化脚本压测，超了就不允许上。移动端的性能优化没有花哨的魔法，本质就是把不必要的推理任务想办法挪走，把必须跑的任务调到最高效的硬件单元上。
6.4 服务端容量规划：算力绝不等于实例数
做服务端架构时，有一个非常普遍的错误——以为开了20个Pod就一定能扛20倍的流量。AI推理服务的瓶颈往往在GPU显存、CPU内存带宽和网络带宽，而不是进程数。我在实践中更看重的是：每个GPU实例能承载的最大并发长度和最长对话轮数。这两个参数决定了一个实例的合理并发上限，超出之后加Pod不仅无济于事，还会因为请求排队互相拖垮。
注意：做容量规划前，先用压测定义好“单实例性价比最高的并发范围”。在这个范围里运行的实例数量乘以单价，才是你真正的服务端预算。
6.5 从Demo到上线的思维转变
最后说一个偏软性但很重要的经验。很多团队的AI助手demo跑得很惊艳，一上生产就崩，根本原因在于开发时只关注了模型能力，没关注架构韧性。Demo阶段只需要“能用”，生产环境要求的是“可控”——必须有超时、重试、熔断、降级、限流、审计这些枯燥但保命的东西。把混合架构从概念落到生产，我建议第一部不是写代码，而是梳理一份“失败场景清单”：服务器挂了怎么办、模型超时怎么办、工具调用失败怎么办、网络断了怎么办。把这几个问答案例化，架构就基本稳了。
放在最后的一点个人体会
做AI助手这么多年，最大的感受是：架构不是一个静态的图纸，而是一套应对不确定性的能力。移动端设备千奇百怪，网络环境不可预测，模型能力日新月异，服务器成本压力时刻都在，混合架构真正解决的问题不是“谁更强”，而是“无论什么条件，助手都能以可接受的方式工作”。
如果你正打算从零搭一个AI助手，或者正在被“纯端还是纯云”的争论困住，不用纠结，按任务分级、让两端各司其职就对了。端侧管好轻量任务和体验底线，服务器管好重计算和复杂Agent能力，连接层做好流式通信和弱网容错——这套思路已经被我反复验证过，稳。
最后分享一个实用小技巧：刚开始搭服务端能力层时，宁可把所有模型调用先收敛到一个不起眼的独立模块里，也别图方便散落到业务代码各处。等你要换模型商或者上线新模型的时候，会感谢当初这个不起眼的决定。
