LLM 计费内幕：账单上每行数字的含义

几乎每家定价表都列出两个数字：每百万 token 的输入价格和输出价格。但真实账单上有五条或六条线，那些没有出现在标题里的项目，往往才是决定你最终付多少钱的关键。

实际计量的内容

计量的既不是词，也不是字符，更不是请求次数，而是 token——模型的分词器将文本切分成的小于词的单元。英文 prose 大约每 token 0.75 个词，"大约四个字符"是个方便心算的估算，但用来做预算就不行了。代码、JSON、非拉丁文字脚本和长标识符的 token 化效率都比 prose 差，有时差得多，而且不同模型系列的分词器也不同。如果某个数字很重要，就用你实际调用的模型的分词器来计数。

价格按每百万 token 报价，因为按单个 token 报价就全是零了。这个单位值得内化：每百万 token 3.00 美元的价格，相当于每个 token 0.000003 美元，而整个成本工程就是在这个尺度上做算术。这也是为什么用浮点数存储这些金额会出问题。

计费模型完全不在乎你是否"打算"发送某个 token。已读 token 和位于检索文档中间未被阅读的 token 之间没有区别；你写的 system prompt 和框架追加的 tool schemas 之间也没有区别；更不会因为你每次对话轮次都重新发送相同的 3000 token 指令就给你优惠。请求数组里的所有内容都是输入，所有输入都要计费。账单比预期大的最常见原因，不是模型太贵，而是 prompt 变长了。

可能被计费的项目

不是每个 provider 都有所有这些项目，但一旦存在就都不是可选的——它们出现是因为你发送了触发它们的某些内容。

单次请求的公式

以每百万 token 美元为价格 P、以 token 为计数 T，单次请求的成本为：

cost = ( P_in    * T_in_uncached
       + P_cache * T_in_cached
       + P_write * T_cache_written
       + P_out   * (T_visible_out + T_reasoning) ) / 1e6

这一类里的所有技术，都是在攻击其中一个项。Prompt caching 把 token 从第一项移到第二项。缩短答案压缩第四项。级联改变你使用的 P。重来一次就把整个表达式复制一遍。没别的了。

一个计算示例

假设 P_in = $1.00/M、P_out = $5.00/M，一个请求包含 2000 token 的 system prompt、400 token 的用户轮次和 300 token 的回答，无缓存、无推理：

input : 2400 * 1.00 / 1e6 = $0.00240
output:  300 * 5.00 / 1e6 = $0.00150
                     total = $0.00390   (3,900 micro-dollars)

不到四厘，听起来不算什么，直到乘以真实产品发出的请求数量。这种乘法就是构建预测模型的全部，也是最有意思的决策所在。

为什么输出比输入贵

两者价格的比值通常在二到五之间，这不是利润率的问题。读取 prompt 是对整个序列的单一并行传递，受限于硬件能做多少算术运算。而生成是每个 token 一次前向传递，每个 token 都必须把模型权重从内存中搬出来，而且无法并行，因为每个 token 都依赖于上一个。

实际后果是，来自其他类型 API 的直觉在这里是反的。发送更多内容很便宜；要求更多内容很贵。10000 token 的 prompt 配 100 token 的回答通常比 1000 token 的 prompt 配 1000 token 的回答便宜，而且响应也更快。把这个比例记在心里——这就是人们忽略的输出长度这个杠杆的原因。

看清定价表的技巧

计算混合价，而不是标题价。输入:输出 token 比为 r 时，有效的每 token 价格是 (r * P_in + P_out) / (r + 1)。两个输入价格相差 2 倍的模型，一旦代入你实际的比值，可能落在几个百分点之内。

检查推理 token 是否被计费。如果一个模型每输出 token 更便宜、但产出数量是对方的五倍，那它并不更便宜。

在所有其他之前先找到缓存读的乘数。如果你很大一部分输入是稳定前缀，那这一个数字对你账单的移动效果超过模型选择本身。

注意单位。每百万是标准但不是唯一；每千还在用，在预测里出现 1000 倍的误差是常见的，也是个很难解释的尴尬错误。

给请求定价，而不是给 token 定价。唯一有意义的数字是一个你发出的请求的成本，用你实际的 token 数量来算。

关于这些数字出处的最后提醒

每个 provider 都在一个页面上发布价格，每个这样的页面都是快照——给定能力水平的价格会反复变动，通常是向下，模型会被迭代，你去年集成的模型的价格可能已经不是你那个别名现在解析到的模型的价格了。你写下的任何东西都应该记录日期和来源，超过一个季度的文档里引用的任何数字都应该被视为估算值。这就是为什么这个系列里的页面用公式而不是表格来构建：公式一年后仍然正确，而你代入的那个数字已经不对了。

跨 provider 比较同一个模型意味着同时比较所有这些项目，而不是比较标题的那一对，这就是为什么 Multigrid 目录按模型和 provider 并列列出输入、输出和缓存输入价格，以及决定输入项能有多大上限的上下文限制。

---