企业官网建设流程全解析

1. 项目概述

MindSpore Transformers 是华为开源的深度学习框架 MindSpore 生态中面向大语言模型（LLM）训练与推理的核心组件库。它提供了一套从模型定义、数据加载、分布式训练到推理部署的完整工具链，专门针对大规模参数模型（如 GPT、BERT、LLaMA 等）的预训练与微调场景进行了深度优化。

我在实际使用中，最直观的感受是 MindSpore Transformers 把很多“脏活累活”都封装好了，但它并不是一个开箱即用的黑盒——恰恰相反，真正想在多卡环境里高效跑起来，你仍然需要深入理解分布式并行的底层机制和显存管理的各种细节。这篇文章，我会从实际踩坑的角度，把大模型预训练与微调过程中最关键的分布式并行方案和显存优化手段拆开揉碎，尽量把“为什么这么做”和“具体怎么做”都讲清楚。

这篇内容适合谁？如果你是刚接触大模型训练的算法工程师，或者已经在用 PyTorch 但想迁移到 MindSpore 生态，又或者你手上有一批多卡资源但训练时显存经常爆掉，那这篇文章应该能帮你少走不少弯路。我会聊聊我跑过的模型、配过的参数、踩过的坑，也会给出可以直接照做的配置方案，希望能让你在自己的机器上更从容地把大模型训起来。

2. 核心技术与场景：为什么是 MindSpore Transformers

2.1 MindSpore Transformers 到底解决了什么

先说说 MindSpore Transformers 在整套技术栈中的位置。它不是一个独立的训练框架，而是构建在 MindSpore 基础框架之上的一层“模型库 + 训练套件”。你可以把它理解成类似 Hugging Face Transformers 之于 PyTorch 的角色：预训练好的模型结构、分词器、训练脚本、数据处理流程，全都给你准备好了。

但和 Hugging Face 那套纯 Python 生态不同的是，MindSpore Transformers 从底层就开始考虑大规模并行训练的问题。它内置了多种并行策略的实现，比如数据并行、模型并行、流水线并行、混合并行，而且这些策略在框架层面被统一封装，你不需要自己去拼接多进程通信逻辑。这一点在真正跑千亿参数模型的时候特别关键。

我见过很多团队用 PyTorch 自研并行逻辑，结果光是把 dynamic loss scaling、梯度同步、参数切分这些组件对齐就花了两三周。MindSpore Transformers 的做法是，把这些组件全部内置到 trainer 里，你只需要配好策略参数，框架自动完成切分和调度。当然，这意味着你必须理解这些策略的原理，否则配错了都不知道从哪排查。

2.2 大模型训练的三个核心战场

大模型虽然名字听着高大上，但训练时真正博弈的其实就三个核心问题。

第一个是并行策略。模型大到单卡装不下，怎么把参数、梯度、优化器状态分到多张卡上，并且让通信开销尽量小。数据并行简单粗暴，但显存冗余严重；模型并行可以拆参数，但通信模式复杂。实际工程里往往需要几种并行方式混合使用。

第二个是显存优化。显存是所有训练者的硬约束。一块 80GB 的 A100/H100 听起来很大，但放进一个 7B 参数的模型，光参数就占 14GB（FP16），再加上梯度、优化器状态（Adam 的 momentum 和 variance）、中间激活值，轻松突破 60GB。所以必须想尽一切办法把显存“挤”出来。

第三个是训练稳定性和效率。大模型训练不是把模型塞进去就行，loss 是否收敛、梯度是否爆炸、吞吐量是否够高，这些直接决定你的时间和电费成本。MindSpore Transformers 在这块也做了不少工作，比如混合精度训练，并行训练时的 loss scaling 自动调整。

2.3 适合用 MindSpore Transformers 的场景

根据我自己的使用经验，有几种场景下 MindSpore Transformers 的优势非常明显。

第一类是已有 MindSpore 基础设施的团队。你总不能因为要跑大模型就把整套技术栈推到重来。MindSpore Transformers 和 MindSpore 框架的版本兼容性更可控，数据格式、算子行为也更统一。

