Qwen-Image-2.1 工作流程：節點鏈、旋鈕，以及自零日以來有何改變

你從這個頁面能得到的是Qwen-Image-2.1一張你可以從零重建、並如實複現的圖：節點鏈按載入器實際使用的名稱列出，決定輸出是否如你所求的那四、五個旋鈕，以及那兩個大家改了、卻不知道自己也改動了噪聲排程的設定。模型本身是廠商統一的文生圖與圖像編輯發布版本，於 2026 年 9 月 20 日以研究授權開源：視覺生成元件有 7B 參數、32 層單流 DiT、16 倍空間壓縮的 64 通道 RGBA VAE，編輯路徑上最多支援十張參考圖像。那個日期放在這裡，是為了告訴你正在接的是哪個檢查點，不是為了宣布什麼。圖才是主題，而這張圖有一段值得一讀的修訂歷史——在你相信別人截的圖之前，先讀一讀：今天出貨的模板並不是第零天出貨的那份模板，而其中四處差異，正是讀者最容易弄錯的地方。

這頁描述的是哪個圖表？

以下所有內容皆讀取自 ComfyUI 工作流程範本儲存庫 Comfy-Org/workflow_templates，版本為 2026 年 10 月 13 日當時的修訂，執行於 ComfyUI 穩定版 v0.39.0（發佈於 2026 年 10 月 5 日）。節點名稱是載入器在圖形中使用的顯示名稱；若某個節點在修訂版本之間新增或重新命名，則會標示日期。通往這些檔案的路徑，是 ComfyUI 自家針對 Qwen-Image-2.1 的教學頁面——其中有三個範本，而本頁先依循文字轉圖像的那一個，再加以變通。

這三個範本分別是Qwen-Image-2.1 Text to Image、Qwen-Image-2.1 Image Edit，以及Remove Background: Qwen-Image-2.1。最後一個並不是不同的圖：ComfyUI 的說明文件指出，它重複使用了影像編輯子圖，並搭配提示詞「Remove the background, and output a PNG image」。所以實際上只有兩個圖需要學習，而其中一個只是疊在另一個之上的提示詞範本。

節點鏈，依序

文字轉圖像範本是子圖——畫布上一個可摺疊的節點，具有十八個對外暴露的輸入——包住一條由十三個節點組成的鏈。在其內部，順序為：

• UNETLoader — 載入 qwen_image_2.1_int8_convrot.safetensors，並將權重 dtype 保留為 預設。這是擴散模型，而你在此選擇的檔案，是決定你的執行結果是否與他人一致的首要因素。

• Qwen Image 2.1 Cache — 位於載入器與取樣器之間。在目前的範本中，它並非可有可無，但可以略過，而且它最可能從你第一週下載的圖形中缺席。

• KSampler — 會從快取節點取得模型、從文字編碼器取得正向與負向條件，以及一個空的潛在空間。它在隨附範本中的小工具讀數為：seed 0、control fixed、steps 25、cfg 1、sampler euler、scheduler simple、denoise 1。

• EmptyLatentImage — 寬度與高度是由位於子圖外部的Resolution Selector節點連接輸入的，而其第三個輸入 batch size 預設為1。

• VAEDecode → SaveImageAdvanced — 解碼器將像素交給儲存節點，其檔名前綴為 Qwen_image_2.1，而輸出格式為 PNG、8 位元、sRGB。PNG 在此並非只是表面功夫：VAE 帶有四個通道，因此 8 位元 PNG 正是讓 Alpha 通道在寫入磁碟過程中保持存活的關鍵。

• CLIPLoader — 載入 qwen3vl_8b_int8_convrot.safetensors，並將類型設為 qwen_image。Qwen3-VL 8B 是文字編碼器，同時也是讀取你參考圖像的視覺塔。

• Text Encode Qwen Image 2.1（節點 ID TextEncodeQwenImage21）— 會對提示詞進行條件化。它接收 clip、提示詞、負向提示詞、選用的 VAE、一個 解析度整數，以及一組會自動增長的影像插槽，命名為 image_1 到 image_16。它會回傳三樣東西：正向條件、負向條件，以及一個潛在空間。那個潛在空間正是大家常忽略的部分 — 它是一個空白的潛在空間，尺寸對應第一張參考影像，而在文字轉影像的圖表中它並未被使用，因為空白潛在空間反而是來自解析度選擇器。

• VAELoader — qwen_image_2.1_vae_bf16.safetensors，同時供應解碼器與文字編碼器的參考影像路徑。

