企业官网建设流程全解析

做这个项目之前，我一直觉得“大语言模型训练”是那种要几百张卡、几千万预算才能碰的事情。直到我系统性把MindSpore Transformers的预训练和微调链路跑通之后，才发现这套东西比想象中亲民，但也比想象中更容易踩坑。这个标题里的几个关键词——MindSpore、Transformers、大语言模型、分布式并行、显存优化——本质上是同一件事：在算力有限的情况下，怎么把一个动辄几十GB的模型放进设备里，用尽量短的时间把训练或微调跑完。这篇文章就是我自己的实战记录，从环境搭建到并行策略，从显存账目到模型导出，每一步都讲清楚“为什么这么做”，把我在这个项目里花掉的那些冤枉时间帮你省出来。如果你手头有哪怕一两张卡，想在 MindSpore 生态里做 LLM 预训练或者微调，这篇文章应该能让你少走一大截弯路。

1. 项目定位与方案选型：为什么是 MindSpore Transformers

1.1 目标场景和核心痛点

我这次的实验环境不算豪华：单机四卡，GPU 显存单卡 24GB，机器上还跑着别的服务，可用内存大概 128GB。目标有两个：一是自己跑通一遍小规模 GPT 风格模型的预训练流程，二是把市面上常见的开源大模型拉下来做指令微调。听起来都是“常规操作”，但真上手之后发现，难的不是模型结构，而是怎么让模型在有限资源下真正转起来。

整个项目最核心的痛点其实是两个。第一是显存：一个 7B 参数量的模型，就算用 BF16 存参数，也要 14GB 左右，这还只是参数，梯度、优化器状态、激活值全算进去，一张 24GB 的卡根本扛不住。第二是时间：单卡训一个 7B 模型哪怕只跑一个 epoch，数据量稍微大一点，都是以天为单位计算的，不搞分布式并行根本没法迭代实验。

所以这个项目真正的技术选型逻辑，不是“我要用什么框架”，而是“我要怎么在约束条件下把训练任务完成”。MindSpore Transformers 的价值在于，它把模型结构、数据处理、训练策略都做了配置化封装，你不需要自己手写数据并行、张量切分这些底层逻辑，但又保留了修改底层策略的入口。对单人开发或者小团队来说，这是从“Could 能跑”到“能反复迭代实验”的关键一步。

1.2 方案对比：手写训练循环还是直接用官方库

在决定用 MindSpore Transformers 之前，我其实纠结过一阵子：是直接用原生 MindSpore 手写训练循环，还是用官方的高层库。两条路我都试了一段，最后选了官方库，原因很直接。

手写训练循环最大的问题是，你要自己处理的东西太多了。大语言模型训练不是 forward 和 backward 那么简单，混合精度怎么开、梯度累积怎么配、分布式并行如果开了张量并行，权重保存和加载时的切分映射谁来管、loss scale 崩了怎么办——这些在框架层都有对应的接口，但散落得到处都是，你得自己组装。我花了两天搭了一个看起来能跑的脚本，结果一上多卡就遇到梯度通信异常，排查了半天才发现是并行上下文配置和优化器初始化顺序的问题。

用 MindSpore Transformers 之后，这些逻辑大部分都收敛到了配置文件和官方训练器里。它内部把 Trainer、数据集、模型注册这几个模块串好了，我只需要关注自己的数据和训练目标。下面是当时做的简单对比：

方案对比的结论很朴素：如果你只是想把模型训出来，而不是研究框架本身，直接用官方高层库是最稳的路径。它可能不像手写那么灵活，但你要的那 80% 功能它都给你封装好了，而且封装的边界恰好避开了最容易出错的部分。

2. 环境搭建：内核选择与 Transformers 库配置

2.1 版本匹配与 Python 内核

MindSpore 这个框架有个特点：不同版本之间的 API 变化非常大，同一个训练脚本放在不同版本下，可能一个能跑一个直接报 undefined symbol。所以环境搭建的第一个原则就是锁版本。我的建议是先确定 MindSpore 主版本，再去官方代码仓库找对应分支的 MindSpore Transformers 代码，不要用最新版强行搭配一个老分支，也不要反过来。

