12B 參數是官方 FLUX.1 schnell 模型卡列出的模型規模，而且該模型卡標示 Schnell 可採用 1–4 步推理；這已足以說明，Flux.1 Mac 本地部署不能只看某張圖片花了幾秒。若本週要作選擇：單人創作、快速安裝和較低維護成本，先選 Draw Things；複雜節點、批量自動化或可重複的生產流程，選 ComfyUI。低記憶體 Mac 則先用同一檢查點完成穩定性試跑，再決定是否改用雲端 Mac 算力。FLUX.1 schnell 官方模型卡
這篇適合使用入門級或較低統一記憶體 Mac、想確認 Flux.1 能否穩定出圖的個人創作者；也適合要在兩種 UI 之間選擇生產工具的設計師與工作室。若您負責批量出圖、設備採購或臨時擴充算力，文中的條件分支可用來估算本機、升級與租用方案。
最後更新於 2026 年 8 月 29 日；模型與授權狀態核實自 FLUX.1 dev 官方模型倉庫、ComfyUI Flux 範例文件 及 Draw Things 公開倉庫。
先按創作任務選 UI，而不是先比一張圖
Draw Things 的優勢在於把模型匯入、參數調整和生成介面整合在同一個軟體中。對個人創作者而言，從下載檢查點到首次出圖的路徑較短，也不必先理解 Python 環境、節點依賴和工作流檔案。這不代表它在每一個 Flux.1 組合上都較快，而是少了一層環境配置和維護工作。
ComfyUI 的價值則不只在採樣時間。當流程需要局部重繪、結構控制、多模型串聯、LoRA 呼叫或批量後處理，節點圖可以把每一個步驟固定下來，方便複製、修改和交接。對工作室而言，流程可重用性往往比單張圖的幾秒差距更能影響每日產量。
我們建議用以下條件作第一輪評分：
- 快速安裝、提示詞迭代、單張交付：Draw Things 優先。
- 節點控制、模型串聯、批量工作流：ComfyUI 優先。
- 只是想知道哪個較快：先不要下結論，必須固定 Flux.1 分支、檢查點、量化等級、解析度、步數、隨機種子和 Mac 配置。
- 需要團隊交接或長期維護：把工作流版本、節點來源和失敗重跑成本納入評分。
實際比較時，至少分開記錄冷啟動、首次出圖、預熱後連續出圖和峰值記憶體。只截取預熱完成後的一次生成時間，會把模型載入、文字編碼器初始化和 VAE 解碼的成本藏起來。
低統一記憶體 Mac 應先控制交換記憶體
Apple Silicon 的統一記憶體由 CPU 和 GPU 共用；Apple 對 hasUnifiedMemory 的說明可用來確認 Metal 裝置是否採用這種架構，而不是把它當成一塊獨立的顯示卡記憶體。Apple Metal 統一記憶體說明 因此，Flux.1 載入模型時，模型權重、文字編碼、採樣中間資料和 VAE 解碼會競爭同一個記憶體池。
這裡有三個容易被忽略的限制。
第一，模型能夠「載入」不等於可以穩定完成出圖。系統可能先把部分資料放入交換記憶體，結果是滑鼠延遲、其他應用程式卡頓，甚至在解碼階段退出。第二，ComfyUI 的 Python 環境、節點和額外模型元件會增加管理複雜度；節點圖越長，越需要確認哪些元件仍留在記憶體中。第三，Draw Things 雖然減少了環境設定，但原生整合不會突破 Apple Silicon 的實際記憶體上限。
Flux.1 Schnell 官方模型卡列出 12B 模型規模，並以 1–4 步作為其快速推理定位；這些是模型層面的資料，不是任何 Mac 都能達到的速度保證。FLUX.1 dev 同樣是獨立的模型分支，且其官方倉庫的授權條件與 Schnell 不應混用，商業工作流在部署前必須重新核對。FLUX.1 dev 官方資料
低記憶體設備的試跑順序應該是：
- 先關閉會大量佔用記憶體的影片、瀏覽器分頁和其他 AI 工具。
- 明確記錄 Mac 晶片、統一記憶體、macOS、UI 版本及模型檔案來源。
- 先匯入 Schnell 或明確適配的量化檢查點，不要一開始就把 Dev、LoRA 和高解析度放在同一流程。
- 固定提示詞、隨機種子、解析度、步數和批次設定，完成一次冷啟動及數次連續生成。
- 觀察系統活動監視器中的記憶體壓力與交換記憶體，而不只看生成畫面是否出現。
- 若持續交換、應用程式退出或系統失去回應，停止增加解析度和模型元件，回退到較輕量配置。
- 只有在 Schnell 穩定後，才評估 Dev 或更複雜的 ComfyUI 工作流。
社群 Issue 可用來發現相容性線索，例如 Draw Things 社群對 Flux.1 的討論，但個案不能取代同機測試，也不能被當成所有 Apple Silicon Mac 的官方效能結論。
單圖創作的成本在操作鏈路
個人創作者每天反覆修改提示詞、種子、採樣參數和 LoRA；所以真正要比較的不是只有每張圖的採樣時間，還包括「修改一次並重新出圖」需要多少人工操作。Draw Things 通常較適合作為低維護入口：模型匯入後，創作者可以直接在同一介面管理常用參數、查看歷史結果，再逐輪調整提示詞。
這種便利對快速提案、概念草圖和單張交付尤其重要。若每輪只改一個提示詞，節點圖的可視化控制未必能抵銷載入環境、整理節點和處理錯誤的時間。對尚未固定工作流的使用者而言，先用 Draw Things 建立可接受的提示詞和參數範本，往往比一開始學習完整節點生態更容易恢復工作。
但若創作流程已經包含多個 LoRA、不同文字編碼器、影像輸入和後處理，ComfyUI 的初期學習成本可能換來更低的重複操作量。此時應把每輪人工調整、失敗後重建和結果命名一併計算；否則很容易因為介面熟悉度而誤判工具效率。
複雜控制應把流程複用列為主要指標
當任務轉向局部重繪、姿態或結構控制、多模型串聯，以及固定格式的批量後處理，ComfyUI 的節點圖更適合建立可視化管線。節點輸入輸出清楚後，工作室可以保留一份範本，讓不同成員只修改提示詞、輸入影像或指定參數，而不必重新描述整個流程。
不過，節點生態也帶來三項成本：
- 原生節點通常較容易追蹤，但功能未必涵蓋所有工作流。
- 第三方節點可補足控制、載入或後處理功能，卻可能因版本、依賴和 Metal 行為不同而失效。
- 社群補丁或優化聲明只能視為待驗證線索；ComfyUI 官方 Flux 範例可作為起點，但不能直接推導出每部 Mac 的記憶體和速度結果。ComfyUI 官方 Flux 範例
因此，複雜流程的評分應包含配置時間、節點更新後的排障時間、失敗重跑機率、輸出命名方式和交接難度。若一個流程每次更新都要重新安裝節點，單次採樣較快也不一定代表整體生產成本較低。
Flux.1 Mac 本地部署的決策條件
我們不建議在沒有同機基準資料時宣布 Draw Things 或 ComfyUI 是速度冠軍。尤其是 Schnell 與 Dev、官方權重與第三方 Q4 或 Q8 量化版本，不能混在同一組結論中。以下條件可以直接用來作選擇：
- 若主要工作是單張概念圖、提示詞試錯和快速交付，則選 Draw Things；否則回到下一項。
- 若需要局部重繪、多模型串聯、批量後處理或流程交接，則選 ComfyUI；否則優先採用維護成本較低的方案。
- 若冷啟動可以完成，但連續生成後交換記憶體持續增加，則先降低模型或解析度並停止擴展流程；否則才進入下一輪品質測試。
- 若Schnell 在固定條件下穩定，而 Dev 造成退出或長時間交換，則保留 Schnell 作本機工作流；否則不要以一次成功強行推論長時間穩定。
- 若任務有固定交付期限、等待隊列或批量需求，則把遠端 Mac 算力加入比較；若只是偶爾試作且本機穩定，則不必為單次需求立即採購硬體。
這份條件表的重點，是將「速度」放回任務脈絡：單人創作者看操作鏈路，工作室看流程複用，技術團隊則要看 API、CLI、工作流版本管理和任務並發。
從本機試用轉向批量生產
如果只是每週偶爾生成少量圖片，本機的優勢是檔案和提示詞不必離開工作環境，且不需要處理雲端連線與交付權限。若工作變成連續批量出圖，則要記錄任務持續時間、排隊等待、環境重建時間和失敗重跑次數；這些成本比一次記憶體不足更能決定是否需要擴容。
我們通常把方案分成三條路徑：
- 繼續本地運行：Schnell 或適配量化版本能穩定完成任務，交換記憶體沒有持續上升，且等待不影響交付。
- 升級 Mac：工作流已固定、使用頻率高，並且長期採購成本低於反覆租用與排障成本。
- 短期租用雲端 Mac 算力：只在活動、驗證、批量交付或臨時高峰使用，且需要先以可複現工作流驗證環境。
若目前方案是低記憶體本機加上不固定的第三方節點，常見缺點是交換記憶體拖慢整台 Mac、節點更新後需要重新排障，以及批量任務缺少可預測的交付時間；若改用一般遠端主機，還可能遇到 Metal 相容性、檔案傳輸和權限管理問題。這種情況下，JexMac 的雲端 Mac 租用更適合用作短期驗證或交付緩衝，但不應取代長期穩定重負載所需的本機規劃。可先參考 JexMac 的方案資訊，再按模型版本、任務量與使用週期填寫算力評估；需要確認環境操作方式時，也可查看 JexMac 使用說明。
常見問題
低記憶體 Mac 的穩定性判斷
Flux.1 能否在低記憶體 Mac 上穩定出圖，取決於模型分支、量化格式、解析度、步數和同時開啟的應用程式。先用 Schnell 或適配量化版本測試，並觀察交換記憶體與記憶體壓力；若持續卡頓或退出，應回退設定，而不是繼續追求完整 Dev 流程。
Draw Things 與 ComfyUI 的速度比較
Draw Things 與 ComfyUI 的速度不能用不同模型檔案或不同預熱狀態直接比較。冷啟動包含載入成本，連續生成則反映預熱後狀態；我們還要記錄峰值記憶體和失敗重跑。Draw Things 可能較省配置時間，ComfyUI 則可能在已固定的批量流程中更有效率。
Schnell 和 Dev 的選擇
Schnell 適合先驗證本機工作流和快速試跑，官方模型卡也將其定位為可用少量步數推理的版本；Dev 則必須獨立核對模型、授權與硬體壓力。不能以 Schnell 的成功結果保證 Dev 同樣穩定，也不能把第三方量化版本的表現套用到官方權重。
Apple Silicon 上的 ComfyUI 記憶體控制
在 Apple Silicon 上，應先移除未使用的第三方節點和模型元件，避免同時載入多個檢查點或高解析度後處理。每次只調整一個變數，並記錄交換記憶體、節點錯誤與重跑結果；社群優化聲明可以提供排查方向，卻不能代替同機驗證。
本機、升級與雲端算力
當任務頻率高、流程固定且需要長期離線使用，升級本機較容易控制總成本；當需求是短期批量、臨時交付或模型驗證，租用雲端 Mac 可避免立即採購。若本機只在偶發高峰失效，先比較等待時間、環境重建和租用週期，再決定是否擴充，通常比單看一次失敗更可靠。
常見問題
Flux.1 放在低記憶體 Mac 上可以穩定出圖嗎？
不能只按機型或記憶體容量下定論。請先固定相同檢查點、量化格式、解析度與步數，從 Schnell 或適配的量化版本開始；若系統持續使用交換記憶體、應用程式退出或整台 Mac 失去回應，就應停止滿規格本機測試，改評估升級或短期雲端算力。
Draw Things 和 ComfyUI 在 Mac 上哪一個生成較快？
沒有脫離測試條件的固定答案。Draw Things 可能因原生整合而減少環境準備時間，ComfyUI 則可能在已完成的流程中更適合批量執行；比較時至少要分開記錄冷啟動、首次出圖、預熱後連續出圖與峰值記憶體，不能拿單次截圖宣布速度冠軍。
Mac 執行 Flux.1 時，應該選 Schnell 還是 Dev？
若目標是低記憶體試跑、快速確認工作流或處理一般單圖任務，先選 Schnell 會較容易控制風險；若需要 Dev 的畫面控制或符合其授權條件的研究用途，才進一步核對模型需求與授權。兩者必須分開測試，不能把 Schnell 的結果套用到 Dev。
ComfyUI 在 Apple Silicon 上怎樣減少記憶體佔用？
先清理未使用的模型元件與第三方節點，避免同時載入多個檢查點、文字編碼器和高解析度流程；再以較保守的量化版本和較低解析度驗證穩定性。每次只改一項變數，並觀察交換記憶體、節點錯誤與重跑情況，否則很難判斷是 Metal、模型或節點造成壓力。
本地 Mac 跑不動 Flux.1，應該升級、租用還是改用遠端算力？
若任務是長期穩定、高頻率且不需要彈性，升級本機比較容易攤平環境維護成本；若只是活動、驗證或短期批量交付，租用雲端 Mac 通常更能避開一次性採購。當等待隊列、交換記憶體和環境重建已經影響交付，再把遠端算力納入方案，而不是只因一次失敗立即買新機。
Flux.1 本機效能不足？用 JexMac 彈性擴展 Mac 算力
以 JexMac 獨享實體 Mac mini M4 遠端執行 Flux.1 測試與創作，無需立即購置新硬體。