多模型API成本监控，按token计费只是开始

上周四下午三点，财务小姐姐在钉钉上给我发了张截图——8万块的API账单，后面跟了把菜刀的表情。

我后背瞬间湿了。

查了一圈发现，有个批处理任务的循环里藏了个bug，导致Claude 3 Opus跑了整整一晚上。那个任务本来是做文本摘要的，用GPT-4o mini就够，几百块能搞定的事，硬生生烧了800倍的钱。

这事让我消沉了两天。我们团队做AI辅助写作平台快一年了，接了6个模型——GPT-4o、GPT-4o mini、Claude 3.5 Sonnet、Claude 3 Haiku、DeepSeek-V3、通义千问-Max。一开始觉得模型越多越好，结果根本管不过来。不同任务对模型的要求完全不一样，摘要生成便宜的就行，深度分析必须上好模型，多语言翻译某些模型表现拉胯得换另一个。

我们最开始做了个最简单的随机分配。蠢。

一个月下来账单爆炸——复杂任务分到小模型，输出质量差不说还得重试，简单任务反而占着贵模型。典型的“该省不省、该花不花”。

我踩过的三个坑，一个比一个疼

坑1：按token计费就完了？天真

我最初的想法特简单：记录每个请求的输入输出token数，乘单价，完事。

第一个月对账就傻了。不同模型的计费逻辑差异巨大，根本不是“统一乘个系数”能搞定的。

GPT系列输入输出分开计价，输出贵3-5倍。Claude也是分开计价，但价格整体比GPT高30%左右。DeepSeek输入便宜得离谱，但输出价格跟GPT-4o mini差不多。通义千问更绝，文本超过8K有额外的上下文加收费，文档里写了但藏得特别深。

还有一个坑我差点没发现：有些模型对system prompt也收费，有些不算。我们之前统一按input token算，导致Claude的成本被低估了将近15%。等等，这里我要更正一下——不是15%，是18.7%，我刚翻了下当时的记录。因为Claude的system prompt收费是按完整token数算的，不像普通input有各种优化，实际单价更高。

我们后来重新设计了计价模型，大概是这样的结构：

// 注意看各种边界情况，每个坑都是钱
const pricingModel = {
 'gpt-4o': {
 inputPrice: 0.0025,
 outputPrice: 0.01,
 cachedInputPrice: 0.00125, // prompt缓存半价
 freeSystemPrompt: true
 },
 'claude-3.5-sonnet': {
 inputPrice: 0.003,
 outputPrice: 0.015,
 cacheWritePrice: 0.00375, // 缓存写入额外收费
 cacheReadPrice: 0.0003,
 freeSystemPrompt: false // system prompt也计费
 },
 // ... 其他模型
}

有个数据特别说明问题：启用prompt缓存后，Claude的成本降了42%，但前两周因为没算cache write的费用，实际节省只有32%。我还在周报里洋洋得意写了“成本下降42%”，后来发现不对，灰溜溜去更正了。

坑2：只看价格不看性能，蠢到家

有段时间我疯狂迷恋DeepSeek。真的太便宜了，输入价格只有GPT-4o的十分之一。我当时想，这还用选吗？全切过去啊。

然后把所有摘要生成任务都切到了DeepSeek。

第三天用户反馈像雪崩一样来了。英文摘要还行，中文摘要经常出现奇怪的翻译腔——就是那种“他做出了一个决定”式的生硬表达。日文摘要更惨，敬语体系完全混乱，有个用户直接留言说“你们是不是用机翻的”。

我们赶紧抽样对比了500条数据。大概的结果是这样的：

| 模型 | 中文摘要评分 | 日文摘要评分 | 平均耗时 | 每千次成本 |

|------|------------|------------|---------|-----------|

| GPT-4o mini | 4.2/5 | 4.0/5 | 1.2s | ¥2.8 |

| DeepSeek-V3 | 3.8/5 | 2.9/5 | 0.9s | ¥0.6 |

| Claude 3 Haiku | 4.3/5 | 4.1/5 | 1.5s | ¥3.5 |

DeepSeek便宜是真便宜。但日文任务完全不能用，这个没得商量。

后来我们调整了策略：多语言任务拆开，日语走Claude，其他语言走DeepSeek。综合成本降了40%，质量没掉。这件事教会我一个道理，成本优化不是找最便宜的模型，而是给每个任务找性价比最高的那个——这话我后来写在团队Wiki首页了。

坑3：并发限制，直接让你怀疑人生

去年12月10号，我们的产品突然爆了一波。QPS从100飙到800，完全没预警。后来才知道是有个科技博主写了篇推荐，发在少数派上。

我们的动态路由逻辑当时是这样的：先试便宜模型，超时或质量不达标再切贵的。听起来挺合理吧？

结果那天下午4点03分，所有DeepSeek的请求突然开始排队。等30秒都排不上。路由系统慌了，疯狂切到GPT-4o。但GPT-4o也有速率限制，我们买的额度根本扛不住800QPS。最后的场面是：便宜模型排队，贵模型限流，请求全堵在中间件里。

我在日志里找到那段记录，现在看还心有余悸：

16:03:22 [DeepSeek] queue_length: 847, avg_wait: 32s
16:03:23 [Router] fallback triggered -> GPT-4o
16:03:24 [GPT-4o] rate_limit_hit: 429 errors, retry_after: 5s
16:03:25 [Router] fallback -> Claude 3.5 Sonnet 
16:03:26 [Claude] rate_limit_hit: 429 errors
16:03:30 [ALL MODELS] degraded, accepting_queue: 1200+

