Comfyui on Tarragon

Hands-on：安裝 ComfyUI + SDXL base

Tue, 12 May 2026 00:00:00 +0000

本篇紀錄裝 ComfyUI 跟 Stable Diffusion XL base 模型、在 Apple Silicon Mac 上跑通最小 text-to-image 流程。ComfyUI 是 2026 年 Apple Silicon 跑 Diffusion 最主流的選擇——節點式工作流（拖拉節點連線、像 visual programming、每個節點負責一段運算）、跨平台、Python 環境、容易客製化。Draw Things（Mac 原生 GUI）更簡單、但 ComfyUI 接 workflow 跟 custom node 的能力強很多。

驗證日期：2026-05-12 ComfyUI：main branch、shallow clone 示範模型：Stable Diffusion XL base 1.0（6.5 GB、stabilityai/stable-diffusion-xl-base-1.0） Python：3.14（venv 隔離、不污染系統）

前置設定

項目	檢查指令	預期
Git	`which git`	`/usr/bin/git` 或 brew 版
Python 3.10+	`python3 --version`	3.10 ~ 3.14 都可、本 demo 用 3.14
磁碟空間	`df -h ~`	至少 15 GB（runtime 3 GB + SDXL 6.5 GB + cache）
統一記憶體	`system_profiler SPHardwareDataType \| grep Memory`	至少 16 GB、推薦 32 GB+

ComfyUI 在 Apple Silicon 跑 Diffusion 用 MPS（Metal Performance Shaders）backend、不需要 NVIDIA CUDA。但跑 SDXL 至少要 12 GB 統一記憶體留給 model + activation、16 GB Mac 跟其他 app 一起會吃緊。

Clone ComfyUI

放在 ~/Projects/ 下、跟其他 dev project 同層：

1cd ~/Projects
2git clone --depth 1 https://github.com/comfyanonymous/ComfyUI.git
3cd ComfyUI

--depth 1 只拉最新 commit、不拉全部歷史、省幾百 MB。要追歷史 / submit PR 才需要 full clone。

ComfyUI 目錄結構（核心部分）：

 1ComfyUI/
 2├── main.py              # 啟動 entry point
 3├── server.py            # HTTP server
 4├── nodes.py             # 內建節點實作
 5├── custom_nodes/        # 第三方 / 客製節點放這
 6├── models/
 7│   ├── checkpoints/     # SD / SDXL 主 model 檔放這
 8│   ├── loras/           # LoRA 微調權重
 9│   ├── vae/             # VAE 模型
10│   ├── controlnet/      # ControlNet 模型
11│   └── ...
12├── output/              # 生成的圖
13├── input/               # 拖進 ComfyUI 的圖片
14└── requirements.txt

建 venv + 裝 dependencies

ComfyUI requirements 含 PyTorch、numpy、PIL、safetensors、einops 等、套件多、版本敏感。用 venv 隔離：

1cd ~/Projects/ComfyUI
2python3 -m venv venv
3source venv/bin/activate
4python --version  # 確認在 venv 內
5pip install --upgrade pip

裝 dependencies：

1pip install -r requirements.txt

實測時間：10-15 分鐘（torch + 各種 dep）、首次跑會編譯部分 C extension。完成後預期看到：

1Successfully installed Mako-... MarkupSafe-... Pillow-... PyOpenGL-... ...
2  torch-... torchvision-... torchaudio-... ...
3  safetensors-... transformers-... ...

驗證 PyTorch + MPS：

1python -c "import torch; print('torch:', torch.__version__, 'mps:', torch.backends.mps.is_available())"
2# torch: 2.x.x mps: True

mps: True 表示 Apple Silicon GPU 加速可用。

下載 SDXL base 模型

SDXL base 約 6.5 GB、是 Stable Diffusion XL 的基礎 model。從 Hugging Face 拉到 ComfyUI 的 models/checkpoints/：

1mkdir -p ~/Projects/ComfyUI/models/checkpoints
2cd ~/Projects/ComfyUI/models/checkpoints
3
4# -L 跟 redirect、--continue-at - 支援中斷後重續、避免 6.5 GB 重下
5curl -L --continue-at - -o sd_xl_base_1.0.safetensors \
6  "https://huggingface.co/stabilityai/stable-diffusion-xl-base-1.0/resolve/main/sd_xl_base_1.0.safetensors?download=true"

下載時間視網速、10-30 分鐘 broadband 都正常。網路中斷時重跑同一個指令、--continue-at - 會從中斷處續傳、不用重下 6.5 GB。完成後：

1ls -lh sd_xl_base_1.0.safetensors
2# 6.5 GB

可選的進階模型：

Model	大小	用途
SDXL base 1.0	6.5 GB	基礎、本 demo 用
SDXL refiner 1.0	6.1 GB	跟 base 配對、提升細節
SD 1.5	4.0 GB	較小、生態最成熟（很多 LoRA）
Flux.1 schnell	12 GB	2024+ 最強開源 SD 級
Flux.1 dev	24 GB	Flux 完整版、品質最佳

SDXL 6.5 GB 是「能驗證 + 不過大」的甜蜜點。再小可以選 SD 1.5（4 GB）、跑 Flux 要 24 GB 磁碟 + 16 GB+ 統一記憶體。

