Qwen3-30B-A3B-Base SFT-LORA+DeepSpeed ZERO3微调OOM问题

[gitma21]

8卡L20：48GB*8
CPU RAM:480GB

ds_z3_moe.json
{
  "train_batch_size": "auto",
  "train_micro_batch_size_per_gpu": "auto",
  "gradient_accumulation_steps": "auto",
  "gradient_clipping": "auto",
  "zero_allow_untested_optimizer": true,
  "fp16": {
    "enabled": "auto",
    "loss_scale": 0,
    "loss_scale_window": 1000,
    "initial_scale_power": 16,
    "hysteresis": 2,
    "min_loss_scale": 1
  },
  "bf16": {
    "enabled": "auto"
  },
  "zero_optimization": {
    "stage": 3,
    "overlap_comm": false,
    "contiguous_gradients": true,
    "sub_group_size": 1e9,
    "reduce_bucket_size": 5e7,
    "stage3_prefetch_bucket_size": 0,
    "stage3_param_persistence_threshold": 1e4,
    "stage3_max_live_parameters": 6e8,
    "stage3_max_reuse_distance": 0,
    "stage3_gather_16bit_weights_on_model_save": false
  }
}

训练配置文件：

### model
model_name_or_path: /home/logs/models/Qwen3-30B-A3B-Base
trust_remote_code: true

### method
stage: sft
do_train: true
finetuning_type: lora
lora_rank: 16
lora_alpha: 32
lora_dropout: 0.05
# 不要用 all：Qwen3-MoE 有 48 层 × 128 experts，all 会给 18432 个 expert 线性层挂 LoRApacking
lora_target: q_proj,k_proj,v_proj,o_proj
deepspeed: examples/deepspeed/ds_z3_moe.json

### dataset
dataset: es_address_sft_30k
template: qwen3_nothink
cutoff_len: 768  # 实测样本最长 698 token
tokenized_path: /home/yangzie.yz/LLaMA-Factory/saves/tokenized/es_address_sft_30k
preprocessing_num_workers: 8
dataloader_num_workers: 2

### output
output_dir: /home/yangzie.yz/LLaMA-Factory/saves/qwen3-30b-a3b-base/lora/es_address
logging_steps: 10
save_steps: 200
save_total_limit: 5
plot_loss: true
overwrite_output_dir: true
report_to: none

### train
per_device_train_batch_size: 4
gradient_accumulation_steps: 2
learning_rate: 1.0e-4
num_train_epochs: 2.0
lr_scheduler_type: cosine
warmup_ratio: 0.03
bf16: true
ddp_timeout: 180000000

### eval
val_size: 0.02
per_device_eval_batch_size: 4
eval_strategy: steps
eval_steps: 200

基座 bf16 权重 61GB，但每次加载完模型权重后，都会OOM，怀疑是ZeRO-3 all-gather 缓冲导致，但无法定位排查

[cloudgpuapp]

你的 ds_z3_moe.json 和仓库自带的 examples/deepspeed/ds_z3_config.json 不一样：自带配置里 reduce 和 prefetch 的 bucket 大小用 "auto"，stage3_max_live_parameters 和 stage3_max_reuse_distance 用 1e9。LlamaFactory 把你这个 30B-A3B MoE 模型的稀疏 MoE 块设成了 ZeRO-3 leaf 模块，DeepSpeed 进入 leaf 模块时会预取它所有子模块的参数，所以同一层的专家会被一起 gather。issue #9448 里有位贡献者用自带配置在单机 8 卡上跑过这个模型的 LoRA，每卡约 15G（昇腾 NPU，batch 1，cutoff 2048）。建议先换回自带配置、per_device_train_batch_size: 1 再试，还不行再试 ds_z3_offload_config.json。我在 CloudGPU 工作，没在 L20 上复现过。

[2SinceJuly]

你的 ds_z3_moe.json 和仓库自带的 examples/deepspeed/ds_z3_config.json 有几处实质差异，OOM 大概率就出在其中两三个上。

