大模型 Token 计费规则详解知识文档
在使用大模型时，我突然想到为什么token计费要区分输入和输出两类分别计价？ 还有为什么输入token还要进一步划分缓存命中和缓存不命中两种情况执行不同计费标准。
0、先科普几个绕不开的基础概念
在回答两个核心问题之前，先把几个高频出现的"行话"用大白话讲清楚，后面就不卡壳了。
1. 什么是 Token？
Token 是大模型处理文本的最小计费单位，可以理解为"模型眼里的一个字符块"。
- 它不完全等于"一个字"或"一个单词"：
- 英文里 1 个 token ≈ 0.75 个英文单词（"hello" 是 1 个 token，"unbelievable" 可能被拆成 3 个）
- 中文里 1 个汉字 ≈ 1–2 个 token
- 为什么不按字符或字数收费？ 因为模型内部本来就是按 token 在算的，token 数才真实反映了计算量。
粗略换算：1000 个 token ≈ 750 个英文单词 ≈ 500 个汉字。
2. 什么是 GPU 和算力？
- GPU：一种专门做大规模并行计算的芯片，是跑大模型的"主力发动机"。一张高端 AI GPU（比如 H100）市场价几十万人民币，租用价按秒计。
- 算力成本：跑模型本质上是在"烧电 + 烧 GPU 时间"。模型每多算一步，电表和折旧表就多跳一格。计费规则的本质，就是把这些真实成本按公平的方式摊给用户。
3. 什么是显存（VRAM）？
- GPU 自带的高速内存，用来临时存放模型权重和计算中间结果。
- 显存非常贵且容量有限（单卡通常 40–80GB）。显存里能塞下什么、能复用什么，直接决定了成本结构——这点在后面讲缓存时是核心。
4. 什么是 Prompt？什么是"上下文"？
- Prompt（提示词）：你发给模型的全部输入，包括系统设定、历史对话、当前问题、参考资料等。
- 上下文窗口（Context Window）：模型一次能"看进眼里"的最大 token 数，比如 128K、200K。超过这个长度的内容会被截断。
- 关键点：每次对话，模型看到的"输入"通常不只是你刚打的那句话，而是整段历史 + 系统提示 + 资料。这就是为什么多轮对话越聊越贵。
一、为什么 token 计费要区分"输入"和"输出"分别定价
核心结论
输入和输出消耗的算力差着数量级，所以单价也差着数量级（输出价通常是输入价的 3–5 倍，部分推理模型甚至 10 倍以上）。
1.1 输入阶段：模型在"读题"——可以并行，便宜
当你把一段 prompt 发给模型时，模型做的事情叫 Prefill（预填充）：
- 一次性把所有输入 token 并行地送进神经网络。
- "并行"是关键——GPU 最擅长的就是同时算一大批数据，几千个 token 可以在一两秒内全部处理完。
- 这个阶段的产物是一份叫 KV Cache（键值缓存） 的中间结果，可以理解为"模型读完题后写在草稿纸上的笔记"。
类比：让你用 5 秒钟扫一眼一整页 PPT，眼睛是并行接收信息的，不累。
1.2 输出阶段：模型在"答题"——必须串行，昂贵
模型生成回复时做的事情叫 Decode（解码），它有一个绕不开的物理限制：
- 必须一个 token 一个 token 地往外蹦，不能并行。
- 每生成一个新 token，都要做一次完整的神经网络前向计算，输入是"原始 prompt + 已经生成的所有 token"。
- 也就是说，生成第 100 个字时，模型实际上要参考前面 99 个字 + 你最初的 prompt，整体过一遍网络。
类比：让你逐字手写一篇 500 字作文，每写一个字都要在脑子里回顾"我前面写了啥、整体思路是啥"，比扫 PPT 累几十倍。
1.3 成本对比一目了然
| 维度 | 输入（Prefill） | 输出（Decode） |
|---|---|---|
| 计算模式 | 并行（一次算一大批） | 串行（一个一个算） |
| GPU 利用率 | 高（吃满算力） | 低（受内存带宽限制） |
| 单 token 耗时 | 极短（毫秒级） | 较长（每个字 10–50ms） |
| 显存占用 | 一次性峰值 | 持续占用直到生成结束 |
| 典型单价 | 便宜（基准价） | 贵 3–5 倍 |
1.4 商业逻辑：为什么必须分开计价？
如果搞"一口价"，只有两种结果：
- 定低了 → 厂商在输出端赔本，长期不可持续，要么涨价要么关停。
- 定高了 → 只发送短输入、读长文档的用户被多收钱，不公平，会被竞品挖走。
分开定价 = 价格匹配真实成本 = 用户和厂商都觉得公平。这是市场竞争自然演化的结果，现在所有主流厂商（OpenAI、Anthropic、Google、字节、阿里、DeepSeek）都遵守这套规则。
二、为什么输入 token 还要分"缓存命中"和"缓存不命中"
核心结论
重复计算 = 重复烧 GPU = 重复烧钱。如果某段输入模型刚刚算过，把结果存起来直接复用，成本骤降，省下的钱以折扣形式返还给用户，皆大欢喜。这套机制叫 Prompt Caching（提示词缓存）。
2.1 缓存的到底是什么？
缓存的不是"文字本身"，而是前面提到的 KV Cache（模型读完输入后写下的草稿笔记）：
- 当你第一次发送某段 prompt，模型做完 Prefill，会生成一份 KV Cache。
- 厂商把这份 KV Cache 暂存在显存或高速存储里（通常保留几分钟到几小时）。
- 如果短时间内有另一个请求，开头部分和上次完全一样，就可以直接把上次的 KV Cache 捞出来用，跳过这部分的计算。
重点：缓存只在"前缀完全一致"时才命中。哪怕只改一个字，从那个字开始往后都必须重算。所以稳定不变的内容（系统提示、知识库文档）一定要放在 prompt 最前面。
2.2 命中 vs 不命中：成本差异
| 场景 | 模型做了什么 | 成本 | 用户价格 |
|---|---|---|---|
| 缓存不命中（Cache Miss） | 老老实实把每个输入 token 跑一遍神经网络，生成新的 KV Cache | 全额 GPU 算力 | 全价（基准价） |
| 缓存命中（Cache Hit） | 直接读取上次存好的 KV Cache，跳过计算 | 几乎只剩"读取存储"的成本 | 打折（通常 1–3 折，部分厂商低至 0.5 折） |
2.3 用一个生活类比说清楚
去餐厅点菜：
- 第一次点一道复杂菜：厨师从洗菜、切菜、调料开始做，耗时 30 分钟，全价收。
- 老顾客 10 分钟后点同款：后厨还留着半成品，加热摆盘 3 分钟出餐，打 2 折。
- 但如果你说"我要同款但去掉香菜"——前面准备好的半成品作废，又得重做，还是全价。
这就是为什么"前缀必须完全一致"才能命中缓存。
2.4 哪些场景特别能省钱？
缓存命中收益最大的典型场景：
长系统提示词（System Prompt） 很多 Agent 应用的系统提示动辄几千 token（角色设定 + 工具说明 + 规则约束），每次对话都重复发送。缓存命中后，这几千 token 几乎不要钱。
多轮对话 每一轮对话都要把"之前所有历史"重新发给模型。第 N 轮时，前 N-1 轮的内容如果命中缓存，成本大幅下降。
RAG（检索增强生成）拼接的长文档 把一份 PDF 当作背景知识反复提问。第二次提问时，那份 PDF 部分命中缓存。
批量处理同模板任务 比如"基于以下模板分析 1000 份简历"——模板部分每次都命中。
2.5 商业逻辑：为什么是双赢机制？
| 角色 | 收益 |
|---|---|
| 用户 | 重复内容大幅省钱，长 prompt 应用（Agent、RAG）成本降一个量级 |
| 厂商 | 显存利用率提高、同样 GPU 能服务更多请求、整体毛利改善 |
| 生态 | 引导开发者把稳定内容放前面、按缓存友好的方式设计 prompt，进一步压低全行业成本 |
关键洞察：缓存定价不是营销噱头，而是把"省下的算力"以折扣形式直接还给用户。厂商之所以愿意这么做，是因为不这么做的话，竞争对手会先做，然后抢走客户。
2.6 实战小贴士（写 prompt 时怎么省钱）
- ✅ 稳定内容（系统提示、知识库、Few-shot 示例）放最前面
- ✅ 动态内容（用户问题、当前数据）放最后
- ❌ 不要在 prompt 中间插入随机变量（时间戳、UUID），会让后面的内容全部失效缓存
- ✅ 多轮对话保持历史结构稳定，不要重排消息顺序
三、把两套规则放一起看：一次完整的计费链路
假设你向某模型发送一个请求：
[系统提示: 5000 tokens] + [对话历史: 3000 tokens] + [当前问题: 200 tokens]
→ 模型生成回复 [800 tokens]如果上一轮对话刚结束 2 分钟（缓存还在）：
| 部分 | Token 数 | 计费类型 | 假设单价 | 小计 |
|---|---|---|---|---|
| 系统提示（命中缓存） | 5000 | 缓存命中输入 | $0.30 / 百万 token | $0.0015 |
| 对话历史（命中缓存） | 3000 | 缓存命中输入 | $0.30 / 百万 token | $0.0009 |
| 当前问题（新内容） | 200 | 缓存不命中输入 | $3.00 / 百万 token | $0.0006 |
| 模型回复 | 800 | 输出 | $15.00 / 百万 token | $0.0120 |
| 合计 | $0.0150 |
如果没有缓存机制，同样请求的成本会是：
- 全部 8200 输入 token × $3.00 + 800 输出 × $15.00 = $0.0366
缓存让这次请求便宜了约 59%。 这就是为什么大型 Agent 应用、客服系统都在拼命优化 prompt 缓存命中率。
四、一句话总结
大模型计费的底层逻辑只有一句话：让价格如实反映 GPU 实际烧掉的算力。
- 输入便宜、输出贵 → 因为读题并行、答题串行，成本天差地别。
- 缓存命中打折 → 因为复用上次的中间结果，几乎没烧 GPU。
理解了这两点，你就能看懂市面上所有主流大模型的定价表，也知道怎么写 prompt 最省钱。