大模型微调：两类显存优化策略对比与选型

一、对比背景：为什么要把这两类策略放在一起比较

大模型微调是对算力与内存高度敏感的工作负载。以一个典型过程为例：当训练样本积累到约1.2万条后，通常希望做控制变量实验，观察不同超参与不同并行优化配置对模型效果和训练效率的影响。此时一个常见做法是参考业界实践文章的建议——在显存充裕的前提下，尽量使用分片程度更低的优化等级（即阶段二），以换取更高的训练吞吐；而在显存吃紧时退回分片程度更高的等级（即阶段三）。

问题往往出在“切换”这个动作上：优化等级从阶段三改成阶段二后，训练过程本身可能一切正常，却在保存模型检查点（checkpoint）时被系统直接终止，返回码-9，且没有任何详细堆栈；而重建一套全新环境后，又可能遇到返回码-11的段错误。这两类故障恰好分别暴露了两种策略在资源占用模型上的差异，以及它们共同依赖的环境版本匹配前提。

因此，本文明确的对比对象有两组：其一是大模型微调中两类主流显存优化策略——参数全量驻留的“策略A（阶段二）”与参数进一步分片的“策略B（阶段三）”；其二是微调过程中两类高频错误——返回码-9（进程被系统强制终止）与返回码-11（段错误）。前者决定“怎么选”，后者决定“出问题怎么查”。

二、对象定义：两个策略、两个错误码分别是什么

2.1 策略A与策略B

两者都源自“零冗余优化”这一通用思想，由主流分布式训练加速框架提供，按切分程度划分为多个等级，最常用的是下面两档：

• 策略A（对应常见的阶段二）：将优化器状态与梯度切分到各个GPU上，但模型参数在每张卡上保留完整副本，单卡显存中“参数”这一项没有被摊薄。
• 策略B（对应常见的阶段三）：在策略A的基础上，把模型参数也切分到各卡，每张卡只保留约1/N的参数；前向与反向计算需要完整参数时，按需临时聚合，用完即释放。

2.2 返回码-9与返回码-11

• 返回码-9：对应信号9（SIGKILL），表示进程被操作系统强制终止。在类Unix服务器操作系统中，当进程消耗的内存（包括CPU内存或GPU显存）过多时，内核的内存不足保护机制（OOM Killer）会直接杀死进程，退出码表现为-9。它不是程序自身抛出的错误，而是操作系统层面的强制终止，因此通常没有详细报错信息。
• 返回码-11：对应信号11（SIGSEGV），即段错误，表示程序试图访问它无权访问的内存地址，例如空指针解引用、越界访问、使用已释放的内存等，通常与程序或依赖库的缺陷、版本不匹配有关。

三、相同点分析

1. 目标一致：两者都是为了降低单卡显存占用，让有限数量的GPU能够装下更大的模型或更大的批次，本质上是“用通信换显存”的不同档位。
2. 技术基础一致：都基于数据并行叠加状态分片的思路，运行在同一套分布式训练框架之上，通过统一的配置入口切换，表面上“改一个参数”就能互换。
3. 适用场景一致：无论是大语言模型还是多模态模型的微调，无论是全参训练还是参数高效微调，两类策略都在同一套训练流程中使用。
4. 训练语义一致：两者都不改变优化目标与收敛逻辑，理论上是同一个训练过程的不同资源编排方式（数值上可能存在细微舍入差异）。
5. 共同前提一致：都要求深度学习框架的构建版本与本地GPU驱动支持的最高运行时版本相匹配，这个前提一旦被破坏，两类策略都可能以段错误等形式失败。

四、核心差异分析

4.1 分片对象与显存占用模型

