选大模型API别只看单价，按业务调用结构折算成本更准

大模型API成本对比的核心不是找一张“每百万 token 最便宜”的价目表，而是把你的业务调用结构套进各家计费规则，算出单次请求成本和月度可预期支出。
只比较输入单价，很容易在输出比例高、缓存命中低或重试频繁的场景里得出相反结论。

先统一比较口径，再收集价格

做对比前先固定四类参数，否则不同厂商的报价无法放在同一张表里：

• 输入输出比例：一次对话或任务中，提示词 token 与生成 token 各占多少。输出通常比输入贵，比例不同结论会变。
• 缓存命中率：部分 API 对重复前缀提供缓存计价，命中部分和未命中部分单价不同。命中率低的业务，缓存折扣基本用不上。
• 重试与失败率：超时、限流、格式错误导致的重复调用会计入账单，对比时要把重试系数乘进去。
• 并发峰值：按量计费看总量，但限流会影响重试率；包月或预留吞吐则要看峰值是否被套餐覆盖。

价格以各厂商控制台或官方计费文档为准，本文不列具体数字，因为价格和模型版本会调整。
你只需要记录当前可查到的输入单价、输出单价、缓存单价和免费额度规则，并注明查询日期。

用一张估算表算出单次请求成本

建议在表格里按业务场景建行，每行对应一个典型请求。
字段可以这样设计：

| 字段 | 说明 |
| --- | --- |
| 场景名 | 如客服问答、文档摘要、代码补全 |
| 平均输入 token | 从日志或样本中统计，不用主观估计 |
| 平均输出 token | 同上，注意不同模型输出长度可能不同 |
| 缓存命中比例 | 重复系统提示词、固定知识前缀占比 |
| 单次重试系数 | 成功请求数 ÷ 总请求数，失败重试也计费 |
| 输入单价 | 按厂商当前报价填入 |
| 输出单价 | 按厂商当前报价填入 |

单次成本可以按下面的思路估算：

单次成本 = 输入token × 输入单价 × (1 - 缓存命中比例 × 缓存折扣)
         + 输出token × 输出单价
         + 重试带来的额外调用成本

这里的“缓存折扣”要按厂商规则换算，不同平台对缓存命中的计价方式不完全一样。不要直接把缓存命中率当成折扣比例，先确认命中部分具体按什么单价计费。

对比时最容易算错的三个地方

只比输入单价。 很多业务输出 token 占比不低，输出单价差异会直接改变排名。
把输入输出比例固定成业务真实值，再比较总成本。

忽略系统提示词和上下文重复。 固定角色设定、工具定义、知识片段每次都会作为输入计费。
长系统提示词场景下，缓存命中率对成本影响很大，需要单独统计。

用平均值掩盖长尾。 平均输入 token 可能被少数超长请求拉高。
对比时至少看平均和中位数两个值，长文档场景还要看 P90 输入长度，避免预算按平均值做、账单按长尾出。

小流量验证账单口径

估算表只能做初筛。
选定两三家候选后，用同一批真实样本各跑一轮小流量测试，重点核对三件事：

• 控制台账单里的 token 计数是否和本地统计接近，差异大时检查分词口径和是否包含系统提示词。
• 缓存命中是否按预期出现，重复前缀是否真的被识别。
• 限流和超时是否导致额外重试，重试量是否体现在账单里。

验证时保留请求日志、响应中的 usage 字段和账单截图，按同一时间段对齐。没有经过这一步，成本对比只能算报价对比，不能算业务成本对比。

选型时怎么用对比结果

如果业务输入长、输出短、重复前缀多，优先看缓存计价和输入单价；
如果输出占比高，重点比较输出单价和最大输出长度限制；
如果并发峰值明显，除了单价还要确认限流阈值和预留吞吐方案。

成本只是选型的一列。
把稳定性、延迟、上下文长度和合规要求放在同一张表里，再结合成本结论做决定。
只按最低单价选，后期可能因为重试、限流或输出质量不足产生更高总成本。

常见疑问：免费额度能不能直接算进对比？
可以记录，但不要用它推算长期成本，免费额度通常有有效期和调用限制。
不同模型价格能不能直接比？
可以比，但要用同一业务样本和同一输入输出比例，否则比较的是两个不同场景。