大模型API调用成本计算器：百万 Token 输入输出价格一览与降本策略

很多人第一次看 API 账单都会愣一下：明明感觉没用多少，钱却花得比预估快。问题多半不在「用得多」，而在没搞清计费口径、没算过单位成本、也没设过任何限制。这篇不讲模型选型，只讲钱：怎么看懂计价项、怎么把用量换算成钱、怎么在不牺牲效果的前提下把成本降下来。

第一次看 API 账单觉得贵的开发者，十个里有九个说不清钱花在哪。不是用得太多，而是从一开始就没搞懂计费口径——输入和输出是一个价吗？缓存命中怎么算？系统提示每轮都重复收费吗？这些不想清楚，任何省钱动作都是瞎猜。

这篇专攻成本测算，不碰选型。目标是让你能在动手写代码之前，就把大概要花多少钱算出来；在账单出来之后，能对得上账、找得到贵在哪；以及在效果不打折的前提下，把该省的钱省下来。

先搞清计价项：输入、输出、缓存各算一笔

几乎所有厂商都把输入和输出分开计价，而且输出普遍比输入贵一截。这意味着让模型复述原文、输出整段文档、或者为了格式把已知内容再吐一遍，都是在用最贵的那部分计费。能做成引用、ID 或者短标记的地方，就别让模型重新生成一遍。

输入 Token

你发给模型的内容，包括系统提示、历史对话、用户当前消息、检索回来的资料

输出 Token

模型生成的内容，含正式回复，也可能含思考过程、工具调用参数

缓存写

把一段固定内容存进缓存的那一次，通常单独计价，价格高于普通输入

缓存读

后续请求命中缓存时读取的部分，通常是所有计价项里最便宜的

不同厂商对系统提示、图片、思考过程的计量口径并不一致，有的把思考 Token 算进输出，有的单独列；图片有的按张算，有的折算成 Token。比价之前先对齐口径，否则拿两个不同算法的单价对比，结论一定是错的。具体每家怎么算，到 /price-watch 核对当时的数字和备注说明。

把每百万 Token 的价格换成「一次任务多少钱」

每百万 Token 多少钱这个数字，对做预算的人其实没什么用——你不会一次调用百万 Token。真正要算的是：你的一次总结、一轮问答、一次代码修改，分别要花多少钱。算法很直接：把真实任务的输入输出量记下来，乘对应单价，得出单次成本。

1. 挑一个代表性任务选你日常调用最多的那类，比如「总结一篇长文」或「回答一轮客服问题」，别挑极端案例
2. 量出真实 Token 数把该系统提示、历史上下文、用户消息、预期输出全部加进去，得到输入输出 Token 量
3. 换算成钱输入量乘输入单价，输出量乘输出单价，相加就是这一次任务的钱。单价到 /price-watch 取当时的数字
4. 乘上放大倍数考虑重试、失败重发、多轮上下文重复发送，实际成本往往是理论值的几倍

这里有个容易踩的坑：单价低的模型不一定总成本低。如果一个便宜模型需要三轮才答对，而贵模型一轮就过，算下来反而贵模型更划算。长上下文任务尤其明显——上下文越长，便宜模型在「多轮重复输入」上的劣势越会被放大。

用量从哪来：把每一笔调用都记下来

靠感觉估算用量是最不靠谱的做法。绝大多数 API 的返回体里都带着本次调用的用量字段，包括输入、输出、缓存命中情况。把这些字段落库，比事后拿总额除以次数靠谱得多。没记日志的团队，建议先跑一周采样再谈降本。

• 调用日志至少要包含：时间、模型、任务类型、输入 Token、输出 Token、缓存命中量、是否重试
• 三个拆分维度必须能查：按任务类型、按模型、按天
• 用量记录要能和充值记录对得上，对不上说明有调用没被统计
• 重试和失败请求也要记，它们同样产生费用
• 日志字段留够余量，后面想按用户或按接口维度拆分时不用改表

对账是这件事的落脚点：月底把用量日志汇总出来的消耗，和实际扣费核对一遍，差额大就说明有统计盲区，比如异步任务没记、定时任务漏记、或者某个内部工具没接入日志。找到盲区比省下几个点更有价值。

钱到底花在哪：六类常见成本放大器

这六类里，前两类是最常见的，也是改动成本最低的。上下文膨胀通常不是模型的问题，是代码没做裁剪或摘要；输出失控往往是提示词没写长度约束。建议按上表逐项过一遍，先找出你自己命中最多的一两个，别想着一次全改。

降本动作清单：按见效快慢排序

降本不要一上来就搞工程改造，先把风险最高的那部分关掉。顺序很重要：先止损，再优化，最后才做改造。这样即使后面的优化没做完，也不会出现账单跑飞的情况。

1. 设额度上限与告警给每个调用方设预算上限，超过阈值就告警或直接降级。这一步不做，后面所有优化都白搭
2. 裁上下文、做摘要压缩历史对话只保留必要部分，长资料先摘要再送。验证方式：改完看单次输入 Token 是否下降
3. 按任务切模型把任务按难度分层，简单活走轻量模型，复杂活才用顶配。验证方式：分层后各层质量指标是否还达标
4. 配缓存与批处理系统提示、固定知识这类高频重复内容走缓存；离线任务走批处理通道。验证方式：缓存命中率、批处理占比是否真的涨了
5. 复测效果每改一步都跑一遍质量抽检，别为了省钱把效果砍没了。省钱但返工，等于没省

什么情况下这套顺序不适用？如果你的调用量本身很小，比如一天几十次，那设额度上限的价值有限，直接做上下文裁剪收益更大。反过来，如果调用量巨大但结构很均匀，缓存和批处理的收益会明显高于改提示词。

动手前的估算流程：先算再跑

上生产之前先估一遍，能避免很多尴尬。估算不需要很准，但要有区间概念：最坏情况大概多少，理想情况大概多少。估出来的数字写下来，跑一段时间后拿来对照，偏差大的地方就是你之前理解错的地方。

# 估算伪代码思路，不是可直接运行的脚本
输入token = 系统提示 + 历史上下文 + 用户消息 + 检索资料
输出token = 预期回复长度 * 安全系数
单次成本 = 输入token * 输入单价 + 输出token * 输出单价
总成本区间 = 单次成本 * 预计调用次数 * (1 + 重试率)
# 单价去 /price-watch 取当时数字，别写死在代码里

• 先估 token 量，再乘单价，得出单次成本区间
• 单次成本乘预计调用次数，看是否在预算内
• 估算偏差大时，用小批量真实任务跑一遍校准
• 把估算结果写下来，跑完对照复盘
• 单价不要硬编码，从配置读，方便调价时更新

估算最容易忽略的是重试和失败请求的成本。如果失败率不低，实际消耗可能是理论值的好几倍。估算时给重试率留个保守的余量，跑一段时间后再用实际数据修正。

复盘节奏：多久看一次账，看什么

成本管理不是一次性工作，得有节奏。频率太高浪费精力，太低又发现不了问题。建议每周看一次分项用量，每月做一次完整对账，把用量日志和实际扣费核对清楚，差额大就查盲区。

把每次调价、换模型、改提示词都记进一条时间线，这样成本出现波动时能快速归因。没有时间线，你会花大量时间猜是哪个改动导致的，而且往往猜错。具体各家当前的价格和计价口径，随时到 /price-watch 看当时的数字，别依赖记忆。