模型 API 比价：单价之外的成本

适合准备接入 API 的开发者、已有调用量的企业团队，以及需要复核现有采购方案的人。尚未确定任务时，准备好代表性输入、期望输出与必要功能，询问模型范围会更有效。

六个比较维度

1. 模型身份：准确标识、版本、输入输出类型、上下文与输出限制。兼容某类接口，未必支持全部功能。
2. 计费口径：输入、输出、缓存或其他项目如何计算；失败、重试、取消及长任务是否计费。
3. 响应表现：对话区分首字等待与完整输出耗时；图片等异步任务记录从提交到可取结果的时间。
4. 用量约束：请求频率、Token 限制、并发与额度分别确认。高额度不自动代表高并发能力。
5. 质量与稳定性：在相同样本上记录任务通过率、错误类型和延迟分布，不只保留平均值或一次成功。
6. 数据与责任：谁处理输入、日志如何保存、异常由谁响应、模型变更和合作结束时如何处理。

比价表怎么填

把每个候选方案写成一行，列固定为下面这些。可以下载比价表模板（CSV），用 Excel 或 WPS 打开。

表里的数字一律来自实测或书面报价，不填口头估计。某一格不知道就写「待确认」。

按合格任务算成本：一个算例

只比单价会得出错误结论。下面用示例价格（不是任何模型的真实报价）演示怎么算。

假设一个客服摘要任务：每次输入约 3000 Token。

• 方案 A：输入 2 元 / 百万 Token，输出 8 元 / 百万 Token。实测平均输出 600 Token，通过率 90%。 每次费用 = 3000 × 2 ÷ 1,000,000 + 600 × 8 ÷ 1,000,000 = 0.0108 元； 每个合格结果 = 0.0108 ÷ 0.9 ≈ 0.0120 元。
• 方案 B：输入 1 元，输出 6 元，单价更低。但实测平均输出 900 Token，通过率 60%。 每次费用 = 3000 × 1 ÷ 1,000,000 + 900 × 6 ÷ 1,000,000 = 0.0084 元； 每个合格结果 = 0.0084 ÷ 0.6 = 0.0140 元。

单价低的 B，每个合格结果反而更贵；如果不合格结果还要人工重做，差距会更大。

还要把这几项算进去：

• 缓存：系统提示和固定资料很长时，支持提示缓存的接口能降低重复输入的费用。按实际命中率估算，不按理想值。
• 重试：超时或报错后自动重试的请求同样消耗用量。
• 月度规模：每个合格结果的费用乘以每月任务量，就是月度成本的估算，再加上预计增长。

一次小规模比较怎么做

与合作方确认可测试范围、费用和频率限制。选择有代表性且允许使用的样本，固定参数与输出标准，记录请求标识、时间和用量。把超时与错误计入结果，避免只统计成功样本。

建议的规模：每个方案 50 到 200 个样本，同一时段内交替调用，避免因为时段不同造成延迟差异。

最后按「完成一个合格任务」的实际用量估算成本，同时列明未验证条件。不要仅凭一个展示分数推断生产稳定性，也不要未经授权进行压力测试。

比价时常见的四个错误

• 只看输入单价：多数任务的输出 Token 单价更高，输出长度对总价影响很大。
• 用平均延迟代表体验：用户感受到的是慢的那部分请求，要看 P95。
• 把总额度当成并发能力：每月额度很高，不代表每分钟能处理同样多的请求。
• 测试样本和真实业务不一致：用简单样本测出的通过率，到真实业务里通常会下降。

常见问题

一个 Token 等于一个汉字吗？

不能用这种固定换算作为计费依据。应以对应模型的计量说明和实际返回的用量字段为准，并确认供应方的结算口径。

首字快就代表整体快吗？

不一定。首字、完整输出和异步任务完成时间是不同指标，应按应用流程分别记录。

必须承诺月用量才能咨询吗？

不需要。可以先提供范围、峰值估计和不确定性，再确认适合的合作方式。具体可用模型、价格与条件以实际沟通为准。

价格变了怎么办？

在合作约定里写明价格变更的通知方式和生效时间。比价表保留报价日期，价格变化后重新计算每个合格结果的费用。