詞表大小（Vocabulary Size）
3 秒看懂
一句話： 詞表大小 = 模型”認識多少個不同 token”。它是 tokenizer 把原始文本切成的離散符號集合的基數，直接決定了模型輸入嵌入層和輸出機率分佈的寬度。
類比： 如果把大語言模型比作一個翻譯官，詞表大小就是他腦子裡能區分的”詞彙條目數”。條目越細碎（詞表小），表達同一句話要用更多條目；條目越粗粒度（詞表大），一句話拆得更少，但每條條目需要獨立分配引數。
3 分鐘產業解釋
為什麼詞表大小值得關注？
大語言模型（LLM）的第一步是 tokenization——把原始文本切分為離散 token 序列。詞表大小（記作 $V$）決定了：
- 序列長度： 同樣一段文本，詞表越大，通常切出的 token 越少（因為更多詞/子詞被整塊編碼），這意味著更短的序列 → 更低的推論延遲和更少的 KV Cache 佔用。
- 模型引數量： 輸入嵌入矩陣和輸出 lm_head 的引數量均為
V \times d_{\text{model}}，在小模型中可佔總引數的 20%–40%。 - 多語言效率： 詞表越大，對中文、日文、阿拉伯文等非拉丁語系的覆蓋率越好，同等文本消耗 token 更少。
- 訓練與推論計算量： 輸出層的 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 型別與詞表建置
| 方法 | 代表模型 | 建置策略 | 典型詞表規模 |
|---|---|---|---|
| BPE（Byte Pair Encoding） | GPT-2/3/4, LLaMA 1/2/3 | 從字元級開始，反覆合併最頻繁的相鄰對 | 50K–150K |
| WordPiece | BERT, DistilBERT | 類似 BPE，但用似然增益選擇合併 | 30K |
| Unigram + SentencePiece | T5 | 從大詞表剪枝，最小化語料似然損失 | 32K |
| Byte-level BPE | GPT-2, GPT-3/3.5, LLaMA 3 | 將所有字元先轉 UTF-8 位元組再做 BPE | 50K–128K |
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$ 很大時：
- 計算瓶頸： 計算 logits 需要
d_{\text{model}} \times V次乘加，softmax 歸一化需要遍歷 $V$ 個元素。在 decode 階段逐 token 生成時，這一步的 FLOPs 佔比可能超過 30%（小模型）至 10%（大型模型）。 - 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。幾乎所有深度學習架構預設實現這一點。
技術演進史
| 時期 | 代表模型 | 詞表大小 | Tokenizer | 關鍵事件 |
|---|---|---|---|---|
| 2018 | BERT-base/large | 30,522 | WordPiece | 確立 subword 標準，中文 BERT 用 21,128 |
| 2019 | GPT-2 | 50,257 | Byte-level BPE | 首次將 byte-level 思路引入大規模 LM |
| 2020 | GPT-3 | 50,257 | Byte-level BPE | 沿用 GPT-2 tokenizer |
| 2020 | T5 | 32,000 | SentencePiece (Unigram) | Google 的 encoder-decoder 標準 |
| 2022 | ChatGPT/GPT-3.5 | ~100,256 | cl100k_base (tiktoken) | OpenAI 大幅擴充套件詞表，提升多語言效率 |
| 2023-02 | LLaMA 1 | 32,000 | SentencePiece BPE | Meta 開源，中文覆蓋有限 |
| 2023-07 | LLaMA 2 | 32,000 | SentencePiece BPE | 沿用 LLaMA 1 tokenizer |
| 2023-Q3 | Qwen (通義千問) | ~151,936 | Byte-level BPE (自研) | 阿里大幅擴充，中文效率顯著提升 |
| 2024-04 | LLaMA 3 | 128,256 | tiktoken (Byte-level BPE) | Meta 詞表擴大 4×，追趕多語言能力 |
| 2024 | DeepSeek-V2/V3 | ~100K+ | Byte-level BPE [自研/供應鏈估算] | 針對程式碼和中英文最佳化 |
| 2024 | GPT-4o | ~200K [估算] | o200k_base (tiktoken) | OpenAI 進一步擴充套件 |
趨勢： 詞表大小在 5 年內從約 3 萬增長到約 20 萬，增長約 6–7 倍，核心驅動力是多語言覆蓋和推論效率。
技術路線對比
| 維度 | 小詞表（~30K） | 中詞表（~50–100K） | 大詞表（~128–200K） |
|---|---|---|---|
| 代表 | BERT, LLaMA 1/2, T5 | GPT-3, DeepSeek-V2 | LLaMA 3, Qwen2, GPT-4o |
| 序列長度（同一文本） | 最長 | 中等 | 最短 |
| Embedding 引數量（$d$=4096） | ~1.2 億 | 2–4 億 | 5–8 億 |
| 多語言效率 | 較差（非英語系需更多 token） | 中等 | 較好 |
| 稀有 token 嵌入學習 | 相對充分（出現頻率相對較高） | 中等 | 可能不充分 |
| Softmax 計算開銷 | 最低 | 中等 | 最高 |
| Tokenizer 訓練複雜度 | 低 | 中 | 高（需更大語料） |
| KV Cache 節省 | 無 | 部分 | 顯著 |
| 適合場景 | 英語為主、小模型 | 通用 | 多語言、大上下文、長文件 |
上下游
上游：Tokenizer 訓練
上游依賴鏈：
大規模多語言語料 ──→ Tokenizer 訓練（BPE/Unigram）
│
▼
詞表檔案（vocab.json / tokenizer.model / .tiktoken）
│
▼
┌───────────────────────┐
│ 模型訓練/推論 │
│ Embedding層 初始化 │
│ 詞表中每個token分配 │
│ 一個d維向量 │
└───────────────────────┘Tokenizer 訓練的關鍵輸入：
- 語料規模與語言分佈（決定詞表覆蓋哪些語言/領域）
- 目標詞表大小（超引數，需要權衡）
- 特殊 token 配置（
[BOS],[EOS],[PAD], 工具呼叫 token 等）
下游：推論最佳化
詞表大小影響的下游最佳化環節：
| 下游環節 | 影響方式 |
|---|---|
| KV Cache | 詞表大 → 序列短 → KV Cache 小 → 批處理吞吐量提高 |
| Speculative Decoding | 草稿模型和目標模型需共享詞表 |
| FlashAttention | 不直接受 $V$ 影響，但序列長度變短會減少 Attention 計算量 |
| Tensor Parallelism | 輸出層可按 $V$ 維度切分（Megatron 中的 Column Parallel） |
| 量化 | Embedding 層的量化需要與 $V$ 維度配合 |
關鍵指標
| 指標 | 含義 | 典型範圍 |
|---|---|---|
| 詞表大小 $V$ | 不同 token 的總數 | 30K–200K |
| 序列壓縮比 | 原始字元數 / token 數 | 中文：1.5–4.0（取決於 tokenizer） |
| OOV 率 | 無法被詞表覆蓋的 token 比例 | byte-level fallback 時理論為 0 |
| 平均每 token 資訊量 | 語料 bits / token 數 | 詞表越大，通常越高 |
| Embedding 引數佔比 | V \times d / \text{總引數} | 小模型 20–40%；大型模型（70B+）< 5% |
| Top-K 命中率 | 取樣時 Top-K 內 token 的累積機率 | 與詞表大小無直接關係，取決於分佈 |
供需與市場資料
供給側
- Tokenizer 訓練本身計算量低：訓練一個 BPE tokenizer 在單 GPU 上幾小時可完成，不構成瓶頸。
- 真正的成本在於詞表擴充套件後的模型重訓： 當 Meta 將 LLaMA 3 詞表從 32K 擴充套件到 128K，所有嵌入引數需要重新初始化和訓練，且因為序列變短，原有的超引數配置（如學習率、上下文長度）可能需要重新調優。
- Tokenizer 工具生態： HuggingFace Tokenizers、SentencePiece（Google）、tiktoken（OpenAI）為主流開源方案。
需求側
| 需求方 | 對詞表大小的訴求 |
|---|---|
| 中文/日文等非拉丁語系應用 | 需要大詞表（≥100K）以保證編碼效率 |
| 程式碼生成 | 程式碼中大量 ASCII 符號和關鍵詞，需要專門的程式碼 token |
| 長上下文推論 | 更大的詞表 → 更短序列 → 更多有效上下文 |
| 邊緣部署/小模型 | 傾向中等詞表以控制 embedding 引數量 |
| RAG/文件處理 | 專業術語（醫學、法律）可能需要領域特定 token |
量化估算
以一個 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\%
代表公司與資本對映
| 公司/機構 | 詞表策略 | 說明 |
|---|---|---|
| OpenAI | GPT-2: 50K → GPT-3.5: ~100K → GPT-4o: ~200K [估算] | 逐步擴充套件，tiktoken 開源了 tokenizer 實現 |
| Meta | LLaMA 1/2: 32K → LLaMA 3: 128K | 一次性大幅擴充套件 4 倍，追趕多語言能力 |
| BERT: 30K, T5/PaLM: 32K → PaLM: 256K | PaLM 論文[參考 PaLM 論文]使用了約 256K 的大詞表，Gemini 系列未公開具體數字 | |
| 阿里巴巴（Qwen） | ~152K | 自研 tokenizer，中文最佳化程度高 |
| DeepSeek | ~100K+ [供應鏈估算] | 程式碼 + 中英文最佳化 |
| Anthropic (Claude) | 未公開 | 使用自研 tokenizer，具體詞表大小 [未充分揭露] |
| HuggingFace | 開源 Tokenizers 庫 | 為開源社群提供 tokenizer 訓練基礎設施 |
產業鏈關鍵節點：
- 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 萬，核心驅動力是全球化多語言需求和長上下文推論效率。
延伸閱讀與來源
- Sennrich et al., “Neural Machine Translation of Rare Words with Subword Units” (2016) — BPE 演算法原始論文
- Kudo & Richardson, “SentencePiece: A simple and language independent subword tokenizer and detokenizer” (2018) — SentencePiece 方法論
- Radford et al., “Language Models are Unsupervised Multitask Learners” (2019) — GPT-2 的 byte-level BPE tokenizer 設計 [OpenAI 論文]
- Touvron et al., “LLaMA: Open and Efficient Foundation Language Models” (2023) — 32K 詞表設計 [Meta 論文]
- Meta, “Introducing Meta Llama 3” (2024) — 詞表擴充套件到 128K 的說明 [Meta 官方技術部落格]
- OpenAI tiktoken 開源庫 — cl100k_base / o200k_base 詞表大小可通過程式碼直接驗證 [GitHub: openai/tiktoken]
- Qwen 技術報告 — ~152K 詞表的中文最佳化策略 [阿里通義千問官方文件]
- Chowdhery et al., “PaLM: Scaling Language Modeling with Pathways” (2022) — 約 256K 詞表的大規模模型 [Google 論文]
⚠️ 資料口徑說明： 本文中 GPT-4o 詞表大小約 200K 為基於 o200k_base 的 [估算]，Anthropic 詞表大小 [未充分揭露]。DeepSeek 詞表大小為 [供應鏈估算]。其他資料均來自對應模型的技術論文或官方開原始碼。