1. 为什么需要一套混合大模型架构从单模型堵点到多Agent体系先聊一个很实际的问题单一大模型跑生产环境到底卡在哪我在过去一年多反复遇到三个坎。第一个是场景覆盖不够。同一个模型很难在复杂推理、代码生成、轻量对话、内容分类这几个方向同时做到又快又省强行用一个模型扛全部流量要么贵得离谱要么响应慢到用户投诉。第二个是数据安全与成本矛盾。有些内部知识库、客户隐私数据根本不适合全部上云但云上大模型的能力确实更强这时候不能二选一只能两边都留。第三个是单点故障的真实代价。曾经有一次云端模型服务宕了四十分钟整个在线助手全部不可用客服系统被打爆那种体验一次就够。所以混合大模型架构这个词本质上不是在追新概念它是被这些生产问题逼出来的。核心思路很简单把不同能力、不同部署位置的模型组合成一个集群在它们前面架一道智能路由上层再接多Agent调度底层做高可用保障。这样一来每个模型只做自己最擅长的事流量按需分发挂了也有备胎顶上。这套方案适合谁后端工程师、AI应用架构师、以及那些正在从小demo往生产级应用过渡的团队。如果你手头有超过三个以上的模型调用场景或者正在纠结到底用云还是本地的问题这篇文章里的思路和代码可以直接拿去改。我自己搭这套体系的直接动因是把一个原本重度依赖云端大模型的客服机器人改造成本地小模型打底 云端大模型增强 多Agent分工的结构。整个改造过程踩了不少坑尤其是路由策略和高可用切换这两块走了很多弯路。所以这篇内容不是理论堆砌全部是实际跑过、验证过的方案。2. 方案选型背后的思考为什么不能粗暴地全都放云端或全都跑本地在动手之前要先想清楚一个架构方向本地部署、云端调用、还是混合部署。这个决策直接决定了后续所有代码怎么写、监控怎么搭、故障怎么处理。2.1 全云端和全本地的代价你可能没算全全云端的优势是模型能力强、接入快、不用管硬件。但问题也很明显数据出域风险。凡是涉及隐私的对话内容客户可能根本不允许出内网。全本地部署则反过来数据安全可控可模型能力天花板低GPU采购成本和运维成本高得吓人。我算过一笔账一个中等规模的团队如果要本地跑一个能媲美云端旗舰模型的推理服务光显卡投入就是几十万起步更不用说后续的散热、机房和值班工程师成本。所以混合部署不是既要又要的妥协而是从成本、安全、性能三个维度取最优解。把高频、敏感、低复杂度的请求留在本地把低频、高难度、需要最强推理能力的请求转发到云端。这是成本和安全之间的动态平衡也是我在实际项目里验证过最可持续的模型接入方式。2.2 多Agent在这里面的真实角色很多人把多Agent理解为多个AI角色一起聊天工程上的理解应该更务实Agent是策略的执行单元每个Agent背后绑定一个能完成特定任务的模型调用链。路由层收到用户请求后先做意图识别再按规则把请求分给对应的AgentAgent内部再去决定调用本地模型还是云端模型。举个例子我的客服系统里有三个Agent一个是售后助手绑定本地部署的7B对话模型处理退换货、物流查询这类标准化问题一个是复杂分析专员绑定云端大模型负责解析用户情绪、生成安抚话术还有一个是知识库检索Agent负责访问向量数据库给其他Agent提供上下文。这三个Agent共享一个短时记忆池保证用户在同一个会话里切换Agent时上下文不断裂。关于多Agent共享记忆后面单独展开。2.3 架构分层把路由层、调度层、高可用层拆开整个混合大模型架构我建议至少分成四层理解层职责关键组件接入层统一API入口鉴权、限流API Gateway路由层请求分类、模型选择、策略匹配Router Service核心Agent调度层意图识别、任务拆分、调用编排Agent Orchestrator推理层实际执行模型推理本地推理服务 云端推理服务分层有什么好处隔离。路由层挂了不影响Agent调度推理层某个节点挂了可以快速切换不至于整个链路雪崩。这个设计思路跟传统后端架构里的网关、服务发现、熔断是一个套路只不过把服务换成了模型。3. 路由层的工程实现两份路由表一套动态分流策略路由是整个混合架构的大脑。它要解决的核心问题是一个请求来了到底交给哪个Agent、哪个模型处理3.1 第一份路由表基于请求类型的规则路由在路由服务里我用Python定义了一套轻量路由规则核心逻辑就是意图识别加关键词/元数据匹配。# router_config.yaml routes: - name: after_sales match_tags: [退换货, 物流, 发票] agent: after_sales_agent model: local_7b priority: 10 - name: complex_analysis match_tags: [投诉, 情绪激烈, 复杂问题] agent: analysis_agent model: cloud_flagship priority: 20 - name: knowledge_base match_tags: [政策, 知识库, 产品参数] agent: rag_agent model: local_embedding cloud_rerank priority: 5匹配逻辑走的是最长标签优先 优先级兜底。规则是这样先看消息里命中了哪些标签标签命中数量相同时优先级高的路由胜出。这个设计参考了传统路由协议里最长前缀匹配的思路简单、高效、好排查。import yaml def route_request(message_text, message_meta): with open(router_config.yaml, r) as f: routes yaml.safe_load(f)[routes] matched [] for route in routes: score sum(1 for tag in route[match_tags] if tag in message_text) if score 0: matched.append((score, route[priority], route)) if not matched: # 默认兜底路由返回本地小模型 return default_agent, local_7b matched.sort(keylambda x: (x[0], x[1]), reverseTrue) return matched[0][2][agent], matched[0][2][model]这套规则一开始也遇到问题纯字符串匹配太脆同义词、漏字、错别字都会导致误判。后来我在匹配之前加了一步轻量级意图分类先用一个很小的文本分类模型也可以理解为一种Embedding匹配把用户意图粗分为几大类再进入关键词路由做细粒度匹配。这样既保证了准确率又没有把整个链路搞得太重。3.2 第二份路由表基于资源状态的动态路由规则路由解决做什么动态路由解决能不能做。生产环境里本地GPU负载随时在变云端服务的响应时间和可用性也不稳定。所以我还维护了一张动态状态表{ local_7b: { health: ok, gpu_util: 0.65, avg_latency_ms: 420, last_success: 1710000000.0 }, cloud_flagship: { health: ok, avg_latency_ms: 1200, quota_remaining: 1870, last_success: 1710000000.0 } }路由层在决定最终目标节点前会先更新一下各节点的健康状态。怎么更新每10秒做一次心跳探活加上每次推理请求的返回延迟和错误码统计汇总成状态分。如果本地节点GPU利用率超过90%且平均延迟飙到正常值的2倍以上标记为过载高优先级请求不再分发到该节点。如果云端节点连续3次调用失败或单次超时超过10秒标记为故障切到备用云端节点或本地节点。这就是所谓的基于PBR思路的模型路由——不是看IP前缀而是看模型节点的质量前缀把流量拨到最优的链路上。跟传统策略路由一样核心是策略优先不是简单的轮询或随机。3.3 多Agent之间的协作与共享记忆前面提到多Agent共享记忆这是多Agent架构里容易翻车的地方。我最初的实现是每个Agent独立上下文结果用户从售后助手切换到复杂分析专员时前面聊的退换货细节全丢了专员根本不知道用户在气什么答非所问。后来我把记忆模块单独拆出来做了一个支持向量检索的共享记忆池# 共享记忆写入 def remember(session_id, user_message, agent_reply): embedding embed_text(user_message) memory_store.add( session_idsession_id, textuser_message || agent_reply, embeddingembedding ) # 共享记忆查询 def recall(session_id, current_query): candidates memory_store.search( session_idsession_id, query_embeddingembed_text(current_query), top_k5 ) return format_context(candidates)每个Agent在处理请求前先调用recall()拿回相关的历史片段拼进提示词里。这样无论当前会话被路由到哪个Agent它都能想起用户在之前的对话里说过什么。这个机制的效果是在多Agent切换的场景里用户体感上像在跟同一个客服聊天。4. 高可用设计从单点到多活围绕永远可用做的妥协与坚持高可用不是买保险是日常工程里必须反复演练的科目。混合部署天然具备高可用优势——本地和云端互为备份。但这只是理论优势落地时依然有很多细节要抠。4.1 网关层高可用健康检查、重试与熔断路由服务和高可用逻辑是绑在一起的。在我看来这就是一个应用层的健康检查与自动故障转移机制。我配置了一个可用性探针每10秒向本地推理服务和云端推理服务各发一次探活请求统计连续失败次数。一旦失败次数达到阈值自动把对应节点标记为不可用并通知路由层更新状态表。另外做了一组重试策略这里有一个容易踩的坑——重试会把故障放大。如果云端节点已经挂了所有请求还是先发给它等超时再重试到本地那么这个超时等待会吃掉大量响应时间。正确的做法是第一次调用失败后立即降级到备用节点而不是原地重试。我把重试次数限制在1次且重试目标必须是不等于当前节点的备用节点。这个快速失败 即时切换的思路比傻重试有用得多。还有一个熔断机制当某个节点在1分钟窗口内的错误率超过30%直接打开熔断开关后续5分钟内所有请求默认发往其他节点不再等待探活。等熔断窗口过了放1%的流量试探恢复情况逐步回切。这个思路跟传统微服务里的熔断器是一样的套路在模型调用场景同样适用。4.2 会话保持与上下文迁移的困难点高可用切换最难的不是节点切换而是会话上下文的迁移。假设一个用户正在跟复杂分析专员对话突然云端旗舰模型故障请求被降级到本地7B模型。本地模型能力不如旗舰模型如果直接把之前的完整上下文塞给它它很可能理解不了反而给出更差的回答。我的解决办法是上下文压缩 按需重放。降级时把对话历史用摘要模型压缩成100字以内的要点再交给本地7B模型处理。同时标记当前会话处于降级模式提示词里明确告诉模型用户前面提到的细节可能不完整遇到不确定信息要主动提问而不是猜测。这个方案的代价是降级期间的用户体验会下降但换来的是服务不中断。在可用性面前体验降级是可以接受的总比用户完全得不到服务强。4.3 训练一个质量路由哨兵失败后的自动回切降级不是终点恢复后还要能自动回切。我在高可用模块里加了一个哨兵任务每30秒对故障节点发出探活请求。如果连续3次探活成功就把节点状态从故障改为恢复但先不急着切换流量。接下来进入观察期先分配5%的流量给恢复节点对比其返回质量指标响应时间、错误率如果连续10分钟表现稳定再逐步把流量比例上调到100%。之所以这么谨慎是因为我遇到过倒退陷阱云端服务刚恢复时冷启动阶段的响应速度极慢如果立刻回切全部流量用户会明显感到卡顿反而比故障期间更难忍。5. 生产环境实战实录排查过的典型问题与修改经验这个部分分享几个我在上线过程中真正遇到、并且花了不少时间才解决的问题。如果你是照着上面的架构自己做大概率也会撞上其中几个。5.1 本地模型假死进程在但推理卡死现象健康检查显示本地推理服务进程活着端口能通但实际推理请求全部超时。路由层看到探活成功继续往本地发流量用户体验就是转圈圈。排查探活用的是简单的HTTP GET请求而这个服务内部的推理队列已经满了GPU显存被打满新的推理请求全部排队等待。解决把探活逻辑从进程存活检测升级为带单次极简推理请求的实际调用。每次都发一个请你回复OK的微型请求能正常返回才算健康。这个改动让假死节点在5秒内就会被发现并摘除流量。其实这就是PBR策略路由思想在应用层的一个衍生不只是看链路通不通还要看下一跳是否真的能转发。5.2 上下文长度对延迟的放大效应现象随着会话轮数增加同一个Agent的响应延迟从600ms涨到3秒以上但系统资源占用并没有明显变化。排查把请求日志拉出来对比后发现问题在上下文长度。每轮对话我们都会把完整历史拼进提示词本地7B模型处理长上下文的计算量呈超线性增长导致延迟飙升。解决给本地模型设置上下文窗口上限超过上限的会话把中间历史压缩成摘要只保留最后几轮完整对话和前面的摘要。这个方案让延迟稳定在800ms以内代价是模型对超早期细节的记忆会模糊不过在客服场景里这个代价完全能接受。5.3 权重分配不均本地节点过度包揽现象配置了云端和本地各承担50%流量但线上观察发现本地节点GPU利用率长期90%以上云端节点则很空闲。排查检查路由日志后发现大量短文本请求被规则路由优先分配到本地小模型而这些请求的量远大于预期。规则本身没问题是流量结构变了——客服系统里90%的问题都是我的快递到哪了这类简单查询。解决给路由增加负载感知权重机制。本地节点GPU利用率超过75%时后续简单请求自动降级为云端处理哪怕云端成本稍高也要保证本地资源不被耗死为复杂请求留出余量。5.4 多Agent共享记忆的串味问题现象共享记忆中存储的是原始用户消息和Agent回复的拼接出现了一个问题用户在咨询售后问题时提到了某个产品切换到知识库Agent查询时这个Agent把售后上下文中提到的产品信息当成了已确认的事实使用导致回答错误。解决共享记忆存储时增加来源标注区分用户陈述和Agent推断。检索时只把用户陈述类内容注入到其他Agent的上下文中Agent推断类内容只供当前Agent使用。这个改动对准确率提升非常明显。6. 关键参数配置参考一套可以直接抄作业的默认值每个项目参数不同但默认值可以给个参考我现在生产环境里跑的就是这套配置。配置项默认值说明健康检查间隔10秒太频繁会浪费资源太慢会影响故障发现速度熔断错误率阈值30%1分钟窗口低于这个值先降级高于直接熔断降级流量比例100%切备用不搞渐进降级故障时一步到位恢复试探流量5%10分钟观察慢慢加量防止恢复假象上下文摘要触发长度超过10轮对话本地模型场景云端可以放宽本地GPU利用率阈值75%超过阈值分流至云端云端调用超时时间10秒超过直接算失败切本地共享记忆检索top_k5太少上下文不够太多干扰模型这些参数不是拍脑袋定的大部分是从故障恢复时间和用户体验两个维度推出来的。比如超时10秒是因为用户能忍受的响应极限大约在10-15秒之间比如熔断阈值30%是因为在实际故障演练里低于这个错误率时手动降级比自动熔断更稳。7. 经验补充分享几条我在实际操作中反复受益的体会调整权限和特例这件事在整个方案中体现得很多但有几条原则性的体会值得单独说说。第一路由规则一定要可视化。我一度把路由配置写得很复杂后来线上出了误判排了一个下午才发现是规则的优先级写反了。现在我在路由服务里加了一个调试接口输入任意文本返回命中了哪些规则、为什么命中、权重怎么算的。排查效率直线上升。第二高可用切换时必须保证幂等。降级切换期间同一个用户请求可能被发送到本地模型随后又切回云端模型重试一次如果这两次结果不一致用户会看到同一个问题得到两个完全不同的大模型回复体验很割裂。解决方式是在会话里记录当前回答已生成重复请求直接返回第一次结果。第三成本监控要和路由联动。云端调用是烧钱的本地调用是省钱的。我在路由状态表里加了一个quota_remaining字段当云端调用余额或配额快用完时自动调低云端节点的优先级把更多流量转到本地。这样成本是动态可控的不至于月底出账单时血压升高。第四多Agent的记忆一定要做隔离和降噪。全部共享是灾难完全不共享是浪费要找到一个平衡点。我的经验是用户明确表达过的信息共享Agent自己推理出来的信息不共享或只在实际需要时共享。这套混合大模型架构从设计到落地前前后后改了三轮每一次改动都来自线上真实问题。分布式系统的高可用设计思路在大模型场景里依然好用只是把服务健康检查换成了模型能力检查、流量分发换成了请求意图路由。核心原则没变永远给用户一个可用的备选方案永远不要因为单点故障而整体不可用。 混合大模型架构实战：路由策略与多Agent高可用设计
1. 为什么需要一套混合大模型架构从单模型堵点到多Agent体系先聊一个很实际的问题单一大模型跑生产环境到底卡在哪我在过去一年多反复遇到三个坎。第一个是场景覆盖不够。同一个模型很难在复杂推理、代码生成、轻量对话、内容分类这几个方向同时做到又快又省强行用一个模型扛全部流量要么贵得离谱要么响应慢到用户投诉。第二个是数据安全与成本矛盾。有些内部知识库、客户隐私数据根本不适合全部上云但云上大模型的能力确实更强这时候不能二选一只能两边都留。第三个是单点故障的真实代价。曾经有一次云端模型服务宕了四十分钟整个在线助手全部不可用客服系统被打爆那种体验一次就够。所以混合大模型架构这个词本质上不是在追新概念它是被这些生产问题逼出来的。核心思路很简单把不同能力、不同部署位置的模型组合成一个集群在它们前面架一道智能路由上层再接多Agent调度底层做高可用保障。这样一来每个模型只做自己最擅长的事流量按需分发挂了也有备胎顶上。这套方案适合谁后端工程师、AI应用架构师、以及那些正在从小demo往生产级应用过渡的团队。如果你手头有超过三个以上的模型调用场景或者正在纠结到底用云还是本地的问题这篇文章里的思路和代码可以直接拿去改。我自己搭这套体系的直接动因是把一个原本重度依赖云端大模型的客服机器人改造成本地小模型打底 云端大模型增强 多Agent分工的结构。整个改造过程踩了不少坑尤其是路由策略和高可用切换这两块走了很多弯路。所以这篇内容不是理论堆砌全部是实际跑过、验证过的方案。2. 方案选型背后的思考为什么不能粗暴地全都放云端或全都跑本地在动手之前要先想清楚一个架构方向本地部署、云端调用、还是混合部署。这个决策直接决定了后续所有代码怎么写、监控怎么搭、故障怎么处理。2.1 全云端和全本地的代价你可能没算全全云端的优势是模型能力强、接入快、不用管硬件。但问题也很明显数据出域风险。凡是涉及隐私的对话内容客户可能根本不允许出内网。全本地部署则反过来数据安全可控可模型能力天花板低GPU采购成本和运维成本高得吓人。我算过一笔账一个中等规模的团队如果要本地跑一个能媲美云端旗舰模型的推理服务光显卡投入就是几十万起步更不用说后续的散热、机房和值班工程师成本。所以混合部署不是既要又要的妥协而是从成本、安全、性能三个维度取最优解。把高频、敏感、低复杂度的请求留在本地把低频、高难度、需要最强推理能力的请求转发到云端。这是成本和安全之间的动态平衡也是我在实际项目里验证过最可持续的模型接入方式。2.2 多Agent在这里面的真实角色很多人把多Agent理解为多个AI角色一起聊天工程上的理解应该更务实Agent是策略的执行单元每个Agent背后绑定一个能完成特定任务的模型调用链。路由层收到用户请求后先做意图识别再按规则把请求分给对应的AgentAgent内部再去决定调用本地模型还是云端模型。举个例子我的客服系统里有三个Agent一个是售后助手绑定本地部署的7B对话模型处理退换货、物流查询这类标准化问题一个是复杂分析专员绑定云端大模型负责解析用户情绪、生成安抚话术还有一个是知识库检索Agent负责访问向量数据库给其他Agent提供上下文。这三个Agent共享一个短时记忆池保证用户在同一个会话里切换Agent时上下文不断裂。关于多Agent共享记忆后面单独展开。2.3 架构分层把路由层、调度层、高可用层拆开整个混合大模型架构我建议至少分成四层理解层职责关键组件接入层统一API入口鉴权、限流API Gateway路由层请求分类、模型选择、策略匹配Router Service核心Agent调度层意图识别、任务拆分、调用编排Agent Orchestrator推理层实际执行模型推理本地推理服务 云端推理服务分层有什么好处隔离。路由层挂了不影响Agent调度推理层某个节点挂了可以快速切换不至于整个链路雪崩。这个设计思路跟传统后端架构里的网关、服务发现、熔断是一个套路只不过把服务换成了模型。3. 路由层的工程实现两份路由表一套动态分流策略路由是整个混合架构的大脑。它要解决的核心问题是一个请求来了到底交给哪个Agent、哪个模型处理3.1 第一份路由表基于请求类型的规则路由在路由服务里我用Python定义了一套轻量路由规则核心逻辑就是意图识别加关键词/元数据匹配。# router_config.yaml routes: - name: after_sales match_tags: [退换货, 物流, 发票] agent: after_sales_agent model: local_7b priority: 10 - name: complex_analysis match_tags: [投诉, 情绪激烈, 复杂问题] agent: analysis_agent model: cloud_flagship priority: 20 - name: knowledge_base match_tags: [政策, 知识库, 产品参数] agent: rag_agent model: local_embedding cloud_rerank priority: 5匹配逻辑走的是最长标签优先 优先级兜底。规则是这样先看消息里命中了哪些标签标签命中数量相同时优先级高的路由胜出。这个设计参考了传统路由协议里最长前缀匹配的思路简单、高效、好排查。import yaml def route_request(message_text, message_meta): with open(router_config.yaml, r) as f: routes yaml.safe_load(f)[routes] matched [] for route in routes: score sum(1 for tag in route[match_tags] if tag in message_text) if score 0: matched.append((score, route[priority], route)) if not matched: # 默认兜底路由返回本地小模型 return default_agent, local_7b matched.sort(keylambda x: (x[0], x[1]), reverseTrue) return matched[0][2][agent], matched[0][2][model]这套规则一开始也遇到问题纯字符串匹配太脆同义词、漏字、错别字都会导致误判。后来我在匹配之前加了一步轻量级意图分类先用一个很小的文本分类模型也可以理解为一种Embedding匹配把用户意图粗分为几大类再进入关键词路由做细粒度匹配。这样既保证了准确率又没有把整个链路搞得太重。3.2 第二份路由表基于资源状态的动态路由规则路由解决做什么动态路由解决能不能做。生产环境里本地GPU负载随时在变云端服务的响应时间和可用性也不稳定。所以我还维护了一张动态状态表{ local_7b: { health: ok, gpu_util: 0.65, avg_latency_ms: 420, last_success: 1710000000.0 }, cloud_flagship: { health: ok, avg_latency_ms: 1200, quota_remaining: 1870, last_success: 1710000000.0 } }路由层在决定最终目标节点前会先更新一下各节点的健康状态。怎么更新每10秒做一次心跳探活加上每次推理请求的返回延迟和错误码统计汇总成状态分。如果本地节点GPU利用率超过90%且平均延迟飙到正常值的2倍以上标记为过载高优先级请求不再分发到该节点。如果云端节点连续3次调用失败或单次超时超过10秒标记为故障切到备用云端节点或本地节点。这就是所谓的基于PBR思路的模型路由——不是看IP前缀而是看模型节点的质量前缀把流量拨到最优的链路上。跟传统策略路由一样核心是策略优先不是简单的轮询或随机。3.3 多Agent之间的协作与共享记忆前面提到多Agent共享记忆这是多Agent架构里容易翻车的地方。我最初的实现是每个Agent独立上下文结果用户从售后助手切换到复杂分析专员时前面聊的退换货细节全丢了专员根本不知道用户在气什么答非所问。后来我把记忆模块单独拆出来做了一个支持向量检索的共享记忆池# 共享记忆写入 def remember(session_id, user_message, agent_reply): embedding embed_text(user_message) memory_store.add( session_idsession_id, textuser_message || agent_reply, embeddingembedding ) # 共享记忆查询 def recall(session_id, current_query): candidates memory_store.search( session_idsession_id, query_embeddingembed_text(current_query), top_k5 ) return format_context(candidates)每个Agent在处理请求前先调用recall()拿回相关的历史片段拼进提示词里。这样无论当前会话被路由到哪个Agent它都能想起用户在之前的对话里说过什么。这个机制的效果是在多Agent切换的场景里用户体感上像在跟同一个客服聊天。4. 高可用设计从单点到多活围绕永远可用做的妥协与坚持高可用不是买保险是日常工程里必须反复演练的科目。混合部署天然具备高可用优势——本地和云端互为备份。但这只是理论优势落地时依然有很多细节要抠。4.1 网关层高可用健康检查、重试与熔断路由服务和高可用逻辑是绑在一起的。在我看来这就是一个应用层的健康检查与自动故障转移机制。我配置了一个可用性探针每10秒向本地推理服务和云端推理服务各发一次探活请求统计连续失败次数。一旦失败次数达到阈值自动把对应节点标记为不可用并通知路由层更新状态表。另外做了一组重试策略这里有一个容易踩的坑——重试会把故障放大。如果云端节点已经挂了所有请求还是先发给它等超时再重试到本地那么这个超时等待会吃掉大量响应时间。正确的做法是第一次调用失败后立即降级到备用节点而不是原地重试。我把重试次数限制在1次且重试目标必须是不等于当前节点的备用节点。这个快速失败 即时切换的思路比傻重试有用得多。还有一个熔断机制当某个节点在1分钟窗口内的错误率超过30%直接打开熔断开关后续5分钟内所有请求默认发往其他节点不再等待探活。等熔断窗口过了放1%的流量试探恢复情况逐步回切。这个思路跟传统微服务里的熔断器是一样的套路在模型调用场景同样适用。4.2 会话保持与上下文迁移的困难点高可用切换最难的不是节点切换而是会话上下文的迁移。假设一个用户正在跟复杂分析专员对话突然云端旗舰模型故障请求被降级到本地7B模型。本地模型能力不如旗舰模型如果直接把之前的完整上下文塞给它它很可能理解不了反而给出更差的回答。我的解决办法是上下文压缩 按需重放。降级时把对话历史用摘要模型压缩成100字以内的要点再交给本地7B模型处理。同时标记当前会话处于降级模式提示词里明确告诉模型用户前面提到的细节可能不完整遇到不确定信息要主动提问而不是猜测。这个方案的代价是降级期间的用户体验会下降但换来的是服务不中断。在可用性面前体验降级是可以接受的总比用户完全得不到服务强。4.3 训练一个质量路由哨兵失败后的自动回切降级不是终点恢复后还要能自动回切。我在高可用模块里加了一个哨兵任务每30秒对故障节点发出探活请求。如果连续3次探活成功就把节点状态从故障改为恢复但先不急着切换流量。接下来进入观察期先分配5%的流量给恢复节点对比其返回质量指标响应时间、错误率如果连续10分钟表现稳定再逐步把流量比例上调到100%。之所以这么谨慎是因为我遇到过倒退陷阱云端服务刚恢复时冷启动阶段的响应速度极慢如果立刻回切全部流量用户会明显感到卡顿反而比故障期间更难忍。5. 生产环境实战实录排查过的典型问题与修改经验这个部分分享几个我在上线过程中真正遇到、并且花了不少时间才解决的问题。如果你是照着上面的架构自己做大概率也会撞上其中几个。5.1 本地模型假死进程在但推理卡死现象健康检查显示本地推理服务进程活着端口能通但实际推理请求全部超时。路由层看到探活成功继续往本地发流量用户体验就是转圈圈。排查探活用的是简单的HTTP GET请求而这个服务内部的推理队列已经满了GPU显存被打满新的推理请求全部排队等待。解决把探活逻辑从进程存活检测升级为带单次极简推理请求的实际调用。每次都发一个请你回复OK的微型请求能正常返回才算健康。这个改动让假死节点在5秒内就会被发现并摘除流量。其实这就是PBR策略路由思想在应用层的一个衍生不只是看链路通不通还要看下一跳是否真的能转发。5.2 上下文长度对延迟的放大效应现象随着会话轮数增加同一个Agent的响应延迟从600ms涨到3秒以上但系统资源占用并没有明显变化。排查把请求日志拉出来对比后发现问题在上下文长度。每轮对话我们都会把完整历史拼进提示词本地7B模型处理长上下文的计算量呈超线性增长导致延迟飙升。解决给本地模型设置上下文窗口上限超过上限的会话把中间历史压缩成摘要只保留最后几轮完整对话和前面的摘要。这个方案让延迟稳定在800ms以内代价是模型对超早期细节的记忆会模糊不过在客服场景里这个代价完全能接受。5.3 权重分配不均本地节点过度包揽现象配置了云端和本地各承担50%流量但线上观察发现本地节点GPU利用率长期90%以上云端节点则很空闲。排查检查路由日志后发现大量短文本请求被规则路由优先分配到本地小模型而这些请求的量远大于预期。规则本身没问题是流量结构变了——客服系统里90%的问题都是我的快递到哪了这类简单查询。解决给路由增加负载感知权重机制。本地节点GPU利用率超过75%时后续简单请求自动降级为云端处理哪怕云端成本稍高也要保证本地资源不被耗死为复杂请求留出余量。5.4 多Agent共享记忆的串味问题现象共享记忆中存储的是原始用户消息和Agent回复的拼接出现了一个问题用户在咨询售后问题时提到了某个产品切换到知识库Agent查询时这个Agent把售后上下文中提到的产品信息当成了已确认的事实使用导致回答错误。解决共享记忆存储时增加来源标注区分用户陈述和Agent推断。检索时只把用户陈述类内容注入到其他Agent的上下文中Agent推断类内容只供当前Agent使用。这个改动对准确率提升非常明显。6. 关键参数配置参考一套可以直接抄作业的默认值每个项目参数不同但默认值可以给个参考我现在生产环境里跑的就是这套配置。配置项默认值说明健康检查间隔10秒太频繁会浪费资源太慢会影响故障发现速度熔断错误率阈值30%1分钟窗口低于这个值先降级高于直接熔断降级流量比例100%切备用不搞渐进降级故障时一步到位恢复试探流量5%10分钟观察慢慢加量防止恢复假象上下文摘要触发长度超过10轮对话本地模型场景云端可以放宽本地GPU利用率阈值75%超过阈值分流至云端云端调用超时时间10秒超过直接算失败切本地共享记忆检索top_k5太少上下文不够太多干扰模型这些参数不是拍脑袋定的大部分是从故障恢复时间和用户体验两个维度推出来的。比如超时10秒是因为用户能忍受的响应极限大约在10-15秒之间比如熔断阈值30%是因为在实际故障演练里低于这个错误率时手动降级比自动熔断更稳。7. 经验补充分享几条我在实际操作中反复受益的体会调整权限和特例这件事在整个方案中体现得很多但有几条原则性的体会值得单独说说。第一路由规则一定要可视化。我一度把路由配置写得很复杂后来线上出了误判排了一个下午才发现是规则的优先级写反了。现在我在路由服务里加了一个调试接口输入任意文本返回命中了哪些规则、为什么命中、权重怎么算的。排查效率直线上升。第二高可用切换时必须保证幂等。降级切换期间同一个用户请求可能被发送到本地模型随后又切回云端模型重试一次如果这两次结果不一致用户会看到同一个问题得到两个完全不同的大模型回复体验很割裂。解决方式是在会话里记录当前回答已生成重复请求直接返回第一次结果。第三成本监控要和路由联动。云端调用是烧钱的本地调用是省钱的。我在路由状态表里加了一个quota_remaining字段当云端调用余额或配额快用完时自动调低云端节点的优先级把更多流量转到本地。这样成本是动态可控的不至于月底出账单时血压升高。第四多Agent的记忆一定要做隔离和降噪。全部共享是灾难完全不共享是浪费要找到一个平衡点。我的经验是用户明确表达过的信息共享Agent自己推理出来的信息不共享或只在实际需要时共享。这套混合大模型架构从设计到落地前前后后改了三轮每一次改动都来自线上真实问题。分布式系统的高可用设计思路在大模型场景里依然好用只是把服务健康检查换成了模型能力检查、流量分发换成了请求意图路由。核心原则没变永远给用户一个可用的备选方案永远不要因为单点故障而整体不可用。