环境准备与核心依赖

在 AMD Instinct MI300X 上跑大模型微调，最大的门槛往往不是算法本身，而是 ROCm 生态的“水土不服”。很多开发者卡在第一步：环境配不通，或者配通了但算子报错。基于最近的实战经验，要想让 LLaMA-Factory 在 ROCm 7.x 下稳定运行，必须从底层依赖开始“扫雷”。

首先，操作系统建议锁定在 Ubuntu 22.04 LTS。这不是玄学，而是该版本内核对 ROCm 7.x 的驱动支持最为成熟。安装完官方驱动后，别急着装 Python 包，先运行 rocm-smi 和 rocminfo。如果前者能清晰列出显卡温度、功耗和显存占用，后者能正确识别出 gfx942（MI300X 的架构代码），那才算拿到了入场券。很多时候遇到的"illegal instruction"错误，根源就是架构代码没对上。

接下来是 PyTorch 的安装。虽然官方提供了预编译包，但在微调场景下，为了兼容 FlashAttention 和 DeepSpeed 的最新特性，源码编译往往是更稳妥的选择。编译前务必设置环境变量：

export PYTORCH_ROCM_ARCH="gfx942"
export MAX_JOBS=8

忽略 PYTORCH_ROCM_ARCH 是导致后续所有算子失效的头号原因。安装完成后，用一行代码验证后端是否就绪：

python -c "import torch; print(torch.cuda.is_available()); print(torch.version.hip)"

看到 True 和对应的 HIP 版本号，才能继续下一步。

LLaMA-Factory 的 ROCm 适配配置

LLaMA-Factory 的优势在于它屏蔽了底层复杂的分布式训练细节，但在 AMD 平台上，我们需要手动介入一些关键配置，才能发挥 MI300X 的大显存优势。核心战场在 examples/train_full/llama3_lora_sft.yaml（或你自定义的配置文件）。

针对 70B 这种参数量巨大的模型，单卡显存即使有 192GB 也捉襟见肘。这里必须启用 ZeRO-3 优化策略，并配合 Offload 技术。在配置文件中，deepspeed 部分需要明确指向一个自定义的 JSON 文件，或者直接在内联配置中写明：

deepspeed: examples/deepspeed/zero3_offload.json
# 或者直接在 yaml 中指定阶段
stage: sft
finetuning_type: lora # 全量微调可改为 full，但显存压力剧增

关键的 zero3_offload.json 内容如下，重点在于将优化器状态、参数和梯度都卸载到 CPU，仅在前向/反向传播计算时才加载回 GPU：

{
  "zero_optimization": {
    "stage": 3,
    "offload_optimizer": {
      "device": "cpu",
      "pin_memory": true
    },
    "offload_param": {
      "device": "cpu",
      "pin_memory": true
    },
    "overlap_comm": true,
    "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_parition_grads": true,
    "stage3_gather_16bit_weights_on_model_save": true
  },
  "bf16": {
    "enabled": true
  }
}

注意，这里强制开启了 bf16。MI300X 对 BF16 的支持非常完善，相比 FP16 能显著降低溢出风险，且不会像 FP32 那样吃显存。同时，pin_memory: true 能加速 CPU 与 GPU 之间的数据交换，这对 Offload 策略的性能至关重要。

关于 FlashAttention，在 ROCm 7.x 中已经原生支持，但需要在启动命令或配置中显式开启。LLaMA-Factory 会自动检测环境，若发现安装了 flash-attn 的 ROCm 版本，会自动注入相关参数。如果编译时遇到报错，通常是因为 Triton 版本不匹配，建议回退到与 PyTorch 绑定的特定 Triton 版本。

70B 模型微调实战：显存与收敛

理论配置说完，来看看实际效果。我们使用 LLaMA-3-70B 进行垂直领域指令微调，数据集约为 5 万条。

显存表现是这次实战最惊喜的部分。在未开启 ZeRO-3 Offload 时，即便使用 LORA 微调，70B 模型的权重加载也会瞬间撑爆单卡。开启上述配置后，单张 MI300X 的显存占用稳定在 160GB 左右（总容量 192GB），留出了约 30GB 的缓冲空间用于 KV Cache 和激活值。这意味着，我们甚至可以在单卡上尝试更大批次的训练，或者在双卡环境下轻松运行全量微调。

监控曲线显示，由于引入了 CPU Offload，每个 step 的训练时间比纯 GPU 模式增加了约 15%-20%。这是数据搬运带来的必然开销。但在 MI300X 的高带宽 HBM3 和 PCIe 4.0/5.0 的加持下，这个损耗完全在可接受范围内。更重要的是，训练过程极其稳定，没有出现常见的 OOM 崩溃。

收敛速度方面，BF16 精度下的损失下降曲线与 NVIDIA H100 上的表现几乎重合。这说明 ROCm 7.x 的数值计算精度已经非常可靠。DeepSpeed 与 FlashAttention 的配合也没有出现算子降级（fallback）的情况，注意力机制的计算效率得到了充分释放。

对于研究人员来说，这套方案的价值在于低成本定制。以前微调 70B 模型可能需要租用昂贵的多卡集群，现在利用单张或少量 AMD 加速卡，配合 LLaMA-Factory 的精细化配置，就能在本地或低成本云实例上完成高质量的特化训练。只要跨过环境配置这道坎，AMD 平台在大模型微调领域的性价比优势是非常明显的。

200小时GPU算力已就位，快来领取：https://marketing.csdn.net/questions/Q2604140858304426315?utm_source=AIpaper