预训练：从 32T tokens 到 Base 模型

万亿参数不是堆出来的 — DeepSeek V4 预训练工程的全栈优化 | 预计阅读时间：25 分钟

---

一、引言

在前几篇文章中，我们拆解了 DeepSeek V4 的架构创新：MoE 专家路由、CSA+HCA 混合注意力、mHC 流形约束超连接。这些架构层面的设计决定了模型能力的上限——但一个 1.6T 参数的模型不会凭空长出来。它需要通过数万亿 token 的训练，把随机初始化的参数变成有意义的表征。

这就是预训练的价值。预训练是大模型能力的根基。

2024 年底发布的 DeepSeek V3 用了 14.8T tokens 训练，总成本约 560 万美元。一年后，V4 把规模翻了一倍多——32T tokens，1.6T 参数，且在华为昇腾 950PR 芯片上完成训练。参数量翻了两倍多，训练数据翻了一倍，而硬件平台还从英伟达切换到了国产芯片。这中间的工程挑战远比"多加几块 GPU"复杂得多。

具体来说，V4 的预训练工程在以下几个层面做了全栈优化：

• 数据层面：32T tokens 的数据清洗、去重、质量打分、多语言配比——数据工程决定了下限
• 词表层面：128K 超大词表的设计与训练——tokenizer 的效率直接影响训练和推理成本
• 训练策略层面：学习率调度、batch size 动态调整、3D 并行策略——让万亿参数训练可持续
• 量化层面：FP4 量化感知训练——把 MoE 权重的显存需求直接腰斩
• 算子层面：MoE 融合内核 + MegaMoE 超级内核——让通信和计算不再互相等待
• 稳定性层面：Loss Spike 防护、梯度裁剪、确定性内核——确保 32T tokens 的训练不白跑

这些优化不是孤立的。数据工程要为词表设计提供语料分布依据，FP4 量化需要训练策略配合，融合算子的设计又受量化方案影响。所有环节咬合在一起，才构成了 V4 的完整预训练管线。

本文按"数据 → 词表 → 训练 → 量化 → 算子 → 稳定"这条链路，逐层拆解 V4 的预训练工程。读完你会理解：32T tokens 的预训练不是简单的"堆数据"，而是一整套系统工程的艺术。

---

二、数据工程

2.1 32T tokens 从哪来

DeepSeek V4 的预训练数据总量是 32T tokens——几乎是 V3（约 14.8-18T tokens）的两倍。但这个数字不是简单的"从互联网上扒了 32T 文本"，而是经过多轮清洗、筛选、配比后的最终训练语料。

数据来源大致分为三类：

来源类别	占比	说明
互联网爬取	~65%	网页文本、论坛、博客、新闻，来自 CommonCrawl 及自有爬虫
结构化知识	~20%	学术论文、技术文档、百科全书、法律条文、财报
代码与推理	~15%	GitHub 代码仓库、竞赛题解、数学证明、逻辑推理数据集

和 V3 相比，V4 的数据来源有三大变化：

第一，长上下文数据的占比大幅提升。 V4 支持 1M token 上下文窗口，预训练数据中包含了大量长文档（书籍、技术手册、完整代码仓库），让模型在预训练阶段就开始学习长距离依赖关系。V3 的长文档占比约 8%，V4 提升到了约 18%。

第二，高质量学术数据的增加。 V4 显著增加了 arxiv 论文、教科书、学术期刊的收录比例。这一点从 V4-Pro-Base 在 SimpleQA-Verified 上的得分可以验证——55.2% 对比 V3.2 的 28.3%，几乎翻倍。世界知识的广度直接受益于高质量学术数据。

第三，合成数据的引入。 32T tokens 的规模超出了纯互联网数据的质量瓶颈。V4 使用了相当比例的合成数据——通过已有模型生成高质量文本、数学推理步骤、代码注释等，再进行质量过滤。这部分数据占比估计在 30-40% 左右，与 Kimi 和 Trinity 等模型的策略接近。

2.2 数据清洗流水线

32T tokens 的原始数据不能直接拿来训练。DeepSeek 的数据清洗流水线包含五个核心阶段，每个阶段都对数据做一次"瘦身"：

原始数据 → 去重 → 毒性过滤 → 质量打分 → 多语言配比 → 最终语料

第一阶段：去重

去重是清洗流水线的第一道关。V4 使用了多层级去重策略：

去重层级	方法	压缩比例
URL 级别	去除重复 URL 的页面	~20%
文档级别	MinHash + LSH 近似去重	~30%
段落级别	SimHash 检测重复段落	~15%
句子级别	n-gram 覆盖度检测	~10%

经过四层去重，原始数据量大约压缩到初始的 50-55%。

第二阶段：毒性过滤

使用基于 BERT 的分类器对数据进行安全过滤。过滤维度包括：暴力内容、色情内容、仇恨言论、个人隐私信息（PII）。这一阶段大约移除 3-5% 的数据。

第三阶段：质量打分

V4 使用了一个专门训练的 quality scorer 模型（基于 DeBERTa 架构），对每条文档从以下维度打分：

• 信息密度（30% 权重）：文本中有效信息与冗余的比例
• 事实准确性（25% 权重）：与已知知识库的一致性
• 语言规范性（20% 权重）：语法正确性、用词精准度
• 可读性（15% 权重）：句子长度、词汇多样性
• 领域价值（10% 权重）：对该领域的知识覆盖度

分数低于阈值的文档被丢弃。这一阶段是"瘦身"最狠的——大约移除 25-30% 的低质量数据。

第四阶段：多语言配比

经过前三阶段清洗后的数据，按语言重新配比。V4 的目标配比如下：

语言族群	目标占比（V4）	对比 V3
中文	~42%	~45%
英文	~35%	~32%
代码（多语言）	~15%	~13%
其他语言	~8%	~10%

