1. 为什么要做混合部署先算清楚这笔成本账先说个很多团队容易踩的坑一上来就追求全量本地化部署。我见过不止一个团队因为“数据敏感”“领导要求私有化”之类的理由直接买了几张A800或者租了一台带H800的裸金属打算把7B、13B、70B全部塞进本地推理。结果跑起来才发现70B模型用FP16加载需要140GB显存单卡跑不动多卡推理延迟又上不去最后只能把量化等级压到INT4效果又缩水。折腾两三个月进度还不如直接用云端API跑POC来得快。混合部署的第一原则不是“技术最先进”而是算清你到底有多少真实推理负载。以一个典型的客服助手场景为例日常并发大约50路会话每路会话平均需要调用3次LLM每次输入输出token总量约1200。如果全部走云端API按当前主流定价输入约2元/百万token输出约6元/百万token单日成本在20到50元区间——这个量级其实完全可以直接用API。但如果是金融、医疗这类场景每次调用都要留审计日志、要脱敏、要隔离数据过云本身就是合规红线这时候哪怕贵也得把核心链路留在本地。我的建议是做一个负载画像把业务请求拆成三类。第一类是高频、格式化、低延迟要求的任务比如意图识别、实体抽取、关键信息摘要这类任务用小参数模型7B以内完全可以覆盖适合本地部署延迟可以控制在500ms以内。第二类是低频、长上下文、高质量生成任务比如报告撰写、复杂推理、多轮深度对话这类任务需要大模型能力本地推理成本过高建议走云端大模型API。第三类是不可降级的核心链路比如涉及用户隐私、财务数据的内容处理无论延迟多高必须本地闭环。这个画像决定了后面所有架构设计的出发点不是让所有流量都走同一条路而是让最合适的流量走最合适的路。再说一个实操层面的理由混合部署本质上是给系统上了一道“双保险”。云端API偶尔会出现限流、超时、地域网络抖动本地GPU集群也有宕机、显存溢出、驱动升级失败的时候。如果全链路都押在单一部署点上一旦出问题整个业务就是零可用。混合部署天然具备“另一条腿”的容错能力问题反而在于——你有没有把切换机制设计好。2. 多Agent的架构分层编排层、路由层、执行层各干各的活多Agent系统看起来热闹拆开来看其实只有三层编排层Orchestration、路由层Routing、执行层Execution。很多团队把三层混在一起写Agent内部既做任务规划又直接调模型API遇到并发一高就乱成一锅粥。正确做法是先把职责切干净。2.1 编排层只负责任务分解不关心模型从哪来编排层是一个“老板”角色负责接收用户请求拆解成子任务确定子任务之间的依赖关系然后分发给不同的Agent去执行。这一步有几个关键决策任务拆解的粒度。拆得太粗一个Agent要干很多事提示词越来越长模型输出质量下降路由层也做不了精准调度拆得太细Agent之间通信开销剧增编排层的调度成本甚至超过推理成本。我的经验是一般拆到“原子能力”级别比如“提取订单号”“判断用户情绪”“查询库存状态”每个原子能力对应一个专职Agent一个Agent只干一件事。依赖关系的表达。子任务之间可能是链式的先A后B、并行的A和B同时跑、或者汇聚式的A和B都完成后再进入C。编排层要把这几种关系显式建模。最笨但最稳的方式是写一个有限状态机状态节点对应子任务状态转移条件对应依赖满足情况。不要迷信LangChain之类的编排框架自动帮你搞定一切复杂业务场景下框架帮不了你什么反而可能让调度逻辑变成黑盒。2.2 执行层Agent的提示词、工具、记忆封装成独立进程执行层是实际干活的Agent。每个Agent绑定一个专用提示词模板、一组可用的外部工具检索、数据库、HTTP API、以及它自己的记忆空间。这里强调一点不要把所有Agent塞进一个进程里跑。Python的GIL问题、内存碎片、全局状态污染任何一条都会让你排查到怀疑人生。我见过一个线上事故两个Agent共享了一个全局变量结果A Agent修改了对话历史B Agent读取的时候直接报KeyError整个链路崩溃排查了两个小时才定位到原因。推荐的做法是每个Agent独立成服务通过gRPC或HTTP API暴露调用接口这样天然隔离状态、支持独立扩缩容、还能快速替换某个Agent的实现而不影响整体流程。当然这样做会引入网络通信开销但对一个正常的Agent链路来说子任务级别的一次HTTP调用耗时和一次LLM推理耗时几百毫秒到几秒相比开销可以忽略不计。2.3 路由层策略执行网关Agent的“参谋部”路由层是整个架构里最容易被低估的部分。它的职责是接收编排层发来的每个子任务判断该路由到哪个Agent、该Agent用本地模型还是云端模型如果模型服务异常决定是否降级或切换。这一层是实现“混合部署”的关键也是实现高可用的关键。3. 本地/云端模型的路由决策不是简单分流而是策略矩阵路由决策这件事很多人以为就是“按流量比例分流”或者“按模型能力分流”真做起来你会发现远没有这么简单。我把路由策略拆成四条线每条线都在不同维度上做判断最后组合成最终决策。3.1 成本优先策略让每块钱都花在刀刃上假设你在本地部署了一个7B的量化模型用于日常客服意图识别云端使用一个70B大模型用于高质量报告生成。一个很自然的策略是对于“摘要意图”“情感分类”这类简单任务永远路由到本地模型因为本地模型的边际成本几乎是0——电费和硬件折旧罢了对于“生成营销文案”“多步推理”这类高价值任务路由到云端因为本地小模型生成的文案质量确实有差距省下来的钱弥补不了效果损失。实现时需要为每个Agent配置一个cost_weight参数路由层在分发时优先选择cost_weight低且能满足任务质量要求的模型。这里要注意不要只看单次调用的token价格还要考虑云端API的延迟成本。比如某些云端API的单次调用价格是便宜但排队起来要等两秒用户交互体验直接崩掉。3.2 延迟优先策略把毫秒级的动作留给本地如果是面向用户的实时交互场景比如聊天机器人、语音助手、实时弹幕分析延迟超过1.5秒用户能明显感觉到卡顿。本地推理在这方面有天然优势模型部署在机房内网RTT能控制在几个毫秒加上推理时间总延迟通常在300到800ms之间。所以路由规则里要加一条latency_sensitive标记。标记为true的子任务默认路由到本地模型如果本地模型压力过大宁可排队也不要轻易切到云端。这里有个经验值本地推理队列在20个请求以内时平均响应时间仍可接受超过20个排队延迟会显著爬升此时应该触发扩容或切换而不是继续硬扛。3.3 数据隐私策略不可跨域的请求坚决挡住数据隐私是一个硬边界不是策略问题是安全底线。比如一个医疗问答场景患者病历数据不允许离开本地机房。那路由层就需要配置一个data_zone标记值为local_only的子任务路由到本地模型和本地工具任何情况下不得转发到云端API。这时候路由层实际上是充当了“数据防火墙”的作用。我建议在路由网关处做一个强制校验任何标记为local_only的请求如果目的地是云端直接拦截并返回错误码。这种“宁可报错也不泄漏”的策略在合规审计时会非常有用。3.4 故障转移策略本地/云端互为备份打破单点依赖当本地模型服务返回超时、错误率飙升或者GPU显存耗尽时路由层应该自动把该模型的任务切换到云端备份模型。反之云端API如果出现认证失败、限流、网络抖动本地有备份模型的话也能切回本地。需要注意两个细节。一是切换要有“熔断”和“恢复”两个状态不要一遇到超时就立刻切换频繁抖动反而让系统不稳定。我常用的做法是连续5次调用失败或错误率超过30%超过1分钟开启熔断后续请求全部切走之后每30秒探测一次原服务探测成功且稳定5分钟后才恢复流量。二是切换前要评估备用模型的“能力差”。云端70B模型切到本地7B模型效果可能差一截所以故障转移策略里最好加一个quality_degradation_allowed标记只有允许质量降级的任务才自动切换否则直接返回降级提示或进入人工处理队列。3.5 路由决策的实现策略矩阵轻量级规则引擎把所有维度组合起来就是一张策略矩阵。举个例子一个客服工单处理Agent的任务路由表长这样子任务类型数据敏感级别延迟要求成本权重路由目标故障降级目标用户意图识别低高0.1本地7B云端小模型情感分析低中0.15本地7B云端小模型工单摘要生成中低0.5云端70B本地13B质量降级客户隐私信息提取高中0.8本地13B无拒绝降级实现上不需要搞一个复杂的规则引擎用YAML写静态规则加上少量动态判断就够了。动态判断有三个来源模型服务的健康状态错误率、延迟、排队长度、当前业务优先级高优任务优先分配优质模型、配额余额云端API还有多少余量。把这些信息聚合成一个状态对象路由层每次决策时同步读取最新状态做一次规则匹配输出路由目标。规则匹配的复杂度控制在O(N)N是规则条数几十条以内完全没问题。4. 混合部署的高可用从单体模型服务到多副本/多网关/多活高可用这件事说起来就一句话“不要让任何一个环节成为单点”但落地起来全是细节。我按自下而上的顺序拆解模型推理层、Agent服务层、路由网关层、数据与记忆层。4.1 模型推理层多副本扩缩容与健康检查本地模型服务推荐使用vLLM或TGI这类推理框架天然支持多卡加载、动态批处理、连续批处理。部署上可以采用多副本模式同一个模型部署两套实例前面挂负载均衡Nginx或云负载均衡器。负载均衡器要配置HTTP健康检查定期请求模型的/health接口返回非200码的实例会被摘除流量。有个坑要提醒大模型推理服务健康检查不能只查“进程活着”而要查“能否正常推理”。进程活着不代表显存没跑满也不代表KV Cache没有异常膨胀。我在健康检查脚本里加了一个“最小推理冒烟测试”每30秒向模型提交一个固定的短请求比如“你好请回复OK”检查响应时间是否超过阈值、返回内容是否合法。这个冒烟测试会增加一点额外负载但换来的是提前发现问题。4.2 路由网关层无状态网关分布式状态协调路由网关是无状态的请求进来之后查策略表、查服务健康状态、决定路由目标然后转发。想要高可用网关本身要部署多副本前面再挂一层负载均衡。网关之间不需要互相通信因为状态都存储在独立的协调层比如Redis或etcd每个网关实例只做只读查询。这里要注意分布式一致性带来的小坑如果用etcd来存储服务健康状态网关实例之间读取到的一致性延迟会导致不同实例路由决策不完全一致。比如实例A看到本地模型正常实例B看到本地模型熔断同一个请求可能被路由到不同地方。这在多数场景下可以接受本来就是尽力而为的容错但如果你在做A/B测试或者需要严格一致性可以用Redis的WATCH事务或者etcd的lease机制来解决。4.3 多活部署区域级容灾如果你的业务体量到了需要跨区域容灾的地步比如两个机房各部署一套那“本地/云端”就不用分主备而是做成双活。每个机房都有本地模型服务也都能访问云端API路由规则按机房的配置分开设置。用户流量就近接入机房如果机房A的本地模型宕机路由层把该机房的流量切到机房B的模型服务跨机房内网转发或者直接转云端。这种架构做起来要复杂一些但可用性提升是立竿见影的。我在实际项目里做过一次区域容灾演练目标是把业务整体从机房A切到机房B过程如下先在机房B逐步放大流量比例从10%到30%再到50%观察错误率和延迟确认B机房能扛住。把机房A的本地模型流量全部切走检查是否有Agent因为找不到服务报错。观察30分钟确认一切平稳后把机房A的Agent服务也下线只保留编排层入口。回切的时候反向操作同样用灰度方式逐步放量不要一次性切回。这次演练让我深刻体会到一件事高可用不是靠“设计”出来的是靠“演练”练出来的。你以为配置好了切换逻辑就能自动搞定一切实际上你永远会低估出事的场景网络分区、DNS缓存、时钟偏移、证书过期……只有通过反复演练提前发现并补齐这些边边角角的问题系统才算真正的高可用。5. 多Agent的共享记忆与状态同步避免“各说各话”的经典翻车现场多Agent系统如果每个Agent都是“失忆症患者”任务之间的上下文就断了用户问“帮我看看我上个月订单”意图识别Agent识别出意图订单查询Agent却不知道用户是谁。共享记忆机制解决的就是这个问题。5.1 会话级记忆通过上下文ID串联所有Agent最简单也最实用的一套机制每个用户会话对应一个全局唯一的会话ID如UUID所有Agent在处理该会话内的子任务时都把会话ID、输入输出记录、中间状态快照写入一个共享记忆存储Redis或PostgreSQL。比如一个客服场景用户问“我的订单到哪里了”编排层把会话ID传入意图识别Agent识别出意图“订单查询”把“意图识别结果”写入记忆订单查询Agent从记忆里读到“意图订单查询”再从记忆里取到“用户ID”上一步用户身份校验Agent写入的然后查数据库把结果写回记忆最后回复生成Agent从记忆里取所有相关记录生成自然语言回复。这套机制看似简单但有一个地方很容易踩坑并发写入覆盖。两个Agent同时向同一个会话ID写数据后写入的会把先写入的覆盖掉。我在Redis的实现里用了Hash结构存储每个会话ID下的JSON对象写操作要带上乐观锁版本号版本号不一致就重试。这样虽然增加了一点复杂度但彻底避免了并发覆盖问题。5.2 全局级记忆从会话到知识库的升华会话级记忆只能解决“当前对话的连续性”解决不了“不同会话之间共享知识”的问题。比如用户问“你们公司支持哪些支付方式”这个答案应该是一个相对固定的知识每次问都从知识库里取。这就要用到全局知识库记忆。全局记忆可以是一套向量数据库如Milvus、Qdrant把知识切块后embedding存储检索时用语义相似度召回。路由层识别到“知识类问题”后先去向量库检索相关片段拼接到提示词里再发送给模型。这套流程做熟之后你可以把一些日常FAQ、产品说明、操作手册都能塞进知识库让Agent回答得又快又准。5.3 记忆的边界与清理记忆不是越多越好。过多的上下文会让提示词膨胀推理延迟升高、效果反而下降。我建议的机制是“滑动窗口归档”最近20轮会话记录放“热记忆”实时读取超过20轮的记录按天归档到冷存储。对于一个客服会话来说用户的操作包含会话ID、Agent ID、输入输出摘要、耗时、token数、路由目标、模型名称、出错信息等字段。**日志不是写给别人看的是写给自己排障用的所以宁可多写也不要漏写。**排障的时候你会发现少一个字段排查链路可能要多花半小时。6.2 全链路追踪把一次用户请求的完整路径画出来光有日志还不够你需要全链路追踪。当用户的一个请求经过编排层分解、路由层先后分发到多个Agent、每个Agent还可能调用模型API和外部工具时问题定位就像在一团乱麻里找线头。分布式追踪系统如OpenTelemetry就是把这根线头找到的工具每个用户请求生成一个全局Trace ID每经过一个服务或调用生成一个SpanSpan之间通过Trace ID串起来能看到每一跳的耗时和状态。在实现时我通常会给每个Agent启动Request ID注入逻辑入口处生成Trace ID通过HTTP Header传给下游服务所有日志、模型调用记录、外部工具调用记录都带上这个Trace ID。一旦线上有问题直接在追踪系统里按Trace ID搜索几秒钟就能看到整条链路的瓶颈在哪个环节。6.3 成本观测每块钱花在哪了要看得一清二楚混合部署最怕的不是流量大而是成本失控。云端API是一口价本地部署是固定投入但如果你路由策略没配好本该走本地的请求全被路由到了云端月底账单会让你怀疑人生。我在成本观测上做了三件事第一在日志里记录每个请求的token数输入输出和模型类型这样每天汇总后能算出“云端总消耗量”和“本地总推理量”第二按业务线拆分成本不同业务线用不同API Key逐条统计第三设置预算告警当某条业务线的当日成本超过设定的日预算80%时钉钉告警自动触达负责人。调整路由策略把一部分流量切回本地成本立刻下降一大截。6.4 预警规则不要等用户投诉了才知道系统挂了最后是预警。高可用系统不是“不出故障”而是“故障能被及时感知并快速响应”。我需要至少配置三类预警规则错误率告警某个模型服务的错误率连续5分钟超过5%触发告警。延迟告警某条链路的P95延迟超过2秒触发告警。容量告警本地模型推理队列长度超过阈值或GPU显存使用率超过90%触发告警。有了预警系统我才能在故障发生后的几分钟内收到通知而不是等到用户投诉了才开始排查。7. 一条完整的故障演练剧本生产环境的“大考”纸上谈兵再多也不如拉出来遛遛。我建议每个季度做一次故障演练下面是一条我常用的演练剧本覆盖了混合部署最关键的两个环节模型故障和路由网关故障。7.1 场景A本地模型服务整体宕机假设业务当前运行状态是60%的请求走本地7B模型40%走云端大模型。本地模型服务所在GPU服务器因为“显存ECC错误”宕机所有本地推理请求开始报错。预期行为路由层检测到本地模型错误率飙升触发熔断。熔断生效后所有原本路由到本地的请求按照策略矩阵的降级路径切换到云端前提是quality_degradation_allowed标记为true。如果是标记为local_only的敏感请求返回降级提示“暂时无法处理请稍后再试”。告警系统触发“本地模型服务不可用”告警值班人员收到通知。验证点从熔断到流量切换完毕整体耗时是否小于2分钟切换后各Agent的完成率是否恢复稳定降级请求有多少降级后的质量下降是否在可接受范围7.2 场景B云端API限流假设云端API在高峰期触发限流返回429状态码持续10分钟。此时如果本地模型还有余量路由策略应该把部分云端请求切回本地。预期行为路由层检测到云端API的错误率和429比例升高。触发“云端熔断”部分允许质量降级的任务切换到本地模型。对于不允许降级的任务如需要70B能力的长文本生成保持排队等待但增加重试退避。验证点切换过程中用户请求的失败率是否控制在一定阈值内云端API恢复后是否自动切回恢复时间多久7.3 场景C路由层本身挂了路由层是混合部署的核心如果它挂了整个请求链路都断了。所以我在设计上让路由层无状态前面加一层负载均衡实际部署两套实例。演练时手动停掉其中一个实例观察请求是否自动转移到另一个实例是否出现丢请求或延迟升高。8. 我的踩坑清单这些问题都是“排雷排出来的”做了这么多混合部署的项目如果让我只说一个核心心得那就是路由和高可用不是靠堆功能堆出来的而是靠一次一次演练踩坑踩出来的。这里放一些我踩过的坑给准备入坑的同学做个参考。量化模型的质量下降本地小模型用INT4量化后在结构化任务如实体抽取上质量损失不大但在生成类任务如写摘要、改写上能明显感觉到“没营养”路由策略别只看成本和延迟质量维度也要考虑进决策矩阵。POST请求超时重试的幂等性模型API的POST请求如果超时重试会导致同一份数据被处理两次生成结果重复。路由层在设计重试策略时一定要考虑幂等性要么带上幂等键要么用“只读”型提示词。网关的线程池大小路由网关默认线程池可能不够用。本地模型推理本身比较慢网关线程被占满就会阻塞后续请求。建议单独给模型调用线程池设置一个合理上限并做线程池满时的降级策略。模型版本升级导致的“效果回归”云端换了模型版本之前测试通过的prompt模板可能突然失效。建议在路由层增加“模型版本管理”每次升级前用小流量灰度测试通过后再全量放开。记忆存储的冷热分离共享记忆存储用Redis做热数据冷数据定期转存到PostgreSQL。Redis内存别开太大不然OOM了会影响整个会话链路。日志也要“三副本”日志和索引是排障的生命线多写一份到对象存储防止本地磁盘写满把日志冲掉。混合部署不是终点它只是你走向更可靠架构的一步。真正让你的系统稳定运行的不是某几个“杀手级配置”而是你愿意在半夜爬起来看告警、在演练中反复调试、在故障后认真复盘的那股劲儿。希望这篇文章能帮你少走几步弯路哪怕只是少改一个错误的配置也多了一份值得。 大模型混合部署与多Agent架构：路由策略与高可用实践指南
1. 为什么要做混合部署先算清楚这笔成本账先说个很多团队容易踩的坑一上来就追求全量本地化部署。我见过不止一个团队因为“数据敏感”“领导要求私有化”之类的理由直接买了几张A800或者租了一台带H800的裸金属打算把7B、13B、70B全部塞进本地推理。结果跑起来才发现70B模型用FP16加载需要140GB显存单卡跑不动多卡推理延迟又上不去最后只能把量化等级压到INT4效果又缩水。折腾两三个月进度还不如直接用云端API跑POC来得快。混合部署的第一原则不是“技术最先进”而是算清你到底有多少真实推理负载。以一个典型的客服助手场景为例日常并发大约50路会话每路会话平均需要调用3次LLM每次输入输出token总量约1200。如果全部走云端API按当前主流定价输入约2元/百万token输出约6元/百万token单日成本在20到50元区间——这个量级其实完全可以直接用API。但如果是金融、医疗这类场景每次调用都要留审计日志、要脱敏、要隔离数据过云本身就是合规红线这时候哪怕贵也得把核心链路留在本地。我的建议是做一个负载画像把业务请求拆成三类。第一类是高频、格式化、低延迟要求的任务比如意图识别、实体抽取、关键信息摘要这类任务用小参数模型7B以内完全可以覆盖适合本地部署延迟可以控制在500ms以内。第二类是低频、长上下文、高质量生成任务比如报告撰写、复杂推理、多轮深度对话这类任务需要大模型能力本地推理成本过高建议走云端大模型API。第三类是不可降级的核心链路比如涉及用户隐私、财务数据的内容处理无论延迟多高必须本地闭环。这个画像决定了后面所有架构设计的出发点不是让所有流量都走同一条路而是让最合适的流量走最合适的路。再说一个实操层面的理由混合部署本质上是给系统上了一道“双保险”。云端API偶尔会出现限流、超时、地域网络抖动本地GPU集群也有宕机、显存溢出、驱动升级失败的时候。如果全链路都押在单一部署点上一旦出问题整个业务就是零可用。混合部署天然具备“另一条腿”的容错能力问题反而在于——你有没有把切换机制设计好。2. 多Agent的架构分层编排层、路由层、执行层各干各的活多Agent系统看起来热闹拆开来看其实只有三层编排层Orchestration、路由层Routing、执行层Execution。很多团队把三层混在一起写Agent内部既做任务规划又直接调模型API遇到并发一高就乱成一锅粥。正确做法是先把职责切干净。2.1 编排层只负责任务分解不关心模型从哪来编排层是一个“老板”角色负责接收用户请求拆解成子任务确定子任务之间的依赖关系然后分发给不同的Agent去执行。这一步有几个关键决策任务拆解的粒度。拆得太粗一个Agent要干很多事提示词越来越长模型输出质量下降路由层也做不了精准调度拆得太细Agent之间通信开销剧增编排层的调度成本甚至超过推理成本。我的经验是一般拆到“原子能力”级别比如“提取订单号”“判断用户情绪”“查询库存状态”每个原子能力对应一个专职Agent一个Agent只干一件事。依赖关系的表达。子任务之间可能是链式的先A后B、并行的A和B同时跑、或者汇聚式的A和B都完成后再进入C。编排层要把这几种关系显式建模。最笨但最稳的方式是写一个有限状态机状态节点对应子任务状态转移条件对应依赖满足情况。不要迷信LangChain之类的编排框架自动帮你搞定一切复杂业务场景下框架帮不了你什么反而可能让调度逻辑变成黑盒。2.2 执行层Agent的提示词、工具、记忆封装成独立进程执行层是实际干活的Agent。每个Agent绑定一个专用提示词模板、一组可用的外部工具检索、数据库、HTTP API、以及它自己的记忆空间。这里强调一点不要把所有Agent塞进一个进程里跑。Python的GIL问题、内存碎片、全局状态污染任何一条都会让你排查到怀疑人生。我见过一个线上事故两个Agent共享了一个全局变量结果A Agent修改了对话历史B Agent读取的时候直接报KeyError整个链路崩溃排查了两个小时才定位到原因。推荐的做法是每个Agent独立成服务通过gRPC或HTTP API暴露调用接口这样天然隔离状态、支持独立扩缩容、还能快速替换某个Agent的实现而不影响整体流程。当然这样做会引入网络通信开销但对一个正常的Agent链路来说子任务级别的一次HTTP调用耗时和一次LLM推理耗时几百毫秒到几秒相比开销可以忽略不计。2.3 路由层策略执行网关Agent的“参谋部”路由层是整个架构里最容易被低估的部分。它的职责是接收编排层发来的每个子任务判断该路由到哪个Agent、该Agent用本地模型还是云端模型如果模型服务异常决定是否降级或切换。这一层是实现“混合部署”的关键也是实现高可用的关键。3. 本地/云端模型的路由决策不是简单分流而是策略矩阵路由决策这件事很多人以为就是“按流量比例分流”或者“按模型能力分流”真做起来你会发现远没有这么简单。我把路由策略拆成四条线每条线都在不同维度上做判断最后组合成最终决策。3.1 成本优先策略让每块钱都花在刀刃上假设你在本地部署了一个7B的量化模型用于日常客服意图识别云端使用一个70B大模型用于高质量报告生成。一个很自然的策略是对于“摘要意图”“情感分类”这类简单任务永远路由到本地模型因为本地模型的边际成本几乎是0——电费和硬件折旧罢了对于“生成营销文案”“多步推理”这类高价值任务路由到云端因为本地小模型生成的文案质量确实有差距省下来的钱弥补不了效果损失。实现时需要为每个Agent配置一个cost_weight参数路由层在分发时优先选择cost_weight低且能满足任务质量要求的模型。这里要注意不要只看单次调用的token价格还要考虑云端API的延迟成本。比如某些云端API的单次调用价格是便宜但排队起来要等两秒用户交互体验直接崩掉。3.2 延迟优先策略把毫秒级的动作留给本地如果是面向用户的实时交互场景比如聊天机器人、语音助手、实时弹幕分析延迟超过1.5秒用户能明显感觉到卡顿。本地推理在这方面有天然优势模型部署在机房内网RTT能控制在几个毫秒加上推理时间总延迟通常在300到800ms之间。所以路由规则里要加一条latency_sensitive标记。标记为true的子任务默认路由到本地模型如果本地模型压力过大宁可排队也不要轻易切到云端。这里有个经验值本地推理队列在20个请求以内时平均响应时间仍可接受超过20个排队延迟会显著爬升此时应该触发扩容或切换而不是继续硬扛。3.3 数据隐私策略不可跨域的请求坚决挡住数据隐私是一个硬边界不是策略问题是安全底线。比如一个医疗问答场景患者病历数据不允许离开本地机房。那路由层就需要配置一个data_zone标记值为local_only的子任务路由到本地模型和本地工具任何情况下不得转发到云端API。这时候路由层实际上是充当了“数据防火墙”的作用。我建议在路由网关处做一个强制校验任何标记为local_only的请求如果目的地是云端直接拦截并返回错误码。这种“宁可报错也不泄漏”的策略在合规审计时会非常有用。3.4 故障转移策略本地/云端互为备份打破单点依赖当本地模型服务返回超时、错误率飙升或者GPU显存耗尽时路由层应该自动把该模型的任务切换到云端备份模型。反之云端API如果出现认证失败、限流、网络抖动本地有备份模型的话也能切回本地。需要注意两个细节。一是切换要有“熔断”和“恢复”两个状态不要一遇到超时就立刻切换频繁抖动反而让系统不稳定。我常用的做法是连续5次调用失败或错误率超过30%超过1分钟开启熔断后续请求全部切走之后每30秒探测一次原服务探测成功且稳定5分钟后才恢复流量。二是切换前要评估备用模型的“能力差”。云端70B模型切到本地7B模型效果可能差一截所以故障转移策略里最好加一个quality_degradation_allowed标记只有允许质量降级的任务才自动切换否则直接返回降级提示或进入人工处理队列。3.5 路由决策的实现策略矩阵轻量级规则引擎把所有维度组合起来就是一张策略矩阵。举个例子一个客服工单处理Agent的任务路由表长这样子任务类型数据敏感级别延迟要求成本权重路由目标故障降级目标用户意图识别低高0.1本地7B云端小模型情感分析低中0.15本地7B云端小模型工单摘要生成中低0.5云端70B本地13B质量降级客户隐私信息提取高中0.8本地13B无拒绝降级实现上不需要搞一个复杂的规则引擎用YAML写静态规则加上少量动态判断就够了。动态判断有三个来源模型服务的健康状态错误率、延迟、排队长度、当前业务优先级高优任务优先分配优质模型、配额余额云端API还有多少余量。把这些信息聚合成一个状态对象路由层每次决策时同步读取最新状态做一次规则匹配输出路由目标。规则匹配的复杂度控制在O(N)N是规则条数几十条以内完全没问题。4. 混合部署的高可用从单体模型服务到多副本/多网关/多活高可用这件事说起来就一句话“不要让任何一个环节成为单点”但落地起来全是细节。我按自下而上的顺序拆解模型推理层、Agent服务层、路由网关层、数据与记忆层。4.1 模型推理层多副本扩缩容与健康检查本地模型服务推荐使用vLLM或TGI这类推理框架天然支持多卡加载、动态批处理、连续批处理。部署上可以采用多副本模式同一个模型部署两套实例前面挂负载均衡Nginx或云负载均衡器。负载均衡器要配置HTTP健康检查定期请求模型的/health接口返回非200码的实例会被摘除流量。有个坑要提醒大模型推理服务健康检查不能只查“进程活着”而要查“能否正常推理”。进程活着不代表显存没跑满也不代表KV Cache没有异常膨胀。我在健康检查脚本里加了一个“最小推理冒烟测试”每30秒向模型提交一个固定的短请求比如“你好请回复OK”检查响应时间是否超过阈值、返回内容是否合法。这个冒烟测试会增加一点额外负载但换来的是提前发现问题。4.2 路由网关层无状态网关分布式状态协调路由网关是无状态的请求进来之后查策略表、查服务健康状态、决定路由目标然后转发。想要高可用网关本身要部署多副本前面再挂一层负载均衡。网关之间不需要互相通信因为状态都存储在独立的协调层比如Redis或etcd每个网关实例只做只读查询。这里要注意分布式一致性带来的小坑如果用etcd来存储服务健康状态网关实例之间读取到的一致性延迟会导致不同实例路由决策不完全一致。比如实例A看到本地模型正常实例B看到本地模型熔断同一个请求可能被路由到不同地方。这在多数场景下可以接受本来就是尽力而为的容错但如果你在做A/B测试或者需要严格一致性可以用Redis的WATCH事务或者etcd的lease机制来解决。4.3 多活部署区域级容灾如果你的业务体量到了需要跨区域容灾的地步比如两个机房各部署一套那“本地/云端”就不用分主备而是做成双活。每个机房都有本地模型服务也都能访问云端API路由规则按机房的配置分开设置。用户流量就近接入机房如果机房A的本地模型宕机路由层把该机房的流量切到机房B的模型服务跨机房内网转发或者直接转云端。这种架构做起来要复杂一些但可用性提升是立竿见影的。我在实际项目里做过一次区域容灾演练目标是把业务整体从机房A切到机房B过程如下先在机房B逐步放大流量比例从10%到30%再到50%观察错误率和延迟确认B机房能扛住。把机房A的本地模型流量全部切走检查是否有Agent因为找不到服务报错。观察30分钟确认一切平稳后把机房A的Agent服务也下线只保留编排层入口。回切的时候反向操作同样用灰度方式逐步放量不要一次性切回。这次演练让我深刻体会到一件事高可用不是靠“设计”出来的是靠“演练”练出来的。你以为配置好了切换逻辑就能自动搞定一切实际上你永远会低估出事的场景网络分区、DNS缓存、时钟偏移、证书过期……只有通过反复演练提前发现并补齐这些边边角角的问题系统才算真正的高可用。5. 多Agent的共享记忆与状态同步避免“各说各话”的经典翻车现场多Agent系统如果每个Agent都是“失忆症患者”任务之间的上下文就断了用户问“帮我看看我上个月订单”意图识别Agent识别出意图订单查询Agent却不知道用户是谁。共享记忆机制解决的就是这个问题。5.1 会话级记忆通过上下文ID串联所有Agent最简单也最实用的一套机制每个用户会话对应一个全局唯一的会话ID如UUID所有Agent在处理该会话内的子任务时都把会话ID、输入输出记录、中间状态快照写入一个共享记忆存储Redis或PostgreSQL。比如一个客服场景用户问“我的订单到哪里了”编排层把会话ID传入意图识别Agent识别出意图“订单查询”把“意图识别结果”写入记忆订单查询Agent从记忆里读到“意图订单查询”再从记忆里取到“用户ID”上一步用户身份校验Agent写入的然后查数据库把结果写回记忆最后回复生成Agent从记忆里取所有相关记录生成自然语言回复。这套机制看似简单但有一个地方很容易踩坑并发写入覆盖。两个Agent同时向同一个会话ID写数据后写入的会把先写入的覆盖掉。我在Redis的实现里用了Hash结构存储每个会话ID下的JSON对象写操作要带上乐观锁版本号版本号不一致就重试。这样虽然增加了一点复杂度但彻底避免了并发覆盖问题。5.2 全局级记忆从会话到知识库的升华会话级记忆只能解决“当前对话的连续性”解决不了“不同会话之间共享知识”的问题。比如用户问“你们公司支持哪些支付方式”这个答案应该是一个相对固定的知识每次问都从知识库里取。这就要用到全局知识库记忆。全局记忆可以是一套向量数据库如Milvus、Qdrant把知识切块后embedding存储检索时用语义相似度召回。路由层识别到“知识类问题”后先去向量库检索相关片段拼接到提示词里再发送给模型。这套流程做熟之后你可以把一些日常FAQ、产品说明、操作手册都能塞进知识库让Agent回答得又快又准。5.3 记忆的边界与清理记忆不是越多越好。过多的上下文会让提示词膨胀推理延迟升高、效果反而下降。我建议的机制是“滑动窗口归档”最近20轮会话记录放“热记忆”实时读取超过20轮的记录按天归档到冷存储。对于一个客服会话来说用户的操作包含会话ID、Agent ID、输入输出摘要、耗时、token数、路由目标、模型名称、出错信息等字段。**日志不是写给别人看的是写给自己排障用的所以宁可多写也不要漏写。**排障的时候你会发现少一个字段排查链路可能要多花半小时。6.2 全链路追踪把一次用户请求的完整路径画出来光有日志还不够你需要全链路追踪。当用户的一个请求经过编排层分解、路由层先后分发到多个Agent、每个Agent还可能调用模型API和外部工具时问题定位就像在一团乱麻里找线头。分布式追踪系统如OpenTelemetry就是把这根线头找到的工具每个用户请求生成一个全局Trace ID每经过一个服务或调用生成一个SpanSpan之间通过Trace ID串起来能看到每一跳的耗时和状态。在实现时我通常会给每个Agent启动Request ID注入逻辑入口处生成Trace ID通过HTTP Header传给下游服务所有日志、模型调用记录、外部工具调用记录都带上这个Trace ID。一旦线上有问题直接在追踪系统里按Trace ID搜索几秒钟就能看到整条链路的瓶颈在哪个环节。6.3 成本观测每块钱花在哪了要看得一清二楚混合部署最怕的不是流量大而是成本失控。云端API是一口价本地部署是固定投入但如果你路由策略没配好本该走本地的请求全被路由到了云端月底账单会让你怀疑人生。我在成本观测上做了三件事第一在日志里记录每个请求的token数输入输出和模型类型这样每天汇总后能算出“云端总消耗量”和“本地总推理量”第二按业务线拆分成本不同业务线用不同API Key逐条统计第三设置预算告警当某条业务线的当日成本超过设定的日预算80%时钉钉告警自动触达负责人。调整路由策略把一部分流量切回本地成本立刻下降一大截。6.4 预警规则不要等用户投诉了才知道系统挂了最后是预警。高可用系统不是“不出故障”而是“故障能被及时感知并快速响应”。我需要至少配置三类预警规则错误率告警某个模型服务的错误率连续5分钟超过5%触发告警。延迟告警某条链路的P95延迟超过2秒触发告警。容量告警本地模型推理队列长度超过阈值或GPU显存使用率超过90%触发告警。有了预警系统我才能在故障发生后的几分钟内收到通知而不是等到用户投诉了才开始排查。7. 一条完整的故障演练剧本生产环境的“大考”纸上谈兵再多也不如拉出来遛遛。我建议每个季度做一次故障演练下面是一条我常用的演练剧本覆盖了混合部署最关键的两个环节模型故障和路由网关故障。7.1 场景A本地模型服务整体宕机假设业务当前运行状态是60%的请求走本地7B模型40%走云端大模型。本地模型服务所在GPU服务器因为“显存ECC错误”宕机所有本地推理请求开始报错。预期行为路由层检测到本地模型错误率飙升触发熔断。熔断生效后所有原本路由到本地的请求按照策略矩阵的降级路径切换到云端前提是quality_degradation_allowed标记为true。如果是标记为local_only的敏感请求返回降级提示“暂时无法处理请稍后再试”。告警系统触发“本地模型服务不可用”告警值班人员收到通知。验证点从熔断到流量切换完毕整体耗时是否小于2分钟切换后各Agent的完成率是否恢复稳定降级请求有多少降级后的质量下降是否在可接受范围7.2 场景B云端API限流假设云端API在高峰期触发限流返回429状态码持续10分钟。此时如果本地模型还有余量路由策略应该把部分云端请求切回本地。预期行为路由层检测到云端API的错误率和429比例升高。触发“云端熔断”部分允许质量降级的任务切换到本地模型。对于不允许降级的任务如需要70B能力的长文本生成保持排队等待但增加重试退避。验证点切换过程中用户请求的失败率是否控制在一定阈值内云端API恢复后是否自动切回恢复时间多久7.3 场景C路由层本身挂了路由层是混合部署的核心如果它挂了整个请求链路都断了。所以我在设计上让路由层无状态前面加一层负载均衡实际部署两套实例。演练时手动停掉其中一个实例观察请求是否自动转移到另一个实例是否出现丢请求或延迟升高。8. 我的踩坑清单这些问题都是“排雷排出来的”做了这么多混合部署的项目如果让我只说一个核心心得那就是路由和高可用不是靠堆功能堆出来的而是靠一次一次演练踩坑踩出来的。这里放一些我踩过的坑给准备入坑的同学做个参考。量化模型的质量下降本地小模型用INT4量化后在结构化任务如实体抽取上质量损失不大但在生成类任务如写摘要、改写上能明显感觉到“没营养”路由策略别只看成本和延迟质量维度也要考虑进决策矩阵。POST请求超时重试的幂等性模型API的POST请求如果超时重试会导致同一份数据被处理两次生成结果重复。路由层在设计重试策略时一定要考虑幂等性要么带上幂等键要么用“只读”型提示词。网关的线程池大小路由网关默认线程池可能不够用。本地模型推理本身比较慢网关线程被占满就会阻塞后续请求。建议单独给模型调用线程池设置一个合理上限并做线程池满时的降级策略。模型版本升级导致的“效果回归”云端换了模型版本之前测试通过的prompt模板可能突然失效。建议在路由层增加“模型版本管理”每次升级前用小流量灰度测试通过后再全量放开。记忆存储的冷热分离共享记忆存储用Redis做热数据冷数据定期转存到PostgreSQL。Redis内存别开太大不然OOM了会影响整个会话链路。日志也要“三副本”日志和索引是排障的生命线多写一份到对象存储防止本地磁盘写满把日志冲掉。混合部署不是终点它只是你走向更可靠架构的一步。真正让你的系统稳定运行的不是某几个“杀手级配置”而是你愿意在半夜爬起来看告警、在演练中反复调试、在故障后认真复盘的那股劲儿。希望这篇文章能帮你少走几步弯路哪怕只是少改一个错误的配置也多了一份值得。