将 LLM API 成本减半：2026 年生产工作负载的模型路由指南

账单里隐藏的成本问题

看看你生产代码里的 model 参数。对大多数已经从原型走到真实流量的团队来说，这个参数在上线时（通常设为当时能用到的最强模型）只设置过一次，之后就再也没动过。每个查询，无论复杂与否，都会发往同一个模型。而这正是静默成本超支藏身之处。

在任何非琐碎的生产工作负载中，查询的难度都不是均匀的。一个客服助手可能有 80% 的查询只是简单查找、分类或简短跟进，20% 才真正需要前沿级推理。一个编码助手可能处理稳定不断的小型重构，以及长尾的多文件架构变更。一个内容流水线可能每处理上百个摘要，就有一个需要结构化的创意写作。工作的形状是不均匀的，但到模型的路由却不是。

如果你今天每月在 GPT-5.5 上跑 100M tokens，而其中 70% 的查询用更便宜的模型也能同样回答得好，那么你大约每月为“用不到的能力”支付了 $600。更大体量下这一模式线性复利：每增加 1B tokens，未路由与已路由之间的差距每月就是数千美元。

路由是这种不对称性的工程解法。原则很简单：把每个查询发给足以胜任的最便宜模型，只有在需要时才升级到更强的模型。真正有意思的是实现里的权衡，而多数公开文章对这些权衡讲得并不好。本文覆盖了在生产里确实有效的三种模式、支撑这个论点的成本计算、会绊倒你的失败模式，以及如何在不重写应用的前提下，从单模型架构迁移到路由架构的行动手册。

本文使用的定价数据来自配套文章（2026 年 LLM API 价格比较），其中建立了全文引用的各模型费率。当本指南引用某个成本数字时，均以该数据为来源。

在生产环境有效的三种路由模式

路由 LLM 流量有三种成熟模式。它们在实现复杂度、延迟开销和可解锁的成本节省上各不相同。多数生产系统最终会组合使用三者；理解各自优势有助于你安排实施顺序。

模式 1：静态规则

最简单的模式。根据请求的可观测属性编写规则，把查询路由到不同模型：输入长度、用户等级、查询类型（如果你已有分类器）、API 端点或业务逻辑。短查询走便宜模型；长查询走更强模型。免费用户用更便宜的模型，付费用户用更强的模型。代码生成请求走代码微调模型；其他走通用模型。

静态路由可预测、易调试，几乎不增加延迟开销：路由决策是几行在本地运行的代码。上限同样较低：你只能基于模型运行前能观测到的属性路由，这意味着不能基于“查询实际有多难”来路由，因为你尚未知晓。对于输入属性与难度高度相关的工作负载（长文档通常更难；代码通常不同于散文；付费用户通常提更苛刻的查询），静态规则以极低工程投入即可拿下 30–50% 的可用节省。

模式 2：级联

适用面最广的模式。先把查询发给低价模型；如果响应达到质量阈值就直接返回；如果不达标，就升级到更强模型并使用其响应。成本节省来自：对于低价模型能搞定的查询，你只需支付低价模型的价钱。

级联模式的区分点在于：路由决策由模型的输出（而不仅是输入）来告知——先让低价模型尝试，再判断结果是否足够好。判断可以多种实现：来自模型本身的置信分数、结构化输出校验（响应是否能按预期模式解析）、自评提示（让一个小模型判断答案是否回答了问题），或者下游行为信号（用户是否接纳答案，还是改写后再问一次）。

级联是多数生产系统最终采用的模式，因为它能捕获静态规则无法捕获的节省。权衡在于：在被升级的查询上，你要为低价模型调用和旗舰模型调用各付一次费，所以节省取决于低价模型层的成功率。本文稍后将详细展开这一模式。

模式 3：基于分类器的路由

上限最高、工程投入也最多。一个小而快的模型（通常是次前沿模型的微调版本，或专用分类器）查看每个入站查询并预测应由哪个下游模型处理。分类器可以基于查询类型（“这是代码生成任务；路由到代码微调模型”）、难度估计（“这是困难推理；路由到 GPT-5.5”），或在历史流量与结果上训练的学得路由策略做决策。