啟動 ComfyUI Server

1cd ~/Projects/ComfyUI
2source venv/bin/activate
3python main.py

預期輸出：

1[Prompt Server] Starting ComfyUI...
2Total VRAM 32768 MB, total RAM 32768 MB
3pytorch version: 2.x.x
4Set vram state to: SHARED
5Device: mps
6Using sub quadratic attention for cross-attention
7...
8Starting server
9To see the GUI go to: http://127.0.0.1:8188

Apple Silicon 統一記憶體被 PyTorch 報成 VRAM 是預期、不是 bug：mps backend 把整個統一記憶體當成「GPU 可見記憶體」、所以 32GB Mac 顯示 Total VRAM 32768 MB。實際使用上 ComfyUI、其他 app 跟系統共用同一塊。

關鍵驗證：

Device: mps → Apple Silicon GPU 啟用
Starting server + http://127.0.0.1:8188 → server 跑了

開瀏覽器到 http://127.0.0.1:8188、看到節點式 UI 就成功。第一次開啟會載入預設 workflow（一個簡單 text-to-image）。

要對外暴露（讓 LAN 內其他機器連）：

1python main.py --listen 0.0.0.0 --port 8188

跟 0.7 隱私資料流提的一樣、0.0.0.0 等於暴露給整個區網、家用 OK 公共網路要小心。

跑第一張圖

ComfyUI 預設 workflow 是 text-to-image：

CheckpointLoader 節點：選 sd_xl_base_1.0.safetensors。
CLIPTextEncode（Prompt）節點：輸入 prompt、例如 a photograph of a cat sitting on a wooden chair, natural lighting。
CLIPTextEncode（Negative）節點：輸入 negative prompt、例如 blurry, low quality, artifacts。
EmptyLatentImage 節點：設定 1024×1024（SDXL 最佳尺寸）。
KSampler 節點：steps=20、cfg=7、sampler=euler 或 dpmpp_2m。
VAEDecode 節點：把 latent 轉成 RGB image。
SaveImage 節點：存到 output/。

點右側 panel 的 Queue Prompt、開始生成。

實測時間（M4 Pro 32GB、SDXL base、1024×1024、MPS backend）：

Steps	第一張（含 model 載入）	後續同 model	備註
15	約 100-110 秒	約 30-40 秒	本驗證實測 106s（含載入）
20	約 130-150 秒	約 40-60 秒	ComfyUI 預設值
30	約 200 秒	約 80 秒	品質更高、邊際效益小

16GB Mac 跑 SDXL：每張 60-180 秒、可能會降頻。

生成完成後在 output/ 看到 PNG 檔（如 comfyui-test_00001_.png）。

用 REST API 直接生成（不開瀏覽器）

GUI 適合互動探索、自動化要走 REST API。完整 script 在 scripts/comfyui-test/generate.py、實際驗證指令：

1cd ~/Projects/blog
2python3 scripts/comfyui-test/generate.py --steps 15

腳本流程：

 1def build_workflow(prompt_text, neg_text, steps):
 2    return {
 3        "3": {"inputs": {"seed": 42, "steps": steps, "cfg": 7.0, "sampler_name": "euler",
 4                         "scheduler": "normal", "denoise": 1.0,
 5                         "model": ["4", 0], "positive": ["6", 0],
 6                         "negative": ["7", 0], "latent_image": ["5", 0]},
 7              "class_type": "KSampler"},
 8        "4": {"inputs": {"ckpt_name": "sd_xl_base_1.0.safetensors"},
 9              "class_type": "CheckpointLoaderSimple"},
10        "5": {"inputs": {"width": 1024, "height": 1024, "batch_size": 1},
11              "class_type": "EmptyLatentImage"},
12        "6": {"inputs": {"text": prompt_text, "clip": ["4", 1]},
13              "class_type": "CLIPTextEncode"},
14        "7": {"inputs": {"text": neg_text, "clip": ["4", 1]},
15              "class_type": "CLIPTextEncode"},
16        "8": {"inputs": {"samples": ["3", 0], "vae": ["4", 2]},
17              "class_type": "VAEDecode"},
18        "9": {"inputs": {"filename_prefix": "comfyui-test", "images": ["8", 0]},
19              "class_type": "SaveImage"},
20    }

workflow JSON 結構解釋：

每個 key（“3”、“4”、…）是節點 ID。任意整數字串、只要在 workflow 內唯一即可。
class_type：節點類型（KSampler、CheckpointLoaderSimple、CLIPTextEncode 等）、ComfyUI 內建。
inputs：節點參數。標量值（如 1024、"euler"）直接寫；連到別的節點輸出用 [node_id, output_index] 形式。
["4", 0] 表示「節點 4 的第 0 個 output」。CheckpointLoaderSimple 有三個 output：model（0）、clip（1）、vae（2）、所以 ["4", 0] 是 model、["4", 1] 是 clip、["4", 2] 是 vae。

每個節點做什麼：