策略A只切分优化器状态与梯度，单卡显存大致等于“完整模型参数 + 1/N的优化器状态与梯度 + 激活值”；策略B把参数也切分，单卡显存大致等于“1/N参数 + 1/N优化器状态与梯度 + 激活值 + 计算时临时聚合参数的缓冲区”。业界常用的粗估方法是：混合精度全参微调下，参数、梯度与自适应优化器状态合计通常达到“参数量×12字节”以上的量级，再叠加与批次大小、序列长度相关的激活值开销（该估算仅供量级参考，实际受框架实现与精度配置影响）。由此可见，两种策略对单卡显存的需求可能相差数倍，这直接决定了多大的模型能在什么样的卡上训起来。

4.2 CPU内存行为与检查点保存：最容易被忽视的差异

这是原文案例中-9错误的根因，也是两种策略最隐蔽的差异：

• 策略A下保存检查点时，分布式训练框架会在CPU内存中构造一份完整的模型权重副本用于汇聚与写出。对于中大型模型，这份临时副本本身就可能达到数十GB；如果机器只有64GB内存，再叠加训练过程的常驻内存，峰值极容易击穿物理内存上限，触发OOM Killer。其典型特征是：训练过程平稳运行，错误稳定复现在“保存checkpoint”这一固定环节，且报错信息极少。
• 策略B下参数本就分片存储，保存时的内存峰值画像相对可控。原文案例中，同样的64GB内存机器使用阶段三保存正常；将节点内存提升到128GB后，阶段二的-9问题随之消失，反向验证了根因。

结论很明确：显存优化策略的选择不只影响显存，还会显著改变CPU内存的峰值曲线。很多团队只监控GPU显存而忽视节点内存，这正是-9类问题难以定位的常见原因。

4.3 通信开销与吞吐

策略B在每次前向与反向计算时都需要临时聚合参数，通信量明显高于策略A，吞吐通常相对更低；策略A通信少、速度快，但单卡显存压力大，可能被迫缩小批次或序列长度。这也是业界实践普遍建议的原因：显存够用时优先选择分片程度更低的阶段二，把省下来的通信开销转化为训练速度；只有当单卡确实装不下完整参数时，才退让到阶段三。

4.4 故障表现与排查路径：-9与-11的对比

• 返回码-9的排查路径：没有堆栈时，先看复现规律——是否稳定发生在某个固定环节（如保存checkpoint）；再核对两个水位——CPU内存与GPU显存；最后对比变量——是否刚切换过优化等级、批次大小或模型规模。原文案例中，“从阶段三切到阶段二后才出现”以及“稳定发生在保存时”这两条线索，直接指向了内存峰值问题。
• 返回码-11的排查路径：段错误多与运行环境相关。原文案例中，拉取最新代码并新建环境后出现-11，根因是新框架默认安装的深度学习库构建面向更高的GPU运行时版本编译（案例中为12.8），而本地硬件驱动最高只支持12.1，二者不匹配。排查方向依次是：核对框架构建与驱动支持的最高运行时版本是否匹配、重建干净环境隔离依赖、逐项回退依赖版本。

4.5 环境兼容性要求

新版微调框架默认拉取的依赖可能“超前”于本地硬件：框架发布节奏快，默认安装的深度学习库往往面向较新的运行时版本编译，而本地驱动受硬件与驱动版本限制，支持的最高运行时版本可能明显更低。安装时应显式选择与驱动匹配的构建，而不是无条件接受默认最新版本。

五、对比表格

对比维度	策略A（阶段二）	策略B（阶段三）
分片对象	优化器状态、梯度	优化器状态、梯度、模型参数
单卡参数驻留	完整副本	约1/N
单卡显存占用	较高	显著更低
通信开销	较低	较高（前向/反向需临时聚合参数）
训练吞吐	较高	相对较低
CPU内存峰值	保存checkpoint时构造全量权重副本，峰值高	参数分片存储与写出，峰值相对可控
对节点内存的要求	高（需预留全量副本空间）	相对较低
适用模型规模	单卡可容纳完整参数副本的模型	更大规模模型、小显存多卡场景
典型故障	内存不足导致返回码-9	显存不足导致OOM；对通信带宽更敏感
配置与运维复杂度	相对简单	略高（需更多关注通信与聚合行为）

