Soup: 通过层流式传输在 4 GB 笔记本 GPU 上微调 8B LLM

Soup 使 8B 模型在消费级笔记本 GPU 上微调成为可能

Soup 是一个旨在消除 LLM 微调基础设施开销的技术框架和 CLI。其主要突破在于层流式传输 (layer streaming)，它允许用户在显存仅为 4 GB 的 GPU 上微调 8B 参数模型。通过将冻结的基础模型视为只读流而非驻留在 VRAM 中的对象，Soup 将峰值显存需求从整个模型的大小降低到单个解码器层的大小。

层流式传输：技术实现与显存效率

层流式传输通过将冻结的基础模型移出 VRAM 并移入主机 RAM（如果 RAM 不足，则移入 NVMe 磁盘）来解决 VRAM 瓶颈。模型会逐层将解码器层喂给 GPU，同时在专门的 CUDA stream 上预取下一层，以保持吞吐量。

4 GB 硬件上的显存性能

在 RTX 3050 Laptop (4 GB VRAM, Windows) 上测得，Soup 对 Llama-3.1-8B (NF4 量化) 实现了以下结果：

峰值 VRAM 使用量： 3.32 GB
吞吐量： 119.6 tok/s
SM 占用率： 100%

对于像 Qwen2.5-3B (未量化的 bf16) 这样较小的模型，Soup 允许在 2.15 GB 的 VRAM 中进行训练，如果模型驻留在 VRAM 中，这种情况通常会导致 CUDA Out-of-Memory (OOM) 错误。

正确性与位精确性

由于流式传输可能会因为在损失值仍在下降时切断 autograd 路径而导致静默失败，Soup 实现了一套严格的正确性协议。每一次发布都经过验证，确保与非流式驻留运行相比是位精确 (bit-exact) 的，在九个架构家族中保持最大绝对 logit 差异为 0.0。

对偏好优化 (DPO, ORPO, SimPO, KTO) 的支持

在 0.72.4 版本中，Soup 将层流式传输扩展到了支持除监督微调 (SFT) 之外的偏好损失函数。

无显存占用参考模型

直接偏好优化 (DPO) 通常需要一个参考模型来与微调后的模型进行比较，这通常会使 VRAM 需求翻倍。Soup 通过使用相同的流式基础模型（并关闭其适配器）作为参考模型来优化这一点。

在 RTX 3050 4 GB 上，流式 DPO 的峰值显存仅为 SFT 峰值的 0.914×。相比之下，强制将第二个物理模型放入 VRAM 会增加 730 MB 的开销。

计算权衡

虽然节省了显存，但存在时间成本。DPO 每一步读取层堆栈的频率是 SFT 的 1.52×。其他方法如 ORPO 和 SimPO 是真正的无参考模型方法，不会产生这种特定的开销。

Soup 工作流：从配置到部署

Soup 将训练后的技术栈简化为单个 CLI。其工作流设计为“一个配置，一个命令”。

安装与设置

Soup 通过 PyPI 分发为 soup-cli。用户可以根据需求安装特定的技术栈：

pip install soup-cli (轻量核心)
pip install "soup-cli[train]" (包含 PyTorch, Transformers, 和 PEFT 的训练技术栈)
pip install "soup-cli[all]" (完整套件)

配置与训练

训练通过 soup.yaml 文件进行管理。一个针对 4 GB 显卡的典型配置包括：

stream_layers: true: 启用基础模型从 VRAM 之外流式传输。
quantization: 4bit: 使用 NF4 来减小存储大小。
stream_source: auto: 自动在 RAM 和 NVMe 磁盘之间进行选择。

训练后工具

除了训练，Soup 提供了一套部署和评估工具：

soup ship: 一个回归测试门禁，使用基于提取的评分器来确保在发布前微调模型不会破坏核心能力（例如，工具调用或 JSON 有效性）。
soup reward synth: 从参考输出中生成确定性的奖励验证器。
soup draft: 测量投机采样 (speculative decoding) 的接受率，并将目标模型蒸馏为稠密草稿模型。
export: 支持多种格式，包括用于 Ollama 和 llama.cpp 的 GGUF，以及 ONNX 和 TensorRT。

社区对本地 LLM 投资回报率 (ROI) 的见解

围绕该项目的讨论突出了向用于业务应用的轻量级、开放权重本地模型转变的趋势。社区成员指出，虽然大规模托管模型占据了新闻头条，但许多企业级用例（例如社区银行的 AML 合规性）并不需要那么高的算力，并且可以通过微调的小型模型更具成本效益地解决，这可能解决目前 LLM 基于 AI 实现面临的“ROI 危机”。