第二类是需要大规模稠密模型并行训练的场景。比如你要在 64 卡甚至 128 卡上训一个几十 B 的模型，用 MindSpore 的并行策略配置会比从零堆 Megatron-LM 的代码省很多事。它的策略搜索工具可以自动帮你找到最优的切分方式。

第三类是对国产硬件栈有要求的场景。昇腾 NPU 搭配 MindSpore 的性能表现确实好，很多算子在图模式编译后有额外的融合优化，这在普通 GPU 上不一定能体现出来。

当然，如果你只是跑个小模型做实验，或者重度依赖 Hugging Face 的社区生态和预训练权重，那 PyTorch 仍然是很顺手的选择。工具选型没有绝对的好坏，关键是看你的场景和资源约束。

3. 分布式并行策略深度拆解

3.1 从数据并行到混合并行：每个方案都在解决什么

没有分布式训练基础的朋友，第一次看到“数据并行”“模型并行”“流水线并行”这些词容易懵。我用一个尽量直白的类比来解释。

假设你要训练一个模型，相当于你要让很多工人（GPU）合作完成一份巨大的作业（训练任务）。数据并行的思路是：每个工人拿一份完全相同的作业副本，大家各自做不同的题目（不同的 batch），做完之后把答案（梯度）汇总起来，更新到共同的作业本（模型参数）上。这个方案简单高效，但问题在于每人手头都要留一份完整的作业本——模型参数每人存一份，显存开销直接乘以卡数。

模型并行的思路则是：把作业本拆开，每人负责其中几页。每个人只保存自己那几页的参数，计算自己负责的部分，然后再通过通信把各页的结果拼起来。这解决了显存放不下的问题，但缺点是计算过程中有大量的跨卡通信，如果切分不合理，通信开销可能比计算还大。

流水线并行更像工厂流水线。把模型的层切成几段，每张卡负责一段，数据像流水线上的工件一样依次流过各段。好处是每张卡只需要存自己那几层的参数和激活值，显存压力小很多；坏处是存在“流水线气泡”，也就是有些卡在等前面卡算完，利用率可能不够满。

实际训练大模型时极少只用一种并行策略，基本都是混合并行，比如同时用数据并行 + 流水线并行 + 模型并行。MindSpore Transformers 的好处就是支持你用一个配置来组合这些策略，而不需要手动实现通信原语。

3.2 MindSpore 的并行配置实战：context 与策略文件

在实际操作中，MindSpore 分布式训练的落地配置分为几个层面。首先是启动方式，MindSpore 支持mpirun和动态组网两种方式。我日常用的最多的是mpirun，直接命令行起多卡进程。

mpirun -n 8 --allow-run-as-root python train.py \ --config configs/llama_7b.yaml \ --strategy strategies/llama_7b_8card.json

这里的核心是策略文件。你预先用 MindSpore 的策略搜索工具生成一个 json 文件，里面定义了每一层的切分方式。比如对 Attention 层的 QKV 权重，指定按行切还是按列切，目标卡数是多少。框架加载这个文件之后，在构图阶段就会自动插入通信算子，你不需要在模型代码里写任何AllReduce、AllGather。

这里有一个关键经验：策略搜索工具生成的默认策略不一定是通信最优的。尤其是对于 attention 和 MLP 这类计算密集、激活值也大的层，需要手动调整切分维度，让通信量和计算量尽量均衡。我一般会生成策略后先跑一个 step，观察training time per step和通信耗时占比，再回头微调策略。

3.3 混合并行的显存账本：算清楚每块显存去哪了

很多新手在配并行策略的时候，只看“显存放得下”就满足了。但我想强调一个更重要的视角：你要算清楚显存到底花在哪了，才能判断该用什么优化手段。

显存占用可以粗略分成四个部分：

• 模型参数：FP16 下每 10 亿参数约 2GB，如果加 FP32 的 master copy，再加 4GB
• 梯度：和参数大小相当，FP16 下每 10 亿参数约 2GB
• 优化器状态：Adam 系优化器需要保存 momentum 和 variance，每 10 亿参数约 12GB（FP32）
• 激活值：取决于 batch size、序列长度、模型宽度和层数，这部分通常最容易被低估