4 CheckpointLoaderSimple：載 SDXL safetensors、輸出 model / clip / vae 三個東西。是整條 graph 的根。
5 EmptyLatentImage：建一張 1024×1024 的空白 latent tensor（不是 RGB 圖、是 4-channel latent space tensor）。SDXL 的「畫布」。
6 CLIPTextEncode (positive)：把 prompt 文字用 CLIP text encoder 轉成 conditioning vector。
7 CLIPTextEncode (negative)：同上、但是 negative prompt（要 avoid 的特徵）。
3 KSampler：核心 denoising loop。15-30 個 step、把 latent 從噪聲變成跟 conditioning 對齊的 latent。
8 VAEDecode：把 latent 用 VAE 解碼成 RGB 圖（1024×1024×3）。
9 SaveImage：寫 PNG 到 output/ 目錄、檔名 prefix comfyui-test。

為什麼 graph 結構這樣：

為什麼 model / clip / vae 從同一個 checkpoint 拿：SDXL 設計上三個元件互相 train、必須同源。從不同 checkpoint 拿會造成生成品質崩。
為什麼 EmptyLatentImage 不直接接 KSampler、要設 batch_size：保留 batch 維度、未來要 batch generation（一次生 4 張）改 batch_size: 4 就好、其他節點不用改。
為什麼 sampler 用 euler、scheduler 用 normal：最簡單的組合、SDXL base 上品質可預測。其他選項（dpmpp_2m、karras scheduler 等）品質可能更好但效果各模型不同。
為什麼 cfg=7.0：classifier-free guidance scale。SDXL 的標準預設、太低（< 3）模型忽略 prompt、太高（> 12）過 saturated。
為什麼 seed=42：固定 seed 讓結果可重現。每次跑同 prompt 同 seed 同 model 結果完全一樣——是調 prompt / 比較 model 的必要條件。

 1def main():
 2    workflow = build_workflow(args.prompt, args.neg, args.steps)
 3    client_id = str(uuid.uuid4())
 4    resp = http_post_json("/prompt", {"prompt": workflow, "client_id": client_id})
 5    prompt_id = resp["prompt_id"]
 6
 7    while True:
 8        time.sleep(2)
 9        history = http_get_json(f"/history/{prompt_id}")
10        if prompt_id in history:
11            outputs = history[prompt_id].get("outputs", {})
12            break
13
14    img = outputs["9"]["images"][0]
15    qs = urllib.parse.urlencode({"filename": img["filename"], "type": "output"})
16    blob = http_get_bytes(f"/view?{qs}")
17    Path(args.out).write_bytes(blob)

每段做什麼：

client_id = str(uuid.uuid4())：每個 client 識別碼。ComfyUI 用 client_id 把 progress events 路由給正確 WebSocket subscriber。本 demo 用 polling、client_id 隨意產生即可。
POST /prompt：送 workflow + client_id、server 回 prompt_id（這次 job 的 UUID）。Server 把 workflow 丟進 internal queue、立刻 return、不會等 generation。
while True: time.sleep(2); GET /history/{prompt_id}：polling 等 job 完成。完成的 job 才會出現在 /history 裡（執行中 / queued 都不算）。
if prompt_id in history：完成判讀——history 內出現該 prompt_id 表示 generation 結束。
outputs["9"]["images"][0]：節點 9 (SaveImage) 的輸出、含 filename、subfolder、type 等資訊。
/view?filename=...&type=output：拿生成的 PNG bytes。type=output 是 ComfyUI 的內部 dir 標記（區分 output / input / temp）。

為什麼這樣設計：

為什麼 polling 而不是 WebSocket：WebSocket 要 subscribe events、處理 connection lifecycle、邏輯複雜。Polling 兩行解決、對教學 demo 夠用。Production 自動化系統建議用 WebSocket、知道每個 progress event。
為什麼 time.sleep(2)：太短（< 1s）對 server 造成不必要 polling；太長（> 5s）感知延遲明顯。2 秒是 demo 友善平衡。
為什麼用 prompt_id 而不是 client_id 查 history：一個 client 可能送多個 job、prompt_id 唯一識別 job。client_id 主要用 WebSocket 訂閱、不是 history query 主鍵。
為什麼 Path(args.out).write_bytes(blob)：PNG 是 binary、用 write_bytes 直接寫；改用 open(...).write() 的 text mode 會在編碼轉換時破壞檔案內容。

實測：M4 Pro 32GB、prompt 「a photograph of an orange cat sitting on a wooden chair, soft natural lighting, detailed fur」、15 steps、cfg=7、euler+normal sampler、seed=42 → 106 秒生成 1024×1024 PNG、1.65 MB。

ComfyUI 的 REST API 形狀（無 OpenAI 相容層）

ComfyUI 沒提供 OpenAI 相容 API、它的 API 是自己的 REST + WebSocket：

POST /prompt：丟一個 workflow JSON、回傳 job id。
GET /history/{prompt_id}：查看生成結果。
GET /view?filename=X：拿生成的圖。
WebSocket：訂閱 job progress events。

API 形狀跟 Diffusion 任務匹配、跟 LLM 的 /chat/completions 完全不同——這正是 4.1 RAG 章節提到「Diffusion 跟 Transformer 工具鏈互不通用」的具體展現。Ollama / LM Studio 對接 Continue.dev 的 OpenAI 相容路徑、跟 ComfyUI 接 SDXL 是完全平行的兩條路。

