一次调用的价格

输入、输出、缓存各是一档价，输出通常最贵。图片和视频用的又是另一套单位，按分辨率折出的块数或按秒算。

一次调用不是收一笔钱，是分几档单价分别收。看不懂这个结构，选模型时就只能比报价单上那个数字，而那个数字通常不是你最终付的钱。

读完你能回答：

• 一次调用里哪几部分分别计价，哪一档通常最贵？
• 为什么输出比输入贵，贵得有道理吗？
• 图片和视频的账为什么不能套文字那套算法？
• 上线前估预算，按什么结构算才不容易差一个数量级？

一次调用是几档单价分别收

输入价。发给模型的一切都算这一档：系统提示、历史对话、检索到的材料、这次的问题。这是量最大、单价最低的一档，它按 token 算，不按字数算。

输出价。模型生成的那部分，通常是全场最贵的一档，和输入差好几倍。

缓存价。输入里开头一段和上次完全一致的部分，很多厂商按折扣价计费，折扣可以很大。这是成本优化里最直接的一个杠杆，它什么时候生效 单独讲。

所以账单的形状是：输入那一段按输入价或缓存价，输出那一段按输出价。一档便宜但量大，一档贵但取决于它说多少。省钱的两个方向因此完全不同——压输入量和压输出量，用的不是同一套手段。看到「输入每百万 token 多少钱」就下单，等于只看了一半的价目表。

有些厂商还有别的档位：离线批处理更便宜但慢，实时语音按秒或按分钟算，新用户常有一笔免费额度。这些不影响上面的结构判断，只影响你按哪一档去估。

输出那一档为什么最贵

因为这两件事在计算上不是一回事。

输入是一次性读完的：整段提示可以并行处理，而且重复的部分能缓存复用。输出只能一个接一个地生成，每多吐一块，都要把前面的序列重新算一遍。它既是计算量，也是延迟。

这条机制带来三个直接结论：

• 让它少说，同时省钱和省时间。「先给结论，理由压到三行以内」这类约束，是回报最高的一句提示词。
• 同一个问题，不同模型说的字数不一样。便宜的模型可能话痨，多输出一半。单价低不等于总价低。
• 分析类任务天然比判断类任务贵。要它写一大段，就是在买最贵的那一档。

图片不是按张算，视频按时长算

到这里都还是文字。一旦输入里有图片，那套「按 token 数估」的直觉就失效了。

图片不是按文件大小、也不是按张数算的。视觉模型会把图先缩放到它能接受的尺寸，再切成固定大小的小块，每个小块折成若干个 token。所以一张图的价钱主要由它的分辨率决定，而不是由你写了多少字决定。一张图折算下来，常常顶得上一大段文字。claude-vision

贵在理解这件事本身：让模型看懂一张图，所需要的计算量远大于读一段同样字节数的文字——像素携带的信息密度低，但计算密度高。这也解释了另一个常见现象：几张截图加一个问题，总费用会明显超过纯文字的对话。

关键在于它是分档的，不是线性的：

• 缩放到上限就封顶。超过模型能接受的长边之后，图会被缩小，多出来的像素不产生费用。所以把一张手机拍的原图直接丢进去，往往不比压缩过的贵多少——但也没多看到细节。
• 跨过一档就跳到另一个价。长边从八百提到一千六，token 数不是按比例涨，而是整段跳上去。你以为「清晰一点，贵一点」，实际是「贵一档」。
• 多图是叠加的。一次请求带几张图，就按几张分别折算，还都占上下文。截图铺一堆的场景，成本往往在这里失控。

视频又是另一套：按时长计价，通常按秒算，分辨率和时长各自把价格推高一档。openai-pricing 它比图片更贵，而且贵得多。

所以正确的做法是：每种模态用自己那套单位单独估，别指望一个心智模型通吃。文字按 token，图片按分辨率折出的块数，视频按时长。混在一起估，误差一定是数量级的。

还有一条省法比调价更有效：能用结构化信息的地方就别用图。要判断页面元素在哪、有没有被遮挡，一份元素清单比一张截图既便宜又准确；要统计数量，一次查询比让它数图省钱得多。这条判断还有机制那一面的理由，多模态输入讲得更完整。

比价要比同一批请求的总账单

拿两个候选模型比价，正确的问题不是「谁家单价低」，而是同一批真实请求跑下来，谁的总费用低。三件事决定答案。

一、你的输入输出比是多少。工单分类、合同审阅这类链路输入长、输出短；把一批用户反馈汇总成趋势报告则反过来，输出占大头。同一个模型放进这两条链路，综合成本能差出几倍。

二、它话多不多。同样一个问题，一个模型回两百字，另一个回一千五百字——后者如果按字计价，贵的就不只是输出那一档，连后续多轮对话里作为历史重新发出去的输入也跟着涨。

三、缓存吃不吃得到。调用结构稳不稳定，决定前缀能不能命中折扣。前缀稳定的链路，实际成本可能远低于报价。

所以比价比的是同任务下跑出来的账单，不是报价单上的数字。一个输出话痨的便宜模型，很容易比一个安静的贵模型更贵。

估预算要按链路算，不是按单价算

上线前估预算，做法是先把你的调用拆成几条链路，每条链路单独算一遍：

一、算单次调用的构成。一条链路的平均输入有多少、输出有多少、其中可缓存的部分占多少。别用「平均输入几十个 token」这种数去估——多轮对话和逐步推进的任务里，每一步都要把之前的全部内容重新发一遍，输入会膨胀到几千 token。

二、乘调用量，别忘了重试和调试。开发、评测、失败重试都会额外产生调用。预算里留出余量，不要把重试当成意外。

三、把每条链路加起来，再除以总次数，得到综合单价。这个数字才是能拿来比模型的数字。

最后一条经验：把计费埋进日志。每次调用记录输入输出各占多少 token，按天汇总。没有这些数据，预算永远在拍脑袋；有了它们，成本就能像任何运营指标一样被优化。

这一条推不出什么

推不出「所以单价最低的就是最省的」。报价单上那几档价是结构，不是结论；真实成本取决于你的调用结构——输入多长、输出多少、能不能吃缓存、一条链路里带几张图。

也推不出「所以应该尽量少调用」。成本是分子，任务是分母。把一次调用拆成五次来「省钱」，通常更贵；真正该看的是每个成功任务的成本，而不是每次调用的成本。这条区分在成本优化里比任何单价技巧都重要。

具体价格随市场变动，以厂商当前的官方报价页为准。claude-pricing