我当时用的是一条相对稳妥的路线：Python 3.8，MindSpore 2.2 系列，加上与之配套的 Transformers 库分支。安装就是标准的 pip 流程，先建一个独立的 conda 环境，把环境隔离做干净。这一步看着没什么技术含量，但实际项目里特别重要，因为大语言模型训练涉及的数据处理库、加速库、通信库依赖很多，一旦和别的项目共用环境，很容易出现“装一个新包把另一个包顶坏”的情况。

环境装好之后，紧接着遇到的一个小问题是“VSCode 里怎么用 MindSpore 内核”。这个热搜关键词背后其实是很多人在 notebook 或 VSCode 里跑 MindSpore 脚本时，发现解释器选不对、内核起不来。我的实操经验是：先确认你的 conda 环境名，然后在 VSCode 里通过命令面板选择 Python 解释器，把它指到 MindSpore 所在环境的 python 路径。如果要在 Jupyter Notebook 里使用，还需要手动注册一下内核：

conda activate mindspore python -m ipykernel install --user --name mindspore --display-name "MindSpore"

注册完之后，在 VSCode 里新建 notebook，右上角选择刚才注册的 “MindSpore” 内核，就可以正常跑了。这里有个容易忽略的点：MindSpore 在 GPU 或加速卡上运行时，很多算子是直接下沉到设备侧执行的，你在 VSCode 里断点调试时，可能代码停在了某一行但设备侧还在跑，看起来像卡死。我的习惯是先在 CPU 或者小模型场景把逻辑跑通，再切到真实设备上做性能验证，不然调试体验会非常痛苦。

2.2 配置注册与 “aimv2” 报错

环境搭好后，我第一次运行官方示例脚本就撞上了一个很经典的报错，也是热搜词里出现过的那个：

aimv2 is already used by a transformers config, pick another name.

刚看到这个报错时一脸懵：我根本没有定义过 aimv2 这个模型。排查了很久才发现问题出在模型配置的注册机制上。MindSpore Transformers 这个库在加载模型时，会从配置文件目录里扫描所有可用的模型配置，并注册到一个全局的注册表里。如果你从不同的来源拷贝过配置目录，或者本地仓库里存在多个同名配置，注册表里就会出现同一个名字被重复占用的冲突。

这个报错的本质是配置名冲突，而不是代码写错了。解决方式也不复杂，我当时做了三件事：

• 检查configs/目录下是否存在重复的模型配置目录，把多余的删掉或改名；
• 清理库的缓存目录，因为某些版本的库会把扫描结果缓存到本地，旧缓存失效后会继续干扰注册；
• 尽量用配置文件路径而不是模型名来实例化模型，比如显式传入 YAML 路径，绕开名字解析。

实操下来，最稳妥的还是直接传配置路径。后来我写训练脚本时，基本都会在代码里显式指定配置文件路径，而不是依赖模型名自动查找：

from mindformers import MindFormerConfig, LlamaForCausalLM config = MindFormerConfig("/your/path/llama_7b.yaml") model = LlamaForCausalLM(config)

这个习惯帮我躲过了后面好几次因为多项目并行导致的名字冲突问题。

2.3 数据准备：MindRecord 与词表

环境没问题之后，下一步就是数据。大语言模型预训练的数据处理流程和普通分类任务不一样，核心区别在于：它不是“读一条样本，处理一条”，而是要把大量文本拼接成固定长度的序列，并且处理好序列边界处的 mask。

MindSpore Transformers 推荐的数据格式是 MindRecord，本质上是一种高效的二进制存储格式，好处是读取速度快，不需要在训练时反复解析 JSON 或文本。我当时用官方提供的数据集转换脚本，把自己的语料转成成套的 MindRecord 文件。转换过程有几个关键点：

• 文本需要按固定长度切分成 chunk，确保每个样本都是模型能接受的seq_length；
• 对于 BOS/EOS 标记要处理好，不能把半句话截断到下一个样本里；
• 标签和输入之间要做 shift，也就是每个 token 的预测目标是下一个 token，这个逻辑在数据处理阶段就要准备好。

我踩过的坑是，最初偷懒直接拿现成的文本文件拼接，没有处理好跨样本的边界，结果训练出来的模型 loss 曲线很漂亮，但生成出来的内容语义破碎。后来才发现是数据处理时把上一句的结尾和下一句的开头拼在一起，模型学到的是“文本拼接”而非“语言规律”。这块处理完之后，训练质量才真正上了一个台阶。

3. 分布式并行：从并行模式到具体参数

3.1 并行模式的选择

