多模型智能路由：按需调度的成本杀手

可视化演示

展示Word2Vec词嵌入空间中的向量类比推理：king - man + woman = queen，词向量捕捉语义关系。

路由理念：后厨不能只靠一位大厨

阿忠是新来的领班，上任第一天就发现账本不对劲：老陈是大厨，月薪抵得上小周和阿豪加起来还多。前任领班图省事，所有订单不分青红皂白全递给老陈。结果呢？白灼菜心是老陈炒的，例汤也是老陈煲的——好吃是好吃，可厨房的人力成本高得吓人，出菜速度还被拖慢，客人们为了等一碗例汤抱怨连连。阿忠干的第一件事，就是立下规矩：订单必须先过他这一关，由他判断该进哪条“生产线”。

这个后厨，就是今天的 LLM 应用平台。老陈、小周、阿豪，分别对应旗舰大模型（GPT-4 级别）、中端模型和轻量小模型。它们之间的单价差距可以高达几十倍甚至上百倍：旗舰模型处理一千个 token 的费用，可能够轻量模型跑上几十次。而真实的线上流量里，真正需要旗舰模型“满汉全席级”推理能力的请求往往只占一小部分——闲聊、翻译、格式化、简单抽取这类“白灼菜心级”请求，能占到六成以上。

多模型路由（multi-model routing）要解决的，正是“把合适的请求交给合适的模型”这个调度问题。一个路由引擎通常包含三件事：难度评估器（判断订单是多难）、路由策略（决定分给谁）、控制目标（在成本、时延、质量之间权衡）。与单模型方案相比，路由能同时带来三个收益：成本下降（省掉不必要的旗舰调用）、时延改善（简单请求用轻量模型更快返回）、质量保障（困难请求不被打折处理）。它的典型适用场景，是同时对接多个 LLM 供应商、请求难度差异较大、且对成本敏感的应用平台。

阿忠在账本上画了条线：全交给老陈，一个月人力成本 X；看菜下碟之后，成本几乎砍半，客人却没有抱怨菜变难吃。这就是路由的第一个价值——它不改变菜的质量上限，只是不再让大厨去炒青菜，把每一分钱都花在刀刃上。

规则策略：领班的固定菜谱

阿忠先立了一本“菜谱”：带骨头的菜给阿豪（他刀工快），需要炖煮的给老陈（火候要稳），其余给中间的小周。这些规则是他多年跑堂的经验总结，写下来就是餐厅的《出菜分流手册》——对应到技术里，这就是“静态规则路由”。

静态规则是路由最简单的形态：根据请求的显性信号直接分流。常见信号有三类：第一类是关键词，出现“翻译”“总结”就倾向轻量模型，出现“推导”“证明”就倾向旗舰模型；第二类是长度，prompt 很短往往简单，超长往往复杂；第三类是任务类型，FAQ 问答走轻量、多轮对话走中端、代码评审走旗舰。这些规则实现快、可解释性强，最适合业务刚起步、流量模式简单的阶段。

但静态规则的“死板”很快会暴露：困难请求不一定包含关键词，长 prompt 也可能是把简单问题问得很啰嗦。于是有了动态阈值——把门槛参数从写死的常量变成可由配置中心随时调整的变量，运营同学可以根据白天晚上的流量特征、预算余量实时微调。再进一步是分级通道：不只有“轻量/中端/旗舰”三档，而是为每档模型设立独立的队列与超时时间，像餐厅里炒锅、蒸锅、烤箱各成一条线，互不挤占。

阿忠的菜谱不是刻在石碑上的，每周会跟着客人反馈改一版：这周凉菜卖得好，就把“凉菜→阿豪”的覆盖范围调大一点。规则策略的精髓不在于规则本身，而在于“规则可以低成本调整”——这正是它作为路由起点的价值。

难度评估：训练一位品菜师

日子久了，阿忠发现菜谱总有盲区。客人点“鱼香肉丝”，有的店是家常版，有的店讲究川味正宗——光看菜名判断难度根本不靠谱。于是他请来一位品菜师，这位老师傅不用尝，光看订单上的食材、做法、加急标记，就能报出一个“难度分”：这道菜给阿豪没问题，那道菜必须老陈上。

“品菜师”对应的技术，是一个超轻量的难度分类器。它要做的事不是真的回答请求，而是预测一个概率：这个请求如果交给旗舰模型以外的模型，能答好的把握有多大，即 P（需要旗舰模型）。注意，这个分类器不能是“又一个大模型”——否则还没省到钱，先多花了一次大模型调用的钱。它应该小到能在毫秒级完成一次推理，开销几乎可以忽略。

