企业官网建设流程全解析

手头有个活儿：把一个671B总参数的MoE大模型从“理论可行”推进到“真能训练”。你别笑，这个规模的模型，放图表上是一页纸，落到集群上就是一团乱麻。671B意味着什么？光BF16权重就有1.3TB左右，还没算梯度、优化器状态和激活值。更麻烦的是它走MoE路线，专家层散落着几百个路由专家，普通的数据并行、全量复制参数那套打法根本没法直接套。这篇文章就是我踩完一圈坑之后整理的实操记录，从数学账到集群选型、从并行策略到DeepSpeed/Megatron落地，再到高频故障排查链路，尽量做到能照着抄。

我自己是在一个有80GB显存的加速卡集群上做的验证，后面提到的所有数字都按这个前提估算。如果你手里的卡显存、互联带宽不一样，结论会变，但整套分析路径是通用的。

1. 671B模型的显存与通信账：先算清再动手

拿到671B先别急着调参，要算清两件事：状态往哪放，数据在网上怎么走。这两笔账算不清楚，后面的并行设计全是拍脑袋。

1.1 显存口径：状态量级是10TB，不是1TB

一个671B参数的稠密模型，如果用BF16保存，光权重就是671×2=1342GB，约1.3TB。训练时还要额外租用梯度，每个参数至少2字节，这又是一份1.3TB。再加上Adam类的优化器状态——fp32主副本、momentum、variance，每个参数加起来约12字节，也就是671×12≈8TB。三者相加：671B×(2B权重 + 2B梯度 + 12B优化器状态) ≈ 10.7TB。

10.7TB是什么概念？128张80GB卡，总显存10.24TB，理论上刚好卡线，但激活值、通信缓冲、临时张量全都挤不出来。这也是为什么很多人第一次跑671B会“想当然地认为塞得下”，实际一启动就OOM。

结论不是“洗洗睡”，而是必须做三件事：优化器状态分片（把Adam状态切开摊到所有卡）、梯度分片、参数本身分片。对MoE模型而言，专家权重是最大头，所以还要配合专家并行，把不同专家放到不同卡上，而不是每卡都复制一份完整专家表。

1.2 激活值这笔账更躲不开

很多人在显存里只算参数，却把激活值忘了。一个hidden size约7168、序列长度4096、global batch几千的模型，单卡堆激活值极其疯狂。好在激活值不像参数那样必须常驻，可以靠激活重计算、序列并行、以及合理切分microbatch来压。

关键原则是：显存永远不要按“总和不超过每卡80GB”来算，要按“在90%水位下还能留出峰值余量”来算。我自己一般会把理论需求压到显存的70%以内，剩下30%给通信和峰值抖动。

再算算训练整体算力。这个671B模型的激活参数约37B，也就是说一个token实际经过的计算量是37B级别，而非671B。如果想训练5T token，总FLOPs大约为6×37×10^9×5×10^12 ≈ 1.1×10^24。假设单卡BF16算力在500 TFLOPs左右、MFU做到40%，那么千卡集群大约要跑两三周。注意这里说的是“千卡”，不是几十张。所以提前确认你的算力规模有没有到这个量级，否则整个项目工期会彻底失控。

1.3 通信量也不容忽视

MoE的通信开销集中在专家路由的all-to-all上。每个token在前向时要确定路由到哪几个专家，专家数据和梯度要往返传输。EP（专家并行）规模越大，单次all-to-all跨的节点越多，通信时间就越不可忽略。

我做过一个粗略核算：hidden为7168、序列4096、global batch为2048时，一个训练步的token总数约840万。每个token要发给若干专家，来回传递的可能就是14KB级别的向量。这还不算反向。在TP=4、EP=8、跨4个节点的配置下，专家all-to-all的通信量常常占总步时的一半以上。这也是为什么后面整篇文章反复强调一句话：网络带宽决定了MoE训练的上限，算力反而排在第二位。

当你把这笔账写进方案评审文档时，评审人通常会问“并行度怎么设”，但真正该先问的是“你测过all-to-all带宽没有”。没有带宽实测数据的并行方案，我建议一律先打回。

2. 硬件集群的边际条件：没有这些互联，并行设计全是空中楼阁

671B的并行方案不是先定软件参数，而是先定硬件拓扑。硬件给不了的东西，软件再怎么调也补不回来。

2.1 单卡能力只是入场券

单卡显存低于80GB基本不用考虑，否则TP要拉到极高的切分维度，通信开销会把计算完全压垮。算力方面，BF16能力越强越好，但这只是入场券，真正决定成败的是卡间的通信拓扑。

