ComfyUI 性能優化顯存與多GPU的三檔調優路徑【免費下載鏈接】ComfyUIThe most powerful and modular diffusion model GUI, api and backend with a graph/nodes interface.項目地址: https://gitcode.com/GitHub_Trending/co/ComfyUI跑一個 2K 出圖工作流進度條卡住終端里刷著 VRAM 壓力告警這就是 ComfyUI 性能優化最典型的起點。多數性能問題可以歸到兩類一類是顯存緊張模型和中間張量互相擠兌觸發反復換入換出甚至 OOM另一類是算力沒喂飽GPU 利用率上不去出圖節奏被拖慢。這兩類問題的解法方向完全不同先把癥狀分清再動手比照著別人的參數表逐條照搬要有效得多。先跑一次基準再決定動哪個參數改參數之前我們建議先花十分鐘把當前狀態量化下來否則所有調優都無從驗證。用一條命令循環觀察顯存與利用率watch -n 1 nvidia-smi跑一次完整工作流重點看峰值顯存和 GPU 利用率兩組數字。如果顯存峰值貼著上限、利用率卻時高時低多半是顯存壓力問題優先處理 VRAM 狀態如果顯存只用了七八成、利用率卻穩定在 90% 以上說明瓶頸不在顯存應該往精度和注意力機制方向查。再看一眼啟動時的日志它會直接告訴你實際生效的 VRAM 模式python main.py 21 | grep -Ei vram|DynamicVRAM新版默認走動態 VRAM日志里會有對應的設備與緩存策略輸出。啟動參數按用途歸類別混著開啟動參數里最容易踩的坑是互斥參數疊加使用。ComfyUI 的 VRAM 模式參數--gpu-only、--highvram、--lowvram、--novram、--cpu同屬一個互斥組同時寫兩個只會取后者日志里未必有明顯提示同理--fp16-unet、--bf16-unet、--fp8_e4m3fn-unet也彼此排斥。按用途歸類之后參數組合就清晰了參數作用適用場景--reserve-vram GB給系統和桌面預留顯存顯存峰值貼近上限、偶發 OOM--vram-headroom GB為動態 VRAM 保留額外余量多開應用或跑長任務--fp16-unet/--fp16-vae降低推理精度換顯存16GB 以下顯存、顯存吃緊--use-quad-cross-attention等切換注意力后端長序列、高分辨率工作流--cache-none/--high-ram控制節點結果緩存策略頻繁換模型導致 RAM 吃緊幾個值得留意的細節--fp16-vae的說明里明確寫了可能產生黑圖出圖異常時先查這里--cpu-vae能把 VAE 解碼挪到 CPU適合采樣卡得住、解碼就爆顯存的尷尬場景注意力后端里--use-split-cross-attention、--use-quad-cross-attention在啟用 xformers 時會被忽略選之前先確認本機實際用的是哪種后端。這個參數組合在不同硬件上差異很大在 4090 上表現好的配置放到 3060 上未必成立實測優先。工作流層面的三個杠桿緩存、批次與拆分參數調完之后還有一層收益藏在工作流組織方式里。第一個杠桿是緩存策略。當前版本的節點結果默認走 RAM 壓力緩存長時間不重啟的服務會不斷積累緩存占著內存和顯存。頻繁切換模型、RAM 吃緊時加--cache-lru 64限定緩存條數或者直接用--cache-none讓每次運行都重新執行全部節點用重算換占用反過來機器內存充足、追求加載速度時--high-ram更合適。第二個杠桿是批次規模。大批量任務一次提交幾百張圖節點結果和中間張量會同時駐留緩存與顯存壓力都會顯著上升拆成每批 8 到 16 張排隊執行峰值占用明顯下降總耗時通常只多出一點排隊時間。第三個杠桿是長工作流拆分一條鏈路串幾十上百個節點的提示與其整體重跑不如在關鍵節點處斷開分階段出圖緩存命中率也會更穩定。多 GPUCFG 分片與多實例兩條路多卡場景下現在有兩條思路適用條件不同。第一條是新版內置的原生多 GPU 支持在工作流里掛上 MultiGPU 相關的 CFG Split 節點配合 GPU Options 節點設置各卡相對速度采樣階段的 CFG 工作單元會按速度比例拆到多張卡上并行計算負載均衡邏輯就寫在 comfy/multigpu.py 里同進程內完成不需要額外部署。第二條是多實例方案卡與卡之間要完全隔離、跑不同模型或不同用戶時更合適CUDA_VISIBLE_DEVICES0 python main.py --port 8188 CUDA_VISIBLE_DEVICES1 python main.py --port 8189或者只寫--cuda-device 0、--cuda-device 1也可以達到同樣效果。多個實例起來之后寫個簡單輪詢器把任務分發到不同端口參考 basic_api_example.py 的隊列接口即可for port in (8188, 8189): requests.post(fhttp://127.0.0.1:{port}/prompt, jsonprompt)說白了就是同進程分片和跨實例并行的取舍任務同質、追求單任務延遲選前者任務異構、追求吞吐選后者。收個尾把參數記成基線調完參數別急著宣布勝利把當前完整的啟動命令和一次出圖耗時記下來當基線之后每改一個參數就記一次結果兩周后回看才有數據可依。最后提醒一個最常見的坑動態 VRAM 是默認行為--lowvram在這種狀態下基本不生效顯存不夠時應該優先試--reserve-vram和--vram-headroom而不是往--lowvram上堆?！久赓M下載鏈接】ComfyUIThe most powerful and modular diffusion model GUI, api and backend with a graph/nodes interface.項目地址: https://gitcode.com/GitHub_Trending/co/ComfyUI創作聲明：本文部分內容由AI輔助生成（AIGC），僅供參考 ComfyUI 性能優化：顯存與多GPU的三檔調優路徑
ComfyUI 性能優化顯存與多GPU的三檔調優路徑【免費下載鏈接】ComfyUIThe most powerful and modular diffusion model GUI, api and backend with a graph/nodes interface.項目地址: https://gitcode.com/GitHub_Trending/co/ComfyUI跑一個 2K 出圖工作流進度條卡住終端里刷著 VRAM 壓力告警這就是 ComfyUI 性能優化最典型的起點。多數性能問題可以歸到兩類一類是顯存緊張模型和中間張量互相擠兌觸發反復換入換出甚至 OOM另一類是算力沒喂飽GPU 利用率上不去出圖節奏被拖慢。這兩類問題的解法方向完全不同先把癥狀分清再動手比照著別人的參數表逐條照搬要有效得多。先跑一次基準再決定動哪個參數改參數之前我們建議先花十分鐘把當前狀態量化下來否則所有調優都無從驗證。用一條命令循環觀察顯存與利用率watch -n 1 nvidia-smi跑一次完整工作流重點看峰值顯存和 GPU 利用率兩組數字。如果顯存峰值貼著上限、利用率卻時高時低多半是顯存壓力問題優先處理 VRAM 狀態如果顯存只用了七八成、利用率卻穩定在 90% 以上說明瓶頸不在顯存應該往精度和注意力機制方向查。再看一眼啟動時的日志它會直接告訴你實際生效的 VRAM 模式python main.py 21 | grep -Ei vram|DynamicVRAM新版默認走動態 VRAM日志里會有對應的設備與緩存策略輸出。啟動參數按用途歸類別混著開啟動參數里最容易踩的坑是互斥參數疊加使用。ComfyUI 的 VRAM 模式參數--gpu-only、--highvram、--lowvram、--novram、--cpu同屬一個互斥組同時寫兩個只會取后者日志里未必有明顯提示同理--fp16-unet、--bf16-unet、--fp8_e4m3fn-unet也彼此排斥。按用途歸類之后參數組合就清晰了參數作用適用場景--reserve-vram GB給系統和桌面預留顯存顯存峰值貼近上限、偶發 OOM--vram-headroom GB為動態 VRAM 保留額外余量多開應用或跑長任務--fp16-unet/--fp16-vae降低推理精度換顯存16GB 以下顯存、顯存吃緊--use-quad-cross-attention等切換注意力后端長序列、高分辨率工作流--cache-none/--high-ram控制節點結果緩存策略頻繁換模型導致 RAM 吃緊幾個值得留意的細節--fp16-vae的說明里明確寫了可能產生黑圖出圖異常時先查這里--cpu-vae能把 VAE 解碼挪到 CPU適合采樣卡得住、解碼就爆顯存的尷尬場景注意力后端里--use-split-cross-attention、--use-quad-cross-attention在啟用 xformers 時會被忽略選之前先確認本機實際用的是哪種后端。這個參數組合在不同硬件上差異很大在 4090 上表現好的配置放到 3060 上未必成立實測優先。工作流層面的三個杠桿緩存、批次與拆分參數調完之后還有一層收益藏在工作流組織方式里。第一個杠桿是緩存策略。當前版本的節點結果默認走 RAM 壓力緩存長時間不重啟的服務會不斷積累緩存占著內存和顯存。頻繁切換模型、RAM 吃緊時加--cache-lru 64限定緩存條數或者直接用--cache-none讓每次運行都重新執行全部節點用重算換占用反過來機器內存充足、追求加載速度時--high-ram更合適。第二個杠桿是批次規模。大批量任務一次提交幾百張圖節點結果和中間張量會同時駐留緩存與顯存壓力都會顯著上升拆成每批 8 到 16 張排隊執行峰值占用明顯下降總耗時通常只多出一點排隊時間。第三個杠桿是長工作流拆分一條鏈路串幾十上百個節點的提示與其整體重跑不如在關鍵節點處斷開分階段出圖緩存命中率也會更穩定。多 GPUCFG 分片與多實例兩條路多卡場景下現在有兩條思路適用條件不同。第一條是新版內置的原生多 GPU 支持在工作流里掛上 MultiGPU 相關的 CFG Split 節點配合 GPU Options 節點設置各卡相對速度采樣階段的 CFG 工作單元會按速度比例拆到多張卡上并行計算負載均衡邏輯就寫在 comfy/multigpu.py 里同進程內完成不需要額外部署。第二條是多實例方案卡與卡之間要完全隔離、跑不同模型或不同用戶時更合適CUDA_VISIBLE_DEVICES0 python main.py --port 8188 CUDA_VISIBLE_DEVICES1 python main.py --port 8189或者只寫--cuda-device 0、--cuda-device 1也可以達到同樣效果。多個實例起來之后寫個簡單輪詢器把任務分發到不同端口參考 basic_api_example.py 的隊列接口即可for port in (8188, 8189): requests.post(fhttp://127.0.0.1:{port}/prompt, jsonprompt)說白了就是同進程分片和跨實例并行的取舍任務同質、追求單任務延遲選前者任務異構、追求吞吐選后者。收個尾把參數記成基線調完參數別急著宣布勝利把當前完整的啟動命令和一次出圖耗時記下來當基線之后每改一個參數就記一次結果兩周后回看才有數據可依。最后提醒一個最常見的坑動態 VRAM 是默認行為--lowvram在這種狀態下基本不生效顯存不夠時應該優先試--reserve-vram和--vram-headroom而不是往--lowvram上堆?！久赓M下載鏈接】ComfyUIThe most powerful and modular diffusion model GUI, api and backend with a graph/nodes interface.項目地址: https://gitcode.com/GitHub_Trending/co/ComfyUI創作聲明：本文部分內容由AI輔助生成（AIGC），僅供參考