很多人第一次比千问 API 价格，是把几个模型名并排一看，挑个数字低的就下单，结果接进项目才发现计费口径对不上：有的按输入输出分开算、有的长上下文另计、缓存和批量又是另一套。这篇不给结论数字，只给一套流程：先把口径对齐，再按任务场景排序，接完用小流量验证账单。每一步都告诉你该看站内哪一页，以及什么情况下这套做法不适用。
不少人第一次比千问 API 的价格，做法是打开模型列表，把几个名字并排一看，挑单价低的那个就接进项目。真正跑起来才发现账对不上：有的模型输入输出分开算，有的长上下文另起档位，缓存命中、批量任务、免费额度又各有一套规则。低单价未必等于低账单，尤其当你的任务输出很长或者重试很多的时候。
这篇不报任何结论数字，只给一套能照着走的流程：先把各模型的计费口径拉齐，再按任务场景排序而不是按价格排序，接完拿小流量把预估账单和真实账单对一遍，最后把选型定下来并留好复核节奏。每一步都说明该去站内哪一页看当时的数据，也说明这步在什么情况下可以直接跳过。
第一步：先把各模型的计费口径对齐
口径没对齐之前的所有比较都是白费。你要先搞清楚每个候选模型的计费结构是不是同一种形状，再谈谁便宜。最省事的办法是把每个模型拆成下面几个问题逐条填，填完再看数字，否则很容易拿一个「元/千字」去和一个「元/百万 token」硬比。
- 输入与输出是否分开计价
- 分不分开决定你的任务里哪一头更烧钱，输出长的任务在这一项上差异最明显
- 长上下文是否单独档位
- 超过某个长度的请求可能按更高档计，长文档类任务必须确认这一点
- 缓存读写
- 命中缓存的输入通常便宜很多，但前提是你的提示词前缀稳定、能反复复用
- 批量任务
- 离线可等的任务走批量通道往往有单独的价格，实时接口不适用
- 免费额度怎么抵扣
- 先扣哪个模型、到期怎么算，会影响你前期试跑的真实花费
把这些维度整理成一张表，逐个模型填「有/无/另有规则」，填完再去站内的模型价格页核对当时的具体数字，路径是 /models。同一批模型放在同一张表里看，口径不一致的地方会立刻暴露出来。
- 先统一单位再比较，把所有单价换算成同一个计量单位，避免混着比
- 把「输入贵、输出便宜」和「输入便宜、输出贵」的模型分开放，它们适合的任务根本不同
- 确认免费额度和付费部分的边界，试跑阶段很容易在这上面算错预算
- 记下每个模型的计费口径版本，价格页上的说明会更新，隔一段时间要重新核一次
第二步：按任务场景而不是按价格排序
价格排序只在一个前提下有意义：这些模型在你的任务上能力都够。所以第二步是先列任务，再谈价格。把项目里要调 API 的地方按类型拆开，每一类单独选型，不要指望一个模型通吃所有场景。
| 任务类型 | 上下文需求 | 输出长度 | 预算敏感度 |
|---|---|---|---|
| 高并发短问答 | 短 | 短 | 高，单价直接放大到调用量上 |
| 长文档理解与摘要 | 长 | 中等 | 中，长上下文档位要先确认 |
| 代码生成与改写 | 中等 | 偏长 | 中高，输出长会推高账单 |
| 结构化抽取与分类 | 中等 | 短且固定 | 高，输出可控所以单价影响最大 |
| 多轮工具调用 | 中等且累积 | 中等 | 低，先保证能力达标再谈钱 |
这张表的关键是把「输入长、输出短」和「输入短、输出长」的任务分开。前者的成本主要压在输入侧，后者的成本主要压在输出侧，两种任务最合适的模型经常不是同一个。填完表再去 /models 对照各模型的价格数字，按行匹配，而不是按整体印象挑一个。
- 拆任务清单把项目里所有调用点列出来，每个标上任务类型、平均输入长度、平均输出长度、是否可离线
- 划能力底线对每类任务写一条最低要求，比如必须支持多轮工具调用或必须能稳定输出 JSON，达不到的直接出局
- 在达标模型里比价剩下的候选按上表逐行比对，注意只比同一口径下的数字
- 留一个备选每类任务选一个主用、一个备用，备用不一定是更便宜的，也可以是能力更稳的
第三步：小流量试跑，把预估和真实账单对上
纸面比价永远会有偏差，因为真实请求的输入输出长度分布、重试率、缓存命中率都和你拍脑袋估的不一样。所以接完不要直接全量切，先拿生产样本的一小部分跑一遍，把账单对出来。
试跑的重点不是看模型回答得好不好，而是看实际消耗和你预估的差多少。差异大的地方通常就那几类：缓存没命中、失败重试重复计费、输出被截断后重发、长请求触发了更高档位。
- 记录每次请求的输入 token、输出 token、是否命中缓存、是否重试
- 跑完把实际花费和事前估算逐项对，标出差异超过预期的项
- 差异大的项回到第二步的表里，看是不是任务拆分或模型选择出了问题
- 对账结果存档，作为后面价格变动时的对照基线
试跑期间的价格和额度说明，以 /price-watch 上当时展示的数字为准，不要拿几天前记下来的数去对账。如果你用的是中转站而不是官方接口，实际扣费口径还可能多一层，这种情况先去 /sites 看该站的可信度记录再决定要不要拿它做试跑。
第四步：把选型决定和复核节奏固定下来
选完之后最容易出问题的是「没人记得当初为什么选这个模型」。过几个月价格变了、新模型出来了，团队里没人说得清该不该换。所以要把决定写下来，并且给复核定一个固定节奏。
| 要记的内容 | 为什么记 | 复核时怎么用 |
|---|---|---|
| 每类任务固定的模型 | 避免后续接手的人凭感觉换 | 看它是否还是当前最优 |
| 备选模型及触发条件 | 换模型不该临时拍脑袋 | 错误率或单次成本超阈值时启用 |
| 试跑时的单位成本 | 这是你唯一的真实基线 | 和当前账单对比看有没有漂移 |
| 上次复核时间 | 防止比价结论过期 | 超过一个周期就重新核一次 |
- 复核时只看两件事：当前任务的实际单位成本有没有变化，有没有能力相当但单价更低的替代
- 价格数字去 /models 和 /price-watch 核对当时的数值，不要凭记忆
- 能力变化看站内的评测页，注意评测维度是否和你的任务类型对得上
- 如果换了模型，重新走一遍小流量试跑，别直接全量切
常见问题
千问各模型的 API 价格差得多吗，直接选最便宜的行不行？
便宜模型和贵模型通常差在上下文长度、推理深度和稳定性上。如果你的任务只是分类、抽取、短问答，选便宜的通常没问题；但涉及长文档理解、复杂代码或多轮工具调用，便宜档容易答不完或质量不稳，重试和返工的成本反而更高。先过能力门槛再比价。
对比价格时要不要把免费额度算进去？
可以算，但要算成「过渡期优惠」而不是长期成本。免费额度有周期、有模型范围和用完即停的规则，具体口径去站内百炼和免费额度相关页面核对。做长期预算时建议按纯付费单价算，免费额度只当缓冲，否则额度一到期预算就对不上了。
接进来之后发现账单比预估高，一般先查哪里？
按顺序查三处：一是输入输出 token 是不是按你预估的长度在跑，长上下文任务最容易超；二是缓存有没有命中，没命中的部分按原价算；三是失败重试有没有重复计费。三处都排除后，再去看是不是走了中转渠道、倍率对不上，那就去比官方价和渠道价的差异。
