大模型微调复现实验分析报告—— 基于单卡 GPU 服务器的训练环境适配与问题排查

大模型微调复现实验分析报告

—— 基于单卡 GPU 服务器的训练环境适配与问题排查

一、实验摘要

本实验在单卡 GPU 服务器上，基于 LLaMA-Factory 框架对伪代码规范化（pseudo2norm）任务进行全参数监督微调（SFT）复现。复现过程并非一帆风顺，先后遭遇四类典型问题：

①训练硬件不支持 bf16 混合精度；

②DeepSpeed 分布式启动方式与单卡环境不匹配；

③模型与依赖下载受网络限制；

④全参微调触发 CUDA 显存溢出。

针对上述问题，实验采取“逐层定位、逐项适配”的排查思路，依次通过“bf16 改 fp16、关闭 DeepSpeed、配置 HF 镜像端点、压缩单步批大小并放大梯度累积”四项措施完成环境与配置的本地化适配，最终以 nohup 后台方式稳定拉起长时训练。整个排查链路覆盖了从依赖安装、精度选型、分布式策略到资源预算的完整工程环节，对同类“单卡复现多卡训练配置”的场景具有较强的参考价值。

二、实验环境与整体排查流程

2.1 软件环境

训练依赖以下核心库，版本之间需严格匹配：

2.2 整体排查流程

复现工作按照“环境搭建 → 启动配置 → 资源适配 → 后台运行”四个阶段推进，每个阶段均以一次报错或瓶颈为驱动完成一轮修复，整体流程如图 1 所示。

图 1  训练环境适配问题排查与解决流程

2.3 常用环境准备命令

# 每次进入 conda 环境前需先初始化 shell

# 模型与数据集下载走国内镜像，避免境外源超时

三、问题现象、根因与解决方案

四类问题的“现象—根因—对策”对应关系汇总如图 2 所示，以下分小节展开分析。

图 2  四类问题“现象—根因—对策”归因矩阵

3.1 混合精度不兼容：bf16 不受硬件支持

首次启动训练即在参数解析阶段抛出异常：

该报错来自 transformers 的 TrainingArguments 校验逻辑：bf16 混合精度要求 GPU 具备 Ampere（安培）及以上架构并配合 CUDA 11.0+。本实验所用 GPU 为上一代架构，仅支持 fp16 半精度，因此训练配置中直接启用 bf16 会触发硬性校验失败。

解决方案是将训练 YAML 配置中的精度开关由 bf16 切换为 fp16：

# 原配置（启用 bf16，当前 GPU 不支持）

bf16: true

# 修改为（关闭 bf16，启用 fp16）

bf16: false

fp16: true

需要注意，fp16 动态范围小于 bf16，训练框架会自动引入损失缩放（loss scaling）以缓解梯度下溢；若后续训练出现损失震荡，可重点关注该因素。

3.2 分布式启动方式不匹配：DeepSpeed 与单卡环境冲突

修复精度问题后再次启动，出现第二个阻断性报错：

原仓库训练配置方案面向多卡集群，要求通过 torchrun 分布式方式拉起进程。而当前服务器仅有一张 GPU，既无必要也无条件启用分布式训练。

图 3  关键配置选型对比：混合精度与训练拉起方式

解决方案有两条路径：其一，按报错提示改用 FORCE_TORCHRUN=1 拉起（适合多卡）；其二，针对单卡环境直接关闭 DeepSpeed。本实验选择后者：

3.3 模型与依赖下载受限：配置国内镜像

环境准备阶段还发现 Hugging Face 官方源访问缓慢、易超时，导致模型权重与数据集下载反复中断。通过设置镜像端点环境变量解决：

该变量会将被 Hugging Face 系工具识别的下载源整体切换至国内镜像站点，属于一次配置、全程生效的低成本优化。

3.4 显存溢出：CUDA OOM 的量化分析与参数再平衡

上述配置修正后训练得以启动，但很快在注意力计算（softmax）阶段崩溃，报错信息给出了完整的显存账本：

从报错数据看：全参微调本身已占用约 27.81 GiB（模型权重、优化器状态与激活值），加上框架与上下文开销后进程总占用达 30.30 GiB，仅剩 1.43 GiB 可用；而单个注意力层的 softmax 激活就需要 1.79 GiB，缺口约 0.36 GiB，直接触发 OOM。各显存分量的对比见图 4(a)。

图 4  显存瓶颈分析与训练批参数调整

解决思路是“以时间换空间”：将单步批大小从 8 降至 1，同时把梯度累积步数从 8 提升至 16，在几乎不改变训练语义的前提下大幅压缩激活显存峰值（见图 4(b)）。同时将学习率固定为 3.0e-6、训练 2 个 epoch，并采用带最小学习率下限的余弦调度器。相关配置修改如下：

需要指出，调整后有效批大小由 8×8=64 变为 1×16=16，等效于训练噪声相对增大；若后续指标不理想，可继续增大梯度累积步数以逼近原始有效批大小，代价是单轮训练时间进一步拉长。

3.5 长时训练守护：后台化与日志留存

微调任务通常运行数小时以上，为避免 SSH 会话中断导致训练终止，最终采用 nohup 后台运行并将全部输出重定向到日志文件：

日志重定向保留了完整的进度条与报错上下文，为事后回溯训练曲线、定位中断原因提供了原始依据。

四、最终训练方案汇总

五、结论与后续建议

5.1 主要结论

（1）复现失败的主要原因并非模型或数据问题，而是“训练配置与本地硬件环境的错配”：精度格式、分布式策略、批大小三项配置均需按单卡 32GB 级环境重新适配。

（2）“报错信息 → 逐层定位 → 最小改动修复”的排查路径效率较高，四类问题均在保持训练语义基本不变的前提下得到解决，未引入额外的训练超参数改动。

（3）显存预算应提前测算：全参微调的显存占用 = 模型权重 + 优化器状态 + 梯度 + 激活值，在大批配置下激活值是首要瓶颈，batch 与梯度累积的组合调节是最直接的降压手段。

5.2 后续建议

（1）精度监控：fp16 数值范围较窄，建议在训练日志中持续观察 loss 是否出现 NaN 或震荡，必要时下调学习率或改用梯度裁剪。

（2）有效批大小对齐：当前有效批大小（16）低于原配置（64），复现指标出现偏差时可优先增大梯度累积步数再评估。

（3）显存余量留白：建议训练配置预留 10%~15% 显存余量，避免序列长度波动（长样本批次）再次触发 OOM。

（4）环境固化：将验证通过的依赖版本（accelerate 1.3.0 / peft 0.14.0 / transformers 4.49.0 / trl 0.8.6）与镜像配置写入环境脚本，便于团队复用与二次复现。

（5）配置模板分层：可整理出“多卡集群版”与“单卡适配版”两套 YAML 模板，降低后续在不同硬件间迁移的试错成本。