大语言模型训练之所以要搞分布式并行，核心原因只有一个：单卡放不下，单卡跑太慢。但“并行”并不是简单地把代码跑在多张卡上，你首先得想清楚要切什么。

MindSpore 提供了几种并行模式，我在项目里实际用到的主要是两类：数据并行和混合并行。数据并行的逻辑最直观——每张卡都持有一份完整模型副本，各自处理不同的数据 batch，训练结束后通过集合通信把所有卡的梯度做平均（AllReduce）。这种方式实现简单，但它的前提是模型能塞进单卡显存，对于大模型来说往往不成立。

混合并行则是在数据并行的基础上叠加模型并行：张量并行把每一层的矩阵参数按行或列切分到多张卡上，数据量大了之后通信代价也指数上升；流水线并行把模型按层切成几段，不同的卡负责不同的层区间，数据像流水线一样逐段经过。这三者的关系可以用一句话总结：数据并行让你能够一次处理更多数据，张量并行和流水线并行让你能够把放不下的模型拆开。

MindSpore 里对应这几个模式的配置入口是并行上下文设置。数据并行需要DATA_PARALLEL，混合并行则常用SEMI_AUTO_PARALLEL，让框架在配置好的策略下自动推导通信和切分。我的建议是不要一上来就选全自动并行，因为自动推导在某些自定义网络里并不总能给出最优策略，半自动模式配合手动指定关键并行维度，反而更可控。

3.2 TP、PP、DP 的参数推演

确定了模式之后，真正难的是 TP、PP、DP 三个维度怎么分配。

我当时以 7B 模型为例做了一次推演。模型大概 32 层，单卡 24GB，总共 4 张卡可用。先看 DP：如果只做数据并行，每张卡都要放完整模型，7B 模型在 BF16 下光参数就 14GB，梯度加优化器状态算下来一张卡至少要 60GB 以上，直接出局。所以必须引入模型并行。

再看 TP：张量并行把每层的参数切到多张卡上，通信发生在每层的 forward 过程中，而且是高频的全量通信。TP 越大，单卡显存压力越小，但通信开销越大。考虑到我的卡是普通 PCIe 互联而不是 NVLink，TP 超过 4 就不太现实了。我最终选用 TP=2，把每层参数切一半，单卡显存压力立刻减半。

然后是 PP：流水线并行把 32 层切成两段，每段 16 层，卡间传输的是激活值而不是梯度，通信频率比 TP 低得多。这里可以设 PP=2，把模型切到两张卡上。最后在四卡环境下，剩余的两张卡组 DP 组，DP=2。这样相当于两条流水线各持一卡处理两份数据，逻辑上是“2 路数据并行 × 2 卡模型并行”的混合组合。

这个配置按四卡算下来，总并行度 2×2=4，刚好用满四张卡。推演过程中我印象最深的一点是：并行度的分配不能只看显存，更要看通信拓扑。如果你的多张卡之间带宽一般，优先保证 DP 足够大，因为 DP 的通信模式最简单、对带宽的容忍度最高。TP 和 PP 这种模型并行，对卡间互联的要求就苛刻多了。

3.3 启动配置与权重切分

具体到配置文件里，MindSpore 里这部分会表现为一段类似下面的并行配置。这里我给出的是简化后的示意：

parallel_config: data_parallel: 2 model_parallel: 2 pipeline_stage: 2 micro_batch_num: 4 parallel_mode: semi_auto_parallel

其中micro_batch_num是流水线并行下 micro batch 的划分数量，它决定了流水线里“气泡”的大小。这个值太小，流水线会频繁等待；太大会增加显存压力。这个参数我一般从 4 开始调，看着卡间通信是否空闲再逐步加。

启动训练时的命令也有讲究。在 GPU 场景下，MindSpore 多卡训练一般通过mpirun或者框架封装的启动器来做：

mpirun -n 4 python run_llm_train.py \ --config configs/llama/llama_7b.yaml \ --use_parallel True

这里有一个很容易踩的坑：分布式训练跑起来之后，模型的权重是按切分策略分散保存在各个 rank（进程）里的。如果你训练到一半中断，想用单卡权重直接加载，会报 shape 不匹配。正确做法是权重保存时把训练策略文件也一起存下来，恢复训练时连同策略一起加载；如果想把切分后的权重合并回完整权重，需要在合并脚本里指定对应的 rank 和策略信息。

