3.1 训练 Tokenizer

Tokenizer 的作用是把原始文本映射为离散 token 序列，再交给模型做自回归建模；它决定了：

• 文本被切分的粒度（字符级/子词级/词级的折中）
• 同样一段文本会被拆成多少个 token（影响训练/推理效率）
• 词表能否覆盖多语种、专业术语、符号格式（影响可学习性与泛化）
• 数字、标点、混合语言（中英夹杂）等边界情况是否稳定（影响推理可靠性）

一个直观示例（仅用于理解切分行为，不代表真实 tokenizer 输出）：

• 输入：你好世界
• 切分：['你', '好', '世', '界']

真实 tokenizer 往往是子词级（subword），会让常见片段合并成更长 token，同时对罕见片段进行拆分，从而在“覆盖率”和“词表大小”之间取得平衡。

---

1）常见分词算法：BPE / BBPE / WordPiece

具体见LLM架构专栏有详细介绍。

**BPE（Byte Pair Encoding）**的核心思想：从一个初始的基本单位集合出发（通常是字符或字节），不断合并最常见的相邻 token 对，直到达到词表大小上限。

• 优点：实现简单、鲁棒，能在多语种/噪声数据里稳定工作
• 典型用途：通用大规模预训练

**BBPE（Byte-level BPE）**在 BPE 的基础上以“字节”为基本单位，天然覆盖任意字符集（中文、表情、罕见符号等）。

• 优点：不会出现“完全 OOV（词表外）字符”
• 代价：对中文等非拉丁语言，如果合并策略不够充分，可能导致 token 偏碎，序列更长

WordPiece的思想与 BPE 类似，但通常以“最大化似然/概率模型的子词组合”为目标来构造词表（实现与细节在不同框架略有差异）。

• 优点：在某些语料和训练范式下，子词边界更稳定
• 典型用途：早期 NLP 与部分现代模型体系

---

2）中文能力与“二次预训练”的背景

早期许多强模型的训练数据以英文为主，导致在中文任务上出现：

• 中文 token 拆分偏碎（序列过长）
• 中文常见词/专名覆盖不足
• 中英混合文本的边界处理不佳

随着中文数据规模与中文导向模型的出现，这个判断需要更谨慎：一些新模型已经具备很强的中文能力。但在工程实践里仍常见下面的路线：将英文表现优秀的模型，用中文语料继续预训练，期待把其已有的能力迁移到中文任务，并补齐中文语料与 tokenizer 方面的短板。

---

3）训练 tokenizer 的基本流程与机器选择

训练 tokenizer 的核心瓶颈通常是：

• 语料规模大（Common Crawl / 大规模网页 / 书籍 / 对话等混合）
• 需要多轮统计与合并（会产生高内存开销）
• 需要反复扫描大文件（I/O 也可能是瓶颈）

因此常见实践是：选择内存大的 CPU 机器，把大语料做流式统计或分片统计，最终汇总频次并训练词表。

---

4）关键细节与工程经验

4.1 数字切分：避免数值推理“格式陷阱”

数字、日期、小数、科学计数法的切分策略会影响模型对数值的“可组合性”。例如：

• 如果 9.11 被切成一个整体 token，而 9.9 被切成 9、.、9，模型在比较、对齐、复制时会出现不一致的表示习惯，容易诱发错误。
• 另一方面，如果把每个数字都拆成单字符 token，序列会变长，效率变差。

常见目标是让数字具备“稳定、可组合”的表示：

• 连续数字段尽量由更规则的子词构成
• 小数点、负号、百分号等符号边界一致
• 日期/货币/单位表达尽量不出现过多不一致模式

这类问题通常不是靠某一个公式解决，而是靠分词规则 + 语料统计 + 词表约束共同实现。

---

4.2 压缩率：1 个 token 对应多少个汉字

所谓“压缩率”，可以用一个简单的统计指标描述（用于评估 tokenizer 粒度）：

$$\rho =\frac{N_{\text{char}}}{N_{\text{token}}}$$

• $N_{\text{char}}$：统计文本中的汉字/字符数量（定义需一致，比如是否计入标点）
• $N_{\text{token}}$：同一文本被 tokenizer 切分后的 token 数量
• $\rho$ 越大：表示越“压缩”（token 更长），序列更短，推理更快
• $\rho$ 越小：表示越“细碎”（token 更短），序列更长，推理更慢

压缩率的取舍：

• 过低（太碎）：序列长度增加，注意力计算和 KV cache 成本增加，推理延迟变高
• 过高（太粗）：词表会包含大量长 token，可能降低组合泛化能力；同时词表过大也会带来训练与部署成本上升