相比 V3，V4 的英文和代码占比略有提升，中文和其他语言略有下降。这反映了 V4 在全球知识覆盖和代码理解能力上的强化目标。

2.3 多语言策略的细节

多语言数据处理不只是"按比例混合"这么简单。V4 在数据工程上有一些更细致的策略：

对低资源语言（泰语、越南语、阿拉伯语等），V4 使用了回译（back-translation）技术做数据增强——先把低资源语言的文本翻译成中文或英文，再翻译回去，通过一致性校验保留高质量的样本。

对代码数据，V4 做了两个重要改进：一是增加了"代码 + 注释"的对齐数据（即代码文件同时带有高质量的文档注释），二是包含了更多完整的项目级代码（多文件仓库），而不是只有零散的代码片段。这对于模型理解代码的跨文件结构和依赖关系至关重要。

对数学数据，V4 不仅增加了数量，还在质量上做了精细筛选——过滤掉推导不完整、存在逻辑跳跃的数学文本，保留步骤完整、逻辑链清晰的样本。

2.4 数据质量对模型的影响

2.5 数据对长上下文能力的支撑

V4 支持 1M token 上下文窗口，这和预训练数据工程密切相关。如果预训练数据中大部分是短文本（几百个 token 的网页、新闻），模型在预训练阶段就"没见过"长序列，后续即使使用了长上下文注意力机制，效果也会大打折扣。

V4 的策略是在预训练数据中逐步增加长序列的比例：

训练阶段	Token 范围	长文档占比	说明
第一阶段	0-10T tokens	~8%	以短文本为主，基础语言能力训练
第二阶段	10-22T tokens	~15%	逐步增加长文档、书籍、完整代码库
第三阶段	22-32T tokens	~25%	大量长文本，为 1M 上下文做适配

这种"渐进式长上下文训练"和 V4 的 batch size 调度类似——训练初期模型还在学习基础语言能力，不需要大量长序列；训练后期，基础能力已经稳定，通过增加长序列让模型学习长距离依赖，为 1M 推理上下文做好准备。

2.6 数据工程的价值量化

数据工程的价值最终体现在模型能力上。以下是 V4 在 V3 基础上的知识能力提升：

评测基准	V3	V3.2	V4-Pro-Base	提升幅度（V3→V4）
SimpleQA-Verified	18.5%	28.3%	55.2%	+36.7 个百分点
MMLU-Pro	52.5%	59.1%	66.8%	+14.3 个百分点
GPQA-Diamond	32.6%	38.7%	44.1%	+11.5 个百分点
HLE（超难推理）	6.4%	8.9%	14.2%	+7.8 个百分点

SimpleQA-Verified 的翻倍提升是最有力的证据——当模型看到更多高质量、多领域的文本，它的世界知识自然变得更广博。这不仅仅是参数量增加的功劳，更是数据工程的结果。

---

三、词表设计

3.1 128K 超大词表

DeepSeek V4 的词表大小是 128K（131,072 个 token），相比 V3 的 100K（102,400 个 token）增加了 28%。这个选择看起来简单，但背后有很深的工程考量。

词表大小和模型效率之间存在一个"不可能三角"：

• 词表越大 → 每个 token 编码的信息越多 → 序列长度缩短 → 训练和推理更快
• 词表越大 → embedding 矩阵越大 → 显存占用越高 → softmax 计算越慢
• 词表越小 → 子词切分更细 → 需要更多 token 表达相同内容 → 效率降低

V3 的 100K 词表已经在推理效率和 embedding 开销之间取得了很好的平衡。V4 推高到 128K，是因为以下原因：

第一，多语言编码效率。 128K 词表允许加入更多中文字词、英文子词和其他语言的高频单元。V4 的 128K 词表中，中文 token 覆盖了约 45K（V3 约 35K），英文约 55K（V3 约 42K），其他语言约 15K（V3 约 10K），特殊 token 约 13K。

第二，代码 token 的优化。 代码中有大量特定子词模式（如 _init_、isinstance、torch.cat 等）。更大的词表可以将这些高频代码 token 编码为单个 token，提高代码场景的训练和推理效率。

第三，序列长度压缩。 128K 词表相比 100K 词表，对于同等长度的中文文本，token 数量大约减少 8-12%。在 1M 上下文窗口下，这个压缩直接转化为显存节省。

3.2 与 V3 词表的对比

指标	V3	V4	变化
词表大小	100,224	131,072	+30,848 (+30.8%)
中文覆盖	~35K tokens	~45K tokens	+28.6%
英文覆盖	~42K tokens	~55K tokens	+31.0%
其他语言	~10K tokens	~15K tokens	+50%
特殊 token	~8K tokens	~13K tokens	+62.5%
中文压缩比	~1.8 token/字	~1.6 token/字	-11% 更好
英文压缩比	~2.8 token/词	~2.6 token/词	-7% 更好
代码压缩比	~3.2 token/操作	~2.8 token/操作	-12.5% 更好

更大的词表带来了明显的压缩率提升——中文场景下，同样一段 1000 字的文章，V4 只需要约 1600 个 token，而 V3 需要约 1800 个。对于每天处理数十亿 token 的 API 服务，这 11% 的差异就是实打实的成本节省。

3.3 Tokenizer 训练细节

DeepSeek V4 的 tokenizer 采用 Byte-level BPE（Byte Pair Encoding） 算法，训练语料来自经过清洗的 32T tokens 数据的一个子集（约 2.5T tokens，按多语言配比采样）。

训练过程的特点：

语料配比。 Tokenizer 训练语料的多语言配比和最终训练数据的配比不同——tokenizer 训练时，低资源语言被过采样（oversample）了 3-5 倍，以确保词表对这些语言的高频单元有足够覆盖。如果按自然分布，低资源语言在词表中可能只有几百个 token，严重影响编码效率。

