大模型的输入价、输出价、缓存价怎么读？别只看一个数字
大模型的价目表至少有三列价：输入价、输出价、缓存命中价，很多家还要按上下文长度分档。只记住一个「多少钱」的数字，选型基本会错——因为你的账单是这几列按你的用量结构加权出来的，不是任何单独一列。
这篇教你读价目表。想直接看逐条带官方来源的表，去价格对比表。
第一列：输入价
输入价按你发过去的 token 数计。发过去的内容包括 system prompt、工具定义、few-shot 示例、检索片段、对话历史和用户输入——不只是用户那句话。
输入价是长文档、长 system prompt、多轮会话场景的成本主力。判断你是不是输入敏感，看一个比值：单次请求的输入 token 除以输出 token。大于三，你就是输入敏感型，选型时优先看这一列。
第二列：输出价
输出价按模型生成的 token 数计，通常明显高于输入价，倍数因家而异。
这意味着写作、写代码、长回答这类场景，成本大头在输出侧。也意味着 max_tokens 这个参数直接和钱挂钩——设得越大，模型越可能一路写下去。
一个常见误判：看到某家输入价特别低就选它，结果自己的场景是短输入长输出，输出价高得离谱，总账反而更贵。所以别只看一列，把两个数一起代进月成本估算器。
第三列：缓存相关的价
提示缓存的价目通常拆成两部分，读的时候要分清：
缓存命中价（读缓存）：当请求前缀命中缓存时，这部分输入按远低于标准输入价的折扣计。折扣力度各家不同，但普遍是数量级级别的便宜。
缓存写入价（建缓存）：有些厂商建缓存要额外收费，价格可能略高于标准输入价；有些厂商按缓存存活时长收存储费。
所以缓存不是无脑开就赚。判断标准是复用频率：同一个前缀在缓存有效期内被复用得越多，越划算；如果每个请求前缀都不一样，写入费反而是净亏。
分档：同一个模型有好几个价
不少厂商按上下文长度分档：短提示走低档，超过阈值跳到高档，超长再跳一档。国产厂商这方面尤其常见，有的还额外区分推理模式和普通模式。
读表时要问自己一句：我的典型请求落在哪一档？ 拿宣传里那个最低档价去做预算，如果你的场景经常是长上下文，会低估不少。
这也是为什么本站的价格对比表对区间价一律取下限并在备注里写全区间——为了可排序，但提醒你按自己的档位重估。
峰谷、Batch、Preview：还有三种价格变体
峰谷定价：有厂商公布高峰时段单价上浮的政策。如果你的业务恰好集中在高峰时段，要按上浮后的价估；能错峰的批量任务则可以主动挪到低谷。
Batch 折扣：离线批处理通常打五折。能异步的活别走实时接口。
Preview / 实验版：预览阶段的模型价格可能随时调整，甚至转正式版后变价。用在生产上要有心理准备，别把长期预算建在一个 Preview 价格上。
为什么单价一样，账单还能差三成
两个原因。
一是分词器差异。 各家分词器切法不同，同样一段中文可能差一两成 token。单价相同的两家，实际计费 token 数不同，账单自然不同。这一项没法从价目表看出来，只能拿同一段文本分别调一次、读 usage 字段对比。
二是重试和失败。 限流触发的重试、格式不合规的重跑，都照常计费。限流额度小的厂商，实际有效成本会被重试推高。
所以比价的终局动作永远是：拿你自己的真实请求，在候选厂商各跑一批，比总账单。价目表是用来筛掉明显不合适的，不是用来定生死的。
把价目表翻译成「你的实际单价」
价目表上的数字是标准档，你真正付的是一个加权平均价。算法是这样的：
你的实际输入均价 = 缓存命中部分 × 缓存价 + 未命中部分 × 标准输入价（若跨档，按各档实际占比加权）
你的实际总价 = 实际输入均价 × 月输入 token + 输出价 × 月输出 token，最后再乘以（1 + 重试系数）
举个方向性的例子：如果你的输入里有六成是固定前缀且缓存命中稳定，而缓存价只有标准价的零头，那么你的实际输入均价会明显低于表上那个数——低到什么程度，取决于命中率和折扣力度。反过来，如果你的请求经常落到高档区间，实际均价会高于表上首行。
结论是：两个团队用同一个模型，实际单价可以差出很多。 所以看到别人说「这家便宜」时，先问他的用量结构和你像不像。
三个最容易读错的地方
第一，单位。 有的厂商按每千 token 报价，有的按每百万 token。两者差一千倍，是所有比价失误里最致命的一种。看到一个「1.5」，先确认它是每千还是每百万。
第二，「低至」两个字。 宣传语里的「低至 X 元」通常指的是最便宜的那个轻量档模型、最短的那档上下文、或者缓存命中后的价格。用它做预算必然低估。找表格里对应你实际模型和档位的那一行，别用宣传数字。
第三，输入输出是否同价。 少数场景下（比如某些包月套餐或折算规则）会给一个统一价，多数按量计费是分开的。看到只给一个数字的表，先确认它是不是把两者合并了，合并口径的数字不能直接和分开口径的比。
价目表之外，还有几项影响真实花费的条款
比价时容易只盯数字，忽略下面这些写在文档角落里的规则，它们同样会改变你的账单。
最小计费单位。 有的接口按请求计一个起步量，短请求特别多时这一项会显著抬高实际均价。高频短调用的场景要特别留意。
多模态内容的折算规则。 图片、音频、视频输入通常不是按 token 直接算，而是按分辨率、时长折算成等效 token。同样一张图，不同厂商折算出的 token 数可能差好几倍，光看文本单价完全看不出来。
思考 / 推理过程是否计费。 带显式推理的模型，中间推理内容有的计入输出 token，有的单独计价。这部分长度不可控，是预算里最容易失控的一项。
额度有效期与结转规则。 预充值的额度是否有有效期、用不完是否结转，直接影响你该一次充多少。
这些条款一般不在价目表首屏，需要点进计费说明文档里翻。麻烦，但比事后解释账单省事得多。
一个读表的检查清单
看到一张价目表，按这五问过一遍：
- 单位是每千 token 还是每百万 token？（差一千倍，最容易翻车的地方）
- 币种是什么？跨币种比之前先统一。
- 这个价对应哪一档上下文长度？
- 有没有缓存命中价、Batch 折扣、峰谷政策？
- 数字是哪一天从官方定价页核的？
最后一问最重要。网上多数「价格总表」不标来源和日期，照着做完预算才发现价格早改了。本站的表每一行都带官方链接和核对日期，就是为了让你能自己点开验一遍。
想按厂商看计费口径，读国产大模型 API 价格对比；想把这些价换算成月成本，用月成本估算器。