DeepSeek API 调价后，如何用多模型路由控制成本

模型 API 调价之后，最直接的反应通常是“换模型”。但在真实业务里，替换模型名称只是最后一步。请求类型、上下文长度、输出上限、失败重试、缓存命中率和降级顺序，往往比单次标价更能决定最终账单。

如果所有请求都固定发送到同一个高能力模型，价格调整会被完整传导到业务成本；如果只追求最低单价，又可能因为回答质量不足、重试次数增加而产生更高的总成本。更稳妥的做法，是先建立可观测的成本基线，再用多模型路由逐步调整流量。

先计算一次请求的完整成本

一条请求的成本至少包含输入、输出和额外能力三部分：

request_cost
= input_tokens × input_unit_price
+ output_tokens × output_unit_price
+ cache_write_cost
+ cache_read_cost
+ tool_or_media_cost

这里不要直接把“上下文窗口”当成实际输入量，也不要把请求耗时当成 Token 数。真正需要记录的是本次请求实际计费的输入、输出、缓存和其他倍率。

为了避免价格表变化导致策略代码频繁修改，可以把价格与路由分开保存：

{
"models": {
"fast-model": {
"input_price": "from_config",
"output_price": "from_config"
},
"reasoning-model": {
"input_price": "from_config",
"output_price": "from_config"
}
}
}

路由器只读取统一后的价格配置，不把厂商名称和价格常量写死在业务代码中。调价时更新配置并重新评估策略即可。

不要按用户路由，要按任务路由

同一个用户可能同时发起摘要、代码审查、复杂推理和批处理任务。如果只按账号等级选择模型，会让大量简单请求占用高成本模型。

更实用的划分方式是按任务特征路由：

路由条件可以从显式参数、接口路径、上下文长度和业务标签中获得，不必让模型先判断“应该调用哪个模型”，否则路由本身也会产生额外成本与延迟。

一套可落地的路由顺序

可以把每类任务配置为“首选模型 + 备选模型 + 最大尝试次数”：

routes:
summary:
primary: fast–model
fallback: general–model
max_attempts: 2
coding:
primary: coding–model
fallback: general–model
max_attempts: 2
reasoning:
primary: reasoning–model
fallback: general–model
max_attempts: 1

这里最重要的不是模型名称，而是明确失败边界。以下情况不应该无条件切换模型：

• 401：通常是鉴权问题，换模型没有意义；
• 403：可能是令牌或分组没有权限；
• 400：请求格式错误，重试只会重复失败；
• 429：需要区分限流和余额问题；
• 5xx：可以有限重试或切换健康渠道。

只有可恢复错误才进入降级链，并且必须设置最大尝试次数。否则一次用户请求可能被复制成多次上游调用，表面成功率提高，实际成本却快速上升。

给输出长度设置业务上限

输出 Token 单价通常会显著影响总成本。很多客户端把 max_tokens 设置为一个很大的固定值，虽然它不代表一定会全部消耗，但缺少业务边界会增加长输出和异常请求的风险。

可以按任务设置不同上限：

短问答：较低上限
结构化摘要：固定字段与中等上限
代码生成：按文件或函数拆分
复杂报告：分阶段生成并逐段验收

对于长任务，先生成提纲，再按章节生成，通常比一次请求生成完整结果更容易控制质量和成本。

缓存不能只看命中率

提示词缓存适合系统提示、工具定义和长文档前缀相对稳定的场景。评估缓存时，应同时记录：

• 写入缓存产生的额外成本；
• 缓存读取的价格倍率；
• 有效期内的重复调用次数；
• 动态内容是否破坏了前缀复用；
• 缓存失败后是否回退为完整输入。

命中一次不一定省钱。只有复用次数达到盈亏平衡点，缓存才真正降低成本。

在网关层记录可解释的路由结果

在 FishAI 这类多模型 API 网关的日常运维中，最有价值的不是“本月总共花了多少”，而是能够解释每次请求为什么选择某个模型、是否发生降级，以及最终消耗来自哪里。

建议每条调用日志至少包含：

request_id
task_type
requested_model
routed_model
route_reason
input_tokens
output_tokens
cache_tokens
attempt_count
latency_ms
final_status
estimated_cost

这些字段可以回答三个关键问题：

调价后的实施顺序

不要在调价当天直接全量切换。更稳妥的步骤是：

验收时不要只看平均成本。至少同时观察 P95 延迟、首次成功率、人工返工率和每个成功任务的总成本。

总结

API 调价并不意味着必须立刻离开某个模型，也不意味着寻找最低单价就能解决问题。真正稳定的成本控制来自任务分类、价格配置解耦、有限降级、输出约束、缓存评估和可解释日志。

当每个请求都能回答“为什么选择这个模型、尝试了几次、消耗了多少”，调价就不再是一次被动迁移，而会变成一项可度量、可回滚的路由调整。

延伸阅读：同一 API 网关接入 Claude Code、Codex CLI 与 Gemini CLI 的配置差异。