词表大小（Vocabulary Size）

3 秒看懂

一句话： 词表大小 = 模型”认识多少个不同 token”。它是 tokenizer 把原始文本切成的离散符号集合的基数，直接决定了模型输入嵌入层和输出概率分布的宽度。

类比： 如果把大语言模型比作一个翻译官，词表大小就是他脑子里能区分的”词汇条目数”。条目越细碎（词表小），表达同一句话要用更多条目；条目越粗粒度（词表大），一句话拆得更少，但每条条目需要独立分配参数。

3 分钟产业解释

为什么词表大小值得关注？

大语言模型（LLM）的第一步是 tokenization——把原始文本切分为离散 token 序列。词表大小（记作 $V$）决定了：

1. 序列长度： 同样一段文本，词表越大，通常切出的 token 越少（因为更多词/子词被整块编码），这意味着更短的序列 → 更低的推理延迟和更少的 KV Cache 占用。
2. 模型参数量： 输入嵌入矩阵和输出 lm_head 的参数量均为 V \times d_{\text{model}}，在小模型中可占总参数的 20%–40%。
3. 多语言效率： 词表越大，对中文、日文、阿拉伯文等非拉丁语系的覆盖率越好，同等文本消耗 token 更少。
4. 训练与推理计算量： 输出层的 softmax 计算量与 $V$ 成正比。

产业现状： 从 GPT-2 时代的约 5 万 tokens，到 GPT-4/LLaMA 3/Qwen2 时代的 10–15 万 tokens，行业趋势是 显著扩大词表，核心驱动力是多语言支持和推理效率优化。

15 分钟专家深入

核心权衡框架

词表大小 V 增大的影响：

                    好处                              代价
              ┌──────────────┐                ┌──────────────┐
              │ 序列更短      │                │ Embedding矩阵│
              │ → 推理更快    │                │ 参数量膨胀    │
              │ → KV Cache↓  │                │              │
              │              │                │ Softmax计算量│
              │ 多语言覆盖↑  │                │ 与V成正比     │
              │              │                │              │
              │ 频繁词可整词  │                │ 稀有token训练 │
              │ 编码效率↑    │                │ 样本不足,嵌入 │
              │              │                │ 学不充分      │
              └──────────────┘                └──────────────┘

2.1 Tokenizer 类型与词表构建

2.2 关键参数关系

Embedding 参数量 = V × d_model
lm_head 参数量   = V × d_model  (若不做权重绑定)
Softmax FLOPs    ≈ O(n_seq × V)  per layer, 仅在最后输出层

权重绑定（Weight Tying）： 多数现代 LLM 将输入 embedding 矩阵与输出 lm_head 共享同一权重，此时 embedding 参数只存一份，大小仍为 V \times d_{\text{model}}。这在小模型中意义重大——例如一个 V{=}128\text{K}、d_{\text{model}}{=}4096 的模型，仅 embedding 就占 128\text{K} \times 4096 \approx 5.24\text{亿} 参数。

2.3 词表大小与序列压缩比

同一段中文文本，不同 tokenizer 的切分结果差异显著：

示例文本: "人工智能正在改变世界"
大致估计（具体结果取决于实现细节）:

LLaMA 1 tokenizer (V≈32K, 多中文语料不足):  ~12-18 tokens
LLaMA 3 tokenizer (V≈128K, 加强中文):        ~6-9 tokens  
Qwen tokenizer    (V≈152K, 针对中文优化):     ~5-8 tokens

含义： 大词表 + 多语言优化的 tokenizer 可以将中文序列压缩 50%–70%，这直接转化为：

• 推理延迟降低（prefill 和 decode 都更快）
• KV Cache 内存减少
• 有效上下文窗口变长（同样的 token 预算能装更多语义）

技术原理（最深）

