4GB显存，真能微调8B模型了

近日，一个名为 SOUP 的开源项目在 Show HN 引发关注：开发者尝试只用 4GB 显存的笔记本 GPU 微调 8B 参数模型。这个结果的真正价值，不是宣布“大模型训练不再需要显卡”，而是证明只要接受速度、上下文长度和训练自由度上的妥协，消费级低显存设备也能完成有实际用途的参数高效微调。

**SOUP 是一个面向低显存设备的大模型微调实验项目，核心目标是在显存无法容纳完整模型训练状态时，通过参数高效训练与内存调度完成 8B 模型适配。**截至 2026 年 8 月 4 日，这类项目更适合被视为开发者实验方案，而不是已经成熟到“一键稳定训练所有 8B 模型”的通用框架。

判断先放在前面：**4GB 显存微调 8B 模型是可行的，但这里的“微调”通常指 LoRA 或 QLoRA，而不是全参数训练；能跑起来也不等于跑得快，更不等于适合生产训练。**它适合做个人知识风格适配、固定格式输出、分类与抽取等小数据实验，不适合长上下文训练、大规模语料继续预训练，也不适合需要频繁迭代的团队项目。

先算账：8B 模型为什么塞不进 4GB 显存

**显存占用不只来自模型权重，还包括梯度、优化器状态、激活值和 CUDA 临时缓冲区。**很多“8B 模型 4bit 后只有 4GB”的说法只计算了静态权重，却忽略了训练和推理的内存结构完全不同。

以 80 亿参数为例，单纯保存权重需要的理论空间如下：

| 权重格式 | 每参数占用 | 8B 权重理论体积 | 能否直接放入 4GB 显存 | |---|---:|---:|---| | FP32 | 4 字节 | 32GB | 不能 | | FP16/BF16 | 2 字节 | 16GB | 不能 | | INT8 | 1 字节 | 8GB | 不能 | | INT4 | 0.5 字节 | 4GB | 只能勉强容纳权重，几乎没有训练余量 |

**全参数训练的内存成本通常会超过 100GB，而不是表面看到的 16GB。**如果采用混合精度训练，除了 FP16 权重，还可能保留 FP32 主权重、FP16 梯度，以及 Adam 优化器的一阶和二阶状态；再加上激活值与框架开销，80 亿参数模型很容易越过 100GB。PaddleNLP 社区在讨论 Llama 3.1 8B 时也给出了模型状态至少约 104GB 的估算，并建议改用 LoRA。

**INT4 权重恰好约为 4GB，不代表一张 4GB 显卡可以直接训练 8B 模型。**显卡驱动、CUDA context、量化元数据、输入张量和中间激活同样需要显存，因此低显存训练必须让部分权重停留在系统内存，或者按层装入 GPU，算完后立即释放。

4GB 方案的本质：不是压缩，而是“少放、晚放、用完就搬走”

**低显存微调的核心是重新安排参数在 GPU、CPU 和磁盘之间出现的时间。**普通训练默认整套模型长时间驻留显存，而 SOUP 这类方案更接近狭小厨房里的流水作业：台面一次只摆当前要处理的食材，其余内容放在储物区，需要时再搬过来。

这套路径通常由四项技术共同完成。

1. LoRA 只训练少量增量参数

**LoRA 是一种冻结基础模型权重、只训练低秩增量矩阵的参数高效微调方法。**假设某个线性层权重为 W，LoRA 不直接更新整个 W，而是学习两个更小矩阵 A 和 B，让最终变化量近似为 BA。

以一个输入、输出维度均为 4096 的线性层为例，原矩阵包含 16,777,216 个参数；如果 LoRA rank 设为 8，两个增量矩阵合计只有 65,536 个参数，相当于原矩阵的约 0.39%。这会显著减少可训练参数、梯度和优化器状态，但基础模型仍然要参与前向与反向计算。

2. QLoRA 用低位宽保存冻结权重

**QLoRA 是将冻结的基础模型权重量化到 4bit，同时以较高精度训练 LoRA 参数的微调方法。**它解决的是基础权重太大的问题，而不是把所有计算都变成 4bit；实际矩阵计算仍可能在 FP16 或 BF16 中进行。

4bit 量化可以把 8B 权重的理论体积从 FP16 的 16GB 降到约 4GB，降幅为 75%。但量化块、缩放因子和计算缓存会产生额外开销，所以真实占用通常高于简单乘法结果。

3. CPU offload 把系统内存当作后仓

