输入令牌是模型在开始生成下一条响应之前接收并处理的令牌。它们来自完整的面向模型的请求，而不只是你最近输入的文字。
“提示令牌”通常指同一回事。不过，这个名称可能会产生误解，因为提示中可能包含应用程序或 API 添加的内容。
完整请求，而不仅仅是你的消息
想象一下，你在聊天框中输入“总结最新报告”。这句话只是输入的一部分。应用程序还可能发送：
- 用于设定助手角色和行为的指令；
- 之前的用户消息和助手消息；
- 报告本身，或从报告中检索出的段落；
- 模型可以调用的工具定义；
- 工具返回的结果；以及
- 用于标识角色、消息边界或生成开始位置的标记。
所有这些部分都可能成为输入令牌。具体包含哪些内容，取决于应用程序、API、模型和已启用的功能。
这为输入令牌划定了精确边界：输入令牌是根据其在一次请求中的角色来定义的。模型在某一轮生成的文本，可能会在下一轮由应用程序作为对话历史重新发送，此时它就会成为下一次请求的输入。
请求如何变成输入令牌
从界面到模型的流程如下：
system instructions ─┐
conversation history ├─> request formatting ─> tokenizer ─> input token IDs ─> model
documents and tools ┤
current message ─────┘首先，应用程序为请求组装上下文。简单的 API 调用可能只包含一个提示。生产环境中的助手则可能添加指令、历史记录、检索到的文档、工具架构以及其他内容。
接下来，服务会按照所选模型的要求格式化这些材料。聊天模型接收的不是带有彩色消息气泡的可视化对话记录，而是通过聊天模板或等效的内部格式构建的序列。vLLM 的聊天 API 文档明确说明了这一步：结构化消息会通过模型的聊天模板转换为文本提示。
然后，分词器会将格式化后的序列转换为令牌 ID。正如Hugging Face 分词器参考文档所示，这一过程可能包括规范化、将文本拆分为片段、将片段映射为 ID，以及添加特殊令牌。由于不同模型可能使用不同的分词器和模板，同样的可见文本并不能保证得到相同的输入令牌数量。
最后，模型处理该令牌序列并开始生成。响应中的使用情况元数据会报告提供商如何统计这次请求。
示例
假设应用程序报告了以下示例请求明细：
- 系统指令：36 个令牌
- 工具定义：74 个令牌
- 对话历史：160 个令牌
- 当前用户消息：12 个令牌
- 消息格式和特殊令牌：15 个令牌
该请求包含297 个输入令牌，尽管当前消息只有 12 个令牌。
现在假设响应包含 60 个生成令牌。这 60 个令牌是此次请求的输出令牌。在下一轮中，应用程序可能会将该答案加入历史记录。同一段文本随后会计入下一次请求的输入数量。
缓存会改变重复输入的处理方式和价格，但不会改变其概念上的角色。如果 297 个输入令牌中有 200 个来自可重复使用的前缀，提供商可能会将这 200 个令牌作为缓存输入单独报告或计价。它们仍然是提供给模型的上下文。例如，Anthropic 会将缓存请求拆分到多个使用情况字段中，而 OpenAI 会将缓存输入作为独立的输入类别公开。请始终阅读当前的字段定义，不要想当然地认为名为input_tokens的字段就是完整总数。
如何计算输入令牌
对于初步估算，可以使用与模型匹配的分词器来估计纯文本的令牌数量。但除非同时应用相同的消息模板、工具格式、特殊令牌、媒体编码和提供商端添加的内容，否则它无法可靠地复现完整的 API 计数。
对于完整请求，请在可用时使用提供商的令牌计数端点。Anthropic 的令牌计数端点接受消息、系统提示、工具、图像和 PDF。Google 的令牌指南同样区分生成前的输入计数和生成后返回的使用情况。OpenAI 的令牌计数指南指出，请求结构和非文本输入会影响完整计数。
将生成前的计数视为容量和成本估算。请求完成后，应保留提供商返回的使用情况响应，作为该调用实际如何计数和计费的记录。
为什么输入令牌很重要
成本
许多 API 会分别为输入、缓存输入和输出定价。一个有用的成本明细如下：
input cost =
uncached input tokens × uncached input rate
+ cached input tokens × cached input rate费率和类别会发生变化，因此应使用提供商当前的定价页面，而不要将价格直接复制到应用程序逻辑中。较长的系统指令、重复的工具定义、大段检索内容以及不断增长的聊天历史，都可能使输入成为工作负载中占比最大的部分。
可用上下文
输入令牌会占用模型上下文中的空间。根据模型和 API 的限制规则，更多输入可能会减少响应可用的空间。因此，发送额外上下文并不等于获得了免费的容量：它会与其他指令、证据和对话轮次竞争模型的注意力和令牌预算。
响应时间
模型必须先处理输入，才能生成第一个输出令牌。较大的输入通常需要更多提示处理工作。重复使用符合条件的缓存前缀可以减少这项工作，但缓存行为和收益取决于具体提供商。
测量
输入令牌数量有助于以比字符数或词数更有用的方式比较请求。它们可以揭示过大的工具架构、发送过多段落的检索系统，或每轮都会增长的对话历史。
常见误解
“输入令牌就是我输入的文字”
你的文字只是可见部分。面向模型的请求还可能包含指令、历史记录、文档、工具、媒体和格式信息。
“一个词等于一个输入令牌”
一个令牌可能是一个词、词的一部分、标点符号，或模型特有的其他单位。不同分词器的令牌边界各不相同。什么是 AI 中的令牌？介绍了这种底层单位。
“缓存令牌就不再是输入令牌了”
缓存令牌是被重复使用的输入。缓存可能会改变计算量、价格和使用情况字段，但缓存前缀仍然会为请求提供上下文。
“助手消息始终是输出令牌”
助手消息在生成时是输出。如果助手消息被纳入后续请求的历史记录，那么它对于后续请求而言就是输入。输入和输出描述的是请求的两面，而不是文本永久不变的类型。
“本地分词器会给出计费数量”
它可能会给出接近的文本计数，但可能遗漏聊天模板标记、工具架构、附件和提供商端格式化内容。请使用 API 在请求完成后返回的使用情况，作为计费记录。
输入令牌如何融入更广泛的系统
输入令牌是模型处理某次请求时的起始序列。输出令牌是在该序列之后生成的，而缓存输入令牌则是输入令牌在处理和计费方面的细分。结合起来，这些类别可以解释 API 响应和定价页面中显示的大多数令牌明细。
重要的习惯是测量组装完成的请求。当一条简短的用户消息产生了出乎意料的大数量时，应先检查系统指令、历史记录、检索材料、工具和格式，而不是先责怪分词器。
接下来可以做什么
检查一条真实的 API 响应，找出所有计入输入总数的使用情况字段。然后对同一个请求运行提供商的生成前计数器，并将估算值与最终使用情况进行比较。如果令牌边界本身还不清楚，请从什么是 AI 中的令牌？开始。接着阅读什么是输出令牌？，然后使用输入令牌、输出令牌与推理令牌的区别来比较这三种计费类别。