【2026 最新】Soup layer streaming 完整教學：4GB 顯卡如何微調 8B 模型？

Soup layer streaming 最近因一則「4GB Laptop GPU 微調 8B 模型」的 Show HN 專案受到關注。截至 2026 年 8 月 5 日，該頁顯示 126 points、24 comments；留言實際追問的不只速度，還包括資料量、自動調參、剩餘顯存與該買什麼硬體。這篇教學會從原理一路做到 YAML、硬體與資料前檢、量測、adapter 驗收，並先把最重要的界線說清楚：目前公開的 4GB／8B 數字是 Soup 維護者量測，不是我們已在同級 CUDA 顯卡完成的第三方重跑。

因此，本文的目標不是把「能啟動」包裝成「值得長期訓練」，而是讓你親手取得五張收據：peak VRAM、主機 RAM、step time、磁碟讀取與 held-out 品質。讀完後，你應該能判斷 Soup 是手上 4GB 顯卡的容量逃生門，還是一次不划算的慢速實驗。

先說結論：Soup 能把門打開，但沒有創造免費顯存

• 它做得到的事：不讓完整 frozen decoder stack 同時常駐 VRAM，而是把底模留在主機端，一層一層搬進固定的 GPU buffer；LoRA 與 gradients 常駐顯卡，optimizer state 則要納入 VRAM 預算，paged optimizer 在壓力下可能換頁到 CPU。
• 它交換掉的東西：主要是 host RAM 容量、PCIe／H2D 頻寬與訓練時間；RAM 不夠時才可能改走 NVMe overflow。Soup 官方也明說，模型若能以一般 resident QLoRA 放進顯卡，就不要開 streaming。
• 它沒有保證的事：任何 4GB 顯卡都能穩定跑任意 8B、adapter 一定有用、或 Soup 比 Unsloth 更快。這三件事都需要同硬體、同模型、同資料與同設定的實測。
• 本文可獨立確認的範圍：我們用 PyPI 的 soup-cli 0.72.4 重現了版本、資料 fixture、inspect／doctor 與 YAML schema；本機是 Apple M4、沒有 NVIDIA CUDA，所以沒有把維護者的 3.32GB 與 119.6 tok/s 當成自己的成績。

Soup layer streaming 一句話怎麼記？

Soup layer streaming ＝ frozen base 住 RAM／NVMe ＋ 當前一層輪流進 VRAM ＋ LoRA 常駐顯卡。

把 8B 模型想成一棟塞不進工作間的大書櫃。一般 QLoRA 是把整座「4-bit 書櫃」放在 GPU，再於抽屜旁掛上可訓練的 LoRA；Soup 則把書櫃留在主機 RAM，工作間只保留當前抽屜、下一個空 buffer，以及不能搬走的 embeddings、lm_head、activation 與 LoRA。它省的是「所有 decoder layer 同時在場」的空間，不是讓模型重量消失。

為什麼一般 QLoRA 在 4GB 還是可能放不下 8B？

QLoRA 論文的核心，是把 frozen base 以 4-bit NormalFloat（NF4）儲存，再透過 LoRA 訓練少量低秩參數；計算與梯度並不是整套都變成 4-bit。這已經大幅降低重量佔用，但 VRAM 還要容納量化 metadata、embedding／輸出 head、activation、logits、LoRA、gradient、optimizer state 的預算／換頁、CUDA context 與 allocator reserve。4GB 不是「8B × 4 bit」算完就剛好。

Soup 的額外一步，是連這份 NF4 decoder store 也不讓它完整 resident。官方 8B 案例裡，untied embedding 與 lm_head 本身就約佔 2.10GB，提醒我們不能把需求簡化成「VRAM 只放一層」。比較準確的心智模型是：

Streaming peak ≈ resident embeddings／head ＋ 兩組 layer buffers ＋ activations／logits ＋ LoRA／gradient ＋ optimizer 預算／換頁 ＋ CUDA 開銷。

如果你想先補齊微調與推論的基本差異，可先讀 AlphaLab 的模型如何學習與LLM 推論引擎；前者解釋 gradient 在改什麼，後者則能幫你分清訓練記憶體與推論 KV cache 不是同一件事。

Soup layer streaming 的四段資料路徑

1. NF4：壓的是 frozen weight 儲存，不是所有運算

