WWDC 前后Siri 和 AI 的结合方向一直是讨论焦点。只看演示的话很容易觉得这是一次模型能力升级问一句系统答得聪明了。但从 AI 工程实践的角度看Siri AI 真正值钱的地方并不是某一个模型而是一套把本地推理、服务端推理和分布式推理串起来的混合架构。本地大模型 Agent 负责隐私敏感和个人化任务服务端负责复杂能力和实时数据分布式推理负责把大规模请求压到可接受的延迟。下面按工程落地的顺序拆开讲。1. 先分清Siri AI 不是“大模型塞进手机”而是混合推理架构1.1 入口是对话核心却是任务调度与工具执行很多人对 Siri AI 的第一反应是“对话变聪明了”。但从做 Agent 的角度看对话只是外壳。一个真正能处理用户请求的系统背后至少要经过这几步理解用户意图、找回上下文、拆分任务、决定调用什么工具、执行动作、再把结果组装成自然语言。这一步一步拆下来就会发现Agent 不是一个模型而是一套流程。模型只是流程里负责“理解”和“生成”的组件其他环节比如任务路由、工具调用、缓存、日志、失败重试都属于工程问题。所以判断 Siri AI 这类系统值不值得研究不能只看模型效果要看它如何把不同规模的模型分配给不同任务。这才是本地大模型 Agent 能不能落地的关键。1.2 本地化与云端服务为什么缺一不可苹果这类公司长期强调端侧处理并不只是因为隐私宣传的需要而是有实际工程价值。本地推理能带来三个很直接的好处隐私敏感的数据不需要离开设备。没有网络时也能完成基础任务。省去一次网络往返交互延迟更低。但本地不是万能的。一个很现实的限制是设备的内存、功耗、散热和芯片面积都有限。模型太大要么装不下要么装下了跑不快要么跑一会儿设备就发热降频。服务端推理可以承载更大的模型回答更复杂的问题也能覆盖需要实时更新知识或调用外部数据的场景。缺点是隐私、合规、网络延迟和调用成本都要重新评估。所以真正合理的架构不是二选一而是“能本地才本地必须远端再远端”。1.3 分布式推理在这个架构里扮演什么角色如果只是简单调用一个云端模型接口其实还谈不上分布式推理。分布式推理的意思是一个大模型的参数没办法放进单台机器的单个加速卡或者单台机器扛不住高并发于是把模型切到多台机器上通过网络协作完成一次推理。从本地 Agent 的视角看分布式推理更像一个“能力强大的远程推理后端”。本地 Agent 自己处理不了的任务可以打包成请求发给这个后端等结果回来再继续执行。这正好解释了标题里的“铺垫”服务端和分布式推理不是本地 Agent 的竞争对手而是它走向可用状态的储备粮。先把云端能力做成稳定服务本地 Agent 才能在能力不足时有地方可以求助。2. 为什么服务端和分布式推理是本地 Agent 的“地基”2.1 大模型单机部署的三道坎容量、吞吐和稳定性做过模型部署的人都知道大模型服务不是“装个依赖启动脚本”那么简单。单机部署通常会碰到三道坎。第一道是容量。大模型的参数量很大光权重文件就可能超过单卡显存。放不下就得做量化、层拆分或者内存卸载。量化会损失一点精度内存卸载会让速度明显下降。模型真正跑起来之后还要留出显存给中间激活值和推理上下文。第二道是吞吐。单个模型服务本质上是一个资源池请求多了要排队。如果每来一个请求就从头算一遍处理速度很难满足真实用户等待预期。想要吞吐高就得引入连续批处理、KV Cache 管理和请求调度这些单独写都不容易。第三道是稳定性。模型进程一旦崩溃所有正在排队的请求都会失败。没有健康检查、没有自动重启、没有失败重试线上效果再好也扛不住真实流量。2.2 分布式推理的重点不是炫技而是用并行换延迟有人觉得分布式推理很难是算法问题。实际上分布式推理更接近系统问题。当模型大到单机放不下时可以把不同的层分配到不同机器上让请求像流水线一样依次经过这叫流水线并行。也可以把同一层参数按矩阵切分到多张卡上计算时做集合通信这叫张量并行。还会有多副本并行也就是同一个模型部署多个实例用负载均衡分摊流量。对开发者来说理解这些概念不是为了亲手从头实现而是为了读懂系统的瓶颈在哪里。比如张量并行能降低单卡显存压力但卡之间通信频率高网络带宽不够时性能会很难看。分布式推理真正要解决的问题是在模型规模、响应延迟和部署成本之间找到一个能接受的平衡点。2.3 从 Server Serving 到 Agent Infra中间还要补什么只把模型服务跑起来离 Agent 可用还差得很远。Agent 场景比普通问答多出几层需求要有上下文管理。多轮对话、长文档、用户画像都要在请求之间维护。要有工具调用协议。模型要能输出结构化动作系统要能解析并执行。要有观察和日志。任务执行到哪一步、调用了什么工具、为什么失败都要能回溯。要有降级策略。远端模型不可用时是走本地模型还是返回占位结果必须提前决定。所以 AI Infra 这个词才会频繁出现。它指的不只是“把模型部署好”而是把模型路由、缓存、可观测性、任务队列、安全策略都做成一套可复用的基础设施。本地 Agent 是这套基础设施的末端执行者。3. 一次 Siri 式请求如何被链路消化3.1 从唤醒词到最终动作请求要经过哪些层假设用户问了一句比较复杂的请求比如“帮我把明天下午的会议改到三点然后提醒我准备一份材料”。语音入口先做语音识别把声音转成文字。接着要做意图理解判断这是一个“修改日程”的动作并且包含时间、对象和结果要求。然后 Agent 要访问日历数据、确认冲突、执行修改再生成一条提醒或文字反馈。可以看到真正消耗“智能”的不只是最后那句回答而是中间的规划与工具执行。模型在这条链路里要出现多次又不能每次都往最大模型上塞否则延迟和成本都失控。3.2 本地小模型与大模型怎么分工一个比较稳妥的分工方式是按任务复杂度分层。轻量任务比如设置闹钟、打开应用、查询本地文件可以用本地小模型甚至规则引擎解决。这类任务对生成能力要求不高对响应速度和隐私要求更高。中等复杂任务比如改写文本、提取摘要、结构化信息本地中档模型也能处理。只有需要深度推理、跨领域知识、复杂代码生成或者大规模知识检索的任务才值得交给服务端大模型。本地 Agent 真正特别的地方在于它掌握了设备上的个人上下文比如日历、通讯录、文件、使用习惯。服务端模型再强也不该直接拿到这些数据。所以正确路线不是“所有请求都去远端”而是“用本地模型处理带隐私的数据用远端模型处理不带隐私的复杂推理”。这也是混合架构比单一大模型更适合个人助理的根本原因。3.3 什么时候该回退到服务端什么时候必须留在本地判断逻辑不能只按“任务难不难”还要看数据敏感性。必须留在本地的场景包括读取用户的私人文件、健康数据、通讯录内容、相册信息。这些数据一旦出设备就会引入合规风险。可以回退到服务端的场景包括常识问答、公开信息检索、代码生成、通用文案创作。这些请求不含或少含个人敏感信息。服务端也有不可用的时候。网络断开、服务过载、接口鉴权失败都需要本地兜底。本地 Agent 至少能给出“当前无法连接服务请稍后再试”的稳定反馈而不是直接崩溃。注意降级策略要提前设计不要在线上故障时才临时想。真实故障时人最容易做错误决策。4. 照着做搭一个可复现的本地远端 Agent 推理路由4.1 前置条件与环境准备如果你也想做一套类似的混合 Agent 原型完全不需要一开始就买一堆服务器。最小环境只需要三样东西一台开发机能跑本地小模型。一个本地推理运行环境比如 llama.cpp、Ollama 这类工具。一个可访问的远端模型服务接口可以是商用 API也可以是自己部署的推理服务。本地模型选择上先把体积放在第一位。不要为了效果选择超过设备内存一半的大模型。如果发现加载完模型后系统明显卡顿说明模型选大了。宁可先选小一号的模型跑通流程再逐步升级。环境准备阶段最容易踩的坑是路径和版本。模型文件下载没完整、路径里带中文、依赖版本和模型要求不匹配都会导致启动报错。建议先单独启动本地模型用一句固定文本验证能正常返回再接路由逻辑。4.2 路由逻辑的最小实现路由是整个系统的核心。下面是伪代码示意不是可以直接复制到生产环境的完整实现# 伪代码示意按任务类型做本地/远端路由 def route_task(task): # 1. 敏感任务优先留在本地 if task.is_privacy_sensitive or task.requires_local_context: return run_local_agent(task) # 2. 简单任务交给本地小模型降低延迟和成本 complexity estimate_complexity(task.text) if complexity LOCAL_COMPLEXITY_THRESHOLD: return run_local_model(task.text) # 3. 复杂任务交给远端推理服务 return run_remote_inference(task.text, timeoutREMOTE_TIMEOUT)这段伪代码想表达三个原则。第一隐私判断优先于复杂度判断。第二复杂度阈值要可配置不是写死在代码里。第三远端调用必须有超时和异常捕获不能因为一个请求失败拖垮整个 Agent。我建议第一次测试不要接真实业务数据而是先准备十条固定测试用例覆盖简单问答、隐私类请求、复杂推理三种类型。跑通后再逐步加场景。4.3 关键参数怎么设路由系统里需要关注的参数不多但每个都影响最终体验。参数作用设置思路本地模型路径决定加载哪个模型文件启动前确认文件完整路径无权限问题复杂度阈值决定任务走本地还是远端先用小样本测试后调不要拍脑袋远端超时时间控制单次请求等待上限根据远端服务历史延迟设置通常偏保守重试次数提高短暂失败的恢复能力建议 1 到 2 次过多会放大故障批量并发数控制同时处理的请求数从 1 开始逐步增加观察内存和延迟失败降级策略接口不可用时如何处理先本地兜底无法处理时返回标准提示参数调整背后有一个原则不要一上来就把并发和超时拉满。先让请求稳定跑起来再提高资源利用率。如果远端服务偶尔超时要看真实耗时分布。不能只看平均值重点看 P95 和 P99。也许 95% 的请求 2 秒内完成但 5% 的请求要 30 秒这时简单调大超时并不能解决问题要检查输入长度、服务排队和网络抖动。5. 用数据判断效果先定指标再谈体验5.1 延迟类指标怎么看混合链路比单一模型多了一次路由判断所以延迟要分成几段看。首 Token 延迟是从请求发出到收到第一个输出标记的时间它反映用户“开始有反馈”的速度。完整响应耗时是从请求发出到全部结果返回的时间它决定用户看到最终答案的快慢。路由耗时是本地分类和调度消耗的时间正常情况下应当控制在几十毫秒以内。建议在日志里记录每段耗时并定期统计 P50、P95、P99。如果 P50 很低但 P99 很高说明存在少数长尾请求拖慢体验。这些长尾请求通常来自超长输入、远端服务排队或者本地模型冷启动。5.2 资源占用类指标怎么观测本地 Agent 最终要跑到真实设备上资源占用比功能更重要。内存和显存决定模型能不能稳定运行。CPU 占用率决定设备会不会在做别的事时明显变卡。连续多次调用后温度会不会升高直接影响移动端体验。网络流量也是一个容易被忽略的指标本地明明能处理的任务如果被路由到远端会消耗用户流量。我的经验是先跑一轮单元测试检查功能正确性再跑一轮资源压力测试连续调用几十次观察内存是否持续增长。如果内存只升不降大概率有显存或内存泄漏不要急着上批量任务先把泄漏定位掉。5.3 质量与稳定性指标模型效果不能只看“一次性回答对不对”。对于 Agent稳定性更值得关注。可以建立三个基础指标任务完成率路由成功且返回完整结果的请求比例。降级触发率因为本地失败或远端超时而触发兜底逻辑的比例。回归测试通过率用固定测试集验证每次改动后是否存在行为退化。有了这些指标你才能分辨“模型变聪明了”是主观感觉还是数据改善。不要用零散对话验证效果要给 Agent 准备一套可重复的回归测试集。注意模型输出没有绝对正确建议用多轮策略来验证。比如任务是否完成、工具调用参数是否正确、返回内容是否满足用户原始约束。6. 问题排查顺序先看输入与路由再动并发和模型参数6.1 现象本地模型能加载但响应慢先区分是启动慢还是每次推理都慢。第一次请求通常包含模型加载和显存预热慢是正常的。连续多次请求后仍然慢就要看模型是否超出设备能力或者 CPU 推理本身太慢。排查顺序是先记录多次请求耗时去掉第一次的冷启动数据再观察进程的内存和 CPU最后考虑换更小的模型、调整量化精度或减少上下文长度。很多时候不是代码问题而是选型问题。模型超过设备能力时优化提示词没有意义。6.2 现象调用远端推理服务经常超时先看客户端日志里是连接失败、读超时还是返回错误码。连接失败多数是网络或鉴权问题。读超时可能是输入太长、远端服务排队或者服务端性能下降。返回 4xx 错误要先检查请求格式和鉴权信息返回 5xx 错误通常说明远端服务有问题。如果单个请求偶尔超时先增加重试。如果持续超时则要检查自己在批量跑任务时是否把并发开得过大。很多远端服务有配额限制超过限制后会表现为大量超时。6.3 现象任务总被错误路由敏感任务被路由到远端、简单任务被路由到大模型这两个问题都常见。出现这种情况先看路由日志。确认每次路由判断读到的输入文本、复杂度打分和判断阈值。错误路由经常不是模型不聪明而是分类逻辑里缺少几条关键规则或者输入样本和真实场景分布不一致。6.4 一套通用排错顺序无论遇到什么问题我建议都按这个顺序排查看现象报错、超时、无输出、输出为空还是输出异常。看输入文本内容、编码、长度、格式是否符合预期。看环境依赖版本、权限、端口、磁盘空间、资源占用。看参数超时、重试、并发、模型路径、输出目录。看工具本身模型版本是否兼容、功能边界是否有已知限制。不要跳过前两步直接改模型参数。很多“模型效果差”的问题最后都是输入格式或路由规则的问题。7. 给同样在做 AI 应用的人几条经验7.1 先跑通最小闭环我见过很多团队一开始就规划大规模 Agent 编排结果卡在第一步模型服务根本不稳定。更合理的路线是先跑通最简链路一条请求进来经过路由判断本地模型或远端模型返回结果日志完整记录全过程。最小闭环跑通之后再考虑记忆、工具调用、任务队列这些增强能力。每一步都保持可回滚不要让系统变成一个没法定位问题的黑盒。7.2 不要一开始就上分布式如果你只是在做产品原型或者请求量远没有达到单机瓶颈不要急着搭分布式推理。分布式会引入网络通信、负载均衡、数据一致性和故障恢复等一系列复杂问题。单机能跑就不要拆分。真正需要分布式的信号是明显的模型权重超过单卡显存单实例并发无法满足延迟目标或者单点部署风险不可接受。在此之前把路由逻辑、日志、监控和回归测试做好收益更大。7.3 把日志、队列和失败重试当一等公民Agent 比普通接口多一层不确定性。模型可能返回非结构化内容工具可能执行失败远端可能超时。这些问题都要通过日志和失败重试来兜底。建议为每个请求生成唯一标识记录路由结果、模型耗时、输出摘要和错误原因。不要把日志只打在控制台里要做成可以按请求 ID 检索的结构化日志。否则问题一旦发生你只能在黑盒里猜原因。7.4 边界要写进设计而不是等到上线才发现本地模型不是能力越强越好要考虑设备功耗和发热。远端模型不是越聪明越好要考虑成本和隐私。任务路由不是分类越细越好规则太多会增加维护成本。混合推理架构未来会成为个人 Agent 的常态因为模型能力和端侧资源之间的矛盾会长期存在。提前把本地、远端、分布式之间的关系理清比追逐最新的模型版本更值得投入。真正到落地那天你会发现体验的上限由模型决定体验的下限却由工程决定。