【2026 最新】Berth 教學：一張 GPU 怎麼輪流跑 LLM 與 ComfyUI？五步完成排隊與顯存驗收

你可能已經讓本機語言模型回答問題，也用 ComfyUI 生成過圖片；兩邊單獨都跑得動，一起啟動卻突然爆顯存。這篇 Berth 教學要解決的，是同一張 GPU 上的引擎交接：誰先用、何時退場，以及如何確認下一位真的有空間。

把顯存想成一張工作桌：文字模型和圖片模型各有一套工具，桌子放不下兩套，就應先收好一套再搬另一套。本文寫給第一次接觸資源調度的讀者，先用白話理解，再提供 Linux＋單張 NVIDIA GPU 的操作路線。你需要已能獨立運作的 llama-server、ComfyUI 和模型；這裡不另教驅動或模型安裝。

主流程依 Berth 的 v0.3.6 穩定發布標籤與對應原始碼整理。本文未在 NVIDIA 主機執行交接測試，因此下方是可自行操作的驗收方法，不是 AlphaLab 的速度成績或實測紀錄。

先說結論：單卡交接＝排隊＋收工＋確認釋放＋再載入

Berth 是顯存的交通管理員。它把引擎的啟動放到租約之後；租約就是「現在輪到你使用」的許可。這個流程改善先後順序，並不把一張卡變成更大的卡。若某個模型連單獨執行都放不下，仍要調整模型、上下文或引擎設定。容量問題可先看 本機 LLM 顯存指南。

依 固定版本的租約說明，未指定 --needs-mib 的工作採整卡租約；本文沿用這個簡單路線。先不要嘗試估一個很小的數字，讓兩套引擎勉強同住。成功條件是：舊工作完整結束、舊程序釋放顯存、新工作取得許可並產出成果。

Berth 教學第一步：固定版本，先拍下空桌子的樣子

怎麼知道顯存真的有釋放？先建立基準。關閉你自己啟動、已完成工作的 AI 引擎，保留桌面與必要程式，執行 nvidia-smi。記下卡的型號、驅動、總量、已用量與程序名稱；這是之後比較的起點，不要求桌面主機回到零占用。

nvidia-smi
nvidia-smi --query-gpu=index,name,memory.total,memory.used,memory.free --format=csv
nvidia-smi --query-compute-apps=pid,process_name,used_gpu_memory --format=csv

第二行看整張卡，第三行看計算程序。依 NVIDIA 的 nvidia-smi 說明，這些是不同層級的查詢；計算程序清單不等於所有顯示工作。先對照總占用與完整 nvidia-smi 程序畫面，再追哪一個引擎新增了多少。

接著安裝固定標籤的 Berth。以下下載檔適用 Linux x86-64；ARM64 使用者須改成同一發布頁的 berth-linux-arm64。在自己建立的空資料夾執行，雜湊核對成功後才安裝；若查驗失敗就停在這裡，重新下載，不繼續啟動。

mkdir -p ~/berth-v036-download
cd ~/berth-v036-download
curl -fLO https://github.com/T-Crypt/berth/releases/download/v0.3.6/berth-linux-amd64
curl -fLO https://github.com/T-Crypt/berth/releases/download/v0.3.6/SHA256SUMS
sha256sum --check --ignore-missing SHA256SUMS

確認顯示該執行檔的 OK，再執行下面兩行；安裝方式來自 官方安裝文件。把 ~/.local/bin 加入你的 PATH，或在之後的命令使用完整路徑。

install -Dm755 berth-linux-amd64 ~/.local/bin/berth
~/.local/bin/berth version

第二步：先啟動管理員，再把兩個引擎交給它

「畫面看得到引擎」就代表受管嗎？讀取狀態和管理啟停是兩件事。先在終端 A 執行 berth daemon --gpu 0，讓它持續開著；另開終端執行 berth status。如果 daemon 無法連線，先排除問題。第一次練習採前景程序，較容易看見錯誤和結束服務。

需要網頁觀察時，可另開終端執行 berth harbor --listen 127.0.0.1:9798，再開啟本機網址。依 安裝文件的網路邊界，Harbor 預設沒有身分驗證；保留 loopback 位址，不改成對外監聽。

現在先記下你原本能正常啟動的兩條命令，以及啟動所在目錄。同時記錄 llama-server --version、ComfyUI 的 Git commit 與工作流檔。停止你自己的舊副本，避免它們繞過調度重新占卡。若原本有 systemd 或容器自動重啟，先暫停那個啟動來源並保留設定備份；不要同時保留原服務與新 wrapper。