事故持续了23分钟。损失了大概4000个请求，额外成本增加了¥3200——因为大部分fallback都落到了最贵的Claude上。我那天晚上加班到凌晨两点，一边改配置一边骂自己。

现在的方案：三层路由

踩完这些坑之后，我把整个路由系统重构了。嗯...这个比较复杂，我尽量讲清楚。

第一层：任务分类器

不再把所有请求一视同仁。先分类：

• **L1-简单任务**：摘要、关键词提取、情感分析
• **L2-中等任务**：翻译、改写、基础问答
• **L3-复杂任务**：深度分析、长文生成、多步推理

分类器本身是个蒸馏后的BERT，跑在我们自己的服务器上，耗时不到50ms，成本可以忽略。

每个任务等级有候选模型池和成本上限：

L1: [DeepSeek-V3, GPT-4o-mini] 预算: ¥1/千次
L2: [GPT-4o-mini, Claude-3-Haiku] 预算: ¥5/千次 
L3: [GPT-4o, Claude-3.5-Sonnet] 预算: ¥30/千次

第二层：智能路由器

这层做实际决策。同时看4个维度：实时成本、模型健康度、任务质量要求、预算剩余。

核心算法是加权评分。大概长这样：

def calculate_model_score(model, task, context):
 # 成本得分：越便宜越高
 cost_score = 1 - (model.estimated_cost / task.budget)
 
 # 质量得分：基于历史数据
 quality_score = get_historical_quality(model, task.type, task.lang)
 
 # 健康度得分
 health_score = model.health_metric
 
 # 预算压力系数
 budget_pressure = context.daily_budget_used / context.daily_budget
 
 weight_cost = 0.3 + (0.4 * budget_pressure)
 weight_quality = 0.4 * (1 - budget_pressure)
 weight_health = 0.3
 
 return (cost_score * weight_cost + 
 quality_score * weight_quality + 
 health_score * weight_health)

效果挺明显的。预算紧张时（月底），系统自动把更多请求路由到便宜模型。我们月底最后三天的成本比月初降了28%，用户满意度只掉了3%。这个3%我觉得可以接受——毕竟省钱也是用户体验的一部分，虽然用户自己感受不到。

第三层：熔断与降级

专门应对并发爆炸。

三个机制：主动预热（每天早上8点发探测请求建立连接池）、动态限流（响应时间超过2秒开始限流）、优雅降级链。

L2翻译任务的降级链举个例子：

主路径: GPT-4o-mini (¥5/千次, avg 1.2s)
 ↓ 超时2秒或错误率>5%
备选1: Claude-3-Haiku (¥8/千次, avg 1.5s) 
 ↓ 超时3秒或错误率>10%
备选2: DeepSeek-V3 (¥1.5/千次, avg 0.9s)
 ↓ 全部不可用
降级兜底: 本地缓存或友好错误提示

加上熔断后，系统可用性从99.2%提到99.7%。0.5%看着不大，但换算成绝对数字，每月多服务了约15万个请求。对于付费用户来说，可能就是“能用”和“用不了”的区别。

监控：让钱看得见

光有路由策略不够。你得能看到钱花在哪儿。

我们搭了个Grafana面板，几个关键指标：实时成本流速（像转速表，每分钟花了多少钱）、模型成本占比（饼图）、异常检测告警（成本飙升30%钉钉秒级通知）、租户维度拆分。

最有用的指标叫「单位任务成本趋势」——处理1000个请求的平均成本是涨了还是降了。这个数字每周一在团队群里公布。降了老板发红包，涨了我请喝咖啡。上个月我请了三次。

有个有意思的数据：上线prompt缓存后，单位成本断崖式下跌37%。但第二周又回升了5%。查了一圈发现产品经理加了新的长文本功能，大部分请求根本命中不了缓存。我们改了缓存策略，不全量缓存，只缓存高频的system prompt片段，命中率从12%提到68%。

据我了解，这个策略在圈子里还不算普遍，大部分人还是一股脑全量缓存。但我觉得得看场景，我们这种system prompt高度重复的业务，片段缓存明显更划算。

实际效果和真心话

跑了三个月，交个成绩单：

• 总成本下降52%（对比最初随机分配）
• P99延迟从4.8秒降到2.1秒
• 预算超支事故从每月3次降到0次

最大的隐性收益：团队对成本有体感了。以前大家调用API像用水龙头，现在路由系统在调试模式显示预估成本，产品经理自己都会主动优化prompt。

不过说实话，这套方案不是银弹。最大的问题是复杂度——三层路由、实时监控、动态权重，出问题时排查起来能让人抓狂。

上个月有个bug我查了整整两天。某个时间段DeepSeek的成本突然暴涨，最后发现是路由系统在计算成本时，把DeepSeek的输出价格搞错了，小数点后多了一个0，导致系统觉得它“很贵”，反而把更多请求分配给了GPT-4o。GPT-4o确实更贵，但因为计算错误，系统以为自己“省钱了”。这种元层面的bug特别难发现，所有监控指标看起来都是“正常”的。

所以如果你也想搞这套，我的建议是渐进式来：

1. 先搭成本监控，看清楚钱花哪儿

2. 核心场景做静态路由（写死的规则）

3. 数据积累够了再上动态路由

4. 熔断降级最后加，那是保命的

别一上来就搞全自动智能路由。你会疯的。

现在回头看那张8万块的账单，居然有点感谢它。要不是那次事故，我们可能到现在还在用随机分配，然后每个月稳定超预算。

说起来，你们团队在多模型调用上有什么骚操作吗？有没有遇到过让你怀疑人生的API账单？评论区聊聊，我看看有没有比我更惨的。

#成本优化 #API网关 #LLM #架构设计 #经验分享