六、典型场景选择

• 场景一：显存充裕、追求训练效率。模型参数及优化器状态在单卡上装得下，优先选择策略A，用更低的通信开销换取更高吞吐。
• 场景二：模型较大、单卡装不下完整参数。选择策略B，用参数分片换取可行性，同时接受吞吐损失与更高的通信要求。
• 场景三：节点内存有限（如64GB）且使用策略A。必须提前评估保存checkpoint时的内存峰值，必要时扩容节点内存（原文案例中提升到128GB后问题解决），或采用降低保存频率、调整保存精度等通用手段缓解。
• 场景四：频繁重建环境或迁移到新机器。先完成版本匹配自检，再启动训练，避免-11类段错误反复出现。

七、选型建议：一个条件化的决策清单

# 示意性决策流程（伪代码）
def 选择优化策略(模型参数量, 单卡显存, 卡数, 节点内存):
    if 单卡显存 >= 完整参数 + 1/N优化器状态与梯度 + 激活值:
        策略 = 策略A          # 吞吐优先
        # 追加检查：保存checkpoint的内存峰值应明显小于节点内存
        if 保存时内存峰值 > 节点内存安全水位:
            扩容节点内存 或 调整保存策略
    else:
        策略 = 策略B          # 显存优先
    return 策略

配套的故障排查清单：

• 遇到返回码-9：确认是否发生在保存环节；核对CPU内存与GPU显存水位；回顾近期是否切换过优化等级或扩大了模型与批次规模。
• 遇到返回码-11：核对框架构建版本与驱动支持的最高运行时版本；在干净环境中重建依赖；逐项回退可疑组件版本。

需要强调的是，两类策略没有绝对优劣：策略A的优势来自“少通信”，代价是显存与内存峰值；策略B的优势来自“分得更碎”，代价是通信与吞吐。选型应基于模型规模、显存与内存水位、吞吐要求和团队运维能力做条件化判断。

八、迁移与使用注意事项

1. 从策略B迁移到策略A：
   • 显存复核：参数驻留从1/N变为全量，单卡显存需求陡增，需重新评估批次大小、序列长度与梯度累积配置。
   • 内存复核：保存checkpoint会产生全量权重副本，64GB量级的节点内存对中大型模型很可能不足，建议预留充分余量。
2. 环境重建与版本匹配：
   • 安装微调框架时，显式选择与本地驱动支持的最高运行时版本相匹配的依赖构建，避免默认拉取面向更新运行时编译的版本。
   • 使用独立、干净的环境隔离依赖，避免新旧库混装引发段错误。
3. 监控与告警：
   • 同时监控GPU显存与CPU内存两个维度，并为“保存checkpoint”环节单独记录日志或设置告警，因为这是内存峰值最容易失控的时刻。
4. 云上与自建环境同样适用：
   • 无论使用自建服务器，还是百度智能云等云上GPU实例，都建议在申请资源时同步评估显存与节点内存两个维度，并确认镜像内的框架构建与GPU驱动版本匹配，避免“显存够、内存不够”或“库新、驱动旧”两类隐性陷阱。

九、总结

策略A与策略B的本质差异在于“分片到哪一层”：阶段二止步于优化器状态与梯度，吞吐高，但要求单卡驻留完整参数，且保存checkpoint时的CPU内存峰值显著；阶段三把参数也切分，显存友好、对节点内存更宽容，但通信开销更大、吞吐相对更低。返回码-9与-11则分别指向“资源不足被系统终止”与“环境版本不匹配引发段错误”两条排查路径，前者看内存与显存水位和复现环节，后者看版本匹配与依赖环境。选型上没有放之四海皆准的答案：显存与内存充裕时优先追求吞吐，资源紧张时优先保可行性与稳定性；每次切换优化等级或重建环境时，把显存、内存、版本匹配三项自检纳入固定流程，就能规避文中这两类最常见的故障。