設定 quantization: 4bit 時，Soup 會把 decoder 內可量化的 Linear weights 離線量成 NF4 shard 並依 fingerprint 快取；layer norm 與 resident extras／untied head 仍保留較高精度。之後會重用快取，而不是每個 step 重新量化。Hugging Face bitsandbytes 文件也把 NF4 定位為訓練 4-bit base 的資料型態。真正被更新的是 LoRA A／B matrix，計算會使用較高精度。

2. Pinned memory：讓搬運有機會和計算重疊

RAM store 若能 page-lock，CUDA 就能在專用 stream 上做非同步 host-to-device copy。兩組固定 buffer 交替工作：GPU 計算第 i 層時，另一組預載第 i＋1 層。PyTorch 官方教學指出，傳輸與運算要真正重疊，需有可用 DMA engine、在獨立的非預設 CUDA stream 做 copy，且來源位於 pinned memory；Soup 在這組條件下使用 non-blocking copy。若 page-lock 失敗，Soup 會退回 pageable RAM；它仍可能繼續跑，但 overlap 變差，而且 pinned RAM 用太多也會壓迫其他程式。

3. Forward＋backward：每層每個 micro-batch 會讀兩次

每個 micro-batch 的 forward 走過一次所有 layer；backward 重新計算時，又需要同一層權重。即使 frozen W 不存自己的 gradient，dL/dx = Wᵀ · dL/dy 仍要用 W，才能把梯度傳回更前面的 LoRA。這就是時間代價的物理來源，不是把 frozen model 設成 requires_grad=False 就能省掉。本文 accumulation 為 4，因此一個 optimizer step 會處理 4 個 micro-batches、每層共讀 8 次；同時也處理 4 倍 token，不能只用讀取次數判定每 token 變慢多少。

4. RAM-first、NVMe fallback：官方 4GB 案例不是每步從 SSD 串流

stream_source: auto 會在主機 RAM 能容納時選 RAM，否則才嘗試 NVMe disk tier。官方設計只接受 NVMe；但 0.72.4 的媒體偵測在混合磁碟或強制 disk 的情境未必能替你守住正確 volume，因此仍要自行確認 shard cache 所在磁碟真的是 NVMe。維護者的 4GB／8B 案例使用約 3.60GB pinned RAM store，NVMe 上的是 shard cache，不是每個 step 的主要 weight path。官方目前只聲稱 disk tier 的 correctness 已檢查，沒有公布 RAM 對 NVMe 的速度差；memory map 又會受 OS page cache 影響，所以不能把「SSD 速度」當成一個乾淨數字。

實作前提：先鎖版本，再檢查 CUDA、RAM、磁碟

以下流程使用 Python 3.10 以上，並鎖定 soup-cli 0.72.4。Soup 更新很快，主分支與已發布 wheel 可能在同一天出現差異；教學若不鎖版本，今天能 parse 的 YAML 明天可能不是同一條路徑。這個 4GB 實作也鎖定 NVIDIA CUDA；Apple Silicon 的 MLX 是另一個 backend，而 streaming 明確要求 backend: transformers，不能直接把本篇設定搬過去。

後文的多行指令以 Bash 續行符號 \ 示範；PowerShell 請貼成單行，或把行尾反斜線改成反引號。

python -m venv .venv

# Linux / macOS
source .venv/bin/activate

# Windows PowerShell 改用：
# .\.venv\Scripts\Activate.ps1

python -m pip install -U pip
# 先到 PyTorch 官方 selector 安裝與驅動、CUDA 相符的 torch
python -m pip install "soup-cli[train]==0.72.4"

soup version --json
hf auth login

Llama 3.1 是 gated model，必須先在 Hugging Face 模型頁接受條款，再登入有權限的帳號。PyTorch wheel 則應依作業系統與 CUDA 版本，從官方安裝選擇器取得；若這一步裝到 CPU build，後面所有 4GB 討論都失去意義。

python -c "import torch; print(torch.__version__, torch.version.cuda, torch.cuda.is_available()); print(torch.cuda.get_device_name(0) if torch.cuda.is_available() else 'NO CUDA')"
soup doctor --disk

這兩行先回答 CUDA 是否為 True、顯卡名稱是否正確；soup doctor --disk 另顯示總 RAM，以及目前工作目錄所在磁碟的類型與 free disk。它不會告訴你當下 available RAM，工作目錄也未必等於 shard cache 所在 volume。Soup 沒有公開的 soup hardware-fit 指令；真正的 soup train setup 才會讀取當下 available RAM／VRAM，並執行 batch／sequence／vocab-aware streaming preflight。

