Soup Enables Fine‑Tuning an 8B Model on a 4 GB Laptop GPU via Layer Streaming

總覽

Soup 將 LLM 微調轉化為簡單的工作流程：一個 YAML 配置、一個指令，且無需 SSH 或基礎設施麻煩。該項目針對 modeste 硬體進行訓練，具體而言，使 8B 模型能在僅具 4 GB VRAM 的筆電 GPU 上運行。

運作方式

Layer streaming 會將凍結的基礎模型保模型之外，並以每次一個解碼器層的方式送入 GPU。在 LoRA 期間，基礎為唯讀，因此可以駐留在主機 RAM 中，並透過專用 CUDA 流將其預先載入一層的小型預分配 VRAM 緩衝區流入。這使得峰值 VRAM 使用量降低至大約單層的大小，而非整個模型。

量化被應用於基礎（預設 4‑bit NF4），以進一步縮小其記憶體佔用。適配器（LoRA）在 VRAM 中正常訓練。

針對基於偏好的損失函數（如 DPO），參考模型不是第二份複製；Soup 重複使用同一個已串流的基礎，並將其適配器關閉，因此只串流一組權重。這使得參考在記憶體中「免費」，但會產生時間成本：DPO 每步讀取層疊的頻率約為標準監督微調的 1.52 倍。

系統保證與非串流駐留運行的位元精確性：在多種架構與精度下，最大絕對 logit 差異為 0.0，並經 CI 測試驗證。

主要功能

• 零 SSH： 無需登入遠端 GPU 機器。
• 單一配置： 單一的 soup.yaml 檔案控制訓練的所有方面。
• 自動處理： 批次大小、GPU 偵測與量化皆自動管理。
• 本地執行： 訓練在使用者自己的 GPU 上以 QLoRA 進行；無需雲端。
• 偏好損失支援： v0.72.4 新增 DPO、ORPO、SimPO 與 KTO 在 layer streaming 上的支援，參考模型的處理方式如上所述。
• 正確性導向： 項目著重於位元精確的可重現性，而非原始速度。

最近更新（v0.72.4）

• Layer streaming 現在適用於 DPO、ORPO、SimPO 和 KTO，而不僅限於監督微調。
• 在 RTX 3050 Laptop（4 GB，Windows）上測量：串流 DPO 的峰值 VRAM 使用量為監督微調峰值的 0.914×。
• 強制使用第二份完整模型作為 DPO 的參考將增加約 730 MB，基本上相當於額外的一份權重複製。
• ORPO 和 SimPO 真正為無參考；KTO 重複使用與 DPO 相同的參考機制。
• VRAM 預檢會將成對損失（chosen + rejected）視為行數的兩倍。
• grpo 和 ppo 仍被排除，因為其生成步驟會每個 token 重新讀取每一層，這無法透過串流攤銷。
• 此版本仍標記為 BETA。

使用指南

安裝

# 輕量核心（CLI、配置、資料工具）
pip install soup-cli
# 添加訓練依賴（torch、transformers、peft、trl、datasets、…）
pip install "soup-cli[train]"

建立配置

# 互動式精靈
soup init
# 或從範本開始（例如 chat）
soup init --template chat

一個典型的 soup.yaml 用於 8B 模型可能如下所示：

base: meta-llama/Llama-3.1-8B-Instruct
task: sft
data:
  train: ./data/train.jsonl
  format: alpaca
  val_split: 0.1
training:
  epochs: 3
  lr: 2e-5
  batch_size: auto
  lora:
    r: 64
    alpha: 16
  quantization: 4bit
  stream_layers: true
  stream_source: auto
output: ./output

訓練、測試與發布

soup train --config soup.yaml          # LoRA、量化、批次處理自動完成
soup chat  --model ./output            # 與您的模型對話
soup push  --model ./output --repo you/my-model

其他指令包括 soup merge、soup export（導出至 GGUF、ONNX、TensorRT 等）、soup eval benchmark、soup data inspect、soup recipes list、soup autopilot 和 soup doctor 進行環境檢查。