这块我自己的经验总结其实就一句话：权重管理从第一天就按分布式标准来做。不要因为现在只是单机四卡就随便 save，后面换大集群时你会回来感谢当初那个规范保存的自己。

4. 显存优化：算力约束下的真正主战场

4.1 先算账：7B 模型到底吃多少显存

显存优化这件事，不先把账算清楚，后面所有操作都像是瞎调。以我最常用的 7B 模型为例，我列过一个很实在的显存消耗表：

不做任何优化的情况下，纯 FP32 训练，光是参数+梯度+优化器状态就超过了 100GB，这个数字对单卡来说完全是绝望的。所以显存优化不是“可选项”，而是必须选。

我的优化路线是分层的：第一层做混合精度，先把优化器状态和梯度的显存占用压下来；第二层做重计算，把激活值这个大头省掉一部分；第三层做 ZeRO 分片，把参数量级本身的显存占用通过多卡摊薄。下面逐项细说。

4.2 混合精度与 loss scale

混合精度的基本原理不复杂：forward 和 backward 的计算用 FP16/BF16，权重和优化器状态保留 FP32，既省显存又保持数值稳定性。MindSpore 的配置里用amp_level控制，O0 是全 FP32，O2 是常用策略，计算用 FP16、权重部分保留 FP32、通过 loss scale 防止梯度下溢。

实际配置里我一般开amp_level: O2，同时启动动态 loss scale。loss scale 是干嘛用的？FP16 的表示范围比 FP32 小很多，当梯度的绝对值很小时，直接存成 FP16 会变成 0，这一步叫“下溢”，model 学不动。动态 loss scale 做的是：训练开始时给 loss 乘一个很大的放大系数，让梯度在回传时不至于被压成 0，然后再根据梯度情况自动调整这个系数。

这里有个来自实践的细节：loss scale 的初始值不要贪大。我用过 2^16 起跑，训练到一半 loss 直接飞掉，因为反向传播后 loss scale 需要回调，但回调周期和梯度异常检测频率没配合好。后来老老实实用默认初始值，让动态模块自己去学习这个尺度，稳定性反而更好。混合精度带来的收益是极其明显的：7B 模型在开 O2 之后，优化器状态省掉一半以上，整体显存从“完全塞不下”变成“勉强能跑”。

4.3 重计算与 ZeRO

混合精度解决的是参数和状态部分的显存，但激活值这个变量还没动。Transformer 模型有个特点：层数越多、序列越长、batch 越大，激活值就越大。7B 模型在序列长度 2048、batch 8 的情况下，激活值随便就是十多个 GB。

重计算的思路是典型的时间换空间：正常 forward 过程会保存每一层的激活值，供 backward 时反推梯度；开启重计算之后，forward 阶段只保留少量关键节点，backward 需要某层激活值时重新算一遍 forward。显存立省，代价是训练时间增加大约 20%-30%。在我这个项目里，重计算带来的时间代价完全可以接受，因为肉眼可见地从“训练一会就 OOM”变成了“能连续跑十几小时不崩”。

ZeRO 则是在多卡场景下进一步省显存的手段。它的核心思想是把优化器状态、梯度甚至参数分片到各卡上，每卡只维护自己负责的那部分，需要通信时再取其他卡的数据。MindSpore 生态里对应这块能力，一般通过配套的 MindSpeed 加速库提供。ZeRO 的三个阶段是递进的：阶段一省优化器状态，阶段二省梯度，阶段三省参数。阶段三虽然最省显存，但通信开销最大，批间延迟上不去。

我的建议是按需选择：如果只是单机多卡，ZeRO 阶段二一般就够用；如果要做大规模跨机训练，再考虑阶段三。ZeRO 不是免费的午餐，它本质上是把显存压力转移成了通信开销，盲目的阶段三在小集群上反而可能比不开还慢。

4.4 梯度累积与单卡微调

梯度累积是“小显存模拟大 batch”的标准手段：显存里只放一个小的 batch，forward 和 backward 连续做 N 次，把梯度累加起来，再做一次参数更新。等效 batch size 等于 单次 batch × 累积步数。

我在单卡微调场景下特别依赖梯度累积，因为它让我可以把 batch size 压到 1 或 2，同时保证等效 batch 不至于太小导致收敛抖动。配置上要留意的是，梯度累积期间的 loss 统计和评估逻辑会变复杂，别把中间 loss 当成最终 loss 去判断收敛。另外梯度累积对混合精度下的 loss scale 也会引入一些耦合，动态 scale 的调整窗口要相应拉长。

