加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
微信扫码咨询客服
POMOAI — 让开源 AI 即刻运行
加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
从"配置地狱"到"一行命令"：Soup 如何让 LLM 微调变得触手可及
凌晨两点，你终于凑齐了想要的对话数据——精选的客服记录、修正后的思维链样本、精心构造的偏好对比。打开文档一看：2万条，格式标准，质量上乘。
然后你看了看手边的 RTX 3060，12GB 显存。
"没事，"你安慰自己，"8B 模型 QLoRA 微调肯定够了。"
三小时后，CUDA out of memory。
你的经历并非孤例。事实上，LLM 微调领域存在一个根深蒂固的矛盾：真正有价值的是小团队和个人开发者，他们最了解自己的垂直场景、最能做出差异化的微调数据——但他们恰恰是最没有 GPU 集群资源的人。
Soup 正是为了解决这个矛盾而诞生的。它用一条 YAML 配置取代数十个命令行参数，让微调变成了 soup init --template chat && soup train 这样简单的工作流。更关键的是，它的 Layer Streaming 技术把 8B 模型在 4GB 显存的 RTX 3050 笔记本 GPU 上跑到了 119.6 token/s，峰值显存仅 3.32GB——而这一切经过了逐位（bit-exact）验证，与常规显存满载运行的结果完全一致。
2024 年，大模型微调工具呈现碎片化格局：Axolotl 擅长分布式、DeepSpeed 可做 ZeRO 优化、LLamFactory 界面友好但各有各的配置语法、同一个超参数在不同工具里叫不同名字。
个人开发者 MakazhanAlpamys 在多次被"配置地狱"折磨后，决定写一个自己的工具。项目于 2026 年 2 月开源，迅速获得关注——因为它做了一件说起来容易、做起来难的事：把微调的复杂度抽象掉，只暴露真正需要关心的参数。
Soup 的设计哲学是"配置即代码"：所有训练参数写在一个 YAML 文件里，soup train --config soup.yaml 启动。开发者不需要记住 per_device_train_batch_size、gradient_accumulation_steps、learning_rate_scheduler_type 等数十个 PyTorch/HF 训练器参数——这些由 Soup 的 autoset 机制自动计算。
Soup 支持当前主流的四种 LLM 微调范式，覆盖从基础到进阶的完整链路：
| 范式 | 命令 | 说明 |
|---|---|---|
| SFT（监督微调） | soup train --task sft --config sft.yaml | 最基础的指令微调 |
| DPO（直接偏好优化） | soup train --task dpo --config dpo.yaml | 利用成对偏好数据，绕过 PPO |
| ORPO / SimPO | soup train --task orpo/simpo | 无参考模型的偏好优化 |
| KTO | soup train --task kto | 基于 Kahneman-Tversky 优化的人类偏好对齐 |
| GRPO | soup train --task grpo | 推理任务强化学习 |
从 v0.72.4 起，DPO 族的所有算法都支持 Layer Streaming——这意味着即使在 4GB 显卡上，你也可以做完整的 RLHF 流程，而不再需要"先 SFT，再想办法云端 DPO"的分段方案。
传统 QLoRA 微调需要将整个量化基础模型常驻显存。Layer Streaming 的思路是：基础模型只加载一次到系统内存，通过 PCIe 总线按层流向 GPU，GPU 上只保留当前计算层的激活值和 adapter 权重。
# soup.yaml — 开启 Layer Streaming
training:
stream_layers: true # 基础模型流出 VRAM
quantization: 4bit # NF4 量化，~4x 存储压缩
batch_size: 4
stream_source: auto # RAM 够用用 RAM，不够自动换 NVMe
v0.72.4 实测（RTX 3050 Laptop 4GB，Llama-3.1-8B-Instruct + NF4 + LoRA）：
有一点必须诚实：Layer Streaming 在时间上并非零代价。DPO 任务中，由于参考模型需要在每步读取全部层栈，实际测得每步耗时约为常规 SFT 的 1.52 倍。项目文档对此毫不遮掩，并明确标注为 BETA 状态。
# 初始化项目，自动生成标准配置
soup init --template chat # 对话模板
soup init --template code # 代码微调
soup init --template medical # 医疗领域
soup init --template vision_llama # 多模态
Soup 在 pyproject.toml 中做了精心设计的依赖分层：
pip install soup-cli）：只含 typer、rich、pydantic、pyyaml 等轻量工具，不含 PyTorchpip install "soup-cli[train]"）：按需引入 torch、transformers、peft、trl、datasets、bitsandbytes、accelerate这种设计让普通用户不会被 5GB+ 的训练依赖"绑架"——只是想查个配置文档？装核心 CLI 就够了。
代码库中有一段罕见的长达 60 行的版本锁定注释，解释了为什么 trl 被锁定在 <0.27：不同版本的 TRL 在 max_prompt_length 参数和模块导出路径上有不兼容变更（从 0.27 的字段移除到 0.28-0.29 的模块重定位），影响 6 种偏好训练器中的 5 种。这是一个"被迫的"保守策略，也侧面说明 LLM 训练生态的碎片化问题有多严重。
src/soup_cli/
├── commands/ # CLI 命令定义（train/eval/serve/export...）
├── config/ # YAML 配置解析与校验
├── trainer/ # 训练器封装（适配多种后端）
├── data/ # 数据集加载与预处理
├── autopilot/ # 自动参数搜索
├── cloud/ # 云端部署集成
├── eval/ # 评估工具
├── recipes/ # 预置训练配方
├── ui/ # Web UI（TUI 界面）
└── mcp_server/ # MCP 协议服务端
# 推荐方式：pip（仅需训练能力）
pip install "soup-cli[train]"
# 完整包（含 FastAPI UI、评估工具等）
pip install "soup-cli[all]"
# 或 Docker 一键部署
docker compose up
# 1. 初始化项目（生成标准配置）
soup init --template chat
# 2. 编辑 soup.yaml（只需改数据路径和模型名）
# model: meta-llama/Llama-3.1-8B-Instruct
# data_path: ./my-data/
# 3. 启动训练
soup train
# 4. 导出为 Ollama 兼容格式
soup export --format ollama
全程不需要 SSH、不需要配置分布式、不需要手动计算 batch size——这些由 Soup 的 autoset 机制处理。
训练完成后，支持多种部署格式：
ollama create 部署4GB 显存"能用"不代表"好用"。实测中 batch_size 通常只能设为 1-2，长序列（2048+ tokens）训练速度会明显下降。如果你有 24GB 显存的 4090，Layer Streaming 的必要性就大幅降低——毕竟基础模型全进显存更快。
官方文档标注 Layer Streaming 功能为 BETA 状态，PPO 和 GRPO 尚未支持（因为逐 token 生成会重复读取全部层，无法通过流式传输摊销成本）。
当前版本深度绑定 HuggingFace 生态（transformers、peft、trl、huggingface-hub），切换到其他生态（如 vLLM 原生微调、TGI）需要额外工作。
Soup 的出现印证了一个趋势：LLM 微调的门槛正在从"专业团队"向"个人开发者"迁移。2025-2026年，随着量化技术成熟（NF4/NF3）、推理优化进步（Layer Streaming、Flash Attention）、开源工具链完善（Axolotl → Soup → Unsloth），"垂直领域微调一个模型"已经从"需要 8 卡 A100"变成"一台游戏本就能搞定"。
GitHub 上 211 颗星、持续活跃的 commits、不断扩大的训练范式支持，都在说明：这是一个被真实需求驱动的项目，而非 demo 产品。
报告生成时间：2026-08-05 | 项目地址：https://github.com/MakazhanAlpamys/Soup | 主页：https://trysoup.dev