1. 项目概述与整体设计思路先交代一下背景我最近半年一直在做一套面向企业内部的智能问答与自动化处理平台底座是大模型但并不是单一模型走到底而是把多种模型拼在一起用。项目上线后踩了不少坑最大的感受是单纯靠一个模型很难在效果、成本、响应速度三者之间找到平衡点。于是我把架构演进成了一套混合大模型架构本地部署开源模型处理高频和敏感请求云端商用模型处理复杂推理和少数疑难case中间加一层路由调度背后用多Agent协同编排任务同时用一套高可用方案保证任何一个组件挂了都不至于让整个服务不可用。这套方案的适用场景很明确你的业务需要大模型推理能力但你又不能把所有数据都丢到云端或者你希望控制成本、降低延迟同时还想让多个模型各司其职。换句话说混合大模型架构解决的核心问题是三个会话数据的隐私边界、单模型能力的短板、系统整体的可用性。如果你是做AI应用的后端工程师、架构师或者你所在团队正在评估从单一模型往多模型方向演进那这篇文章应该能帮你少走一些弯路。整个项目的技术栈分布大概是这样底层基础设施是CentOS服务器加PostgreSQL和MySQL两套数据库中间服务层用Python写Agent编排逻辑网络层涉及双网卡、策略路由和负载均衡再往上就是模型网关这一层。后面我会按模块把路由、多Agent、高可用这些细节展开。2. 多Agent架构设计与并发配置2.1 Agent职责拆分多Agent不是简单地把多个大模型实例堆在一起就行它和自然语言理解、任务分解、工具调度是强绑定的。我在实际项目中把Agent分成了四层。最外层是入口Agent负责接收用户提问做意图识别和敏感信息过滤。第二层是规划Agent负责把复杂任务拆解成子任务判断每个子任务需要调用本地模型还是云端模型。第三层是执行Agent每个执行Agent绑定一个具体的大模型实例有基于本地部署模型的也有对接云端API的。第四层是验证Agent专门检查执行结果是否符合预期如果质量不达标就触发重新调度。四层各司其职之后系统的可维护性提升了一大截。以前所有逻辑都塞在一个Agent里并发一上来就乱套现在每个Agent只做一件事出问题时我也能快速定位到底是在哪一层出的问题。2.2 Agent并发参数配置多Agent最容易翻车的地方就是并发配置。我一开始想简单了以为给每个Agent加线程池就行结果系统一上线就被打爆了。原因在于每个Agent不只是CPU计算它还会访问数据库、调用模型推理接口、读写缓存瓶颈经常在IO上而不是单纯的CPU。我的建议是按两层来配并发。第一层是网关层的并发控制同时放进来多少个会话请求这层我用的是进程池加信号量进程数设置为CPU核心数的两倍左右信号量限制了同一时刻最多同时处理任务数避免请求全部涌进来。第二层是模型调用层的并发控制同时跑多少个模型推理请求这层需要重点盯着GPU显存和模型服务的吞吐。给一组实测数据参考我用的本地模型是7B参数的量化版本单卡在普通生成场景下大概能扛住每秒四到五个请求。如果你把Agent并发开到二十以上模型服务就会出现排队响应时间会从两秒涨到七八秒。所以在配多Agent并发时先压测模型服务本身的能承受的QPS再倒推Agent的并发数比拍脑袋定要靠谱得多。另外还有一个容易忽略的点Agent之间如果共享数据库连接池要特别注意连接数的分配。规划Agent的并发是直接乘上预估的子任务数量这个操作在高并发场景下会把连接池瞬间打满。我给每个Agent配置了独立的连接池上限核心Agent的池子大一些边缘Agent的池子小一些实测下来对系统稳定性帮助非常大。2.3 多Agent协同的几处关键细节多Agent协同说白了就是一套带状态的任务流转机制。我在实现之初借鉴了工作流引擎的思想每个任务都有生命周期从created到scheduled再到running最后是succeeded或failed。这里有几个细节值得记录。第一Agent之间的通信我用的是消息队列而不是直接HTTP调用。直接调用的问题是调用链太深容易超时而且没有办法做重试。改用消息队列之后Agent之间彻底解耦队列还能顺带做削峰填谷。第二任务状态不能让Agent自己维护而是统一放到后端的任务表里否则一旦Agent崩溃状态就全丢了。第三规划Agent分出来的子任务要带有依赖关系字段处理的时候才能确定谁先执行谁后执行。我遇到过这样的问题几个执行Agent同时处理同一个批次的任务结果对同一份业务数据进行更新导致数据被覆盖。后来我在任务表里加了版本号字段Agent每次更新前先比较版本号版本不对就不往下写这才把问题解决。多Agent系统里并发安全永远不是小事。3. 模型路由与本地/云端混合部署的基础设计3.1 模型路由的决策逻辑路由是整个混合架构里的大脑它决定了每个请求到底是去本地模型跑还是去云端模型跑或者是多个模型并行跑再取最优结果。这个决策直接影响成本、延迟和效果。我设计模型路由时没有用特别花哨的规则就是一个多级判断的流程。第一步看数据敏感性包含公司内部敏感字段的请求无条件路由到本地模型即使本地模型效果差一些也不能出内网。第二步看任务类型如果用户明确要求写代码、做数学推理这种本地模型不擅长的事情直接路由到云端模型。第三步看成本预算每个月给云端调用设一个配额配额超了就自动把请求转移到本地模型。第四步看当前负载如果本地模型服务已经满了也会把一部分请求临时转到云端。这套流程说起来简单但落地的时候要特别注意优先级排序。敏感性和任务类型的判断优先级最高成本和负载只是兜底。如果顺序搞反了比如先看负载再看敏感性那敏感数据就可能因为本地负载高而被转发到云端这种事一次都不能发生。3.2 策略路由思想在模型网关中的落地说到路由我在做模型网关的时候发现它和网络里的策略路由PBR思想是相通的。PBR是什么意思呢普通的静态路由是根据目的IP决定下一跳而策略路由可以基于源地址、报文大小、应用类型做更细粒度的路径选择。我借鉴这套思路把模型网关的路由也做成了可配置的策略表。每条策略包含匹配条件和动作。匹配条件有请求来源、用户ID、模型类别、请求内容长度等动作就是转发到某个模型端点或者做降级处理。策略表存放在数据库里网关启动时加载到内存缓存管理员修改策略后通过接口刷新缓存不需要重启网关进程。比如我有一条策略是这么写的来源IP属于内网运维网段且请求包含代码生成关键词则路由到大参数云端模型用来保证内部开发人员的使用体验。实际上就是走云端API。另一条策略是普通业务请求优先走本地模型本地模型超时或返回异常时降级到云端模型。这些策略用类似规则引擎的方式实现比硬编码在代码里灵活得多。3.3 双网卡场景下的路由配置混合部署还有一个绕不开的环节服务器通常有两张网卡一张接内网一张接公网。内网网卡用来访问本地模型集群和数据库公网网卡用来访问云端模型API。如果默认路由配置不当就有可能出现公网流量走了内网或者内网流量出了公网的情况。我在项目里遇到过很典型的案例服务器装了两张网卡系统默认路由指向了内网网关结果云端API的请求全部超时。排查下来发现虽然访问外网IP的数据包从公网网卡出发了但响应回来的包是从内网网卡进入的连接状态对不上直接被丢弃。解决办法就是配策略路由给两个网卡分别建独立的路由表然后按源IP或者按目标网段来选择走哪张网卡。具体到CentOS系统上我在/etc/iproute2/rt_tables里增加了100 lan和200 wan两个表然后在/etc/sysconfig/network-scripts/下配置了对应的路由规则。所有访问内网网段的流量固定走lan表其余流量走wan表同时保留了一条默认路由作为兜底。这里补充一个很容易踩的坑配置完策略路由之后要测试对称路由也就是出去的路径和回来的路径要一致否则连接会不稳定。由于有些网络环境会过滤非对称路由的包所以在很多生产环境里常见的做法是干脆把默认路由删掉只保留两条精确的路由规则这样最干净。4. 高可用方案设计与落地4.1 高可用方案的整体层次高可用不能只看某一个点它是一个从下到上的体系。我在这个项目里把它分成了四层网络层、服务层、数据层、应用层。每一层都有自己对应的高可用手段。网络层的重点是冗余和切换常见的做法是双网卡绑定加交换机堆叠保证单点网络故障不影响业务。服务层的高可用是负载均衡加健康检查多个模型网关实例挂在负载均衡后面某个实例挂了流量自动切到其他实例。数据层的高可用是主从复制加自动切换PostgreSQL和MySQL分别做主从同步主机故障后从库自动升主。应用层的保障是多副本部署加状态外置Agent实例没有本地状态任何实例都可以随时替换。这四层里数据层的高可用是最容易出问题的也是我最想展开讲的。因为模型网关、Agent这些服务都是无状态的设计挂了就重启反倒是数据库这种有状态的组件一旦出故障处理起来要特别小心。4.2 数据库高可用的两套方案实践我在项目里其实同时用了两套数据库一套PostgreSQL用来存任务状态和Agent元数据一套MySQL用来存业务数据。之所以没有统一成一套是因为业务团队指定要用MySQL而任务状态这边我更喜欢PostgreSQL的一些特性。两套数据库我分别用了不同的高可用方案。PostgreSQL这边我用的是主从异步流复制加Patroni管理。Patroni会监听PostgreSQL的健康状态主库故障时自动把从库提升为主库同时通过etcd做分布式锁保证只有一个节点能成为新的主节点。这套方案在实测中切换时间大概在十秒左右我当时体验下来觉得相对可靠应用层只需要配置数据库连接串并且程序里加入重连和重试的逻辑即可。MySQL这边用的是MGRMySQL Group Replication方案也就是组复制。MGR的特点是同一时刻只有一个主节点写入其他节点实时同步主节点故障时组内自动选举新主。这套方案在机房内网环境下运行很稳定延迟基本上在毫秒级但跨机房部署时网络抖动会导致同步断开所以如果后续要跨机房容灾可能还是要评估一下其他方案。两套方案给我的共同教训是高可用不是搭建完就完事了要定期做故障演练。我每个月会主动停掉主库模拟一次切换看看整个流程能不能自动跑通。第一次演练的时候我发现PostgreSQL切换后有几个应用连接没有正确重连导致服务一直报错这正是平时不演练发现不了的。4.3 故障切换的整体流程把高可用真正落到每天的操作里就需要定义清晰的故障切换流程。我总结了一套适用混合大模型架构的切换流程按顺序分为六个步骤。第一步是故障检测。这里我用的是健康检查探活每五秒检查一次关键组件的状态连续三次失败就认为出故障了。第二步是确认故障范围。这里需要区分到底是模型服务挂了还是数据库挂了还是只是某个Agent实例不稳定。确认范围很重要因为不同的故障类型对应的切换策略完全不同。第三步是执行切换。比如数据库主备切换或者网关请求重新分配目标。第四步是流量切换后的验证。切换到备用节点之后要立即发几个测试请求确认链路是通的再用真实流量慢慢放量。第五步是通知与记录把故障原因和处理过程记录下来。第六步是复盘找到根因然后评估到底需要改进什么。这里面最容易忽略的是第二步不管是自动化的检测还是人工的判断都要先想清楚故障影响面再动作。如果你不问清楚就急着切很可能把本来好好的节点也弄挂。我之前有一次因为网络抖动导致健康检查误报系统自动把主库切走了结果原主库根本没挂两个库同时写数据最后花了好几个小时才修复数据一致性。从那之后我在健康检查的逻辑里增加了连续失败次数的延迟确认机制还引入了第二套检查维度比如磁盘和网络延迟的综合评估误报率就降下来了。5. 实战中的坑与排查技巧5.1 多Agent并发调用模型导致资源耗尽第一个典型的坑是多Agent并发调用模型服务时GPU显存直接被打满然后模型服务进程崩溃。表现的症状是系统刚开始运行正常并发一上来所有请求都超时日志里全是CUDA out of memory。排查思路是这样的先看模型服务本身的日志确认是不是显存溢出。如果是再去看Agent这层的最大并发数是多少和模型服务能承受的并发量是否匹配。这个问题的根因就是Agent层的并发配置没和模型服务层对齐Agent认为自己在并发执行但模型服务根本处理不过来。解决的办法有两个方向。一个是控制Agent层的并发上限把并发数降到模型服务压测值的百分之七十左右留一定的缓冲。另一个是在模型服务前面加一层队列把超出处理能力的请求排队而不是直接丢弃。我最后两个方向都做了并发降了下来队列排了起来系统稳定性明显好了很多。5.2 双网卡配置导致的云端模型访问超时第二个坑在前面提到过就是双网卡服务器访问云端模型API超时。这个问题的排查过程比较复杂我整理一下排查思路方便你以后参考。第一步用ping和curl测试公网连通性看是不是网络本身的问题。第二步查看系统路由表ip route show看一下默认路由指向了哪个网卡如果指向内网网卡那外网访问肯定有问题。第三步查策略路由规则ip rule show看一下有没有自定义的路由规则把流量引到了错误的地方。第四步同时抓两个网卡的包分析数据包到底是从哪张网卡出去的回包又出现在哪张网卡上。我最后抓包发现数据包从公网网卡发出去没问题但回包到了内网网卡因为内网网卡也配置了同网段的IP系统回包时选了内网路径。解决方法是给公网网卡的回包路径单独加一条策略路由并且调整路由优先级让回包强制走公网网卡。这种问题在混合部署场景里其实非常常见。建议你如果有双网卡需求第一个动作就是把策略路由和默认路由的设计画出来确保出方向入方向都清晰可见再动手配置。5.3 高可用切换后连接池不释放第三个坑是数据库主备切换后应用层的连接池还保持着旧主库的连接导致写操作全部失败。PostgreSQL主备切换的瞬间旧主库的连接会断开但应用层的连接池不知道它会继续从池子里拿出坏连接去执行SQL报错后应用又没有重试机制于是服务就直接挂了。解决这个问题的办法我在中间件这一侧做了两个处理。第一连接池配置了testOnBorrow每次从池子里拿连接之前先做一次校验如果校验失败就直接丢弃重建。第二应用层做了数据库操作的自动重试当报错类型是连接异常或者主库不可达时短暂等待后重新执行一次操作。这种问题靠代码层面解决是不够的还必须在运维层面配合。我在做主备切换演练时会刻意观察应用日志里有没有大量的连接异常如果有就说明应用的连接池配置还需要继续调优。5.4 Agent任务卡死与消息堆积还有一个非常隐蔽的坑某个Agent处理的子任务里有少量长期不返回结果的任务这些任务把线程池的线程全部占住了后续任务全部阻塞。因为每个任务都设置了超时时间但超时后线程没有真正中断资源没有释放。这里需要说明一下Python的线程一旦启动如果要强制中断它一般会涉及到比较复杂的处理方式不一定能很好地配合那些依赖锁和数据库连接的代码。更稳妥的办法是从业务层面控制。我给每个Agent的线程池设置了一个队列大小和一个拒绝策略队列满了就不接收新任务拒绝策略触发时把任务重新放回消息队列等线程空出来再消费。另外每个子任务的超时时间不能统一设置。规划Agent生成的任务有的简单有的复杂统一设一个超时时间会导致简单的任务过早超时复杂的任务又一直完不成。我后来会根据任务的预估复杂度和历史执行耗时动态计算超时时间简单任务给三十秒复杂任务能到十分钟这样一来任务卡死的情况就大大减少了。6. 这套架构后续的演进与个人体会6.1 从静态路由走向动态路由我目前的模型路由策略基本都是预设规则的静态路由虽然能满足大部分业务需求但它有一个明显的局限——无法根据模型效果动态调整。比如本地模型升级了一个新版本整体能力变强了但路由策略还是按旧版本的能力在分配流量就浪费了新版本的能力。后续我计划在路由层加入动态反馈机制。每个请求处理完成后验证Agent会给一个质量分这个分数会回流到路由模块路由模块定期统计每个模型在不同任务类型上的平均得分。当某个模型在某个任务类型上的得分高于另一个模型时自动调高这类任务路由到该模型的比例。相当于给路由做了一个线上A/B测试的机制。这个演进做起来有一定复杂度主要难在质量分的建设和回流通道的稳定性。但如果真能做出来混合大模型架构的智能化程度会再上一个台阶成本控制也会精细很多。6.2 监控告警与容量规划的经验最后分享一点我自己在监控和容量规划上的体会。混合部署架构比单一模型架构要复杂得多你不仅要看服务器CPU、内存、GPU这些基础指标还要看模型服务的队列深度、平均响应时间、路由命中率这些业务指标。我自己搭了一套监控看板把几个核心指标放在一屏上模型服务的GPU利用率和队列深度、Agent线程池的活跃线程数、数据库的连接数和主从延迟、路由层的请求分布和策略命中情况、以及云端API调用的费用估算。这些指标一旦出现异常在它们的演化趋势变得明显之前往往就已经能从看板上看出端倪了。容量规划方面我一开始低估了模型服务的扩容成本。本地模型每加一个GPU节点规划、采购、部署、压测整体节奏比较慢而云端模型的弹性扩容随时可以做费用本身可控。这个特性决定了混合部署这套方案天然要留一手弹性能力日常流量以本地模型为主大促或突增流量时把压力转移到云端。这也是为什么我把云端API的连接配置和自动降级机制从一开始就做进去了。回过头来看这套架构的整个演进过程我的体会是混合大模型架构、多Agent协同、本地/云端混合部署、路由与高可用每一块单独拿出来都有成熟的技术方案难的是把它们组合到一起并让整个系统在真实业务压力下稳定运转。组合得好不好取决于你对模型能力、系统资源、成本预算和故障场景这四件事的理解深度。踩过这些坑之后我越来越坚信一件事架构没有银弹只有把每个环节的取舍想清楚系统才会在关键时候替你把事情扛住。