合并决策的平衡。 BPE 训练过程中，合并频率最高的 token pair 不一定总是"最优"的。V4 的 tokenizer 训练使用了一个带正则化的合并策略——对跨语言合并做惩罚，避免不同语言的字符被合并到同一个 token 中（例如中文字符和英文字符被合并为同一个 token 不会提升编码效率）。

词表裁剪。 初始训练生成的候选 token 数量超过 200K，经过以下裁剪策略压缩到 128K：

1. 移除出现频率低于阈值的 token
2. 移除长度过长的 token（> 8 个字符原则上不保留，除非是高频短语）
3. 按语言覆盖度做最终筛选

---

四、训练配置

4.1 模型配置概览

在进入训练策略之前，先回顾 V4 两个版本的关键架构参数：

参数	V4-Pro	V4-Flash
总参数量	1.6T	284B
激活参数量	49B	13B
Transformer 层数	61	43
隐藏维度	7,168	4,096
注意力头数	64	32
专家数（MoE）	256	128
激活专家数（Top-K）	8	6
词表大小	128K	128K
上下文长度	1M	1M
训练 token 数	32T	32T

4.2 优化器配置

V4 的训练使用混合优化器策略：

参数组	优化器	学习率	Weight Decay	说明
注意力参数	Muon	2e-4（Pro）/ 4e-4（Flash）	-	矩阵权重，Muon 优选
MoE 专家权重	Muon	2e-4（Pro）/ 4e-4（Flash）	-	梯度稀疏，Muon 更稳定
FFN 权重	Muon	2e-4（Pro）/ 4e-4（Flash）	-	矩阵权重
Embedding	AdamW	2e-4（Pro）/ 4e-4（Flash）	0.1	非矩阵结构
LayerNorm	AdamW	2e-4（Pro）/ 4e-4（Flash）	0	标量参数
输出头	AdamW	2e-4（Pro）/ 4e-4（Flash）	0.1	非矩阵结构

关于 Muon 的详细原理和与 AdamW 的对比，第 04 篇文章已做了充分讨论。此处不再展开。

学习率调度采用标准的三段式：

1. Warmup 阶段（前 2,000 步）：学习率从 0 线性上升到峰值。
2. 主训练阶段：使用 Cosine Decay（余弦退火）将学习率逐步降低到峰值的 10%。
3. 稳定收敛阶段（最后 5% 训练步数）：学习率固定在峰值的 10%，做精细调优。

峰值学习率的确定经过了多轮小规模实验：在 27B 参数的测试模型上，分别测试了 1e-4、2e-4、4e-4、8e-4 四组学习率，根据验证集困惑度选择最优值。结果显示两个版本的峰值学习率差异较大——Pro 因为参数量大、训练更稳定，选择较低的 2e-4；Flash 因为更轻量，可以用 4e-4 加速收敛。

Batch size 调度同样不是固定值。训练初期使用较小的 batch size（约 512 序列），随着训练进行逐步增大到 4,096 序列。这种"渐进式 batch size"策略的好处是：训练初期模型还很"幼稚"，小 batch 提供更多梯度更新步骤，有利于快速探索参数空间；训练后期模型已经接近收敛，大 batch 提供更稳定的梯度估计，避免震荡。

4.3 3D 并行策略

1.6T 参数的模型不可能装进一张 GPU。V4 的分布式训练使用了数据并行（Data Parallelism, DP）、张量并行（Tensor Parallelism, TP）、流水线并行（Pipeline Parallelism, PP） 的三层并行策略。

并行维度	切片方式	适用场景	通信开销
数据并行（DP）	按 batch 维度切分	数据无关的计算	梯度同步（低频）
张量并行（TP）	按权重矩阵维度切分（行/列）	单层内的矩阵乘法	All-Reduce（高频）
流水线并行（PP）	按层切分	不同层之间的计算	激活传递（低频）

三层并行的协调方式如下：

GPU 集群组织
├── DP Group 0 (64 GPUs)
│   ├── TP Group 0 (8 GPUs)    ← 每 8 GPU 做张量并行
│   │   ├── PP Stage 0 (1 GPU) ← 前几层
│   │   ├── PP Stage 1 (1 GPU) ← 中间层
│   │   └── PP Stage 2 (1 GPU) ← 最后几层
│   ├── TP Group 1 (8 GPUs)
│   └── TP Group 2 (8 GPUs)
├── DP Group 1 (64 GPUs)
└── DP Group ... (多组)

对于 V4-Pro 的 1.6T 参数量，DeepSeek 使用了约 2,048 张华为昇腾 950PR 芯片完成训练。TP=8（每组 8 卡做张量并行）、PP=3（3 段流水线）、DP=85（约 85 组数据并行），构成了完整的并行拓扑。

4.4 专家并行与通信优化

MoE 模型的并行比普通 Transformer 更复杂——因为专家分布在不同的 GPU 上，token 需要跨 GPU 路由。

V4 在 MoE 层的并行上使用了细粒度专家并行（Fine-grained Expert Parallelism, EP） 方案。具体来说：

• 每个专家被分配到一张或多张 GPU 上
• Router 在每个 GPU 上独立计算，确定 token 要发送到哪些远程专家
• Token 通过 All-to-All 通信发送到对应的 GPU
• 专家计算完成后，结果通过 All-to-All 返回

这个过程的关键瓶颈是 All-to-All 通信。在 V3 中，通信和计算是串行的——先发 token，再算，再收结果。V4 的 EP 方案通过流水线化实现了通信和计算的重叠：当 GPU 在计算第一批 token 的专家输出时，第二批 token 的 All-to-All 传输同时在后台进行。

