LLM 微调基础：加载 / 微调一个 7B 模型，到底需要多少显存？
7B（70亿）参数模型的显存需求：基础推理 14GB，全参 SFT 微调 87GB，LoRA 微调 18 GB，PPO 超 130 GB，GRPO 80-100 GB。
·
对于一个70亿参数的模型，从简单的推理到复杂的强化学习训练，显存占用的跨度可以从14GB到超过100GB。 具体的需求取决于我们使用的技术（如SFT、PPO、GRPO）以及是否应用了LoRA、量化等优化手段。
为了更直观地理解，本文不同阶段的显存占用情况整理成了下面的表格，以清晰展示从基础推理到全参数微调，再到PPO和GRPO这些强化学习训练的显存需求差异。
🧠 7B模型各阶段显存占用概览
| 阶段 | 场景 / 算法 | 估算显存占用 | 核心组成部分与说明 |
|---|---|---|---|
| 基础占用 | 仅加载模型 (FP16) | ~14 GB | 模型本身参数是起点。在FP16精度下，70亿参数正好占用14GB 。这是所有后续计算的基础。 |
| 推理 | 在线服务 | ~17 GB | 在模型参数基础上，增加了KV缓存和激活值。这部分是动态的，与序列长度和并发数相关。例如，处理32K上下文时，KV缓存可能需要额外2.5GB 。 |
| 监督微调 (SFT) | 全参数微调 | ~87 GB | 这是最“重”的阶段。除了模型参数(14GB)和梯度(14GB)，最大的开销来自优化器状态。以AdamW为例，它为每个参数存储两个32位的优化器状态，需要惊人的56GB 。 |
| LoRA 微调 | ~18 GB | 通过冻结原模型，只训练极少量参数（约1%），优化器状态和梯度的显存占用被大幅压缩，从56GB和14GB分别降至约0.56GB和0.14GB，是性价比极高的方案 。 | |
| QLoRA (4-bit) | ~8 GB | 在LoRA基础上，再将基础模型量化为4-bit加载（占3.5GB），使得在单张消费级显卡上微调7B模型成为可能 。 | |
| 强化学习 (RL) | PPO | > 130 GB | 显存危机的重灾区。它需要同时加载策略模型、参考模型、奖励模型和价值模型。仅策略模型和参考模型的SFT开销就已接近90GB，价值模型（与策略模型规模相当）会再增加约40GB+，导致总需求轻松破百 。 |
| GRPO | ~80-100 GB | 相比PPO，GRPO的核心优化是直接去掉了价值模型（Critic），用组内奖励的统计量替代其功能，因此显存需求大幅下降 。NVIDIA官方建议，即使是7B模型的GRPO训练，也需要至少2张80GB的GPU（合计160GB显存）才能比较从容地启动 。 |
💡 核心要点解析
-
为什么全参数SFT这么“吃”显存？
关键在于优化器状态。在训练时，我们不仅需要模型本身，还需要为每个参数存储其梯度，以及优化器用来更新参数的额外状态（如Adam的动量和方差）。为了计算的数值稳定性，这些优化器状态通常用32位精度存储，因此其显存占用非常高 。 -
RL训练中，PPO和GRPO的关键区别在哪？
- PPO 就像一个需要“教练”的运动员。这个“教练”就是价值模型，它负责实时评估运动员（策略模型）的每一个动作，指导其改进。但聘请这个“教练”需要付出巨大的显存代价 。
- GRPO 则像是一个“自学”的运动员。它不需要单独的“教练”，而是通过在同一批次的多次尝试中，比较自己哪个动作获得了更高的“奖励分”（即组内奖励归一化）来学习和优化，从而省去了价值模型的巨大开销 。
🔧 如何给“显存危机”解围？
如果硬件资源有限，不必灰心，有很多成熟的优化策略可以背着我们“省吃俭用”：
- 首选参数高效微调：LoRA 和 QLoRA 是解决SFT显存问题的“灵丹妙药”，能让显存需求从87GB直接降到个位数 。
- 用GRPO替代PPO：如果要做RL，优先考虑 GRPO 这类无价值模型的算法，能从算法层面直接降低一半左右的显存压力 。
- 开启“内存省钱”模式：
- 梯度检查点：用一点点计算时间，换取反向传播时不存储大量中间激活值，能节省约30-40% 的显存 。
- 混合精度训练/量化优化器：使用 AdamW8bit 优化器，将优化器状态量化为8位，能减少75%的优化器显存开销 。
腾讯云面向开发者汇聚海量精品云计算使用和开发经验，营造开放的云计算技术生态圈。
更多推荐
8
0- 0
已为社区贡献1条内容
所有评论(0)