举个例子，我跑过一个 7B 的 LLaMA 类模型，单卡 FP16 参数占 14GB，梯度 14GB，优化器状态 84GB（因为 Adam 要两倍状态的 FP32），这就已经 112GB 了，即使不算激活值也远超单卡 80GB。

所以光靠数据并行是绝对行不通的——每张卡都要存一份完整参数和优化器状态，显存开销直接翻倍。这时候必须用 ZeRO 或者模型并行把状态拆掉。MindSpore 里对应的方案是ParallelMode配置加上optimizer_state_shard，把优化器状态按数据并行维度切分，这样每张卡只需要维护自己那部分状态，显存就能降下来一大截。

另外提醒一句，MindSpore 的auto_parallel可以自动搜索最优切分，但在超大模型上搜索本身也有开销。我通常的做法是：先用人工经验指定一个大致的并行方案（比如流水线 + 数据并行 + ZeRO），再让自动搜索去微调特定层的切分，这样既省时间又能拿到不错的性能。

4. 显存优化实操：从重计算到 offload

4.1 重计算（Recompute）：用时间换空间

如果说并行策略是“把显存分散到多张卡”，那重计算就是“把显存开销转移到计算时间上”。

梯度反传的时候，我们需要每一层的激活值来计算梯度。如果不做处理，所有层的激活值都要在显存里保留到反向阶段，深度一大就直接爆掉。重计算的做法是：向前传播时，只保留部分关键节点（比如每隔几层存一份）的激活值，其他的直接丢掉；反向传播需要用到某一层的激活值时，再重新向前计算一遍。

这听起来很浪费计算，但实测下来通常只增加约 30%-50% 的前向开销，却能把峰值激活显存降到原本的 1/5 甚至更低。对于那些序列长度长、batch 又不得不调大的场景，几乎是救命的操作。

MindSpore 里开启重计算非常简单，但有几个细节值得注意。

# 在训练配置中开启重计算 trainer_config = dict( recompute=True, recompute_fusion=True, # 融合重计算区间，减少额外前向次数 recompute_slice_activation=True, # 将激活值分片保存，进一步省显存 )

recompute_fusion的作用是把多个算子合并成一个重计算区，避免每个算子都单独存一份输入导致显存碎片化。recompute_slice_activation则是把大的激活张量做切分，按需释放。我实际对比过，两个都开了之后，7B 模型的峰值显存大致能从 40GB 降到 28GB 左右，收益相当可观。

不过要记住，重计算不是越多越好。如果整个模型都重计算，那前向计算量几乎翻倍，训练速度会大打折扣。通常的做法是：只对激活值特别大的层开启重计算，比如 attention 的 softmax 结果和 MLP 的中间激活值。MindSpore 里你可以通过按层指定 recompute 标记来实现这种精细控制。

4.2 Offload 至 CPU：把显存压力转嫁给内存

当显存实在挤不下了，还有一个备选方案是把部分状态挪到 CPU 内存里，这就是 offload。MindSpore 支持优化器状态的 CPU offload，也支持部分参数的 offload。

这里我要说一个很多人会踩的坑：无条件把所有状态都 offload 到 CPU，训练速度可能直接砍半甚至更惨。因为 CPU 和 GPU 之间的 PCIe 带宽有限，频繁搬运数据会成为新瓶颈。我自己实测下来，如果只是把优化器状态（FP32 的 momentum 和 variance）offload 到 CPU，因为这部分只需要每步更新一次，搬运开销还能接受；但如果把参数或者梯度也 offload，那前向和反向张量都要频繁跨设备拷贝，速度会让人崩溃。

所以我的建议是：优先用重计算和混合精度压缩显存，最后才考虑 offload。如果必须 offload，优先 offload 优化器状态，并且配合梯度累积来降低搬运频率。梯度累积其实就是把多个小 batch 的梯度攒起来，攒够一定步数再做一次优化器更新，这样 offload 的数据搬运间隔拉长，带宽压力小很多。