基于分类器的路由可优于级联，因为路由决策发生在任何昂贵模型运行之前，因此不会在注定要用旗舰模型的查询上支付“低价模型税”。代价是构建、训练与维护分类器本身的工程工作，以及路由调用带来的小额延迟开销。对超大体量工作负载，这笔投入能回本；对小体量，通常不值当。

哪种模式先上：如果你的工作负载有明显的路由信号（输入长度、用户等级、端点），先用静态规则；如果没有，或当静态规则的红利吃尽后，用级联；只有在静态与级联都已到位且体量足以支撑工程投入时，才上基于分类器的方案。直接跳去做分类器是经典的过度工程陷阱，多数团队会后悔。

开始路由之前要衡量什么

不测不优。把任何路由逻辑引入生产系统前，先为当前的单模型工作负载打点，以便之后对比。打点不必复杂：记录每个请求的一小组字段就足够启动。

最小可用打点：

• 每个请求：使用的模型、输入 token 数、输出 token 数、成本（由 token 数与费率表计算）、端到端延迟、响应状态（成功/错误/部分），以及如果有的话，一个查询类型标签。
• 每个会话或用户：会话长度、重试次数（暗示用户未接受首答）、跟进率（暗示答案需要澄清）。
• 一份留出评测集：100–500 条具有代表性的查询，可在任意模型上复跑，并有你信任的参考输出。用它来衡量候选低价模型在你的工作负载上是否产出可接受的质量。没有它，所有路由决策都是瞎猜。

评测集是大多数团队投入不足的地方，却是任何路由项目杠杆最高的基础设施。像 Promptfoo 或 Helicone evals 这种轻量工具能快速搭建；对早期工作负载，一套手工挑选的 50 条、人工评分的样例就足够起步。

完成打点后，按现状跑至少一周建立基线。数据的形状（输入长度分布多偏、多少查询短且简单、多少看起来很难）会告诉你应该从哪种路由模式开始。

级联模式详解及成本计算

级联模式值得展开，因为它适用面最广，也是多数团队会率先或次先实现的模式。数学推演也让路由的价值更具体。

考虑一个今天跑在 Claude Sonnet 4.6 上的代表性生产工作负载：每月 100M tokens，80% 输入、20% 输出，按标价计算月账单 $475。假设在前面放一个级联：查询先打到 Claude Haiku 4.5，只有当 Haiku 的响应未通过质量检查时才升级到 Sonnet 4.6。Haiku 4.5 的标价是每百万 tokens 输入 $1.00、输出 $5.00，是 Sonnet 价格的三分之一。

成本计算取决于两个参数：在 Haiku 层成功的百分比（成功率），以及成功与升级两类查询的输入/输出比例差异。为简化，假设二者输入/输出比例相同，成功率为 70%，意味着 Haiku 在 70% 的查询上给出的响应足够好，30% 升级到 Sonnet。

这说明了什么。 即便在中等的 70% 成功率下（Haiku 10 次对 7 次足够好），级联也能把账单砍半。原因是：低价模型调用相对旗舰调用便宜得多，即使在 30% 的升级查询上为两次调用都付费，也远小于每次都走旗舰。收支平衡点（级联成本等于单模型成本）大约在 33% 成功率。低于此值，直连更划算；高于此值，级联占优。

最小可用级联实现

下面是该模式的最简版本，使用 OpenAI 兼容客户端的 Python 表达（适用于任何暴露 OpenAI 兼容端点的提供商，包括通过 Anthropic 兼容层的 Claude、Gemini，以及 CometAPI 的统一端点）。结构刻意从简；生产实现会加入可观测性、错误处理与更完善的质量检查。

from openai import OpenAI
import json

client = OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.cometapi.com/v1",  # 或者你选择的提供商
)

CHEAP_MODEL = "claude-haiku-4-5"
FLAGSHIP_MODEL = "claude-sonnet-4-6"