常用 Custom Nodes

ComfyUI 的核心功能來自 custom nodes、社群維護。最常用：

Custom Node	功能
ComfyUI-Manager	管理其他 custom node、安裝 / 更新
ComfyUI-Impact-Pack	物件偵測、masking、inpainting
ComfyUI-AnimateDiff	影片動畫生成
ComfyUI-ControlNet-Aux	ControlNet preprocessor
ComfyUI-IPAdapter-plus	圖像 reference embedding

安裝方式（透過 ComfyUI-Manager）：

1cd ~/Projects/ComfyUI/custom_nodes
2git clone https://github.com/ltdrdata/ComfyUI-Manager.git
3# 重啟 ComfyUI、UI 多一個 Manager 按鈕、之後用 Manager 裝其他 node

常見坑

Python 版本太新、torch 沒 wheel

PyTorch 對最新 Python（3.13、3.14）的 wheel 發布有 lag、可能 pip install -r requirements.txt 跑 build from source 慢 + 失敗。退到 Python 3.11 / 3.12：

1brew install python@3.11
2python3.11 -m venv venv
3source venv/bin/activate
4pip install -r requirements.txt

`mps: False`、跑在 CPU 上

確認 PyTorch 是 Apple Silicon 版本（不是 x86_64 emulation）：

1python -c "import platform; print(platform.machine())"
2# arm64 ← 正確；x86_64 ← 走 Rosetta、要重裝

如果是 x86_64、表示 venv 用了 Intel Python。重建 venv：

1deactivate
2rm -rf venv
3arch -arm64 python3 -m venv venv

記憶體不夠、推論時 crash

SDXL 在 16 GB Mac 上吃緊、可能 swap 或 crash。緩解：

1# 降解析度
2python main.py --normalvram   # 預設、~12 GB
3python main.py --lowvram      # 較省、~8 GB、慢
4python main.py --novram       # 極省、~4 GB、極慢、實用上界

或換 SD 1.5（4 GB checkpoint）、記憶體需求 < SDXL 的一半。

Workflow JSON 載入失敗

ComfyUI workflow 是 JSON 描述節點 + 連線。如果是別人分享的 workflow、可能用了你沒裝的 custom node。錯誤訊息會列出缺哪些 node、用 ComfyUI-Manager 補裝。

Port 8188 被佔

1lsof -i :8188
2python main.py --port 8189  # 改 port

跟 LLM stack 並存

ComfyUI 用 port 8188、跟 Ollama (11434) / LM Studio (1234) 完全不撞、可同時跑。實務配置：

服務	Port	用途
Ollama	11434	寫 code、對話
ComfyUI	8188	產圖
LM Studio	1234	探索新 LLM
Open WebUI	3000	ChatGPT 風格瀏覽器介面

各服務獨立、不干擾、可以一台 Mac 跑全部（看記憶體預算）。

何時這篇會過時

ComfyUI 主分支 API 短期內穩定（大量社群依賴）。
SDXL base 1.0 不會消失、但會被新版本（SDXL 1.1、Flux 等）取代——「下載 .safetensors 放 models/checkpoints/」流程不變。
MPS backend 持續優化、效能會提升、但介面不變。
Python 版本相容性會持續演化、pip install -r requirements.txt 偶爾要降版 Python。

讀的時候若 pip install 失敗、看 ComfyUI GitHub issues 跟 PyTorch release notes 對應的 Python 版本。

跟其他 hands-on 章節的關係：完整 hands-on 系列見 Hands-on 章節索引、跨服務的 lifecycle / 記憶體管理見 Resource management、ComfyUI 跟 Ollama 同台跑的記憶體預算規劃見 0.5 Apple Silicon 記憶體預算。

Hands-on：LLM 運行中 + 結束的資源管理

Tue, 12 May 2026 00:00:00 +0000

跑本地 LLM 的核心 invariant 跟雲端不一樣：Mac 是 shared resource、不是 dedicated GPU。雲端 inference server 跑進 dedicated container、結束 instance 自然回收所有資源；本地推論伺服器跑在你日常用的 Mac、跟統一記憶體共享同一塊容量，忘記管理會 silently 吃光 RAM、磁碟、port、最後讓系統變慢甚至 swap。

本篇紀錄三個 dimension（RAM / 磁碟 / port）的觀察工具跟釋放姿勢、對比 Ollama 跟 ComfyUI 兩種典型 lifecycle、加上實測釋放數字。對應 0.7 隱私資料流原理「每個 hop 都要 audit」這條思維——資源管理也是 hop 級的 audit、不是「裝完就忘」。

驗證日期：2026-05-12 環境：macOS 14、Apple Silicon、Ollama 0.23.2、ComfyUI 0.21.0、SDXL base 1.0

為什麼這事重要

雲端 inference：

1Container start → load model → serve requests → container stop → 所有 RAM / 磁碟 / port 自動回收

本地 inference：

1brew services start → load model on demand → serve → ??? → 你忘記 stop
2                                              → RAM / 磁碟一直被佔
3                                              → 下次重開機才釋放

具體會踩到的問題：

