大模型路由：从集合预测到成本感知的动态调度实战

1. 从单一答案到集合预测大模型路由问题的范式转变最近在折腾大模型应用落地的朋友估计都绕不开一个头疼的问题面对市面上眼花缭乱的模型从闭源的GPT-4、Claude到开源的Llama、Qwen到底该选哪个更具体点用户发来一个请求我该把这个请求“路由”给哪个模型来处理才能兼顾效果、成本和速度这可不是拍脑袋决定的。传统的做法往往是基于一些简单的规则比如“复杂问题用GPT-4简单问题用便宜模型”或者干脆用一个模型打天下。但实际跑起来你会发现规则总有失灵的时候成本也经常失控。这就引出了今天要聊的核心大模型路由LLM Routing。它本质上是一个决策问题——根据输入请求的特征动态选择最合适的模型或Agent来执行。而这篇论文标题《Multi-Agent Routing as Set-Valued Prediction: A WildChat Benchmark and Cost-Aware Evaluation》点出了一个非常关键但常被忽视的视角路由决策不应该是一个非此即彼的“点预测”而应该是一个“集合预测”。什么叫集合预测简单说对于一个用户问题理想的系统给出的不应是唯一的“最佳模型”而应该是一个候选模型的有序列表。比如对于某个翻译任务系统可能判断首选是模型A效果最好备选是模型B成本低80%且效果下降可接受再次是模型C速度最快。这背后的逻辑很务实所谓的“最佳”模型往往依赖于单一、脆弱的评估指标比如只追求最高准确率。但在真实业务中“最佳”是个多目标权衡的结果涉及效果、单次调用成本、响应延迟、吞吐量限制、甚至模型供应商的稳定性。只给一个答案系统就失去了灵活性和鲁棒性。把路由看作集合预测正是对这种复杂性的回应。它承认不确定性并为下游的调度系统保留了选择空间。例如当首选模型暂时过载或预算超支时系统可以自动降级到列表中的下一个模型而不是直接报错或牺牲用户体验。这个思路对于构建高可用、高性价比的大模型服务至关重要。接下来我们就基于这个核心视角拆解一下实现一个实用路由系统需要趟过的坑以及如何利用像WildChat这样的基准来科学评估。2. 路由系统的核心挑战在不确定性中做多目标决策构建一个生产级的多模型路由系统远不止写几个if-else规则那么简单。它本质上是一个在多重约束和不确定性下的实时决策问题。我们需要深入理解几个相互交织的核心挑战才能设计出合理的解决方案。2.1 模型异构性与能力画像模糊首先我们面对的是一群“性格”和能力各异的模型Agents。它们之间的差异是全方位的架构与规模有纯解码器的GPT风格有编码解码的T5风格参数从70亿到万亿不等。训练数据与领域有的在通用语料上训练有的在代码、数学或特定行业数据上精调。涌现能力复杂推理、指令跟随、上下文学习等能力在不同模型上的表现差异巨大。服务接口有的提供OpenAI兼容的API有的需要通过特定SDK或私有化部署调用。问题在于我们很难为每个模型建立一个精确、全面的“能力画像”。模型卡片提供的信息往往是宏观和片面的。一个模型可能在数学推理上很强但在创意写作上平平另一个模型可能长于中文理解但英文逻辑稍弱。这种能力的模糊性和任务相关性使得基于静态标签的路由规则极易失效。2.2 动态变化的环境与约束生产环境是动态的路由决策必须实时考虑以下约束成本这是最直接的商业约束。不同模型的API调用成本差异可达数个数量级如GPT-4与小型开源模型。成本又可分为按Token计费和按调用次数计费需要精确换算。性能延迟与吞吐量用户对延迟敏感尤其是对话场景。模型本身的生成速度、网络延迟、服务提供商的队列长度都会影响端到端响应时间。同时你的系统可能有总体吞吐量上限。预算与配额每日、每月的调用预算或针对特定模型的速率限制Rate Limit。服务可用性没有任何云服务能保证100%可用。模型服务可能临时降级、中断或返回非预期错误。这些约束并非孤立存在。例如为了降低成本而选择廉价模型可能导致响应变慢或效果下降进而影响用户体验而为了追求低延迟选择本地小模型又可能无法处理复杂任务。路由系统必须在每一秒都对这些动态约束进行权衡。2.3 评估的困境单一指标与真实场景脱节学术界和工业界早期评估路由策略常常陷入一个误区使用一个单一的、基于效果的指标如任务准确率、BLEU分数来评判好坏。这带来了两个问题忽略多目标性一个将95%的请求都路由给GPT-4的策略准确率可能最高但成本也高得无法承受。反之一个全部使用廉价模型的策略成本最低但效果太差用户无法接受。真正的“好”策略是在帕累托前沿上寻找最佳权衡点。离线评估与在线表现鸿沟基于静态测试集如MMLU、HellaSwag的评估无法反映真实流量的分布、用户的真实意图以及动态约束的影响。一个在基准测试上表现良好的路由器上线后可能因为无法处理长尾请求或对成本波动不敏感而失败。因此我们需要一种新的评估范式它必须是成本感知的Cost-Aware并且建立在能够反映真实世界复杂性和“野性”Wild的基准之上。这正是WildChat Benchmark试图解决的问题。3. WildChat Benchmark面向“野生”对话的评估战场论文中提到的WildChat Benchmark其名字中的“Wild”非常传神。它旨在弥补传统学术基准与真实应用场景之间的差距为路由算法提供一个更贴近现实的试金石。我们可以从以下几个维度来理解它的价值。3.1 什么是“野生”对话数据传统的对话基准如MT-Bench通常由专家精心设计问题质量高、意图清晰、领域相对集中。但真实的用户提问是混乱、多样且充满噪声的话题极其广泛从技术咨询、情感倾诉到脑筋急转弯、生成特定格式的文本无所不包。意图模糊与多轮交织用户可能不会在一开始就清晰表达所有需求对话目标会在多轮交互中演变和细化。语言风格多变包含口语化表达、拼写错误、网络用语、混合语言中英文夹杂等。包含“不可能任务”用户会提出模型能力范围之外的要求或包含错误前提的请求。WildChat Benchmark很可能采集或合成了大量此类“野生”用户对话数据构建了一个在分布上更接近真实线上流量的测试集。在这样的数据上测试路由算法其结果才更具说服力和预见性。3.2 基准如何支持“集合预测”评估一个支持集合预测评估的基准需要提供比“问题-标准答案”更丰富的元信息和评估框架。多维度标注对于测试集中的每个对话或请求除了可能的标准答案参考更重要的是拥有多维度的标注或可计算指标。例如任务类型标签分类、生成、推理、代码、创意写作等。难度等级简单、中等、复杂。领域标签科技、生活、金融、娱乐等。所需能力逻辑推理、知识检索、长文本理解、格式遵从等。模型能力矩阵基准需要预先对一批候选模型即路由池中的Agent在上述维度上进行全面的评估形成一个“模型-能力”矩阵。这个矩阵是路由器进行预测的知识基础。集合评估指标传统的评估只关心排名第一的预测是否正确。对于集合预测我们需要新的指标例如召回率K正确的模型或效果达标且成本可接受的模型出现在预测的前K个候选中的比例。K1时就是传统准确率。平均排序正确模型的平均排名位置排名越靠前越好。成本加权得分不仅看是否预测到还要看预测的排序是否优化了成本。例如将成本更低且效果达标的模型排在前面会获得更高得分。这样的基准允许我们评估路由算法1是否能识别请求的真实需求2是否能从集合中召回合适的模型3是否能对候选模型进行符合多目标优化如成本效益的排序。3.3. 成本感知评估的具体实现“成本感知”是论文标题的另一个重点。在WildChat这样的基准上评估必须将成本纳入核心考量。一个典型的成本感知评估流程可能如下定义成本模型为每个候选模型定义明确的成本。这可以是经济成本每千Token的美元/人民币费用。计算成本预估的GPU秒或浮点运算量对于私有化部署。延迟成本一个与响应时间相关的惩罚函数。混合成本以上各项的加权组合。定义效果阈值并非所有任务都需要追求极致效果。对于每个测试样本可以根据其类型定义一个最低可接受的效果阈值例如通过一个基线模型的得分来定义。模拟路由决策让被评估的路由算法对每个测试请求输出一个有序的模型候选列表。计算效用分数模拟一个简单的调度策略例如按列表顺序选择第一个效果达标且当前可用的模型然后计算处理该请求所消耗的成本和达到的效果。聚合与分析在整个测试集上我们可以绘制出路由策略的“成本-效果”曲线并与几个基线策略对比全部使用最贵模型效果上限成本上限。全部使用最便宜模型效果下限成本下限。随机路由。基于简单规则的路由。一个优秀的路由算法其成本-效果曲线应该最靠近坐标系的左上角即用更低的成本达到更好的效果。通过这种评估我们可以定量地回答“这个路由器每月能为公司节省多少预算”或者“在预算不变的情况下它能将平均用户体验提升多少”4. 构建集合预测路由器的实战路径理解了挑战和评估方法我们来探讨如何实际构建一个将路由视为集合预测的系统。这个过程可以分为离线准备和在线服务两个阶段。4.1 离线阶段模型画像构建与路由策略训练在系统上线前需要完成大量的基础工作。4.1.1 构建细粒度模型能力矩阵这是路由器的“知识库”。你需要对你路由池中的每一个模型进行全方位的“体检”。这个过程是昂贵但必要的。选择评估基准不仅仅用WildChat还应覆盖多个垂直领域基准如代码HumanEval、数学GSM8K、考试MMLU、指令跟随IFEval等以获得模型能力的多视角视图。自动化评估流水线搭建一个自动化的框架能够向各个模型API发送测试问题收集响应并调用相应的评估脚本打分。注意处理速率限制和错误重试。提取特征向量对于每个模型将其在各个基准、各类任务上的得分转化为一个多维的特征向量。例如[数学得分代码得分指令遵循得分常识得分中文理解得分平均响应时间每千Token成本...]。这个向量就是模型的“DNA”。4.1.2 请求特征化与意图识别路由器需要对输入的请求进行快速理解并将其映射到一个特征空间以便与模型特征进行匹配。轻量级特征提取基础特征请求文本长度、Token数、语言检测、是否包含代码块、数学公式等特殊格式。语义特征使用一个轻量且高效的文本嵌入模型如BGE-M3、bge-micro将请求编码为一个语义向量。这个向量能捕捉请求的核心主题和意图。基于关键词/规则的快速分类使用预定义的正则表达式或关键词列表快速识别出明显类型的请求如“翻译”、“总结”、“写代码”、“角色扮演”等。这可以作为语义向量的有效补充。意图分类模型可以训练一个轻量的文本分类模型如基于BERT-base微调将请求分到预先定义好的意图类别中如“创意生成”、“逻辑推理”、“信息提取”、“开放式聊天”。这个类别标签是一个强有力的路由信号。4.1.3 路由策略的学习与优化如何将请求特征与模型特征关联起来并输出一个有序列表这里有几个主流思路基于学习的排序模型将路由问题形式化为一个“学习排序”问题。训练数据来自历史交互日志请求被调用的模型最终的效果反馈和成本。模型如LambdaMART学习预测对于一个给定请求哪个模型会获得更高的“效用分数”一个综合效果和成本的指标。在推理时模型对所有候选模型进行打分并排序。多臂老虎机与上下文赌博机这是一个在线学习框架。每个模型被视为一个“老虎机臂”拉动臂选择模型会产生一个带有随机性的奖励效果并消耗成本。路由器需要平衡“探索”尝试不确定的模型和“利用”选择当前已知最好的模型。上下文信息请求特征可以帮助做出更智能的选择。这种方法特别适合模型能力动态变化或新模型加入的场景。基于规则的专家系统虽然不够智能但在初期简单有效。例如注意规则系统容易陷入维护地狱。当规则超过20条时其间的冲突和优先级处理就会变得非常复杂。它更适合作为初版原型或保底逻辑。4.2 在线阶段低延迟推理与动态调度离线训练好的路由器需要集成到高并发的在线服务中这对延迟和可靠性提出了苛刻要求。4.2.1 低延迟路由推理路由决策必须在毫秒级完成不能成为系统瓶颈。模型轻量化如果使用神经网络做路由必须使用高度优化的轻量模型如蒸馏后的小模型、使用ONNX Runtime或TensorRT加速。向量检索将请求的语义向量与预计算的模型特征向量进行近似最近邻搜索。可以引入成本、延迟等约束作为过滤或重排序条件。使用FAISS或HNSWlib等库可以实现毫秒级的检索。特征缓存对于高频、重复的请求模式例如常见的系统指令前缀可以缓存其路由决策或特征提取结果避免重复计算。4.2.2 动态调度与降级策略路由器输出的是一个有序列表[Model_A, Model_B, Model_C]而非最终决定。真正的调度器需要基于实时状态做出最终选择。健康检查与熔断调度器持续监控所有模型后端服务的健康状态延迟、错误率。当某个模型错误率飙升时立即将其从候选池中临时熔断避免将流量导向故障服务。负载均衡与限流即使一个模型健康也可能因为瞬时流量过高而排队。调度器需要感知各后端的当前负载优先选择空闲或负载低的后端。预算控制维护一个全局和/或用户级的预算计数器。当选择某个成本模型时检查预算是否充足。如果首选模型因预算不足不可用则自动降级到列表中的下一个选项。最终决策逻辑一个简单的调度器伪代码如下def schedule(request, model_candidate_list): for model in model_candidate_list: if not is_model_healthy(model): continue if not is_within_budget(model, request): continue if is_overloaded(model): continue # 或加入权重概率 # 所有检查通过选择该模型 return dispatch_to(model, request) # 如果列表中的所有模型都不可用执行降级策略 return dispatch_to(fallback_model, request) # 或返回一个友好的错误4.2.3 反馈闭环与持续迭代一个智能的路由系统必须是能够自我演进的。数据收集记录每一次路由决策的完整上下文请求特征、候选列表、最终选择的模型、模型的响应、用户端的反馈如点赞/点踩、实际消耗的成本和延迟。效果评估定期如每天分析日志计算关键指标整体成本、平均响应延迟、任务成功率、用户满意度等。并与“全部用贵模型”的基线进行对比计算节省的成本和效果折损。模型更新将收集到的新数据特别是那些路由失败或效果不佳的案例加入到训练集中定期重新训练或微调路由模型使其适应最新的流量分布和模型表现。5. 避坑指南从理论到实践的关键陷阱在实现上述架构的过程中我们会遇到许多纸上谈兵时想不到的坑。以下是一些从实战中总结出的经验教训。5.1 数据偏差与冷启动问题路由器的质量极度依赖于训练数据和模型能力矩阵的准确性。坑用于构建模型能力矩阵的基准测试集如MMLU, HellaSwag可能与你的真实业务流量分布严重不符。一个在通用基准上表现平平的模型可能在你的特定业务领域如法律文书分析上表现优异。如果矩阵不能反映这一点路由器就会“错杀忠良”。对策必须建立自己的业务评估集。从历史用户请求中采样一批有代表性的问题组织人工或通过强基线模型如GPT-4进行标注和评估生成针对你业务场景的“黄金测试集”。用这个集合来校准模型能力矩阵。冷启动当一个新的模型加入路由池时没有历史数据如何评估其能力盲目测试成本高。解决方案可以先在小流量如1%上做A/B测试快速收集其在你业务集上的表现数据。同时可以利用模型发布的官方基准成绩作为一个先验分布结合其模型家族、参数规模等信息做一个初步的能力预估。5.2 延迟与成本的动态性与测量误差成本和延迟不是恒定值测量它们本身也有开销和误差。延迟陷阱网络延迟波动很大。一次测量到的低延迟不代表下次也低。如果路由器过于依赖瞬时延迟做决策可能导致流量在几个后端间“振荡”引发连锁问题。对策使用平滑后的移动平均延迟如EWMA - 指数加权移动平均而非瞬时值。同时为每个后端设置一个“预热”权重新启动或恢复的后端初始权重较低随着成功请求的积累逐渐增加权重避免瞬间被流量打垮。成本计算误差API成本通常按输入输出Token总数计算。但在路由决策时你只有输入用户请求无法预知模型的输出长度。使用历史平均输出长度或基于请求长度的预测模型来估算成本必然存在误差。对策在成本优化目标中引入稳健性。不要追求理论上最低成本的极致点而是在成本预算附近设置一个“缓冲带”。例如允许路由器选择成本比最低方案高10%但效果更稳定的模型以应对估算误差。5.3 复杂请求与长对话上下文的路由失效用户的问题不是孤立的特别是在多轮对话中。坑一个简单的后续问题“上面这个结论的理由是什么”如果脱离了之前的对话历史是无法理解的。路由器如果只分析当前轮次的query很可能会将其误判为一个简单的定义查询从而路由到能力不足的模型。对策路由器必须能够访问和处理对话历史。一种有效的方法是将最近几轮的关键对话历史或经过摘要的历史与当前query拼接起来再进行特征提取。这增加了计算开销但对于维持对话一致性至关重要。另一种思路是由上游的对话状态管理器提供一个本次对话的“意图摘要”或“领域标签”作为路由的强特征。5.4 评估指标的片面性与“Goodhart定律”Goodhart定律说“当一项措施变成目标时它就不再是一项好措施。” 这在路由评估中尤为明显。坑如果你单纯优化“成本下降百分比”路由器可能会学会将大量简单但高价值的问题用户愿意为高质量答案付费也路由到廉价模型导致整体用户体验下降长期来看用户流失反而造成更大损失。对策评估指标必须是综合的、与业务目标对齐的。例如定义一个“业务效用函数”效用 α * 用户满意度分数 β * (1 - 标准化成本) - γ * 平均延迟惩罚。其中α, β, γ的权重需要业务方和技术方共同讨论确定反映公司当前阶段的战略重点是抢占市场优先还是盈利优先。线上A/B测试的最终指标应该是用户留存率、付费转化率等核心业务指标而不仅仅是技术指标。