成本最优路由实践：让聚合层自动选最便宜的模型

2026-07-27

大模型调用成本的差异可以高达几十倍——GPT-4o 处理同样的任务，成本可能是 Llama 3.1 70B 的 20 倍。成本最优路由的核心思路是：不是所有任务都需要最贵的模型，让聚合层根据任务特征自动选择性价比最高的上游。

我见过一个真实案例：一个客服机器人日均调用 10 万次，早期全部走 GPT-4o，光 API 费用一个月就快 4000 美元。后来做了拆分——70% 的请求是”查订单状态""退货流程怎么走”这类简单意图识别和话术生成，切到 GPT-4o-mini 后单次成本从大约 0.01 美元降到 0.0005 美元左右，剩下 30% 需要理解上下文、判断投诉情绪的复杂对话才继续用 GPT-4o。账单直接砍掉了近七成，用户投诉率没有明显上升——因为简单问题本来就不需要旗舰模型的推理能力。这就是成本路由要解决的问题：不是一刀切降级，而是把”贵”用在刀刃上。

不同模型的成本差异有多大

以 2026 年上半年的大致价格水平（输入 token/百万）为参考：

模型	输入价格	输出价格	适用任务
GPT-4o	~$5	~$15	复杂推理、代码、多模态
Claude 3.5 Sonnet	~$3	~$15	写作、分析、长文本
Gemini 1.5 Pro	~$3.5	~$10.5	长上下文、文档理解
GPT-4o-mini	~$0.15	~$0.6	简单问答、分类
Claude 3 Haiku	~$0.25	~$1.25	快速响应、低复杂度
DeepSeek V3	~$0.27	~$1.1	中文任务、代码
Llama 3.1 70B (自托管)	按算力折算	—	批处理、合规场景

价格随时变动，以各服务商官方页面为准。以上仅作量级参考。

从表中可以看出，简单任务用 GPT-4o-mini 替代 GPT-4o，成本可降低 30–50 倍。

价格差这么大，背后不是厂商随便定的，主要是两个原因。一是模型架构：像 GPT-4o-mini、Claude Haiku 这类小模型参数量小，推理时占用的算力少，厂商摊到每 token 上的成本自然低；而 GPT-4o、Claude Sonnet 这类模型参数量大（部分还是 MoE 架构，推理时激活的专家网络更多），单 token 算力消耗更高。二是输出 token 通常比输入 token 贵 3–5 倍——这一点很多人算成本时会漏算。如果你的任务是”输入很短、输出很长”（比如让模型写一篇长文、生成大段代码），实际花费主要看输出价格那一列，而不是输入价格。尤其是带推理链（reasoning/CoT）的模型，模型内部会先生成一长串”思考过程”再给答案，这部分隐藏的 token 也是要计费的，估算成本时容易被低估，建议直接看服务商账单里的实际 completion_tokens 字段，而不是拍脑袋估。

成本路由的核心策略

策略一：任务分级路由

将业务任务按复杂度分级，不同级别路由到不同模型：

# LiteLLM 配置示例
model_list:
  # 轻量级：分类、摘要、简单问答
  - model_name: fast-cheap
    litellm_params:
      model: openai/gpt-4o-mini

  # 标准级：内容生成、代码补全
  - model_name: standard
    litellm_params:
      model: deepseek/deepseek-chat

  # 旗舰级：复杂推理、重要决策
  - model_name: premium
    litellm_params:
      model: openai/gpt-4o

应用层根据任务类型选择模型名：

def get_model_for_task(task_type: str) -> str:
    mapping = {
        "classify": "fast-cheap",
        "summarize": "fast-cheap",
        "write": "standard",
        "code": "standard",
        "reason": "premium",
        "audit": "premium"
    }
    return mapping.get(task_type, "standard")

这段代码简单粗暴，但真实项目里最容易踩的坑是分级标准怎么定。刚开始很多团队图省事，直接让上游业务代码传一个 task_type 字符串过来，结果没多久就发现同一个”write”标签下混进了简单的邮件回复和复杂的产品文案，质量参差不齐。更靠谱的做法是分两层：能用规则判断的（比如输入长度、是否命中固定模板、是否包含特定关键词）用规则分级，不确定的再丢给一个专门的小模型（比如 GPT-4o-mini）做一次”意图分类”，分类本身也是一次调用，但花费几乎可以忽略（几百 token，成本不到 0.001 美元），换来的路由准确率提升往往是值得的。这里有个取舍：

分级方式	优点	缺点	适用场景
纯规则（关键词/长度/接口来源）	零额外成本、延迟低	边界情况判断粗糙	任务边界清晰、量大的场景
模型分类 + 路由	判断更准确，能理解语义	多一次调用，增加几十到几百毫秒延迟	任务类型模糊、误判成本高的场景
人工预标注 + 缓存分类结果	准确率最高	无法覆盖长尾新问题	高频固定问题（FAQ 类）

我的经验是：先上纯规则跑一版，收集一段时间的日志，看误判率高不高，再决定要不要加模型分类这一层，不要一开始就上重的方案。

策略二：聚合层自动成本路由

LiteLLM 支持 cost-based-routing，自动在满足需求的模型中选最便宜的：

router_settings:
  routing_strategy: cost-based-routing
  # 自动排除不满足 context 长度要求的模型

OpenRouter 的 openrouter/auto 也实现了类似逻辑，不指定模型时自动选价格最优的上游。

