你的 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 是 LMSYS 团队 2024 年 6 月开源的项目，截至现在 GitHub 上 5053 stars、395 forks，是目前最权威的开源 LLM 路由实现。它的官方 博客 和 论文 (arXiv: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 年两个代表性档位对比：

激进那档——只有 14% 的流量走 Opus——正好对应 RouteLLM 实测的"14% 调用、便宜 75%"那组数据，一年省下来约 5 万美元。这不是 PPT 数字，是把 LMSYS 论文里的实测比例直接套到 2026 年定价上的结果。质量呢？RouteLLM 保证 95% 旗舰性能，对绝大多数客服/问答场景，用户根本感知不到差别。

更骚的是，裁判本身几乎不花钱：mf router 是个本地跑的矩阵分解小模型，一次判断的成本是微秒级 CPU 计算，连一次额外 API 调用都不需要（关键词/向量派系甚至连模型都不用）。

四、三种落地姿势：从白嫖到托管，总有一款适合你

flowchart TD
    A[用户请求进来] --> B{路由层 裁判}
    B -->|"难度分 < 阈值<br/>简单请求 70%-86%"| C[便宜模型<br/>Haiku / Flash / GPT-mini]
    B -->|"难度分 ≥ 阈值<br/>难题 14%-30%"| D[旗舰模型<br/>Opus / GPT-5 / Pro]
    C --> E[返回结果]
    D --> E
    E --> F[账单结算<br/>旗舰用量降到 1/7 ~ 1/3]

    G[实现路径选择] --> H1[路径1: 开源自建<br/>RouteLLM / FrugalGPT]
    G --> H2[路径2: 网关层<br/>LiteLLM / Portkey / Helicone]
    G --> H3[路径3: 商业路由<br/>NotDiamond / OpenRouter auto]
    H1 -.免费最省.-> B
    H2 -.统一管理.-> B
    H3 -.零运维.-> B

路径 1：开源自建（RouteLLM）——最省、最可控

适合有 Python 后端、流量大、想榨干每一分钱的团队。pip install "routellm[serve,eval]"，起一个 OpenAI 兼容服务器，前端代码把 base_url 指过来就行。零路由费用，账单直接打到模型厂商。缺点：阈值要自己拿真实流量校准，初期需要折腾。配合 LiteLLM 还能统一管各家模型 API（RouteLLM 底层就是用它支持多厂商的）。

路径 2：网关层集成（Portkey / Helicone / LiteLLM）——团队级首选

如果你本来就要上一个 AI 网关（做日志、限流、重试、多模型 fallback），那直接用带路由能力的网关最划算。Portkey 和 Helicone 都内建了 conditional routing，能按 prompt 特征分流；LiteLLM 的 router 模块支持按"复杂度标签"或"fallback"做级联。好处是路由、可观测性、成本看板一站式搞定，坏处是网关本身可能抽水或要订阅。

路径 3：商业路由 API（NotDiamond / OpenRouter auto）——零运维

最懒、最快。NotDiamond 做的就是"你给我 prompt，我自动给你挑最便宜且够好的模型"，号称针对每个请求在几十个模型里选最优组合。OpenRouter 则有 :auto 这类自动路由模型和 Optimizer 模式，把"选模型"这件事外包出去。适合 MVP 阶段、不想碰基础设施、或者想 A/B 测试多个模型的场景。代价是路由判断本身可能要付一点钱、且把决策权交给了第三方。

我的建议优先级：流量大且稳定 → 路径 1（RouteLLM），省得最狠；团队多人协作、已有网关 → 路径 2；早期项目/想快速试 → 路径 3，等流量起来再迁回路径 1。

五、信息差总结：你知道的 vs 海外早玩明白的

六、行动指南：今天就能做的三件事

1. 先量，再切。拉你最近一个月的 API 日志，按 prompt 长度和任务类型粗分一下。如果发现超过 60% 是"短输入 + 分类/摘要/翻译"这类轻任务——恭喜，你就是路由的最大受益者，潜在降本 50% 起。

2. 灰度接入 RouteLLM。不用一上来全切。先在测试环境起一个 RouteLLM 服务，把 10% 流量影子路由过去（只记录会怎么分流，不真改结果），观察一周小模型被打分的分布。确认简单请求确实被判成"简单"后，再逐步把真实流量切过去。

3. 校准你的阈值。路由成败全看阈值。用 RouteLLM 的 calibrate_threshold 工具，喂入你自己的真实历史请求（而不是默认的 Chatbot Arena 数据），设定你想要的"旗舰调用比例"（比如 20%），让它给你专属阈值。用自己业务数据校准的阈值，比论文默认值能多省一截。

一个反直觉的提醒：路由省的是"钱"，但不省"延迟"——旗舰请求该多慢还是多慢，而且路由判断本身也有一丢丢开销。如果你的瓶颈是延迟不是成本（比如实时语音），路由的收益要打折看。但对 90% 的"成本焦虑型"应用，这条路值得今天就研究。

参考来源

• RouteLLM GitHub 仓库（lm-sys/RouteLLM） — 开源框架，5053 stars，含 4 种 router 实现
• RouteLLM 官方博客：An Open-Source Framework for Cost-Effective LLM Routing — 降本 85%/45%/35% 的原始数据
• RouteLLM 论文 (arXiv:2406.18665) — "Learning to Route LLMs with Preference Data"
• LiteLLM (BerriAI/litellm) — 多模型统一网关，RouteLLM 底层依赖
• NotDiamond / OpenRouter — 商业路由 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 等场景全覆盖。