Soup：用一份 YAML 在 4 GB 显卡上微调 8B 模型
Fine-tune LLMs from one YAML. Layer streaming trains an 8B model on a 4 GB laptop GPU.
秒懂
- 它是什么？
- Soup 是一个把 LLM 微调压缩成单条命令的 CLI 工具，主打低显存场景。它的 layer streaming 机制能在 4 GB 笔记本 GPU 上训练 8B 模型，但该功能仍标注为 BETA，且最新版本刚修复了一个重大的显存浪费问题。
- 适合谁用？
- Soup 适合那些拥有低端消费级 GPU、想本地微调 8B 级模型、且不愿折腾 SSH 和复杂训练脚本的个人开发者或小团队。它不适合需要精确控制训练流程的研究人员，也不适合训练超过 8B 参数或使用非 LoRA 方法的场景。
- 能商用吗？
- 可以。Apache-2.0 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库在最近一天内有新的提交。
- 用什么语言写的？
- 主要是 Python（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决的是哪一类痛苦
微调大语言模型通常意味着先配置远程 GPU 服务器，再处理 CUDA 版本、Python 依赖、数据格式和训练脚本之间的冲突。Soup 的定位是把这个过程压缩成一条命令。根据 README，它的目标是让用户不用 SSH、不用写配置文件，只需一个 YAML 文件就能完成微调。这主要面向个人开发者、小型团队，以及那些只有一台带 4 GB 显存笔记本的人。它不是一个通用训练框架，而是一个把 QLoRA 流程封装好的前端。如果你从未微调过模型，或者每次都要花半天时间让训练脚本跑起来，Soup 的设计意图就是消除这部分摩擦。
Layer streaming：把冻结的基座模型请出显存
Soup 最核心的机制是 layer streaming，这是一个可选功能，通过配置项 stream_layers: true 开启，目前仍标注为 BETA。传统 QLoRA 训练会把整个冻结的基座模型加载到显存，一个 8B 模型即使量化到 NF4 也需要数 GB 空间。Soup 的做法是逐层处理：把基座模型按 decoder layer 拆分，每次只把一个层送入 GPU，计算完梯度后就换下一层。README 中给出的实测数据是，在 RTX 3050 Laptop 4 GB 上，用 Llama-3.1-8B-Instruct 加 NF4 量化，峰值显存 3.32 GB，吞吐 119.6 tok/s。这个数字是在 v0.72.2 版本测得的，而 v0.73.0 做了一次正确性修复，在 32B 模型上吞吐下降了 4.8%，且没有在 4 GB 显卡上重新验证。所以这个性能数据只能作为参考，不能当作当前版本的承诺。
安装与启动：三条命令进入训练
Soup 的安装方式很直接。在 Python 3.10 到 3.12 环境中，执行 pip install "soup-cli[train]" 即可安装带训练功能的版本。注意，如果只装裸的 soup-cli，那只是一个轻量 CLI，不能训练。安装后，先运行 soup init --template chat 生成一个聊天模板的 YAML 配置，再执行 soup train 启动训练。这个流程不需要任何配置文件以外的设置，自动检测 GPU、自动决定 batch size 和量化方式。README 强调，soup serve 命令在绑定非回环地址时必须提供 --tool-auth-token，否则进程会以退出码 2 结束。这个安全机制在 v0.74.0 中变成了强制行为，之前只是警告。
v0.74.0 的教训：一个 fp32 加载让显存翻倍
最新版本 v0.74.0 的发布说明里有一个值得警惕的细节：在修复之前，所有 SFT 加载路径都把冻结的基座模型以 fp32 精度加载，即使检查点本身是半精度。这导致显存占用翻倍。在 H100 上用 Llama-3.1-8B 加 LoRA 测试，峰值从 48,241 MiB 降到 18,658 MiB，减少了 28.9 GB，而且三次重复实验的结果字节一致。这意味着 Soup 在很长一段时间里都多占了近 30 GB 显存，而用户可能毫无察觉。这个案例说明，宣称的显存优化需要持续验证，不能依赖某个版本的单次测量。对于 4 GB 显卡用户来说，这个修复可能意味着 layer streaming 的显存余量更大，但 README 没有给出修复后在 4 GB 卡上的新数据。
已知限制与兼容性问题
Soup 并非没有坑。README 明确提到一个依赖冲突：项目声明的 torch>=2.5.0 下限与 trl>=0.29 不兼容，在 torch 2.5.1 下 trl 无法导入。新安装通常会解析到更新的 torch，但如果你锁定版本，就可能遇到导入失败。另一个限制是 layer streaming 在免费 Colab 或 Kaggle 的 T4、P100、V100、GTX 16xx 上无法工作，原因是 peft 以检查点的 dtype 创建 LoRA 适配器，而 fp16 GradScaler 需要 fp32 梯度。这意味着低端 GPU 并不都能享受 layer streaming 的好处。此外，v0.74.0 还修复了四个 SSRF 绕过，涉及 IP 地址的缩写、十进制、十六进制和八进制写法，这些漏洞影响了遥测和 webhook 防护。如果你把 Soup 部署在可访问网络的服务上，需要关注这类安全问题。
一个替代方案：标准 QLoRA 工具链
Soup 并非唯一选择。标准的 QLoRA 流程通常使用 Hugging Face 的 transformers、peft 和 trl 库，手动编写训练脚本。与 Soup 的核心区别在于，标准流程把基座模型整体加载到显存，因此 4 GB 显卡几乎不可能训练 8B 模型，除非使用梯度检查点等额外技巧。Soup 的 layer streaming 提供了另一种思路，但代价是增加了复杂性和 BETA 状态。如果你不需要在 4 GB 设备上训练，或者你更愿意控制每个训练细节，那么标准 QLoRA 工具链更透明，也更容易调试。Soup 的价值在于它把这些库的集成工作打包好了，省去了版本匹配和脚本编写的麻烦。
维护成本与许可证考量
Soup 采用 Apache-2.0 许可证，这是一种宽松的许可证，允许商业使用和修改，但如果你分发修改后的版本，需要保留原始版权声明。项目托管在 GitHub，最近一次推送是 2026 年 9 月，说明仍在活跃维护。v0.74.0 的发布说明提到，该版本的 120 个合并 pull request 中有 116 个来自外部贡献者，共 25 人。这既有好处也有风险：外部贡献能带来多样化的修复，但也意味着维护者需要花时间审查和合并。对于采用者来说，升级成本取决于你使用的功能：如果你只是用 soup train，那么跟随版本升级通常不会破坏配置；但如果你依赖 soup serve 的某些行为，需要注意 v0.74.0 中退出码和工具端点的变化。建议在升级前阅读每个版本的 release notes，特别是涉及安全修复的版本。
编辑结论
Soup 适合那些拥有低端消费级 GPU、想本地微调 8B 级模型、且不愿折腾 SSH 和复杂训练脚本的个人开发者或小团队。它不适合需要精确控制训练流程的研究人员，也不适合训练超过 8B 参数或使用非 LoRA 方法的场景。在采用前，务必先阅读 docs/performance-and-quantization.md 中关于 layer streaming 的 BETA 说明，并在自己的显卡上运行 notebooks/proof-4gb.ipynb 验证显存峰值与数值一致性。同时检查 v0.74.0 的修复是否解决了你关心的 fp32 加载问题，因为该问题曾导致显存占用翻倍。如果这些验证通过，Soup 可能是你接触 LLM 微调的最短路径；如果失败，请回到标准 QLoRA 工具链。
社区笔记