MindSpore 里的 offload 配置大概是这样：

optimizer: type: AdamWeightDecay offload: true offload_param: false offload_grad: false

offload_param和offload_grad默认关掉，我强烈建议不要随便开。真到了必须开参数 offload 的规模，那说明你的显存规划本身就有问题，应该优先考虑调整并行策略而不是硬扛。

4.3 混合精度：FP16 与 BF16 的选择与 loss scaling

混合精度已经是所有大模型训练的标配，MindSpore Transformers 也不例外。它的机制是：模型参数和激活值用 FP16 存储和计算，同时保留一份 FP32 的模型副本（或者叫 master weight）用于参数更新，这样既省显存又保证精度。

FP16 的一个经典问题是表示范围有限，数值太小会下溢成 0，数值太大容易溢出成 inf。所以需要loss scaling：在反向传播前把 loss 乘一个大系数（比如 1024 或 4096），让梯度落在 FP16 的可表示范围内，更新完之后再把梯度除以这个系数。

MindSpore 里默认会自动调整 loss scaling 系数，你只需要在配置里开启即可。但有个细节要注意：如果你的 loss 出现 NaN 或者 inf，系统会自动跳过本轮更新并减小 scaling 系数，这在训练初期比较常见。不要一看到这种日志就以为出大问题了，先观察几轮再说。

BF16 是另一个常见选择，它在昇腾硬件上支持得很好。BF16 和 FP16 的显存占用一样，都是 2 字节，但 BF16 的指数位更多，表示范围比 FP16 大得多，几乎不太会出现溢出问题。缺点是小数位少，精度略低，对某些对精度敏感的模型可能不适合。我的经验是，预训练阶段更喜欢用 BF16，因为训练时间很长，稳定性比微小的精度优势更重要；微调阶段如果有收敛不稳定的情况，可以换回 FP16 配合动态 scaling 试试。

4.4 长序列场景的显存杀手：激活值如何管理

聊显存优化，如果不专门说激活值管理，等于白聊。刚才提到激活值在显存里占比很大，尤其是在长序列场景下。假设 sequence length 是 2048，attention 计算得到的 score 矩阵维度是 batch × head × seq × seq，那就是 2048 × 2048，单是这一层几个头的中间结果加在一起就可能上 GB。

处理长序列激活值有几个手段，我把它们按推荐优先级排个序：

• 使用稀疏注意力或滑动窗口注意力，从算法层面减少 attention 的显存和计算量
• 使用FlashAttention类算子，把 attention 计算融合起来，不落地完整的 score 矩阵
• 开启激活值重计算，只保留少量 checkpoint
• 调整模型并行策略，把 attention 的头切分到多卡

MindSpore Transformers 里部分模型已经内置了 FlashAttention 算子，但你需要在配置里显式打开。几年前我第一次跑长文本模型时没开这个，直接 OOM，后来开了之后峰值显存降了将近一半，速度还快了不少。这类算子的意义，本质上就是用计算换显存，而且由于 cache 命中率更高，往往还能顺带提速。

另外要提醒的是梯度检查点（gradient checkpointing）在部分中文社区资料里常常和重计算混着叫，其实是同一个东西。MindSpore 的文档里叫“重计算”，PyTorch 的文档里叫“gradient checkpointing”，都是指前向时不保存中间激活、反向时重新计算。

5. 预训练与微调的完整实战流程

5.1 预训练：数据处理、模型初始化和训练调度

预训练的流程看着简单：数据灌进去，模型跑起来，loss 往下降。但实际工程里每一步都有讲究。

先说数据管线。MindSpore Transformers 支持直接从 Hugging Face 格式的数据集转换到 MindRecord 格式，这是 MindSpore 的二进制存储格式，读取效率比直接读文本高很多。数据处理的时候要注意：tokenize 和 packing 一定不要在训练进程里做，否则 CPU 会成为瓶颈。我习惯用单独的数据预处理脚本，把原始文本转成 token id 的 MindRecord 文件，训练时直接用MindDataset加载。