3.1 词表在模型架构中的位置

                    ┌─────────────────────────────────────┐
                    │          Transformer Block ×N        │
                    │  ┌────────────────────────────────┐  │
     Input IDs      │  │  Self-Attention + FFN           │  │
    [batch, seq]──→ │  │  (参数与 V 无关)                 │  │
         │          │  └──────────────┬─────────────────┘  │
         ▼          │                 │                     │
  ┌──────────────┐  │                 │                     │
  │  Embedding   │  │                 │                     │
  │  Table       │  │                 │                     │
  │  [V, d]      │  │                 │                     │
  └──────┬───────┘  │                 ▼                     │
         │          │         ┌──────────────┐              │
         └──────────┼────────→│  lm_head     │──→ logits    │
                    │         │  [d, V]       │  [b, seq, V] │
                    │         │  (=Embedding^T│              │
                    │         │   if tied)    │              │
                    │         └──────────────┘              │
                    └─────────────────────────────────────┘

关键： Transformer block 内部的 Self-Attention 和 FFN 参数量完全与 $V$ 无关。$V$ 仅影响：

• 输入端的 Embedding Table（参数量 V \times d）
• 输出端的 lm_head（参数量 d \times V，权重绑定时复用 embedding）
• 最终 softmax 的计算量（$O(V)$ 逐元素）

3.2 Softmax 瓶颈与大词表

输出层 softmax 计算：

P(w_i) = \frac{\exp(z_i)}{\sum_{j=1}^{V} \exp(z_j)}, \quad z = \mathbf{h} \cdot \mathbf{W}_{\text{head}}^T

当 $V$ 很大时：

1. 计算瓶颈： 计算 logits 需要 d_{\text{model}} \times V 次乘加，softmax 归一化需要遍历 $V$ 个元素。在 decode 阶段逐 token 生成时，这一步的 FLOPs 占比可能超过 30%（小模型）至 10%（大模型）。
2. Softmax 瓶颈： 当 V \gg d_{\text{model}} 时，logits 的变化受限于 d_{\text{model}} 维子空间（softmax 瓶颈），softmax 输出分布的表达能力受限。但这在现代 LLM 中通常不构成严重问题，因为 d_{\text{model}} 一般足够大（如 4096–12288）。

3.3 Byte-level Fallback 机制

现代 tokenizer 多采用 byte-level fallback：

编码流程：
  原始文本 → UTF-8 字节序列 → 在词表中查找/合并

  如果某个 Unicode 字符（如罕见中日韩字符、emoji）
  从未在训练语料中出现 → 回退到逐字节编码
  （256 个基本字节 token 保证 100% 覆盖）

这意味着：理论上任何输入都能被编码，不会 OOV (Out-of-Vocabulary)
但罕见字符会被拆成 2-4 个字节 token，效率降低

3.4 Softmax 中的数值稳定性

大 $V$ 带来的另一个工程挑战：logits 数值范围大，直接做 \exp 容易溢出。实践中必须使用：

\text{logits}_i' = \text{logits}_i - \max_j(\text{logits}_j)

即 log-sum-exp trick。几乎所有深度学习框架默认实现这一点。

技术演进史

趋势： 词表大小在 5 年内从约 3 万增长到约 20 万，增长约 6–7 倍，核心驱动力是多语言覆盖和推理效率。

技术路线对比

上下游

上游：Tokenizer 训练

上游依赖链：

大规模多语言语料 ──→ Tokenizer 训练（BPE/Unigram）
                          │
                          ▼
                    词表文件（vocab.json / tokenizer.model / .tiktoken）
                          │
                          ▼
              ┌───────────────────────┐
              │  模型训练/推理         │
              │  Embedding层 初始化    │
              │  词表中每个token分配    │
              │  一个d维向量           │
              └───────────────────────┘

Tokenizer 训练的关键输入：

• 语料规模与语言分布（决定词表覆盖哪些语言/领域）
• 目标词表大小（超参数，需要权衡）
• 特殊 token 配置（[BOS], [EOS], [PAD], 工具调用 token 等）

下游：推理优化

词表大小影响的下游优化环节：