RAM：18 GB SDXL 模型載入後不會自動卸、即使 ComfyUI idle、Python process 仍占 RAM
磁碟：ollama pull 累積、~/.ollama/models/blobs 半年可長到 50 GB+、不主動清不會減
Port：上次 crash 的 ollama serve 進程沒乾淨清、port 11434 還占著、下次啟動報「address already in use」
GPU / Metal：模型載入後 Metal context 佔住、跟其他 GPU-using app（影片剪輯、遊戲）競爭

三個 dimension + 觀察工具

Dimension	觀察指令	看什麼
RAM	`vm_stat \| head -5`	Pages free（每 page 16 KB）、空閒越多越好
RAM（per process）	Activity Monitor 或 `ps aux \| sort -k6 -rn \| head`	哪個 process 佔最多記憶體
磁碟	`df -h ~ \| tail -1`	系統 volume 剩餘
磁碟（per dir）	`du -sh ~/.ollama/models/blobs`	LLM models 累積量
Port	`lsof -i :11434`	誰在 listen 該 port
Process	`ps aux \| grep -i ollama \| grep -v grep`	Ollama / ComfyUI / Python 跑哪幾個
Ollama loaded models	`ollama ps`	哪些 model 在 RAM、size、idle timer

實測：剛 kill 完 ComfyUI（SDXL + Python venv）後、vm_stat 看到 free pages 從 619K 變 1090K（每 page 16 KB）、約 +7.5 GB RAM 釋放——這就是 SDXL + ComfyUI process 一直占的記憶體量。

Ollama 的 lifecycle（auto-unload 模式）

Ollama 走「按需 load / idle unload」設計：

1brew services start ollama          → daemon 啟動、沒 model 載入、RAM 占用 ~200 MB
2                                     port 11434 listening
3ollama run gemma3:4b "hello"        → 把 model 載入 RAM (~4-5 GB)
4                                     立刻 generate response
5                                     model 留在 RAM
6(idle 5 分鐘、無新 request)         → Ollama 自動 unload model
7                                     RAM 釋放、daemon 仍跑著
8ollama run gemma3:4b "next"         → 重新 load model（~5-10 秒）、generate
9brew services stop ollama           → daemon 結束、port 釋放

關鍵參數 OLLAMA_KEEP_ALIVE（環境變數、預設 5m）：

 1# 看當前 loaded models
 2ollama ps
 3# NAME         ID              SIZE      PROCESSOR    UNTIL
 4# gemma3:4b    a2af6cc3eb7f    5.5 GB    100% Metal   4 minutes from now
 5
 6# 啟動時調 keep_alive（持續佔 RAM 直到 ollama 重啟）
 7OLLAMA_KEEP_ALIVE=-1 brew services restart ollama
 8
 9# 啟動時讓 model 用完立即 unload
10OLLAMA_KEEP_ALIVE=0 brew services restart ollama

選 keep_alive 的 trade-off：

設定	RAM 占用	首字延遲	適合場景
`0`	最低（generate 完立即釋放）	高（每次都重 load）	偶爾用、RAM 緊張
`5m`（預設）	中（活躍用占住、閒 5 分鐘後釋放）	低（活躍期不重 load）	大多場景
`-1`	高（永久占住）	最低	整天頻繁用、RAM 充裕

主動 unload 指令：

1# 把 idle 的 model 立刻從 RAM 卸掉、但 daemon 仍跑
2curl -s http://localhost:11434/api/generate \
3  -d '{"model": "gemma3:4b", "keep_alive": 0}'
4
5# 或關掉整個 daemon
6brew services stop ollama

ComfyUI 的 lifecycle（持續占用模式）

ComfyUI 走完全不同模式：model 載入後一直在 RAM、直到 server process 結束。沒有 auto-unload 機制。

 1python main.py                      → ComfyUI server start、port 8188 listening
 2                                     RAM ~3 GB（Python venv + 框架）
 3第一次 Queue Prompt (用 SDXL)        → 載入 sd_xl_base_1.0.safetensors (~6 GB)
 4                                     RAM 跳到 ~9-10 GB
 5                                     generate 完成、model 留在 RAM
 6連續多張生成                          → 維持 ~9-10 GB、沒 unload
 7idle 1 小時                          → 仍 ~9-10 GB（沒 timer）
 8切到 ControlNet workflow             → 多載 ControlNet model (~2 GB)、ComfyUI 自動 swap
 9                                     RAM 暫升、SD 部分可能被 evict 到 disk
10Ctrl+C / pkill                       → process 結束、RAM 完全釋放

要釋放 ComfyUI 占的 RAM、唯一方法是結束 server：

 1# 找 PID
 2ps aux | grep "ComfyUI/main.py" | grep -v grep
 3
 4# 優雅關（讓它 cleanup）
 5pkill -INT -f "ComfyUI/main.py"
 6
 7# 強制 kill（如果上面沒反應、最多等 5 秒再強制）
 8pkill -KILL -f "ComfyUI/main.py"
 9
10# 確認 port 釋放
11lsof -i :8188 | head -3

實測：M4 Pro 32GB、SDXL base 載入後 ComfyUI process 占 ~8 GB RAM；pkill -9 後 vm_stat 顯示 free pages 增加 ~470K page（7.5 GB 釋放）。