一个常见经验目标是：中文场景下 $1$ 个 token 映射到约 $1.5$ 个汉字左右（实际取决于语料与算法）。这不是硬指标，而是实践中“效率与泛化”较常见的平衡点。

---

4.3 移除脏 token 与敏感 token

在海量网页语料中，容易出现：

• 乱码片段、异常控制字符
• 非自然语言噪声（脚本碎片、极端重复、无意义拼接）
• 不希望进入模型记忆的敏感字符串

通常会在训练词表前进行：

• 语料清洗（去重、去噪、过滤低质量页面）
• 对候选 token 进行黑名单过滤（包括某些控制字符序列、明显垃圾片段等）

目标不是“完全消除风险”，而是显著降低模型在预训练阶段吸收无价值或高风险片段的概率。

---

4.4 领域 token：提升业务场景的压缩率与可学习性

如果业务场景明确（例如医疗、金融、法律、工业制造），可以把高频且语义稳定的专业词汇优先进入词表，以减少拆分带来的序列膨胀，并提升模型对专业词的稳定表征能力。

例如医疗文本中，如果“药品名/检验项/疾病名”频繁出现，那么把这些术语更倾向于作为整体 token，会带来：

• 更短的序列（推理更快）
• 更稳定的拷贝与引用（减少拼写与断裂）
• 更好的长上下文信息密度（同样长度容纳更多有效信息）

这类策略需要谨慎：领域 token 不宜无限加，否则词表过大、长 token 过多会破坏泛化，且增大 embedding 参数规模与训练难度。

---

4.5 多语覆盖：中英覆盖率与小语种策略

常见目标是：

• 中英覆盖率足够大（网页与代码、术语、缩写混杂很普遍）
• 小语种是否加入取决于业务需求与数据占比

如果小语种数据占比很低但被强行纳入，会出现：

• 词表容量被稀释
• 主语言压缩率下降
• 训练预算被低收益部分消耗

---

4.6 预留“词表余量”：为后续对齐与扩展留空间

实践中常会在 $vocab\_size$ 与模型的 embedding 表规模之间预留一定余量，以支持后续阶段加入新 token 并训练其 embedding。直观原因是：后续对齐/业务适配阶段可能需要引入预训练阶段未充分覆盖的符号、特殊标记、领域新词等。

---

5）词表扩充：在原词表基础上补齐中文 token

很多情况下不从零训练 tokenizer，而是：

1. 保留原始 tokenizer 的主体结构（兼容已有生态与权重）
2. 手动或半自动扩充词表（加入常见汉字/常用片段/领域词）
3. 针对新增 token 的 embedding 做额外训练（让新 token 能被模型有效利用）

典型做法是：新增大量汉字 token，以降低中文文本的过度拆分；随后使用较大规模中文语料对新增 token 的 embedding 进行训练，从而让模型快速适应中文。

这一策略的优点：

• 与原模型权重、推理系统更兼容
• 用较小成本改善中文表示与压缩率
• 对“中英混合”场景更友好

需要注意：

• 新增 token 越多，embedding 参数增长越明显
• 如果新增 token 覆盖不合理，可能造成词表冗余与学习困难

---

2.3.2 确定模型结构和参数

在现代 LLM 预训练中，模型结构通常采用成熟的 Transformer Decoder-only 体系，并结合一套高性能、工程化程度高的组件组合，例如：

• RoPE（旋转位置编码）
• GQA（Grouped-Query Attention）
• RMSNorm（均方根归一化）
• SwiGLU（门控前馈激活）

这套组合的目标非常务实：在保持性能的同时，让训练更稳定、推理更高效。

---

1）典型结构组件的作用

1.1 RoPE：更自然的相对位置建模与长上下文扩展

RoPE 将位置信息以“旋转”的方式注入到注意力的 $Q,K$ 向量中，使得注意力能够更自然地表达相对位置信息，并在长上下文扩展中具备较好的可扩展性（实际还需要配合插值/外推策略与训练数据分布）。

---

1.2 GQA：在 MHA 与 MQA 之间折中

注意力中，Query 头多样性对表达能力重要，但 Key/Value 的缓存是推理的主要显存开销之一。GQA 通过“多组 Query 共享一组 KV”在性能与缓存之间取得平衡：

• 相比 MQA（所有 Query 共享 KV），表达能力更强
• 相比 MHA（每个头独立 KV），KV cache 更省

这对大模型部署、长上下文推理、吞吐优化非常关键。

---

1.3 RMSNorm：更简洁稳定的归一化

RMSNorm 相比 LayerNorm 通常实现更简单、开销更小，且在大规模训练中常见到良好的稳定性表现。其核心是基于均方根进行尺度归一化，而不显式减去均值。

---

1.4 SwiGLU：更强的门控前馈层

