Soup 通过层流式传输在 4 GB 笔记本 GPU 上实现 8B 模型的微调

概览

Soup 将 LLM 微调转化为简单的工作流程：一个 YAML 配置，一个命令，无需 SSH 或基础设施麻烦。该项目面向 modeste 硬件进行训练，具体来说，使得 8B 模型能够在仅有 4 GB VRAM 的笔记本 GPU 上运行。

工作原理

层流式传输将冻结的基础模型保留在 VRAM 之外，并以每次一个解码器层的方式喂送到 GPU。在 LoRA 过程中，基础模型是只读的，因此可以驻留在主机 RAM 中，并被流送到一个小的预分配 VRAM 缓冲区，在专用 CUDA 流上提前预取一层。这将峰值 VRAM 使用量降低到大约单层的大小，而不是整个模型的大小。

量化被应用于基础模型（默认 4‑bit NF4），以进一步减小其内存占用。适配器（LoRA）在 VRAM 中正常训练。

对于基于偏好的损失（如 DPO），参考模型不是第二个副本；Soup 重复使用同样的流式基础模型，只是将其适配器关闭，因而只需要一套权重被流式传输。这使得参考模型在内存中“免费”，尽管会带来时间成本：DPO 每步读取层栈的次数大约是标准监督微调的 1.52 倍。

该系统保证与非流式常驻运行的位精确一致：在多种架构和精度下，最大绝对 logit 差异为 0.0，已在 CI 测试中验证。

关键特性

• 零 SSH： 无需登录远程 GPU 机器。
• 单一配置： 单个 soup.yaml 文件控制训练的所有方面。
• 自动处理： 批量大小、GPU 检测和量化均由系统自动管理。
• 本地执行： 训练在用户自己的 GPU 上使用 QLoRA 运行；无需云端。
• 偏好损失支持： v0.72.4 版本在层流式传输基础上加入了 DPO、ORPO、SimPO 和 KTO，参考模型的处理方式如上所述。
• 正确性聚焦： 项目强调位精确可重现性，而非原始速度。

最近更新（v0.72.4）

• 层流式传输现在适用于 DPO、ORPO、SimPO 和 KTO，而不仅仅是监督微调。
• 在 RTX 3050 Laptop（4 GB，Windows）上测量：流式 DPO 的峰值 VRAM 使用量为监督微调峰值的 0.914×。
• 强制使用第二个完整模型作为 DPO 的参考将增加约 730 MB，基本上相当于权重的另一份拷贝。
• ORPO 和 SimPO 真正做到无参考；KTO 复用了 DPO 的相同参考机制。
• VRAM 预检会将配对损失（chosen + rejected）视为行数的两倍。
• grpo 和 ppo 仍被排除，因为它们的生成步骤会每个 token 重新读取每一层，这无法通过流式传输摊销。
• 此版本仍标记为 BETA。

使用指南

安装

# Light core (CLI, config, data tools)
pip install soup-cli
# Add training dependencies (torch, transformers, peft, trl, datasets, …)
pip install "soup-cli[train]"

创建配置

# 交互式向导
soup init
# 或从模板开始（例如 chat）
soup init --template chat

一个典型的 soup.yaml 用于 8B 模型可能如下所示：

base: meta-llama/Llama-3.1-8B-Instruct
task: sft
data:
  train: ./data/train.jsonl
  format: alpaca
  val_split: 0.1
training:
  epochs: 3
  lr: 2e-5
  batch_size: auto
  lora:
    r: 64
    alpha: 16
  quantization: 4bit
  stream_layers: true
  stream_source: auto
output: ./output

训练、测试和交付

soup train --config soup.yaml          # LoRA, quantization, batching handled
soup chat  --model ./output            # talk to your model
soup push  --model ./output --repo you/my-model

其他命令包括 soup merge、soup export（导出为 GGUF、ONNX、TensorRT 等）、soup eval benchmark、soup data inspect、soup recipes list、soup autopilot 和 soup doctor（环境检查）。

性能测量（作者报告）

• 在 RTX 3050 Laptop（4 GB，Windows）上：Llama‑3.1‑8B 在 NF4 并使用层流式传输时达到 119.6 tok/s，峰值 VRAM 使用量为 3.32 GB，且 100 % SM 占用率。
• 同一张卡运行 Qwen2.5‑3B 时，使用未量化的 bf16 基础模型可达 143 tok/s，VRAM 占用为 2.15 GB；如果基础模型常驻则会导致 CUDA‑OOM。
• 相比于常驻基线（以 0.5 B 模型规模测量）的流式开销为 1.43×；作者提供了该基线以供验证。
• 这些数字是 Windows 特定的；Linux 可能会略有改善。
• 所有测量记录（包括被丢弃的运行）均可在仓库的 benchmarks/ 目录中找到。

社区洞察

• 本地模型 ROI： 评论者指出，小型开放权重模型可以避免大型托管模型的成本，并解决许多企业在使用 LLMs 时看到的 ROI 危机。
• 实际应用： 一位用户在社区银行使用微调后的 4B 模型进行 AML 合规，引用了相同的 ROI 依据。
• VRAM 疑问： 有评论询问为什么仍存在硬性 VRAM 需求；作者解释说，冻结的基础模型必须被流式传输，因为它仍然需要在每次矩阵乘法之前到达，而流式传输将需求降低到单层。
• 超参数调优： 另一位评论询问 Soup 如何自动调优超参数并进行复杂的训练决策。源码未描述自动超参数搜索；CLI 自动处理批量大小、GPU 检测和量化，而学习率、LoRA 秩等则在配置文件中设置。
• 数据量： 有关微调所需数据量的疑问被提出。仓库仅提供短示例数据集；源码中未给出所需数据量的具体指导。
• 硬件建议： 有请求针对特定 4 GB GPU 笔记本的推荐；源码未背书任何特定型号。
• 网站成本和可读性： 一位用户质疑“免费开始”标签是否会改变，并评论了站点的灰色-on-黑色可读性。项目许可证为 Apache‑2.0，且始终免费。
• 评论质量： 一位观察者指出，该帖子近半数评论似乎无价值或疑似 LLM 生成，低信号评论相对于帖子得分的比例较高。

局限性和常见问题

• VRAM 上限： 作者未声称在 4 GB 卡上支持超过 8B 的模型；14B NF4 需要约 7.5 GB 的页锁定主机内存，这超过了测试笔记本上测得的约 7.12 GB 上限。
• 偏好损失开销： 虽然参考模型在内存中是“免费”的，但 DPO 每步会增加约 1.52× 的层栈读取次数。
• 被排除的算法： GRPO 和 PPO 故意被排除，因为它们的每 token 生成会重新读取每一层，从而抵消流式传输的好处。
• 自动超参数调优： 源码未提供关于学习率、LoRA 秩或其他超参数自动调优的细节；这些必须在 soup.yaml 中指定。
• 数据量指南： 未给出通用的所需微调数据集大小规则；用户需自行实验。

结论

Soup 表明，通过层流式传输和 4‑bit 量化，8B 参数的 LLM 可以在仅具 4 GB VRAM 的消费级笔记本 GPU 上进行微调。该方法保持数值精确性（与常驻训练的位精确匹配），同时将基础设施需求降至最低——无需 SSH，仅需一个配置文件，并自动处理批量大小和量化。该项目仍然是开源的（Apache‑2.0），并鼓励社区贡献，尤其是在单个 4 GB 笔记本无法提供的硬件密集型验证方面。