為什麼 Ollama 跟 ComfyUI 設計不同

因素	Ollama 設計	ComfyUI 設計
主要使用模式	API 服務、IDE plugin 透過 HTTP 用	互動 GUI、user 連續調 prompt
Model 切換頻率	高（不同任務換不同 model）	低（一次 session 通常一個 model）
User 期待的 latency	低首字延遲（IDE 補完場景）	高 throughput（連續生圖）
結論	Auto-unload 釋 RAM 給其他 model	持續載入避免重複 load 浪費

兩種設計都 valid、適合不同使用模式。理解差異後就知道 ComfyUI 一直占 RAM「不是 bug」、是設計選擇。

跟其他本地 server 對比

Server	Auto-unload	主動 unload 指令	占 RAM 觀察
Ollama	有（5 分鐘 idle）	`keep_alive: 0` 或 stop daemon	`ollama ps`
LM Studio	無（GUI 主動關閉 model 才釋）	GUI Eject Model	Activity Monitor
llama.cpp `llama-server`	無	kill process	`lsof -i :8080`
ComfyUI	無	kill process	`ps aux \| grep ComfyUI`
oMLX	有（per model 可配）	API endpoint	server log

結論：只有 Ollama 跟 oMLX 內建 auto-unload、其他都要手動釋放。GUI server（LM Studio）通常給 user 一個「Eject」按鈕、CLI server 通常要 kill process。

標準釋放程序

寫 code 完一天結束、要釋放所有資源、按下表順序操作：

 1# 1. 確認當前狀態（記下要還回去多少 RAM）
 2vm_stat | head -3
 3df -h ~ | tail -1
 4ollama ps
 5ps aux | grep -E "ollama|ComfyUI|llama-server" | grep -v grep
 6
 7# 2. 釋放當前載入的 LLM models（Ollama）
 8brew services stop ollama
 9# 或保留 daemon、只 unload model：
10# curl -s http://localhost:11434/api/generate -d '{"model": "", "keep_alive": 0}'
11
12# 3. 結束 ComfyUI / 其他 GUI server
13pkill -INT -f "ComfyUI/main.py" 2>/dev/null
14pkill -INT -f "llama-server" 2>/dev/null
15sleep 5
16# 強制（如果上面沒清乾淨）
17pkill -KILL -f "ComfyUI/main.py" 2>/dev/null
18pkill -KILL -f "llama-server" 2>/dev/null
19
20# 4. 驗證所有 port 釋放
21lsof -i :11434 -i :1234 -i :8080 -i :8188 -i :8000 2>&1 | head
22
23# 5. 確認釋放量
24vm_stat | head -3
25# free pages 該明顯增加

容易出錯的「釋放方式」

killall Python：會 kill 所有 Python process、包括其他 dev tool（如 jupyter、Django）。用 pkill -f "ComfyUI/main.py" 等明確 pattern。
rm -rf ~/.ollama：會清掉所有 model registry、下次要重 pull 全部 model。Cleanup 用 ollama rm 才精準。
brew uninstall ollama：直接卸載 Ollama 本身、過 reinstall 麻煩。Stop service 就夠。
重開機釋放：work 但太重、會中斷其他工作。用 process-level 操作即可。

磁碟長期累積管理

Models 一旦 pull 進 ~/.ollama/models/blobs、不主動 rm 不會減少。半年累積可長到 50 GB+。

Ollama models 只是磁碟大戶之一。整台 Mac 突然被吃光、要從哪裡查起的全機診斷順序（先排除快照浮動、再用實際佔用值逐層找大戶），見 macOS 磁碟空間診斷流程——那篇的佔用大戶表也會把 ollama 列為其中一項、再連回本篇的專屬清理 idiom。

觀察累積

 1# Ollama models 總占用
 2du -sh ~/.ollama/models/blobs
 3# 4.1G    /Users/tarragon/.ollama/models/blobs
 4
 5# 逐 model 看大小
 6ollama list
 7# NAME                       ID              SIZE      MODIFIED
 8# gemma4:e4b                 c6eb396dbd59    9.6 GB    Less than a second ago
 9# nomic-embed-text:latest    0a109f422b47    274 MB    3 hours ago
10
11# ComfyUI checkpoints 累積
12du -sh ~/.ollama ~/Projects/ComfyUI/models 2>/dev/null
13# 4.2G    /Users/tarragon/.ollama
14# 7.0G    /Users/tarragon/Projects/ComfyUI/models

清理策略

 1# 刪掉很久沒用的 model
 2ollama rm 
 3
 4# 一次清掉所有 Ollama models（保留 daemon）
 5ollama list | tail -n +2 | awk '{print $1}' | xargs -I {} ollama rm {}
 6
 7# 看 ComfyUI checkpoints 哪些可清
 8ls -lh ~/Projects/ComfyUI/models/checkpoints/
 9
10# 手動刪不要的 .safetensors（小心、不能 undo）
11rm ~/Projects/ComfyUI/models/checkpoints/.safetensors

磁碟管理 idiom

定期（每月或磁碟剩 < 20% 時）做：

