先说一个我自己趟过的结论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请求-响应每次对话都要经历完整的建链和断链在移动网络下体验很差。后来针对流式输出场景引入了SSEServer-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混合架构接近04G弱网 - 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能力连接层做好流式通信和弱网容错——这套思路已经被我反复验证过稳。最后分享一个实用小技巧刚开始搭服务端能力层时宁可把所有模型调用先收敛到一个不起眼的独立模块里也别图方便散落到业务代码各处。等你要换模型商或者上线新模型的时候会感谢当初这个不起眼的决定。