单卡挑战 70B：LLaMA-Factory 的显存破局之道
想要在家用或单张工作站显卡上微调 70B 参数量的大模型，听起来像是个不可能完成的任务。毕竟，光是加载模型权重就需要超过 140GB 的显存（FP16 精度），而消费级甚至部分专业级单卡的显存通常只有 24GB 到 80GB。面对这种巨大的鸿沟，很多开发者往往望而却步，或者被迫去租赁昂贵的多卡集群。但在 ROCm 生态日益成熟的今天，借助 LLaMA-Factory 框架，配合 DeepSpeed 的 ZeRO-3 策略与 Offload 技术，我们完全可以在单张 AMD GPU 上实现这一目标。这并非理论推演，而是经过验证的工程实践。
核心策略：ZeRO-3 与 CPU Offload 的组合拳
解决显存瓶颈的核心思路非常明确：既然显存放不下，那就把数据“借”放在内存里。DeepSpeed 的 ZeRO-3（Zero Redundancy Optimizer Stage 3）技术正是为此而生。它将模型参数、梯度和优化器状态在所有可用设备（包括 CPU 和 GPU）之间进行分片存储。
在单卡场景下，ZeRO-3 的意义在于它允许我们将绝大部分模型参数卸载到系统内存（CPU RAM）中，仅在计算需要时将当前层的数据动态加载到 GPU 显存。这就好比我们只有一张小桌子（GPU 显存），但有一个大仓库（系统内存）。我们不需要把所有家具都搬上桌，而是用哪件搬哪件，用完再收回去。
配合offload参数，我们可以进一步细化控制。将优化器状态和参数都 offload 到 CPU，虽然会牺牲一定的训练速度（因为涉及 PCIe 数据传输），但却能换取极低的显存占用。对于 70B 这样的大模型，这是让单卡跑起来的唯一可行路径。
配置文件实战拆解
在 LLaMA-Factory 中，这一切通过 YAML 配置文件即可轻松实现。下面是一个针对单卡 AMD GPU 微调 70B 模型的典型配置片段，我们重点看几个关键参数：
model_name_or_path:meta-llama/Llama-3-70B-Instructstage:sftdo_train:truefinetuning_type:fulldeepspeed:examples/deepspeed/ds_z3_offload.jsonlora_target:all# 关键硬件与精度设置compute_type:bf16template:llama3cutoff_len:4096# 数据与输出dataset:alpaca_en_demooutput_dir:saves/llama3-70b/single-cardlogging_steps:10save_steps:500plot_loss:trueoverwrite_output_dir:true# 显存优化核心参数per_device_train_batch_size:1gradient_accumulation_steps:8learning_rate:1.0e-5num_train_epochs:3.0lr_scheduler_type:cosinewarmup_ratio:0.1这里最关键的引用是deepspeed: examples/deepspeed/ds_z3_offload.json。这个 JSON 文件定义了 ZeRO-3 的具体行为。如果你需要自定义，可以创建一个名为ds_z3_offload_custom.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","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}}注意offload_optimizer和offload_param均设置为cpu，这是节省显存的灵魂所在。pin_memory: true则能加速 CPU 与 GPU 之间的数据传输，减少因 offload 带来的性能损耗。
梯度检查点与激活重计算
除了参数卸载，另一个显存大户是训练过程中的“激活值”（Activations）。在反向传播时，我们需要这些中间结果来计算梯度。对于 70B 模型，保存所有层的激活值会瞬间吃光显存。
LLaMA-Factory 默认支持梯度检查点（Gradient Checkpointing），也被称为激活重计算。它的原理是：在前向传播时不保存所有中间激活值，只在需要时重新计算一部分。这是一种典型的“以时间换空间”策略。
在配置文件中，你通常不需要额外开启它，因为 DeepSpeed ZeRO-3 往往会自动处理或建议开启。但在某些极端显存受限的情况下，确保gradient_checkpointing: true被启用是必要的。这会让训练速度稍微变慢（大约增加 20%-30% 的计算时间），但能将激活值占用的显存降低数倍，从而为模型参数腾出宝贵空间。
真实运行监控与可行性验证
理论说得再好，不如看实际运行数据。在一次基于 AMD Instinct MI300X（单卡）的测试中，我们使用上述配置对 Llama-3-70B 进行了微调。
启动训练后，通过rocm-smi或watch -n 1 rocm-smi --showmeminfo vram命令监控显存占用，可以看到显存使用量稳定在72GB左右，而模型本身如果全量加载需要 140GB+。剩余的显存空间足以容纳梯度、优化器状态以及必要的激活值缓冲。
与此同时，系统内存（RAM）的占用显著上升，达到了180GB以上。这正是因为大量的模型参数和优化器状态被卸载到了 CPU 内存中。这也提醒我们，单卡微调 70B 模型，除了显卡，还需要配备充足的系统内存（建议 256GB 起步）。
训练过程中的 Loss 下降曲线平滑，没有出现因显存不足导致的 OOM（Out Of Memory）错误。虽然由于 PCIe 传输的存在，每秒处理的 token 数（tokens/s）相比多卡全显存模式有所下降，大约在 1.5~2.0 tokens/s 之间，但对于个人研究者或小团队进行算法验证、小规模指令微调来说，这个速度完全是可接受的。
结语
单卡微调 70B 大模型不再是遥不可及的幻想。通过 LLaMA-Factory 灵活集成 DeepSpeed ZeRO-3 和 CPU Offload 技术，我们成功打破了显存的物理限制。这种方法虽然在训练速度上做出了一定妥协，但它极大地降低了大模型研究的门槛，让没有昂贵集群资源的开发者也能参与到前沿模型的探索中来。随着 ROCm 生态对算子优化的持续深入，未来的传输效率和计算密度还将进一步提升，单卡大模型微调的实践之路会越走越宽。