LLM Pricing Comparison 不能只看 Token 单价
做 LLM pricing comparison 时，不能只比较输入和输出 token 单价。真实成本取决于模型在你的工作流里如何表现：上下文长度、输出长度、重试、缓存支持、推理设置、工具调用和质量要求都会改变最终账单。
建议先用 AI API 价格表 收集当前单价，再用 AI 文本成本计算器 把同一个工作流放到多个候选模型上估算。目标不是找到最便宜的 token，而是找到最便宜且可靠的工作流。
第一步：统一价格单位
不同供应商可能用不同方式展示价格。比较前先统一基础字段：
| 字段 | 为什么重要 |
|---|---|
| 输入 token 价格 | prompt、文档、历史对话和检索上下文都会产生输入成本。 |
| 输出 token 价格 | 回答、JSON、摘要和报告会产生输出成本。 |
| 上下文窗口 | 决定是否需要切片、检索或摘要。 |
| 缓存价格 | 重复 prompt 或上下文时会改变实际成本。 |
| 推理或特殊模式 | 可能改变普通文本输出之外的成本行为。 |
每个价格都要保留来源链接和日期。供应商价格会变，旧假设会让比较失真。
第二步：用同一个工作流比较模型
不要用不同 prompt 比较不同模型。每个候选模型都应使用同一组真实工作流样本。比如比较客服助手时，应包含相同的系统 prompt、检索上下文、用户消息、回答格式和重试策略。
然后估算：
- 平均输入 token
- 平均输出 token
- 月请求量
- 预期重试率
- 缓存命中假设
- fallback 或升级调用行为
这也是计算器比价格表更有用的地方。Token cost calculator 预算指南 解释了为什么单价不等于产品预算。
第三步：加入质量和重试成本
最便宜的模型如果需要更多重试、更长 prompt 或下游校验，整体可能并不便宜。更强模型如果减少失败生成和修复调用，反而可能让某个工作流更省钱。
比较时要记录质量相关成本：
| 成本因素 | 示例 |
|---|---|
| 重试成本 | 重新生成失败 JSON 或弱回答。 |
| 校验成本 | 额外调用模型检查或修复输出。 |
| 人工审核成本 | 输出不稳定导致更多人工复核。 |
| 延迟成本 | 工作流变慢，影响产品可用性。 |
不一定要立刻把每个因素换算成金额，但必须记录哪个模型需要额外步骤才能达到可接受质量。
第四步：区分推理、RAG 和简单文本任务
一个总表很容易掩盖任务差异。选择模型或供应商前，先按任务类型拆开：
- 简单文本任务： 改写、分类、抽取、短答。
- RAG 任务： 长输入上下文、检索片段、引用和 grounded answer。
- 推理任务： 规划、多步分析、编程、数学和复杂决策。
- Agent 任务： 多次模型调用，加上工具、记忆和重试。
推理较重的工作流应放到 推理成本计算器 单独估算。RAG 任务则要包含检索上下文和缓存假设，而不是用一个短 demo prompt 代表真实成本。
第五步：用预算区间做决策
最终比较应该展示区间，而不是一个数字。实用的模型决策表至少包括：
| 场景 | 回答什么问题 |
|---|---|
| 低使用 | 如果上线初期 adoption 慢，会花多少？ |
| 预期使用 | 计划月账单是多少？ |
| 高使用 | 如果功能成功增长，会花多少？ |
| 失败偏多 | 如果重试和长输出增加，会花多少？ |
如果两个模型成本接近，就按可靠性、工作流适配、延迟和运维简单度选择。如果一个模型单价明显便宜但需要很多 workaround，标价可能不是实际节省。
FAQ
比较 LLM pricing 的最佳方法是什么？
统一输入和输出价格，用同一组工作流样本测试多个模型，把上下文长度、输出长度、重试、缓存和质量相关额外调用都纳入，再比较月度场景。
最便宜的 LLM 一定让工作流最便宜吗？
不一定。便宜模型可能需要更多重试、上下文切分、额外校验或人工审核。应比较总工作流成本，而不是只看 token 单价。
多久应该更新一次 LLM 价格比较？
当供应商改价、模型替换、工作流流量变化，或日志显示 token 用量偏离原估算时，都应该更新比较。
总结
LLM pricing comparison 是工作流比较，不是单价截图。统一价格、比较同一请求模式、纳入重试和质量成本、区分任务类型，并用月度预算区间而不是单个 token 单价做最终决策。