问看到价格页后我会做的三步核验？

# 看到价格页后，我会做的三步核验

这是一次个人使用后的经验整理。第一次看多模型 API 的价格页时，最容易做的事情是挑一个倍率最低的渠道；但实际接入后，我更关心这条价格能不能在自己的任务里复现。

下面这张截图展示了多个渠道或分组的倍率。它很适合帮我缩小候选范围，但我不会把其中任何一个数字直接写成“长期最低价”或“固定成本”。页面、模型、渠道、缓存规则和活动都可能变化，截图只能说明对应时点展示过什么。


## 第一步：确认比较前提一致

比较两个渠道前，我会先固定模型、提示词、最大输出、工具定义和网络环境。否则一个渠道多输出了几百 Token，或者另一个渠道换了模型，最终费用再低也没有可比性。

长上下文场景还要固定前置上下文。缓存输入是费用的一部分，冷缓存和热缓存如果混在一起，结论很容易失真。

## 第二步：把最终账单拆开

我会记录输入总量、缓存输入、未缓存输入、输出 Token、实际倍率和最终费用。这样可以区分费用变化是由哪里造成的：

- 提示词或上下文变长；

- 缓存没有命中；

- 输出没有限制；

- 渠道或分组发生变化；

- 重试让一次业务动作产生多次调用。

只看“每百万 Token 单价”或“倍率”时，这些差异都很难暴露出来。

## 第三步：把成本和体验一起看

一个渠道即使费用更低，也可能不适合需要即时反馈的交互任务；反过来，更快的首字时间也不一定值得为所有批处理任务付出更多成本。

所以我会按业务分开决定：

| 场景 | 优先验证 |

| --- | --- |

| 在线聊天与代码补全 | 首字时间、错误率、输出质量 |

| 长文档分析 | 缓存输入、完整耗时、最终费用 |

| 离线批处理 | 成功率、吞吐、重试后成本 |

用一组真实任务跑完这三步，才能知道一个价格页上的数字是否适合自己的项目。本文是个人测试和截图阅读的整理，不构成价格或性能承诺；具体以实际调用时的页面和账单为准。