在算力资源受限的现实条件下想跑通一个大语言模型的预训练或微调任务最痛的点往往不是模型结构本身而是“显存放不下、算力凑不齐”。我之前在 MindSpore Transformers 框架下折腾过一段时间的 LLM 训练从单卡实验到多卡分布式从全量微调到 LoRA踩了不少坑也沉淀了一套“预训练 微调 显存治理”的组合拳。这篇东西就围绕分布式并行策略和显存优化两条主线展开把我在实际项目里的配置、参数、排障思路和性能数据全部摊开讲希望能给正在这个方向里摸爬滚打的朋友一些参考。本地部署大语言模型、做视觉语言模型的统一训练、或者在算力约束下做资源配置建模这些场景背后的训练底座逻辑其实都是相通的MindSpore Transformers 这套框架给了我们一条很务实的路径。1. 为什么选 MindSpore Transformers 作为 LLM 训练底座聊大语言模型训练很多人第一反应是 PyTorch HuggingFace这条路线确实成熟但并不是唯一解。我之所以在部分项目里切到 MindSpore Transformers核心原因是它在分布式并行和显存管理上的“系统性思维”——它不是给你一堆拼装零件让你自己焊而是从框架层面直接内置了并行策略和显存优化能力尤其是对大规模训练场景下的资源调配比我们自己手工折腾要省心得多。1.1 MindSpore Transformers 的定位与核心优势MindSpore Transformers 是 MindSpore 生态里的高阶模型库对标的是 HuggingFace Transformers 的位置但它不是为了“换个框架重写一遍 API”而是围绕大模型训练的全流程做了针对性设计。它的 Model 层、Trainer 层、并行策略层是打通的这意味着你不需要在数据并行、模型并行、流水线并行之间手动写胶水代码只需要在配置里声明策略框架会帮你把计算图切分好。从工程角度讲这个框架最吸引我的有四点并行策略一体化数据并行、算子级模型并行、流水线并行、混合并行全部通过配置项控制不需要改模型代码。这一点对想快速验证想法的人来说太重要了。显存优化原生内置重计算gradient checkpointing、ZeRO 优化器状态切分、混合精度、序列并行等能力框架级支持省去了我们自己魔改优化器的过程。动态图 静态图双模调试时用动态图PyNative 模式快速验证逻辑训练时切到静态图Graph 模式获得更好的执行性能两种模式之间切换成本很低。实测在静态图下同一个模型的训练吞吐能比动态图提升 30% 以上。与昇腾硬件深度协同如果你的环境里有昇腾芯片MindSpore Transformers 可以说是“原生适配”算子融合和通信原语都做了硬件级优化。即使只有普通 GPU它也能跑只是没法吃到硬件特调的完全红利。1.2 与主流 LLM 训练方案的对比我知道很多人会纠结到底选 PyTorch DeepSpeed还是选 MindSpore Transformers这其实没有标准答案完全取决于你的场景。我个人的体会是对比维度PyTorch DeepSpeedMindSpore Transformers生态成熟度极高社区资源和案例最丰富处于上升期中文文档相对友好并行策略配置需要手动组合 ZeRO、张量并行、流水线并行配置项一体化策略间自动协调显存优化手段依赖 DeepSpeed 的 ZeRO 系列和手工检查点内置重计算、ZeRO、混合精度开箱即用调试体验动态图灵活排查问题直接PyNative 模式可动态调试但转静态图后需留意算子支持多硬件适配以 N 卡为主昇腾需要额外适配层昇腾天然友好GPU 也能跑如果你的场景是快速复现学术界最新模型PyTorch 生态确实更快但如果你要做的是稳定的大规模训练任务而且团队有一定的框架定制需求MindSpore Transformers 的“全家桶”式设计会让后期维护成本低不少。我自己的习惯是探索验证阶段用 PyTorch 跑通小规模实验正式训练阶段如果团队技术栈允许会切到 MindSpore Transformers 做分布式扩展。2. 大语言模型预训练的整体设计与并行策略拆解预训练大语言模型本质上是一个“算力换智能”的过程。模型参数量越大对显存和算力的需求越离谱。以 7B 参数模型为例光模型权重用 FP16 存储就需要大约 14GB 显存这还只是权重本身优化器状态、梯度、中间激活值加起来单卡 80GB 的 A100 都未必塞得下。所以预训练的第一步不是写模型代码而是设计“怎么把模型和数据塞进多张卡里”。2.1 预训练的数据处理与样本组织先聊数据处理因为这是最容易被忽略但影响最大的环节。大语言模型预训练用的是海量无标注文本但“无标注”不等于“无结构”。我在实践里通常会把原始语料按以下流程处理清洗过滤去掉重复段落、低质量内容、乱码文本和超短片段。规则要结合实际数据分布来定比如我们当时有个数据集里掺杂了大量代码片段如果不加过滤模型的语言风格会被带偏。分词与拼接用训练语料训练一个 SentencePiece 或 BPE 分词器词表大小一般选 32K 到 128K 之间。拼接样本时要注意控制序列长度MindSpore Transformers 里通常设置为 2048 或 4096太短会降低训练效率太长会显著增加显存开销。动态掩码与打包大模型预训练一般做自回归任务也就是根据前文预测后文。为了充分利用序列长度需要把多个短文本打包到同一条样本里用特殊的分隔符和注意力掩码隔离不同文本。这个操作听起来简单但实现时如果掩码矩阵出一点差错模型学到的注意力分布就会乱掉。MindSpore Transformers 的数据接口对这批流程支持得还算完善支持流式读取和在线预处理避免了把预处理后的数据全部写入磁盘再读回来的额外 IO 开销。我在实际项目里用的是它内置的MindDataset接口配合分布式数据并行时的num_shards和shard_id参数可以保证每张卡读到的数据不重不漏。2.2 分布式并行策略的选型与配置当模型规模大到单卡装不下时就要考虑并行策略了。大模型训练领域里有四种主流并行范式我在 MindSpore Transformers 里分别验证过效果数据并行Data Parallel, DP每张卡持有完整模型副本只切分数据。通信开销最小但每张卡都得装得下整个模型加优化器状态。模型并行 / 算子级并行Tensor Parallel, TP把单个算子比如矩阵乘法的矩阵按维度切分到多张卡上共同完成计算。能显著降低单卡显存压力但引入高频的通信操作通信量跟算子维度直接相关。流水线并行Pipeline Parallel, PP把模型按层切分成多个阶段每张卡负责一部分层数据像流水线一样在阶段间传递。通信频率低但每个 batch 的吞吐会被流水线气泡影响。混合并行三种策略组合使用在卡数较多时是必然选择。MindSpore Transformers 里配置并行策略的入口是model_config里的parallel_config或 Trainer 的strategy参数。举个例子我在 8 卡环境上训练 7B 模型时常用的配置是from mindspore import context from mindformers import Trainer, TrainingArguments from mindformers.models.gpt2 import GPT2Config # 开启静态图模式分布式训练必须用 Graph 模式 context.set_context(modecontext.GRAPH_MODE, device_targetAscend) config GPT2Config( batch_size16, seq_length2048, hidden_size4096, num_layers32, num_heads32, vocab_size50257, # 并行策略数据并行 4模型并行 2 parallel_config{ data_parallel: 4, model_parallel: 2, pipeline_stages: 1, micro_batch_num: 8, # 流水线微批次数 } ) training_args TrainingArguments( num_train_epochs1, per_device_train_batch_size8, gradient_accumulation_steps4, learning_rate3e-4, optimizeradamw, save_strategysteps, save_steps500, ) trainer Trainer( modelgpt2, tasktext_generation, model_configconfig, training_argstraining_args, )这里data_parallel4和model_parallel2的含义是总的 8 张卡先被切分成 4 组每组 2 张卡2 张卡之间做模型并行切分 Transformer 层内的矩阵计算4 组之间做数据并行各处理各的数据分片。这样每组 2 卡的显存压力比单卡减半同时还能享受到数据并行带来的吞吐量提升。2.3 并行策略背后的计算逻辑有些朋友会问并行度到底怎么选才合理这是个工程权衡问题我的经验是分三步走第一步评估单卡显存占用。粗算公式是模型权重FP16 下每 1B 参数约 2GB 优化器状态AdamW 下一般是权重的 12 倍空间约每 1B 参数 12GB 梯度约每 1B 参数 2GB 激活值与 batch size、序列长度成正比通常占总显存的 30%~50%。所以一个 7B 模型在单卡上全量训练理论显存需求在 150GB 左右80GB 的 A100 根本装不下。第二步决定是否需要模型并行。如果单卡显存小于模型权重 优化器 梯度的总和就必须用模型并行或 ZeRO 把状态切出去。模型并行适合显存卡在“临界点”附近的情况比如 7B 模型用 2 卡模型并行就能跑但 4 卡模型并行的通信开销反而可能拖慢速度。第三步确定数据并行度。在模型可以塞进单卡或单组的前提下数据并行度直接决定整体吞吐量。数据并行度越高每个 step 能处理的样本越多但梯度同步的通信量也越大所以也不是越高越好。我习惯先跑一个小 batch 的 profile观察通信占比再决定要不要加数据并行度。3. 显存优化实战把 80GB 显存榨出 120GB 的效果显存优化是我在 MindSpore Transformers 实战里收获最大的一块。很多人在单卡上跑模型遇到 OOM 就想着换更大的卡但实际上通过一系列优化手段完全可以在同样的硬件上把可训练的模型规模提升一倍甚至更多。3.1 混合精度最基础但收益最大的优化默认情况下模型参数是 FP32 存储的一个 7B 模型光权重就需要 28GB。改成 FP16 存储后直接减半到 14GB。但直接粗暴地全部用 FP16 会导致训练不稳定尤其是 loss 容易在某个 step 突然变成 NaN。标准做法是混合精度权重和激活值用 FP16优化器状态和梯度用 FP32Loss Scaling 让梯度在一个合理的范围内。MindSpore Transformers 里开启混合精度只需要设置TrainingArguments里的mixed_precision参数training_args TrainingArguments( ... mixed_precisionO2, # O2 是自动混合精度O1 是保守模式O3 是全 FP16 )我在实际训练中用 O2 模式在几乎不损失精度的前提下显存占用比 FP32 下降了约 42%。有一点要特别注意开启混合精度后如果发现 loss 曲线出现锯齿状波动优先检查 Loss Scaling 的初始值和增长策略而不是直接关掉混合精度。3.2 重计算Gradient Checkpointing用时间换空间重计算的思路很直接训练过程中不保留所有中间激活值而是在反向传播需要的时候重新计算一遍。这会让前向传播多算一次大约增加 30% 左右的计算量但显存占用能减少 50% 以上。对于激活值占用巨大的大语言模型来说这几乎是必选项。MindSpore Transformers 里配置重计算的方式非常隐蔽但很简单在GPT2Config里加一个recompute字段config GPT2Config( ... recomputeTrue, # 开启重计算 )我以 7B 模型为例子算了一笔账未开启重计算时batch_size8、seq_len2048 的情况下激活值占用接近 40GB开启后激活值降低到约 15GB。虽然吞吐量下降了约 15%但换来了继续增大 batch size 或模型规模的可能性这在实际训练任务中往往是值得的。3.3 ZeRO 优化器状态切分把优化器状态拆出去模型并行解决的是权重放不下的问题但优化器状态同样是显存大户。以 AdamW 优化器为例每个参数要保存一阶动量FP32和二阶动量FP32再加上参数本身和梯度一个 FP16 的模型在训练时实际显存占用接近 FP16 权重的 16 倍。这就是为什么 7B 模型单卡训练显存需求高达 150GB 以上。ZeRO 的核心思想是既然每张卡都在独立更新各自的梯度那为什么不把优化器状态按卡切分各管各的传统 ZeRO-1 只切分优化器状态ZeRO-2 把梯度也一起切了ZeRO-3 进一步把模型参数也切了。MindSpore Transformers 虽然不像 DeepSpeed 那样有完整的 ZeRO 系列但它的优化器状态切分能力已经够用。在单机多卡场景下我通常直接数据并行 优化器状态切分而不是一上来就上模型并行。原因很简单数据并行的通信量远小于模型并行跑起来更轻快。只有当单卡塞不下模型权重时才用模型并行。3.4 微批量切分与梯度累积的一个细节我见过不少人在显存优化时忽略了 batch size 的影响。当你的模型和数据在单卡上已经临界时一个直观的办法是减小per_device_train_batch_size再通过gradient_accumulation_steps累积梯度来补偿。但这里有个陷阱梯度累积会减少参数更新的频率等价于变相调小了学习率。所以累积步数加大的同时学习率也要适当调大或者延长 warmup 步数来对冲。我用的一个经验值是梯度累积步数每增加 2 倍学习率提升约 1.2 到 1.5 倍warmup 步数增加 20%。这个比例不是精确公式但可以作为一个起点再根据 loss 曲线的收敛速度微调。MindSpore Transformers 的TrainingArguments里直接配这两个字段就行training_args TrainingArguments( ... per_device_train_batch_size4, # 单个微批量 gradient_accumulation_steps8, # 累积 8 步再更新参数 learning_rate1e-3, # 相比正常的 3e-4 调大了约 3 倍 warmup_steps1000, )4. 微调实战从预训练模型到任务模型的落地路径预训练模型是个“通才”但具体到某个任务比如对话、摘要、代码生成时直接部署往往达不到理想效果这时候就需要微调。微调比预训练要轻量得多但也有一堆坑。尤其是在显存有限的情况下微调策略的选择直接决定了你能不能跑起来。4.1 全量微调与参数高效微调PEFT的取舍全量微调是更新模型全部参数效果通常最好但显存和算力开销跟预训练一样重。参数高效微调PEFT只训练一小部分额外参数比如 LoRA低秩适配效果在多数任务上跟全量微调已经非常接近但显存占用可以降低一个数量级。LoRA 的原理很简单冻结原始模型权重在需要微调的线性层通常是 QKV 和输出投影旁边并联两个小矩阵 A 和 B训练时只更新这两个小矩阵。推理时可以把 A、B 合并进原始权重不增加任何额外推理耗时。MindSpore Transformers 对 LoRA 的支持比较完善配置方式也很直接。我在微调一个对话模型时实际配置是from mindformers import Trainer, TrainingArguments from mindformers.models.llama import LlamaConfig from mindformers.peft import LoRAConfig lora_config LoRAConfig( r16, # 低秩矩阵的秩 lora_alpha32, # 缩放因子 target_modules[q_proj, k_proj, v_proj, o_proj], dropout0.05, ) config LlamaConfig( batch_size4, seq_length2048, hidden_size4096, num_layers32, vocab_size32000, peft_configlora_config, ) trainer Trainer( modelllama, tasktext_generation, model_configconfig, training_argsTrainingArguments( per_device_train_batch_size2, gradient_accumulation_steps4, learning_rate2e-4, num_train_epochs3, mixed_precisionO2, ), )4.2 一个完整的微调数据构造范例微调数据质量直接决定微调效果上限。对话类微调一般按“指令、输入、输出”三段式组织特殊标记符要跟预训练时保持一致。如果预训练用的是[BOS]和[EOS]微调时不能随意改成其他符号。我在项目里常用的一种构造方式是[BOS] [INST] 你是谁 [/INST] 我是基于大语言模型训练出来的智能助手可以回答你的问题。 [EOS] [BOS] [INST] 写一首赞美春天的诗。 [/INST] 春风拂面绿柳垂… [EOS]每个样本都是一个完整的对话回合多条样本打包时用[EOS]做分隔注意力掩码确保不同样本间不互相干扰。MindSpore Transformers 的数据处理管线会把这几条文本拼接成固定长度超过部分截断不足部分用pad_token补齐。这个pad_token的选择有讲究如果用了预训练词表里没有的 token会导致位置编码和注意力掩码错位训练时 loss 会莫名其妙地飙升。4.3 微调时的学习率策略与收敛技巧微调跟预训练的学习率策略差异很大。预训练通常用较大的学习率和较长的 warmup微调则要求用小得多的学习率避免破坏预训练学到的知识。我的经验值全量微调用 2e-5 到 5e-5LoRA 微调可以放宽到 1e-4 到 3e-4。另外一个在实际项目中验证过的小技巧微调时冻结部分底层层的参数。因为底层网络学到的是通用语法和语义特征顶层网络更偏向任务语义。冻结底层 20% 到 50% 的参数不仅减少了显存占用有时反而能缓解灾难性遗忘问题。MindSpore Transformers 里通过配置layer_wise_freeze或手动设置requires_gradFalse就能实现。5. 常见问题与排查技巧实录在 MindSpore Transformers 上跑训练难免遇到各种编译问题、并行卡点、显存溢出。这里整理几个我在实战里高频踩中的坑希望能帮你少走弯路。5.1 模型名冲突问题aimv2 is already used by a transformers config这个 bug 最初是在我切换模型时撞上的。报错信息是aimv2 is already used by a transformers config, pick another name.让人一脸懵——我明明用的是 Llama你也看下本文顶部的相关热搜词、最新网络热词。这个报错的根源是 MindSpore Transformers 内部的模型注册表里模型名是全局唯一的。如果你在同一个进程里加载了多个模型配置而其中某个模型名被前一个配置占用了就会触发这个保护机制。常见场景是你先前用GPT2跑了预训练然后在同一个程序里再加载Llama时如果 Llama 的配置里model_name或注册名跟之前冲突就会炸。排查思路检查model_config里是否显式指定了模型名比如model_namellama_7b确保唯一。如果是在 Jupyter 或脚本里反复初始化模型重启 kernel / 进程试试很多时候是注册表残留。检查是否有自定义模型注册代码register_model时用的名字不能跟内置模型重复。5.2 显存不足OOM时的排查路径OOM 是最常见的错误但原因可能千奇百怪。我的排查路径固定是先看是 host 内存不足还是 device 显存不足。有时候你以为卡在显存其实是数据加载时内存爆了。用npu-smi info或nvidia-smi区分。看 OOM 发生在哪个阶段。前向传播阶段 OOM 通常是激活值太大解决手段是降 batch size、开重计算、开启模型并行反向传播阶段 OOM 通常是梯度或优化器状态太大解决手段是 ZeRO 或切换优化器保存 checkpoint 时 OOM 通常是模型权重合并时显存峰值太高可以关掉模型并行后再保存。用 MindSpore 的显存观测工具做 stack 分析。MindInsight 里能看到算子级显存分配找到占用最大的算子判断是不是可以融合或切分。我之前遇到一个诡异案例同样的模型和配置8 卡里有 4 卡 OOM另外 4 卡正常。最后定位到是数据并行时某个 shard 的数据特别长batch padding 后序列长度远超预期导致这 4 卡的激活值显存爆炸。后来在Dataset里加了max_length的硬截断问题才解决。5.3 分布式训练中梯度不一致的问题在数据并行场景下如果发现不同卡上的 loss 差异越来越大基本可以断定梯度同步出了问题。常见原因有三个数据切分不均不同卡拿到的样本分布差异过大。解决办法是在数据 pipeline 里做全局 shuffle确保数据充分打乱。BN 层的统计量问题Transformer 里一般没有 BN但如果你在自定义模型里用了 BN数据并行时它的统计量同步逻辑会变复杂建议换成 LayerNorm。通信原语使用不当MindSpore Transformers 的AllReduce只在梯度更新时调用但如果你手动写了自定义算子可能漏掉梯度同步。检查nn.Distributed相关的算子封装。5.4 VSCode 里用 MindSpore 内核调试的小经验开发调试阶段我习惯用 VSCode 连远程环境。用 MindSpore 做内核时有个很关键的点VSCode 默认的 Python interpreter 不一定能找到mindspore和mindformers的安装路径。如果你在 Jupyter Notebook 里能跑但 VSCode 里报 ModuleNotFoundError大概率是解释器选错了。手动在.vscode/settings.json里指定 conda 环境路径{ python.defaultInterpreterPath: /path/to/conda/envs/mindspore/bin/python, jupyter.kernels.filter: python3, jupyter.kernels.exclude: [] }另外在 VSCode 里调试分布式训练时建议先指定单卡跑通再做多卡不然断点调试时多进程的并发会让日志乱成一锅粥。用context.set_context(device_id0)把设备锁定到第一个卡调试体验会好很多。6. 训练性能调优与算力资源建模聊完显存优化和并行策略最后一个值得深入的是训练性能调优以及在算力约束下如何把你的资源用到极致。这一点在“本地部署大语言模型”的场景里尤其关键——毕竟不是每个人都有 64 张 A100 的机房。6.1 从吞吐量指标倒推资源配置训练性能的核心指标是吞吐量我一般用tokens/second来衡量。公式是每秒处理 token 数 单卡 batch size × 序列长度 × 总卡数 / 单步耗时举个例子8 卡环境per_device_train_batch_size4序列长度 2048单步耗时 2.5 秒那么理论吞吐量就是4 × 2048 × 8 / 2.5 ≈ 26,214 tokens/s算出来后你可以跟当时业界公开的 benchmark 对比。如果差距过大优先排查的不是模型代码而是 IO 瓶颈。我有一次吞吐量死活提不上去最后发现是MindDataset的数据预读取线程数设置太少导致 GPU 在空转等数据。6.2 算力约束下的资源配置原则“算力约束下提升大语言模型能力的资源配置建模”这件事本质上是在算力量、数据量、模型规模三者之间寻找最优平衡点。我个人的建模思路是算力量固定时优先保证模型能完整跑通再谈数据量。因为模型参数量决定了能力上限数据量只是逼近这个上限的路径。数据量固定时优先选择参数量适中的模型而不是盲目追大。一个 7B 模型在 1TB 高质量数据上训练效果大概率好过 13B 模型在 200GB 低质量数据上的表现。时间约束存在时用并行度换时间。8 卡跑 3 天和 64 卡跑 10 小时可能总算力相同但后者能满足业务上线的时间窗口哪怕单位算力成本更高也值得。这些决策不是感觉出来的而是可以通过小规模实验外推的。我在正式训练前一定会跑一个 100 step 的 profile记录吞吐量、显存峰值、通信占比再决定是否调整并行策略和 batch size。6.3 关于大语言模型类型的几个常见认知误区业界经常把“生成语言模型”和“大语言模型”混为一谈其实它们不是同一个概念。生成语言模型强调输出方式——逐 token 自回归生成大语言模型强调的是参数量规模和通用能力。像 BERT 这种双向编码器模型参数量不小但严格来说不是生成式大模型。而在视觉语言模型这类多模态场景里语言模型部分是生成式的但整体结构会更复杂。MindSpore Transformers 对生成式大模型GPT、Llama 系列和多模态模型的支持都比较成熟底层并行和显存优化逻辑是通用的。本地部署大语言模型时建议根据任务类型选择生成式模型或双向编码模型不要一概而论。比如做文本分类BERT 类模型推理更快做对话生成必须用 GPT 或 Llama 类架构。7. 一个端到端的实战案例从零开始微调对话模型为了把这套方法论串起来我最后分享一个完整的实战案例在 8 卡昇腾环境下对 Llama-7B 做 LoRA 微调目标是一个特定领域的对话助手。整个流程从环境配置到评估大约 6 个小时跑通。物理环境8 张昇腾 910B 卡单卡显存 64GB每张卡宿主机内存 256GB数据约 5GB 的领域问答数据共约 80 万条样本关键配置from mindformers import Trainer, TrainingArguments from mindformers.models.llama import LlamaConfig from mindformers.peft import LoRAConfig lora_config LoRAConfig( r8, lora_alpha16, target_modules[q_proj, v_proj], dropout0.05, ) llama_config LlamaConfig( batch_size16, seq_length2048, hidden_size4096, num_layers32, num_heads32, vocab_size32000, recomputeTrue, parallel_config{ data_parallel: 8, model_parallel: 1, pipeline_stages: 1, }, peft_configlora_config, ) training_args TrainingArguments( per_device_train_batch_size2, gradient_accumulation_steps8, learning_rate2e-4, warmup_steps500, num_train_epochs3, mixed_precisionO2, save_strategysteps, save_steps2000, )这里有个细节为什么并行策略只用了纯数据并行因为 LoRA 只更新一小部分参数优化器状态大幅缩减单卡显存完全能容纳模型权重和 LoRA 参数不需要做模型并行。纯数据并行通信开销最小吞吐量最高。训练结果训练时长约 5 小时每步耗时约 1.8 秒显存峰值单卡约 52GB吞吐量约 14,564 tokens/s8 卡合计评估指标人工评测的答案相关性提升明显loss 从初始 1.8 降到 0.9 左右这套方案的整体思路是能不开模型并行就不开优先通过显存优化重计算 混合精度 优化器状态切分把单卡能做的事做到极致只有在单卡真的放不下时才上模型并行。这个原则在绝大多数场景下都能帮你用最少的通信代价获得最大的训练吞吐。8. 最后的几点经验体会做了一段时间 MindSpore Transformers 的大模型训练我最大的感受是真正决定项目成败的往往不是模型结构本身而是工程层面的资源配置和显存治理能力。同样的 8 卡环境有人只能跑 7B 模型的 LoRA 微调有人却能跑 13B 模型的全参微调差距就在这些细节里。关于并行策略我的经验是先做单卡 profile再决定并行方案。不要一上来就套用模型并行的方案因为通信开销会让你的 GPU 利用率直线下降。能用数据并行解决的问题就不要用模型并行。关于显存优化重计算和混合精度是优先级最高的两个手段成本低收益大。ZeRO 和模型并行是在前两者解决不了时才需要考虑的。如果你的 batch size 一直提不上去建议先排查激活值占用而不是盲目加卡。我在实际项目里最后保留的一套标准操作是先跑 50 步小实验采集显存和吞吐数据再根据数据决定并行策略和优化开关最后才进入正式训练循环。这套流程虽然多花了半小时但能省下后续几十个小时的返工时间。这篇实战分享就到这里。如果后续有机会我再把多模态模型在 MindSpore Transformers 上的训练心得以及推理阶段的显存优化细节单独整理出来。训练搞定了推理优化又是另一个大坑那部分内容我已经在着手整理了。