如果想在单卡上做 7B 规模模型的微调，我的推荐配置大致是：启用 BF16 混合精度、开启重计算、batch size 设为 2、梯度累积 8 步，配合 LoRA 把真正参与更新的参数量从几十亿降到千万级。这个组合我在 24GB 的卡上实测下来能跑通，速度不快但至少能迭代。显存优化说到最后还是那句话：先算清楚钱花在哪了，再决定怎么省。不检查显存分配就盲开大模型，大概率会在 OOM 报错里度过一整天。

5. 预训练与微调全流程：从脚本到本地部署

5.1 预训练脚本与关键配置

环境、并行、显存都打通之后，预训练流程就水到渠成了。MindSpore Transformers 的官方仓库里提供了训练入口脚本，比如run_llm_train.py，关键配置都收敛在 YAML 文件里。我整理了一份带注释的简化版，方便你对照调整：

model: type: llama model_name: llama_7b seq_length: 2048 vocab_size: 32000 hidden_size: 4096 num_layers: 32 trainer: type: trainer optimizer: type: adamw lr: 3e-4 weight_decay: 0.01 lr_schedule: type: cosine warmup_steps: 1000 train: batch_size: 4 max_steps: 50000 grad_accum_steps: 8 save_interval: 1000 output_dir: ./output

这里面最有指导意义的是学习率方案。大语言模型预训练一般用 warmup + cosine 衰减：前几百步学习率从零缓慢爬升到峰值，目的是让优化器状态稳定下来，之后再按余弦曲线逐步降低学习率。为什么不能直接用一个固定学习率？因为训练的后期 loss landscape 越来越平滑，学习率太大容易在收敛点附近来回震荡，造成 loss 曲线 “锯齿” 明显。

我预训练时的习惯是：先用一个极小模型（比如 1B）快速跑几百步验证数据链路和并行配置，确认没有 OOM、没有通信异常、loss 在稳定下降，然后再切到 7B 模型正式开跑。这个习惯帮我避免了至少三次因为数据 mask 错误导致的“白训一晚上”。预训练流程里最需要耐心的是前几千步，loss 可能不降反升，但只要数据没问题，过完 warmup 它就会稳定下来。

5.2 微调：LoRA 优先

预训练解决的是“让模型学会语言”的问题，微调解决的是“让模型按你想要的方式回答”的问题。在有限算力下，我的经验是微调优先选择 LoRA，而不是全参微调。

LoRA 的核心逻辑是：冻结原来的预训练权重，在 Transformer 的特定线性层旁边插入低秩旁路，只训练这个旁路。为什么这样有效？因为大模型预训练阶段已经学到了大量通用知识，微调只需要在很小的高维子空间里调整它的行为，低秩矩阵完全够用。显存方面的收益是实打实的：全参微调要更新几十亿参数，LoRA 只更新几百万参数，梯度和优化器状态小了两个数量级，24GB 单卡就能跑 7B 模型。

LoRA 的实际配置参数有三组要关注：rank、alpha、target modules。以我在 7B 模型上的经验，rank=8 到 16 是一个合理的起步范围，rank 太小表达力不够，太大又失去了低秩省显存的意义；alpha 一般取 rank 的两倍，它的作用只是缩放旁路的输出权重，不是学习率；target modules 决定往哪些层插入 LoRA，通常集中在 attention 的 q 和 v 投影，如果想更高表达力，可以把 attention 的 o_proj 甚至 FFN 层都加进去。

我当时用 LoRA 微调的配置大致是：

finetune: method: lora lora_rank: 8 lora_alpha: 16 lora_dropout: 0.05 target_modules: - q_proj - v_proj

如果微调任务和预训练任务差异特别大（比如从通用语料切到某个特定领域的专业问答），并且你的数据量足够大，可以适当增大 rank 或者把 target modules 扩展到全部线性层。全参微调的优势是效果上限更高，但在我这种资源条件下性价比太低了，LoRA 是更现实的路线。

5.3 权重保存、导出与本地部署

微调完之后，模型不只是留在训练环境里自我欣赏的，它最终要服务实际业务。这个项目里我最后做了一步“本地部署大语言模型”，把微调好的模型导出成推理格式，拿到另一台没有训练卡的小机器上跑。