细粒度 EP + DualPipe 的组合是 V4 的关键工程选择。DualPipe 是一种 1F1B（一个前向、一个反向）的流水线调度方案，和标准流水线并行（GPipe 的同步调度）相比，DualPipe 的"异步重叠"特性让流水线气泡（pipeline bubble）大幅减少。V4 将 DualPipe 从层间并行（PP）扩展到了专家并行（EP）层面——当 GPU 在处理第 N 个 micro-batch 的前向计算时，第 N+1 个 micro-batch 的 All-to-All 通信已经在进行。这种"计算-通信双管道"的设计让 EP 的通信开销几乎被完全隐藏。

为了进一步减少 EP 的通信量，V4 还使用了随机舍入策略：MoE 梯度在不同 rank 之间同步时，从 FP32 降采样到 BF16，并使用两阶段策略避免低精度加法引起的累积误差。

这种细粒度的通信-计算重叠方案在 V4 中得到了双重验证——在英伟达 H800 GPU 和华为昇腾 950PR NPU 上均测试通过。这是 DeepSeek V4 跨硬件适配能力的重要体现。

---

五、FP4 量化训练

5.1 为什么需要 FP4

大模型训练中，显存是最稀缺的资源。对于一个 1.6T 参数的 MoE 模型：

• 模型权重（FP8）：约 1.6 TB
• 优化器状态（动量，FP32）：约 6.4 TB 对比 AdamW 的 12.8 TB（因为 Muon 省掉了二阶矩）
• 梯度（FP8）：约 1.6 TB
• 激活值（中间计算）：取决于 batch size，数 TB

即使使用了 Muon 节省了一半优化器状态，总显存需求仍然在 10 TB 以上。按每张华为昇腾 950PR 的 80 GB 显存计算，需要超过 2,000 张 NPU。

FP4 量化训练的目标很简单：砍掉一半的权重显存。

5.2 量化感知训练（QAT）的原理

DeepSeek V4 对 MoE 专家权重和 CSA indexer 的 QK 路径使用了 FP4 量化感知训练（Quantization-Aware Training, QAT）。

"感知训练"的含义是：与其在训练完成后强行量化模型、承受精度损失，不如在训练过程中就让模型"预演"低精度计算，提前适应量化带来的数值扰动。

V4 的 FP4 QAT 流程如下：

前向传播：
FP32 主权重 → FP4 量化 → FP8 反量化 → FP8 计算 → FP32 输出
                    ↓
              存为 FP4 推理权重

反向传播：
梯度 → 直接传回 FP32 主权重（通过 STE）

关键步骤说明：

1. 主权重保持 FP32。 模型的"真实"参数始终以 FP32 精度存储和更新。这保证了训练的精度不会持续下降。
2. 前向传播时模拟量化。 每次前向计算前，将 FP32 权重先量化到 FP4（MXFP4 格式），然后反量化到 FP8 参与实际计算。这个过程叫"模拟量化"——计算是在 FP8 上进行的，但模型"体验"了 FP4 量化带来的数值精度损失。
3. 使用 Straight-Through Estimator（STE）处理梯度。 量化操作在数学上不可微——你可以把它想象成一个"四舍五入"的操作，导数几乎处处为 0。STE 的解决思路很粗暴：前向传播走量化后的权重，反向传播假装量化操作不存在，直接把梯度传回 FP32 权重。实践证明这个"骗梯度"的方法在 QAT 中非常有效。
4. 推理时直接使用 FP4 权重。 训练完成后，FP4 权重直接被用于推理，不再经过"量化→反量化"的模拟过程。这带来实际的速度和显存收益。

5.3 FP4 在哪些地方量化

V4 的 FP4 量化不是"全盘量化"，而是选择性地应用于两个关键组件：

组件	是否 FP4 量化	原因
MoE 专家权重（up/down/gate 投影）	是	占权重的大头，量化收益最大
CSA Indexer QK 路径	是	计算密集，FP4 tensor core 算力翻倍
注意力 QKV 投影	否（FP8）	对精度敏感，FP8 已经足够
Embedding 层	否（FP8）	稀疏计算，量化收益有限
LayerNorm / RMSNorm	否（FP32）	小计算量，精度要求高
路由器	否（FP8/FP32）	计算量小，路由精度影响大

这种选择性量化策略是 V4 的一个关键工程决策——不为了量化而量化，只在量化收益大于精度损失的场景下使用 FP4。

5.4 性能对比：FP4 vs FP8 vs INT8

以下是不同量化方案在 V4 典型配置下的对比：

指标	FP8（无 QAT）	FP8（QAT）	FP4（QAT）	INT8（QAT）
权重显存	1.6 TB	1.6 TB	0.8 TB	0.8 TB
相对 FP8 性能损失	-	<0.5%	<1%	~3-5%
训练吞吐量（相对）	1.0x	0.98x	1.15x	0.95x
推理吞吐量（相对）	1.0x	1.0x	1.3-1.5x	1.1x
量化训练额外开销	无	~5%	~8%	~10%
硬件支持	广泛（H100/昇腾）	有限（部分支持）	有限（昇腾 950PR 原生支持）	广泛

FP4 QAT 在 V4 中的表现可以说是"超预期"——性能损失控制在 1% 以内，但权重显存减半、推理吞吐量提升 30-50%。这背后的原因有两个：

第一，MoE 专家的权重冗余度天然高。 MoE 专家之间参数隔离，单个专家本身不需要极高的精度来维持整体模型能力。FP4 对单个专家的精度损失，在 MoE 的多个专家加权组合过程中被"平均"掉了。