選用分支是最後一塊拼圖。第二個 CLIPLoader 會載入 qwen3.5_9b_qwen_image_2.1_pe_t2i.int8_convrot.safetensors，並將類型設為 stable_diffusion——而不是 qwen_image，這個差異是刻意為之的，因為這是文字生成檢查點，而非視覺編碼器。它會饋入 Generate Text 節點，其輸出會經過 Preview Any 送到取樣器的正向提示詞，並由 ComfySwitchNode 切換，接線至 refine_prompt 輸入。一個 Primitive String (Multiline) 節點存放改寫所遵循的系統提示詞，你可以檢視並編輯它。

算一算這條鏈，真正做事的只有六個節點：載入擴散模型、載入文字編碼器、載入 VAE、編碼提示詞、從空的潛在樣本取樣、解碼並儲存。範本裡其餘的一切都只是記憶體或便利性考量。

第零天圖表和這張圖表之間有什麼變化？

這是你從教學截圖複製工作流程之前，值得先了解的部分，因為 Qwen-Image-2.1 範本在首次推出後被修改了五次，而且這些修改並非表面修飾。

• 2026 年 9 月 20 日 — 第一個範本。提交 96309bd530，「新增 Qwen Image 2.1 範本」。文字生圖子圖中有七個節點：載入器、編碼器、空白潛在、取樣器、解碼器。CLIP 載入器設為 bfloat16 文字編碼器，qwen3vl_8b_bf16.safetensors — 那個 16.33 GB 的檔案。

• 2026年9月20日，同日晚些時候。 提交 371a7b7171 將該載入器切換為 qwen3vl_8b_int8_convrot.safetensors，這個 8.71 GB 的檔案，訊息為「Switch Qwen Image 2.1 CLIP to int8 convrot」。範本本身的註記將其標為「loaded by the templates, lower memory」。用早上那個檔案建立的工作流程，與用晚上那個檔案建立的工作流程，並不是同一個工作流程。

• 2026 年 9 月 25 日。這個 Qwen Image 2.1 Cache 節點首次出現在圖形中，連同整個提示增強分支——第二個 CLIP 載入器、Generate Text、Preview Any、切換開關、系統提示詞節點。在此日期之前，沒有可設定的快取節點，也沒有可關閉的重寫步驟。影像編輯範本在同一天新增了對應的輸入。文字轉影像備註在此修訂版本中也新增了 4 百萬像素這一行，以及透明影像提示詞包裝器。

• 2026年9月28日。檔案大小已新增至下載備註中——這是文件變更，而非圖表變更，但讀者用來與其下載管理員核對的數字正是出自這裡。

• 2026年9月30日。提交 9fae1041be，「Qwen Image 2.1：更新 PE 設定」——這是兩個 2.1 範本最後一次被更動的時間。這一個最為關鍵，卻也最不顯眼。Generate Text 節點上有三個值被改動：權杖預算 max_length從 16256 下調至 4096、重複懲罰從 1.05 改為 1.0，以及 thinking從關閉改為開啟，而該節點自身的註記如今寫著這個檢查點「是以推理區塊訓練的，少了它就會降低品質」。範本註記將較早的數值描述為官方數值，並說明這個上限的存在是為了讓「單次改寫不會跑上好幾分鐘」。

改變的沒有部分，才是這件事中有用的那一半。取樣區塊在零日範本與今天的版本之間是位元組完全相同的：steps 25、cfg 1、euler、simple、denoise 1、seed 控制固定，解析度選擇器輸出端的空 latent，批次大小 1。這張圖從來不是靠移動取樣器來修正的。它是靠改為載入不同的文字編碼器檔案、加入快取節點，以及修正提示增強器本身的設定來修正的。

圖底下還有一層。範本定案之後，ComfyUI 的核心仍持續變動：9 月 29 日的 v0.38.0 改進了 Qwen 2.1 KV 快取位置邏輯，而 10 月 5 日的 v0.39.0 推出了「修正 qwen image 2.1 中選取 int8 或 int4 快取時崩潰的問題」。如果你的圖是今天的，而你的建置版本比那還舊，快取下拉選單就不是慢速選項，而是崩潰。

讀者最可能弄錯的轉盤

從文件明確陳述的內容開始，因為這樣能省去大部分的猜測。三個 Qwen-Image-2.1 工作流程全都以steps 25、cfg 1、euler 取樣器和 simple 排程器進行取樣。這是 ComfyUI 自家的摘要，而且與隨附的 widget 完全吻合。