**CPU offload 是把暂时不参与计算的权重或优化器状态保存在系统内存，只在需要时传入 GPU。**它用 PCIe 传输换取显存空间，因此 4GB 训练能否顺利进行，往往不只取决于显卡，还取决于系统内存容量、内存带宽和 PCIe 链路。

如果机器只有 8GB 系统内存，即使 GPU 显存达到 4GB，也很容易在加载模型、数据预处理或保存检查点时触发交换分区。更现实的配置是 16GB 内存起步，32GB 会明显从容；SSD 还需要为基础模型、量化缓存、数据集和多个适配器检查点预留数十 GB 空间。

4. 激活检查点用算力换显存

**梯度检查点是一种不保存全部中间激活、在反向传播时重新计算部分前向结果的技术。**它可以降低激活值占用，但每一步训练要做更多计算，因此速度会进一步下降。

序列长度对激活值尤其敏感。把训练上下文从 2048 tokens 降到 512 tokens，虽然不能简单断言显存一定减少 75%，但通常会带来非常明显的下降；如果模型仍使用传统注意力实现，注意力矩阵的部分开销还会随序列长度平方增长。

4GB、8GB 与 24GB 显卡的训练体验完全不同

**4GB 方案解决的是“能不能做”，8GB 以上才开始讨论“是否好用”。**在同一个 8B 模型上，不同显存档位对应的训练目标和容错空间并不相同。

| GPU 显存 | 典型方案 | 建议序列长度 | 建议 micro batch | 主要限制 | 适合场景 | |---:|---|---:|---:|---|---| | 4GB | 4bit LoRA、CPU 卸载、分层加载、梯度检查点 | 128—512 | 1 | 极慢、频繁搬运、容易 OOM | 验证想法、小数据适配 | | 8GB | QLoRA、部分 CPU 卸载 | 512—1024 | 1—2 | 长上下文仍吃紧 | 个人项目、数千条样本 | | 12GB—16GB | 常规 QLoRA | 1024—4096 | 1—4 | 受模型结构影响 | 较完整的本地实验 | | 24GB | QLoRA 或更高精度 LoRA | 2048—8192 | 2—8 | 主要受吞吐量限制 | 高频迭代与中型数据集 | | 80GB 级 | 全参数或高吞吐 LoRA | 取决于模型上限 | 更高 | 成本高 | 研究与生产训练 |

**这张表中的长度和批量是保守起点，不是硬件保证。**不同 8B 模型的层数、隐藏维度、注意力实现和词表大小不同，显存占用也会变化；Windows 原生环境、WSL2 和 Linux 的可用显存还可能存在差异。

实战前先确认：你的任务真的需要微调吗

**微调最适合改变模型的行为模式，而不是把大量事实硬塞进参数。**如果目标是让模型记住经常更新的内部文档，RAG 通常比 LoRA 更合适；如果目标是让模型稳定输出固定 JSON 结构、遵守特定客服语气、识别领域标签，LoRA 才更有价值。

适合 4GB 设备尝试的任务包括：

• 将自然语言稳定转换为固定字段格式；
• 学习客服、游戏角色或写作语气；
• 对短文本做分类、实体抽取与意图识别；
• 学习某套简短、稳定的操作规范；
• 用几百到几千条高质量样本验证数据配方。

不适合 4GB 设备的任务包括：

• 以数十亿 tokens 进行继续预训练；
• 训练 8K、32K 或更长上下文能力；
• 全参数改变模型的知识结构；
• 在大量超参数组合上做网格搜索；
• 追求每小时处理数百万 tokens 的训练吞吐量。

第一步：把环境变量变少，而不是一次堆满功能

**低显存训练最重要的环境策略是固定变量并逐项验证。**建议优先使用 Linux 或 WSL2、近期稳定版 NVIDIA 驱动以及与 PyTorch 对应的 CUDA 运行环境，并确保系统不会同时运行浏览器 GPU 加速、游戏或其他 CUDA 程序。

可以先获取 SOUP 仓库并创建独立环境：

git clone https://github.com/MakazhanAlpamys/Soup.git
cd Soup
python -m venv .venv
source .venv/bin/activate

**依赖版本应以仓库当前 README 和锁定文件为准。**低显存训练对 PyTorch、Transformers、量化库和 CUDA 版本组合较敏感，盲目升级某一个包，可能导致量化算子不可用、CPU 卸载失效或显存突然增加。

在开始训练前，先记录硬件基线：

nvidia-smi
python --version

**空闲状态下的可用显存应尽量接近显卡标称容量。**一张 4GB 显卡如果已经被桌面、浏览器和视频程序占用 800MB，实际留给训练的空间只剩约 3.2GB，很多本来贴线可运行的配置会直接失败。

