Soup：一条命令微调大模型，4GB 显卡也能跑 8B

Soup Logo

从"配置地狱"到"一行命令"：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 月开源，迅速获得关注——因为它做了一件说起来容易、做起来难的事：把微调的复杂度抽象掉，只暴露真正需要关心的参数。

核心功能：YAML 驱动的微调流水线

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"的分段方案。

Layer Streaming：显存优化的核心技术

传统 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）：

峰值显存：3.32 GB
推理速度：119.6 token/s
结果与常规显存满载运行逐位一致（bit-exact）

有一点必须诚实：Layer Streaming 在时间上并非零代价。DPO 任务中，由于参考模型需要在每步读取全部层栈，实际测得每步耗时约为常规 SFT 的 1.52 倍。项目文档对此毫不遮掩，并明确标注为 BETA 状态。

配置模板系统

# 初始化项目，自动生成标准配置
soup init --template chat        # 对话模板
soup init --template code        # 代码微调
soup init --template medical     # 医疗领域
soup init --template vision_llama # 多模态

技术架构：如何把 20+ 行代码变成 3 行

依赖分层设计

Soup 在 pyproject.toml 中做了精心设计的依赖分层：

核心 CLI（pip install soup-cli）：只含 typer、rich、pydantic、pyyaml 等轻量工具，不含 PyTorch
训练扩展（pip install "soup-cli[train]"）：按需引入 torch、transformers、peft、trl、datasets、bitsandbytes、accelerate
可选扩展：eval（lm-eval）、wandb、deepspeed、fast（unsloth）、ui/serve（FastAPI）等

这种设计让普通用户不会被 5GB+ 的训练依赖"绑架"——只是想查个配置文档？装核心 CLI 就够了。

TRL 版本锁定

代码库中有一段罕见的长达 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 机制处理。

部署与导出

训练完成后，支持多种部署格式：

GGUF：量化模型文件，可配合 llama.cpp 使用
Ollama：直接 ollama create 部署
vLLM：高吞吐量推理服务

局限与争议

消费级显卡的边界

4GB 显存"能用"不代表"好用"。实测中 batch_size 通常只能设为 1-2，长序列（2048+ tokens）训练速度会明显下降。如果你有 24GB 显存的 4090，Layer Streaming 的必要性就大幅降低——毕竟基础模型全进显存更快。

Layer Streaming 仍在 BETA

官方文档标注 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

Soup：一条命令微调大模型，4GB 显卡也能跑 8B

Soup Logo

从"配置地狱"到"一行命令"：Soup 如何让 LLM 微调变得触手可及

开篇：那个被显卡内存劝退的夜晚

然后你看了看手边的 RTX 3060，12GB 显存。

"没事，"你安慰自己，"8B 模型 QLoRA 微调肯定够了。"

三小时后，CUDA out of memory。

背景：从"工具集"到"统一工作流"

核心功能：YAML 驱动的微调流水线

支持的训练范式

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`	推理任务强化学习

Layer Streaming：显存优化的核心技术

# 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）：

峰值显存：3.32 GB
推理速度：119.6 token/s
结果与常规显存满载运行逐位一致（bit-exact）

配置模板系统

# 初始化项目，自动生成标准配置
soup init --template chat        # 对话模板
soup init --template code        # 代码微调
soup init --template medical     # 医疗领域
soup init --template vision_llama # 多模态

技术架构：如何把 20+ 行代码变成 3 行

依赖分层设计

Soup 在 pyproject.toml 中做了精心设计的依赖分层：

核心 CLI（pip install soup-cli）：只含 typer、rich、pydantic、pyyaml 等轻量工具，不含 PyTorch
训练扩展（pip install "soup-cli[train]"）：按需引入 torch、transformers、peft、trl、datasets、bitsandbytes、accelerate
可选扩展：eval（lm-eval）、wandb、deepspeed、fast（unsloth）、ui/serve（FastAPI）等

这种设计让普通用户不会被 5GB+ 的训练依赖"绑架"——只是想查个配置文档？装核心 CLI 就够了。

TRL 版本锁定

代码结构

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 机制处理。

部署与导出

训练完成后，支持多种部署格式：

GGUF：量化模型文件，可配合 llama.cpp 使用
Ollama：直接 ollama create 部署
vLLM：高吞吐量推理服务

局限与争议

消费级显卡的边界

Layer Streaming 仍在 BETA

官方文档标注 Layer Streaming 功能为 BETA 状态，PPO 和 GRPO 尚未支持（因为逐 token 生成会重复读取全部层，无法通过流式传输摊销成本）。

生态锁定风险

当前版本深度绑定 HuggingFace 生态（transformers、peft、trl、huggingface-hub），切换到其他生态（如 vLLM 原生微调、TGI）需要额外工作。

行业意义：个人微调时代的来临

GitHub 上 211 颗星、持续活跃的 commits、不断扩大的训练范式支持，都在说明：这是一个被真实需求驱动的项目，而非 demo 产品。

报告生成时间：2026-08-05 | 项目地址：https://github.com/MakazhanAlpamys/Soup | 主页：https://trysoup.dev