python tools/dataset_preprocess.py \ --input_path ./data/raw_text \ --output_path ./data/processed \ --tokenizer_path ./tokenizer/llama_tokenizer \ --seq_length 2048 \ --packing_strategy concat

再说模型初始化。预训练不像微调那样有预训练权重可以加载，你得从随机初始化开始。MindSpore 里建议打开参数初始化检查，尤其是 embedding 层的标准差设置是否合理。我看到不少预训练任务最后收敛慢甚至不收敛，问题就出在初始化参数范围太大，导致早期 loss 飞得很高。

最后是训练调度。预训练几乎都是一路跑到底用 cosine decay 学习率调度。不过有几个经验可以分享：一是 Warm up 步数不要过长，一般在总步数的 1%-2% 就够，过长反而会拖慢收敛；二是如果 loss 出现明显震荡，优先检查 batch size 是否合理（太大容易震荡），其次再检查学习率；三是建议每隔固定步数保存一次带优化器状态的 checkpoint，这样随时可以无缝续训。

5.2 微调：低成本适配大模型的关键操作

微调和预训练的显存压力、并行策略选择有很大区别，因为微调通常基础模型已经很小（比如 7B/13B），资源需求相对低，但训练稳定性要求更高。

微调的第一步通常是把某些层的参数冻住。冻结参数的好处有两个：一是减少需要更新的参数量，降低显存占用；二是让模型在少样本场景下不容易破坏原有权重分布，是缓解灾难性遗忘的重要手段。MindSpore 里可以通过设置requires_grad = False来冻结指定层，或者直接用配置文件的frozen_params列表。

model: type: LlamaForCausalLM frozen_params: - "model.embed_tokens.weight" - "model.layers.0.self_attn.*" tune_params: - "model.layers.*.mlp.*"

微调时显存优化优先级和预训练不太一样。预训练阶段我们优先重计算 + 混合并行；微调阶段反而可以多用 LoRA 这类参数高效微调方案。LoRA 的思想是冻结主干权重，在旁边插入低秩分解的旁路矩阵，只训练这些旁路参数。比如一个 7B 模型，用 LoRA 之后可训练参数量可能只有原来的 0.1%，显存占用和优化器状态少了一大截，这是微调场景下最省资源的方案。

MindSpore Transformers 对 LoRA 的支持也比较成熟，配置上要指定 LoRA 作用的模块、秩大小和缩放系数。

lora: r: 8 lora_alpha: 16 target_modules: - "q_proj" - "v_proj" - "k_proj" - "o_proj"

一个很容易被忽略的点是lora_alpha的设置。它不是随便填的，一般建议lora_alpha = r * 2。如果设置的缩放系数太大，微调曲线会非常不稳定；设置得太小，旁路更新幅度太小，模型学不动。我之前见过很多人直接用默认值 8，结果模型适配效果很一般。从经验来看，LoRA 的 r 在 8-16 之间比较平衡，alpha 设为 r 的两倍，在绝大多数文本生成任务上都能拿到不错的效果。

5.3 从 One-GPU 到 Multi-GPU 的迁移例证

我拿一个具体的案例来走一遍多卡迁移的过程，这样比单纯摆配置更容易理解。

假设我有一条 7B 模型微调任务，原本单卡 A100 80GB 上跑，batch size 只能开到 4，训练一个 epoch 要 3 天。现在我换到 4 张 A100 上，目标是把训练时间缩短到 1 天以内，同时保持显存不爆。

第一步，我先把分布式训练框架搭起来。MindSpore 是context.set_auto_parallel_context来设置并行模式。微调场景数据并行就够了，所以parallel_mode=DATA_PARALLEL，再把 batch size 从 4 改成 16（4 卡各吃 4），理想情况下吞吐量能接近线性提升。

import mindspore as ms ms.set_context(mode=ms.GRAPH_MODE, device_target="Ascend") ms.set_auto_parallel_context( parallel_mode=ms.ParallelMode.DATA_PARALLEL, gradients_mean=True, )

