文章目录Soup v0.72.4技术解析层流式QLoRA如何在4GB显存微调8B模型一、引言二、QLoRA之后为什么还需要Layer Streaming2.1 显存都花在哪里2.2 数据流三、v0.72.4让偏好对齐也能流式运行3.1 DPO的第二个模型怎么省掉3.2 四种偏好损失3.3 内存免费时间不免费四、安装与配置实战4.1 安装4.2 4GB显存的SFT配置4.3 DPO配置五、性能、正确性与已知限制六、横向对比本地小显存训练怎么选七、总结Soup v0.72.4技术解析层流式QLoRA如何在4GB显存微调8B模型一、引言亲爱的朋友们创作不容易若对您有帮助的话请点赞收藏加关注哦您的关注是我持续创作的动力谢谢大家有问题请私信或联系邮箱jasonai.fngmail.comQLoRA 把基座权重量化到 4 bit只训练小型 LoRA 适配器已经显著降低微调门槛。但一个 8B 模型的量化权重、激活、优化器状态和 CUDA 缓冲区叠加后通常仍超出 4 GB 笔记本 GPU 的舒适范围。开源训练工具 Soup 在 v0.72 系列引入 Layer Streaming冻结基座不常驻显存而是从主机内存或 NVMe 按解码层送入 GPU。项目在 RTX 3050 Laptop 4 GB 上报告Llama-3.1-8B-InstructNF4LoRA、序列长度 512 的训练峰值为 3.32 GB吞吐 119.6 tok/s并与常驻权重运行做到 bit-exact。2026 年 8 月 3 日发布的 v0.72.4 又把流式训练从监督微调扩展到 DPO、ORPO、SimPO 和 KTO。它解决的不是“4 GB 显存装下完整 8B 模型”而是让冻结权重按层经过显存只有适配器和当前计算所需状态驻留。二、QLoRA之后为什么还需要Layer Streaming2.1 显存都花在哪里项目全参微调普通QLoRASoup Layer Streaming基座权重高精度常驻GPU4bit常驻GPU4bit存RAM/NVMe按层送GPU可训练参数全部参数LoRA适配器LoRA适配器优化器状态很大只覆盖LoRA只覆盖LoRA激活取决于序列和批量仍是主要变量仍是主要变量传输开销低低每步多次读取层权重QLoRA 解决“权重精度与训练参数量”Layer Streaming 进一步解决“冻结基座是否必须常驻显存”。代价是 PCIe、内存或磁盘传输进入训练热路径。2.2 数据流RAM中的NF4基座 / NVMe权重 │ ▼ 逐层读取 GPU双缓冲区Layer N计算时预取Layer N1 │ ├─ 冻结基座前向/反向所需计算 └─ LoRA参数常驻并更新 │ ▼ 下一层覆盖缓冲区直至完成一轮核心条件是基座冻结。若每一层完整权重都要更新权重、梯度和优化器状态不能简单流过即丢LoRA 只训练低秩增量才使“基座移动、适配器驻留”成立。三、v0.72.4让偏好对齐也能流式运行3.1 DPO的第二个模型怎么省掉DPO 需要比较策略模型与参考模型。普通实现会保留第二份冻结模型正好抵消流式省内存的意义。Soup 使用同一份流式基座计算参考输出时关闭 LoRA 适配器计算策略输出时打开适配器不建立第二个模型实例。同一份流式基座权重 │ ├─ LoRA ON ─► policy log-prob └─ LoRA OFF ─► reference log-prob发布测试使用一个 730.44 MB 模型作为控制流式 DPO 峰值 81.87 MB流式 SFT 为 89.53 MB强制创建真实第二模型则达到 812.32 MB多出的 730.44 MB 正好是一份权重。这个小模型测试用于证明“没有第二实例”不能与 8B 模型 3.32 GB 的整机峰值直接比较。3.2 四种偏好损失方法是否需要参考模型v0.72.4处理DPO需要同一基座关闭适配器作为参考KTO需要与DPO相同batch size至少2ORPO不需要直接在流式策略上计算SimPO不需要直接在流式策略上计算项目特别澄清 KTO 并非真正 reference-freeGRPO 和 PPO 则明确不支持 Layer Streaming因为 rollout 生成每输出一个 Token 都要重新读取全部层无法摊薄传输成本。3.3 内存免费时间不免费DPO 每步读取层栈的次数约为 SFT 的 1.52 倍。Layer Streaming 让参考模型在显存上“免费”并不让额外前向在时间上消失。若主机内存带宽、PCIe 或 NVMe 较慢训练速度可能明显下降。四、安装与配置实战4.1 安装python-mvenv .venvsource.venv/bin/activate pipinstall-Usoup-cli[train]soup doctor项目要求 Python 3.10。v0.72.4 将 TRL 约束到0.7.0,0.25因为较新 TRL 分阶段移除了多种偏好 Trainer 使用的配置字段自行升级 TRL 可能导致导入或初始化失败。4.2 4GB显存的SFT配置base:meta-llama/Llama-3.1-8B-Instructtask:sftdata:train:./data/train.jsonlformat:chatmlmax_length:512training:stream_layers:truestream_source:autoquantization:4bitbatch_size:1lora:r:16alpha:32target_modules:[q_proj,v_proj]output:./outputsoup train--configsoup.yaml soup chat--model./output soupexport--model./output--formatgguf--quantq4_k_m4.3 DPO配置base:meta-llama/Llama-3.1-8B-Instructtask:dpodata:train:prefs.jsonlmax_length:512training:stream_layers:truequantization:4bitbatch_size:1lora:r:16target_modules:[q_proj,v_proj]4 GB 成功记录使用特定 RTX 3050、NF4、batch 1 和 seq 512不代表任意 8B、任意上下文都能装下。词表大小、架构、驱动、显示占用和桌面系统都会改变峰值。五、性能、正确性与已知限制项目官方记录/说明8B实测RTX 3050 Laptop 4GB峰值3.32GB119.6 tok/s正确性与相同损失的非流式运行bit-exact差异0.0数据源基座可来自RAM放不下时可来自NVMe状态Layer Streaming仍为BETA不支持流式GRPO/PPO因逐Token rollout反复读层VRAM pre-flight 对偏好损失采用保守上界可能拒绝实际能运行的长序列官方建议降低max_length。此外v0.72.0 流式训练保存的适配器曾因键名多出.inner.而不生效已在 v0.72.1 修复旧适配器应检查并重新训练或转换。六、横向对比本地小显存训练怎么选路线显存策略优势代价Soup Layer Streaming冻结基座按层从RAM/NVMe送GPU4GB可训练8B单YAML支持偏好损失传输慢仍为Beta普通QLoRA4bit基座常驻GPU工具和文档成熟、吞吐高8B通常需要更多可用显存CPU/NVMe Offload参数或状态分层卸载通用框架支持较多配置复杂性能依实现而异云GPU全部常驻大显存卡速度快、可扩展费用、数据边界与运维Soup 适合个人实验、教学和小数据 LoRA不等于 4 GB 笔记本已经能经济地进行大规模后训练。数据量大、上下文长或时间敏感时1624 GB 本地卡或云 GPU 仍更现实。七、总结维度核心结论核心机制冻结NF4基座存于RAM/NVMe按解码层送入GPULoRA适配器常驻训练4GB实测Llama-3.1-8B在RTX 3050 Laptop上峰值3.32GB官方记录119.6 tok/s版本升级v0.72.4新增DPO、ORPO、SimPO、KTO的流式偏好训练参考模型DPO/KTO复用同一基座并关闭适配器不创建第二份权重真实代价省显存但增加层读取架构仍为Beta不支持GRPO/PPO rolloutSoup v0.72.4 把“能否微调”与“模型能否常驻显存”拆开了。对冻结基座而言权重不必一直待在最昂贵的存储层只要接受更多传输时间4 GB 笔记本也能完成过去需要更大显存的 8B LoRA 与偏好对齐实验。参考资料Soup官方仓库Soup v0.72.4发布说明Exact Layer Streaming论文与测量记录