大模型路由（LLM Routing）落地实战：用 1/10 成本保住 95% 质量的分级路由工作流

“不是每个请求都需要你最贵的那个模型。”这句话几乎是 2025 年之后做 LLM 应用成本优化的共识。大网关也都在推：OpenRouter 的 Auto Router、Factory 的 Router、NotDiamond、Martian，开源的 RouteLLM。卖点都很诱人——旗舰级质量、便宜大约 25%、全自动。但真相更有意思：论文里动辄 85%-98% 的省成本，是在特定基准上测出来的；换成混合的生产流量，诚实的数字大约是 20%-25%，而且有商业路由在混合流量下比“不路由”还差。本文不重复那些总览，直接给你一套五步落地工作流，每一步都配真实数据，让你自己能判断这条路到底值不值得走。

第一步：摸底——把你的流量按复杂度分级

路由能省多少钱，第一步取决于你真实的流量构成，而不是厂商的宣传。一家 B2B SaaS 客服 AI 在做优化前先做了流量分析：70% 是简单 FAQ、25% 中等、5% 复杂（bcloud 咨询的 2025 案例）。另一份工程复盘里，一家实时聊天机器人 78% 的请求都在 200 token 以内，是典型短查询（sivaro 的 2025 案例）。也就是说，即便你现在全量用 GPT-4 级模型，真正需要它的可能只有 5%-25%。

一个开源社区团队的混合架构更有代表性：他们用一个轻量分类器把请求分成三档——87% 走 Phi-3 Mini（每请求约 0.011 美元）、11% 走 GPT-3.5 Turbo、2% 走 GPT-4（HackerNoon 2025 案例）。成本从每月 8200 美元掉到 470 美元，客户满意度反而从 94% 升到 96%。这一步你不用写代码，先拉一周的调用日志，按意图/长度/历史正确率分个档，算出“如果简单请求全走小模型”的理论上限。算完你会发现，多数业务的省钱空间比想象中大。

第二步：建一个轻量分类器（约 20 毫秒，费用可忽略）

分级之后，需要一只能“看一眼请求就决定去哪”的轻量分类器。它可以是规则（按长度、关键词、是否含代码块），也可以是一个很小的模型（前面那支团队的分类器是个 tiny BERT，只看长度、关键词和句法结构，分类本身成本可忽略）。关键是它必须在生成之前就完成判断，而且耗时远小于一次大模型调用。一个最简的骨架长这样：

def route(prompt: str) -> str:
    # 轻量分类：在生成之前决定去哪，耗时约 20ms
    if len(prompt) < 120 and is_faq(prompt):
        return "gpt-4o-mini"          # 简单 FAQ：最便宜
    if needs_reasoning(prompt):
        return "claude-opus"          # 深度推理：最强
    return "gpt-4o"                   # 其余：默认中坚

别把这一步想复杂。分类器的目标不是 100% 正确，而是“大部分简单请求别去碰旗舰模型”。就算分类器有约 3% 的错误率，把复杂问题误判给小模型，小模型通常也能“凑合答个大概”，而省下的钱远大于偶尔答偏的代价。HackerNoon 那个案例里，分类器错了约 3%，依然把月成本砍了 94%。

第三步：设计分级路由表（小模型扛多数，旗舰留 hard 活）

把“哪个请求去哪个模型”固化成一张路由表，让它可配置、可灰度。这里有个常被忽略的实测：OpenSmartRoute 在 2026 年 9 月用 150 条真实请求做了盲测，路由后花费 0.0263 美元，始终用旗舰模型是 0.2457 美元——便宜 89.3%，而且盲评质量反而更高（9.53 vs 9.15，满分 10）；其中 122 条去了小模型、28 条去了中型模型。这说明“路由改变的是哪个模型来计费，而不是发多少 token”，只要分类准，小模型接得住大多数。

学术侧也有扎实数据：RouteLLM（LMSYS，arXiv 2406.18665）在 MT-Bench 上用弱模型（Mixtral-8x7B）做路由，只把 14%-26% 的请求发给 GPT-4，却保留了 GPT-4 约 95% 的质量，成本降幅超过 85%。但请注意——这是特定基准的数字。RouteLLM 在 MMLU 上只有约 45%、GSM8K 上约 35% 的降幅。省幅高度依赖你的查询构成，单一“平均省 X%”数字要打问号。

和语义缓存、Prompt Caching 一样，路由是“按请求特征选最便宜可胜任的载体”的思路延伸；去 OpenAI 平台页、Anthropic 平台页、DeepSeek 平台页对比各档模型单价，是填这张路由表的前提。