麻煩之處在於，25 和 40 都是不同問題的正確答案。廠商自家的模型卡執行 diffusers 管線時採用 num_inference_steps=40，而 diffusers 管線的預設值也是 40；ComfyUI 的文件表示，發佈的管線「搭配 euler 取樣器約使用 40 到 50 步，而範本從較低的 25 開始」。這兩個數字都不是錯誤。它們分別是圖形預設值與參考執行。

• 步數 — 方向與取捨。步數較低會更快，而且根據 ComfyUI 的文件，效果會因工作類型而異：簡單的局部編輯在 4 到 8 步時仍能維持，而「改寫整個畫面的編輯會失去連貫性，需要完整的 25 步」。像手和手指這類頑固的精細細節「大約到 30 步才會穩定」，而從 25 提高到 40 可減少細節區域的雜訊。方向是單調的，取捨則是線性的：文件的建議是，只有在某個具體問題無法解決時才調整步數，而不是為了保險起見而提高步數。

• 指引 — cfg 1 代表關閉引導，而那是官方發佈的路徑。 在 cfg 1 時，ComfyUI 會跳過負向條件處理階段，因此負向提示詞不會有任何效果。範本保留 cfg 1，「也就是 Qwen-Image-2.1 發佈時所採用的路徑」；diffusers 管線以自己的說法表達同一件事，將 true_cfg_scale 預設為 1.0，因為「Qwen-Image 2.1 本來就是在不使用引導的情況下取樣」。只有在你確實想讓負向提示詞發揮作用時才提高它，並且要清楚代價：cfg 2 會更貼近密集提示詞，包括小字與數字，「代價是邊緣過度銳化」；更高的數值會使曝光偏向過亮或過暗；cfg 5 會嚴重降低品質；cfg 0.5 會讓影像崩壞。ComfyUI 的指示是一次只更改一個數值，並在固定種子下進行比較。

• 解析度是百萬像素目標，不是一個矩形。 解析度選擇器節點會設定長寬比與百萬像素預算，其中 1.0 MP 約為 1024x1024。Qwen-Image-2.1 原生以 2K 生成，因此 2048x2048 正方形的目標約為 4.0 MP。模型要的是 32 的倍數——文字編碼器resolution 輸入上的工具提示指出，參考會調整為約 resolution x resolution 像素、以 32 的倍數為單位，並保持長寬比，而管線本身的尺寸輔助工具也會四捨五入至 32。廠商的模型卡公布了 2K 預設值：1:1 為 2048x2048、4:3 為 2400x1792、3:4 為 1792x2400、3:2 為 2528x1696、2:3 為 1696x2528、16:9 為 2752x1536、9:16 為 1536x2752。

• 超出 2K 會犧牲遵循度，而非銳利度。遠高於模型訓練時 2K 尺寸的目標（例如 4K）會失去提示遵循度。這是已有記載的行為，而非從架構推斷而來。

• 真正反直覺的一點：解析度也會改變噪聲排程。Qwen-Image-2.1 使用流速匹配的 Euler 排程器取樣，其時間步位移是動態的，而管線會根據潛在序列的長度——也就是你所選解析度產生多少個 token——來計算這個位移。檢查點的排程器設定在 256 到 8192 的影像序列範圍內，將 base_shift 設為 0.5、max_shift 設為 0.9，而管線每次呼叫都會把你這次執行的序列長度餵進該公式。因此，改變畫布會改變取樣器的排程，而不只是畫面。在 ComfyUI 範本中沒有可設定的位移控制項——KSampler 的輸入是 model、positive、negative、latent image、seed、steps、cfg、sampler name 和 scheduler，這就是完整清單。如果你在 4 MP 的結果看起來與 1 MP 的結果不同，而且你無法單用細節多寡來解釋，原因就在這裡。

• 在編輯圖（graph）上，解析度的行為不同，而且是最昂貴的預設值。當custom_size 關閉時——也就是範本預設值——編輯會以第一張參考影像的尺寸產生。resolution 設為 0 時，每張參考影像會維持自身的像素尺寸並四捨五入為 32 的倍數，因此一張 3000x4000 的照片會產生 3008x4000 的畫布。若值大於 0，則會改為將該影像的長寬比縮放至 resolution x resolution 像素的預算——這是總像素數，而不是寬度。ComfyUI 自家的成本範例，在 RTX 5090 上測得：3000x4000 的參考影像在 resolution 為 0 時，每次迭代約需 6 秒；同樣的編輯在 resolution 為 1024 時，每次迭代約需 0.3 秒，尺寸大約是 896x1184。把custom_size 開啟，並從 Resolution Selector 取得畫布，且讓它接近調整尺寸後的第一張影像大小，「否則編輯可能會偏移」。