分类器的构建分三步。第一步是特征提取：从请求里抽取廉价信号，例如文本长度、是否含代码块、是否含数学符号、是否要求多步推理、是否含领域专业词汇。第二步是训练：用历史请求加上质量标注（人工评分、用户反馈或大模型蒸馏出的参考答案）作为标签，训练一个逻辑回归或小型树模型。第三步是置信度校准：当分类器输出贴近 0.5 的模糊概率时，说明它拿不准，此时策略上应当“回退”——宁可多花点钱走更高级的模型，也不要误判导致质量翻车。

品菜师也有拿不准的时候。阿忠给他定了一条规矩：拿不准的菜，一律按高难度处理，请老陈出马。宁可偶尔多花一次旗舰的钱，也不能让一道“佛跳墙”毁在学徒手上——这就是置信度校准在实际运维中的体现。

成本权衡：效果与支出的天平

阿忠心里有杆秤。省钱的方案谁都喜欢，但如果为了省钱让客人吃到糊掉的菜，回头客跑了，账算下来更亏。所以他给厨房定了一条铁律：任何分流方案，先保证“平均菜品质量不低于 80 分”，再谈省钱。这条铁律，就是路由优化的“质量约束”。

对应到技术，路由策略的调优是一个约束优化问题：改变阈值 $t_1$、$t_2$，分流比例就会变化，进而同时影响期望成本 $\mathbb{E}[C]$ 与期望质量 $\mathbb{E}[Q]$。如果只盯着成本，把阈值调得很松，简单请求固然全部去了轻量模型，但中难度请求也会被误伤，质量跌破红线——这就是“过度压榨”。

求解这个优化问题有几种做法。最朴素的是网格搜索：把 $t_1$、$t_2$ 在合理范围内离散化，逐一模拟并计算对应的（成本，质量）组合，找出满足约束且成本最小的点。更高效的是贝叶斯优化：把阈值组合看作搜索空间，用历史模拟结果拟合代理模型，用最少的试验逼近最优解。此外，优化时要特别注意“误分类代价不对称”：把困难请求判成简单（送去轻量模型）的代价，远高于把简单请求判成困难（送去旗舰模型）的代价——这一点要在目标函数里用系数体现，否则省下的是钱，丢掉的是口碑。

阿忠最后选定的方案并不是最省钱的方案，而是“踩在 80 分质量线上”的最优方案。天平的两端，一头是每月账单，一头是客人满意度。路由的价值，就是在两者之间自动找到那个让老板睡得着觉的点。

监控评估：领班的巡场检查

菜谱定好了，品菜师也上岗了，阿忠还是每天打烊后巡场：翻垃圾桶看剩菜多不多，翻客诉单看哪道菜被退得多。他清楚，厨房是活的——厨师会状态波动，食材会换供应商，菜单上的规则再好，也得靠数据来验证是不是真的在起作用。

路由上线后的监控，围绕三类指标展开。一是成本指标：成本节省率是最直观的 KPI，衡量路由相对“全旗舰方案”省了多少钱。二是流量指标：旗舰透传率（直接走旗舰的请求占比）、各档位调用量分布，能反映策略是否跑偏。三是质量指标：模型回答的错误率、用户反馈分、兜底重试率——质量塌方往往比成本超标更隐蔽、更致命。另外，时延的 P95 也要盯：简单请求被路由到轻量模型后理论上应该更快，如果 P95 反而上升，说明通道配置出了问题。

监控的进阶形态是漂移检测。线上请求的难度分布不是静止的：业务上新、季节波动、竞品变化都会让“简单/中等/困难”的比例悄悄移动。常见做法是用滑动窗口统计最近一段时间的难度分布，与新一批请求的分布做对比（如 KL 散度或分布间距离），当漂移超过阈值时触发告警。同时配合成本异常告警：某天成本突然翻倍，往往意味着某个阈值失效或上游流量结构突变，需要立刻介入。

巡场检查的意义不是“发现问题”，而是“尽早发现问题”。阿忠的账本上，成本节省率就是那面最显眼的仪表盘：它不出声的时候一切正常，一旦指针松动，阿忠当晚就会去找品菜师和菜谱的麻烦——监控把“事后补救”变成了“事前警觉”。

持续调优：菜单的四季更新

半年过去，餐厅的客流结构悄悄变了：外卖订单占比越来越大，外卖客人的菜偏简单、出餐要求快；堂食客人的要求则越来越高，爱点需要功夫的菜。阿忠的菜谱要是还停留在半年前，轻量作坊会忙不过来，大厨又会闲着——他必须让分流系统跟着季节和客流一起进化。

