1. 开场为什么需要智能模型路由AI网关负责统一接入外部大模型API和内部自建模型转发请求、管理密钥、控制限流。传统网关就是一个固定转发代理但实际接上多个模型后会发现业务方对模型的需求往往非常动态——同一套对话系统有的用户问法律问题需要专家模型有的用户只需要快速闲聊用轻量模型成本压力大的时候希望自动降级到便宜模型晚上流量高峰又希望优先保障核心链路。这些场景靠“人工在配置中心改路由规则”根本忙不过来于是就需要让网关本身具备路由决策能力根据请求特征、模型状态、成本策略等条件自动把一次请求分发给最合适的后端模型。这就是智能模型路由要解决的核心问题把“人去选模型”变成“网关替人选模型”。这篇文章结合我个人的落地经验把路由设计方案、关键算法、扩展边界和排坑过程完整拆开讲适合正在做AI网关或准备接多模型的同学参考。2. 路由设计前必须回答的三个问题动手写路由模块之前我建议团队先坐下来把三个问题讨论清楚否则后面容易返工。2.1 路由决策的输入是什么路由不是随便拍脑袋选模型必然基于一组信号。我梳理下来常用输入分四类请求特征包括意图类型闲聊、法律、医疗、输入长度、是否多轮、是否涉及敏感词、需要JSON结构化输出还是自由文本业务属性来自调用方的app_id、渠道来源、业务线、用户等级比如VIP用户路由到更强模型免费用户统一走轻量版模型状态模型是否过载、错误率、平均响应时延、排队长度成本约束当天预算消耗、模型单价、企业自定义的限流策略。建议在第一步先定义好路由输入的数据结构和来源。以我的实践为例网关在HTTP请求进入时就解析出headers中的业务标识、body中的消息长度和意图标签并同时从模型状态服务拉取所有可用实例的负载信息打包成一张上下文字典供路由策略实时消费。2.2 路由决策是规则为主还是模型为主我见过不少团队直接上机器学习模型做路由效果反而不稳定。原因在于路由决策的可解释性要求很高一旦选错模型业务方会质疑“为什么给我分到了一个弱的模型”如果拿不出一套可解释的规则很难收场。实际落地推荐“规则基座动态加权”的混合策略先保证80%的流量由明确规则决定去向剩下20%交给动态评分来优化成本和效果。比如我负责的网关最先跑通的是规则路由如果请求意图等于法律咨询直接进入法律专家模型如果上下文长度超过一定阈值则切到长上下文模型。规则简单却稳定解决了很多问题。后续才逐步叠加评分因素比如同样的法律请求在高峰时如果专家模型压力过大就会在分数上适当降低专家模型的优先级把部分流量平滑到备用模型。2.3 路由和模型网关的现有功能如何协同现有网关通常已有负载均衡、重试、熔断、限流等功能。智能路由不是把这一套推倒重来而是叠加在它们之上。我的经验是路由只负责选择目标模型把请求发出去之后后续的重试、熔断、超时逻辑仍然复用原有链路。这样可以降低改动范围也方便逐步灰度。3. 路由决策核心模块的具体实现3.1 基础数据结构与预筛阶段路由模块启动前需要准备好一份“模型能力画像”也就是给每个后端模型打标签。比如某厂商的gpt-4o可以用tags标记为强推理、支持JSON、支持128K上下文某个开源7B模型则标记为轻量、中文流畅、不支持复杂工具调用企业内部微调的客服模型标记为领域专属、对内部术语理解准确。这组tags就是路由规则的匹配依据。预筛阶段的第一步是过滤不可用实例。常规做法是实例每5秒上报一次心跳和负载路由在决策前把错误率超过阈值比如5%的实例直接移出候选池。这里有一个我实际踩过的坑如果统一把阈值设死在重流量时段会出现频繁甩开故障实例的情况。后来我们是把错误率和响应时延合起来看短时间多次错误才移出单次超时保留重试机会这样能避免因为偶发抖动导致路由频繁切换。预筛之后是规则匹配阶段。每个业务方可以在网关配置一组规则比如intent law AND user_level vip model Aintent chat AND token_length 800 model Bdocument_type contract model C长文档专用规则按优先级排序命中的直接输出目标模型。这一步相当于把人工决策固化下来起到快速兜底的作用。3.2 动态评分的权重设计与归一化在规则没有命中的情况下会进入动态评分阶段。评分直接影响模型的排序结果具体实现过程如下候选池内每一个模型会从以下维度打分效果分来源于离线评测数据。例如在公开测试集和内部业务集上的综合得分取值范围0到1效果越好越接近1成本分把模型单价归一化到0到1区间价格越低越接近1响应速度分基于历史调用时延P50值越快得分越接近1稳定性分基于历史错误率错误率越低得分越接近1。总分的计算公式可以简化为score w1 * effect_score w2 * cost_score w3 * speed_score w4 * stability_score权重由平台管理员在配置中心设置。我建议的初始默认值大致是0.5、0.2、0.2、0.1后续根据业务目标调整。比如一个追求体验的VIP渠道可以把效果分权重调高到0.7一个预算敏感的渠道把成本分权重调到0.5。数据归一化时有一个细节容易忽略模型单价之间可能差十倍以上如果直接用原始价格做归一化会出现“最贵模型分数被压得极低”的问题。建议归一化时采用“相对最优”方式也就是以候选集内的最低价格作为参考点而不是以全局最低价做分母。3.3 多目标约束与优先级抢占网关场景里多目标约束几乎必然存在。最常见的是同时要求性能和成本这时评分跑完后还要加一个约束检查如果成本分排名前二的模型响应速度都低于某一条业务SLA线则强制把响应速度分权重临时上调保证不违反SLA。我还实现过一种优先级抢占机制当某个高优业务线请求到来时网关会临时检查低优业务线当前占用的模型容量如果容量紧张就把低优请求重新路由到备用模型让出主模型资源。这块逻辑要写在调度模块里路由模块本身不直接管理容量只输出目标模型建议由调度层真正执行“抢占”。4. 数据采集与效果闭环路由不能只选不评4.1 路由决策日志的结构决策日志是后续优化路由策略的基础建议保存以下字段request_id全链路追踪标识请求特征快照意图标签、消息长度、来源渠道候选模型列表及各自评分最终选中的模型命中规则ID或进入评分阶段决策耗时和上下文容量这些日志一方面用于线上排障另一方面可用作离线模拟的输入。比如策略调整后在测试环境跑离线回放比较新旧策略的模型选择差异和预计成本变化这比直接上生产灰度更安全。4.2 效果回流与迭代方式路由的效果不能只看“选了哪个模型”而要看用户最终反馈。比如对话产品中用户是否点踩、是否重新提问、是否转人工都是效果信号。把这些信号按模型维度回收到一个日级统计表中再结合离线评测分数动态修正模型的效果分。这样线上模型真的表现不好时效果分下降路由会自然把流量往更优模型迁移。当前效果分建议用平滑方式更新公式如下effect_score_new alpha * online_signal_score (1 - alpha) * effect_score_oldalpha取0.3左右即可避免单日波动造成路由抖动。这里有个值得注意的地方不要让路由系统每更新一次效果分就把全部策略重算一遍那样极易震荡。更稳妥的做法是固定每天凌晨更新一次历史分数线上路由运行期间仍使用缓存值。5. 工具选型与生态配合5.1 路由决策规则引擎的选型规则引擎不需要过于复杂。如果团队已有配置中心比如Apollo或Nacos直接在配置中心用JSON/YAML描述规则即可就能满足大部分需求。我早期用过一个开源规则引擎功能很强大但团队维护成本高反而拖慢迭代。后来改成配置中心下发JSON规则几周内就完成了线上切换。动态评分模块如果是纯Java/Go实现不建议引入很重的计算框架用本地缓存加载模型指标、评分函数写在业务代码里就够了。核心原因是路由路径上每一次额外RPC都会增加毫秒级延迟而在网关这种高并发场景毫秒级延迟都会被放大。5.2 模型状态感知与健康检查模型状态感知依赖两类信号主动健康检查网关定期发送心跳请求通常是一个极短文本的“ping”验证模型服务可用性被动采集通过在流量转发时记录的成功率、时延、超时次数结合历史基线做异常判断。主动健康检查建议周期设置为5到10秒一次太频繁会浪费模型服务资源太稀疏又感知不到瞬时故障。此外需要特别处理健康检查与真实流量之间的关系当真实流量本身很大时健康检查频率应该自动降低优先让真实请求通过。6. 线上灰度、故障转移与常见坑位6.1 灰度发布的具体路径智能路由上线最大的风险是“新策略误选了模型导致线上效果下滑”。我推荐按以下路径灰度离线回放使用最近一周的请求日志跑新老路由策略对比模型选择分布、预估成本、平均时延影子流量新路由逻辑只记录决策结果不实际改变转发目标对比影子结果和线上实际结果白名单灰度把某个内部测试渠道或某个低风险业务切到新路由观察日志和指标逐步放量从5%流量开始逐步增加灰度比例每档稳定24小时左右再继续。这里有一个必须掌握的注意点灰度期间要同时盯住业务方核心指标比如对话完成率、平均响应时延、成本消耗趋势不能只看路由系统自己的日志。即便路由决策变了但业务方核心指标没有劣化才能说明切换是安全的。6.2 故障转移与防止路由雪崩排名第一的候选模型故障时路由应立即故障转移到第二名此时要避免反复重试同一个故障模型。在实现上网关会维护一个本地故障标记表某个实例一旦连续失败N次则在未来30秒内不再作为候选。这样可以避免“路由认为可用但每次请求都超时”的恶性循环。还要特别注意路由环节的自我保护。如果模型状态数据源本身出现故障——比如状态服务响应超时——网关不应该阻塞请求去等待状态数据而应该走本地降级策略直接根据最近一次缓存状态进行路由甚至暂时按默认模型转发。我见过因为状态服务抖动导致整个AI网关请求超时的反面案例所以降级逻辑要提前设计好。6.3 我踩过的一个典型坑评分权重“过于智能”早期我们追求“全自动”把成本权重在高峰期自动调得很高结果低峰时也维持了高成本权重导致所有流量都涌向便宜模型业务方反馈效果下滑。后来改成“权重调节触发必须有明确信号冷却时间”的方案自动调节动作发生之后至少30分钟内不再二次调节并且每次调节前先跑一次离线模拟算出如果按新权重路由预计受影响流量占比低于阈值才允许执行。这个坑的本质是动态调节不能没有约束。要让系统具备自我纠偏的手段就得在每次决策前都校验“变更是否会突破业务红线”比如固定时段内切换模型的请求比例上限。7. 后续扩展多级路由与用户级偏好目前整套方案已经在内部多个业务线上稳定运行。后续我打算扩展两个方向多级路由统一入口先按渠道分到集群级策略再按请求特征做模型级路由两级策略分离便于不同团队独立维护用户级偏好路由允许用户在侧边栏主动选择“更聪明”或“更省钱的模型”网关结合用户级显式偏好和平台默认策略做融合决策。这两个方向的实现依然建立在现有的规则评分架构上只是把上下文里的用户偏好字段纳入评分输入。整个系统的演进逻辑是一脉相承的先打好规则底座再逐步增加动态因素。提示如果你的团队正准备做智能路由建议先从最简单的规则预筛开始跑通日志回放和灰度流程后再考虑引入动态评分一步到位往往适得其反。