也不要硬背「一定要 16GB RAM」。維護者機器是 16.9GB 總 RAM，NF4 decoder store 約 3.60GB，但 Soup 會依當下可用 RAM 做保守選擇，page-lock 上限又是另一件事。以 Llama 3.1 8B 原始 checkpoint、NF4 cache、虛擬環境與輸出合計，先預留約 25～30GB free disk 是實務工作估算，不是 Soup 的硬規格。

步驟一：用小型 Alpaca dataset 做 smoke test

Soup 內建一份極小的 Alpaca fixture，適合測格式、tokenizer 與資料路徑，不適合拿來判斷 adapter 品質。先複製它，再跑三層檢查：

soup data demo alpaca_demo --output ./alpaca.jsonl
soup data inspect ./alpaca.jsonl --rows 3
soup data validate ./alpaca.jsonl --format alpaca
soup data doctor ./alpaca.jsonl \
  --model meta-llama/Llama-3.1-8B-Instruct \
  --format alpaca \
  --max-length 512 \
  --show-mask 3

inspect 看欄位、空值、重複與長度；validate 確認 Alpaca schema；data doctor 才把 tokenizer、chat template、loss mask 與 truncation 放在一起看。你自己的資料每列至少應像這樣：

{"instruction":"用一句話解釋 layer streaming","input":"","output":"它逐層搬運 frozen base，以主機頻寬與時間交換 VRAM。"}

正式訓練前，把驗收題另外存成 eval/tasks.jsonl，不要讓它進 train。val_split 也不是神奇的公平切分：Soup 當前採位置切分，因此應先打亂資料，或直接準備一份目的明確的 held-out set。想把整套流程做成可回放的資料與評估管線，可以延伸到AI Agent Harness 是什麼與如何打造 Agent Harness；核心觀念一樣是把輸入、執行與驗收拆開。

步驟二：用一份 YAML 啟動 streamed QLoRA

把以下內容存成 soup.yaml。這是一份保守的教學起跑設定，不是維護者 benchmark 的逐項重現，也不是最終品質配方：

base: meta-llama/Llama-3.1-8B-Instruct
task: sft
backend: transformers

data:
  train: ./alpaca.jsonl
  format: alpaca
  max_length: 512
  val_split: 0.1

training:
  epochs: 1
  lr: 2.0e-4
  batch_size: 1
  gradient_accumulation_steps: 4
  quantization: 4bit
  optimizer: paged_adamw_8bit
  gradient_checkpointing: true
  stream_layers: true
  stream_source: auto
  stream_buffers: 2
  logging_steps: 1
  lora:
    r: 16
    alpha: 16
    dropout: 0
    target_modules: [q_proj, v_proj]

output: ./output/soup-8b-lora

• batch_size: 1：streaming 模式明確拒絕 auto，因為 auto 原本要 OOM-probe 一個不存在的 resident model。Soup 不會偷偷替你縮 batch 或 context。
• gradient_accumulation_steps: 4：在不增加單次 micro-batch VRAM 的情況下取得較大 effective batch，但底模也會多讀幾輪。若你要對照維護者的吞吐 protocol，必須改回 1；兩組速度不能混寫。
• quantization: 4bit：讓 streamed base 內可量化的 Linear weights 走 NF4；若是 none，就是 streamed LoRA 而不是 streamed QLoRA。
• gradient_checkpointing: true：可保留作為 config 意圖；streaming wrapper 本身已固定逐層 checkpoint，並停用 HF Trainer 的第二層 checkpoint，避免重複重算，所以這個 key 不會再疊出額外節省。
• stream_source: auto：RAM 能放就 RAM，不夠才嘗試 NVMe。若你要乾淨測 RAM 與 disk，請分成兩個固定 source 的 run。
• stream_buffers: 2：double buffering；不要直覺改成 1，因為一組 buffer 無法同時載入下一層與計算當前層。
• q_proj、v_proj、r: 16：靠近維護者 8B 案例的窄 LoRA 範圍，優點是省記憶體；代價是容量可能比 all-linear adapter 小。不同 target／rank 的品質與速度不可直接排名。

這份 YAML 已以 0.72.4 schema parse；真正資料要自行決定 epoch、learning rate、dropout 與 effective batch。小 fixture 跑通只代表 plumbing 正常，不代表你應該把相同參數用在數十萬筆資料。

步驟三：dry-run 之後，真正 preflight 在 train setup

soup train --config soup.yaml --dry-run
soup train --config soup.yaml

