按任务选小模型降本：轻量模型路由省 60–80% 成本
旗舰大模型能力强，但并非每个任务都需要旗舰。把合适的任务交给合适档次的模型，是系统性降低 API 成本最有效的架构决策之一——不改 prompt、不牺牲质量，综合成本可降 60–80%。
模型价格档次对比
各家厂商通常提供 2–3 个价格档次的模型，价差悬殊：
| 档次 | 典型代表（截至 2026-06） | 相对价格 | 适用任务 |
|---|---|---|---|
| 轻量/快速 | GPT-4o mini、Claude Haiku、Qwen-Turbo、DeepSeek-V3（部分） | 1× | 分类、路由、摘要、格式化、简单问答 |
| 标准对话 | GPT-4o、Claude Sonnet、Qwen-Plus | 5–15× | 通用对话、内容生成、代码辅助 |
| 旗舰/推理 | o3、Claude Opus、DeepSeek-R1 | 30–100× | 复杂推理、数学证明、深度分析 |
以上为定性对比，实际价格以各厂商官方定价页面为准，截至 2026-06。
关键洞察： 如果你的系统中 70% 的请求属于简单任务（分类、提取、格式转换），全部送给旗舰模型相当于用超跑送外卖。
哪些任务可以安全降档
下表帮你判断任务是否适合降档到轻量模型：
| 任务类型 | 可降档到轻量？ | 说明 |
|---|---|---|
| 意图分类 / 路由判断 | 是 | 输入输出简单，轻量模型准确率足够 |
| 关键词提取 / 实体识别 | 是 | 结构化输出，边界清晰 |
| 情感分析 | 是 | 二分类或多分类，轻量模型表现稳定 |
| 摘要生成（短文本） | 是 | 300 字以内摘要，质量差距不明显 |
| 代码补全（简单片段） | 通常是 | 复杂逻辑建议保留旗舰 |
| 多步推理 / 数学证明 | 否 | 需要旗舰或推理模型 |
| 创意写作 / 长文生成 | 视质量要求 | A/B 测试后决定 |
| 复杂代码调试 | 否 | 旗舰模型明显更好 |
模型路由的实现思路
最简单的路由方案是两级路由：
def route_task(user_input: str) -> str:
"""用轻量模型判断任务复杂度，返回应使用的模型名称"""
classification_prompt = f"""
判断以下用户请求的复杂度，只输出 "simple" 或 "complex"。
- simple：意图分类、信息提取、简单问答、格式转换
- complex：多步推理、代码调试、深度分析、创意写作
用户请求：{user_input}
"""
# 路由本身用最便宜的模型
result = call_llm("gpt-4o-mini", classification_prompt, max_tokens=10)
if result.strip() == "simple":
return "gpt-4o-mini" # 轻量模型处理
else:
return "gpt-4o" # 标准/旗舰模型处理
路由成本本身可以忽略不计：路由调用的输入短（分类 prompt + 用户请求）、输出极短（“simple”/“complex”），单次路由成本通常不足实际任务成本的 1%。
max_tokens=10 这个参数不是随便写的：分类结果只有 “simple”/“complex” 两个词，给再多 token 配额也用不上，反而会让某些模型在输出完结果后继续”多说两句”（比如加个解释），拖慢响应还浪费 token。这行代码背后的思路是——给模型的输出空间越小，它越没机会跑题，这是控制轻量模型行为稳定性的一个笨办法但很管用。
三级路由：把中间地带也管起来
两级路由（simple/complex）在实际跑起来后，你大概率会发现一批”不上不下”的任务：比如”帮我把这段话换个说法但保留专业术语”，用轻量模型效果时好时坏，用旗舰又觉得浪费。这时候可以加一档 medium，对应标准模型：
def route_task_v2(user_input: str) -> str:
"""三级路由：simple/medium/complex 分别对应轻量/标准/旗舰模型"""
classification_prompt = f"""
判断以下用户请求的复杂度，只输出 "simple"、"medium" 或 "complex"，不要输出任何解释。
- simple：意图分类、信息提取、简单问答、格式转换
- medium：内容改写、中等长度总结、通用问答、简单代码生成
- complex：多步推理、代码调试、深度分析、创意长文写作
用户请求：{user_input}
"""
result = call_llm("gpt-4o-mini", classification_prompt, max_tokens=10).strip()
model_map = {
"simple": "gpt-4o-mini",
"medium": "gpt-4o",
"complex": "o3",
}
return model_map.get(result, "gpt-4o") # 兜底：判断异常时走标准档，不直接砸向旗舰
注意最后一行的兜底逻辑：如果路由模型返回了预期之外的字符串（比如多打了个句号、或者输出了”simple。“这种带标点的变体），model_map.get 会退到 gpt-4o 而不是直接报错或默认扣向最贵的旗舰模型。这是个容易被忽略的细节——路由本身也会出错，兜底档位选贵了等于白路由，选便宜了又可能砸质量，标准档通常是最安全的兜底选择。
路由准确率怎么自测，别凭感觉上线
不要相信”我看了几个例子感觉分类挺准”这种判断，落地前至少做一轮离线评测：
- 从历史日志里随机抽 200 条真实请求（别用你自己编的测试用例，编的用例往往偏简单）
- 人工标注每条请求的真实复杂度（simple/medium/complex），作为标准答案
- 跑一遍路由函数，把模型判断结果和人工标注做对比，算出混淆矩阵
- 重点看两个指标：simple 类别的误判为 complex 率（这个高只是浪费钱，不影响质量，可以容忍）、complex 类别的误判为 simple 率（这个高会直接砸输出质量，是红线，必须压到 5% 以下才能上线）
你应该看到类似这样的结果才算合格：simple 召回率 ≥ 90%，complex 误判为 simple 的比例 ≤ 5%。如果 complex 误判率超过 10%，说明分类 prompt 的边界描述不够清晰，需要往 prompt 里补充更多带边界感的例子（few-shot），而不是简单调低阈值。
真实踩过的坑
坑一：轻量模型输出格式不稳定，下游 JSON 解析直接崩 用轻量模型做结构化提取时，偶尔会遇到这种报错：
json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)
根因通常不是模型”没提取到”，而是它在 JSON 前后加了解释性文字，比如”好的，以下是提取结果：{…}”，导致 json.loads 直接从第一个字符就解析失败。修法有两种：一是在 prompt 里加”只输出 JSON，不要任何前后缀说明”这种强约束（多数轻量模型能听懂，但不是 100% 可靠）；二是代码侧加一层正则兜底，用 re.search(r'\{.*\}', text, re.S) 先把大括号包裹的部分抠出来再解析，比纯靠 prompt 约束稳得多。
坑二：路由请求本身把配额打满 路由调用的请求量约等于你的总请求量（每次业务请求都要先过一遍路由），如果路由模型和业务里其他调用共用同一个 API Key，很容易先把这个 Key 的 RPM（每分钟请求数）配额吃满，报出：
Error code: 429 - Rate limit reached for gpt-4o-mini
这时候业务请求量没变，但因为路由这一步先挂了，整条链路全部失败。解决办法：给路由单独开一个 Key 或独立的限流额度，避免和主业务调用抢配额；如果调用量特别大，也可以考虑本地部署一个小分类模型（甚至规则/关键词匹配）做路由，完全不占用外部 API 配额，见下面的对比。
坑三：多轮对话里路由只看最后一句，判断跑偏 如果路由 prompt 只拼接了用户最新一句话，在多轮对话场景下容易误判——前几轮铺垫都很简单，但用户最后一句”那就按刚才说的方案改一下代码”看似简单，实际依赖前文上下文，真正执行起来是个复杂任务。修法是路由 prompt 里带上最近 1–2 轮的对话摘要，而不是只看孤立的最后一句。
LLM 路由 vs 规则/向量路由，怎么选
不是所有场景都值得用一次额外的 LLM 调用来做路由判断，下表是三种常见路由方式的取舍：
| 路由方式 | 额外延迟 | 额外成本 | 准确率 | 适用场景 |
|---|---|---|---|---|
| 关键词/规则匹配 | 几乎为 0 | 0 | 边界任务表现差 | 任务类型固定、可枚举关键词的场景（如客服工单分类） |
| Embedding 相似度分类 | 低（一次 embedding 调用） | 很低 | 中等，依赖样本质量 | 有历史标注数据、任务类型相对稳定 |
| 轻量 LLM 分类（本文方案） | 一次串行调用的延迟 | 极低 | 较高，能理解语义细节 | 任务描述灵活多变、规则难穷举 |
如果你的场景任务类型高度固定（比如只有”退款""查订单""投诉”三种），规则匹配的成本和延迟都更低，没必要多绕一次 LLM 调用；只有当任务表述五花八门、规则难以穷举时，LLM 路由的语义理解优势才值得为它多付一次调用的延迟和成本。
路由带来的延迟要不要紧
两级路由是串行的两次调用（先路由、再执行），会比直接调用旗舰模型多出一次网络往返的延迟，通常是 200ms–1s 级别，具体取决于路由模型的响应速度。如果你的产品对首字延迟极敏感（比如实时语音助手），可以考虑把路由判断和”默认走轻量模型直接开始生成”并行发起，一旦路由判断为 complex 再中断轻量模型的生成并切到旗舰重新生成——用一次多余的轻量调用换取大多数场景下的低延迟，只在少数复杂任务上多付一次轻量模型的成本，这个成本相对旗舰模型的价差可以忽略不计。
降本效果估算
假设系统每天 10,000 次调用，其中 70% 是简单任务：
| 优化前 | 优化后 |
|---|---|
| 全部走旗舰模型 | 7,000 次走轻量模型 + 3,000 次走旗舰 |
| 成本基准：10,000× | 约：7,000×0.07 + 3,000×1 = 490 + 3,000 = 3,490× |
| 相对成本：100% | 相对成本：约 35% |
实际节省幅度取决于简单任务的占比和两档模型的价差，但 50–70% 的降幅 在工程实践中非常常见。
落地注意事项
- 先做离线评测再上线：用历史请求样本分别跑轻量和旗舰模型，对比输出质量，确认轻量模型在你的场景下可接受
- 从最确定的任务开始：意图分类、情感分析等边界清晰的任务先切，风险最低
- 保留逃生通道：路由结果存日志，发现降档导致质量问题时可以快速切回旗舰
- 定期重新评测：模型在持续更新，每季度重跑评测，轻量模型能力可能已经赶上上一代旗舰
常见问题
路由判断错误怎么办？
路由错误有两个方向：把复杂任务分给轻量模型（质量下降）、把简单任务分给旗舰（成本浪费）。建议设置用户反馈机制，对低满意度的回答自动升级重跑，同时用这些样本持续优化路由 prompt。
推理模型什么时候值得用？
o3、R1 等推理模型的思考 token 同样计费，单次成本极高。仅对确实需要多步推理、数学证明、复杂规划的任务使用，绝不作为默认选项。
有没有开源的模型路由框架？
RouteLLM 是一个专门做模型路由的开源项目，提供了基于强弱模型打分的路由策略，可以作为起点参考。
延伸阅读：
- 计费原理总览：大模型 token 计费完全指南
- 全面优化清单：大模型 API 成本优化 10 招
- 批量任务省钱：Batch API 批量调用省钱指南
- 上线前成本估算：上线前怎么估算月成本
- Token 用量估算：Token 计算器
- token 成本专题：token 成本 Hub