选LLM API的六个价格陷阱

你把一张"最便宜的 LLM API"表格 copy 回来，然后按价格列选 model。两周后账单对不上，你却找不到原因。FuturPulse 发表在 Dev.to 上的这篇文章给出了一份读价目表的 checklist，以下是其中可以直接使用的部分。

记录 URL 和日期，不要只记数字

作者的诊断：问题不在于谁在价格上撒谎，而在于比较表格把一个多维度的事物压缩成了唯一一个数字。

按照文章说法，没有来源的价格是谣言，有来源但没有日期的价格是带批注的谣言。供应商会悄无声息地改价目表：没有 changelog，没有通知，只是同一页上出现了一个不同的数字。

所以最低记录单位是三个字段而非一个：model | price | source_url | observed_on。作者说得很清楚，如果你填不出 source_url 用的是 vendor 自己的 pricing 页面——而不是某篇写这个页面的博客——那你就不是有价格，你只是有一个声明。

Input、output 和 cached input 是三个不同的价格

Token output 几乎总是比 token input 贵，通常贵好几倍。Cached input，在有支持的地方，比普通 input 便宜。只有一列的表格正在悄悄选择三种价格中的一种，希望你的 workload 恰好匹配。

文章举了两个实际负载的形态。摘要或提取类任务 input 长、output 短，所以 input 价格占主导。生成内容或运行 agent 则 prompt 短、completion 长、多轮，所以 output 价格占主导——于是"便宜"的 model 在前一种情况下到了后一种情况就变成了贵的。同样的两个 model，结论完全相反，而价目表一个字都没变。

用你自己的日志来计算

作者提议的方法不需要 benchmark，只需要你的日志：取一天真实的请求，计算 input 和 output token 的中位数，再乘以价格。文章里的示例函数按每百万 token 的 USD 价格接收输入，把按缓存比例折算后的 input 部分加上 output 部分，除以一百万得到每次调用的费用，再乘以每天调用数乘以 30 得到月费用。

文章里的示例代码大约十行。作者说，它生成的排名是你的，而表格里的排名是作者以你的名字写的 workload。

两处比较表格完全失效的地方

第一处是 tokenizer。"每百万 token"是一种约定，但 token 不是通用单位——每个 vendor 切分文本的方式不同。对于英文散文，差异小到可以忽略；但对于 code、JSON、非拉丁文字或标点密集的文本则不行。文章没有单独讨论越南语，所以安全做法是在比价前用自己的真实 payload 样本在每个 vendor 的 tokenizer 上跑一遍。

第二处是多模态。图像和音频按每个 vendor 各自的比率换算成 token，取决于分辨率、分块方式，有时还取决于你随请求发送的一个"detail"标志。两个 vendor 可能公布相同的每百万 token 价格，但对同一张图片收费却大相径庭。作者提议唯一诚实的做法：把同样的十个真实 input 发给每个候选者，然后读 response 里的 usage 字段——一个十五分钟的实验。

今天就把 source_url 和 observed_on 两列加到你内部的价目表里。把 input、output 和 cached 分成三列。对于任何"一美元以下"的声明，都要读附带条件——文章提醒这些声明通常没错，但只在特定条件下成立——某个 tier、某个 batch endpoint、某个关于 cached input 的假设，或者某次促销。