这里我想特别提醒gradients_mean这个参数。如果开启，梯度聚合的时候会取多卡的平均值，相当于 batch size 翻倍的效果；如果关闭，梯度是直接累加，等效于 batch size 也翻了倍但学习率需要随之调整。从实践角度来看，我建议开gradients_mean=True，并且学习率不要动，这样多卡和单卡的优化轨迹最接近，不容易出幺蛾子。

第二步是打开重计算。从单卡切到多卡之后，虽然显存被摊到多张卡上了，但每张卡上仍然是完整的模型副本，所以参数占用的显存并没有减少，只有激活值因为 batch size 减少而下降。如果卡数不多、模型又比较大，还是建议打开重计算和混合精度，确保每张卡都有足够的余量。

第三步是检查数据加载是否成为瓶颈。多卡训练时，如果每个 step 耗时突然变长但 GPU 利用率不高，大概率是数据加载跟不上。MindSpore 的MindDataset建议把num_parallel_workers调大，配合prefetch_size让数据提前在内存中排队。实测下来这招能有效打满 GPU 利用率。

这套配置跑下来，4 卡的数据并行 + 重计算 + 混合精度，吞吐量大约是单卡的 3.5 倍，训练时间从 3 天缩短到 1 天以内。没有用到流水线并行或者模型并行，因为 7B 模型在 80GB 显存下单卡完全放得下，瓶颈主要在计算吞吐量，数据并行已经够用。

5.4 更大规模模型：从 7B 到 65B 的扩容路径

如果你的目标是训练 65B 甚至更大参数的模型，光靠数据并行就不够了。我以 65B 模型在 32 卡环境为例，说一下容量规划是怎么做的。

65B 模型在 FP16 下，参数约 130GB，光是参数就放不进单卡 80GB 的显存。梯度同样也需要 130GB，Adam 优化器状态更是夸张地需要 780GB（FP32 的 momentum 和 variance）。也就是说，全部状态合计超过 1TB。如果平均摊到 32 张卡，每张卡也要约 32GB 的状态空间，再加上激活值和中间缓存，80GB 的卡也就勉强够用。

这时候我会这么分配：先按流水线并行把模型切成 4 段，每段负责约 16B 参数，放到 4 组卡上；每一组内部 8 张卡再做数据并行和 ZeRO 优化器状态切分。这样配置的通信模式是：组间做流水线通信，组内做梯度 AllReduce，通信量为 4 倍流水线 stage 的梯度大小，整体压力比较均衡。

MindSpore 里对应的并行配置大体上就是设置pipeline_stages=4，然后在每个 stage 内数据并行 8 路。策略文件里需要为每层指定 stage 的分配位置。这里有个很实用的技巧：把 embedding 层放在第一个 stage，把 lm_head 放在最后一个 stage，中间层尽量均匀切分，这样每个 stage 的计算量差不多，流水线气泡最小。

另外一个常被忽略的点是通信算子与计算算子的重叠。MindSpore 在处理 AllReduce 的时候默认是同步的，也就是梯度算完才开始通信。如果你把通信和下一层的前向计算重叠起来，理论上能省下不少时间。不过这个优化在框架层面不太好手工控制，我建议是先从大粒度上把并行方案设计合理，再考虑这种微优化。

6. 实战中的高频问题与排查手册

6.1 显存 OOM 的排查步骤

OOM 是训练大模型最容易遇到也最让人头疼的问题。我的排查路径一般是这样。

先看训练日志里的显存峰值，MindSpore 会在训练结束时打印峰值显存占用。如果日志没开，可以用npu-smi或者ms_dbug工具实时查看。确认了峰值显存之后，结合模型规模做一次粗略估算——如果光是参数和优化器状态就超过了卡显存，那不用犹豫，直接改并行策略；如果参数和状态没问题，那就是激活值太多，优先开重计算。