du -sh ~/.ollama ~/Projects/ComfyUI/models 看當前累積
ollama list 看哪些 model 沒在用（看 MODIFIED 欄、太舊的考慮刪）
刪實驗用的 model、保留 daily-driver
ComfyUI checkpoints 同樣 review

Port / Process 排錯

啟動報「address already in use」

 1# 找誰占
 2lsof -i :11434
 3# COMMAND  PID  USER   ...   NAME
 4# ollama   xxx  ...    ...   TCP localhost:11434 (LISTEN)
 5
 6# 看是不是 zombie process
 7ps aux | grep $(lsof -ti :11434 | head -1)
 8
 9# 清掉
10kill -9 $(lsof -ti :11434)
11
12# 或重啟 service（會自動清舊 instance）
13brew services restart ollama

Ollama daemon 掛了不知道

 1# 健康檢查
 2curl -s http://localhost:11434/api/version
 3
 4# 沒回應、看 service 狀態
 5brew services list | grep ollama
 6
 7# 沒在跑、重啟
 8brew services start ollama
 9
10# 看 log
11tail -50 /opt/homebrew/var/log/ollama.log

ComfyUI 看似跑著但 Queue 不動

1# 看 stdout / stderr log
2tail -30 /tmp/comfyui.log  # 如果啟動時 redirect 到 log
3
4# 看是不是 GPU / Metal stuck（極少見、但 SDXL 大量並發可能踩到）
5# 解法：kill + 重啟
6pkill -9 -f "ComfyUI/main.py"

完整排錯流程跟「先確認哪一層壞」見 1.7 排錯方法論。

觀察記憶體佔用：實測對照

跑這幾步紀錄 baseline → load model → kill 的 RAM 變化：

 1# Baseline
 2vm_stat | grep "Pages free"
 3# Pages free:                              1090076.   ← ~17 GB free
 4
 5# 啟動 Ollama + load 4B model
 6brew services start ollama
 7ollama run gemma3:4b "hello"
 8ollama ps
 9# NAME       SIZE     PROCESSOR    UNTIL
10# gemma3:4b  5.5 GB   100% Metal   4 minutes from now
11
12vm_stat | grep "Pages free"
13# Pages free:                               750000.   ← 跌 ~5 GB（model 載入）
14
15# 額外啟動 ComfyUI + load SDXL
16nohup python main.py > /tmp/comfyui.log 2>&1 &
17# 在 GUI 上 Queue Prompt 跑一次 SDXL generation
18vm_stat | grep "Pages free"
19# Pages free:                               280000.   ← 再跌 ~7.5 GB（SDXL 載入 + Python venv）
20
21# kill 全部
22brew services stop ollama
23pkill -9 -f "ComfyUI/main.py"
24sleep 3
25vm_stat | grep "Pages free"
26# Pages free:                              1090000.   ← 回到 baseline

每 page 16 KB、所以 free pages 數字 × 16 KB = 實際 free RAM bytes。

自動化釋放：launchd / shell alias

寫個 shell function 一鍵 cleanup：

 1# 加進 ~/.zshrc
 2llm-cleanup() {
 3  echo "[*] Stopping Ollama..."
 4  brew services stop ollama 2>/dev/null
 5
 6  echo "[*] Killing ComfyUI..."
 7  pkill -INT -f "ComfyUI/main.py" 2>/dev/null
 8  sleep 3
 9  pkill -KILL -f "ComfyUI/main.py" 2>/dev/null
10
11  echo "[*] Killing other model servers..."
12  pkill -KILL -f "llama-server" 2>/dev/null
13  pkill -KILL -f "lm-studio-server" 2>/dev/null
14
15  echo "[*] Verifying ports..."
16  for p in 11434 1234 8080 8188 8000; do
17    lsof -i :$p 2>/dev/null | head -2
18  done
19
20  echo "[*] Free RAM:"
21  vm_stat | grep "Pages free"
22}

完事打 llm-cleanup 一鍵釋放、不用記每個 process 怎麼 kill。

何時這篇會過時

不會過時的部分：

RAM / 磁碟 / port 三個 dimension 是長期 invariant、用什麼 LLM server 都成立。
「Mac 是 shared resource、需要主動管理」這個 framing。
Ollama 跟 ComfyUI 兩種典型 lifecycle 對比（auto-unload vs persistent）。
觀察工具（vm_stat、lsof、ps、du、Activity Monitor）是 macOS 系統 API、不會 deprecate。
標準釋放程序、自動化 shell function 模式。

會變的部分：

具體 model size / RAM 占用數字（隨模型架構演化）。
OLLAMA_KEEP_ALIVE 等具體環境變數名（Ollama API 演化）。
ComfyUI 可能加 auto-unload feature（社群有 issue 在討論）。

讀的時候若指令跑不過、先 --help 看當前版本 flag；釋放 RAM 的「kill process」這個機制本身永遠成立。

跟其他 hands-on 章節的關係

Ollama 安裝：介紹 brew services start/stop、本篇延伸 lifecycle 細節
ComfyUI 安裝：介紹 ComfyUI 啟動、本篇延伸 RAM 占用 + 釋放
1.7 排錯方法論：用三層架構定位故障、本篇是 lifecycle 視角的補完
0.7 隱私資料流原理：「每個 hop 都要 audit」延伸到資源層