在終端 B，用下面的包裝方式啟動文字引擎。把大寫路徑改成自己的 llama-server 與 GGUF 路徑；模型應是你已驗證能單獨使用的版本。--drain-slots 讓交接等待文字工作槽完成，--fail-closed 則讓缺少管理員時拒絕這次不受保護的啟動。

berth run --as llama-server --priority interactive --wait 10m --fail-closed \
  --drain-slots http://127.0.0.1:8080 -- \
  /ABS/PATH/llama-server -m /ABS/PATH/model.gguf \
  --host 127.0.0.1 --port 8080 --metrics

這裡 -- 前面是 Berth 的參數，後面才是文字引擎的參數。以 官方引擎整合範例與 llama.cpp Server 文件交叉核對：/slots 用於觀察工作槽，--metrics 開啟指標。先用 curl -f http://127.0.0.1:8080/slots 確認可讀，再送正式文字請求。

Berth 教學第三步：讓文字先做完，圖片再接棒

排隊時究竟應該看到什麼？看同一段工作的完整交接。先透過你原本的文字客戶端送一個有足夠輸出長度的低風險請求，保留回覆。在回覆仍進行時，到 ComfyUI 原本的工作目錄，用它既有的 Python 環境啟動以下命令；先把路徑替換正確。

berth run --as comfyui --priority interactive --wait 10m --fail-closed \
  --drain-comfyui http://127.0.0.1:8188 -- \
  /ABS/PATH/ComfyUI/.venv/bin/python /ABS/PATH/ComfyUI/main.py \
  --listen 127.0.0.1 --port 8188

兩者使用相同 interactive 優先序。依固定版本規則，同級新要求可以要求交接；已設定的工作邊界仍須等待。這裡的 --wait 10m 是本次取卡等待上限，不是保證十分鐘內完成工作。若遇到既有 min_turn 或 juggle 防反覆切換規則，先讀取等待原因，保留它，而非為了讓畫面好看就移除保護。

• 文字尚在生成：查 berth status 與 /slots，確認新要求在等待，文字回覆繼續。
• 文字回覆完成：觀察舊引擎進入交接，並在另一終端執行 nvidia-smi -l 1，看舊程序占用下降。
• ComfyUI 取得租約：待伺服器啟動後開啟 http://127.0.0.1:8188，載入你已單獨跑通的工作流，只送一張圖片。
• 圖片完成後：保存輸出；要切回文字，在終端 B 再執行同一條文字 wrapper。這次 ComfyUI 的佇列邊界是接棒條件。

圖片的「排進去了」和「已完成」也要分開。ComfyUI 官方 API 文件把 /prompt 定義為送件入口，/queue 為佇列，/history/{prompt_id} 為該件歷史。保留 prompt ID、完成歷史與實際圖片，才知道工作完成，而不只是按鈕被按下。

這段練習不是建議兩邊不停互搶。每一趟都完成一次工作再換；要特別觀察「忙碌時等待」，才在第一份回覆進行中提出下一個取卡要求。若 client 逾時，先查租約及引擎日誌，確認是否仍在等待，避免連點重試造成更多要求。

第四步：分清「已卸載」「停放 RAM」與「真的可用」

文字結束了，為什麼程序還在？停止與停放是不同狀態。先檢查自己的既有設定，停用測試引擎的 keep_comfyui_up 與停放 hook，讓本篇手動路線採取停止程序；以停止舊引擎、重新啟動下一個為主。若你另外採用官方 Gateway 的停放設定，ComfyUI 可以卸下模型而保留服務，權重或快取會留在系統記憶體，仍可能保留 CUDA context。

因此「網頁還開著」不代表模型還占滿顯存；「模型卸載」也不代表程序的 GPU 占用歸零。官方停放機制會把剩餘占用納入下一次取卡判斷，並依 RAM 條件決定能否停放。冷載入要讀檔，停放要使用系統 RAM，兩者各有成本。

自行驗收時，每個階段記四欄：時間、租約持有者與等待原因、驅動總占用與相關 PID、工作結果。先比較同一張卡的基準，再看舊程序與新程序，不要把一個 EST. VRAM 估計欄位當成驅動實測。若要加入速度比較，另記從送件到第一個輸出，以及從送件到完整成果，別把等待時間和模型載入時間混成一個數字。