第四步：上质量护栏（别让“省成本”变成“掉质量”）

这是路由最容易翻车的一步。2026 年的 LLMRouterBench 用统一框架复测了 21 个数据集、33 个模型、约 40 万条样本，结论很清醒：不少近期路由（含商业的 OpenRouter）并没有超过一个简单基线——“始终选一个最佳固定模型”。OpenRouter 的路由相对 Best-Single 是负 24.7%，也就是比不路由还差；表现最好的路由器（Avengers-Pro）也就约 32% 的成本降幅，且只是“追平”最佳单模型，而非超越。所以“路由一定更省”是个错觉，关键是你得在自己的流量上压测。

质量护栏怎么做：在生产流量里按 1%-5% 抽样，用更强的模型或人工对路由结果重新打分，设一个质量地板（例如不低于旗舰模型 95%），一旦某类请求跌破就告警，并自动把该类回退到更强模型。再把护栏数据喂回分类器训练，形成闭环。NVIDIA 内部的员工支持 agent 就用这套“数据飞轮”：持续把生产日志和人工反馈做成训练集，把 70B 的大模型换成 1B-8B 的小模型，结果准确率 94%-96%、成本降 98%、延迟降 70 倍（ZenML 收录的 NVIDIA 案例）。护栏不是可选装饰，是路由能长期跑的前提。

第五步：灰度上线 + 监控 + 数据飞轮

最后一步是上生产，别一把梭。bcloud 那个 83% 降本的案例，分了六周：第 1-2 周分析查询构成，第 3-4 周上线分级路由 + 分类器，第 5 周加语义缓存，第 6 周 A/B 验证“质量无退化”后逐步放量。HackerNoon 团队更保守：先 10% 流量跑一周，再 50%，再 100%，每阶段盯着质量回归，提前抓出 3 个边界 case。

上线后必须盯三类指标：成本（按模型、按功能拆）、质量（CSAT、抽样重打分、解析成功率）、性能（p50/p95/p99 延迟、缓存命中率、路由错误率）。路由到小模型后，如果 CSAT 掉了哪怕 1 个点，都要能立刻定位是哪类请求。更多可监控的隐性成本，见隐藏计费陷阱；“路由 + 缓存 + 批处理”的完整省钱组合拳，见成本优化 2026。和 多厂商容灾 配合，路由还能在强模型不可用时自动降级到小模型保底——这是另一层韧性。

落地清单（今天就能开始）

1. 拉一周调用日志做流量分级。算清简单/中等/复杂占比，先得到“理论上限”。

2. 用规则或小模型写分类器。目标不是 100% 正确，是“多数简单请求别碰旗舰”。耗时控制在 20ms 量级。

3. 把路由表做成可配置。简单→mini 模型、中等→中坚、复杂/推理→旗舰；先全量走中坚，再逐步把简单请求切出去。

4. 必上质量护栏。抽样重打分 + 质量地板 + 自动回退。没有护栏的路由，迟早掉质量。

5. 灰度放量 + 盯三个指标。成本/质量/性能分模型看板，10%→50%→100% 逐步放。

6. 养数据飞轮。把护栏和生产日志喂回小模型微调，像 NVIDIA 那样把准确率推到 94%-96%，而非永远依赖旗舰。

三个最容易踩的坑

坑 1：被“省 85%”的宣传带偏。那是特定基准（MT-Bench 等）的数字；混合生产流量里诚实的省幅约 20%-25%，且部分商业路由在混合流量下比“不路由”还差（OpenRouter 负 24.7%）。一切以你自己的流量压测为准。

坑 2：分类器太重，把省下的钱吃回去。路由判断必须极轻（约 20ms、费用可忽略）。如果为了“更准”上了个大模型做分类，它本身就是一笔不小的开销，省幅会被抵消。OpenSmartRoute 的盲测里路由反而更快，正是因为分类够轻。

坑 3：没有质量护栏。路由到小模型后质量会悄悄掉，且不易察觉。必须抽样重打分 + 质量地板 + 自动回退，否则“降本”会变成“客诉”。

结语

大模型路由不是“接个自动路由就完事”的银弹，而是一套“摸底 → 分类 → 路由表 → 护栏 → 灰度飞轮”的工作流。它的真实价值在生产混合流量里大约 20%-25% 的省幅，叠加语义缓存、Prompt Caching 后能到更高；但前提是你自己压测过、有护栏、能监控。把“用最便宜可胜任的模型”当成默认策略，而不是把旗舰模型当万能钥匙——这才是把单位经济模型真正跑正的方式。各家模型单价与可用性随时在变，上 TokenNexus 首页查实时报价与路由建议。

推荐阅读