• NVLink域内的带宽：单机8卡通常能到600GB/s级别，适合做TP和需要频繁同步的GEMM切分。
• 跨节点RDMA网络：至少400Gbps级别，通常用InfiniBand或者同等级别的RoCE。这张网络负责数据并行梯度同步、流水线激活传递，尤其是专家all-to-all。
• 存储系统：训练checkpoint动辄几百GB到上TB，普通NFS扛不住，最好上并行文件系统或对象存储+高性能read cache。

我见过一个方案，算力卡都是顶级，但跨节点用的是千兆网卡，训练一启动phy间的通信就变成“走廊扛冰箱”，几十秒卡死一次。这种集群别说671B，跑个几十B的dense模型都艰难。

2.2 网络拓扑和并行度如何对应

参考下面这张对应关系表，本质上就是“什么通信放在什么物理路径上”：

这里有个经验：TP不要拉得太大。TP通信是每层都来一次all-reduce，规模越大通信占比越高。在8卡单机内用TP=4~8是舒服的，跨节点的TP我已经踩过两次坑，延迟直接翻几倍。

2.3 超节点与容错规划

如果资金和资源允许，尽量把EP和TP约束在同一个高带宽域内。这里说的“超节点”既可以是8卡一机，也可以是更大规模的NVL域。EP的通信模式是“每个token都可能去任何一张专家卡”，不像PP那样是固定激活流，所以它对全互联带宽极其敏感。如果EP域跨了太多普通网络跳数，通信时间会不可控，训练经常出现NCCL超时。

硬件规划里还要留够冗余。千卡训练一定会遇到卡故障、节点重启、NCCL异常，尽量提前做到两件事：训练框架支持周期性checkpoint恢复；集群调度器允许把训练任务趁checkpoint间隙重启。我见过很多团队等到第一块卡烧了才开始设计容错，结果一次故障丢两天的训练进度。

3. 把DP/TP/PP/EP/SP五张牌排列组合，才是分布式训练的正解

整套并行策略没有银弹，是把五种并行维度组合起来让各自承担合适的工作。

3.1 每个维度的职责边界

• DP（数据并行）：把global batch切成若干份。每个DP rank持有完整模型的一个并行副本（其实是组合后的副本），梯度经过all-reduce同步。DP是最容易理解的维度，但代价是通信正比于参数规模。
• TP（张量并行）：把一层内的大GEMM切成多个小GEMM，多卡协作完成一次算子计算。好处是显存占比下降，坏处是通信极频繁，适合NVLink域。
• PP（流水线并行）：按层切分，每张卡只负责一段网络层。通信量小，但会产生流水线气泡，需要靠microbatch和合理的schedule填满。
• EP（专家并行）：把所有路由专家切成N份，每张卡只保存并计算部分专家。MoE模型的token需要通过all-to-all送到目标专家卡上，FFN算完再送回原卡。
• SP（序列并行）：把序列维度切到多卡，配合TP做LayerNorm、Dropout等操作的显存分摊，长上下文训练基本逃不掉。

3.2 实际配置参考

下面是我在验证中跑过、认为有参考价值的三档配置。注意每个配置的“总卡数=DP×TP×PP×EP”，SP通常挂在TP组内，不单列乘积。

这里我要特别提醒：EP=8以上的配置，需要先把节点内NVLink带宽和跨节点RDMA带宽都吃到接近饱和；如果EP域过大而带宽跟不上，算力利用率会直线下滑。我的习惯是先把EP锁定在“单组不超过64卡”的范围内，如果专家数量很大，再考虑把专家再切细一点。

3.3 为什么组合起来优于任何一种单一并行

有人会问：既然TP和EP都分摊显存，能不能只开TP不开EP？不行。671B的专家数量通常是几百个，如果只依靠TP，一个专家会被切得零碎，每个GEMM都要跨卡all-reduce，MoE的稀疏优势反而被通信吞噬。EP的本质是保留专家计算的稠密性，让每个专家整体或接近整体地落在一张卡上，计算不碎，只通过网络交换token。

PP解决的是“层太多、单卡放不下”，但引入气泡。DP解决的是“数据吞吐不够”，但会复制整个并行副本。只有把DP/TP/PP/EP/SP组合在一起，才能做到：显存被摊薄，计算不碎，流水线气泡可控，数据吞吐够大。这也是为什么这类模型一定需要一整套并行框架支持，而不是自己在代码里手工拼几个AllReduce就能搞定。

4. 用DeepSpeed+Megatron把配置落到命令行的完整流程

并行策略定完后，就要落到具体框架上。我这边主要用的是DeepSpeed + Megatron的组合：DeepSpeed管ZeRO、MoE、梯度累积这类内存优化，Megatron管TP/PP和主训练循环。

4.1 选型逻辑

