Soup：把 8B 模型塞進 4 GB 顯卡的那條路，以及它還沒鋪平的地方
Fine-tune LLMs from one YAML. Layer streaming trains an 8B model on a 4 GB laptop GPU.
秒懂
- 它是什麼？
- Soup 用一份 YAML 包住 QLoRA 微調，靠 layer streaming 讓凍結的 base 不進 VRAM。本文只看它能確認的機制、指令與限制，包括 v0.74.0 修掉的 fp32 載入錯誤與那個對不上的 torch 版本下限。
- 適合誰用？
- 如果你手上只有一張消費級顯卡、想把資料集跑成一個 LoRA adapter，而且願意接受 BETA 標記與實驗性路徑，Soup 的 soup init 加 soup train 兩步流程值得在一個小模型上先試；若你要的是多節點訓練、可審計的資料管線，或不能承受設定檔語意變動的正式環境，它現階段的定位不適合。動手前先確認三件事：安裝時實際解析到的 torch 版本是否高於 2.5.1（README 明說 torch 2.5.1 配 trl 0.29 無法 import）、你的 GPU 是否落在 T4、P100、V100、GTX 16xx 這類 v0.74.0 才修好 streaming 的型號、以及是否需要把 stream_layers 打開。
- 可以商用嗎？
- 可以。Apache-2.0 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫在最近一天內有新的提交。
- 用什麼語言寫的？
- 主要是 Python（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
誰在為 GPU 記憶體打架，Soup 想接手哪一段
微調一個 8B 等級的模型，卡住多數人的不是資料，是顯卡記憶體。QLoRA 已經把權重壓到 4-bit，但凍結的 base model 仍要完整佔住 VRAM，加上梯度、優化器狀態與活化值，一張 4 GB 的筆電顯卡幾乎沒有空間。README 把痛點寫得很直白：即使是熟練團隊，也有三到五成時間花在對抗基礎設施，而不是改進模型。
Soup 的目標讀者是這群人：手上有消費級 GPU、想跑 SFT 或 DPO、不想 SSH 進一台隨時會壞的機器、也不想在 DeepSpeed 設定檔之間來回。專案以 Apache-2.0 釋出，PyPI 套件名為 soup-cli，支援 Python 3.10 到 3.12。它把訓練流程收斂成一份 YAML 加一行指令，README 的說法是「One config, one command, done」。這個承諾的範圍要看清：它處理的是單機、LoRA 系微調的設定複雜度，不是分散式訓練。
layer streaming：把凍結的 base 逐層餵給 GPU
Soup 最核心的機制是 layer streaming。作法是讓凍結的 base 權重留在 VRAM 之外，按解碼器層為單位，一次餵一層進 GPU 計算。README 給出的量測是在 RTX 3050 Laptop 4 GB 上跑 Llama-3.1-8B-Instruct 加 NF4：119.6 tok/s，峰值 3.32 GB，並稱結果與一般常駐式訓練 bit-exact 相同，另外在 H100 上獨立複現為 113.00 tok/s、同樣 3.32 GB。
這些數字的時間點必須說清楚，README 自己標註了：tok/s 是在 v0.72.2 量的，早於 v0.73.0 的修正，那次修正讓 32B 情境慢了 4.8%，而且之後沒有在 4 GB 卡上重測。所以 119.6 這個數字是歷史值，不是當前版本的效能承諾。專案也附了 notebooks/proof-4gb.ipynb，把行程上限壓在 4 GB，再斷言串流模型與一般模型 bit-identical，讓你自己驗。這個功能預設關閉，要開 stream_layers: true，而且 README 明寫仍是 BETA。
v0.74.0 修掉的那個 fp32 載入，比新功能更值得看
這個 release 的標題本身就是問題陳述：凍結的 base 一直被以 fp32 載入。README 說明，所有 SFT 載入路徑都會把凍結 base 默默升成 fp32，等於用兩倍於 checkpoint 的精度把一份永遠不會收到優化器更新的權重放進記憶體。修好之後，在 H100 上以 Llama-3.1-8B 加 LoRA 量測，峰值從 48,241 MiB 降到 18,658 MiB，2.59 倍、28.9 GB，三次重複結果一致。可訓練的 base 仍刻意以 fp32 載入。
同一版還修了四種同型的 SSRF 繞過，用縮寫、十進位、十六進位與八進位 IPv4 寫法（127.1、2130706433、0x7f000001、0177.0.0.1）觸及 telemetry 與 webhook 的防護，其中一條路徑連 OTLP tracing 的驗證器都繞過。另有兩項行為變更要注意：soup serve 綁到非 loopback 主機卻沒有 --tool-auth-token 時，從印警告改成直接 exit 2；/v1/tools/bash 在具備 OS 層隔離後重新啟用，也就是說它保護的端點現在真的會執行程式。最後，免費 Colab 與 Kaggle 層級原本完全無法串流，T4、P100、V100、GTX 16xx 會讓 layer streaming 崩潰，原因是 peft 以 checkpoint 的 dtype 建立 LoRA adapter，而 fp16 GradScaler 需要 fp32 梯度。
從安裝到跑起來：實際會敲到的指令與設定鍵
安裝指令在 README 第一段：pip install "soup-cli[train]"。它特別註明 [train] 額外依賴才是微調需要的，裸裝 soup-cli 只是輕量 CLI。接著三步是 soup init --template chat 產生起始設定，再 soup train 開始訓練。設定以 YAML 為單位，README 沒有在可見段落列出完整鍵名，只提到 stream_layers: true 這個開啟 layer streaming 的鍵，以及 soup serve 的 --tool-auth-token 參數。
雲端路徑是 soup train --cloud lambda，預設只做規劃（plan-only），終止動作放在 finally 區塊並輪詢確認真的終止。這裡有個必須先處理的依賴衝突：README 的 known limitation 明說宣告的 torch>=2.5.0 下限與 trl>=0.29 不相容，在 torch 2.5.1 上 trl 根本無法 import，全新安裝會解析到較新的 torch 而繞過，但如果你在既有環境裡升級，這個下限就是個陷阱。
BETA 標籤、複現條件與那個沒重測的數字
最明顯的限制寫在功能自己身上：layer streaming 是 opt-in 且標為 BETA，README 用「still BETA」描述它。一個能省下數 GB VRAM 的路徑被放在預設關閉的位置，代表維護者對它的信心還沒有到讓所有人預設踩上去。第二個限制是量測的時間差：119.6 tok/s 來自 v0.72.2，v0.73.0 的修正讓 32B 慢了 4.8%，而 4 GB 卡上的數字沒有重跑。任何拿這個數字做採購或容量規劃的人都應該知道它是舊的。
第三個限制是硬體覆蓋的補丁性質。T4、P100、V100、GTX 16xx 這幾類常見的免費或入門卡，是在 v0.74.0 才修好 streaming 崩潰，這說明這條路徑的硬體矩陣是被動補齊的，不是一開始就設計齊全。如果你的卡不在 README 與 release note 提過的型號裡，最務實的驗證方式就是跑 notebooks/proof-4gb.ipynb 那個斷言，而不是相信任何轉述的數字。
反過來說，什麼情況不該用 Soup？需要多節點、需要把資料前處理與訓練拆成可審計的獨立階段、或團隊已經有穩定的自建訓練框架，那 Soup 幫你省下的是設定複雜度，而你本來就沒有這個問題。
跟直接寫 PyTorch 加 PEFT 的差別在哪
最直接的替代方案是自己在 PyTorch 上接 transformers、peft、trl 三個套件寫訓練迴圈，也就是 Soup 底層用的同一組東西。差別不在能力，在控制權的位置。自己寫，你能決定每一層何時載入、梯度如何累積、checkpoint 何時落地，代價是這些決定都要你自己做，而且做錯的症狀往往不是報錯，是峰值記憶體悄悄翻倍。Soup 把這些決定收進 YAML 與自動偵測，README 列的賣點是自動批次大小、GPU 偵測與量化。
另一條路是直接用 Hugging Face 的 TRL 範例腳本。TRL 提供訓練邏輯，但不提供一層封裝去猜你的硬體。Soup 在 TRL 之上加了 CLI、設定檔與那條 layer streaming 路徑，並且在 v0.74.0 把版本對齊到 Transformers 5.x、TRL 0.29、PEFT 0.20。選擇的關鍵是：你要的是可預測的預設值，還是每一個記憶體決策都握在自己手上。前者換來速度，後者換來除錯時你知道問題在哪一層。
維護成本與授權的實際含意
授權是 Apache-2.0，寬鬆、可商用、含專利授權條款，對衍生作品沒有 copyleft 要求。這裡不涉及法律建議，只提醒一點：你的訓練資料、base model 與產出的 adapter 各自有自己的授權，Apache-2.0 只涵蓋 Soup 這個工具本身，不會改變那些條款。
升級成本方面，材料顯示這個專案的節奏很快，v0.73.2 到 v0.74.0 之間有多項行為變更，其中 soup serve 的退出碼從警告改為 exit 2 屬於破壞性變更，任何依賴它輸出格式或退出碼的腳本都要跟著改。依賴鏈也綁得緊：Transformers 5.x、TRL 0.29、PEFT 0.20 這組版本是 release note 明列的組合，而 torch 下限與 trl 的衝突說明這條鏈沒有完全對齊。v0.74.0 提到 120 個合併的 PR 中有 116 個來自維護者以外、共 25 人，這代表外部貢獻活躍，也代表變更來源分散，升級前讀 release note 的必要性比一般專案高。
編輯結論
如果你手上只有一張消費級顯卡、想把資料集跑成一個 LoRA adapter，而且願意接受 BETA 標記與實驗性路徑，Soup 的 soup init 加 soup train 兩步流程值得在一個小模型上先試；若你要的是多節點訓練、可審計的資料管線，或不能承受設定檔語意變動的正式環境，它現階段的定位不適合。動手前先確認三件事：安裝時實際解析到的 torch 版本是否高於 2.5.1（README 明說 torch 2.5.1 配 trl 0.29 無法 import）、你的 GPU 是否落在 T4、P100、V100、GTX 16xx 這類 v0.74.0 才修好 streaming 的型號、以及是否需要把 stream_layers 打開。最後這點決定了你是在跑一條已修復的預設路徑，還是一條標著 BETA 的最佳化路徑。
社群筆記