--dry-run 會驗證 config 與資料，但不會證明 CUDA 可用、RAM 能 page-lock、NF4 shard 能建立，或實際 4GB VRAM 能撐過 optimizer step。Soup 只有在真正 train 中解析模型、建立 shard、讀取當下 free RAM／VRAM 後，才會做 streaming-specific 預估並在超額時拒絕。這個區別很重要：dry-run pass ≠ hardware-fit pass。

第一次執行還包含下載與一次性 NF4 cache 建置，不能拿它和 warm-cache step time 混在一起。預設 cache 位於 ~/.soup/layer-stream/；0.72.4 只有在環境變數解析後的路徑位於 $HOME、目前工作目錄或 $TMPDIR 之下時，才接受 SOUP_LAYER_STREAM_CACHE_DIR，否則會回退預設位置。若要改用另一顆 NVMe，可把專案工作目錄放到該 volume，並核對 log 的 Preparing layer shards -> ... 實際路徑。先讓 real preflight 通過，再觀察至少一個完整 optimizer step，才有資格說「這個 config 能跑」。

維護者的 4GB／8B 成績，究竟證明了什麼？

Soup repository 的 v0.72.2 benchmark ledger（0.72.4 仍收錄）記錄：RTX 3050 Laptop 4GB、Windows 11、Llama 3.1 8B Instruct、NF4、LoRA r16 且只套 q／v、sequence 512、batch 1、PagedAdamW8bit、10 steps warm-up 後量 50 steps。在該次維護者測試中，torch.cuda.max_memory_allocated() 為 3.32GB、throughput 為 119.6 tok/s、pinned store 約 3.60GB。

這組數字的正確讀法有四個限制：

1. n=1，沒有誤差範圍：50 個 measured steps 不能代表不同 RTX 3050 功耗、散熱、driver 與 Windows session。
2. 3.32GB 不是整張卡總佔用：它是 PyTorch allocator 可見的 tensor allocation peak；CUDA context、driver、display reserve 要另外看 NVML／nvidia-smi。
3. 119.6 tok/s 包含 padding：不能直接拿來估計你自己的有效 token 速度；不同 sequence length、資料長度與 accumulation 都會改變結果。
4. 沒有 8B held-out 品質驗收：較小 fixture 的 bit-exact 測試不能推導「這個 8B adapter 已有用」。4GB 卡也無法在相同條件建立 resident 8B 對照。

所以它證明的是：維護者在一組明確且窄的設定下完成了 streamed training steps。它還沒有證明「所有 4GB 都行」、一般化速度或 adapter 品質。這也是為什麼精確數字不放進本文標題與結論。

步驟四：收齊五張收據，分開判斷「能跑」與「值得跑」

收據一：VRAM 要同時看 allocator 與整卡

nvidia-smi --query-gpu=timestamp,memory.used,utilization.gpu,clocks.sm,temperature.gpu --format=csv -l 1

nvidia-smi 每秒取樣適合抓整卡記憶體、utilization、clock 與溫度，但可能漏掉短暫 spike；Soup 畫面上的 allocated memory 又不含所有 driver 開銷。若你要宣稱精確 peak，應在同一 Python process 量 torch.cuda.max_memory_allocated() 與 max_memory_reserved()，再和 NVML total usage 並列，不能只挑最好看的那一欄。

收據二：RAM 要分 store size、process RSS、是否 pinned

Soup 印出的 store size 不是全系統或全 process peak。Windows 可用 Task Manager／Process Explorer，Linux 可用 /usr/bin/time -v 另記 maximum resident set size；log 同時保留「PINNED RAM」或「PAGEABLE fallback」。如果訓練把系統逼到 swap，VRAM 沒爆也不代表配置健康。

收據三：速度要跳過建 cache 與 warm-up

固定 model、commit／wheel、dataset hash、batch、accumulation、max length、LoRA target、rank、driver 與 power mode。至少跑三次，跳過 cache 建置與 warm-up，報 step time 的 mean／standard deviation；若報 tokens/s，應另外算 non-padding tokens。soup runs show <run-id> 可取 duration、steps 與 loss，但不是維護者的精確 10＋50 benchmark harness。

收據四：磁碟要區分 cache build 與每 step physical read

RAM tier 的 NVMe cache 檔存在，不代表訓練正在從 SSD 串流。若測 stream_source: disk，要分開記 cold／warm page cache、process physical reads 與 step time；否則你量到的可能只是 OS cache，而不是裝置吞吐。Soup 尚未提供可直接引用的 RAM-vs-NVMe slowdown。