MindSpore 环境里这一步主要涉及权重格式转换和模型导出。LoRA 微调后，模型权重分两部分：预训练底座和 LoRA 分支。真正要部署时，需要先把 LoRA 分支合并回底座权重，再导出成统一的推理格式。MindSpore 里导出使用的是model.export这类接口，最终生成 MINDIR 格式的模型文件，后续用 MindSpore Lite 这类推理框架加载。

这里有个我踩过的坑：MINDIR 的导出对 MindSpore 的版本很敏感，用训练环境导出的 MINDIR 不一定能在推理环境的旧版本上加载。所以导出之前先查两边版本是否兼容，避免部署当天才被发现“文件打不开”。另外导出时静态 shape 和动态 shape 的选择也很关键：如果部署场景的输入长度是固定的，用静态 shape 推理速度更快；如果面对的是用户自由输入，建议导出动态 shape，否则输入长度一变就会报错。

部署到本地之后，整个项目的链路就闭环了：数据准备 → 预训练 → 分布式并行优化 → 显存优化 → 微调 → 导出 → 部署。这中间每一步单独拿出来都不算难，但串在一起，每一步的决定都会影响后面的效率。

6. 常见问题与排查实录

6.1 并行与显存问题

并行和显存是项目里遇到问题最多的区域，我把它们单拎出来讲。

首先是 OOM。我的排查顺序是：先看 log 里的显存分配失败发生在哪一步。如果发生在优化器初始化阶段，说明参数和优化器状态的显存已经超标，优先开重计算或者降 batch；如果发生在 forward 中期，往往是激活值太大，优先开重计算或者缩短序列长度；如果发生在 backward，可能是中间梯度临时变量占满了显存，可以调小micro_batch_num或者把梯度累积步数加大，减小单个 batch 的规模。

其次是分布式通信异常。GPU 场景下经常表现为 NCCL 超时或者 rank 之间同步失败。这类问题十有八九出在卡间网络拓扑和并行策略不匹配上。比如你在没有高速互联的两张卡之间强行开 TP=2，通信延迟高到一定程度训练器就会判定超时。我的处理方法是先降低 TP 数值，改成纯 DP + 梯度累积，先确认基础链路没问题，再逐步加模型并行。

还有前面提过的模型配置名冲突问题，这类是 MindSpore Transformers 特有的，解决思路在第二章已经详述过了。凡是遇到 “already used by a transformers config” 这类报错，先别怀疑代码写错，优先去查配置注册目录里的重复项。

6.2 收敛与数据问题

训练跑起来了，结果 loss 不降或乱跳，这种问题其实比 OOM 更让人头疼，因为它不会给你一个明确的异常堆栈。

loss 完全不降，先检查学习率和 warmup：大模型训练前期 loss 不降是正常的，但如果跑了上万步还是一条直线，大概率是学习率太低或者数据没有正确喂进模型。loss 有下降但伴随大量尖峰，可能是 loss scale 调整不稳定，也可能是数据里混进了异常样本——某个异常长的文本或包含大量特殊字符的内容，都会让局部 loss 突然拉高。loss 降到某个平台后停滞，通常是学习率策略导致，可以等 cosine schedule 自动衰减，或者手动降低学习率重启一次。

微调场景还有一个高频问题：训练数据太少导致反复拟合同一批样本。LoRA 微调时因为参数量小，拟合速度非常快，loss 降得很漂亮，但 val loss 却一直在涨，这就是过拟合了。我的应对方案是加大 dropout、降低 rank、减少训练 epoch，三条路同时走。

6.3 排查速查表

这里综合成一个速查表，按问题现象快速定位方案：

这个表是我在实际项目里逐步整理出来的，每次踩坑就往里补一条。用了一段时间之后，大部分问题基本上看现象就能锁定方向，不再需要从零排查。

最后再分享一个小技巧：我在实验里始终遵守一条顺序——先用 1B 模型把全流程跑通，再换 7B 模型做大规模并行和显存调优。因为 1B 模型跑一轮只需要十几分钟，可以快速验证数据、并行、权重管理的正确性，而 7B 模型一次训练就是几十个小时，任何小错误都会被放大成灾难。这个顺序帮我省下的时间，比我在调参上花费的所有精力加起来都多。大模型训练这件事，最大的成本从来不是算力，而是反复试错的时间。