关键指标

供需与市场数据

供给侧

• Tokenizer 训练本身计算量低：训练一个 BPE tokenizer 在单 GPU 上几小时可完成，不构成瓶颈。
• 真正的成本在于词表扩展后的模型重训： 当 Meta 将 LLaMA 3 词表从 32K 扩展到 128K，所有嵌入参数需要重新初始化和训练，且因为序列变短，原有的超参数配置（如学习率、上下文长度）可能需要重新调优。
• Tokenizer 工具生态： HuggingFace Tokenizers、SentencePiece（Google）、tiktoken（OpenAI）为主流开源方案。

需求侧

量化估算

以一个 7B 参数模型、$V$=128K、$d$=4096 为例：

• Embedding 参数量：128{,}000 \times 4{,}096 = 5.24 \text{亿} \approx 5.24 \text{亿参数}
• 占总参数比：5.24\text{亿} / 70\text{亿} \approx 7.5\%
• 若 $V$=32K，则 embedding 参数量仅为 1.31\text{亿}，占比 \approx 1.9\%

代表公司与资本映射

产业链关键节点：

• Tokenizer 训练工具 → 模型厂商自研或使用开源库
• 词表决定推理侧 KV Cache 效率 → 影响 GPU 需求量
• 大词表 → 更大的 embedding 权重文件 → 影响模型分发和加载时间

投资逻辑

1. 多语言大模型趋势利好”大词表”

随着非英语市场（中国、日本、中东、东南亚）对 LLM 需求爆发，大词表 + 多语言优化的 tokenizer 成为标配。这意味着：

• 推理效率提升 → 降低 token 成本 → 扩大应用场景
• 但也意味着模型的 embedding 权重更大 → 存储和加载开销增加

2. 长上下文趋势与词表的协同

词表越大 → 同样上下文窗口（如 128K tokens）能承载更多原始文本 → 等效上下文能力增强。这与长上下文推理的技术趋势（RoPE 外推、Ring Attention 等）形成协同。

3. 边缘部署的小模型挑战

端侧小模型（1B–3B 参数）中，大词表的 embedding 参数占比可能过高（15%–40%），迫使采用更小词表或知识蒸馏策略。这可能催生 专用端侧 tokenizer 的需求。

4. Tokenizer 本身不是护城河

Tokenizer 训练成本极低，不是竞争壁垒。真正的壁垒在于 词表确定后的大规模预训练——一旦选定了 tokenizer，更换成本极高（需要重训整个模型）。

常见误读纠偏

❌ 误读 1：“词表越大，模型越聪明”

纠偏： 词表大小与模型智能无直接关系。词表大小影响的是 输入编码效率 和 输出概率分布的宽度，而不是模型的推理能力或知识量。一个 128K 词表的模型并不比 32K 词表的模型”更聪明”——它只是能用更少的 token 表达同样内容。模型的”聪明”来自训练数据、模型架构、训练规模（Chinchilla scaling law）等。

❌ 误读 2：“词表大了，参数量就一定大幅增加”

纠偏： 词表增大影响的是 embedding 层（V \times d），在大模型中占比很小。例如 LLaMA 3 70B 模型，embedding 参数约 128\text{K} \times 8192 \approx 10.5\text{亿}，仅占 70B 总参数的约 1.5%。只有在小模型（1B–3B）中，词表扩展才会显著影响参数占比。

❌ 误读 3：“不同 tokenizer 切出来的 token 数可以跨模型直接比较”

纠偏： 不同 tokenizer 的 token 定义完全不同，无法直接比较 token 数来判断效率。例如 GPT-3.5 的 “token” 和 LLaMA 3 的 “token” 切分粒度不同。真正的比较基准应是 同一文本在不同 tokenizer 下的 token 数。

❌ 误读 4：“词表大小需要手动选择最优值”

纠偏： 在实践中，词表大小通常是一个启发式选择，基于：

