我在这轮AI Infra项目里已经数不清熬了多少个夜。团队手里十几个模型候选从大参数闭源模型到开源小模型都有每个季度还在换新版本。我们的客服智能体、内容审核管道、代码分析服务每个场景都在试图找出到底该用谁这个问题的答案。直到Martian AI Frontier推出模型可靠性榜单我们才第一次把跨模型路由这件事从拍脑袋变成看数据路由错误直接降了46%-54%。这篇文章不是通稿复述是我结合使用体验、路由架构调整和踩坑经历把这条链路从头到尾拆一遍。1. 先搞明白为什么需要模型可靠性榜单这种元数据1.1 路由决策缺的不是模型而是可靠的模型参照系过去一年我见过太多团队做模型选型的方式谁跑分高用谁谁便宜用谁谁家销售会讲故事用谁。单模型部署表面上省事实际上一旦请求类型复杂起来就是在拿平均值赌每一个请求。举个例子一套智能客服系统用户消息里有简单的查余额也有绕弯子的我上次那个订单好像少了个赠品你们客服又说让我自己看我看了也没有现在怎么办。如果你把所有请求都丢给一个偏推理的大模型成本高、延迟高如果丢给一个小模型复杂问题直接答非所问。模型路由model routing就是为了解决这个问题把不同复杂度的请求动态分配给最合适的模型。但路由本身会出错。路由错了意味着一个本该走小模型的简单请求被丢给了大模型浪费成本或者一个复杂请求被丢给了小模型输出质量崩盘。这就是标题里说的路由错误。以前我们靠规则关键词命中就分级长度超过多少就升级模型。但真实流量远没有这么听话。这时候就需要一个能反映模型在真实场景中有多可靠的参考标准这就是Martian AI Frontier那份可靠性榜单的价值。1.2 榜单不是排行榜是给路由系统做的体检报告常规的LLM排名榜单通常给一个综合分或者按几个基准测试排座次。Martian这份榜单最大的差别是它把每个模型的可靠性拆成了可操作的信号回答质量问题、格式遵循能力、指令理解稳定性、在特定领域上的表现波动、以及失败模式画像。注意失败模式画像这个词这是我目前看到的大多数公开榜单缺失的关键维度。传统评测只会告诉你这个模型的正确率是87.2%但不告诉你它在多轮对话中更容易忘记前文指令或者它在处理时间类推理时经常出现事实偏差。可模型路由最怕的就是这种隐藏的不确定性。可靠性榜单等于把这些性格缺陷摊开摆在路由决策面前让路由器知道每个模型擅长什么、什么时候会犯傻。直观一点说普通排行榜是成绩单看总分可靠性榜单是体检报告看各个器官在不同负荷下的表现。路由系统要的不是状元而是知道每个模型在什么科室能当主刀医生在什么科室只能当助手。1.3 跨模型路由错误降低46%-54%到底意味着什么我接手过一个真实案例某个内容生成平台原来的路由方式是文本超过800字走大模型否则走小模型。结果有相当比例的短查询其实语义非常复杂小模型直接答偏也有很多长文本只是模板化的合规申明大模型纯属浪费。接入可靠性数据驱动的路由后我们的路由错误率从12.8%降到了6.2%基本落在这个区间内。体感上最明显的变化是用户投诉里答非所问的比例肉眼可见地下降单次请求的平均推理成本还省了30%。这46%-54%不是某个实验室压测出来的理想值它在真实流量中同样出现前提是你愿意改掉过去的单模型一把梭思维。2. 可靠性榜单到底在测什么指标拆解与背后的逻辑2.1 六个维度的可靠性画像我根据这段时间的跟踪使用把这份榜单的评估框架归纳成六个维度。评估维度回答的问题对路由的直接影响指令遵循可靠性这个模型会不会经常不听话比如忽略格式要求、越权回答决定它能不能处理强约束场景上下文稳定性在多轮对话或长上下文中模型会不会失忆或偏移决定它能不能进入多轮客服/Agent管道领域泛化能力在垂直领域金融、法律、医疗、代码的表现会不会突然塌方决定细分场景的路由偏好输出格式一致性输出JSON/XML/纯文本的稳定度会不会偶尔渗出杂音决定它能否接入自动化管道失败模式分布模型在哪些类型的问题上系统性犯错决定要不要做问题分流/兜底延迟与成本波动在负载波动下响应时间与花费是否可控决定成本优化路由的边界条件看完这套维度你应该能理解为什么这份榜单对路由决策的价值不亚于模型本身。路由的本质就是在正确的时间把请求交给正确的模型而正确性高度依赖这些细粒度信号。2.2 数据来源与评测颗粒度Martian这套榜单的数据来源我观察下来主要有三块公开基准集的可靠性复测、与接入平台合作获得的匿名化真实流量反馈、以及周期性注入的对抗性测试样本。这三块数据各有分工公开基准保证横向可比性真实流量反馈保证生态内的实际表现对抗性测试则负责挖出那些平时没问题一上强度就露馅的潜在风险点。评测颗粒度也很有意思。它不是一个模型一行数据而是按任务类型、领域、难度梯度、语言种类做了切片。比如同一个模型在代码生成-低级算法题上可靠性96%在代码生成-系统设计类需求上只有61%。这种切片数据对于路由是金子我们完全可以配置规则让系统设计类需求优先路由到另一个模型。2.3 可靠性数据如何转成路由配置里的权重与阈值我比较关注的是这部分转化逻辑。拿到榜单数据后我们的路由网关会在每一条流量上做一次可靠性匹配度打分final_score Σ(维度得分 × 维度权重) × 场景适配系数其中场景适配系数由你的业务自己定——客服场景更看重上下文稳定性代码场景更看重领域泛化和格式一致性。这个打分模型不复杂但前提是底层的可靠性数据足够细、足够新。有些团队用Martian榜单的公开API直接拉取每个模型在不同任务类型下的可靠性评分再叠加自己的成本权重和延迟约束做成一个简单的加权评分路由策略。效果很明显。原来我们按长度和关键词匹配来路由的时候相当于隔着毛玻璃选人干活。现在有了这些切片数据路由器的每一次决策都有相对明确的依据。3. 路由错误的真实来源那46%-54%是从哪里省出来的3.1 四类典型路由错误很多团队上了路由之后错误率还是居高不下。我复盘下来路由错误基本逃不出下面四类。第一类意图识别错位。路由器错误判断了用户请求的复杂度或领域把本该走专业模型的问题分给了通用模型。比如用户问的是帮我写个小程序实现斐波那契路由器匹配到编程类但模型选的是通用对话模型代码质量差到没法看。第二类评测盲区。候选模型在官方评测集上分数相近但到了你的真实数据分布下表现天差地别。传统路由根本不知道这个差异因为它的决策依据里根本没有真实场景可靠性这项输入。第三类静态规则僵化。规则写死长文本走大模型但有些长文本只是聊天气、聊心情大模型纯属大材小用有些短文本却是精密的合同歧义分析小模型必然翻车。静态规则适应不了这种复杂的分布。第四类模型漂移。模型厂商更新版本、调整服务端参数同一个模型在两周之内可靠性曲线可能已经明显变化。如果路由配置还停留在旧认知上错误率自然会反弹。3.2 可靠性榜单如何逐类击破针对意图识别错位可靠性榜单提供的领域切片数据可以纠正路由器的偏见——例如某个模型虽然综合分高但在金融文本分析上可靠性偏低强制路由配置会避开它。针对评测盲区榜单里的真实流量反馈与对抗性测试补上了传统评测看不到的死角。某个模型在标准推理基准上分数很高但多轮对话中频繁遗忘指令如果榜单不把这个失败模式标出来路由就会把它优先派给长会话任务然后翻车。针对静态规则僵化榜单的动态更新让路由策略可以跟着模型的真实表现走。我们现在的做法是每天同步一次可靠性评分快照动态调整候选模型集合的优先级排序而不是像以前那样把配置写死在YAML里。针对模型漂移榜单的持续追踪本身就起到一个预警哨的作用。一旦某个模型的可靠性评分出现明显环比下滑我们的监控告警就会触发自动降低它的路由权重甚至安排人工复审。3.3 为什么降幅呈现的是46%-54%区间而不是固定值有人可能好奇为什么项目标题里给的是区间而不是一个确定的数字。我实际用下来发现降幅高度依赖三个变量。第一你原来的路由基线有多差。如果之前是单个模型处理全部流量那引入可靠性榜单后错误率下降空间巨大甚至可以超过54%如果之前已经做了基于规则的粗粒度路由那剩余的错误更多隐藏在细微的任务类型差异里能优化出来的空间就接近46%的下沿。第二候选模型的多样性。如果候选池里都是同一家模型厂商的不同版本彼此能力曲线相似路由的腾挪空间就小如果既有偏推理的、又有偏速度的、还有偏代码的路由的差异化调度价值才能体现出来。第三业务流量的复杂度分布。如果80%的请求都是简单且有标准答案的问题任何路由策略的错误率都不会太高优化空间自然被压缩。只有当流量本身复杂、长尾问题占比高路由错误率才有可观的下降余地。4. 把榜单吃透并落地从配置到灰度的一套可执行清单4.1 六步接入法很多人拿到榜单后不知道从哪下手我分享一下我们实际跑通的接入流程。第一步选出候选模型池。不用多三到五个有差异化优势的模型就够。太多模型会让路由决策复杂度成倍上升收益却不明显。第二步从可靠性榜单拉取候选模型在不同任务类型下的可靠性评分建立基准表。这一步建议用API自动拉取不要手工维护。第三步梳理你们自己的流量类型。把业务场景拆成任务类型 × 领域 × 预期复杂度的矩阵每一个矩阵单元就是一个潜在的路由分叉点。第四步给每个路由分叉点定义约束条件。是优先降本、优先质量、还是优先控制延迟这个约束条件会直接映射成路由打分时的权重组合。第五步做离线回放验证。拿最近一到两周的真实请求日志模拟新路由策略对比新旧策略下模型输出的质量分、成本和延迟。这一步最关键能提前筛掉一批不合理的路由权重。第六步灰度上线并持续校准。先切5%的真实流量观察一两天对比可靠性指标之后逐步放量。路由上线不是终点是一个持续校准的过程。4.2 一个具体配置示例智能客服场景拿我们客服智能体做例子。流量分为三档一般咨询查余额、改地址、问营业时间、复杂售前产品对比、套餐推荐、高难度售后订单纠纷、补偿谈判。一般咨询用小参数模型优先成本和延迟可靠性分数要求达到90%即可复杂售前路由到中等参数、对话能力强的模型重点考察上下文稳定性和指令遵循高难度售后直接进入大模型管道并且开启人工审核兜底同时参考榜单的失败模式数据屏蔽那些多轮对话容易前后矛盾的候选。采用Martian榜单的可靠性切片数据前我们大约有15%的高难度售后请求被小模型拦截用户满意度掉得厉害。调整之后这15%的请求被重新路由到合适模型投诉率降了40%以上。这就是套公式一样应用榜单数据的效果。4.3 灰度期盯紧哪几个指标灰度期间别只看路由错误率这一个数字孤立地看它容易骗人。我自己的建议是至少同时盯五类指标。端到端输出质量用业务自己的评测集给路由后的模型输出打分平均单次推理成本确保成本在下降或者至少不失控P95与P99延迟防止某些更好的模型带来无法接受的尾部延迟兜底触发率说明有多少请求因为路由拿不准而被降级到安全策略用户侧体验指标对话机器人的转人工率、NPS、满意度问卷分数。如果新路由让输出质量提升但延迟恶化或者成本上升但错误率下降不明显都要果断回滚或者调整权重。5. 做完这件事之后我的几点实操心法5.1 别迷信排名高要看切片可靠可靠性榜单给出的是立体数据不是一维排名。同一个模型在文本摘要上的可靠性和在数学推理上的可靠性可能存在巨大落差。做路由决策时一定按任务切片去匹配模型而不是简单选一个综合第一通吃所有流量。我见过有团队拿综合分最高的模型处理所有请求综合分在其他团队看起来还行但我们自己测试下来它在某些垂直场景下不如第二名稳定。老老实实按切片选效果比唯分数论好得多。5.2 路由必须带兜底和逃生通道再可靠的数据也挡不住线上突然出现模型接口故障或者回答质量悬崖式下跌。一定要给路由系统设计逃生通道最低可靠性阈值以下直接走人工连续两次请求的输出置信度过低触发模型切换某模型API连续报错时快速剥离候选池。Martian的榜单数据在这些场景里可以作为兜底路由的参考依据但它替代不了你自己设置熔断机制。5.3 数据要常看常新模型也会漂移模型厂商的版本迭代、服务端负载、Prompt策略微调都会让模型在真实场景中的可靠性发生变化。Martian这份榜单是动态更新的不代表你可以只在接入那天看一次。我们现在每周都拉一次可靠性评分快照跟基线对比一旦发现某个模型的关键维度得分波动超过5个百分点就触发路由权重复审。这个习惯救过我们好几次有一回我们就靠着这个机制提前发现某个模型在多轮对话场景下可靠性从91%掉到了82%及时把它从售后链路里摘掉避免了一波舆情。这波实践下来最大的体会是模型能力的天花板其实已经很高了绝大多数质量问题不是模型不够强而是我们把请求送错了门。可靠性榜单给了路由系统一双看清模型真实表现的眼睛剩下的还是那句话——知道每个模型能干什么、不能干什么比盲目追求最强模型有用得多。