第二，FP4 在昇腾 950PR 上有硬件加速。 华为昇腾 950PR 的 Da Vinci 架构原生支持 FP4 计算，FP4 tensor core 的理论算力是 FP8 的两倍。这和技术报告中的一段说明一致——V4 的验证覆盖了英伟达和华为两种平台，但量化方案的硬件优化主要针对昇腾。

5.5 训练与推理中的 FP4 差异

FP4 在训练和推理阶段的使用方式是不同的，这是一个容易被忽略的细节：

阶段	FP4 使用方式	目的
预训练前向	模拟量化（FP32→FP4→FP8→计算）	让模型适应低精度计算
预训练反向	STE（梯度直接通过量化层回传）	保持梯度精度
RL 训练	实际 FP4 权重（不模拟）	采样行为与部署一致
推理	实际 FP4 权重	速度 + 显存收益

在 RL 训练（强化学习后训练阶段）中，V4 直接使用实际的 FP4 量化权重进行前向推理，而不是模拟量化。这样做的目的是保证 RL 采样时的模型行为与线上部署完全一致——如果 RL 阶段使用模拟量化，RL 优化出的策略在真正部署时可能因为量化精度的微小差异而表现不同。

5.6 FP4 Indexer

除了权重量化，V4 还对 CSA indexer 做了 FP4 优化：

CSA indexer 的 QK 路径全程跑在 FP4 上。 传统 attention 中，query 和 key 的内积通常用 FP16 或 FP8 计算。V4 将 indexer 的 Q 和 K 矩阵都量化到 FP4，然后做内积。这带来的效果是：

• 算力翻倍：FP4 tensor core 相比 FP8 算力翻倍
• 带宽降低：权重的加载带宽降到 FP8 的 1/2（FP8 的带宽需求已经是 FP16 的一半）
• 召回率保持：FP4 量化后，KV 条目的召回率保持在 99.7%

召回率 99.7% 意味着：由于 fp4 量化而被"漏掉"的相关 KV 条目只有 0.3%，对注意力效果的影响可以忽略。这个数字是 V4 敢在 indexer 上使用 FP4 的底气。

---

六、MoE 融合算子

6.1 传统 MoE 执行的性能瓶颈

一个标准的 MoE 层执行流程包含四个步骤：

1. 门控计算（Gating）：Router 网络为每个 token 计算专家亲和度分数 → 访存密集
2. Token 分发（Dispatch）：根据路由结果将 token 发送到对应专家所在的 GPU → 通信密集
3. 专家计算（Expert FFN）：每个专家执行前馈计算（通常是 up/gate/down 三个投影） → 计算密集
4. 结果合并（Combine）：将所有专家输出按权重加权求和 → 通信密集

在传统实现中，这四步是串行的——每步之间有显存搬运和 kernel launch 开销。具体来说：

传统 MoE 执行流程
Step 1: 门控计算 → 写 HBM
Step 2: 读取门控结果 → Dispatch → 写 HBM  
Step 3: 读取 token → 专家 FFN → 写 HBM
Step 4: 读取专家输出 → Combine → 写 HBM

每一步的"写 HBM"和"从 HBM 读"都伴随着数十甚至上百微秒的 kernel launch 延迟。 当专家数量达到 256（V4-Pro）时，这些"小碎步"的开销被放大到难以忽视的程度。在 V4 的 profiling 数据中，传统 MoE 执行的 kernel launch 开销占总时间的 15-25%。

6.2 融合设计的思路

V4 的 MoE 融合内核（Fused MoE Kernel） 将这些步骤整合为一个单一的 GPU kernel：

融合后的 MoE 执行流程
Step 1-4: 门控 → Dispatch → 专家 FFN → Combine（全部在 GPU 片上完成）

核心变化是：中间结果不写回 HBM，直接在 GPU 的 SRAM（共享内存）中流转。 具体来说：

1. Gating 计算的分数直接留在共享内存中，被 Dispatch 步骤消费
2. Token 在共享内存中完成路由，数据直接传递给对应的专家计算单元
3. 专家 FFN 的中间激活同样留在共享内存，被 Combine 步骤消费
4. 最终输出直接写回 HBM，省掉了所有中间结果的读写

这种设计的挑战在于共享内存的大小管够不够。V4-Pro 的隐藏维度是 7,168，单个 token 的中间状态约 28 KB（FP8 下）。H100 的共享内存是 228 KB（每个 SM），昇腾 950PR 的共享内存约 192 KB。一个融合 kernel 需要同时处理 4-8 个 token 才能在吞吐量上达到最优——共享内存刚好够用。

6.3 TileLang 实现

MoE 融合内核使用 TileLang 实现。TileLang 是 DeepSeek 内部开发的领域特定语言（DSL），用于高效生成 GPU/NPU 内核代码。它的设计思路和 TVM/TIR 类似，但针对大模型训练中的 MoE 场景做了专门优化。

一个简单的 TileLang 融合内核伪代码：

