最近，头部大模型厂商陆续调整 API 定价。表面看是单价的例行上调，但如果调价的同时计量方式也在变化，开发者的真实成本涨幅往往会远超价格表上的数字。对依赖模型 API 的团队来说，这已经不是"多花点钱"的问题，而是"钱花到哪里去了，根本算不清"的问题。
标价成本为什么失真
大多数团队算 API 成本的方式，是拿价格表上的单价乘以调用量。这在模型与计量方式长期不变时勉强够用，一旦发生两类变化就会系统性失真：一是单价上调，比如输入输出价格整体上涨；二是 tokenizer 变更，同一段代码在新版本下消耗的 Token 数明显增多，等价于用量被"偷偷放大"。单价与用量同时变化时，真实成本涨幅不是两者相加，而是相乘。
成本治理的四个工程化环节
1. 数据采集：在统一网关层记录每一次调用
成本治理的前提是数据。建议在团队的统一 API 网关层拦截所有模型调用，把每次调用的模型、Token 数、业务线、环境记录下来。以 Python 为例，核心逻辑可以收敛在一个函数里：
# 统一网关层记录单次调用的真实成本
PRICING = {
"flagship": {
"input": 3.0, "output": 15.0}, # 美元 / 百万 Token
"fast": {
"input": 0.5, "output": 2.0},
}
def record_usage(call_id, model, prompt_tokens, completion_tokens, project, env):
p = PRICING.get(model)
if not p:
return
cost = prompt_tokens / 1e6 * p["input"] + completion_tokens / 1e6 * p["output"]
emit_metric(
name="llm_call_cost",
value=cost,
tags={
"project": project, "env": env, "model": model},
)
把计价表集中维护，即使厂商调价，也只需要改一处配置，历史数据可以重算回放。
2. 成本归因：按业务线拆分账单
只有总量没有拆分，等于没有数据。归因至少要支持三个维度：项目（哪个业务线）、环境（生产/测试/预发）、模型（哪家哪个型号）。有了这三个维度的聚合，月底就不用再对着混合账单猜"哪个团队烧了最多钱"。
3. 模型路由：让便宜模型干简单活
团队里最贵的模型，往往不是用在最难的任务上，而是用在最顺手的地方。代码补全、日志分析、文案初稿这些任务，完全可以用成本更低的模型完成。在网关层加一道路由：按任务类型、上下文长度、业务优先级，把请求分发到不同档位的模型上。
def route_request(task_type, priority, input_len):
if task_type in ("code_completion", "log_summary") and input_len < 4000:
return "fast" # 低成本档位
if priority == "high":
return "flagship" # 高优任务上旗舰
return "fast"
这一步做好的收益非常直接：相当一部分请求被切到低成本模型上，成本下降幅度往往比跟厂商谈折扣更可观。
4. 预算告警：在账单爆掉之前拦截
为每个项目、每个环境设置预算阈值，按天聚合消耗，超过阈值触发告警。结合云上监控与告警体系，可以把"月底发现账单爆了"提前到"当天发现异常消耗"。
把治理能力沉淀到云上可观测体系
以上四步本质上是一套可观测能力的建设：指标（每次调用的成本与延迟）、日志（调用明细与错误）、告警（预算阈值与异常波动）。在阿里云上，可以基于日志服务（SLS）采集调用明细，用云监控配置预算与消耗告警，再结合函数计算或云原生网关承载统一路由层，把成本治理做成团队长期复用的基础设施，而不是每次涨价后临时救火。
小结
模型 API 调价是行业常态，但"算不清账"不是常态。把数据采集、成本归因、模型路由、预算告警四个环节工程化落地，团队才能在厂商每次调价时快速回答一个问题：这次涨价，真正涨到我们头上多少？
