做AI网关两年多我越来越觉得整个网关里最核心、也最容易被低估的模块就是智能模型路由。很多人把网关理解成“统一Key管理 请求转发”其实这顶多算个代理。真正让网关有价值的地方在于它能根据每一次请求的具体情况自动决定“这个请求该交给哪个模型”。这个决策做得好能直接省下一大笔模型调用成本还能把整体响应质量拉上去。这篇文章我就把自己在设计AI网关智能模型路由时的完整思路、决策依据、核心实现和生产环境踩过的坑一次性讲清楚。不管你是准备自研网关还是想给自己团队的多模型接入做个分流方案都值得看完。1. 先搞清楚智能模型路由到底在解决什么问题1.1 多模型时代网关缺的不是转发而是分流现在的企业接大模型早就不只接一家了。OpenAI的GPT系列、Anthropic的Claude、Google的Gemini国内还有通义、文心、智谱、MiniMax等等。应用层如果直接调各家SDK代码里全是厂商适配模型换一个就要改一遍。网关把接入统一掉这只是第一步。真正麻烦的是同一个业务系统里请求的性质天差地别。用户随口问一句“今天天气怎么样”和让模型“帮我分析这份财报里现金流异常的原因并生成结论”对模型能力的要求完全不是一个量级。前一个用最便宜的小模型就行后一个必须上推理能力强的旗舰模型。如果所有请求都打给最强的模型效果确实没问题但成本会很感人。如果你所有请求都打给最便宜的模型效果又撑不住。AI网关里的智能模型路由解决的就是这个“分流”问题在不牺牲质量的前提下让每一次请求都尽可能打到“够用且最便宜”的模型上。1.2 路由与负载均衡的本质区别这个点我经常跟人强调模型路由不是负载均衡。负载均衡是把同质的请求均匀分散到多个实例上目标是把压力摊开。模型路由则完全不同它面对的请求是异质的模型池里的模型能力有高低、成本有差异、擅长领域也各不相同。路由要考虑的是“匹配度”不是“平均分配”。你可以把模型池想象成一个团队的几个成员有资深的专家有性价比高的中级工程师还有实习生。负载均衡的逻辑是“每个人手上的活差不多”而模型路由的逻辑是“简单任务给实习生中等任务给中级工程师复杂任务才请专家出手”。两者思路彻底不一样混为一谈就会把路由策略设计歪。所以做智能模型路由之前要先有一个认知这是一套围绕“请求画像”和“模型能力画像”的匹配系统。后面的所有设计都是围绕这个匹配过程展开的。2. 路由决策机制不要把一个判断搞成玄学2.1 决策输入先给请求画个像要让路由做判断网关先得搞清楚“这个请求到底长什么样”。这项工作我习惯叫它“请求画像”。画像不需要多复杂关键特征抓准就行。实际操作中我会从四个维度给请求采集特征。第一个维度是任务类型。它是闲聊、翻译、代码生成、摘要总结、内容创作还是需要复杂推理的数学题这个可以用关键词匹配加一个极轻量的文本分类器来做。比如请求里出现“def”、“function”、“debug”大概率是代码类出现“翻译”、“translate”就是翻译类。第二个维度是复杂度。也就是这个问题是简单还是难。我会综合看输入长度、是否包含多步推理要求、是否要求输出结构化长文等因素。比如用户说“一步步思考”、“详细解释原理”、“给出论证过程”这些指令都会提高复杂度打分。第三个维度是上下文规模。多轮对话不能只看当前这一轮要把整个会话历史算进去。上下文越长模型要处理的负担越重对小模型的干扰也越大所以长上下文场景天然更适合用窗口更大、质量更稳的模型。第四个维度是约束条件。预算、延迟SLA、合规要求都算。比如某些请求要求响应时间必须低于1秒或者成本不能超过某个上限这些会作为硬性过滤条件参与决策。画像数据完全可以在网关层本地算完不需要调用外部模型也不需要额外引入一个重型的AI服务否则路由本身就会变成整个链路的瓶颈。2.2 三层次策略硬约束一票否决、打分择优、兜底保底拿到请求画像之后下一步就是决策。我强烈建议把路由策略拆成三个层次不要混在一起写否则后面维护绝对会疯。第一层是硬约束过滤。这一层必须做“一票否决”。比如某个客户签了合规协议数据只能走他指定的私有化模型那不管其他模型分数多高都不能选。再比如某个模型供应商当前可用率已经崩了正在熔断期那就直接把它从候选集里移出去。硬约束不做成否决项而是做成扣分项是我见过最典型的路由设计失误因为可用率跌到50%的时候分数再低也架不住其他维度给它补分最后流量照样打过去线上事故就是这么来的。第二层是软性评分。通过硬过滤的候选模型进入打分环节由计分模型根据成本、质量匹配度、延迟、稳定性这些维度逐项打分选出当前请求下最合适的模型。这一层解决的是“大家都在候选池里谁最优”的问题。第三层是兜底策略。当所有候选模型都不可用或者打分结果异常时必须有一个默认的fallback通道。通常我会配一个“绝对不出错”的保守选择比如成本最高但质量最稳的旗舰模型保证请求永远有去路。这三个层次的设计原则是硬约束负责拦截打分负责择优兜底负责保底。各管各的别越权。2.3 计分模型怎么定五个因子和权重打分是模型路由里最核心的算法部分。我的做法是加权评分这个方法可解释性强、调试方便上线之后出了问题也能很快定位是哪个因子在捣乱。完整的评分公式可以做得很复杂但实际工程里最常用的就是五个因子。质量匹配分用来判断模型能力和请求需求的匹配度。比如代码类任务在代码能力强的模型上得分就高中文场景下中文语料优化过的模型得分就高。这一项是决定“这个模型适不适合该任务”的核心因子权重我一般给到0.4左右。成本分衡量模型在预估token消耗下的费用是否合理。预算范围之内成本越低分越高。这一项的权重交给业务导向决定如果你们团队主要诉求是降本可以给到0.3如果只在乎质量成本权重就可以压得很低。延迟分是根据模型的历史平均首token延迟和总响应时间来估算的既要满足SLA又不过度牺牲质量。稳定性分用模型最近一小时的可用率、错误率、限流率来计算。需要注意的是和硬约束不同打分的稳定性分是给“还能用但有风险”的模型做惩罚用的如果可用率已经跌破阀值应该在第一层直接被拦掉不该进打分环节。最后一个因子是业务优先级分比如某些模型被标记为“内部战略主推”、“已签署最低消耗协议”当你需要优先完成某个供应商的月度消耗额度时这个因子就能派上用场。它的权重平时设成0只有在特定运营周期才拨高。权重这个东西没有标准答案但有一件事是确定的所有权重加起来必须是1这样可以保证最后得分落在可比较的区间内。我习惯再给每个模型加一个“最低录取线”低于这条线宁可走兜底模型也不硬上。3. 路由引擎怎么落地关键模块与核心代码3.1 网关路由链路的完整走向讲完策略设计说说在网关里到底怎么落地。一条请求从进入AI网关到转发出去我通常会让它走七个环节鉴权与配额检查、解析请求并维护会话上下文、构建请求画像、执行硬约束过滤、对候选模型打分排序、检查和触发熔断降级、输出决策日志并转发上游。这七个环节里前两个是网关的通用能力不用多说。真正体现路由设计的是后五步。我在实际实现的时候会把后面五步组装成一条独立的“路由链”不跟请求转发逻辑混在一起。这样做的优点是路由策略可以独立升级、独立灰度不会牵一发动全身。路由链的执行要保证无外部依赖或者说不能强依赖外部服务。否则路由模块本身一个请求超时整条转发链路就堵住了。这是网关这种高并发组件的铁律。3.2 复杂度与token估算路由的“眼睛”路由决策依赖一个关键前置条件——估算token消耗。没有它成本分和延迟分都无从谈起。这里有一个很实用的经验不要在路由阶段调用真正的tokenizer太慢了高并发扛不住。更好的做法是用启发式估算。以中文为例经验值是1个汉字大概0.6到0.8个token英文则是约4个字符折1个token。想要更精确一点可以在网关收到请求时用tiktoken或对应模型的tokenizer离线缓存一份词表做快速估算实测误差能控制在5%以内性能损耗只在毫秒级。复杂度的计算我用的是几个可解释的加分明细输入超过2000个token加2分要求结构化长文输出加1分命中“逐步推理”、“详细解释”等深度推理指令加2分任务类型是代码或数学额外加1分。总分封顶10分超过就按10分算。复杂度超过7的请求基本就不建议路由到轻量模型了。你可以先把这个逻辑做粗糙一点再靠线上日志慢慢调参。因为复杂度本身是一个辅助维度它不需要完美只要趋势正确就行。真正决定“这个请求难别用小模型”的阈值是在实际运营里调出来的。3.3 核心代码一个可运行的简化路由引擎我用Go写了一个简化版路由引擎的核心逻辑。这段代码不是生产级完整方案但骨架和思路可以直接参考。生产环境里需要加缓存、加分布式锁、加观察指标这些后面再说。package router type RouteRequest struct { TaskType string // chat / code / translate / reasoning Prompt string EstInputTok int EstOutputTok int MaxCostCents int64 TimeoutMs int64 ContextRounds int } type ModelCandidate struct { Name string Provider string CostPer1KIn float64 CostPer1KOut float64 AvgLatencyMs int64 Availability float64 MaxTokens int TaskTypes []string } type ScoreItem struct { Model string Score float64 Reason string } // EstimateComplexity 基于启发式规则估算请求复杂度0-10 func EstimateComplexity(req *RouteRequest) int { score : 0 if req.EstInputTok 2000 { score 2 } if req.EstOutputTok 1000 { score 1 } if req.TaskType reasoning || req.TaskType code { score 2 } if req.ContextRounds 5 { score } if score 10 { score 10 } return score }候选集过滤和打分部分我把它拆成两个函数。硬过滤用“一票否决”逻辑软评分用加权求和。这里要特别说明一下成本分我做了对数缩放因为模型之间的价格差异可能有几十倍直接按线性算会让低成本模型的分数过炸对高成本旗舰模型反而不公平。对数缩放之后价格差被压到合理区间打分更平稳。func FilterCandidates(all []ModelCandidate, req *RouteRequest, complexScore int) []ModelCandidate { out : make([]ModelCandidate, 0, len(all)) for _, c : range all { if c.Availability 0.9 { continue // 可用率跌破阈值直接淘汰 } if int64(c.AvgLatencyMs) req.TimeoutMs { continue // 延迟不满足SLA淘汰 } if !contains(c.TaskTypes, req.TaskType) { continue // 不支持该任务类型淘汰 } out append(out, c) } return out } func ScoreModel(c ModelCandidate, req *RouteRequest, complexScore int) float64 { // 质量匹配任务类型完全匹配给高分否则低分 quality : 0.3 if contains(c.TaskTypes, req.TaskType) { quality 1.0 } // 成本分预估总消耗后取对数缩放越便宜分越高 estCost : (float64(req.EstInputTok)/1000.0)*c.CostPer1KIn (float64(req.EstOutputTok)/1000.0)*c.CostPer1KOut if float64(req.MaxCostCents) 0 estCost float64(req.MaxCostCents) { return -1 // 超出预算直接不参与 } costScore : clamp(1.0-math.Log(1.0estCost)/5.0, 0, 1) // 延迟分满足SLA前提下越快越高 latencyScore : clamp(1.0-float64(c.AvgLatencyMs)/float64(req.TimeoutMs), 0, 1) // 稳定性分越接近1越好 stabilityScore : c.Availability return quality*0.4 costScore*0.25 latencyScore*0.2 stabilityScore*0.15 }打分结果排序后取最高分作为路由目标同时把得分明细和命中选择的原因记录到日志里。每条决策都要带一个route_id方便后续排障。这个习惯非常关键它让每一个未知问题都有了可追溯的起点。4. 从设计到落地生产环境必须处理的细节4.1 成本控制别让路由帮你烧钱设计文档里写“降本增效”很容易真正落地的时候成本控制是最容易翻车的环节。我经历过一次线上事故路由上线后成本没降反升查了半天发现是预估输出token的模型参数设得过于乐观实际输出量是预估值的三四倍导致成本分形同虚设。控制成本的核心不是把成本因子权重调高而是设置硬性的预算天花板。我给每个请求都会算一笔“MaxCostCents”一旦某个候选模型的预估成本超过这个值直接不参与打分。这样做的好处是成本控制从“软性引导”变成了“硬性拦截”就算打分模型再激进也不会突破预算边界。还有一个比较实用的经验就是给不同业务线配上不同的“成本系数”。比如内部工具类请求走低成本通道对外客户展示类请求走稳定质量通道。这种按业务线隔离预算的做法比在全局路由规则里调权重要好维护得多。4.2 灰度与版本管理新模型怎么安全放量新模型接入路由池不能直接开放全量流量。我的做法是分三步走。第一步线上双写观测。将新模型和现有模型在相同请求下各跑一遍对比输出质量和耗时时间周期根据请求量决定至少要积累一两天数据。第二步把新模型的初始权重设得很低比如让它只承接1%的流量并通过“探针流量”随机抽取请求打给它收集真实场景下的反馈。第三步根据数据逐步放量到5%再到20%每上一个台阶就观察一次成本、延迟、可用率、用户反馈四类指标。版本管理上每个模型在网关里要有唯一的版本号。模型升级不能原地覆盖要作为一个新的候选实体注册进路由池。比如claude-3-5-sonnet-20240620升级到claude-3-5-sonnet-v2两个版本并行存在路由可以先灰度新版把不稳的流量再切回旧版。很多公司没有这个意识直接在配置里替换模型名出了问题只能整体回滚整个链路都会跟着抖。4.3 可观测每个路由决策都要能解释智能路由这东西本质上是把“谁来做请求”的权力从人手里交给了算法。如果算法做了决策你却不知道它为什么这么做那生产环境出问题的时候只能干瞪眼。所以路由决策的可观测性一定要在设计阶段就埋好。我会在路由日志里记录以下字段请求画像的快照包括任务类型、复杂度、预估token数候选模型列表只要进入打分环节的模型都要记录每个候选模型的各项因子得分和加权总得分最终命中的模型和兜底原因如果走了fallback要标注具体触发了哪个条件最后是路由耗时这个指标必须单独监控路由本身延迟不能成为瓶颈。这些日志喂给监控系统之后至少每天要看一遍“路由决策分布”多少请求命中了大模型多少命中了小模型各模型分支的平均延迟和成本分别是多少。一旦发现某个模型长期接不到流量或者某个模型的上游错误率异常升高监控就会报警。做网关路由没有可观测性等于盲飞这句话我说过很多次了。5. 常见路由故障现场问题与排查实录5.1 新模型上线后一直没流量这个现象特别常见。新模型上线好几天了后台看流量分布它承接的请求数少得可怜。排查思路往往集中在“注册信息是否完整”和“打分是否被压制”这两个点上。前者容易查后者我一开始也没意识到。真正的坑在于新模型的稳定性分没有历史数据我当时的代码把未知数据的模型默认给了0的可用率它直接被硬过滤拦掉了连打分环节都没进。这个设计用意是保守可它把新模型彻底堵死了。解决方案是新模型需要有一个“观察期”。观察期内不去拦它给它一个介于安全和不安全之间的默认可用率比如0.95同时用探针流量引入它作为候选模型让它在打分环节里跟老模型同台竞技。等积累到足够的历史数据之后再切换到基于真实统计的可用率。这个调整做完新模型才有机会被路由选中并逐步放量。5.2 上下文token估算不准引发超限有一次线上表现是路由把一批长对话请求打到了小窗口模型上结果大量报错模型侧返回“上下文长度超限”用户侧表现为对话框里突然一片红。我的第一反应是路由过滤逻辑出问题了查了半天才发现是token估算函数在中文语境下偏差太大估算出的token数比模型实际要处理的少了一大截导致小窗口模型被误判成可用。修复方案有两层。第一层估算函数必须按模型家族的词表做校准。同一个文本在不同模型里的token计数差异比想象中大不能拿一个通用算法硬套所有模型。第二层给可用模型的窗口判断加一个保守系数。比如模型的窗口是8192那么只有估算token消耗低于7200时才认为它满足条件留下10%的buffer防止估算误差。后来我就把这个保守系数写成了每个模型的固有配置项而不是全局写死。这个坑给我的教训是路由里任何判断“模型能不能扛得住”的逻辑都要做误差兜底绝对不能拿估算结果直接跟模型上限硬碰硬。5.3 加了路由层后首token变慢这个反馈我收到过好几次症状是网关吞吐正常但用户感觉响应变慢了尤其是首token出现的时间被拉长。排查发现链路里多消耗了几十毫秒到一两百毫秒。位置其实不难找就藏在请求画像环节。我当时在画像里加了一个“意图分析”步骤调的是一个外部轻量模型等于在路由阶段又做了一次模型调用。这个设计本质上违背了我前面说的原则路由链路不能有强外部依赖。首token时间被拉长不说一旦那个外部模型超时整个请求就跟着超时。解决方法是把意图分析从路由链路里拿掉改成网关本地词典加规则实现的轻量分类器。精确度确实比模型分类差一些但足以支撑路由决策。路由本来也不需要100%精准的意图识别它的核心是把请求分到大致正确的方向越简单越好。这个改动之后路由本身的开销从100毫秒级降到了5毫秒以内整体延迟影响几乎可以忽略。最后再分享一个经验路由的稳定性因子权重一开始不能设得太低。我早期版本里可用率的权重只给了0.1结果某供应商连续故障了三小时路由还在选择它主要原因是质量分和成本分太占优可用率的扣分完全拉不回来。后来我把“可用率跌破0.85直接移出候选集”改成硬约束同时把稳定性在打分里的权重调到0.15以上这种故障就基本绝迹了。模型路由里那些“一票否决”的硬约束永远比加权打分可靠。打分负责择优硬约束负责兜底两者分工明确这个系统才能真正抗住生产环境的考验。