自带的官方配置

"zero_optimization": {
  "stage": 3,
  "overlap_comm": false,
  "contiguous_gradients": true,
  "sub_group_size": 1e9,
  "reduce_bucket_size": "auto",
  "stage3_prefetch_bucket_size": "auto",
  "stage3_param_persistence_threshold": "auto",
  "stage3_max_live_parameters": 1e9,
  "stage3_max_reuse_distance": 1e9,
  "stage3_gather_16bit_weights_on_model_save": true
}

你的配置与之对比

参数	自带	你的	影响
reduce_bucket_size	"auto"	5e7	固定 50MB，远小于 auto 推出的值
stage3_prefetch_bucket_size	"auto"	0	关掉了预取
stage3_param_persistence_threshold	"auto"	1e4	过小，参数会频繁换入换出
stage3_max_live_parameters	1e9	6e8	同时驻留的参数少了 40%
stage3_max_reuse_distance	1e9	0	关掉了复用，参数反复 gather
stage3_gather_16bit_weights_on_model_save	true	false	保存时行为不同

为什么这些会 OOM

stage3_max_reuse_distance: 0 是主因之一。 这个值的含义是「距上次使用多远以内的参数还值得留在显存里」。设成 0 等于告诉 ZeRO-3 不要复用任何已驻留参数——每个使用点都会重新 gather。对 MoE 尤其致命，因为激活的 expert 每次前向都要重新拉一遍。

stage3_prefetch_bucket_size: 0 关掉了预取，于是 gather 变成串行的等待，显存峰值不降反升（没有预取就无法提前释放）。

stage3_param_persistence_threshold: 1e4 太小，小参数也会被反复换出；官方用 auto，DeepSpeed 会根据模型规模推出合理阈值。

stage3_max_live_parameters: 6e8 ——MoE 的专家层数量多，活跃参数峰值比同尺寸 dense 模型高，压到 6e8 会让换入换出过于频繁，显存抖动更容易撞上限。

直接改法

先用官方配置，只改 stage：

{
  "train_batch_size": "auto",
  "train_micro_batch_size_per_gpu": "auto",
  "gradient_accumulation_steps": "auto",
  "gradient_clipping": "auto",
  "zero_allow_untested_optimizer": true,
  "bf16": { "enabled": "auto" },
  "zero_optimization": {
    "stage": 3,
    "overlap_comm": false,
    "contiguous_gradients": true,
    "sub_group_size": 1e9,
    "reduce_bucket_size": "auto",
    "stage3_prefetch_bucket_size": "auto",
    "stage3_param_persistence_threshold": "auto",
    "stage3_max_live_parameters": 1e9,
    "stage3_max_reuse_distance": 1e9,
    "stage3_gather_16bit_weights_on_model_save": true
  }
}

fp16 段可以删掉——你用的是 bf16，同时留着两段容易让人误判启用了哪个。bf16.enabled: "auto" 配合 --bf16 就够。

MoE 额外的几件事

1. 专家并行优先于 ZeRO-3。 Qwen3-30B-A3B 的 3B 激活参数意味着稀疏度高，ZeRO-3 对专家参数的分片收益有限，反而增加通信。如果框架支持（LLaMA-Factory 的 --enable_expert_parallel，视版本而定），先试专家并行 + ZeRO-2。
2. --deepspeed 之外再看 --gradient_checkpointing true，MoE 的显存峰值通常出现在激活而非参数上。
3. cutoff_len 先降到 2048 试跑一轮，确认是配置问题还是单纯超长序列导致，再往回加。

验证方式

改完后观察 nvidia-smi 的显存曲线：如果是持续高位后缓慢爬升直到 OOM，那是激活/碎片问题（加 gradient checkpointing）；如果是一开始就顶满，那是 ZeRO 配置的驻留参数太多，继续调 stage3_max_live_parameters 和 max_reuse_distance 往上加，而不是往下压。