確定性：種子固定了什麼，以及它沒有固定什麼

固定種子是必要但不充分的，而隨附範本彼此對此的做法並不一致。文生圖的 KSampler 隨附的控制選項是 固定；兩個編輯範本——影像編輯與背景移除——隨附的控制選項則是 隨機。同樣的取樣器、同樣的預設值，重新排入佇列後的行為卻相反。

假設種子已固定。以下是仍會改變影像的因素：

• KV 快取。這是重頭戲，而且它有正式文件記載，而非道聽途說。Qwen-Image-2.1 會在第一步之後快取文字與參考影像的鍵和值；pipeline 原始碼說明這麼做是合理的，因為在該模型的因果調理（causal conditioning）之下，調理詞元與步數無關。接著它點出對任何想重現同一張圖的人來說最關鍵的事：切換該快取「在降低精度下無法逐位元重現同一張影像」，因為解碼步驟與預填充步驟所用的注意力序列版面不同，兩者切分方式不同、落在不同的捨入結果上——而第一個區塊的一個 ULP 差異會被 32 個區塊以及每個取樣器步驟放大，所以「這兩種設定會產生同樣有效但肉眼可見不同的樣本」。原始碼本身的指示是：要固定某個樣本，就得固定這個旗標。在 ComfyUI 中，該旗標位於 Qwen Image 2.1 Cache 節點上，形式為 device（auto、gpu、cpu、off）與 dtype（default、int8、int4）。

• 快取節點自身的發布歷史。它在 2026 年 9 月 25 日之前並不存在，因此 day-zero 工作流程沒有這項設定，行為也不同於今日的版本。而關閉——唯一能排除快取的設定——「每一步都重新計算前綴，這比較慢，但這是排除快取的唯一方法」。

• 該用哪些模型檔案。此範本會載入一個 int8 擴散模型與一個 int8 文字編碼器。把其中任一個換成 bf16 檔案，運算方式就隨之改變。下載說明會同時列出兩者及其檔案大小，正是因為這個選擇確實會造成差異。

• 提示增強器，如果它是開啟的話。當 refine_prompt 開啟時，影像模型是從改寫後的提示進行取樣，而不是你輸入的那一個——而且改寫內容是由另一個Generate Text節點產生的，它有自己的取樣參數：temperature 1.0、top_k 20、top_p 0.95、自己的 seed 欄位，以及 max_length token 預算。你的 KSampler seed 完全涵蓋不到這些。Preview Any 子圖內的節點會顯示實際送達影像模型的提示，這是唯一能知道你剛剛重現了什麼的方法。

• ComfyUI 的建置版本。這些範本本身附有警告：載入工作流程時若缺少節點，通常表示目前的建置版本早於這些節點，而 Desktop 與 Cloud 會跟隨穩定版本，因此可能落後 nightly 版。

所以，重現別人的 Qwen-Image-2.1 圖像並不是換個種子就好。它涉及範本修訂版本、兩個模型檔案、解析度設定、steps、cfg、sampler、scheduler、快取裝置與 dtype、增強器的開／關狀態及其自身的種子——而且，就編輯圖而言，還包括第一張參考圖的尺寸。ComfyUI 並未針對這些工作流程發布任何種子可重現性保證，而 diffusers 原始碼也直白指出，切換快取會改變取樣結果；請把完全一致視為你刻意組裝出來的成果，而不是種子交到你手上的東西。

多於一張圖片，以及記憶的去處

在出貨預設配置下，這張圖形每次執行只會產生一張影像，而要改變這點的旋鈕並不光鮮：EmptyLatentImage 節點的第三個輸入，也就是批次大小，接線值為 1。調高它，正是讓取樣器從一次佇列中輸出多張影像的關鍵。

代價究竟是什麼，這正是得誠實面對的地方。範本會明確告訴你快取存放在哪裡——auto會使用閒置的 VRAM，接著再用系統 RAM；cpu會在運算背後進行預取，而文件將其描述為只損失少許速度；off會在每一步重新計算前綴，速度較慢。他們也量化了精度這一面：int8能將快取減半，且約維持 bf16 精度，而int4能將其縮減至四分之一，但會使每步誤差大約加倍。他們沒有公布的是批次大小對應 VRAM 的表格，ComfyUI 的文件也沒有。如果你是在為某張顯卡調整批次大小，誠實的答案是：沒有官方數據涵蓋這一點；有公開效果可循的調節槓桿是快取裝置與 dtype，以及解析度目標，因為它會同時提高潛在表示數量和快取前綴。