收據五：adapter 要離開訓練程序重新載入

python -c "from pathlib import Path; from safetensors.torch import load_file; d=Path('output/soup-8b-lora'); p=d/'adapter_model.safetensors'; assert (d/'adapter_config.json').is_file() and p.is_file(); k=list(load_file(str(p))); print('tensor_count=',len(k)); print('bad_inner_keys=',[x for x in k if '.inner.' in x][:3])"

tensor_count 必須大於 0，bad_inner_keys 應為空。Soup 0.72.0 曾把 adapter key 多存一段 .inner.，loader 可能只回到未微調 base；0.72.1 已修正，因此本文鎖 0.72.4。接著在新程序、未參與訓練的題目比較 base 與 tuned：

# eval/tasks.jsonl 每列例如：
{"prompt":"用一句話解釋 layer streaming","expected":"逐層","scoring":"contains"}

# 請在能容納兩份非 streaming 模型的較大 GPU 執行；CPU 改成 cpu 且需足夠 RAM
soup ship \
  --base meta-llama/Llama-3.1-8B-Instruct \
  --adapter ./output/soup-8b-lora \
  --task-eval ./eval/tasks.jsonl \
  --device cuda

這裡有個很容易踩的坑：當前 soup chat 不會沿用訓練的 layer streamer，而會載入一份一般完整 base；live soup ship 更會分別建立 base 與 tuned generator，等於兩份非 streaming model instance。因此「4GB 能訓練」不等於「同一張 4GB 卡也能直接驗收」。你可以改在能容納兩份模型的較大 GPU、RAM 足夠的 CPU，或用另一套 sequential／4-bit evaluator 驗證。training loss 下降只能證明 optimizer 有動，不能代替 held-out task win 與 general regression gate。

Soup vs 一般 QLoRA vs Unsloth：怎麼選？

選 Soup layer streaming，如果模型就是 resident 放不下

你的條件是「已經有 4GB NVIDIA laptop GPU、想做小資料實驗、可接受 beta 與較長時間」，Soup 才有清楚價值。它是 capacity path，不是免費加速器。真正及格線是 real preflight 過關、一個 optimizer step 不 OOM、主機沒有 swap thrash、step time 可接受，而且 adapter 在另一個 eval 環境贏過 base。

選一般 QLoRA，如果 4-bit base 與訓練狀態能 resident fit

Resident QLoRA 不必每個 step 反覆 H2D 搬所有 layer，路徑更成熟、比較容易 profile 與評估。只要模型、context 與 LoRA 設定能放進顯卡，Soup 官方建議就是關掉 streaming。這通常也是「值得跑」比「勉強能跑」更重要的分界。

選 Unsloth，如果 resident fit，而且目標是加速與省 resident 記憶體

Unsloth主要優化 resident fine-tuning；Soup streaming 則接管 model-load path，所以目前 backend: unsloth 與 stream_layers: true 會在 config 階段被拒絕。兩者不是可疊加的開關；Soup 公開 ledger 的 apples-to-apples resident 對照只量到 0.5B，本文也沒有同卡同設定結果，因此不做 Soup／Unsloth 的速度或品質排名。

決策樹：8B resident QLoRA 放得下 → 先跑一般 QLoRA／Unsloth；放不下，但你已有 4GB 卡且願意接受 beta → 試 Soup；準備為這件事買新 GPU → 優先買更多 VRAM，而不是把 4GB 當目標規格。

如果你喜歡把工具放進完整工作流，而不是只看 demo，可再看Hermes Agent 教學與如何節省 Claude tokens：兩篇背後共同的工程原則，都是把「省資源」視為可量測的 trade-off，而不是行銷形容詞。

常見失敗與修正順序

1. 401／403 下載失敗：先確認 Llama 授權已接受、hf auth login 登入的是同一帳號。
2. torch.cuda.is_available() 是 False：回到 PyTorch 官方 selector，安裝與 driver／CUDA 相符的 wheel；不要繼續調 Soup YAML。
3. batch_size: auto 被拒絕：這是 streaming 的設計，不是 bug。從 1 開始，讓 real preflight 決定是否能提高。
4. RAM pinning fallback：關閉吃 RAM 的程式、降低同時工作量；若仍是 pageable，實測 step time 再決定是否繼續。
5. stream_source: auto 改走 disk：先確認是 NVMe、空間足夠，再分開量 cold／warm；不要套用 RAM benchmark。
6. adapter 能存但輸出沒變：檢查 tensor count、.inner. key、版本、重新載入 log 與 held-out 差異。
7. 想直接換成 Unsloth backend：目前不相容；若你已能 resident fit，就另開一份非 streaming config 做公平 A/B。
8. 想把 context 從 512 拉長：activation 與 logits 會增加，必須重新跑 real preflight，不能假設 decoder streaming 會吸收所有成長。

