环境准备：让 Radeon 显卡“开口说话”

在 AMD 显卡上跑大模型，过去总给人一种“配置地狱”的刻板印象。但随着 ROCm 生态的成熟，尤其是社区涌现出大量自动化工具后，门槛已经大幅降低。对于手头只有一张 Radeon 显卡（如 RX 7900 XT/XTX 或 Pro W7800）的个人开发者来说，想要复现 LoRA 微调流程，第一步不是去啃几百页的官方文档，而是利用社区验证过的脚本快速搭建地基。

核心依赖是 PyTorch 的 ROCm 版本。别再尝试手动从源码编译了，那不仅耗时极长，还容易因为 HIP 编译器路径问题半途而废。推荐直接使用预编译好的 Docker 镜像，或者通过 pip 安装指定版本的 torch 和 torchvision。关键在于确认你的显卡架构代号（gfx version），例如 RDNA3 架构通常对应 gfx1100。在启动容器或运行脚本前，务必导出环境变量：

export HSA_OVERRIDE_GFX_VERSION=11.0.0
export PYTORCH_ROCM_ARCH=gfx1100

这一步至关重要，它能欺骗底层驱动，让为 Instinct 计算卡优化的内核在你的消费级显卡上顺利运行。如果跳过此步，后续训练大概率会直接报 HIP error 或直接闪退。此外，确保当前用户已加入 video 和 render 用户组，这是访问 GPU 硬件的基础权限，很多“莫名其妙的报错”其实仅仅是权限不足导致的。

关键配置：解锁 LLaMA-Factory 的 ROCm 模式

环境就绪后，重头戏在于如何让 LLaMA-Factory 正确识别并调用 AMD 后端。很多人直接照搬 NVIDIA 的教程，结果发现程序根本找不到 CUDA，或者直接回退到 CPU 模式慢如蜗牛。LLaMA-Factory 的社区分支已经原生支持了 ROCm，但需要我们在配置文件中进行显式声明。

在项目根目录下的 examples/train_lora 文件夹中，我们需要修改或新建一个针对 AMD 的 YAML 配置文件。最核心的改动在于将 compute_type 设置为 bf16（如果显卡支持）或 fp16，并强制指定后端。以下是一个经过实战验证的配置片段，适用于单卡微调场景：

model_name_or_path: meta-llama/Llama-3-8B-Instruct
adapter_name_or_path: null
template: llama3
finetuning_type: lora
lora_target: all
output_dir: saves/llama3-8b/lora/radeon-test
overwrite_output_dir: true
do_train: true
do_eval: false
per_device_train_batch_size: 2
gradient_accumulation_steps: 4
learning_rate: 1.0e-4
num_train_epochs: 3.0
lr_scheduler_type: cosine
warmup_ratio: 0.1
bf16: true  # 关键：启用混合精度
ddp_backend: pytorch  # 单卡无需 deepspeed，简化通信
plot_loss: true
include_effective_tokens_per_second: true

注意这里的 bf16: true。Radeon RX 7000 系列及更新架构对 BF16 有较好的硬件支持，能显著减少显存占用并加速计算。如果你的显卡较老不支持 BF16，请改为 fp16: true 并移除 bf16 字段。另外，单卡环境下不需要配置复杂的 DeepSpeed ZeRO 策略，原生的 PyTorch DDP 甚至单机单卡模式反而更稳定，减少了因 RCCL 通信库兼容性带来的潜在风险。

避坑指南：解决 BF16 数值溢出与显存监控

在实际训练中，AMD 平台最容易遇到的拦路虎是数值溢出（Loss 变成 NaN）。这通常是因为 BF16 的动态范围虽然大，但在某些特定的算子实现上，ROCm 底层的优化不如 CUDA 成熟，导致梯度爆炸。

遇到 Loss 瞬间变 NaN 的情况，不要急着换模型，先尝试调整 flash_attention 的设置。部分版本的 ROCm 对 Flash Attention 2 的支持尚不完善，建议在配置文件中显式关闭它：

disable_flash_attn: true

虽然这会牺牲一点训练速度，但能极大提升稳定性。如果关闭后仍然溢出，可以尝试降低学习率至 5.0e-5，或者在启动命令中加入 --optim adamw_torch 强制使用 PyTorch 原生优化器，避开可能存在的 Apex 兼容性问题。

另一个痛点是显存监控。习惯了 nvidia-smi 的用户在 AMD 平台上往往会手足无措。其实 ROCm 提供了功能对等的 rocm-smi 工具。在训练过程中，新开一个终端窗口，运行：

watch -n 1 rocm-smi --showmeminfo vram

这条命令能实时刷新显存使用情况。你会发现，随着 gradient_accumulation_steps 的增加，显存占用是阶梯式上升的。对于 8B 参数量的模型，在开启 LoRA 且 Batch Size 为 2 的情况下，通常需要 16GB 以上的显存才能流畅运行。如果显存爆满（OOM），除了减小 Batch Size，还可以尝试裁剪最大序列长度（cutoff_len），将默认的 2048 降至 1024，这通常能腾出 2-3GB 的宝贵空间。

启动训练与效果验证

一切准备妥当后，就可以启动训练了。LLaMA-Factory 提供了统一的 CLI 入口，命令非常直观：

llamafactory-cli train examples/train_lora/llama3_lora_sft_radeon.yaml

观察控制台输出，重点关注 loss 的变化曲线。在正常的单卡 LoRA 微调中，前 100 步 loss 应该呈现明显的下降趋势。如果看到 loss 震荡剧烈或不降反升，请立即检查数据集格式是否正确，以及上述的精度设置是否匹配显卡能力。

训练完成后，生成的 Adapter 权重可以直接用于推理测试。值得一提的是，在单张 Radeon 显卡上完成这一整套流程，不仅证明了消费级硬件的可行性，也意味着我们不再需要依赖昂贵的云端算力集群就能进行个性化的模型定制。社区的力量正在填补官方文档的空白，从自动化脚本来到底层算子的优化，每一个开源项目的贡献都在让这条路径变得更加平坦。对于个人开发者而言，现在正是利用手头现有硬件探索大模型微调的最佳时机。