多模型路由与推理成本优化：一个网关调度 3 个 LLM 的生产级方案复盘
一、一个模型打天下的成本幻觉：70B 处理"今天天气怎么样"要花 0.3 元
部署单一 70B 模型来处理所有请求的策略，在成本细算后显得触目惊心。日均 50 万请求中，约 45% 是简单的查询和闲聊（3~5 轮对话、简单事实查询），用 7B 模型完全可以胜任。但现有架构将所有请求无差别路由到 70B 模型，单次推理成本约 0.03 元。简单估算：0.03 元 × 50 万 × 30 天 = 45 万元/月。而如果 45% 的请求能用 7B 模型处理（成本约 0.003 元/次），月成本可降至 25 万元，降幅 44%。
多模型路由（Model Router）的核心思想是：在请求到达推理引擎之前，先判断任务的复杂度，然后将复杂任务路由到大模型、简单任务路由到小模型。这是推理成本优化的"第一性原理"——不是让模型更便宜，而是把便宜模型能用好的任务从昂贵模型手中夺过来。
二、复杂度路由器的设计：用一个 BERT 撬动三倍的成本效率
路由器的核心挑战是"如何在极低成本下判断请求的复杂度"。方案选用了 DistilBERT-base（6600 万参数）作为复杂度评分器，在 2 万条标注数据（人工标注 0-10 分复杂度）上微调：
# 请求复杂度分类器 —— 67M 参数的 BERT 判断请求需要多大的模型 from transformers import DistilBertForSequenceClassification, DistilBertTokenizer class ComplexityRouter: """ 任务复杂度分级： 0-3 分: 简单查询、闲聊、翻译、摘要 → 路由到 7B 小模型 4-6 分: 一般推理、代码解释、基础分析 → 路由到 13B 模型 7-10 分: 复杂推理、多步逻辑、专业领域 → 路由到 70B 模型 """ def __init__(self): self.tokenizer = DistilBertTokenizer.from_pretrained( "distilbert-base-uncased" ) self.model = DistilBertForSequenceClassification.from_pretrained( "distilbert-base-uncased", num_labels=1 # 回归输出：0-10 分连续值 ) # 路由阈值（通过验证集调优的 F1 最优点） self.threshold_small = 4.0 # ≤4 分走小模型 self.threshold_large = 7.0 # ≥7 分走大模型 # 中间地带（4-7 分）走中模型 def route(self, prompt: str, history: list[str] = None) -> str: """返回目标模型名称：small/medium/large""" # 构造路由器输入：将对话历史与当前 prompt 拼接 # 历史对话的复杂度也影响判断（多轮复杂推理 vs 闲聊） full_context = " ".join((history or []) + [prompt])[-512:] # 截断 inputs = self.tokenizer( full_context, truncation=True, max_length=512, return_tensors="pt" ) with torch.no_grad(): score = self.model(**inputs).logits.item() # 复杂度分数 score = max(0.0, min(10.0, score)) # 钳制到 [0, 10] if score <= self.threshold_small: return "small" # 7B elif score >= self.threshold_large: return "large" # 70B else: return "medium" # 13B性能开销：DistilBERT 单次推理约 2ms，相对于大模型的推理延迟（200ms~2s）可忽略。模型显存占用约 260MB，可以在推理网关的同一张 GPU 上部署。
三、路由准确率与回退策略
路由器的核心指标是"不把复杂任务错分为简单"（召回率优先于精确率）。错误的将复杂任务路由到小模型会导致回答质量下降，用户满意度受损。
| 路由决策 | 实际简单 | 实际中等 | 实际复杂 |
|---|---|---|---|
| 路由到 7B | 82.3% ✅ | 8.5% ⚠️ | 0.6% ❌ |
| 路由到 13B | 12.4% ⚠️ | 78.2% ✅ | 8.2% ⚠️ |
| 路由到 70B | 5.3% ⚠️ | 13.3% ⚠️ | 91.2% ✅ |
关键数据是"实际复杂→路由到 7B"的 0.6%（极低）。在复杂需求被错误路由到小模型时，系统会启用"回退策略"：
# 自适应回退 —— 检测到回答质量不足时重新路由到更强模型 class AdaptiveFallback: def should_fallback(self, response: str, complexity_score: float) -> bool: """ 判断 7B 模型的回答是否需要回退到更强的模型。 检测几个信号： 1. 回答极度简短（<20 字符）且非确认性回复 2. 回答中包含了"不确定""无法回答""需要更多信息"等弱信号 3. 原始复杂度评分接近阈值边界（3.5-4.0） """ weak_signals = ["不确定", "无法回答", "需要更多", "抱歉", "对不起", "我不清楚", "not sure", "cannot"] is_borderline = 3.5 <= complexity_score <= 4.0 is_too_short = len(response) < 20 and response not in {"好的", "可以", "OK"} is_weak = any(signal in response.lower() for signal in weak_signals) # 任意两个信号同时出现，触发回退 return sum([is_borderline, is_too_short, is_weak]) >= 2四、整体成本与满意度对比
| 指标 | 单模型（全 70B） | 多模型路由 | 改善 |
|---|---|---|---|
| 月推理成本 | 45 万元 | 24.5 万元 | -45.6% |
| 平均响应延迟 | 1.8s | 0.9s | -50% |
| 用户满意度 | 91% | 90.2% | -0.8% |
| 请求路由耗时 | 0 | 2.1ms | — |
| 回退率（7B→70B） | — | 3.2% | — |
满意度仅下降 0.8%（从 91% 到 90.2%），这是成本降低 45.6% 的极小代价。回退率 3.2% 意味着每 1000 次路由中只有 32 次需要重新调用大模型，额外成本仅增加 2.5%。
五、总结
多模型路由的设计原则：
- 优先级是召回率 > 精确率：宁可将简单任务路由到大模型（多花点钱），也不能将复杂任务路由到小模型（伤及用户体验）。0.6% 的漏网率是可接受的安全边界；
- 路由模型本身的开销必须极低：67M 参数的 DistilBERT，2ms 推理，260MB 显存。如果路由器本身的成本接近一次大模型推理，就失去了经济学意义；
- 回退机制是安全网：3.2% 的回退率看似不高，但没有它的系统会在边缘场景下给出不可接受的回答。回退承担的是"兜底"角色；
- 成本优化的"甜点"在中间的 13B 模型：78.2% 的中等复杂度请求从 70B 降到 13B，在质量下降极小的情况下贡献了最大的成本节省。
适用边界：本方案适用于请求复杂度有明显分层的场景（客服、问答、内容生成）。对于重度推理为主导的场景（代码生成、数学证明），大多数请求本来就属于复杂类别，路由的收益会被稀释。