官方 公開測量頁提供 RTX 4090、特定 RAM、驅動與模型配置的切換紀錄，也分開描述等待與載入。它能幫你設計測法，無法替你的 GPU 預先填成績。本文因此不承諾省多少秒，也不以一次畫面變綠宣告穩定。

第五步：兩個近期問題，先查版本與控制權

看不到模型資訊，是否代表釋放失敗？先分辨顯示配對與實際占用。2026 年 10 月 28 日查閱時，v0.4.0-rc.5 發布說明已列出依 llama-swap 的模型檔案路徑配對 Library 的修正，涵蓋模型 ID 與 GGUF 檔名不同的情況。這是候選版修正，不能倒推本文固定的 v0.3.6 已包含它。

碰到 SERVED BY 或 EST. VRAM 空白，先對照 berth status、llama-swap 的實際啟動參數與驅動程序資訊。問題 #197 的原始回報是 Windows 11＋v0.3.6 的特定案例；不要把它擴大成所有部署都失去調度功能。新手可先完成本文的直接 llama-server 路線，再處理既有 llama-swap 整合。

Docker 又是另一種問題：看見容器，不等於能控制它。穩定版的 容器整合文件已提供 berth run --container NAME -- docker start -a NAME 形式。這和容器自己的排程、restart policy 把它重新啟動，是不同的啟動來源。查出誰會開它，才能把那條路徑一起納入管理。

本週 問題 #172反映的正是背景容器與控制權需求。不要因 issue 仍開著，就寫成 Berth 完全不支援 Docker。若容器自行重新載入，先保存狀態與日誌，正常停止自己的該容器，修正啟動來源，再重跑交接；不要對整張卡的所有 PID 執行強制終止。

截至本次查閱，穩定發布標籤仍是 v0.3.6，最新候選版為 v0.4.0-rc.5。前者的 README 本身仍標示 alpha；「穩定發布」指非 prerelease 標籤，不等於已達成熟產品等級。先固定版本完成自己的驗收，再在獨立環境評估候選版修正。

遇到卡住怎麼退出？先停自己的引擎，再停管理員

若狀態停在 aground，意義是釋放沒有符合驅動驗收，下一位仍被擋住。先執行 berth reclaim 閱讀它記錄的 PID、程序起始時間與占用；不要一開始就加 --yes。依 租約與回收規則，未受管程序會被列出，但不會因列在這裡就自動變成 Berth 可終止的工作。

正常退出可執行 berth stop llama-server --wait 或 berth stop comfyui --wait，核對工作已完成與租約釋放。確認兩個受管引擎結束後，再回到 daemon／Harbor 終端按 Ctrl-C。若你原本暫停過自動啟動服務，恢復前先決定是否保留 Berth 包裝，避免恢復成兩套同時啟動。

常見問題：八個判斷先講答案

Berth 會增加實體顯存嗎？

不會。本文使用整卡輪流租約；模型單獨放不下時，要回到模型容量與引擎設定處理。

Harbor 看得到引擎，就已經受管嗎？

不一定。狀態讀取與租約控制分開；查該啟動命令是否經過 wrapper，以及是否取得租約。

為什麼每條 wrapper 都加 –fail-closed？

因為預設是 fail-open。固定版本文件說 daemon 不在時，預設仍可能啟動成未受保護工作；本練習選擇拒絕那種啟動。

排隊代表現在已替我保留顯存嗎？

不代表。排隊是等待許可；實際載入仍取決於當時驅動狀態與引擎能否成功啟動。

卸載後一定會回到零 MiB 嗎？

不一定。桌面基準與存活程序的 context 可能仍占用；先比較基準和相關 PID。

ComfyUI 停放後可以一直直接送 8188 嗎？

應走受管入口。若改用停放配置，官方文件要求透過 Gateway 恢復租約；直接送到後端可能在未取卡時重新載入。本文未開停放，手動練習只在取得租約後送工作。

Library 空白就該升候選版嗎？

先查實際占用與模型配對。rc.5 已列相關修正，但升級仍需重做你自己的交接驗收，不能只看欄位恢復顯示。

適合只想偶爾生成一張圖片的人嗎？

先看你是否常在不同引擎之間切換。若只有一個引擎，先把單次工作跑穩；若常因爭卡而手動關服務，這套交接觀念更有用。

給新手的三個重點

• 先讓每個引擎單獨跑通，再用整卡租約學交接，不急著共住。
• 同時保存管理員狀態、驅動占用與最終成果；這三種證據各回答一個問題。
• 保留版本和原啟動設定，從一次文字→圖片→文字開始，成功後再加自動化。