• 如果从零自己写，至少要处理TP里每层权重切分、PP的microbatch调度、EP的all-to-all实现、以及统一checkpoint格式，工作量巨大，三个月起步。
• 直接用Megatron-LM类框架，TP/PP/SP内置，底层通信都是高度优化的。
• 用DeepSpeed是因为它的MoE实现能把“专家并行”和“ZeRO优化器状态分片”合在一起处理，而且ZeRO-3对大规模参数加载非常友好。

所以我的建议是：主体代码跑在Megatron风格的工程里，内存优化挂DeepSpeed，这是现阶段最踏实的组合。

4.2 数据准备与模型配置

数据入口必须按global batch切好。DP rank之间拿到不同的数据切片，所有rank合起来构成一个完整global batch。注意顺序，训练时要把“按序列打包”和“按专家均衡”两个目标权衡好，不要为了省token强行把过长序列一条条硬拼，那会让attention的计算分布极不均匀。

模型的MoE部分，关键配置是专家数量、每token激活的专家数、专家容量（capacity factor）。容量因子要留有余量，通常设1.1到1.25之间。太紧会导致token drop，太松会浪费计算。这在分布式环境下比dense模型更敏感。

4.3 一份可改的DeepSpeed配置示例

以下是我验证时用过的配置模板，字段值是当时实测可跑的，不代表所有集群都适用，但结构可以直接复用。

{ "train_batch_size": 2048, "gradient_accumulation_steps": 8, "train_micro_batch_size_per_gpu": 4, "optimizer": { "type": "AdamW", "params": { "lr": 3e-4, "betas": [0.9, 0.95], "eps": 1e-8, "weight_decay": 0.1 } }, "scheduler": { "type": "WarmupCosine", "params": { "warmup_min_lr": 0, "warmup_max_lr": 3e-4, "warmup_num_steps": 2000, "total_num_steps": 50000 } }, "zero_optimization": { "stage": 3, "reduce_bucket_size": 5e8, "allgather_bucket_size": 5e8, "overlap_comm": true, "contiguous_gradients": true }, "moe": { "enabled": true, "num_experts": 256, "top_k": 8, "ep_size": 4, "min_capacity": 4, "noisy_gate_policy": "RSample", "aux_loss_coef": 0.01 }, "fp16": { "enabled": true, "loss_scale": 0, "loss_scale_window": 1000, "initial_scale_power": 16, "min_loss_scale": 1 }, "checkpoint": { "load": "/path/to/checkpoint", "save": "/path/to/save", "tag": "step1000" } }

几个字段说明一下。

• train_batch_size是global batch，它等于train_micro_batch_size_per_gpu × 梯度累积步数 × DP。所以不要只改一个数字，要看乘积是否等于你想要的batch。
• moe.ep_size要和启动时的卡组对应。如果整体并行是DP=4、TP=4、PP=4、EP=4，那么EP组的大小是4，启动脚本要保证这4张卡在该EP域内。
• aux_loss_coef不能只图均衡就把系数调到很大，经验上0.01附近起步，再根据aux_loss曲线调整。调太大会破坏主loss收敛。

4.4 启动命令与监控

多机启动我习惯用torchrun拉起Megatron训练脚本，DeepSpeed配置作为附加参数传入。示意如下：

torchrun --nnodes=32 --nproc_per_node=8 \ --rdzv_endpoint=MASTER_IP:29500 \ train.py \ --model-config configs/671b_moe.json \ --deepspeed ds_config.json \ --tensor-model-parallel-size 4 \ --pipeline-model-parallel-size 4 \ --expert-model-parallel-size 4 \ --data-parallel-size 4 \ --seq-length 4096 \ --global-batch-size 2048 \ --bf16

启动后一定要看两个指标：throughput和MFU。如果MFU低于30%，先查通信排队，再看理论计算量是否被激活重计算拖垮。日志里还要盯aux_loss、moe_token_drop_rate，这两个指标异常会让模型质量悄悄劣化。

另外建议每个训练步都做一次周期性的通信延迟采样，记录每个EP域的all-to-all用时。这一步能让你在故障还没完全发生时提前发现网络劣化，而不是等日志刷出一片超时再手忙脚乱。

5. 训练实测中的五个高频坑：完整排查链路

下面这五个问题是我在验证阶段的真实排查记录，每个问题我都按“现象→定位→修复”的思路写，尽量做到可复现。

5.1 NCCL超时与节点间链路退化

现象：训练偶尔卡死，日志出现NCCL timeout，重启后过一段时间又复现。

定位链路：先看是EP的all-to-all还是DP的all-reduce超时。EP超时往往伴随某个switch端口流量异常；DP超时则优先怀疑某个节点网卡降速。用通信测试脚本单独跑一个all-to-all，把每条链路带宽拉出来。

