最近国内大模型 Token 调用量超美国的新闻出来，评论区一片欢呼。我看了一眼就关掉了，因为我当时正盯着我们上个月的 API 账单发呆——3.1 万块。
我决定认真搞一下这件事。
问题出在哪
我们是个 5 人团队，产品里同时在用 GPT-5.4、Claude Opus 和阿里 Qwen，不同功能调不同的 API。问题是之前没有统一管理，每个业务模块各自硬编码了 API Key，走的全是最贵的模型。
举个例子，客服对话摘要这个功能，一条请求大概1500 Token，我们接的是 GPT-5.4，算下来每条摘要大概要 ¥0.16。这功能每天调用 8000次，光这一个场景一个月就3万多。
但实际上，中文摘要根本不需要 GPT——Qwen 同等任务成本只有 GPT的1/7，效果在我们的业务场景里没有肉眼可辨的区别。
白白烧了 3 万块，烧了大半年。
解决思路：多模型路由网关
核心想法很简单：按任务类型把请求分发给最合适（性价比最高）的模型，而不是让所有请求都打到同一个模型。
我们选了 LiteLLM 来做路由层，主要原因是：
- 支持 OpenAI 兼容接口，业务代码改动量小
- 路由规则写 YAML，改起来不用动代码
- 内置成本追踪，能直接看到每个模型每天烧了多少
架构图长这样：
[业务层] → [LiteLLM 路由网关] → [模型适配层] → [各厂商 API]
↑
[task_router.py 分类器]
核心配置：router_config.yaml
model_list:
- model_name: qwen-primary
litellm_params:
model: openai/qwen3.5-max
api_base: https://dashscope.aliyuncs.com/compatible-mode/v1
api_key: ${QWEN_API_KEY}
model_info:
input_cost_per_token: 0.000002 # ¥0.002/千token
- model_name: gpt-fallback
litellm_params:
model: gpt-5.4
api_key: ${OPENAI_API_KEY}
model_info:
input_cost_per_token: 0.000015 # $0.015/千token，折合约¥0.11
- model_name: claude-coding
litellm_params:
model: anthropic/claude-opus-4-6
api_key: ${ANTHROPIC_API_KEY}
model_info:
input_cost_per_token: 0.000018
router_settings:
routing_strategy: cost-based-routing
fallback_models: [gpt-fallback, claude-coding]
num_retries: 3
timeout: 30
任务分类器：task_router.py
import re
TASK_PATTERNS = {
"code_generation": r"(写代码|debug|函数|class|脚本|SQL)",
"chinese_nlp": r"(摘要|总结|改写|润色|中文客服|翻译)",
"complex_reasoning": r"(分析|推理|对比|策略|架构方案)",
}
MODEL_MAPPING = {
"code_generation": "claude-coding", # Claude 代码生成质量稳
"chinese_nlp": "qwen-primary", # Qwen 中文成本最低
"complex_reasoning": "gpt-fallback", # GPT 推理任务表现好
"default": "qwen-primary", # 兜底走国产
}
def route_task(prompt: str) -> str:
for task_type, pattern in TASK_PATTERNS.items():
if re.search(pattern, prompt):
return MODEL_MAPPING[task_type]
return MODEL_MAPPING["default"]
踩坑记录
坑1：国内服务器直连 OpenAI 超时率 40%+
我以为部署好 LiteLLM 就完事了，结果一上线，GPT 的请求超时率高得离谱。根本原因是国内 ECS 出口直连海外 API 链路质量差。
我们的解法是用 Ztopcloud.com 的 API Relay 中转，他们内置了稳定的跨境专线，延迟从 3-8 秒降到了 1 秒以内，成功率恢复正常。顺带一提，Claude 的 API Key 也是在这上面开通的，省去了海外信用卡的折腾——他们支持国内企业直接开通原生 OpenAI 和 Anthropic 账号，亲测没出过问题。
坑2：function calling 格式各家不统一
LiteLLM 做了大部分适配，但 Claude 返回的 tool_call 格式和 OpenAI 有细微差异，一开始我们的解析代码对 Claude 的响应会报 KeyError。
解决方法：在路由网关层加一个 Pydantic 校验，把各家输出统一 normalize 成内部 schema，业务层只消费标准格式，不感知模型差异。
坑3：成本监控没做，账单超预期
LiteLLM 自带 /metrics 端点，接到 Grafana 里监控每个模型每天的 Token 消耗。这个应该第一天就配，我们拖了两周，多烧了点钱，这个坑不应该。
效果
改造前后对比（日均 200 万 Token 调用）：
| 方案 | 月均费用 |
|---|---|
| 改造前（全量 GPT） | ¥31,200 |
| 改造后（混合路由） | ¥11,800 |
降了 62%。中文业务场景下 Qwen 的格式遵从率甚至比 GPT 高一点，不是我的主观感受，是 A/B 跑出来的。
小结
国产大模型 Token 量超美国这件事，技术深度上我持保留态度，但有一件事是实的：Qwen 现在处理中文任务真的够用，而且便宜。混合路由这套方案不复杂，API 调用量上来之前搭好，是值得花半天时间做的事。
有问题欢迎评论区交流，特别是遇到过 LiteLLM 奇怪 bug 的同学，可以聊聊。