第二步：从保守预算开始配置

**4GB 显存的第一轮目标应该是成功完成 20 个训练 step，而不是直接跑完整数据集。**下面是一份配置预算表，具体字段名称要以 SOUP 当前版本为准，不应把它当成可以直接复制执行的配置文件。

weight_precision: 4bit
lora_rank: 4
lora_alpha: 8
lora_dropout: 0.05
sequence_length: 256
micro_batch_size: 1
gradient_accumulation_steps: 16
gradient_checkpointing: true
cpu_offload: true
train_embeddings: false
train_lm_head: false

**LoRA rank 设为 4 或 8，是 4GB 设备更合理的起点。**rank 越高，可训练参数和优化器状态越多，但效果并不会线性增长；对格式化输出、分类和语气适配等窄任务，低 rank 往往已经够用。

**目标模块应该先少后多。**第一轮可以只考虑注意力中的查询和值投影层；如果显存和训练速度允许，再扩展到键投影、输出投影或 MLP 层。一次把所有线性层都挂上 LoRA，会增加训练参数、检查点体积和计算负担。

**序列长度应该根据样本分布设置，而不是照抄模型上限。**如果 90% 的训练样本都少于 220 tokens，把长度设为 2048 只会浪费计算；更稳妥的方法是先统计 token 长度的 P90 或 P95，再设置略高于该分位数的截断值。

第三步：数据质量比多跑几个 epoch 更重要

**低算力训练必须优先提高每条样本的信息密度。**在只有 4GB 显存的情况下，清洗 1000 条高质量数据，通常比反复训练 10000 条重复、冲突或模板错误的数据更划算。

训练数据至少要做四项检查：

1. **格式一致性检查。**同一种任务不要混用互相冲突的系统提示和输出格式。
2. **重复率检查。**大量完全相同的回答会让模型过度拟合固定短语。
3. **长度检查。**超长样本被截断后，可能只留下问题而丢掉答案。
4. **留出集检查。**至少保留 5%—10% 的样本不参与训练，用于比较前后效果。

**聊天模型应沿用基础模型对应的 chat template。**Llama、Qwen、Gemma 等模型使用的特殊 token 与角色模板并不相同，模板套错可能让 loss 正常下降，但推理时表现反而恶化。

第四步：先跑 20 步，再决定是否加码

**短程试跑是排查低显存训练问题成本最低的方法。**建议先使用 20—50 条样本、训练 20 个 step，并同时观察显存峰值、系统内存、GPU 利用率、单步耗时和 loss。

运行期间可以持续观察 GPU：

watch -n 1 nvidia-smi

**一个健康的低显存训练过程不一定有很高的 GPU 利用率。**如果方案频繁在 CPU 与 GPU 之间搬运权重，GPU 利用率可能呈锯齿状波动；这不一定代表程序错误，而是内存换时间的直接结果。

需要重点记录的指标包括：

| 指标 | 正常信号 | 风险信号 | |---|---|---| | GPU 显存 | 峰值稳定，不持续上涨 | 每步增加，最终 OOM | | 系统内存 | 有波动但能回落 | 持续逼近物理内存上限 | | Loss | 总体下降，允许短期抖动 | 很快变为 NaN 或始终不变 | | 单步耗时 | 前几步预热后趋于稳定 | 越跑越慢，磁盘持续高负载 | | GPU 利用率 | 周期性起伏 | 长时间为 0 且进程无输出 |

**如果发生 OOM，调整顺序应从最影响显存的项目开始。**先缩短 sequence length，再确认 micro batch 为 1，然后减少 LoRA 目标层和 rank，最后再检查量化与 CPU offload 是否真的生效。梯度累积主要模拟更大的有效 batch，不会让单次前向的激活值消失。

第五步：不要只看训练 loss

**训练 loss 下降只能说明模型更会复现训练数据，不能证明它在真实任务上更好。**低数据量 LoRA 尤其容易出现过拟合：训练样本回答得很像，换一种问法就崩。

建议至少建立三组测试：

• **原始能力组：**检查微调后是否损害基础问答、推理与语言能力；
• **目标任务组：**检查格式正确率、分类准确率或人工偏好；
• **对抗改写组：**把训练问题换一种说法，观察是否仍能完成任务。

**结构化任务应使用可计算指标。**例如 100 条测试数据中有 93 条通过 JSON Schema 校验，就记录格式通过率为 93%；分类任务则记录准确率、F1 和混淆矩阵，不要只凭几段对话截图判断成功。

