大模型 API 的计费方式里，最容易让人困惑的一点，就是为什么几乎所有平台最后都会落到 token 这个单位上：大模型为什么按 token 收费，而且不同 token 还会有不同价格。
很多人刚接触模型 API 时，最容易困惑的不是模型能力，而是账单。明明只问了几个问题，为什么费用会涨得这么快？为什么输入便宜、输出更贵？为什么上下文一长，成本就开始明显失控？
如果把这件事讲简单一点，可以先记住一句话：模型收费，买的不是“一次回答”，而是整段推理过程中消耗的计算与带宽资源。
1. 什么是 token
在大模型计费里，token 不是“字数”也不是“单词数”，而是模型处理文本时使用的切分单位。
它可能是：
- 一个汉字
- 一个英文单词的一部分
- 一个标点符号
- 一小段常见词组合
所以 API 平台通常不会按“每句话”或“每次请求”收费，而是按模型实际读入和生成的 token 数量收费。
这比按请求次数计费更合理，因为同样是一次请求，可能只输入 20 个字，也可能塞进去 20 万 token 的上下文，两者消耗完全不是一个量级。
2. 为什么输入和输出要分开定价
现在大多数模型 API，都会把价格拆成两部分：
- 输入 token 价格
- 输出 token 价格
而且常见情况是：输出 token 比输入 token 更贵。
原因并不难理解。
模型处理输入时，本质上是在“读”和“编码”已有内容；但生成输出时，它需要一步一步预测下一个 token，再继续预测下一个 token。这个过程不只是读取，而是持续进行推理和采样，所以通常更耗算力。
你可以把它粗略理解成：
- 输入：像把材料递给模型
- 输出：像让模型现场写答案
“现场写”的计算成本，通常比“把材料读一遍”更高，所以输出价格更贵是很常见的设计。
3. 为什么上下文越长，费用越容易失控
很多人以为自己只是在“多贴一点背景资料”，但从模型账单的角度看，这件事的影响往往比想象中大。
原因在于：模型每次调用时，通常都要重新处理当前请求里带进去的整段上下文。
也就是说，如果你当前请求里包含：
- 系统提示词
- 历史对话
- 工具返回结果
- 长文档片段
- 代码文件内容
这些内容都会一起进入输入 token 计费。
所以真正让账单变大的，往往不是最后那一句提问，而是它前面拖着的一大串上下文。
当对话轮数增加、工具调用变多、历史消息不断回灌时，token 成本就会被一轮轮放大。
4. 工具调用为什么特别容易涨 token
在 Agent、代码助手、工作流自动化这类场景里，token 消耗通常比普通聊天高得多。
问题不只是“模型回答了一段话”，而是整个流程里会不断出现这些内容：
- 读文件
- 看日志
- 调接口
- 返回 JSON
- 执行工具结果再回填给模型
每一次工具调用的结果，只要被重新塞回下一轮上下文，就会继续变成新的输入 token。
这就是为什么很多开发者会发现：
不是模型本身单价特别离谱，而是工作流把 token 账单一层层叠上去了。
例如一个编码 Agent 连续做下面这些事：
- 读取项目结构
- 打开几个源码文件
- 跑一次测试
- 把报错日志喂回模型
- 再读取更多相关文件
每一步都可能让后续请求背着更长的上下文继续跑。这样即使单价不变，总账单也会很快增长。
5. 为什么同样是模型，价格会差很多
不同模型的 token 价格差异，背后通常不只是“厂商想卖贵一点”，而是和几个因素直接相关：
- 模型规模
- 推理效率
- 上下文长度
- 部署成本
- 目标市场
模型越大、激活参数越多、推理链路越复杂，单次生成一个 token 的成本通常就越高。
如果模型还支持超长上下文、复杂推理、工具调用优化，那它的基础设施压力也会进一步增加。
所以定价本质上是在覆盖几类成本：
- GPU / 加速卡资源
- 显存占用
- 推理延迟
- 网络与服务稳定性
- 峰值并发能力
便宜模型不一定差，贵模型也不一定适合所有场景。很多时候价格差，反映的是“这类能力大概值多少基础设施成本”。
6. 为什么缓存输入会更便宜
不少模型平台现在会提供：
- cached input
- prompt caching
- prefix caching
这类能力的共同思路是：如果一大段输入已经算过，不要每次都从头按原价重算。
比如一个固定 system prompt、固定工具说明、固定长文档前缀，如果每轮都完全重复发送，平台就有机会把其中一部分计算缓存下来。这样同样是输入 token，缓存命中的部分就可以按更低价格计费。
这也解释了为什么很多 API 价格页会出现三档甚至更多价格：
- 普通输入
- 缓存输入
- 输出
它们反映的不是文字内容不同，而是底层计算是否可以复用。
7. “便宜 token”为什么不等于“总成本更低”
很多人看到某个模型“每百万 token 超便宜”，第一反应是总成本一定更低。实际上不一定。
因为总账单大致等于：
token 单价 × 实际消耗量
而实际消耗量又会被很多因素放大：
- 提示词写得太长
- 历史消息不清理
- 工具结果回填过多
- 输出太啰嗦
- 一个任务反复重试
所以真正决定账单的，通常不是单价一个变量，而是：
- 模型单价
- 每轮输入长度
- 每轮输出长度
- 调用次数
- 工作流设计
这也是为什么“低单价模型”在某些 Agent 任务里，最后总费用仍然可能不低。因为它可能需要更多轮交互、更多补充上下文、更多失败重试。
8. 开发者该怎么估算 token 成本
如果你想在项目里更稳地控制预算，可以先用一个很朴素的估算方式：
- 统计平均每次请求的输入 token
- 统计平均每次请求的输出 token
- 估算一个任务会调用多少轮
- 再乘上对应模型单价
举个思路上的例子：
- 每轮输入
8k tokens - 每轮输出
1k tokens - 一个任务跑
10轮
那它真正消耗的就不是“一次问答”，而是：
- 输入约
80k tokens - 输出约
10k tokens
如果中途还有日志、工具结果、文件内容不断追加，总量还会继续上升。
所以做预算时，最好不要只看单轮，而要看一个完整任务闭环到底会吃掉多少 token。
9. 怎么实际控制账单
如果你已经在用 API 或 Agent，下面这些做法通常最有效：
- 缩短 system prompt，避免重复废话
- 定期裁剪历史消息
- 工具返回结果只保留必要字段
- 长文档先检索，再喂局部片段
- 控制输出长度，避免模型无上限展开
- 对高价值任务用贵模型，低价值任务用便宜模型
很多时候，省钱最有效的方式不是一味换更便宜的模型，而是先把工作流里无意义的 token 消耗砍掉。
10. 这件事真正该怎么理解
大模型 token 定价，说到底是在给“模型读了多少、想了多少、写了多少”计费。
它不是传统软件那种按账号、按次数、按包月就能完全描述的资源模型，因为模型调用本身就是一个动态计算过程。你塞进去的上下文、拉起的工具、要求的输出长度，都会直接影响成本。
所以理解 token 定价，最重要的不是背价格表，而是先建立一个直觉：
- 长上下文会涨输入成本
- 长输出会涨生成成本
- 工具链会放大总 token
- 缓存和工作流设计会明显影响账单
只要把这几个点想清楚，大多数模型 API 的价格结构其实都不难理解。