## 你的 API 账单里，七成钱花在了"杀鸡用牛刀"上
先说一个很多中国开发者没意识到、但每天都在发生的事：你调用 Claude Opus 4.8 或 GPT-5 这种最贵的旗舰模型时，里面大概有 **70% 的请求，小模型本来就能答得一样好**。
"翻译这句话"、"把这段日志分类成三类"、"从这段话里提取一个手机号"、"判断用户是否在骂人"——这些活儿，Claude Haiku 4.5 或 Gemini Flash 闭着眼睛都能干。但你的代码里写死了 `model = opus`，于是每一次"你好"都按 Opus 的价格计费。旗舰模型的输出价是小模型的 **15 到 30 倍**，简单请求却占了真实流量的大头。
这就是本轮的信息差：海外从 2024 年起就有一整套成熟方案，叫做 **LLM 路由（Model Routing / Cascading）**——在请求到达模型之前，先花几乎为零的成本判断一下"这道题难不难"，简单的扔给便宜模型，难的才升级给旗舰。LMSYS（就是搞 Chatbot Arena 排行榜那帮人）开源的 **RouteLLM** 实测：**在保持 95% 旗舰性能的前提下，最高砍掉 85% 的账单**。而国内几乎没人系统讲这套东西，多数人还停留在"统一调一个模型"的原始阶段。
## 一、路由层是个什么东西：一个不答题、只判卷的"裁判"
理解路由，最关键的一点是：**裁判不需要会答题，只需要会判断这道题难不难。**
举个最朴素的例子。你家里有个装修队：贴瓷砖这种简单的活，派徒弟去就行；改承重墙这种要命的活，才需要总工亲自动手。但你怎么知道哪个是贴瓷砖、哪个是承重墙？你需要一个"包工头"在前面看一眼图纸，做一次分流。包工头不干活，他只做决策——决策的成本，远远低于"所有活都让总工干"的浪费。
LLM 路由就是这个包工头。它在你的应用和大模型之间插一层很薄的逻辑，对每个进来的 prompt 打一个分：
- 分数低于阈值 → 交给便宜模型（weak model）
- 分数高于阈值 → 交给旗舰模型（strong model）
这个"打分"有几种实现方式，从便宜到贵：
1. **规则/关键词路由**：几乎零成本。看到 prompt 里有"translate"/"翻译"就走小模型，看到"架构设计/step by step"就走大模型。粗暴但有时候够用。
2. **向量相似度路由**：用 embedding 把当前请求和你历史请求的库做比对，"长得像简单问题的"就分给小模型。RouteLLM 的 `sw_ranking` 就是这个思路。
3. **轻量分类器路由**：训练一个小小的 BERT 或矩阵分解模型（RouteLLM 的 `mf` router），输入 prompt 直接输出一个难度分。这是性价比最高的方案。
4. **置信度级联（Cascading）**：先让小模型直接答，让小模型自己判断"我答得有没有把握"，没把握再升级给大模型。Stanford 2023 年的 **FrugalGPT** 就是这个流派。
四种方式里，目前最被验证、最划算的是 **第 3 种——轻量分类器**。RouteLLM 官方推荐的就是 `mf`（matrix factorization）router。
## 二、RouteLLM：开源白嫖的路由器，5053 颗星的硬核数据
[RouteLLM](https://github.com/lm-sys/RouteLLM) 是 LMSYS 团队 2024 年 6 月开源的项目，截至现在 GitHub 上 **5053 stars、395 forks**，是目前最权威的开源 LLM 路由实现。它的官方 [博客](https://lmsys.org/blog/2024-07-01-routellm/) 和 [论文 (arXiv:2406.18665)](https://arxiv.org/abs/2406.18665) 给出了几个值得你截图保存的硬数字：
> 在保持 **95% 的 GPT-4 性能** 的前提下，相比只用 GPT-4，路由方案的账单：
> - MT Bench 上降本 **超过 85%**
> - MMLU 上降本 **45%**
> - GSM8K（数学题）上降本 **35%**
更细的数据点更扎心——同样是达到 95% 的 GPT-4 水平，路由后只需要 **26% 的 GPT-4 调用量**（便宜约 48%）；调到激进一点，甚至可以做到**只有 14% 的请求走旗舰模型，整体便宜 75%**。他们还顺手跟市面上的商业路由服务比了一下，结论是 RouteLLM 在同等表现下，**比商业产品还便宜 40% 以上**。
为什么数学题（GSM8K）只省 35% 而对话（MT Bench）能省 85%？因为数学题几乎道道都需要大模型硬刚，路由空间小；而真实业务里大量是"问你好、查信息、做分类"这种简单请求，路由空间巨大。**也就是说——你的业务越偏客服、RAG、分类、摘要，路由能省的钱越多。**
RouteLLM 最香的一点：它是 **OpenAI 客户端的 drop-in 替换**。你不用改业务代码，把 `OpenAI()` 换成 `Controller()`，把 `model="gpt-4"` 换成 `model="router-mf-0.11593"`，完事。阈值那个数字（0.11593）是它自带的校准工具 `calibrate_threshold` 跑出来的——你告诉它"我想让大约 50% 的请求走旗舰模型"，它就吐给你对应的阈值。
## 三、2026 年实操测算：把裁判接到你账单上，到底省多少
理论说够了，我们来算真账。假设你跑一个 AI 客服 / 文档问答类应用，月流量稳定在 **1 亿 input + 5000 万 output token**（中等规模，约等于一家成长期 SaaS 的用量）。我们用 2026 年两个代表性档位对比：
| 方案 | 模型分布 | input 费用 | output 费用 | 月账单 | 相比全旗舰 |
|--------|---------|-----------|------------|--------|-----------|
| 全旗舰（现状） | 100% Opus 4.8（$15/$75） | $1,500 | $3,750 | **$5,250** | 基准 |
| 全小模型 | 100% Haiku 4.5（$1/$5） | $100 | $250 | $350 | 降 93%（但质量崩） |
| **路由（激进）** | 14% Opus + 86% Haiku | $296 | $740 | **$1,036** | **降 80%** |
| 路由（保守） | 30% Opus + 70% Haiku | $520 | $1,300 | $1,820 | 降 65% |
激进那档——只有 14% 的流量走 Opus——正好对应 RouteLLM 实测的"14% 调用、便宜 75%"那组数据，**一年省下来约 5 万美元**。这不是 PPT 数字，是把 LMSYS 论文里的实测比例直接套到 2026 年定价上的结果。质量呢？RouteLLM 保证 95% 旗舰性能，对绝大多数客服/问答场景，用户根本感知不到差别。
更骚的是，裁判本身几乎不花钱：`mf` router 是个本地跑的矩阵分解小模型，一次判断的成本是微秒级 CPU 计算，连一次额外 API 调用都不需要（关键词/向量派系甚至连模型都不用）。
## 四、三种落地姿势：从白嫖到托管，总有一款适合你
```mermaid
flowchart TD
A[用户请求进来] --> B{路由层 裁判}
B -->|"难度分 < 阈值
简单请求 70%-86%"| C[便宜模型
Haiku / Flash / GPT-mini]
B -->|"难度分 ≥ 阈值
难题 14%-30%"| D[旗舰模型
Opus / GPT-5 / Pro]
C --> E[返回结果]
D --> E
E --> F[账单结算
旗舰用量降到 1/7 ~ 1/3]
G[实现路径选择] --> H1[路径1: 开源自建
RouteLLM / FrugalGPT]
G --> H2[路径2: 网关层
LiteLLM / Portkey / Helicone]
G --> H3[路径3: 商业路由
NotDiamond / OpenRouter auto]
H1 -.免费最省.-> B
H2 -.统一管理.-> B
H3 -.零运维.-> B
```
**路径 1：开源自建（RouteLLM）——最省、最可控**
适合有 Python 后端、流量大、想榨干每一分钱的团队。`pip install "routellm[serve,eval]"`，起一个 OpenAI 兼容服务器，前端代码把 base_url 指过来就行。零路由费用，账单直接打到模型厂商。缺点：阈值要自己拿真实流量校准，初期需要折腾。配合 [LiteLLM](https://github.com/BerriAI/litellm) 还能统一管各家模型 API（RouteLLM 底层就是用它支持多厂商的）。
**路径 2：网关层集成（Portkey / Helicone / LiteLLM）——团队级首选**
如果你本来就要上一个 AI 网关（做日志、限流、重试、多模型 fallback），那直接用带路由能力的网关最划算。[Portkey](https://portkey.ai/) 和 [Helicone](https://helicone.ai/) 都内建了 conditional routing，能按 prompt 特征分流；LiteLLM 的 router 模块支持按"复杂度标签"或"fallback"做级联。好处是路由、可观测性、成本看板一站式搞定，坏处是网关本身可能抽水或要订阅。
**路径 3：商业路由 API（NotDiamond / OpenRouter auto）——零运维**
最懒、最快。[NotDiamond](https://www.notdiamond.ai/) 做的就是"你给我 prompt，我自动给你挑最便宜且够好的模型"，号称针对每个请求在几十个模型里选最优组合。[OpenRouter](https://openrouter.ai/) 则有 `:auto` 这类自动路由模型和 Optimizer 模式，把"选模型"这件事外包出去。适合 MVP 阶段、不想碰基础设施、或者想 A/B 测试多个模型的场景。代价是路由判断本身可能要付一点钱、且把决策权交给了第三方。
我的建议优先级：**流量大且稳定 → 路径 1（RouteLLM）**，省得最狠；**团队多人协作、已有网关 → 路径 2**；**早期项目/想快速试 → 路径 3**，等流量起来再迁回路径 1。
## 五、信息差总结：你知道的 vs 海外早玩明白的
| 维度 | 多数人的认知（信息差低位） | 路由玩家的做法（信息差高位） |
|------|------------------------|--------------------------|
| 选模型 | 全程写死一个旗舰模型 | 按 prompt 难度动态分流 |
| 简单请求 | 用 Opus 接"你好"，花 15 倍的钱 | 70%-86% 流量走 Haiku/Flash |
| 质量权衡 | 怕小模型拉低整体质量 | RouteLLM 实测保持 95% 旗舰性能 |
| 省钱幅度 | 想到的是降级模型或缓存 | 同质量下降本 35%-85% |
| 路由成本 | 以为要多调一次大模型判断 | 本地小分类器，几乎零成本 |
| 工具生态 | 不知道有现成开源方案 | RouteLLM/LiteLLM/Portkey 一条龙 |
## 六、行动指南：今天就能做的三件事
1. **先量，再切**。拉你最近一个月的 API 日志，按 prompt 长度和任务类型粗分一下。如果发现超过 60% 是"短输入 + 分类/摘要/翻译"这类轻任务——恭喜，你就是路由的最大受益者，潜在降本 50% 起。
2. **灰度接入 RouteLLM**。不用一上来全切。先在测试环境起一个 RouteLLM 服务，把 10% 流量影子路由过去（只记录会怎么分流，不真改结果），观察一周小模型被打分的分布。确认简单请求确实被判成"简单"后，再逐步把真实流量切过去。
3. **校准你的阈值**。路由成败全看阈值。用 RouteLLM 的 `calibrate_threshold` 工具，喂入你自己的真实历史请求（而不是默认的 Chatbot Arena 数据），设定你想要的"旗舰调用比例"（比如 20%），让它给你专属阈值。**用自己业务数据校准的阈值，比论文默认值能多省一截。**
一个反直觉的提醒：路由省的是"钱"，但不省"延迟"——旗舰请求该多慢还是多慢，而且路由判断本身也有一丢丢开销。如果你的瓶颈是延迟不是成本（比如实时语音），路由的收益要打折看。但对 90% 的"成本焦虑型"应用，这条路值得今天就研究。
---
### 参考来源
- [RouteLLM GitHub 仓库（lm-sys/RouteLLM）](https://github.com/lm-sys/RouteLLM) — 开源框架，5053 stars，含 4 种 router 实现
- [RouteLLM 官方博客：An Open-Source Framework for Cost-Effective LLM Routing](https://lmsys.org/blog/2024-07-01-routellm/) — 降本 85%/45%/35% 的原始数据
- [RouteLLM 论文 (arXiv:2406.18665)](https://arxiv.org/abs/2406.18665) — "Learning to Route LLMs with Preference Data"
- [LiteLLM (BerriAI/litellm)](https://github.com/BerriAI/litellm) — 多模型统一网关，RouteLLM 底层依赖
- [NotDiamond](https://www.notdiamond.ai/) / [OpenRouter](https://openrouter.ai/) — 商业路由 API 与 auto 路由方案
---
> 本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵**爱卫生**（微信ID: gprshome201101）维护。
> 聚焦5G/6G核心网、3GPP标准、AI工具实战。知识星球「51学通信」提供深度技术答疑和行业洞察。
> [!tip] 51学通信知识星球
> **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。
> **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。
> **当前规模**：5200 篇主题 / 990 个回答，198 元/年。
> **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。
> **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。