• 参考已有模型的经验（如 32K、128K 是常见档位）
• 目标语言的覆盖需求
• 模型大小与 embedding 参数占比的平衡

没有严格的理论最优值。BPE 训练中设定的合并次数决定了最终词表大小，这更像是一个工程决策而非理论优化。

学习路径

Level 1: 理解基本概念
├── 学习 BPE 算法原理（建议读 GPT-2 原论文的 tokenizer 部分）
├── 用 HuggingFace tokenizers 库手动训练一个 BPE tokenizer
└── 对比不同 tokenizer 对同一段中文文本的切分结果

Level 2: 理解工程影响
├── 计算你熟悉模型的 embedding 参数量（V × d_model）
├── 分析序列长度对 KV Cache 内存的影响
└── 实验：用不同 vocab size 训练小模型，观察 loss 曲线差异

Level 3: 理解架构设计决策
├── 研读 LLaMA 3 技术报告（关于 tokenizer 从 32K 扩展到 128K 的决策）
├── 理解 Megatron-LM 中输出层的 Tensor Parallel 切分方式
└── 研究 Speculative Decoding 中草稿模型与目标模型的词表共享问题

Level 4: 前沿研究
├── 关注多语言 tokenizer 的公平性问题（某些语言是否被过度切分）
├── 研究动态词表（Dynamic Vocabulary）或自适应 tokenization
└── 探索 byte-level models（如 MegaByte, ByT5）对 subword 范式的挑战

推荐实操

# 用 tiktoken 对比 GPT-3.5 和 GPT-4o 的 tokenizer
import tiktoken

text = "人工智能正在改变世界"

# GPT-3.5 era tokenizer
enc_cl100k = tiktoken.get_encoding("cl100k_base")
tokens_cl = enc_cl100k.encode(text)
print(f"cl100k: {len(tokens_cl)} tokens, vocab size ≈ 100K")

# GPT-4o era tokenizer  
enc_o200k = tiktoken.get_encoding("o200k_base")
tokens_o2 = enc_o200k.encode(text)
print(f"o200k:  {len(tokens_o2)} tokens, vocab size ≈ 200K")

一句话总结

词表大小是 LLM 的”字典厚度”——它不决定模型多聪明，但直接决定了模型处理文本的效率：词表越大，同等文本用更少 token 表示，推理更快，多语言覆盖更好，但 embedding 参数和 softmax 计算开销也随之增长；当前行业趋势是从 3–5 万大幅扩展到 10–20 万，核心驱动力是全球化多语言需求和长上下文推理效率。

延伸阅读与来源

1. Sennrich et al., “Neural Machine Translation of Rare Words with Subword Units” (2016) — BPE 算法原始论文
2. Kudo & Richardson, “SentencePiece: A simple and language independent subword tokenizer and detokenizer” (2018) — SentencePiece 方法论
3. Radford et al., “Language Models are Unsupervised Multitask Learners” (2019) — GPT-2 的 byte-level BPE tokenizer 设计 [OpenAI 论文]
4. Touvron et al., “LLaMA: Open and Efficient Foundation Language Models” (2023) — 32K 词表设计 [Meta 论文]
5. Meta, “Introducing Meta Llama 3” (2024) — 词表扩展到 128K 的说明 [Meta 官方技术博客]
6. OpenAI tiktoken 开源库 — cl100k_base / o200k_base 词表大小可通过代码直接验证 [GitHub: openai/tiktoken]
7. Qwen 技术报告 — ~152K 词表的中文优化策略 [阿里通义千问官方文档]
8. Chowdhery et al., “PaLM: Scaling Language Modeling with Pathways” (2022) — 约 256K 词表的大规模模型 [Google 论文]

⚠️ 数据口径说明： 本文中 GPT-4o 词表大小约 200K 为基于 o200k_base 的 [估算]，Anthropic 词表大小 [未充分披露]。DeepSeek 词表大小为 [供应链估算]。其他数据均来自对应模型的技术论文或官方开源代码。