def cascade(messages, output_schema=None):
    """
    通过级联运行一次查询。
    返回 (response, model_used, escalated)。
    """

    # 第一步：尝试低价模型
    cheap_response = client.chat.completions.create(
        model=CHEAP_MODEL,
        messages=messages,
        response_format=output_schema,
    )

    cheap_text = cheap_response.choices[0].message.content

    # 第二步：判断低价模型的响应是否足够好
    if is_acceptable(cheap_text, output_schema):
        return cheap_text, CHEAP_MODEL, False

    # 第三步：升级到旗舰模型
    flagship_response = client.chat.completions.create(
        model=FLAGSHIP_MODEL,
        messages=messages,
        response_format=output_schema,
    )

    flagship_text = flagship_response.choices[0].message.content

    return flagship_text, FLAGSHIP_MODEL, True


def is_acceptable(response_text, output_schema=None):
    """
    质量门。
    如果低价模型的输出足够好，则返回 True。
    """

    if not response_text or len(response_text.strip()) < 10:
        return False

    if output_schema:
        # 结构化输出：必须能按 schema 解析
        try:
            parsed = json.loads(response_text)
            return validate_schema(parsed, output_schema)

        except (json.JSONDecodeError, ValueError):
            return False

    # 对于自由文本响应，请接入你自己的质量信号：
    # - 模型返回的置信分数
    # - 让小模型做自评打分的提示
    # - 基于规则的检查（长度、格式、拒答模式）

    return True

这只是起点，而非完工实现。面向生产你需要补上三件事：

• 一个“真”的质量门。上面的 is_acceptable 函数故意极简。实际上，质量门是级联中最关键的部分：门槛过松会放出低质量答案；过严又会频繁升级、丢失节省。多数生产级联会结合结构化输出校验、拒答检测（低价模型表示“我做不到”）以及小模型的自评打分。
• 每请求可观测性。记录使用了哪个模型、是否升级、各层延迟与成本。这样在级联跑一周后，你才能知道实际成功率是否如预期。
• 评估用的金丝雀通道。即便级联在低价层“通过”，也让一小部分流量（比如 5%）同时走旗舰。用留出的评分任务对比两者响应。这是抓住无声质量退化的方法；见下一节。

路由失效的地方

上面的成本节省数学是成立的，但也是乐观情况。有三种失败模式常常绊倒团队，直面它们的诚实程度决定了你的路由层究竟是持续创造价值，还是悄悄损害产品。

升级请求的延迟开销

当查询升级时，你要在旗舰调用开始前先付出一次低价模型的延迟。如果低价模型 800ms、旗舰 1.5s，那么升级查询端到端是 2.3s。对延迟敏感的工作负载，这很要命。缓解措施包括选择足够快的低价模型（Haiku 4.5 与 Gemini 3 Flash 就为此设计）、为低价调用设置激进超时，以及对最可能升级的查询考虑并行调用。有些团队接受延迟代价，因为省下的钱很大；也有团队用静态规则避免把显然很难的查询送入级联。

无声的质量退化

最隐蔽的失败模式。低价模型产出的响应虽通过了质量门，但比旗舰弱一些：略微不够准确、略微不够有用、略微更容易漏掉边界情况。用户不会立刻抱怨；你观测的指标（响应延迟、错误率、门通过率）都看起来正常；但下游指标（用户留存、转化率、客服升级）开始漂移。等你注意到，已经发了几周的劣化答案。

防线就是前述金丝雀通道：一部分流量并行走旗舰，与级联响应一起按评测标准打分。评分可由模型完成（LLM-as-judge），也可抽样人工复核。关键是维持一个独立于级联自身质量门的连续质量信号，让退化作为该信号的漂移被发现，而非作为下游的意外。

代码与可观测性的复杂度成本

路由图中的每个新增模型，都是一个需要评测、监控，并在提供商发布新版本时更新的对象。两层级联尚可把控；一个涵盖代码、RAG、聊天、代理与边角路径的五模型分类器路由，相比替换掉的单模型架构复杂得多。体量足够时，这份复杂度值得；体量不够，维护路由层所花的工程时间会超过它带来的节省。对你的体量门槛要保持诚实。

聚合器如何提供帮助（以及它们的局限）

LLM 聚合器（通过单一 OpenAI 兼容 API 暴露多模型的服务）与路由有两种不同的交集。两者都值得理解，因为“要不要在路由栈里用聚合器”的答案取决于你更在乎哪一种交集。

真正的帮助：消除集成成本负担

