手動跑得通，只證明了你這臺電腦：Comfy API 上線前的五張檢查清單

把生圖工作流從個人畫布搬上程式可呼叫的服務，中間隔著環境打包、提交格式、金鑰與資料、輸入上限、費用與授權五道關卡；本文用劇場比喻說明 Build 到 Deployment 的運作，並整理上線前可以照著走的驗證順序。

深夜的個人電腦前，ComfyUI 的節點畫布上按下執行鍵，幾十秒後一張修好的商品照出爐。這套流程跑了幾個月，穩定到每個節點的位置都背得起來。接下來的念頭也很自然：把它接到公司網站，讓使用者上傳圖片，伺服器自動出圖。

Comfy API 正是為這一步設計的服務：把 ComfyUI 工作流連同執行環境，部署成應用程式可呼叫的網址。但真的動手的人，常撞上同一堵牆。同一份工作流，在自己電腦生得出圖，送進部署環境，直接報錯。缺節點、缺模型、格式不對，三種原因涵蓋大多數案例。手動跑通和能夠上線之間，隔著五項檢查。

先把 Comfy API 講成一句話

它做的事，是把「人在畫布上操作」翻成「程式送請求、追蹤工作、取回結果」。呼叫端先整理使用者輸入，轉成工作流接受的參數；送出後記住工作 ID，等狀態變成完成，再讀取輸出。官方提供 Python 與 TypeScript 的 SDK，走 HTTP 也能串接。

這種人定義流程、程式執行並回報的分工，也出現在其他工程現場，晶片設計領域的工程師下目標、模型操作 EDA 工具合作走的是同一個方向。差別在於 Comfy API 要求你自己把整個環境打包帶走，這也是五項檢查的由來。

從排練場到劇場：服務怎麼運作

用劇場來想最容易。Build 是打包：這齣戲需要的劇本、道具、演員與燈光設定全部裝箱，對應到 ComfyUI 版本、自訂節點、模型檔與 Python 依賴，貼上版本標籤。Release 是蓋章：宣告某一箱可以上演，成為準備部署的版本。Deployment 是開演：選定劇場，也就是 GPU 規格與區域，讓那一箱實際運作，對外掛出服務網址。

兩個名詞要分清。端點是應用程式送請求的地址，工作者是實際接工作的 GPU 執行單位；能同時開多少工作者，決定同一時間消化得了多少請求。部署設定和呼叫端的程式介面也是兩回事，前者決定工作在哪裡跑，後者決定參數怎麼送、狀態怎麼等、結果怎麼拿。兩邊各有負責人，上線才不會變成沒人管的事。

一個容易被忽略的細節：建立新的 Release，並不會自動替換正在服務的舊端點。這個設計讓版本能退回，也常造成誤解，以為改完工作流、發了新版，線上就自動更新，使用者拿到的其實還是舊結果。更新通道出事的代價，家電圈有現成例子：三星冰箱曾因誤收內部測試版更新而停擺，機器停止製冷、門打不開，囤放的食材整批報廢。版本替換慢一拍、明確一點，多數時候是保險。

本機跑通只證明了一件事

證明你這臺電腦的環境能跑，僅此而已。自訂節點裝在哪個資料夾、模型檔放在哪顆硬碟、Python 套件是哪個版本，這些資訊不會跟著工作流的 JSON 一起離開你的電腦。部署環境少了其中一樣，輕則工作流載入失敗，重則跑到一半斷在使用者眼前。

所以第一項檢查是依賴盤點：把自訂節點、模型檔、LoRA、Python 套件與 ComfyUI 版本全數列出，逐一確認納入 Build。官方文件說明 Build 會收錄相關模型、節點與依賴，但實際用了哪些只有團隊自己知道，不能假設檔案會自動搬過去。要更新時，順序是記下改了什麼、建新的 Build、再發布，直接改動線上環境是大忌。

另外四項檢查，各自卡在哪

第二項是提交格式。畫布上儲存的 JSON 給人看、給介面載入；API 要的是另一種匯出格式，欄位結構不同，要用 API 格式重新匯出。同時要定義哪些欄位對外開放，例如提示詞、尺寸、輸入圖片，以及結果怎麼取回。程式端若假設回傳永遠只有一張圖，工作流改版後多出遮罩或多張輸出，下遊流程就跟著出錯。手動操作時人多看一眼就發現的差異，程式不會自己發現。

第三項是金鑰與資料。API 金鑰放在伺服器端的安全設定裡，不寫進公開的前端程式碼，也不交給終端使用者。資料面要核對儲存政策：Comfy 官方支援文件目前說明，輸入與輸出會在伺服器保留 24 小時，之後刪除。團隊要依自己處理的資料敏感度，判斷這個期限符不符合內部政策，並決定產物要不要搬到自有儲存。網站若要讓使用者長期下載圖片，也得自己存一份，短效下載連結不能當永久網址用。

第四項是輸入檢查。圖片格式與檔案大小、尺寸上限、批次數量、提示詞長度，全部要在程式端設界。這些在手動時代靠人眼與常識把關，上線後都成了必須寫成規則的界線；漏了一條，一張超大的 HEIC 檔就能讓工作掛掉，錯誤訊息還未必看得懂。

第五項是費用與授權。GPU 規格與區域在部署時決定，工作者是計費單位，開著就計費，要開多少得設計。商用之前另要核對模型與節點的授權條件、使用限制與輸出權利：能下載、能載入、能拿輸出營利，在授權條款裡常常是分開答覆的三件事。

三個名字，三種需求

Comfy 生態有三個容易混淆的名字：ComfyUI 桌面與本機環境，偏向自己創作與執行；Comfy Cloud，在瀏覽器裡操作 ComfyUI；Comfy API，把工作流變成程式可呼叫的端點。評估的第一步是確認需求落在哪一層。若只是要呼叫一個託管模型生圖，用不到自訂節點與多步流程，直接模型 API 可能更省事，不必為用不到的工作流管理多背維運負擔。

上線前的驗證順序

五項檢查可以收斂成一個原則：部署這件事，比匯入一份 JSON 多得多，它把一個人的創作環境，翻成一個團隊可維運的服務。環境要能重建，欄位要有契約，金鑰與資料要有界線，輸入要有規則，費用與授權要有帳，每項檢查最好都掛一個負責的人，出事才知道找誰。

實際順序：先在新的 Build 上用代表性輸入跑一輪測試，包含刻意送進會出錯的輸入，確認結果與錯誤處理都符合預期；然後開 Release、選 GPU 與區域上線。上線後盯兩個訊號，工作失敗率與每件產出的 GPU 成本。前者反映環境或輸入檢查有沒有漏，後者決定這個服務能不能長期經營。

資料來源：本站編輯參考 APPI News〈Comfy API 部署前必查的 5 個工作流條件〉（作者：張饒輝 Lightman Chang）改寫而成，原文出處；原文文字內容採 CC BY 4.0 授權。