持续调优的第一步是反馈闭环：每一次路由决策、模型返回、用户反馈、兜底结果，都要被记录下来，形成结构化样本。这些样本既是监控的数据源，也是下一轮训练的燃料。第二步是策略迭代：定期（如每周）用新样本重训难度分类器、重新校准阈值，让“品菜师”的眼力跟上最新的请求口味。

迭代方式有两种节奏。离线重训适合稳定场景：攒一批新数据，训练新模型，离线回测看成本和质量指标是否改善，再灰度上线。在线更新适合漂移快的场景：用梯度下降等在线学习算法，让分类器权重随风向小步微调。最后，任何改动都要过 A/B 验证的关卡：新策略和旧策略各拿 5%~10% 的流量跑一段时间，用成本节省率与质量指标同时说话，显著占优才全量。这一套“反馈→重训→A/B→灰度”的循环，就是路由系统的自我进化。

阿忠后来把厨房的管理总结成一句话：没有一劳永逸的菜谱，只有不断演化的分流系统。多模型路由绝不是部署上线就结束的“一次买卖”，而是一个持续运转的成本优化引擎——这也正是它被称为“成本杀手”的真正底气。

AI 应用场景

Python 演示

import math  def sigmoid(z):    # sigmoid 函数，把任意实数压缩到 0~1 的概率区间    return 1.0 / (1.0 + math.exp(-z))  class DifficultyClassifier:    # 难度分类器：输入请求特征，输出"需要旗舰模型"的概率    def __init__(self, weights, bias):        self.weights = weights        self.bias = bias     def predict(self, features):        # 加权求和 + 偏置，再经过 sigmoid 得到概率        z = self.bias        for w, f in zip(self.weights, features):            z += w * f        return sigmoid(z)  class ModelRouter:    # 多模型路由器：按难度概率把请求分发给轻量/中端/旗舰模型    def __init__(self):        self.clf = DifficultyClassifier([0.4, 0.9, -0.3], -1.2)        self.low_th = 0.45        self.high_th = 0.75        self.prices = {"light": 0.01, "mid": 0.10, "flag": 1.00}        self.total_cost = 0.0        self.route_count = {"light": 0, "mid": 0, "flag": 0}     def extract_features(self, prompt):        # 提取三个廉价特征：长度、是否含代码、是否含数学推理        length = min(len(prompt) / 200.0, 1.0)        has_code = 1.0 if ("def " in prompt or "import " in prompt) else 0.0        has_math = 1.0 if any(k in prompt for k in ["derive", "prove", "=", "formula"]) else 0.0        return [length, has_code, has_math]     def route(self, prompt):        # 路由主流程：提特征 -> 算难度概率 -> 按阈值分流 -> 记账        features = self.extract_features(prompt)        hard_prob = self.clf.predict(features)        if hard_prob < self.low_th:            model = "light"        elif hard_prob < self.high_th:            model = "mid"        else:            model = "flag"        cost = self.prices[model]        self.total_cost += cost        self.route_count[model] += 1        return model, cost, hard_prob  def main():    router = ModelRouter()    samples = [        "hello, how is the weather today?",        "please calculate 37 times 89.",        "explain back propagation in neural networks.",        "derive the differential form of maxwell equations and prove the physical meaning.",        "write python code for binary search and prove its time complexity.",    ]    for prompt in samples:        model, cost, prob = router.route(prompt)        print("{} | prob={:.2f} | route->{} cost=${:.2f}".format(prompt[:20], prob, model, cost))    paid = router.total_cost    flag_total = len(samples) * router.prices["flag"]    saved = (1.0 - paid / flag_total) * 100.0    print("routed cost=${:.2f}, all-flag cost=${:.2f}, saved={:.1f}%".format(paid, flag_total, saved))    print("route count: {}".format(router.route_count))  if __name__ == "__main__":    main()

1. z = self.bias; for w, f in zip(self.weights, features): z += w * f把特征向量和权重加权求和，得到一个难度分数。
2. return sigmoid(z)用 sigmoid 把分数压成 0~1 的概率，表示“需要旗舰模型”的可能性。
3. if hard_prob < self.low_th: model = "light"概率低于下阈值时，判断为简单请求，交给最便宜的轻量模型。
4. elif hard_prob < self.high_th: model = "mid"概率落在中间区间时，交给中端模型，兼顾质量与成本。
5. else: model = "flag"概率高于上阈值时，说明请求很难，必须交给旗舰模型兜底。
6. self.total_cost += cost每次路由后累加实际成本，用于最终的节省率统计。
7. saved = (1.0 - paid / flag_total) * 100.0计算相对“全用旗舰”的成本节省率，这是路由系统最核心的 KPI。

常见误区

面试题