门控结构通过“选择性通过信息”增强表达能力。以 SwiGLU 为例，前馈层不再是单一路径的非线性变换，而是引入门控分支，使得网络能学习“哪些特征该被放大/抑制”。

---

2）模型规模与资源估算：显存、精度与训练策略

模型大小（例如 7B/14B/30B/70B）与训练资源（显存、并行策略、优化器与精度）强相关。下表是一个工程上的简要参考（同一规模在不同实现、序列长度、并行策略下会有差异）：

Method	Bits	7B	14B	30B	70B	xB
Full (fp32)	32	120GB	240GB	600GB	1200GB	～18xGB
Full (pure_bf16)	16	60GB	120GB	300GB	600GB	～8xGB
Freeze/LoRA/GaLore/APOLLO/BAdam	16	16GB	32GB	64GB	160GB	～2xGB
QLoRA	8	10GB	20GB	40GB	80GB	～xGB
QLoRA	4	6GB	12GB	24GB	48GB	～x/2GB
QLoRA	2	4GB	8GB	16GB	24GB	～x/4GB

理解这张表的关键点：

• 精度越高（fp32 > bf16），参数与优化器状态占用越大，训练更稳但成本更高
• **PEFT/冻结策略（LoRA 等）**减少可训练参数与优化器状态，显存需求显著下降
• **量化训练（QLoRA）**进一步压缩存储与带宽，但需要额外关注数值稳定性、吞吐与实现细节

一个常见的实际决策路径是：

• 资源充足：优先 bf16 全参训练（效果与稳定性更一致）
• 资源受限：采用 PEFT 或 QLoRA（更快落地，成本更低）
• 需要极致部署：推理端再做量化与 KV cache 优化

---

2.3.3 训练框架选择

预训练框架的选择，直接影响：

• 训练吞吐（tokens/s）
• 大规模并行（TP/PP/DP）的可用性与稳定性
• 工程可维护性（参数可控、日志完备、复现容易）
• 大模型启动与加载速度（尤其是百亿/千亿规模）

在工程实践中，预训练通常优先选择 Megatron-LM 一类专为大规模训练优化的框架；如果模型体系与生态更贴近某个具体实现（例如 Qwen 系），则可选择相应的 Megatron patch 方案，以减少适配成本并复用社区优化。

同时，预训练阶段一般不优先使用以“训练灵活性”为主的通用框架来替代高度工程化的预训练框架，尤其是在追求极限吞吐与大规模并行稳定性时。

---

1）为何优先选择 Megatron-LM

1.1 训练速度快：并行策略成熟

Megatron-LM 在以下方面积累深厚：

• Tensor Parallel（张量并行）
• Pipeline Parallel（流水线并行）
• Data Parallel（数据并行）与高效通信
• 针对注意力、RoPE、MLP 等关键算子优化

对于大规模预训练，“吞吐”往往是第一生产力：同样训练预算下，吞吐越高意味着可训练 token 越多，或者可更快完成同等训练。

---

1.2 参数体系清晰：可控的工程入口

预训练需要大量可调参数：

• 并行配置（TP/PP/DP）
• dropout、正则、梯度裁剪
• 激活重计算（checkpointing）
• 混合精度与损失缩放
• 序列长度、打包策略、数据混合比例
• 学习率 warmup 与衰减策略等

一个结构化、可追踪的参数系统，能显著降低“训练跑起来但不可控/不可复现”的风险。对于需要多次实验迭代的团队来说，这点尤为关键。

---

1.3 启动与加载速度快：大规模调试成本更低

当模型规模上升到数十亿甚至上百亿参数时：

• 权重加载与分片初始化可能成为瓶颈
• 训练脚本的 debug 成本显著上升
• 一个小问题可能导致整套分布式作业重启

预训练框架如果能做到快速加载与稳定启动，会显著提升整体研发效率。

---

2）一个实际决策案例：从“目标”倒推框架与配置

假设目标是训练一个中文增强的 7B 模型：

• 数据：中文网页 + 通用语料混合
• 需求：兼顾中英与数字格式稳定性
• 资源：多机多卡，追求高吞吐

典型选择会是：

1. tokenizer：采用 BBPE 或 BPE，并对中文高频片段做适度合并与扩充
2. backbone：RoPE + GQA + RMSNorm + SwiGLU 的稳定结构
3. 框架：Megatron-LM（或针对特定模型生态的 Megatron patch）
4. 训练精度：优先 bf16 全参；资源受限则考虑 PEFT/QLoRA 路线用于快速验证数据与策略

这样组合的核心逻辑是：把不可控因素（分布式稳定性、吞吐瓶颈、算子性能）交给成熟框架，团队把主要精力放在数据与训练策略上。