大语言模型如何计算与统计 Token 数

一、先厘清概念：Token 是模型处理的离散单元

大语言模型并不直接把“字”或“词”作为输入输出单位。用户提交的文本会先经过规范化、切分和映射，转换为一串离散的符号编号，模型再基于这些编号进行推理与生成。Token 可以理解为模型在当前处理流程中使用的离散文本单元。它可能对应一个完整词语、一个子词、一个汉字、一个标点、一个字节片段，甚至一个表情符号的一部分。具体对应关系取决于模型词表、切分规则和文本本身的语言特征。

因此，Token 不是“汉字数”，也不是“英文单词数”。同一段文本在不同模型下可能得到不同的 Token 数；同一段中文在不同业务场景下也可能因为词表覆盖、空白、标点、数字串、混合语言等因素而出现差异。工程上更准确的理解是：Token 是文本进入模型后形成的符号序列长度，是上下文窗口、生成长度和计量统计的核心单位。

字符数只能作为粗略线索，不能作为最终计量依据。比如一段短中文可能包含较少的汉字，但由于标点、换行、表情、特殊符号或多语言混排，Token 数可能高于预期；一段较长的英文也可能因为高频词被合并处理，Token 数低于按字符数估算的结果。对于成本敏感或上下文长度敏感的系统，应以实际分词结果或服务端计量结果为准。

二、总消费构成：输入 Token 与输出 Token

一次模型调用的 Token 消费通常由两部分组成：请求侧输入 Token 和生成侧输出 Token。输入部分不仅包括用户直接输入的问题，还可能包括系统指令、角色设定、历史对话、检索增强片段、结构化模板、工具描述、格式约束等内容。输出部分则是模型生成并返回的文本，某些场景下还可能包含协议标记、工具调用参数或结束标记等，具体以实际服务的计量说明为准。

总消费可以概括为：

总 Token 数 = 输入 Token 数 + 输出 Token 数

例如，某次请求输入部分消耗 100 Token，模型生成回答消耗 200 Token，那么本次调用合计消费 300 Token。需要注意的是，输入与输出的单价可能不同，因此成本不能简单用总 Token 数乘以单一价格。更严谨的成本估算方式是分别统计输入与输出：

成本 ≈ 输入 Token 数 × 输入单价 + 输出 Token 数 × 输出单价

其中单价单位、计费阶梯、最小计费单位等应以实际服务说明为准。工程系统应分别记录输入 Token、输出 Token 和总 Token，而不是只记录一个总量。这样既便于成本核算，也便于分析成本异常究竟来自上下文膨胀还是输出过长。

三、多轮对话中的 Token 会累积

多轮对话是 Token 统计中最容易被低估的场景。很多系统在每一轮请求时，会把系统指令、历史消息、当前用户问题以及必要的检索片段重新组装为上下文提交给模型。也就是说，历史对话内容往往会在后续请求中再次进入输入部分。即使某些文本在前一轮已经出现过，只要它仍被放入当前上下文，就仍然可能计入当前请求的输入 Token。

因此，多轮对话的输入 Token 会随轮次增加而增长。轮次越多、历史越长、检索片段越多，输入部分越容易膨胀。常见控制手段包括：保留最近若干轮对话、对较早历史做摘要压缩、只检索与当前问题相关的片段、把稳定指令与动态内容分离、限制单个片段的长度、对长文档做分段处理等。需要强调的是，任何压缩和截断都应基于 Token 预算，而不是只按字符数截断，否则容易在边界处产生不可控的上下文损失。

流式生成场景下，输出 Token 通常随着生成过程逐步累计。若因超时、主动停止、内容截断等原因提前结束，实际计量应以服务端记录为准。不同服务对失败请求、重试请求、缓存命中的处理规则可能不同，工程上不应自行假设“失败一定不计费”或“重试一定重复计费”，而应在日志中记录请求状态、重试次数和计量结果，定期核对。

四、Token 与字符之间为什么没有固定比例

Token 与字符之间不存在放之四海而皆准的固定换算系数。原因主要有以下几点：

第一，语言差异。高频词、常用词组可能被合并为较少 Token；生僻词、专有名词、混合语言、表情符号和特殊符号可能被拆成多个 Token。中文中常见字词可能以单字或词组形式出现，英文中空格、标点和词形变化也会影响切分结果。

第二，文本类型差异。自然语言段落、代码、日志、结构化文本的 Token 密度不同。代码中的缩进、换行、括号、运算符、长变量名和数字串往往会被拆得更碎；结构化文本中的字段名、引号、分隔符也会占用 Token；日志中的时间戳、编号和重复符号同样可能增加 Token 数。