排查 OOM 时不要只看峰值显存。碎片化同样会导致分配失败。MindSpore 的显存管理机制对于反复分配和释放不同大小的张量，容易产生显存碎片，表现为“明明显存看着还有 10GB，但分配一个 8GB 的张量就是失败”。遇到这种情况，可以尝试关闭动态显存缓存，或在训练命令里加ms_memory_optimize_level=1之类的参数，把显存预分配和复用打开。实际跑长文本任务时，这个参数帮我解决过好几次假 OOM。

6.2 训练 loss 震荡或发散的处理

loss 震荡和发散，绝大多数时候跟分布式训练无关，而是出在优化器配置或模型初始化上。

我的检查顺序是：

• 先看学习率。如果学习率超过 3e-4（7B 级别模型常用 1e-4 到 3e-4 的区间），震荡概率会显著上升。解决方式是降低学习率，或者改用带有 warmup 的调度。
• 再看 batch size。batch 太小，梯度噪声大会震荡；batch 太大，模型早期可能学不进去。微调任务里尽量保持 batch 在 16 到 64 之间。
• 然后看混合精度。如果 loss 出现突然的 NaN，大概率是 loss scaling 出了问题，开启动态 scaling 或者换 BF16 通常能解决。
• 最后检查数据。有没有异常的 padding 或者数据泄漏，导致某条样本的梯度特别大。用 grad clipping 可以顺带兜底。

grad clipping 在预训练里我一般会设置为全局范数 1.0。开启后训练稳定性会明显好转，代价是极端情况下收敛会变慢一点，但这个代价完全值得。

6.3 多卡通信卡死或训练停滞的处理

多卡训练最怕的就是卡死，所有卡状态都很正常，但训练进度一动不动。这时候第一件事是检查日志是不是有超时或者通信失败的记录。

常见原因有三个：

• NCCL 或 HCCL 通信超时。MindSpore 在昇腾上走的是 HCCL，在 GPU 上走的是 NCCL。如果网络拓扑复杂或者 IB 链路没有打通，通信可能直接挂掉。排查方式是用设备自检工具看看各个卡之间是否可以正常通信。
• 训练进程的 batch size 不匹配。多卡训练时，如果每张卡的数据量不相等，就会在某些卡提前跑完而其他卡还在等，看起来就像卡死。解决方式是确保数据集能被卡数整除，或者开启drop_remainder=True。
• 日志阻塞。训练进程本身没死，但日志输出太多导致 IO 阻塞。节省日志输出量，或者把日志写到内存盘上，一般能解决。

再说一个很基础但容易被忽略的点：卡号必须从 0 开始连续使用。你如果用了 4 张卡但把 rank 配成了 1、2、3、5，某些通信库会在建链的时候直接失败或者表现异常。确保物理卡和 rank 一一对应，能少踩一半以上多卡的坑。

6.4 参数配置速查表

为了让你在实操时少翻文档，我整理了一份可以直接对照的常见问题速查表。这张表里的数值来自我跑 7B/13B 模型的实测经验，不同模型结构会有差异，但可以作为配置的起点。

7. 个人体会与调参心得

MindSpore Transformers 给我最大的感受是：它把大模型训练的“工程门槛”降低了不少，但并没有把“理解门槛”一并消掉。你依然需要透彻理解并行策略是怎么切分的、显存从哪里省出来、loss 为什么不降，才能真正把一套训练流程稳定地跑起来。

我自己用的是先在单卡上跑通、再逐步扩展并行规模的路线。先在单卡把模型结构和数据管线验证好，再切成 2 卡试水，确认策略文件和通信链路没有问题，再上 4 卡、8 卡甚至更多。每次扩展都先跑 50 到 100 个 step 看吞吐量和显存的变化，再决定是否继续加卡。这样做虽然看起来慢，但能避免很多一次性大规模部署时才会炸出来的问题。

最后说一个很多资料不会告诉你但我觉得特别实用的技巧：MindSpore 的训练日志里，除了关注 loss 和吞吐量，一定要盯着recompute触发次数和通信耗时占比。这两个指标能直观地暴露出显存压力和通信瓶颈的问题。训练前期多花几分钟看日志，后期就能省下无数次 debug 的时间。