从“字”到“Token”：模型眼中的文本单位

一、从“字”到“Token”：模型眼中的文本单位

在我们人类眼中，文本是由字、词、句子组成的连续序列。但对于大语言模型来说，直接处理一长串字符效率太低。因此，它需要一个分词器来将文本切分成一个个更小的、有语义的单元。这个单元，就是 Token。你可以把它理解为模型消化文本的“最小单词块”。

Token 的划分规则因模型和分词器而异。一个常见的英文单词（如 “hello”）通常是一个 Token，但一个生僻或较长的词可能会被拆分成多个子词 Token。中文则更倾向于按字或常用的词来切分。例如，“我爱中国” 可能被拆分为 ["我", "爱", "中国"] 三个 Token。理解 Token，是理解模型一切行为（包括计费）的基础。

二、深入 Token：分词器如何工作？

分词器（Tokenizer）是执行文本到 Token 转换的组件。它内部维护着一个庞大的词表，其中包含了模型训练时见过的所有 Token。当我们输入一段文本时，分词器会按照特定算法（如 BPE， Byte Pair Encoding）在词表中查找并匹配，将文本分解为 Token 序列。这个序列才是模型真正“看到”和处理的输入。

我们可以通过代码直观地看看分词过程。以 Hugging Face 的 transformers 库为例：

from transformers import AutoTokenizer

# 加载一个常用的分词器，例如来自 GPT-2 的
tokenizer = AutoTokenizer.from_pretrained("gpt2")

text = "Hello, how are you doing? I'm learning about AI tokens."
tokens = tokenizer.tokenize(text)
token_ids = tokenizer.convert_tokens_to_ids(tokens)

print(f"原始文本: {text}")
print(f"拆分后的Token: {tokens}")
print(f"对应的Token ID: {token_ids}")
print(f"总Token数: {len(tokens)}")

运行这段代码，你会看到文本被转换成了一个 Token 列表。标点符号、空格也可能成为独立的 Token。模型通过这些数字 ID 来索引其内部的“知识”并进行计算。

三、计费的核心：输入、输出与单价

大模型的 API 计费本质上就是为模型处理的 Token 数量付费。这个费用通常分为两部分：

输入 Token：你发送给模型的提示词（Prompt）所包含的 Token 数。这部分是你在请求中提供的所有文本（包括系统提示、历史对话、当前问题等）。
输出 Token：模型生成并返回给你的回复所包含的 Token 数。这部分由模型动态生成，其长度往往是你最需要注意的成本变量。

关键点在于：模型的定价是 “每千个 Token 的价格”，并且输入和输出的单价通常是不同的。输出 Token 的单价往往远高于输入 Token，因为生成回复对模型的计算资源消耗更大。

提示：在 API 响应中，通常会明确返回本次调用消耗的 prompt_tokens 和 completion_tokens 数量。这是核对账单和优化成本的第一手数据。

四、实际 API 调用中的 Token 计算

在实际调用 API 时，Token 计算是自动且精确的。你无需手动计算，但需要理解其构成以便优化。让我们以 OpenAI 的 Chat Completion API 为例，一次简单的调用大致会产生如下 Token 消耗：

输入侧：系统提示词 + 用户本次输入的完整历史对话。
输出侧：模型生成的完整回复文本。

一个重要的机制是“上下文窗口”。每个模型都有一个最大上下文长度限制（如 4096、8192、128K Tokens），这是输入+输出 Token 数的总和。如果你发送的对话历史过长，接近这个上限，那么模型可用于生成回复的空间就很小了。这不仅是功能限制，也是成本考量——你一直在为越来越长的历史输入付费。

五、实战：如何估算与优化成本？

理解原理后，我们可以通过策略来管理和优化成本。

首先，估算。在向 API 发送请求前，你可以使用上述的分词器代码粗略估算输入文本的 Token 数。输出部分则需要你大致控制回复的预期长度。

其次，优化。核心思路是“精炼输入，控制输出”。具体策略包括：

优化提示词：用更简洁、明确的指令，去除冗余的上下文描述。
管理对话历史：在长对话中，定期进行历史摘要或丢弃不重要的旧消息，而不是无限制地将所有历史发给模型。
善用参数：API 通常提供 max_tokens 参数来硬性限制输出的最大长度。这是一个非常有效的成本控制阀。
选择模型：不同模型的 Token 单价差异巨大。对于简单任务，使用更小、更便宜的模型即可。

六、总结与关键心得

回顾一下，Token 是模型处理文本的基本单位，由分词器决定。计费则基于消耗的输入和输出 Token 数量，乘以各自的单价。

最后，分享几个个人心得：

成本意识前置：在产品设计阶段就应考虑 Token 消耗，将成本作为核心指标之一。
输出是成本大头：永远要关注你的系统生成了多长的回复，因为这直接关系到“输出单价”乘数效应。
Token 不等于字：中英文的 Token 数差异很大，一个中文字可能对应1-2个 Token，而英文单词可能对应1-3个 Token。估算成本时需注意。

终极提示：最高效的学习方法，就是打开一个 API 提供商的控制台（如 OpenAI Playground），输入不同长度的文本，亲眼观察 Token 计数和预估费用的变化。这种直观感受比任何理论都管用。