Token 与上下文长度

理解与应用

Token 是分词器把文本转换成序列时得到的基本单位。它可能是一个字、一个词的一部分、标点或其他片段，并对应词表中的编号。模型处理这些编号的表示，再将生成的编号解码成文字。同一句话使用不同分词器，得到的 token 数可能不同，因此字符数、单词数和 token 数不能按一个固定比例互换。

假设应用要让模型阅读一份长文档。看起来用户只问了一句“总结一下”，实际输入却还包含任务指令、历史对话、文档正文和工具说明。这些内容都占空间。若某个调用允许的总预算为 4096 个 token，输入已占 3500，再要求生成 1000 个 token 就无法同时容纳。具体模型怎样限制输入、输出或推理用量，要依照对应接口；预算计算中的数值应来自实际计数，而非文本看起来有多长。

缩短文本也不只是机械截掉末尾。合同最后一段可能是例外条件，JSON 最后的字符可能是闭合括号；只按长度截断，会把关键含义或格式一起截掉。更稳妥的处理是先按章节、字段或段落选择当前任务需要的内容，再用对应的分词器计数，并留出生成空间。这样，token 数控制的是长度，内容选择负责保留完整的意思。

动手试一试：把工具说明和输出空间也算进预算

4096 是本例约定的总预算，不代表某款产品的上下文上限。程序只演示预算运算，不负责分词。接入真实模型时，应替换为对应计数结果，并考虑接口包装等额外开销。

将代码保存为 example.py，使用 Python 3.10+ 运行 python3 example.py。仅使用标准库，无需密钥，不会调用外部模型。

Python 代码

# 假定下列数字已由目标模型的计数器测得；不是字符数估算。
input_tokens = {
    "任务指令": 180,
    "工具说明": 420,
    "文档片段": 1600,
    "历史对话": 300,
}
context_limit = 4096
reserved_output = 1000
used = sum(input_tokens.values())
remaining = context_limit - used - reserved_output
print("输入合计:", used)
print("保留输出后剩余:", remaining)

new_excerpt_tokens = 700
if new_excerpt_tokens > remaining:
    print("新增片段放不下，需要重新选择材料")

运行结果

输入合计: 2500
保留输出后剩余: 596
新增片段放不下，需要重新选择材料

常见误区

• 用“一个汉字就是一个 token”计算硬限制，可能导致实际请求超出预算。
• 只统计用户问题而忽略工具定义、检索结果和历史对话，会低估真实输入长度。

前置与延伸

建议先读

• 大语言模型（LLM）

相关概念

• 文档切分（Chunking）
• 上下文压缩

参考与版本

Apollo 原创讲解与教学示例。参考资料用于核对技术定义；核验日不代表资料的发布日期。

• Hugging Face：Tokenizers ↗

  已核对官方分词器课程；具体切分取决于 tokenizer，本篇不使用字符数冒充真实 token 计数。 · 核验：2026-10-10