这里”满足需求”具体是怎么判断的？LiteLLM 会先根据请求里的上下文长度、是否需要工具调用（function calling）、是否需要视觉理解这些能力标签，把不满足条件的模型筛掉，再在剩下的候选里按配置的价格表挑最便宜的一个。这就带来一个真实的坑：便宜模型被限流了怎么办。如果 fast-cheap 这一档模型触发了上游的速率限制，返回 429，聚合层如果没配 fallback，请求会直接失败。所以线上一定要配好降级链，别指望”自动选最便宜的”就万事大吉：

router_settings:
  routing_strategy: cost-based-routing
  fallbacks:
    - fast-cheap: ["standard", "premium"]  # 便宜档限流/报错时依次降级到贵档
  retry_policy:
    TimeoutErrorRetries: 2
    RateLimitErrorRetries: 3

也就是说，成本路由和容错路由要一起配置，不然为了省钱把可用性搭进去，得不偿失。

策略三：输入长度感知路由

长提示词的 token 成本显著更高，可以根据输入长度动态选择：

def select_model_by_length(messages: list) -> str:
    # 简单估算 token 数（约 1.5 字符/token）
    total_chars = sum(len(m["content"]) for m in messages)
    estimated_tokens = total_chars / 1.5

    if estimated_tokens < 1000:
        return "fast-cheap"
    elif estimated_tokens < 8000:
        return "standard"
    else:
        return "premium"   # 长文本用支持长上下文的模型

注意这里的 1.5 字符/token 只是一个粗糙的估算，实际偏差可能不小——中文平均下来大约 1.5–2 个汉字对应 1 个 token，但不同厂商的分词器（tokenizer）算法不一样，Qwen 和 GPT 系列的切分方式就有差异，同一段文本估出来的 token 数能差出 10%–20%。如果你的估算值比实际值偏低，路由到了一个上下文窗口不够的模型，真实报错通常长这样：

Error: This model's maximum context length is 8192 tokens. However, your messages resulted in 9350 tokens.

排查思路很简单：先确认是不是估算函数低估了 token 数，如果是长期稳定运行的服务，建议直接用对应厂商的官方分词库（比如 OpenAI 的 tiktoken）做精确计数，而不是拿字符数除以一个经验系数，尤其是对 token 阈值敏感的路由判断，几十个 token 的误差就可能导致误判到错误的档位。

策略四：Prompt Caching 降低重复成本

对于有大量重复 System Prompt 的场景（如 RAG 的固定上下文、客服机器人的知识库前缀），启用 Prompt Caching 可节省 50–90% 的输入 token 费用。Anthropic Claude 和 OpenAI 都支持这一特性，详见Prompt Caching 实践。

这里补充两个容易踩的坑。第一，两家的实现方式不一样：OpenAI 是自动缓存，只要请求的前缀重复且超过一定长度（官方文档给的门槛是 1024 token 起），系统自动命中缓存，你不需要额外配置；Anthropic 则需要你在 system 或 messages 里显式加 cache_control 断点标记要缓存到哪个位置，不加就没有缓存效果。第二，缓存要求的是前缀完全一致，哪怕你只是在 System Prompt 里改了一个标点符号、加了一个空格，都会导致缓存失效，费用立刻恢复原价——而这种失效是静默发生的，日志里不会报错，只会看到账单莫名其妙变高。所以如果你启用了 Prompt Caching，建议在监控里单独盯一下缓存命中率（大部分聚合层/服务商的用量接口会返回 cached_tokens 或类似字段），命中率突然掉下去，往往是有人动了 System Prompt 没注意。

成本监控与报警

成本路由配合监控才能真正落地：

按模型统计费用：在聚合层日志中记录每次调用的模型、token 数、费用
设置预算上限：LiteLLM 支持按 key 设置月度预算，超限自动拦截
定期审查模型分布：检查是否有任务被错误路由到昂贵模型

具体落地时，日志至少要留这几个字段，后面排查异常账单全靠它们：

字段	用途
`model`	实际命中的上游模型（不是请求时填的路由名）
`prompt_tokens` / `completion_tokens`	输入输出各自的 token 数，判断是不是输出侧超支
`cached_tokens`	命中缓存的 token 数，异常下降说明缓存失效
`latency_ms`	配合费用一起看，有些便宜模型延迟高，得权衡
`route_reason`	记录这次为什么选中这个模型（分级/长度/自动成本路由），出问题时能倒推

预算怎么定也有个简单公式可以参考：月度预算 ≈ 日均调用量 × 各档位任务占比 × 对应单次成本 × 30，再加 20%–30% 的浮动余量应对流量高峰。算出来的数字设成 LiteLLM 的 max_budget，接近阈值（比如到了 80%）就通过 webhook 推一条报警到企业微信或钉钉群，而不是等超限了才发现——超限拦截是最后一道防线，不该是唯一的防线。

常见问题

成本路由会影响响应质量吗？ 会有影响，这是成本与质量的权衡。关键是做好任务分级——只在你确认质量差异可接受的任务上使用便宜模型。建议用 A/B 测试验证降级模型的质量，详见多模型 A/B 测试怎么做。

批处理任务怎么降本？ 批处理任务对延迟不敏感，可以：使用支持 Batch API 的服务商（OpenAI Batch API 比实时 API 便宜 50%）、选择开源自托管模型（如 Llama 70B 按算力计费）、在低峰期处理以利用动态定价。

国内模型比境外模型便宜多少？ DeepSeek V3 的价格约为 GPT-4o 的 1/20，通义 Qwen-Plus 也有类似量级的差距。对于中文为主的业务，国内模型在成本上有极大优势，且质量在中文任务上并不逊色。