为什么 LLM API 的输出 token 比输入 token 贵 4-8 倍

随便打开任意一家主流 LLM API 的定价页面——OpenAI、Anthropic、Google，哪家都一样——你会发现同一个规律反复出现：输出 token 的价格是输入 token 的好几倍。而且不是一点点溢价。在目前的各家模型中，这个比例稳定落在 4 到 8 倍之间。这不是某个厂商特有的定价怪癖，而是这些模型实际运行方式的直接结果。

真正的原因：输入是并行的，输出是串行的

处理输入 token——你的 prompt、系统消息、对话历史——只需要一次前向计算。模型一次性读入全部输入，并行计算它们之间的注意力。现代 GPU 非常擅长这种批量并行计算，所以一个3000 token 的 prompt 和一个300 token 的 prompt，实际消耗的计算时间并不会按 token 数量成比例增加——跑一次模型本身的开销才是主要成本，输入的长度反而是次要因素。

生成输出 token 则完全不同。每一个新 token 都依赖于它前面的所有 token，包括模型刚刚生成出来的那些——所以回复的第500个 token 必须等第499个 token 存在之后才能算出来。这就逼出了一个串行循环：每生成一个输出 token 就要跑一次前向计算，一次接一次，整个序列没法并行化。生成500个输出 token，意味着要把模型连续跑500遍，而不是一遍。

这种计算量上的不对称——输入是一次并行计算，N 个输出 token 需要 N 次串行计算——正是为什么不管公司、模型架构还是所在地区，各大厂商的定价看起来都一样。这与其说是一个商业决策，不如说是底层计算成本被直接转嫁到了价格上。

这对你写 prompt 意味着什么

实际结论很直白：一段啰嗦的模型回复，成本会不成比例地高于一个长 prompt 配一个简短答案的组合，即便两者总 token 数看起来差不多。如果你想压缩 API 花费，精简输出长度通常比精简输入长度每 token 省得更多。

几个具体做法：

• 明确限制回复长度。 系统提示里加一句“用一段话回答”，或者设置 max_tokens 上限，对成本的影响往往比精简你自己的 prompt 更大。
• 要结构化输出而不是散文式回答。 一个包含三个字段的 JSON 对象，通常比用句子解释同样内容要短得多，而且对下游同样好用。
• 不要为了省输出而在系统提示里惜字如金。 一个更长、更精确的系统提示（输入，便宜）如果能稳定得到一个简短正确的答案（输出，贵），通常比一个简短模糊的提示让模型用一长串话来试探要划算。
• 对高频、低复杂度的输出用更便宜的模型。 如果任务不需要旗舰模型级别的推理能力——比如分类、抽取、简短回复——入门档模型的输出单价往往能低一个数量级。

算出具体要花多少钱

这个比例解释了输出为什么更贵，但具体的美元数字取决于你用的是哪个模型，以及请求两端各自实际消耗了多少 token。由于输入/输出的比例——以及两者之间的倍数——确实因模型而异（入门模型和旗舰模型用的倍数不一样），想知道自己的真实成本，唯一靠谱的办法就是把实际数字代入对应的模型去算。

CodeKitHub 的LLM API 定价计算器正是做这件事：选一个模型，输入你的输入和输出 token 数，它会给出输入成本、输出成本和合计——如果你大致知道每月请求量，还能给出月成本预估。如果你不确定自己的 prompt 实际用了多少 token，AI Token 计数器工具会用真实分词器给出精确数字，而不是靠字符数粗略估算。

两个工具都完全在你的浏览器里运行——不需要 API key，不需要账号，什么都不会发送出去。