这两者的划分，背后对应的是大模型在硬件（GPU）上的计算模式差异以及商业成本考量。我们可以把它们拆开来看：
一、 为什么 Token 分为“输入”和“输出”？
大模型处理输入和生成输出时，GPU 的工作状态是完全不同的。这在技术上对应大模型推理的两个核心阶段：Prefill（预填充） 和 Decode（解码）。
结合上图，我们可以很直观地看到这两者的区别：
1. 输入 Token（对应左图：Prefill 阶段）
- 工作原理： 当你发送一段提示词（Prompt）给模型时，模型会一次性、并行地读取所有输入 Token。它会计算这些 Token 彼此之间的关联性，并把计算结果存成一种叫做 KV Cache（键值缓存） 的临时数据。
- 硬件特点： 因为是并行处理，GPU 的成千上万个核心可以同时满载运转。这个阶段属于算力受限（Compute-bound），GPU 的计算效率非常高。
2. 输出 Token（对应右图：Decode 阶段）
- 工作原理： 模型吐出回复时，必须一个字一个字（Token 逐个）地往外蹦（自回归）。每生成一个新的 Token，GPU 都必须把之前所有 Token 的 KV Cache 从显存里“读”出来，算完新 Token 后，再把新 Token 的结果“写”回显存。
- 硬件特点： 每次只算一个 Token，GPU 强大的算力根本用不满，大量的时间都浪费在了反复读写显存的等待中。这个阶段属于显存带宽受限（Memory-bandwidth bound）。
总结： 生产一个“输出 Token”花的时间和对硬件的消耗，远比处理一个“输入 Token”要高（通常商业定价上，输出 Token 比输入 Token 贵 3~5 倍）。因此，API 必须把它们分开计费。
二、 输入为什么又分为“缓存命中”和“缓存不命中”？
既然输入阶段大费周章算出来的 KV Cache 这么有用，如果用户在同一个长对话里反复聊天，或者一个 AI Agent（智能体）频繁读取同一段几万字的系统提示词/代码库，每次都让 GPU 重新对这几万字做一次 Prefill 计算，既慢又极其浪费资源。
为了解决这个问题，大模型厂商推出了 Context Caching（上下文缓存） 技术：
1. 缓存命中（Cache Hit）
- 发生场景： 你发过去的提示词开头部分，跟之前发过的、或者服务器上已经缓存过的内容完全一致（比如同一个多轮对话的历史记录、或是固定不变的巨量 Prompt）。
- 技术表现： 服务器发现这部分内容的 KV Cache 已经在显存/内存里了，于是直接拿来复用，跳过了这部分 Token 的并行计算过程。
- 用户感知： 模型的首字延迟（TTFT，即吐出第一个字的速度）暴降；同时因为帮服务器省了算力，厂商会给你极大的折扣（通常缓存命中的 Token 价格只要原价的 1~5 折）。
2. 缓存不命中（Cache Miss）
- 发生场景： 你发了一段全新的问题，或者之前的对话缓存因为长时间没用，被服务器的清理机制踢出了显存。
- 技术表现： 模型无法作弊，必须老老实实从头把这部分 Token 跑一遍 Prefill 流程，重新计算完整的 KV Cache。
- 用户感知： 按照正常的标准输入价格计费。
| Token 类型 | 硬件瓶颈 | 处理方式 | 计费相对权重 |
|---|---|---|---|
| 输入 - 缓存命中 | 几乎不占算力 | 直接读取现成缓存 | 极便宜（1折~5折） |
| 输入 - 缓存不命中 | 算力受限 (Compute-bound) | 并行计算，生成新缓存 | 标准价（1倍） |
| 输出 (Decode) | 显存带宽受限 (Memory-bound) | 串行计算，逐字生成 | 最贵（3倍~5倍） |
