环境准备与依赖检查

在 AMD GPU 上跑通大模型微调，第一步往往不是写代码，而是把地基打牢。很多开发者在 ROCm 环境下遇到的“段错误”或“非法指令”，根源都在于基础环境没对齐。如果你手头有 Instinct MI300X 这类算力卡，或者正在使用支持 ROCm 7.x 的 DevCloud 环境，建议先确认操作系统为 Ubuntu 22.04 LTS 或更新版本，老内核对新硬件的调度支持确实不够看。

安装驱动时，务必通过官方源添加 ROCm 软件包，千万别随意下载第三方编译好的驱动包，兼容性坑太多。装完后别急着跑 Python 脚本，先用 rocm-smi 看看显卡状态，能正常列出温度、功耗和显存占用才算驱动层没问题。接着运行 rocminfo 确认硬件架构识别正确（比如 MI300X 对应 gfx942），这一步错了后面编译全是白搭。

Python 环境强烈建议用 Conda 隔离，创建一个干净的虚拟环境，避免系统自带包干扰。编译器方面，GCC 11 或 Clang 15 是比较稳妥的选择，CMake 版本最好在 3.20 以上。这些看似琐碎的检查，其实能帮你避开 80% 后续可能出现的编译报错。

LLaMA-Factory 部署与核心配置

环境就绪后，就可以引入主角 LLaMA-Factory 了。这个框架之所以在开源社区这么火，就是因为它把复杂的底层细节屏蔽得非常好，让你能专注于数据和处理逻辑，而不是去调试 DeepSpeed 的通信参数。在 ROCm 7.x 生态下，它对 AMD GPU 的支持已经相当成熟，能够无缝调用针对 HIP 架构优化的 FlashAttention 和 DeepSpeed 组件。

安装过程相对直接，克隆仓库后进入目录，确保你的 PyTorch 版本是专门编译给 ROCm 的（可以通过 pip install torch --index-url https://download.pytorch.org/whl/rocm6.0 类似源获取，具体视 ROCm 版本而定）。安装依赖时，注意检查 deepspeed 和 flash-attn 是否成功编译并链接到了正确的 HIP 库。如果源码编译 flash-attn 失败，通常是因为 HIP_PATH 环境变量没设对，手动导出一下路径再重试即可。

真正的魔法发生在配置文件里。LLaMA-Factory 允许你通过一个简单的 YAML 文件来控制整个训练流程。针对 AMD Instinct 系列显卡的大显存优势，我们需要重点调整几个参数。首先是精度设置，将 compute_type 指定为 bf16。相比 fp16，bf16 在保持动态范围的同时避免了梯度下溢，特别适合大模型训练，而且 MI300X 对 bf16 的算力支持非常充沛。

显存优化：ZeRO-3 与大模型微调实战

有了 bf16 打底，接下来要解决的就是显存占用问题。想要在一台或多台 MI300X 上微调 70B 甚至更大参数的模型，单靠常规手段肯定是不够的，这时候必须启用 DeepSpeed 的 ZeRO-3（Zero Redundancy Optimizer Stage 3）策略。

在 LLaMA-Factory 的配置文件中，你可以这样定义 DeepSpeed 参数：

deepspeed: examples/deepspeed/ds_z3_config.json

对应的 ds_z3_config.json 核心内容如下：

{
  "train_batch_size": "auto",
  "train_micro_batch_size_per_gpu": "auto",
  "gradient_accumulation_steps": "auto",
  "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"
  },
  "fp16": {
    "enabled": false
  },
  "bf16": {
    "enabled": true
  }
}

这段配置的关键在于开启了 stage: 3，它会将模型参数、梯度和优化器状态分片存储在所有 GPU 之间，极大降低了单卡显存压力。更进一步，配合 offload_optimizer 和 offload_param 将部分状态卸载到 CPU 内存，可以利用系统庞大的 DDR 内存来换取 GPU 显存空间。虽然这会带来一定的 PCIe 传输开销，但在 MI300X 这种拥有极高 HBM 带宽的卡上，结合合理的 batch size 调整，依然能跑出非常可观的训练速度。

启动训练命令非常简单：

llamafactory-cli train examples/train_lora/llama3_lora_sft.yaml

框架会自动读取配置中的 deepspeed 选项，初始化分布式环境，并处理混合精度训练中的梯度缩放（Gradient Scaling）。你完全不需要手动编写 loss scaling 的逻辑，LLaMA-Factory 内部已经集成了稳定的实现，防止在 bf16 模式下出现数值溢出或不稳定。

实战效果与避坑建议

在实际操作中，利用这套组合拳，我们在单节点 8 卡 MI300X 环境下成功微调了 70B 参数量的模型。得益于 ZeRO-3 的分片机制，每张卡的显存占用被控制在合理范围内，即使开启较大的序列长度也不会轻易 OOM。社区反馈也表明，在 ROCm 7.x 上运行 LLaMA-Factory 的收敛曲线与理论预期高度吻合，并没有因为换了硬件平台而出现训练发散的情况。

当然，过程中也有几个小坑值得注意。首先是多卡通信，确保你的环境安装了 RCCL（ROCm 版的 NCCL），并且所有显卡之间的互联走的是 Infinity Fabric 而不是低速以太网，否则张量并行时的通信延迟会拖慢整体进度。其次，如果在训练初期发现 loss 不下降，检查一下数据预处理是否正确，有时候 tokenizer 的版本差异会导致输入格式错乱。

最后，关于项目选型，Github 上标榜支持 ROCm 的库不少，但一定要看最近的 Commit 活跃度。LLaMA-Factory 之所以可靠，是因为它紧跟上游 PyTorch 和 DeepSpeed 的更新，对新版 ROCm 的适配响应很快。对于那些半年没更新的项目，哪怕功能描述再诱人，也建议谨慎尝试，毕竟生产环境的稳定性才是第一位的。

通过合理配置 bf16 精度和 ZeRO-3 策略，LLaMA-Factory 让在 AMD 显卡上定制大模型变得不再遥不可及。对于希望降低算力成本、构建私有化模型的团队来说，这确实是一条值得投入的可行路径。

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