// TileLang 伪代码：MoE 融合内核
func fused_moe_kernel(tokens: Tensor, experts: Tensor, router: Tensor) {
    // Step 1: Gating — 在共享内存中计算路由分数
    shared_gates = matmul(tokens, router) @ shared_memory
    
    // Step 2: Dispatch — 根据路由分数分配 token 到专家
    // 不写回 HBM，直接在共享内存中操作
    dispatched_tokens = dispatch(tokens, shared_gates) @ shared_memory
    
    // Step 3: Expert FFN — 在共享内存中执行专家计算
    // up/gate/down 三层投影
    expert_out = matmul(dispatched_tokens, experts.up) @ shared_memory
    expert_out = silu(expert_out)
    expert_out = matmul(expert_out, experts.down) @ shared_memory
    
    // Step 4: Combine — 加权聚合专家输出
    result = combine(expert_out, shared_gates)
    
    // 最终结果写回 HBM
    write_to_hbm(result)
}
```TileLang 是 DeepSeek 内部开发的领域特定语言（DSL），用于高效生成 GPU/NPU 内核代码。

TileLang 的选择不是偶然的。它有以下几个优势：

**第一，硬件无关的算子描述。** 你在 TileLang 中写的是"对矩阵 A 和矩阵 B 做某种运算"，而不是"用 CUDA 的某种 warp-level 原语"。同一个 TileLang 程序可以编译为英伟达 CUDA 内核和华为昇腾 CANN 内核。这对于 V4 需要在两种硬件平台上验证的需求来说，至关重要。

**第二，自动融合优化。** TileLang 的编译器可以自动识别相邻操作之间的数据依赖关系，决定哪些中间结果应该留在片上、哪些应该写回 HBM。开发者只需要用 TileLang 描述"计算逻辑"，编译器负责"计算调度"。

**第三，确定性保证。** 标准 CUDA 内核由于 warp 调度顺序的不确定性，在多 GPU 训练中可能存在数值不一致的问题。TileLang 编译器强制规定了计算顺序的确定性策略，确保每次运行得到相同的数值结果。

### 6.4 加速效果

DeepSeek 技术报告中公布了融合内核在各种负载下的加速数据：

| 负载场景 | 传统实现 | 融合内核 | 加速比 |
|---------|---------|---------|-------|
| 通用推理（BF16） | 基线 | 优化后 | **1.50-1.73x** |
| 时延敏感场景（RL 采样） | 基线 | 优化后 | **1.70-1.96x** |
| 训练前向（FP8） | 基线 | 优化后 | **1.35-1.52x** |
| 训练反向（FP8） | 基线 | 优化后 | **1.20-1.35x** |
| **训练端到端** | 基线 | 优化后 | **约 1.33x** |

为什么训练加速比推理小？因为训练过程中，反向传播需要保留前向的中间结果用于梯度计算——部分中间状态即使融合了也无法省略。而推理只需要前向，融合的效果更明显。

**1.33x** 的训练端到端加速意味着：原来需要 100 天的训练，现在只需要 75 天。在 2,000+ 张 GPU/NPU 的集群规模下，这 25 天的节省对应的是数千万级别的训练成本。

---

## 七、MegaMoE 超级内核

### 7.1 通信-计算重叠

MoE 融合内核解决的是单 GPU 上的计算效率问题。但 MoE 还有一个更大的瓶颈：**跨 GPU 通信**。

在 V4 的专家并行方案中，每个 token 需要被发送到 8 个（Pro）/ 6 个（Flash）不同 GPU 上的专家。当专家数量（256）远大于激活专家数（8/6）时，All-to-All 通信就是一个不可避免的开销。

传统方案中，通信和计算是串行的：

All-to-All 发 token → 专家计算 → All-to-All 收结果 (100μs) (200μs) (100μs) 总延迟：~400μs

V4 的 **MegaMoE 超级内核** 把这个流程改成了流水线形式：

批次 1: All-to-All 发 token → 专家计算 → All-to-All 收结果 批次 2: All-to-All 发 token → 专家计算 → ... 批次 3: All-to-All 发 token → ...

当 GPU 在计算第 1 批 token 的专家输出时，第 2 批 token 的 All-to-All 传输同时在后台进行。通信和计算被完全重叠：

MegaMoE 执行示意图

时间 → ┌──────────────┐ ┌──────────────┐ │ 计算批次 1 │ │ 计算批次 2 │ └──────────────┘ └──────────────┘ ┌──────────────┐ ┌──────────────┐ │ 通信批次 2 │ │ 通信批次 3 │ └──────────────┘ └──────────────┘

总延迟：max(计算时间, 通信时间) ≈ 200μs（没有重叠时为 400μs）

### 7.2 微批次粒度的重叠

MegaMoE 的核心创新在于**微批次（micro-batch）粒度**的通信-计算重叠。

传统方案中，重叠的最小单位是整个 batch——GPU 先把所有 token 发出去，再开始计算。这意味着 All-to-All 通信必须等所有 token 都到达目标 GPU 才能开始计算，延迟是"通信 + 计算"的总和。

MegaMoE 把 token 按更细的粒度分组——不是等到全部 token 都发送完再计算，而是**每收到一小批 token 就立即开始计算这批 token 对应的专家输出**，同时后一批 token 的传输在后台继续。

这种微批次粒度的重叠对 MoE 场景特别有效，因为：

1. 每个专家的计算独立——不需要等到所有 token 收齐才开始
2. 专家数量多（256 个）——token 分发到不同专家的过程天然可以分批次进行
3. 激活专家数少（8/6）——每批 token 只需要和少量 GPU 通信

### 7.3 推理加速 1.96x

MegaMoE 的最大加速效果出现在推理场景。技术报告中的数据显示：

| 上下文长度 | 标准 EP | MegaMoE | 加速比 |
|-----------|--------|---------|-------|
| 4K | 基线 | 优化后 | **1.32x** |
| 32K | 基线 | 优化后 | **1.58x** |
| 128K | 基线 | 优化后 | **1.74x** |
| 512K | 基线 | 优化后 | **1.91x** |
| **1M** | 基线 | 优化后 | **1.96x** |

**上下文越长，加速效果越明显。** 原因很直观：长上下文下，batch size 和序列长度都更大，通信量更高，通信和计算重叠的空间也更充足。在 1M 上下文下接近 2x 的推理加速，意味着同样硬件可以处理两倍的推理请求——对于 API 服务的毛利率有直接帮助。

### 7.4 跨硬件验证

DeepSeek 在 V4 技术报告中特别提到，MegaMoE 方案**在英伟达 GPU 和华为昇腾 NPU 上均完成了验证**。

这不是一个简单的"移植"工作。英伟达 H800 使用 NVLink 做卡间通信（带宽 900 GB/s），而华为昇腾 950PR 使用 HCCS（带宽约 600 GB/s）。两者的通信带宽差异、拓扑结构不同，要求 MegaMoE 的通信调度方案能同时适配两种硬件。

DeepSeek 的解决方案是**在 TileLang 层抽象了通信接口**——同一套 MegaMoE 代码，编译时根据目标硬件选择不同的通信后端。这和高性能计算中"写一次代码、编译到多个平台"的思路一致。

---

## 八、训练稳定性

### 8.1 万亿参数训练的噩梦

32T tokens、1.6T 参数、2,000+ 张 NPU、数月训练——这些数字放在一起意味着什么？

**如果你的训练在第 100 天崩溃了，你需要从最近的有效 checkpoint 重新起训，相当于至少浪费 1-2 天的计算。** 如果 checkpoint 本身也坏了（写入错误、硬件故障等原因），损失更大。

在大规模训练中，稳定性和性能提升一样重要——一个训练中途崩溃的 1.6T 模型，即使设计得再好也毫无价值。

V4 的预训练面临着几类稳定性风险：

| 风险类型 | 触发条件 | 后果 | 频率 |
|---------|---------|------|------|
| Loss Spike | 某层激活值突然爆炸 | 模型输出变成 NaN，训练中断 | 偶发（1-2 次/万步） |
| 梯度爆炸 | 反向传播梯度数值过大 | 参数更新异常，后续训练失效 | 较少（<0.1% 步数） |
| 硬件故障 | GPU/NPU 内存错误、通信超时 | 单卡故障导致整个训练挂起 | 高频（多卡集群日常） |
| 数值精度溢出 | FP4/FP8 低精度计算中的溢出 | 单步更新失真 | 极少（<0.01% 步数） |

### 8.2 梯度裁剪与 Loss Spike 防护

**梯度裁剪（Gradient Clipping）** 是应对梯度爆炸的标准手段。V4 将全局梯度范数的裁剪阈值设置为 **1.0**——如果所有参数的梯度向量范数超过 1.0，就等比例缩小到 1.0。这个值经过 27B 测试模型上的多轮实验确定：大于 5.0 说明裁剪太宽松（不能有效防止爆炸），小于 0.1 说明裁剪太激进（影响正常训练）。

**Loss Spike 处理** 比梯度裁剪更激进。当损失函数的值在几步之内突增超过预设阈值（一般是正常损失的 2-3 倍）时，系统会自动触发以下流程：

1. 丢弃当前 step 的参数更新（不使用该步的梯度）
2. 从上一个健康 checkpoint 重新加载模型状态
3. 对该 step 的数据源做标记（可能是某条数据有问题）
4. 用小 50% 的 batch size 重跑该 step
5. 如果还是 spike，则跳过该数据，继续训练

这套自动化流程在 V4 的 32T 预训练中多次被触发。据技术报告披露，32T tokens 的训练过程中，Loss Spike 防护系统自动恢复了约 20-30 次训练——每次恢复成本约 5-10 分钟计算时间，远好于人工介入的数小时或数天。

### 8.3 mHC 在稳定性中的作用

mHC（Manifold-Constrained Hyper-Connections）是 V4 训练稳定性的**底层保障**。

第 04 篇文章已经详细阐述了 mHC 的原理。这里只从预训练的角度说明它和稳定性的关系：

**如果没有 mHC，V4 的 61 层深度在训练中会频繁出现 Loss Spike。** V4 的技术团队在 27B 测试模型上的消融实验证实：使用标准残差连接和 Pre-LN 的 61 层模型，在 1T token 的训练中平均每 5,000 步出现一次 Loss Spike；使用 mHC 后，这个频率降低到每 50,000 步一次——**降低了 90%**。

| 稳定措施 | 独立效果 | 配合 mHC 的效果 |
|---------|---------|---------------|
| 梯度裁剪 | 范数 > 1.0 时缩放 | 裁剪频率降低 70%（梯度更稳定） |
| Loss Spike 自动恢复 | 检测到 spike 后自动恢复 | 触发频率降低 90%（spike 更少） |
| 确定性内核 | 消除数值不确定性 | 配合 mHC 更易复现问题 |
| 预热学习率 | 前 2K 步线性上升 | 稳定过渡，mHC 使预热更平滑 |

mHC 不是独立的稳定性方案，它**和梯度裁剪、Loss Spike 自动恢复等机制协同工作**——mHC 从源头上减少了训练不稳定的出现概率，梯度裁剪和自动恢复作为兜底方案处理漏网之鱼。

### 8.4 确定性内核与批不变性

DeepSeek V4 的训练基础设施中，一个值得关注的设计是**确定性内核（Deterministic Kernels）**。

标准 CUDA 计算中，由于浮点数的结合律不成立（a+b+c != a+(b+c)），不同的线程并行计算顺序会导致微小的数值差异。这在单次推理中可以忽略，但在多步训练中会累积——同一个 checkpoint 在不同运行环境下恢复训练，可能走向完全不同的参数空间。

V4 的确定性内核通过以下方式保证每次运行结果一致：

1. **双内核策略**：对每个计算操作，提供"快速版"和"确定版"两个内核。快速版用于正常训练，确定版用于 checkpoint 验证和问题排查。两者输出差异在 FP8 精度下不超过 0.1%。
2. **分离累加缓冲区**：在矩阵乘法的反向传播中，使用单独的累加缓冲区，避免不同 warp 之间的计算交叉。
3. **显式的计算顺序**：TileLang 编译器在生成内核代码时，强制规定 block 的计算顺序，不允许 GPU 硬件动态调度。

这些设计看似繁琐，但在 2,000+ 卡的集群上价值巨大——**没有确定性，你永远无法确定一个训练崩溃是 bug 还是硬件问题。**

### 8.5 Checkpoint 与容错

V4 的 checkpoint 策略也做了针对性设计：

| 维度 | V3 方案 | V4 方案 | 改进 |
|------|--------|---------|------|
| 保存频率 | 每 1,000 步 | 每 500 步 | 减少损失 |
| 保存格式 | 单文件 | 分片多文件 | 单文件损坏不影响全局 |
| 验证机制 | 无 | 保存后立即加载验证 | 及时发现坏 checkpoint |
| 历史保留 | 最后 3 个 | 最后 5 个 | 有更多恢复点可选 |
| 写前日志（WAL） | 无 | 有 | 写入中断可恢复 |

写前日志（Write-Ahead Log）是最关键的改进——在写入 checkpoint 之前，先把写入计划记录到日志中。如果写入过程中训练集群挂掉，恢复时可以从 WAL 中知道"我应该有 checkpoint 但还没写完"，从而避免使用损坏的 checkpoint 继续训练。

此外，V4 还使用了**集群级抢占式任务调度器**。这个调度器可以随时暂停或恢复任何正在运行的任务。当硬件故障被检测到时（比如某张 NPU 的 ECC 错误率超标），调度器会自动将该卡上的任务迁移到备用卡上，并从最近的有效 checkpoint 恢复，整个过程无需人工介入。结合写前日志的 checkpoint 验证机制，V4 的集群能在 90% 以上的硬件故障场景下实现**5 分钟内的自动恢复**。

### 8.6 激活检查点策略

V4 的 61 层深度对显存提出了巨大挑战。训练过程中的中间激活值（activation）是显存消耗的大户——每层都需要保留前向计算的中间结果，用于反向传播时的梯度计算。

V4 使用了**选择性激活检查点（Selective Activation Checkpointing）** 策略：

| 组件 | 是否检查点 | 原因 |
|------|-----------|------|
| 注意力层输出 | 否（保留） | 计算量大，重算成本高于存储成本 |
| FFN 中间激活 | 是（丢弃） | 计算量小，重算成本低 |
| MoE 路由结果 | 是（丢弃） | 可快速重算 |
| Norm 输出 | 否（保留） | 体积小，保留更划算 |
| mHC 映射矩阵 | 否（保留） | 后续计算需要 |

这种"选择性"策略比"全检查点"（丢弃所有激活值、全部重算）在训练吞吐量上高出约 25%，同时比"全保留"节省了约 40% 的显存。是 V4 在显存受限的昇腾 950PR 上能跑通 1.6T 模型的关键工程决策之一。

---

## 小结

本文按 "数据 → 词表 → 训练配置 → 量化 → 算子 → 稳定性" 的完整链路，拆解了 DeepSeek V4 预训练工程的全栈优化。

**数据工程**把 32T tokens 的原始数据，经过四层去重、毒性过滤、质量打分、精确配比，变成了高质量的预训练语料。数据质量直接驱动了 V4-Pro-Base 在 SimpleQA 上的翻倍提升。

**词表设计**将词表从 V3 的 100K 扩展到 128K，通过更精细的多语言 token 覆盖和代码 token 优化，在序列长度上节省了 8-12% 的空间。

**训练配置**通过混合优化器策略（Muon + AdamW）、渐进式 batch size、3D 并行（DP/TP/PP）和细粒度专家并行，让 1.6T 参数、2,000+ 张 NPU 的集群能够高效运行。

**FP4 量化训练**是 V4 最具性价比的工程创新。有选择地对 MoE 专家权重和 CSA indexer 进行 FP4 QAT，在性能损失 <1% 的前提下，将权重显存砍半、推理吞吐量提升 30-50%。

**MoE 融合算子**通过 TileLang 将门控、分发、专家计算、合并步骤融合为单一 kernel，实现 1.5-1.73x 的推理加速和约 1.33x 的训练加速。

**MegaMoE 超级内核**通过微批次粒度将通信和计算完全重叠，在 1M 上下文下达到 1.96x 推理加速。

**训练稳定性**通过梯度裁剪、Loss Spike 自动恢复、确定性内核、改进的 checkpoint 策略，为 32T tokens 的漫长训练提供了系统性保障。

这些优化的共同主题是：**不是堆资源，而是优化每一个环节的效率。** 数据效率、计算效率、显存效率、通信效率——所有环节都被仔细审视和优化。这正是 DeepSeek 能够以远低于竞品的成本，训练出世界级大模型的原因。

---

## 检验标准

- [ ] 能说明 V4 数据清洗的五个阶段及其作用：去重（URL/文档/段落/句子四层）、毒性过滤（BERT 分类器）、质量打分（信息密度/事实准确性/语言规范性等五维评分）、多语言配比（中 42%/英 35%/代码 15%）——至少说出三个阶段的具体方法
- [ ] 能解释 128K 词表相比 100K 的三重收益（多语言覆盖提升、代码 token 优化、序列长度压缩 8-12%），以及 Byte-level BPE 训练中的平衡策略（跨语言合并惩罚、词表裁剪）
- [ ] 能用一张对比表说清楚 FP4 QAT 和 FP8/INT8 量化的差异——在权重显存（0.8 TB vs 1.6 TB）、性能损失（<1% vs 0.5%/3-5%）、推理吞吐量（+30-50%）三个维度上
- [ ] 能回答一个工程问题：为什么上下文越长 MegaMoE 的加速效果越好？——微批次粒度的通信-计算重叠在长序列下效果更显著，1M 上下文可达 1.96x

---

[← 上一篇：mHC 超连接与 Muon 优化器](./04-mhc-muon-optimizer) | [下一篇：后训练：OPD 与 GRM →](./06-post-training)