千问api平台模型价格对比，一次说清做法（第一步：先把计费口径对齐，再谈贵）

想给项目挑一个千问模型，把几个模型的单价摆在一起看，很容易比出错误结论：有的按输入输出分开计、有的有缓存价、有的长上下文加价，直接比「每百万 token 多少钱」就会错位。这篇给一套固定流程：先把计费口径对齐，再按任务类型做对照，最后用真实用量验证。适合刚接入或准备换模型的开发者。

给项目挑千问模型，最容易犯的错是把几个模型的单价摆在一张表上直接比大小。千问各模型计费方式并不统一：有的输入输出分开计价，有的带缓存命中价，长上下文还可能另算一档。口径没对齐就比，结论大多是错的。

这篇给一套固定流程：先把计费口径对齐，再按任务类型筛选候选，然后用真实样本跑一遍单任务成本，最后上线验证测算准不准。适合刚接入千问或者正准备换模型的开发者，照着走一遍就能得出自己的结论。

第一步：先把计费口径对齐，再谈贵不贵

对齐口径的核心动作是：拿到候选模型的计费说明，逐项确认输入、输出、缓存命中、长上下文这几档分别怎么算。缺哪一档就在对照表里标出来，别默认它不存在。全部确认完再进入比价，比的过程中发现口径不一致就退回这一步。

口径确认后，把单价统一换算成「一次典型请求的成本」再比，不要停在每百万 token 的标价上。换算可以直接用站内工具：到 /tools/token-price-calculator 按输入输出长度算单次消耗，再用 /tools/model-cost-calculator 折算成日成本量级。

当期具体数字不要凭记忆或旧截图，价格会调整。到 /official-api/providers/alibaba 和 /official-api 核对当时的数字，以页面上的为准。什么情况不适用：如果你的请求绝大多数是短输入短输出，缓存那一档基本用不上，对齐口径时可以直接忽略缓存项，不必为它纠结。

第二步：按任务类型把模型和场景对上号

在比价之前先把线上任务分类，常见四类：高频短问答、长文档阅读总结、代码生成、批量结构化抽取。这四类对上下文长度和输出长度的要求差别很大，混在一起比价没有意义。分完类再动手筛模型。

• 高频短问答：看重单次成本低、延迟稳定，输出通常很短
• 长文档阅读总结：先看上下文长度够不够，再看长上下文的计费档
• 代码生成：输出偏长、对结果可读性要求高，成本主要压在输出侧
• 批量结构化抽取：量大、格式固定，重点看能否稳定输出结构化结果

给每一类任务标出必须满足的硬条件，比如上下文长度够不够、是否需要结构化输出、能接受多长的响应延迟。用硬条件先把候选模型筛一遍，筛完再比剩下的几个，避免一开始就把所有模型拉进比价表。

第三步：用真实样本跑一遍单任务成本

从线上日志里抽一批真实请求当样本，分别打给候选模型，记录每次的输入 token 数、输出 token 数和实际耗时。单任务成本用单次 token 消耗乘当期单价，再乘预估日均调用量，得出日成本量级。

1. 抽样本按任务类型各抽一批真实请求，保留原始输入，别手工改写成理想化的短句。
2. 跑两轮每个候选模型都跑同样样本，记录 token 数和耗时，同一请求重复跑一次看波动。
3. 算成本用 /tools/token-price-calculator 按记录的长度算单次成本，再乘调用量折算日成本。
4. 填对照表至少列模型、单任务成本、延迟、结果是否可用四列，只列单价的一列没有决策价值。

什么情况不适用：样本量太小，或者任务差异极大（有的请求只有一句话、有的几万字），单任务成本会被拉偏。这时要按长度分层，短请求和长请求分别算，再看各自的调用占比加权。

第四步：切换之后怎么验证没算错

上线后先跑一段时间，把实际账单和测算值放在一起对。差额明显超过预期，先查缓存命中比例，再查是否有重试导致的重复计费。验证通过之前，别急着把旧模型下线。

• 核对单次 token 数：实际消耗是否和样本测算接近
• 核对单价口径：计费页面有没有改档或调整
• 核对调用量：是否有重试、超时重发造成的放大
• 核对缓存：命中比例是否和测算假设一致

计费口径或单价调整时，不能只改测算表，要同步重算历史用量，否则前后对比会失真。另外把用量结构复核纳入常规节奏，调用量上来以后，最优模型可能换人，原来的结论要重新跑一遍。

排查顺序固定下来：先看单次 token 数变没变，再看单价口径变没变，最后看调用量有没有重复计费。按这个顺序查，大多数账对不上都能定位到具体环节。