整體心法：本地 LLM 工作流跟雲端不一樣、要主動管理 lifecycle、不能裝完就忘。

Hands-on：本地 AI 工具實作筆記

Mon, 11 May 2026 00:00:00 +0000

本子資料夾收錄本地 AI 工具的實際安裝跟驗證紀錄。跟 1.x 原理章節的關係：

1.x 原理章節	Hands-on 紀錄
為什麼選 Ollama	實際 `brew install` + `ollama pull` 流程
Speculative decoding 原理	MTP 模型實際載入 + 速度量測
ComfyUI 在生態的位置	實際 git clone + Python 環境 + 模型路徑配置

本資料夾的內容會隨工具版本演化：指令、目錄結構、相依套件版本都會變。寫的時間戳記在每篇開頭、版本資訊在 frontmatter。跟 1.x 原理章節的差別是「原理跨工具世代不變、實作筆記是當下這版的快照」。

章節列表

章節	主題
Quickstart：clone repo 後跑通所有 demo	4 步驟整合 setup、跑 RAG / MCP / permission demo、跨 hands-on 系列導讀
Ollama 安裝 + Gemma 模型	brew install、ollama pull、curl 驗證
ComfyUI + Stable Diffusion XL	git clone、Python 環境、SDXL 模型放哪
Whisper 語音轉文字	`brew install whisper-cpp` + Metal 加速、GGML 模型選擇、`whisper-cli` + ffmpeg 驗證轉錄
Piper TTS 文字轉語音	下載 binary、voice 選擇、wav 輸出
RAG demo：用 blog content 當 corpus	embedding + retrieval、串 Ollama
MCP server demo：暴露 blog content	最小 MCP server、給 LLM 用
權限邊界實驗：LLM 改檔案 / 寫 shell 誰執行	LLM 是 pure function、wrapper 才是權限 gate、`--dry-run` / `--confirm` / `--auto` 取捨
跨資料夾風格 follow 任務的 model size 對比	1B vs 4B 在「讀資料夾、follow 既有格式、寫新章節」任務上的 structural metrics phase transition
LLM 運行中 + 結束的資源管理	RAM / 磁碟 / port 三 dimension 觀察、Ollama auto-unload vs ComfyUI persistent lifecycle、實測釋放數字、自動化 cleanup shell function
RAG / MCP 的資源 footprint	RAG ingest / query / MCP server 三階段 RAM / 磁碟 / process 實測、多模型並存 RAM 衝突、長期累積管理

通用前置

所有工具都假設你的 Mac 滿足：

Apple Silicon Mac（M1 / M2 / M3 / M4）
macOS 14 (Sonoma) 或以上
Homebrew 安裝完成（brew --version 可看版本）
至少 16 GB 統一記憶體（24 GB+ 較順）
至少 20 GB 可用磁碟空間（本系列總共會佔約 15 GB）

需要 Python 環境的工具（ComfyUI、Whisper）會用 venv 隔離、不污染系統 Python。

驗證紀錄環境

本系列的指令在以下環境驗證：

項目	版本
macOS	Darwin 24.3.0（Sonoma 14.x）
Homebrew	由 `/opt/homebrew/bin/brew` 提供
Python	3.x（系統或 pyenv 都可）
驗證日期	2026-05-11

換 Mac 規格、換 macOS 版本、半年後再讀本系列、指令可能要小調整、但前置設定的種類跟驗證步驟的結構通常不變。看到指令跑不過時、回 1.7 排錯方法論的三層架構定位、不要把錯誤訊息當絕對。

Comfyui on Tarragon

Hands-on：安裝 ComfyUI + SDXL base

前置設定

Clone ComfyUI

建 venv + 裝 dependencies

下載 SDXL base 模型

啟動 ComfyUI Server

跑第一張圖

用 REST API 直接生成（不開瀏覽器）

ComfyUI 的 REST API 形狀（無 OpenAI 相容層）

常用 Custom Nodes

常見坑

Python 版本太新、torch 沒 wheel

mps: False、跑在 CPU 上

記憶體不夠、推論時 crash

Workflow JSON 載入失敗

Port 8188 被佔

跟 LLM stack 並存

何時這篇會過時

Hands-on：LLM 運行中 + 結束的資源管理

為什麼這事重要

三個 dimension + 觀察工具

Ollama 的 lifecycle（auto-unload 模式）

ComfyUI 的 lifecycle（持續占用模式）

為什麼 Ollama 跟 ComfyUI 設計不同

跟其他本地 server 對比

標準釋放程序

容易出錯的「釋放方式」

磁碟長期累積管理

觀察累積

清理策略

磁碟管理 idiom

Port / Process 排錯

啟動報「address already in use」

Ollama daemon 掛了不知道

ComfyUI 看似跑著但 Queue 不動

觀察記憶體佔用：實測對照

自動化釋放：launchd / shell alias

何時這篇會過時

跟其他 hands-on 章節的關係

Hands-on：本地 AI 工具實作筆記

章節列表

通用前置

驗證紀錄環境

`mps: False`、跑在 CPU 上