有兩個批次陷阱位在籬笆的另一側，也就是 diffusers pipeline 裡，而且兩者都值得了解，因為 ComfyUI 圖會把它們隱藏起來。在那裡，num_images_per_prompt 會讓批次倍增；如果你傳入一個產生器清單，其長度必須與有效批次大小完全一致，否則 pipeline 會拋出錯誤。而條件影像清單是「整批中每個提示詞共用同一組影像，而不是每個提示詞各有一筆項目」——你不能讓批次中的每個提示詞都有自己的參考影像；來源的指示是改為每個提示詞呼叫一次 pipeline。編輯子圖在不同位置也有相同形式的限制：它的 BatchImagesNode 會將最多十張參考影像批次送進文字編碼器，這是在批次處理輸入，而不是輸出。十張參考影像不會讓你得到十張圖片。

從同一圖形進行圖像到圖像

你不需為此使用不同的圖形。影像編輯模板就是文字生圖鏈，只是把空潛在換成文字編碼器的潛在輸出，兩個 LoadImage 節點會將 image_1 與 image_2 饋入子圖的參考插槽，並在最後加上一個 ImageCompare 節點，讓你可以將輸入與輸出並排檢視。將一張影像放入 image_1，讓 image_2 保持空白，寫下一段指令，那就是圖生圖：你的圖片是模型讀取的上下文，而不是它會部分去噪的起始潛在。這條路徑上沒有強度或去雜訊滑桿可設定，因為目標從雜訊開始，而你的參考則改由編碼器與 VAE 進入。

以下是兩者的界線，各用一句話說明，因為這兩者只差一次搜尋，而人們常會拿錯那一個。

• 以圖生圖是指當你想要一個變化版本時：你把一張圖片和一段描述交給模型，它就會在你選擇的畫布上，畫出一張與你的圖片相似的新圖片。

• 編輯是指當你想要進行變更時：你交給模型一張影像和一項指令，指出應該有哪些不同之處，並可選擇提供遮罩或塗繪標記，而模型會保留畫面其餘部分。

線索就在你即將輸入的那句話裡。「讓它看起來像這樣，但改成夜晚」屬於 i2i；「把外套改成紅色，其餘不變」則是編輯，而在這張圖上，編輯路徑正是遮罩、十個參考槽位，以及局部編輯行為所在之處。隔壁那個問題屬於另一頁的主題，而這一頁停在界線處，好讓你能分辨自己位於哪一邊。

Turbo 檢查點，用一段話說明

一則交叉參照，因為 turbo 這個拼法就落在這個查詢家族裡，讀者遲早會遇到。Qwen-Image-2.1-Turbo是同一套 7B 視覺生成架構的另一個 8 步檢查點，於 2026 年 10 月 9 日發布，並由同一個 QwenImage21Pipeline載入。它自己的模型卡寫著，該檢查點「內含其建議的取樣排程，因此可直接使用，無須手動設定排程器」，生成時預設使用 CFG 1，而且單獨設定 num_inference_steps並不會覆寫已儲存的排程——必須在呼叫時明確傳入 sigmas引數才行。這些都不會改變本頁的節點鏈：同樣的載入器、同樣的編碼器、同樣的取樣器節點。改變的是排程的來源，而這正是你在比較 turbo 執行與基礎模型執行、進而斷定模型變差之前，最該在自己的圖中檢查的一件事。

在圖表中，接下來該做什麼

請從 ComfyUI 的範本庫載入範本，而不是從螢幕截圖，然後在排入任何工作之前先讀取四個節點。在 Resolution Selector 上，設定你真正想要的長寬比；如果你想要模型原生的 2K，就設定 4.0 MP 目標。在 KSampler 上，如果你打算重現某次執行，就確認 control 為 fixed，並讓 steps 維持在 25、cfg 維持在 1，直到有特定項目失敗為止。在 Qwen Image 2.1 Cache 上，現在就決定 device 和 dtype 並寫下來，因為你之後無法更改它們，否則你會拿兩張圖片來比較，彷彿只有提示詞變動過。而在 Generate Text 節點上，先讓 refine_prompt 保持關閉，直到你有一個喜歡的基準 —— 然後再打開它，在 Preview Any 中查看改寫結果，並保留你原本使用的 seed，這樣比較才有意義。