很多开发者在要接通义千问 API 之前，最先卡住的不是怎么调通，而是「这东西到底按什么收钱、我这个月大概会花多少」。网上搜到的价格多半是旧口径，缓存、批量、阶梯价这些细节又各说各话，照着算出来的预算跟实际账单对不上。这篇不报具体数字，只把收费构成、影响用量的几个变量、以及一套从用量倒推预算和核账的流程讲清楚，数字让你自己去站内页面对。
很多开发者在要接通义千问 API 之前，最先卡住的不是怎么调通，而是「这东西到底按什么收钱、我这个月大概会花多少」。网上搜到的价格多半是旧口径，缓存、批量、阶梯价这些细节又各说各话，照着算出来的预算跟实际账单对不上。
这篇不报具体数字，只把收费构成、影响用量的几个变量、以及一套从用量倒推预算和核账的流程讲清楚。凡是要看价格的环节，我都写成「去站内某个页面查当期值」，这样你看到的永远是当天有效的口径，不会拿一篇几个月前的文章当依据。
先搞清楚钱是按哪几项收的
通义千问 API 走的是按量计费，钱主要落在输入 token 和输出 token 上，两者单价通常不同，输出那一侧更贵。把「一次请求花多少」当成只算一个问题，是预算跑偏最常见的起点。你还要意识到，同一模型可能挂在多条产品线下，比如在线推理、批量任务、上下文缓存、微调后托管，各自的计价口径和折扣规则不一样。
- 输入 token
- 你发给模型的那部分内容，包含系统提示词和拼进上下文的资料。
- 输出 token
- 模型生成返回的部分，通常单价高于输入侧。
- 批量通道
- 非实时任务可以走的路子，计价规则与在线调用不同。
- 上下文缓存
- 重复前缀被复用时的计费方式，命中与否影响单次成本。
判断标准很简单：报给你的那个「单价」，先问清它对应哪条产品线、哪个模型档位、是否是阶梯后的价格。这些信息到 /official-api/providers/alibaba 看阿里云百炼的模型与计费入口，确认你要用的模型当前挂在哪个口径下。如果页面上的口径和你手里的报价单对不上，以站内当期页面为准。
决定你账单高低的几个变量
调用量只是其中一个变量，真正拉开差距的是单次请求的输入长度、输出长度、并发与重试次数、以及是否命中缓存或走了批量通道。同一段业务逻辑，换一种提示词组织方式，输入 token 可能差出数倍。长篇资料每次全量塞进上下文，是最容易被忽略的放大器。
| 变量 | 它怎么抬高账单 | 先看哪里 |
|---|---|---|
| 平均输入长度 | 每轮都重发长资料，按次累加 | 调用日志里的输入 token 字段 |
| 平均输出长度 | 生成过长或格式啰嗦，输出侧更贵 | 抽样几条返回内容人工看 |
| 重试与失败 | 超时重发等于付两次钱 | 网关的错误率与重试统计 |
| 并发峰值 | 触发限流后的重复请求 | 限流与排队日志 |
| 通道选择 | 实时与批量计价口径不同 | 站内计费入口的通道说明 |
- 先量出基线再谈优化：拿一周真实日志，算日均请求数、平均输入 token、平均输出 token。
- 用 /tools/model-cost-calculator 按你的平均长度代一遍，比拍脑袋估算靠谱得多。
- 对增长做假设：用户量翻倍、单次上下文变长，分别会出现什么结果，各算一遍。
- 把「调试与压测」单独列一档，它们不属于生产用量，但同样产生费用。
做预算的四步走法
- 第一步：从日志里抽三个数日均请求数、平均输入 token、平均输出 token。没有日志就先跑一周埋点，字段口径参考 /usage 页面，别只记总数不记分布。
- 第二步：换算成日成本三项相乘得到日 token 量，再按当期单价换算。单价去 /official-api 与 /tools/token-price-calculator 核对，不要用记忆里的数字，也不要用手抄的旧截图。
- 第三步：留不确定性余量重试、调试、上下文膨胀通常让实际用量高于估算，按经验留一段缓冲，而不是卡着理论值算，卡得越死月底落差越大。
- 第四步：按月展开并设告警把结果摊成一张月度表，设预算告警。工具与设置参考 /tools 里的换算工具和站内告警指引，别等到账单出来才第一次看。
这套走法什么时候不适用？如果你们还在早期验证阶段，调用量小到可以忽略，那就不值得花时间精算，先把功能跑通更重要。反过来，已经有稳定用户量的业务，少算重试和上下文膨胀这两块，预算基本注定要修正。
月底对账与下一步调整
对账有个固定顺序：先看总用量是否超出预期，再看单次平均 token 是否异常，最后才怀疑单价。大多数「账单不对」的抱怨，查下来其实是前两项变了，而不是计价规则改了。按这个顺序走，能省掉大量来回沟通。
- 排查重试和失败调用，看是不是有稳定的重复请求。
- 检查长上下文是否每次全量重发，能否前缀复用或裁剪。
- 确认是否有人绕过统一网关直连，导致用量分散、无法对账。
- 核对当月是否有口径变化，去 /official-api 看当期说明。
调整方向分三类，成本和工期差别很大：改提示词与上下文裁剪，不动代码；换更合适的模型档位，改配置；把非实时任务挪到批量通道，改流程。按紧迫度和影响面排序，别一上来就动架构。
还有一点：预算本身要跟着业务跑。新功能上线、用户量变化之后，重新走一遍上面的四步，别把上季度的估算当长期结论。想横向比较不同供应商与中转站的当期报价，可以去 /price-watch 看追踪记录，变化往往比你以为的频繁。
下一步先用你手头一周的调用日志，把日均请求数和平均输入输出长度三个数填出来，再去站内把当期单价对上，一轮下来大概要花多少心里就有谱了。→常见问题
通义千问 API 是不是按次收费？
不是，主流是按 token 计费，也就是按输入和输出的文本量算钱，跟请求次数只有间接关系。一次请求里塞很长的上下文，费用会明显高于十次短问答。具体到某个模型的单价与计费口径，到站内官方 API 价格页核对当期数字。
为什么我按官方单价算出来的钱和账单对不上？
常见原因有三类：一是没区分输入输出单价，二是没算上重试和失败调用产生的 token，三是你的调用实际走了缓存、批量或某条折扣通道。先按「用量是否超预期」而不是「单价是否写错」的顺序排查，再到价格追踪页看当期口径有没有变动。
小团队第一次接入，预算怎么给才不慌？
先跑一周真实调用并记录日均请求数与平均输入输出长度，再据此算出月度区间，而不是一上来就定死一个数。给调试和重试留出余量，同时设好预算告警。等业务稳定后按实际用量重算一次，把估算换成实测值。
