刚接上通义千问，跑了两天就开始犯嘀咕：这一天到底花了多少钱？是按 token 算还是按次算，输入输出为什么分开计？这篇不背单价，只给你一套从用量记录倒推每日花费的顺序：先把调用量摊成每天多少 token，再回官方价格页取当时的数字相乘，最后用账单核对一遍。照着走一遍，你就能说出自己这个项目一天大概多少钱。
刚把通义千问接进项目里，跑了两天心里就开始打鼓：这一天到底烧了多少钱？是按 token 算还是按次算，输入和输出为什么要分开计？这篇不给你背单价，因为价格随时会动，背了也白背。我给你一套从自己的用量记录倒推每日花费的顺序，照着走一遍，你就能大概说出自己这个项目一天要花多少钱。
思路很简单：你先量出属于你自己的那个变量，也就是一天用了多少 token，再回到官方页面取当时的价格数字，两者相乘，最后拿账单核对一次。下面按这个顺序展开，每一步都告诉你具体去哪里看、看什么字段。
先量出你一天到底用了多少 token
算钱最容易犯的错，是一上来就去查单价。单价是对所有人都一样的，真正决定你花多少的是你自己的调用量。所以第一步不是打开价格页，而是打开你自己的调用日志，捞出一整天的记录。这一步做扎实了，后面只是乘法。
你的日志里至少要能落地这几个字段：请求时间戳、调用的模型名、这一条请求的输入 token 数、输出 token 数、有没有命中缓存。缺任何一个，后面出偏差时你都找不到原因。如果是刚开始接，还没建日志，那就先让接口返回值里的用量字段落库，别用字数除以一个系数去硬猜，猜出来的数没有核对价值。
- 日志字段清单：时间戳、模型名、输入 token、输出 token、是否命中缓存
- 用一整天的真实流量当样本，不要拿测试数据凑数
- 把工作日高峰和夜间批处理分开看，混在一起算出来的日均会偏
- 日志没记 token 的，先把用量字段落地再做下一步
回到官方页面取当时的价格数字
量出自己的用量之后，才轮到价格。通义千问不同档位的模型，输入单价和输出单价往往不是同一个数，取价的时候要分开抄两个数，不能只记一个总价。而且官方价格会调整，也会有不同的阶梯和活动档位，所以这篇不写死任何数字，请你到站内的官方 API 资料库核对当时的输入、输出单价。
如果你是通过百炼这类平台入口接入，要先确认计价口径是平台侧定还是模型侧定，两者不一定完全相同，入口之间的区别可以在站内的服务商页面里对照。如果你走的是中转渠道，那还要再乘一道渠道倍率，倍率从哪来、怎么算，直接看站内站点目录里对应站点的说明，不要凭印象估。
把量乘上价：一天的账怎么乘出来
有了输入和输出各自的 token 量，也有了当时的两个单价，接下来就是乘法。基础算式是：输入 token 数除以一百万再乘输入单价，加上输出 token 数除以一百万再乘输出单价。输出的单价通常更高，所以那种长篇大段回答的任务，单价会被输出这一项拉高，别只盯着输入看。
乘之前建议先做一次单位换算，通义千问的价格一般按每百万 token 报，但你的日志里可能是别的口径。拿不准的时候到站内的 token 价格换算工具走一遍，确认自己没把每千 token 当成每百万 token。换算完再换个工具交叉验证，两个工具结果差得离谱，基本就说明有一处单位抄错了。
| 要算的数 | 怎么取 | 用来干什么 |
|---|---|---|
| 日输入 token | 日志汇总一天输入 | 乘输入单价 |
| 日输出 token | 日志汇总一天输出 | 乘输出单价 |
| 峰值日用量 | 挑流量最高那天 | 设报警阈值 |
| 月度外推 | 日均乘天数 | 判断预算够不够 |
建议你一次算三个数：日均、峰值日、月度外推。只算均值容易低估，因为你某一天做压测或者上了个新功能，量会突然跳上去，峰值这个数才是设报警线和预算线时真正要看的。
每日花费速查清单与常见偏差
把上面几节串起来，就是一条可以每天跑一遍的清单。顺序别乱，乱了就容易在某一步用错数。跑熟之后，这一套动作花不了几分钟，但能让你对自己的花销心里有底。
- 捞用量按天汇总请求日志，拿到输入、输出各自的 token 总量。
- 分开统计输入和输出分别记数，不要合成一个总数。
- 抄单价到站内官方资料库取当时的输入、输出单价，渠道再叠倍率。
- 做乘算按输入、输出两条线分别乘，再相加得到当天估算。
- 对账单和真实账单比一次，差得多就回头查是哪一步口径不同。
- 记偏差把偏差原因写下来，下次估算时提前考虑进去。
常见偏差有三个，值得单独盯。一是重试和失败的请求，你日志里可能也记了，但这类请求到底算不算钱要看平台口径，别默认免费。二是多轮对话，每一轮都会把历史上下文带进去，看着是同一个问题，越往后输入 token 涨得越快，这是很多人日花费超预期的主要原因。三是缓存命中，命中与否会改变实际单价，算完账记得回来看一眼自己的命中率有没有影响到估算结果。
什么情况下这套估算不适用
上面这套算式的前提是纯文本、按量计费、流量相对平稳。只要三个前提有一个不成立，估算就得换方法，不能硬套。写清楚不适用的边界，比给你一个看起来很精确的数更有用。
- 混了图片或语音
- 非文本模态不按 token 算，计费单位不同，得到站内模型库查对应模态的口径
- 用包月或编程套餐
- 按量单价外推不成立，额度口径看站内对应的套餐页面
- 用量波动极大
- 均值没有参考价值，应按高峰和低谷分别算，再取上限来估预算
- 估算与账单对不上
- 以账单为准，差异排查用站内的换算与检测工具，不要用估算数去反推
还有一点要记住：估算给你的只是一个量级感，真实扣费永远以你的账单为准。估算的作用是让你在量突然涨、或者渠道换了之后，第一时间察觉到花费可能变了，而不是拿它当精确记账。
先量自己的用量，再取当时的价格，两个数一乘，最后一定拿账单对一次。下一步把你自己的用量和站内当时的单价对一遍，再顺手看一眼中转站点的渠道说明和价格追踪页，确认自己用的那档价格没变。→
常见问题
通义千问 API 一天大概多少钱，有没有一个通用数字？
没有通用数字，因为花费完全由你自己的调用量决定。同样的模型，一天几十次短问答和一天几万次长文本处理能差好几个数量级。正确做法是先从日志里取出你一天的输入、输出 token 量，再乘上官方页面当时的单价。想快速出结果，可以用站内的 token 单价换算工具，把总量代进去看量级。
按 token 算出来的数和实际账单对不上，一般先查哪里？
先查三处：一是模型名有没有写错档位，同系列不同档单价差很多；二是输入输出有没有被算混，输出一般更贵；三是统计期间有没有重试、失败重发或缓存命中的调用混在里面。把这三项对齐之后再看差值，剩下的差距通常来自计价口径，建议到官方价格页面重新核对一次当时的单价与规则。
小团队想控制每日花费，最该先动手改哪一块？
先砍输出长度，再砍输入冗余。输出的单价通常更高，把回答限制在够用的长度，收益最直接；输入侧则通过精简系统提示、控制历史轮数来压缩。这两项改完再考虑换档位或加缓存。如果这些都不见效，说明问题在调用量本身，那就要回到业务层判断哪些请求其实没必要发。