效能測量（作者報告）

• 在 RTX 3050 Laptop（4 GB，Windows）上：Llama‑3.1‑8B 在 NF4 與 layer streaming 下達到 119.6 tok/s，峰值 VRAM 使用量為 3.32 GB，且 100 % SM 佔用率。
• 同一張卡運行 Qwen2.5‑3B 時，未量化的 bf16 基礎在 2.15 GB VRAM 下達到 143 tok/s，若基礎常駐則會導致 CUDA‑OOM。
• 串流相對於常駐基線的開銷（在 0.5 B 模型規模下測量）為 1.43×；作者提供該基線以供驗證。
• 這些數據為 Windows 特定；Linux 可能會略好一些。
• 所有測量紀錄（包括被捨棄的運行）均可在儲存庫的 benchmarks/ 目錄中找到。

社群見解

• 本地模型 ROI： 評論者指出，小型開放權重模型可避免大型託管模型的成本，並解決許多企業在 LLM 上看到的 ROI 危機。
• 實際應用： 一位使用者在社區銀行使用微調後的 4B 模型進行 AML 合規，引用相同的 ROI 原則。
• VRAM 問題： 有評論詢問為何仍存在硬性 VRAM 需求；作者解釋說，凍結基礎必須被串流，因為它仍需在每次矩陣乘法前到達，而串流將需求降至單層。
• 超參數調整： 另一則評論詢問 Soup 如何自動調整超參數並進行複雜訓練決策。來源未描述自動超參數搜尋；CLI 自動處理批次大小、GPU 偵測與量化，而學習率、LoRA 階等則設定於配置檔案中。
• 資料量： 有關微調所需資料量的問題被提出。儲存庫僅提供短範例資料集；來源中未給出所需資料量的具體指導。
• 硬體建議： 有請求針對具體 4 GB GPU 筆電的推薦；來源未背書任何特定型號。
• 網站成本與可讀性： 一位使用者質疑「免費開始」標籤是否會改變，並評論站點的灰色對黑色可讀性。該項目採用 Apache‑2.0 授權並保持免費。
• 評論品質： 一位觀察者指出，該執行緒中近半數評論無效或似乎為 LLM 生成，指出低訊號評論相對於貼文分數的比例較高。

限制與常見問題

• VRAM 上限： 作者不聲稱支援在 4 GB 卡上運行超過 8B 的模型；14B NF4 需要約 7.~7.5 GB 的頁鎖定址，超過測試筆電上測得的約 7.12 GB 上限。
• 偏好損失開銷： 雖然參考模型在記憶體中是「免費」的，但 DPO 會導致每步讀取層疊的次數增加 1.52×。
• 被排除的演算法： GRPO 和 PPO 故意被排除，因為其每個 token 的生成會重新讀取每一層，這會抵消串流的好處。
• 自動超參數調整： 來源未提供學習率、LoRA 階或其他超參數自動調整的自動調整細節；這些必須在 soup.yaml 中指定。
• 資料量指引： 沒有普遍規則** 來決定所需的微調資料集大小；使用者必須自行實驗。

結論

Soup 證明，透過 layer streaming 與 4‑bit 量化，8B 8B 參數 LLM 可以在僅具 4 GB VRAM 的消費者筆電 GPU 上進行微調微調方法能在僅具 4 GB VRAM 的消費者筆電 GPU 上微調 8B 參數 LLM。該方法保持數值精確性（與常駐訓練的位元精確匹配），同時將基礎設施需求降至最低——無需 SSH、單一配置檔案，以及自動處理批次大小與量化。該項目仍為開源（Apache‑2.0），並鼓勵社群貢獻，特別是針對單一 4 GB 筆電無法提供的硬體密集驗證。

Now we need to ensure we didn't translate anything inside code blocks. We kept code blocks as is. Also we must not translate inline code like `soup.yaml`, `soup init`, etc. We kept them unchanged. Also we must not translate URLs, package names, repository names, GitHub usernames. There's none. Also we must not translate things like