第三，规范化与模板影响。大小写转换、全半角处理、空白压缩、换行保留策略、消息模板拼接方式都会改变最终符号序列。模板本身也会占用输入 Token，例如角色说明、格式要求、示例和分隔符都不应被忽略。

第四，模型词表不同。不同模型可能采用不同的切分策略和词表规模，因此同一段文本在不同模型下的 Token 数可能不同。工程上不能拿一个模型的估算系数直接套到另一个模型上。

实际项目中，建议对真实业务文本做抽样统计：按业务类型分别统计输入与输出的 Token 分布，观察中位数和高分位值，再据此设置预算和告警阈值。相比“字符数除以某个固定数”的粗略估算，基于真实样本的 Token 分布更可靠。

五、计算流程与伪代码示例

从工程实现角度看，一次调用的 Token 统计可以拆成以下步骤：

1. 组装完整上下文：明确哪些内容进入输入，包括系统指令、历史对话、当前问题、检索片段、模板和工具描述。
2. 按目标模型的分词规则编码文本：不要自行按空格或字符切分来代替模型分词。
3. 统计输入 Token：对完整拼接后的上下文统计，而不是简单把各片段估算值相加。拼接边界可能引入额外符号，合并后统计更准确。
4. 校验上下文上限：确保输入 Token 加预留输出 Token 不超过模型上下文窗口，预留输出用于避免生成被截断。
5. 生成并统计输出 Token：记录最终输出长度；流式场景下累加已生成内容。
6. 分别记录输入、输出、总量、模型标识、请求类型、是否重试等字段，用于成本分析和容量规划。

下面给出一个不依赖具体产品接口的伪代码示例：

type TokenStat = {
  inputTokens: int,
  outputTokens: int,
  totalTokens: int,
  estimatedCost: number
}
interface Tokenizer {
  encode(text: string): int[]
}
function buildContext(systemPrompt, history, userMessage, retrievedChunks):
    return joinByTemplate(systemPrompt, history, retrievedChunks, userMessage)
function estimateCall(tokenizer, contextText, expectedOutputTokens,
                     inputPrice, outputPrice):
    inputIds = tokenizer.encode(contextText)
    inputTokens = inputIds.length
    // 预留输出 Token，避免超过上下文窗口
    reservedOutputTokens = expectedOutputTokens
    totalTokens = inputTokens + reservedOutputTokens
    estimatedCost = inputTokens * inputPrice
                  + reservedOutputTokens * outputPrice
    return {
      inputTokens: inputTokens,
      outputTokens: reservedOutputTokens,
      totalTokens: totalTokens,
      estimatedCost: estimatedCost
    }

上述示例只表达统计思路：输入部分按完整上下文编码后统计，输出部分按预期或实际生成长度统计，成本按输入输出分别计价。实际单价单位、计费精度和窗口限制应以服务说明为准。伪代码中的 Tokenizer 代表通用分词能力，不代表任何特定工具或平台。

六、常见误差来源与优化实践

第一，多轮对话历史重复提交。优化方向是历史摘要、最近窗口、相关性检索和记忆分层。第二，长文档直接整段放入上下文。优化方向是按 Token 分块、只保留相关片段、对片段做压缩摘要。第三，代码和结构化文本直接全量传入。优化方向是去除无关注释、压缩空白、精简字段、只传必要片段。第四，输出长度不可控。优化方向是设置最大输出长度、明确格式约束、使用停止条件，但要注意约束说明本身也占输入 Token。第五，估算方法过于粗糙。优化方向是用真实样本校准，把本地估算与服务端计量做定期比对，关注高分位成本而不是只看平均值。

此外，还应关注上下文窗口保护。一个常见原则是：输入 Token 加上最大预期输出 Token 应小于模型可用上下文窗口。如果只校验输入而不预留输出，可能导致生成中途被截断。对于成本敏感业务，应分别设置输入预算和输出预算，并对异常长请求、重复重试、历史膨胀等情况建立监控告警。

七、总结

Token 计算的核心可以归纳为三点：第一，Token 是模型处理文本的离散单元，与字符、词语、字节之间不存在固定一一映射；第二，总消费由输入 Token 与输出 Token 相加构成，成本通常需要分别计价；第三，多轮历史、模板、检索片段、代码和结构化文本都会影响 Token 数，工程实现应按完整上下文统计，预留输出长度，并以实际计量结果作为最终依据。只有把 Token 统计纳入请求组装、上下文管理、成本核算和监控告警的完整链路，才能更准确地评估大语言模型应用的调用成本与上下文容量。