在 1.1 节我们把 LLM 的本质还原为“逐 Token 概率接龙”，在 2.1 节我们把模型规模拆解为参数量、层数、隐藏维度等硬件指标。但这两者之间还缺一块关键拼图：模型一次性能“看”多长的文本？以及文本到底是怎么被“看”进去的？这就是 Token、词表和上下文窗口要回答的问题。对使用者而言，这三个概念直接决定你的计费账单、显存占用和 Prompt 设计策略。
一、Token：模型的最小“原子”，也是计费单位
Token 是大模型处理文本的最小单元。它不一定是“字”，也不一定是“词”，而是词表（Vocabulary）中某一个条目的索引编号。
- 英文：1 个 Token 通常对应约 0.75 个单词，或一个常见子词。例如 "unbelievable" 可能被切成
["un", "believ", "able"]；"New York" 可能是一个整体 Token。 - 中文：取决于训练时使用的分词算法。在 GPT-4 中，“我爱你”≈ 3 个 Token；“大语言模型”可能≈ 2–4 个 Token；但一些生僻字或繁异体字可能被拆成多个字节级 Token。
- 数字与符号：纯数字序列常被拆开。例如
1234可能是["12", "34"]；π可能是一个 Token，但3.14159可能被切成多个。
为什么你必须关心 Token？
- 它是计费单位：OpenAI、Anthropic、国内云厂商全部按输入 + 输出的 Token 数计费。同样一段中文，在 GPT-4 上可能比在某国产模型上贵，因为 Tokenization 方式不同。
- 它是模型真正的“阅读单位”：模型看到的不是“字”或“词”，而是 Token ID 序列。Prompt 工程的本质，就是在操控 Token 序列的统计概率。
- 它决定上下文窗口的利用率：一个号称 128K 窗口的模型，如果处理中文时每个汉字平均占 1.5 个 Token，实际能装的汉字数只有约 8.5 万字，而非 12.8 万字。
实用技巧：
- 用官方 Tokenizer（如 OpenAI 的 Tiktoken）或在线工具提前测算你的 Prompt 长度。
- 控制 Prompt 冗余：删除无意义的空格、换行、重复修饰词，能直接省钱。
- 英文 Prompt 通常比中文更“省 Token”，因为英文子词切分后的信息密度更高。
二、词表（Vocabulary）：Token 的“字典”，决定切分规则与模型盲区
词表是模型认识的所有 Token 的集合，通常是一个固定大小的查找表（Lookup Table），规模从 3 万到几十万不等。
| 模型/系列 | 词表大小 | 特点 |
|-----------|----------|------|
| GPT-3 | 50,257（≈50K） | BPE，多语言支持一般 |
| Llama 2 | 32,000 | SentencePiece，对非英语支持较弱 |
| Llama 3 | 128,000 | 大幅扩充，多语言与代码 Token 更优 |
| Qwen2 | 150,000+ | 中文优化，汉字覆盖更全 |
| Gemma | 256,000 | 更大词表，减少长尾词被切碎的概率 |
词表大小的工程权衡：
- 词表小：每个 Token 承载信息少，序列变长，推理时自回归步数增加，但 Embedding 层和输出层参数量小。
- 词表大：单个 Token 信息密度高，序列缩短，推理更快；但 Embedding 矩阵会膨胀（参数量 = 词表大小 × 隐藏维度），且罕见 Token 训练不充分容易成为“死亡权重”。
特殊 Token（Special Tokens）：
这些不是自然语言内容，而是控制模型行为的“开关”：
<|begin_of_text|>/<|end_of_text|>：序列起始 / 终止标记。<|user|>、<|assistant|>、<|system|>：对话模板分隔符，告诉模型“现在轮到谁说话”。<|pad|>：批量推理时用于对齐短序列的填充标记（通常被注意力掩码忽略）。<|unk|>：遇到词表外字符时的兜底标记（现代 BPE / SentencePiece 已极少出现）。
实用认知：
- 同样的汉字，在不同模型里可能被切成完全不同的 Token 序列。这解释了为什么某个 Prompt 在 GPT-4 上效果很好，换到另一个模型就失效——不是模型笨，而是它“读”到的 Token 序列不同。
- 如果你的业务涉及大量专业术语、化学式、代码库，优先选择词表对这些领域覆盖更全的模型，能显著提升效率并降低被切乱的风险。
三、上下文窗口（Context Window）：模型的“工作记忆”容量
上下文窗口指模型在一次前向传播中能处理的最大 Token 数，通常用“K”表示（4K、8K、128K、1M）。它包括系统提示 + 历史对话 + 用户输入 + 模型已输出内容的总和。
关键区分：物理窗口 vs 有效窗口
- 物理窗口（Physical Context Length）：模型架构支持的最大 Token 上限，由位置编码和注意力机制决定。例如 Llama 3 原生 8K，通过 RoPE 基频调整可扩展到 128K。
- 有效窗口（Effective Context Length）：模型在实际长文本中，对远距离信息的检索与利用精度。这是 1.3 节提到的“长文本一致性衰减”的技术根源——虽然 128K 的 Token 都“在窗口里”，但模型可能只记得住后 32K 的内容，前 96K 的事实容易丢失或混淆。
上下文窗口的演进与现状：
- 早期 GPT-3：2K–4K
- GPT-4 Turbo / Claude 3：128K
- Gemini 1.5 Pro：1M–2M（多模态 Token 混合计算）
- 国内模型（Kimi、Qwen2.5、DeepSeek-V2）：128K–256K，部分测试支持百万字级
显存杀手：KV-Cache（呼应 2.1 节）
在 2.1 节我们提到推理显存 ≈ 参数 × 精度。但这只算静态权重。长文本推理时，真正的显存黑洞是 KV-Cache：
- 每生成一个新 Token，模型需要缓存前面所有 Token 的 Key 和 Value 向量。
- 缓存显存 ≈
2 × 层数 × 隐藏维度 × 序列长度 × 批次大小 × 精度字节数 - 粗略估算：一个 7B 模型处理 128K 上下文，KV-Cache 可能吃掉数十 GB 显存，远超权重本身。
这就是 1.4 节工程层存在的理由——没有 PagedAttention（vLLM）、没有 KV-Cache 量化、没有滑动窗口注意力，再长的物理窗口也只是纸上谈兵。
长文本的三种工程应对：
- RAG（检索增强生成）：不把所有文档塞进窗口，而是先检索相关片段（通常 < 4K Token），再让模型生成。这是目前最稳妥的长文本方案。
- 滑动窗口 / 环形注意力：只让模型“仔细看”局部窗口，远距离信息通过压缩或摘要传递。牺牲了部分全局精度，换取显存可行性。
- 文本预处理：在进入模型前，用传统 NLP 或更小的模型做摘要、分段、去重，减少输入 Token 数。
实用建议：
- 不要迷信“128K 上下文”的标称值。如果你的任务需要精确引用文档前部细节（如合同审阅、论文综述），建议将关键段落前置，或分段处理。
- 设计 Agent 工作流时，与其给模型塞 10 万字让它自己找重点，不如让模型先读目录、再决定调用哪些片段——这是把长上下文压力从“硬件”转移到“策略”。
- 监控实际 Token 用量：很多对话类产品默认携带完整历史，几轮下来就很容易撞墙，需要设计摘要 / 遗忘机制。
四、三者的联动关系：一个完整的输入旅程
当你发送一段文字给模型，它经历的流程是：
- Tokenization：分词器对照词表，把字符串切分为 Token ID 序列（例如
[15496, 11, 616, ...]）。 - Embedding Lookup：每个 Token ID 从词表中取出对应的向量，进入 Transformer。
- 位置编码：给每个位置加上位置信息，让模型知道谁在前谁在后。
- 注意力计算：在上下文窗口范围内，计算所有 Token 之间的关联。
- 自回归输出：预测下一个 Token，循环往复。
如果这个链条中任何一环出问题——词表缺字导致乱码、Token 数超窗被截断、KV-Cache 爆显存导致服务崩溃——模型就无法正常工作。
五、小结
- Token 是模型的原子单位和计费单位。同样文本在不同模型中 Token 数不同，设计 Prompt 前务必测算。
- 词表 决定 Token 切分规则与信息密度，专业领域应优先选择词表覆盖度高的模型。
- 上下文窗口 是模型的物理工作记忆，但有效注意力随长度衰减。长文本场景下，RAG 和分段策略往往比硬塞全量文本更可靠。
- 三者共同构成“模型如何吃进去文本”的完整链条，直接影响你的成本、延迟和效果天花板。
在 2.4 节，我们将进入大模型最富争议的三个特性——涌现能力、幻觉与对齐。理解了 Token 和上下文窗口的物理约束，你就能更深刻地明白：为什么模型会在某些规模上“突然开窍”，又为什么在长文本末端信誓旦旦地编造事实。