修复：这类问题靠调代码没用。要么把EP收缩到NVLink域内，要么要求基础设施团队换掉劣化链路。临时缓解手段是把NCCL的NCCL_P2P_LEVEL调低，禁止跨节点P2P，改用共享内存中转，但带宽会打折，只适合救急。

5.2 OOM：激活值峰值爆炸

现象：刚开始训练没事，跑几百步后OOM，报错指向FFN/注意力层。

定位链路：先用单个microbatch逐步启动，把batch size从1测到目标值。如果batch=4还OOM，八成不是batch问题，而是激活重计算没开全，或者序列并行没生效。打开PyTorch的显存快照工具看峰值点，通常能看到attention的中间张量堆积。

修复：激活重计算全开，必要时把某些重计算粒度从layer级细化到block级；再配序列并行，把LayerNorm和Dropout的输出切到TP维度之外。若还不行，只能砍seq-length或者把microbatch再切小。

5.3 MoE负载不均衡：某个专家卡显存暴涨

现象：训练正常跑，但expert卡之间的显存和计算时间明显不均衡，aux_loss逐步升高。

定位链路：查看每个专家被路由到的token数。如果少数专家是“热门专家”，说明Router已经偏科。这个偏科有数据原因，也有初始化原因。先用均衡校验工具检查forward和backward的per-expert计数，不要直接质疑训练数据。

修复：提高min_capacity，避免token掉落；给路由加全局负载均衡约束；必要时把专家权重重新初始化。长期方案是使用偏置项更新的轻量均衡法，既不打乱主梯度，又能逐步纠偏。

5.4 Loss尖峰

现象：loss在一段时间内平缓，突然飙升几个点，然后又自己回落或直接发散。

定位链路：检查是否出现在大规模梯度all-reduce之后。如果是，优先怀疑数据乱序或某些batch混入异常长文本。再看梯度norm曲线，如果尖峰前梯度norm已经明显偏大，说明有效学习率过高。

修复：给梯度加clip，同时把这几个可疑batch单独扫一遍清洗。训练数据里的重复片段会在MoE下被放大，因为多个专家看到同样的路由模式，梯度更新容易同向叠加。如果尖峰反复出现，把梯度整流的窗口值从1.0先调到0.5，跑稳再放回1.0。

5.5 Checkpoint加载失败或恢复后效果漂移

现象：保存时一切正常，恢复训练后loss不衔接，甚至直接报张量形状不匹配。

定位链路：多半是并行维度与保存时的并行维度不一致。很多框架在恢复时要求网格规模、TP/PP/EP配置完全一致，不能“从16卡恢复到8卡”，除非用了统一格式的分布式检查点。

修复：统一启用torch.distributed.checkpoint格式，或者框架自带的universal checkpoint导出。恢复前，用脚本对检查点做一次参数完备性校验，把“加载成功”和“参数真正完整”两件事分开验证。大模型环境下，检查点文件几十上百个，某个分片损坏很常见，必须有校验环节兜底。

6. 没有千卡集群时，如何用小规模验证671B训练代码

很多人第一步就卡在“我根本没有那么多卡”。确实，671B级别的完整训练必须真刀真枪上集群，但我们能通过合理降级，把90%的坑提前排掉。

6.1 同构缩小版：保留MoE骨架，缩减宽度和层数

把hidden size从7168降到2048，层数从61降到16，专家数量从256降到64，top-k仍然设8，保留共享专家。这样总参数可能只有几B到十几B，但路由、all-to-all、负载均衡、ZeRO分片这些核心逻辑完全一致。用这个缩小版在64卡上把配置、训练、恢复、故障演练全部跑一遍，等于把超级工程的“抽水试验”做完了。

6.2 通信带宽预测试

用固定大小的tensor模拟all-to-all，测出跨节点带宽。再看TP组内all-reduce延迟。这些数据回填到方案估算里，比自己拍脑袋算通信耗时靠谱得多。

6.3 单机8卡起步的“麻雀配置”

如果只有一机8卡，可以临时用TP=2、PP=2、EP=2、DP=2来验证训练主链路，虽然跑不动671B，但可以验证：

• 数据管线是否按并行维度正确切分；
• 模型并行与优化器状态分片是否正常；
• checkpoint保存和恢复是否能跨并行配置迁移。

我在确定最终256卡配置前，就是先用单机8卡把上述三件事全部跑通，再在64卡上做一次完整验证。看似慢，实际比直接上大集群试错快得多。

我个人最大的体会是：671B这种规模的MoE训练，真正稀缺的不是算力堆砌，而是通信规划能力。很多团队把预算花在顶级GPU上，却忽略了网络和存储，最后跑起来吞吐一塌糊涂。先算账，再选硬件，最后才是配参数。把这个顺序走对，671B分布式训练才不会从“技术问题”变成“玄学问题”。