Soup: 透過層流技術 (Layer Streaming) 在 4 GB 筆記型電腦 GPU 上微調 8B LLM

Soup 讓 8B 模型能在消費級筆記型電腦 GPU 上進行微調

Soup 是一個技術框架與 CLI，旨在消除 LLM 微調的基礎設施開銷。其主要的突破在於層流技術 (layer streaming)，這讓使用者能在僅有 4 GB VRAM 的 GPU 上微調 8B 參數模型。透過將凍結的基礎模型視為唯讀串流而非常駐於 VRAM 的物件，Soup 將峰值記憶體需求從整個模型的容量降低到單個解碼器層 (decoder layer) 的大小。

層流技術：技術實作與記憶體效率

層流技術透過將凍結的基礎模型移出 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) 錯誤。

正確性與位元精確度 (Bit-Exactness)

由於串流可能會因為在損失函數下降時切斷 autograd 路徑而導致無聲失敗，Soup 實作了嚴格的正確性協定。每一次發布的版本都會針對非串流的常駐執行進行位元精確 (bit-exact) 驗證，在九種架構家族中維持最高絕對對數機率 (logit) 差異為 0.0。

對偏好優化 (DPO, ORPO, SimPO, KTO) 的支援

在 0.72.4 版本中，Soup 將層流技術擴展到支援除了監督式微調 (SFT) 之外的偏好損失函數。

無記憶體消耗的參考模型

直接偏好優化 (DPO) 通常需要一個參考模型來與微調後的模型進行比較，這通常會使 VRAM 需求翻倍。Soup 透過使用相同的串流基礎模型（並關閉其 adapter）作為參考模型來優化此點。

在 RTX 3050 4 GB 上，串流 DPO 的峰值記憶體僅為 SFT 峰值的 0.914×。相比之下，若強制將第二個實體模型放入 VRAM，則會增加 730 MB 的開銷。

計算權衡 (Computational Trade-offs)

雖然節省了記憶體，但卻有時間成本。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) 的接受率，並將目標模型蒸餾成稠密草稿模型 (dense draft models)。
soup export: 支援多種格式，包括用於 Ollama 和 llama.cpp 的 GGUF，以及 ONNX 和 TensorRT。

社群對本地 LLM 投資報酬率 (ROI) 的見解

圍繞該專案的討論凸顯了向用於商業應用的微型、開源權重本地模型轉向的趨勢。社群成員指出，雖然大型託管模型佔據了頭條新聞，但許多企業應用場景（例如：社區銀行用於 AML 合規性）並不需要那種程度的算力，且可以透過微調的小型模型更具成本效益地解決，這可能解決目前 LLM 基礎 AI 實作中所面臨的「ROI 危機」。