**生成任务应固定采样参数后再比较。**基础模型和 LoRA 模型需要使用相同的 temperature、top-p、最大生成长度与系统提示，否则差异可能来自采样，而不是训练。

第六步：只保存适配器，别急着合并模型

**LoRA 训练完成后优先保存 adapter，而不是立刻合并成完整权重。**适配器通常比基础模型小得多，更方便版本管理，也能让同一个 8B 基座挂载多个任务版本。

在 4GB 显卡上合并权重可能再次触发内存问题，因为合并过程可能需要同时持有基础权重、LoRA 参数和输出权重。更稳妥的做法是先在 CPU 内存中完成合并，或者直接在推理时动态加载适配器。

**基础模型版本必须与 adapter 严格对应。**即使模型名称相似，只要权重修订版本、词表或层结构不同，适配器就可能无法加载，或者在没有明显报错的情况下产生错误输出。

这类方案最大的代价是时间

**4GB 微调把显存瓶颈转化成了传输和计算瓶颈。**当模型层不断在系统内存和 GPU 之间移动时，PCIe 带宽、内存拷贝、量化与反量化都会拖慢训练；笔记本 GPU 还可能因功耗墙和温度墙降频。

因此，不能用桌面 RTX 4090 的训练速度推算 4GB 笔记本 GPU 的耗时。即使两张卡都能执行同一套 CUDA 算子，显存带宽、计算单元、功耗和散热能力也可能相差数倍，CPU offload 还会进一步放大差距。

**更合理的成本判断是先测每 step 耗时，再估算完整训练。**如果一次试跑稳定后的单步耗时为 30 秒，完整任务需要 3000 step，那么纯训练时间约为 25 小时；再考虑评估、保存检查点和异常重跑，实际占用会更长。

SOUP 的价值，不是取代成熟框架

**SOUP 最有价值的地方，是把 4GB 设备从“只能推理小模型”推进到“可以验证 8B 微调想法”。**它降低了个人开发者接触参数高效训练的硬件门槛，也适合教学、算法验证和隐私敏感的小数据实验。

**SOUP 暂时不应被理解为 LLaMA-Factory、Transformers PEFT 或云端训练平台的全面替代品。**成熟框架在模型覆盖、分布式训练、日志、断点恢复、评估与社区验证方面仍更完整；SOUP 更像一把针对极端显存预算打造的专用工具。

| 方案 | 最低硬件门槛 | 训练速度 | 配置复杂度 | 灵活性 | 推荐用途 | |---|---|---|---|---|---| | SOUP 类低显存方案 | 最低，可挑战 4GB GPU | 慢 | 较高 | 中等 | 可行性验证、教学实验 | | 常规 QLoRA/PEFT | 通常建议 8GB—24GB | 中等 | 中等 | 高 | 个人与团队微调 | | LLaMA-Factory | 取决于模型与配置 | 中等至快 | 较低 | 高 | 标准化训练流程 | | 全参数训练 | 通常需要多张大显存 GPU | 快但成本高 | 高 | 最高 | 研究、继续预训练 |

最后的实战建议

**4GB 显存微调 8B 模型应该被当作工程约束题，而不是性能奇迹。**它证明了“显存不够”不再等于“完全不能训练”，但每省下一部分显存，通常都要用更多系统内存、传输时间、重复计算或功能限制来交换。

如果手头只有一台 4GB 显存笔记本，最稳妥的路线是：选择一个 8B 指令模型，准备 500—2000 条高质量短样本，将序列长度控制在 256 左右，以 micro batch 1、LoRA rank 4 起跑，开启 4bit 权重、CPU offload 与梯度检查点，先完成 20 步稳定性测试，再逐项增加长度、rank 和数据量。

**只要任务边界足够窄，4GB 设备训练出来的 adapter 完全可能有用。**但如果一次实验需要运行数十小时，或者每次修改数据都要重新等待一天，那么升级到 12GB—24GB 显卡或短期使用更高规格算力，往往比继续压榨 4GB 显存更经济。

参考来源

• SOUP：Fine-tune an 8B model on a 4 GB laptop GPU：本文话题对应的开源项目，展示低显存笔记本 GPU 微调 8B 模型的实现方向。
• PaddleNLP Issue #9293：讨论 Llama 3.1 8B 的全参数 SFT 内存需求，以及在消费级 GPU 上改用 LoRA 的建议。
• Hugging Face PEFT：主流参数高效微调工具库，可用于理解 LoRA adapter、目标模块与模型加载机制。
• Hugging Face Transformers 性能文档：介绍梯度累积、梯度检查点、混合精度等训练显存优化方法。