Soup layer streaming FAQ

1. Soup 真的能讓任何 4GB 顯卡微調任何 8B 模型嗎？

不能這樣保證。目前是維護者在特定 RTX 3050 Laptop、Llama 3.1 8B、512 context 與窄 LoRA 設定下的 beta 成功案例。架構、vocab、untied head、CUDA reserve 與散熱都會改變結果。

2. 一定要 16GB 系統 RAM 嗎？

沒有可通用的固定數字。Soup 真正做 streaming plan 時看的是當下 available RAM、stream store、resident extras 與 pinning 能力；RAM 不足時 auto 才可能選 NVMe。用 soup doctor --disk 盤點總 RAM 與工作目錄磁碟，再讓 real train setup 判斷。

3. 沒有 SSD 就完全不能用嗎？

RAM 放得下 streamed store 時，不需要每 step 從 SSD 讀。一般磁碟仍需存 checkpoint 與 shard cache；只有 RAM 不足且選 disk tier 時，NVMe 才進主要 streaming path。官方設計是 NVMe-only，但仍應自行確認實際 cache volume，不要只相信 0.72.4 的自動偵測。

4. Base 都 frozen 了，為什麼 backward 還要再讀一次？

因為 frozen 不等於 detach。W 不需要自己的 gradient，但反向傳播仍要用 Wᵀ 計算輸入梯度，才能把訊號送到更前面的 LoRA。Checkpoint recomputation 因而再載入每層。

5. Soup 會自動幫我調 batch size 與 context length 嗎？

不會。Streaming 拒絕 batch_size: auto，preflight 會預估並拒絕不安全 config，而不是替你改小。可自動選的是 RAM／NVMe source，以及 pinning 失敗後的 fallback。

6. Soup streaming 可以和 Unsloth 一起開嗎？

目前不行。兩者都要掌控 model-load path，Soup 0.72.4 會拒絕這個組合。若模型能 resident fit，改做一份不開 streaming 的 Unsloth config。

7. 同一張 4GB 卡能訓練，就一定能 chat 與 ship eval 嗎？

不一定。當前 soup chat 載入一份完整 base，live soup ship 會建立 base 與 tuned 兩個非 streaming generator；驗收可能要換能容納兩份模型的較大 GPU、RAM 足夠的 CPU，或另一套 sequential／量化 evaluator。

8. 怎麼證明 adapter 不是空殼？

至少做三關：確認 adapter 檔案含有 tensor 且沒有 .inner. 錯誤 key；在新程序成功載入；用完全未訓練的 held-out tasks 比較 tuned 與 base，同時檢查一般能力沒有超過可接受的 regression。前兩關只驗結構，不能單獨證明模型真的學會任務。

給新手的五個重點

1. Soup 省掉的是完整 decoder stack 同時常駐 VRAM，不是所有 model memory。
2. NF4 壓縮 frozen base；LoRA、gradient 與計算不等於全部 4-bit。
3. doctor 與 dry-run 都不是 streaming hardware-fit；要看到 real train preflight 與 optimizer step。
4. 維護者 3.32GB／119.6 tok/s 是一組可追查的 beta 記錄，不是第三方通用 benchmark。
5. 「能跑」看容量收據；「值得跑」還要看時間、主機壓力與 held-out adapter 品質。

延伸閱讀與下一步

如果你剛開始建立 AI 工程地圖，可從 AlphaLab 的AI 專區與完整課程繼續；實作前則建議把Soup layer streaming 官方文件和本文 YAML 並排，確認版本仍是 0.72.4 或先重做 schema 驗證。

最好的下一步不是直接丟一整晚訓練，而是用小資料完成一次 cache build、一個 optimizer step、adapter 重新載入，再把五張收據填完。記住開頭那句：frozen base 住主機、當前一層輪流進 VRAM、LoRA 留在顯卡。只要你願意用 host bandwidth 與時間換容量，Soup 就可能讓既有 4GB 筆電顯卡跨過「完全不能啟動」的門；是否值得走下去，則由你的量測與 held-out 結果決定。