在直连各提供商 API 上构建级联或分类器路由，意味着管理多个 SDK、多个认证凭证、多个结算界面，以及多套提供商特性差异（超时行为、错误格式、限流语义）。对多模型路由而言，这些开销是真实的。像 CometAPI 这样的聚合器把所有模型都放在单一的 OpenAI 兼容端点后面，意味着路由上的代码变更只是改 model 参数，无需切换提供商、无需不同密钥、无需独立的可观测层。对于那些路由的主要障碍是集成成本而非质量评估成本的团队，这点至关重要。

需要警惕的点：内置路由层

有些聚合器提供“智能路由”或“模型优化器”，会基于查询替你选模型。原型阶段可能有用，但作为生产默认通常不合适。原因在于：路由决策是你栈里最与工作负载特定的一环——什么算“难到需要升级”，取决于你的评估标准、延迟预算、质量门槛与成本上限。一个通用的路由层不可能了解这些。多数生产系统更适合选择一个薄而透明的聚合器（暴露与直连相同的模型、统一凭证与账单），并在其上构建自有路由逻辑，而非依赖无法调校的黑盒路由层。

迁移作战手册

从单模型生产工作负载安全、逐步迁移到路由架构的路径。原则是每一步改动都可以单独回滚，并在做下一步之前衡量其影响。

• 为当前工作负载打点。记录每个请求的模型、输入/输出 tokens、成本、延迟和查询类型标签。至少运行一周建立基线。没有它，后续每一步都是瞎猜。
• 搭建评测集。整理 100–500 条你信任参考答案的代表性查询。这就是你在每一步将级联与单模型基线对比的留出集。
• 找出最高体量的查询类型。基于打点数据，找到流量占比最高的查询类别。先在这里试点级联。不必是最容易的类别，只要体量大，因为节省集中在这里。
• 为该类别做一个级联原型。两层：先低价，质量门不过再走旗舰。先在评测集上运行。把成本与质量同单模型基线对比。若质量达标且成本下降，继续；若质量下降，收紧质量门再试。
• 在生产按流量百分比灰度发布。对选定类别先放 5–10% 流量。至少跑一周。监控级联的升级率、每请求成本、各层延迟，以及金丝雀通道的质量对比。如果指标符合原型预期，扩到 25%、50%、再到 100%。
• 对下一个查询类型重复。第一个类别完全迁移并落地节省后，转向下一高体量类别。每个级联都是独立决策；不要假设一个类别有效的模式对另一个也有效。
• 建立持续的质量金丝雀。多个类别跑在级联后，永久设置留出金丝雀通道，用 5% 流量走旗舰做打分对比。这是你防止无声退化的早预警系统，也是让路由层在模型更新中保持可信的关键。

什么时候不值得做路由

诚实以告。有些工作负载，路由的工程投入不划算，及早识别能省时间：

• 单模型确实适用全量场景的工作负载。如果评测集显示低价层在整个工作负载上都有显著质量下滑，级联就无从施展。比如被推理能力卡住的代码生成负载：Haiku 会太频繁地撞上质量门，使级联无法省钱。
• 极低体量工作负载。大致在每月 LLM 花费 $200 以下，构建与维护路由层的工程时间通常超过省下的钱。阈值因负载而异，但确实存在。诚实评估你的体量是否足以支撑这项工作。
• 对合规“记录在案供应商”有要求的环境。如果你的合规要求所有生产流量都必须走某一特定供应商关系，多模型路由会让这件事变复杂。仍可能存在供应商内部的路由选项（Anthropic 内的 Sonnet → Opus；OpenAI 内的 GPT-5 nano → GPT-5.5），但跨供应商路由更难被接受。

诚实的表述：当你的工作负载体量大、查询难度不均匀、且你具备评估基础设施来判断级联质量是否可接受时，路由会回本。大多数有意义规模的生产负载符合这一描述；有些不符合，坚持单模型反而迭代更快。两种选择都可以成立。

接下来做什么： 如果你还没有过目本文所依赖的各模型费率卡，请先看配套文章，2026 年 LLM API 价格比较：GPT-5.5、Claude Sonnet 4.6、Gemini 3.5 Flash 和 DeepSeek V4。那里的定价数据能让本指南中的成本数学在你的具体负载上落地。