תהליך העבודה של Qwen-Image-2.1: שרשרת הצמתים, החוגות, ומה שהשתנה מאז יום אפס

מה שאתה מקבל מהעמוד הזה הוא Qwen-Image-2.1 גרף שאתה יכול לבנות מאפס ולשחזר — שרשרת הצמתים לפי השמות שהלואדרים באמת משתמשים בהם, ארבעת או חמשת החוגות שקובעות אם הפלט הוא מה שביקשת, ושתי ההגדרות שאנשים משנים בלי לדעת שהם שינו את לוח זמני הרעש. המודל עצמו הוא מהדורת טקסט-לתמונה ועריכת-תמונה המאוחדת של הספק, שפורסמה בקוד פתוח ב-20 בספטמבר 2026 תחת רישיון מחקרי: 7B פרמטרים ברכיב היצירה החזותית, 32 שכבות DiT בזרם יחיד, VAE בעל 64 ערוצים מסוג RGBA בדחיסה מרחבית של פי 16, ועד עשרה תמונות ייחוס במסלול העריכה. התאריך הזה נועד לומר לך איזה צ'קפוינט אתה מחווט, לא להכריז על משהו. הגרף הוא הנושא, ולגרף יש היסטוריית גרסאות שכדאי לקרוא לפני שאתה סומך על צילום מסך של מישהו אחר שלו — התבנית שמשוחררת היום היא לא התבנית ששוחררה ביום הראשון, וארבעה מההבדלים הם בדיוק הדברים שטועים בהם.

איזה גרף העמוד הזה מתאר

כל מה שלהלן נקרא ממאגר תבניות זרימות העבודה של ComfyUI Comfy-Org/workflow_templates, בגרסה העדכנית ל־13 באוקטובר 2026, בהרצה על ComfyUI stable v0.39.0 (פורסם ב־5 באוקטובר 2026). שמות הצמתים הם שמות התצוגה שהטוענים משתמשים בהם בגרף; כאשר צומת נוסף או ששמו שונה בין גרסאות, התאריך מצוין. הדרך לקבצים האלה עוברת בעמוד המדריך של 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 אומר שהיא עושה שימוש חוזר בתת-גרף עריכת התמונה עם הפרומפט "הסר את הרקע, ופלוט תמונת PNG". לכן יש שני גרפים ללמוד, ואחד מהם הוא תבנית פרומפט מעל האחר.

שרשרת הצמתים, לפי הסדר

תבנית טקסט-לתמונה היא תת-גרף — צומת אחד מתקפל על הקנבס עם שמונה-עשרה כניסות חשופות — שעוטף שרשרת בת שלושה-עשר צמתים. בתוכו, הסדר הוא:

• UNETLoader — טוען את qwen_image_2.1_int8_convrot.safetensors עם סוג המשקל שנשאר על ברירת מחדל. זהו מודל הדיפוזיה, והקובץ שאתה בוחר כאן הוא הדבר הראשון שקובע אם ההרצה שלך תואמת לזו של כל אחד אחר.

• Qwen Image 2.1 Cache — יושב בין הטוען (loader) לדוגם (sampler). הוא אינו אופציונלי בתבנית הנוכחית, אך ניתן לעקוף אותו, וזהו הצומת שסביר מכולם שיחסר בגרף שהורדתם בשבוע הראשון.

• KSampler — לוקח את המודל מצומת המטמון, את ההתניה החיובית והשלילית ממקודד הטקסט, ואת הלטנט הריק. הווידג'טים שלו בתבנית המסופקת מראים: זרע 0, בקרה קבוע, צעדים 25, cfg 1, סמפלר euler, מתזמן simple, הפחתת רעש 1.

• EmptyLatentImage — הרוחב והגובה מחוברים מהצומת Resolution Selector שנמצא מחוץ לתת-גרף, והקלט השלישי שלו, גודל אצווה, מגיע כ-1.

• VAEDecode → SaveImageAdvanced — המפענח מעביר פיקסלים לצומת השמירה, שתחילית שם הקובץ שלה היא Qwen_image_2.1 והפורמט שלה מגיע כ־PNG, 8-bit, sRGB. ל־PNG אין כאן תפקיד קוסמטי: ה־VAE נושא ארבעה ערוצים, ולכן PNG 8-bit הוא מה שמשאיר את ערוץ האלפא חי בדרך לדיסק.

• CLIPLoader — טוען את qwen3vl_8b_int8_convrot.safetensors כשהסוג מוגדר ל-qwen_image. ‏Qwen3-VL 8B הוא מקודד הטקסט, והוא גם מגדל הראייה שקורא את תמונות ההפניה שלך.

• קידוד טקסט Qwen Image 2.1 (מזהה צומת TextEncodeQwenImage21) — מתנה את הפרומפט. הוא מקבל את ה-clip, פרומפט, פרומפט שלילי, VAE אופציונלי, מספר רזולוציה שלם, וקבוצה שמתרחבת אוטומטית של משבצות תמונה בשם image_1 עד image_16. הוא מחזיר שלושה דברים: התניה חיובית, התניה שלילית, ולטנט. הלטנט הזה הוא החלק שאנשים מפספסים — הוא לטנט ריק בגודל של תמונת ההתייחסות הראשונה, ובגרף טקסט-לתמונה הוא אינו בשימוש כי הלטנט הריק מגיע מ-Resolution Selector במקום.

• 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 נערכו חמש פעמים אחרי שהן הופיעו לראשונה, והעריכות אינן קוסמטיות.

• 20 בספטמבר 2026 — התבנית הראשונה. קומיט 96309bd530, "הוספת תבנית Qwen Image 2.1". שבעה צמתים בתת־הגרף של טקסט-לתמונה: הטוענים, המקודד, הלטנט הריק, הדוגם, המפענח. טוען ה-CLIP הוגדר למקודד הטקסט bfloat16, qwen3vl_8b_bf16.safetensors — הקובץ בגודל 16.33 GB.

• 20 בספטמבר 2026, מאוחר יותר באותו יום. קומיט 371a7b7171 העביר את אותו מטעין ל-qwen3vl_8b_int8_convrot.safetensors, קובץ בנפח 8.71 GB, עם ההודעה "החלפת Qwen Image 2.1 CLIP ל-int8 convrot". ההערה של התבנית עצמה מתייגת אותו כ"נטען על ידי התבניות, צריכת זיכרון נמוכה יותר". זרימת עבודה שנבנתה מהקובץ של הבוקר וזו שנבנתה מזה של הערב אינן אותה זרימת עבודה.

• 25 בספטמבר 2026. צומת הQwen Image 2.1 Cache הופיע לראשונה בגרף, יחד עם כל ענף שיפור הפרומפט — טוען ה-CLIP השני, Generate Text, Preview Any, המתג, צומת פרומפט המערכת. לפני תאריך זה לא היה צומת מטמון להגדיר ולא שלב שכתוב לכבות. תבנית עריכת התמונות קיבלה את הקלטים המתאימים באותו יום. גם הערת הטקסט-לתמונה קיבלה, בגרסה זו, הן את שורת 4 המגה-פיקסלים והן את עטיפת הפרומפט לתמונה שקופה.

• 28 בספטמבר 2026. גדלי קבצים נוספו להערות ההורדה — שינוי תיעודי, לא שינוי בגרף, אבל זה המקום שממנו מגיעים המספרים שקורא בודק מול מנהל ההורדות שלו.

• 30 בספטמבר 2026.קומיט 9fae1041be, "Qwen Image 2.1: עדכון הגדרות PE" — הפעם האחרונה שנגעו באחת משתי תבניות 2.1. זה הדבר החשוב ביותר והפחות גלוי. שלושה ערכים בצומת Generate Text השתנו: תקציב הטוקנים max_length מ-16256 ל-4096, קנס החזרתיות מ-1.05 ל-1.0, ו-thinking מ-off ל-on, כאשר בהערה של הצומת עצמו נאמר כעת שה-checkpoint "אומן עם בלוק חשיבה ומאבד איכות בלעדיו". הערות התבנית מתארות את הערכים הקודמים כערכים הרשמיים ואומרות שהתקרה קיימת כדי ש"שכתוב בודד לא יימשך דקות רבות".

מה שלא השתנה הוא המחצית השימושית של זה. בלוק הדגימה זהה ברמת הבתים בין תבנית יום האפס לזו של היום: צעדים 25, cfg 1, euler, simple, denoise 1, בקרת seed קבועה, latent ריק בפלט של Resolution Selector, גודל אצווה 1. הגרף מעולם לא תוקן על ידי הזזת הדוגם. הוא תוקן על ידי שינוי איזה קובץ text-encoder נטען, הוספת צומת המטמון, ותיקון ההגדרות של משפר הפרומפט עצמו.

עוד שכבה אחת יושבת מתחת לגרף. ליבת ComfyUI המשיכה להשתנות אחרי שהתבניות התייצבו: v0.38.0 ב-29 בספטמבר שיפרה את לוגיקת מיקום מטמון ה-KV של Qwen 2.1, ו-v0.39.0 ב-5 באוקטובר כללה "תיקון קריסה בעת בחירת מטמון int8 או int4 ב-qwen image 2.1". אם הגרף שלך הוא של היום והבילד שלך ישן יותר מזה, תפריט המטמון הנפתח הוא לא אפשרות איטית — הוא קריסה.

החוגות שסביר ביותר שקורא יטעה בהן

התחילו ממה שהתיעוד קובע באופן חד-משמעי, כי זה מסיר את רוב הניחושים.כל שלושת תהליכי העבודה של Qwen-Image-2.1 דוגמים עם steps 25, cfg 1, euler sampler, ו-simple scheduler.זה הסיכום של ComfyUI עצמו, והוא תואם בדיוק את הווידג'טים המסופקים.

הסיבוך הוא ש-25 ו-40 הם שניהם תשובות נכונות לשאלות שונות. כרטיס המודל של הספק עצמו מריץ את צינור diffusers עם num_inference_steps=40, וברירת המחדל של צינור diffusers היא גם 40; התיעוד של ComfyUI אומר שהצינור שפורסם "משתמש בכ-40 עד 50 צעדים עם הדוגם euler, והתבנית מתחילה נמוך יותר, ב-25". אף אחד מהמספרים אינו שגיאה. הם ברירת מחדל של גרף והרצת ייחוס.

• Steps — כיוון ופשרה. ערך נמוך יותר מהיר יותר, ולפי התיעוד של ComfyUI הוא מחזיק מעמד באופן שונה בהתאם למשימה: עריכות מקומיות פשוטות מחזיקות מעמד ב-4 עד 8 צעדים, "ואילו עריכות שמשכתבות את כל הפריים מאבדות קוהרנטיות וזקוקות ל-25 המלאים". פרטים עדינים ועקשניים כמו ידיים ואצבעות "מסתדרים עד כ-30 צעדים", ומעבר מ-25 ל-40 מפחית את ה"fizzle" באזורים עתירי פרטים. הכיוון מונוטוני והפשרה לינארית: עצת התיעוד היא להתאים את מספר הצעדים רק כאשר משהו ספציפי אינו נפתר, ולא להעלות אותם ליתר ביטחון.

• הנחיה — cfg 1 פירושו הנחיה כבויה, וזהו הנתיב המפורסם. ב-cfg 1 ‏ComfyUI מדלג על מעבר ההתניה השלילית, כך שלתפיסה שלילית אין השפעה. התבנית שומרת על cfg 1, "שהוא הנתיב שעבורו Qwen-Image-2.1 פורסם"; ה-pipeline של diffusers אומר את אותו הדבר במילותיו שלו, ומגדיר כברירת מחדל את true_cfg_scale ל-1.0 מפני ש"Qwen-Image 2.1 מיועד להידגם ללא הנחיה". העלו אותו רק כשאתם באמת רוצים שהפרומפט השלילי ייכנס לתוקף, ודעו את המחיר: cfg 2 הולך אחרי פרומפטים צפופים בצורה צמודה יותר, כולל טקסט קטן ומספרים, "במחיר של קצוות מחודדים מדי"; ערכים גבוהים יותר מסיטים את החשיפה לעבר בהירות יתר או עמעום יתר; cfg 5 פוגע קשות באיכות; cfg 0.5 שובר את התמונה. ההוראה של ComfyUI היא לשנות ערך אחד בכל פעם ולהשוות בזרע קבוע.

• רזולוציה היא יעד של מגה-פיקסלים, לא מלבן. הצומת Resolution Selector מגדיר יחס גובה-רוחב ותקציב מגה-פיקסלים, כאשר 1.0 MP הוא בערך 1024x1024. Qwen-Image-2.1 מייצר באופן מקורי ב-2K, ולכן היעד לריבוע של 2048x2048 הוא בערך 4.0 MP. כפולות של 32 הן מה שהמודל רוצה — תיאור העזרה על הקלט resolution במקודד הטקסט אומר שהפניות מותאמות מחדש לגודל של בערך resolution x resolution פיקסלים בכפולות של 32, תוך שמירה על יחס הגובה-רוחב, וגם פונקציית העזר של הממדים של ה-pipeline מעגלת ל-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 דוגם עם מתזמן אוילר מסוג flow-matching שהיסט צעדי הזמן שלו דינמי, והפייפליין מחשב את ההיסט מאורך רצף הלטנטים — כלומר, מכמה טוקנים הרזולוציה שבחרתם מייצרת. קונפיגורציית המתזמן של הצ'קפוינט מגדירה base_shift 0.5 ו-max_shift 0.9 על פני טווח רצף תמונה של 256 עד 8192, והפייפליין מזין את אורך הרצף של ההרצה שלכם אל תוך הנוסחה הזו בכל קריאה. לכן שינוי הקנבס משנה את לוח הזמנים של הדוגם, ולא רק את הפריים. בתבנית של ComfyUI אין שום בקרת shift שאפשר להגדיר — הקלטים של KSampler הם model, positive, negative, latent image, seed, steps, cfg, שם הדוגם ו-scheduler, וזו כל הרשימה. אם התוצאות שלכם ב-4 MP נראות שונה מהתוצאות שלכם ב-1 MP באופן שאי אפשר להסביר רק במידת הפירוט, זו הסיבה.

• בגרף העריכה, הרזולוציה מתנהגת אחרת והיא ברירת המחדל היקרה ביותר. עם 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 וקח את הקנבס מבורר הרזולוציה, ושמור אותו קרוב לגודל התמונה הראשונה לאחר שינוי הגודל, "אחרת העריכה עלולה לזוז".

דטרמיניזם: מה ה-seed קובע, ומה הוא לא קובע

זרע קבוע הוא הכרחי אך לא מספיק, והתבניות המסופקות אינן מסכימות זו עם זו לגביו. ה-KSampler של טקסט-לתמונה מגיע עם בקרה קבועה; שתי תבניות העריכה — עריכת התמונה והסרת הרקע — מגיעות עם בקרה אקראית. אותו סמפלר, אותן ברירות מחדל, התנהגות הפוכה בעת הוספה מחדש לתור.

נניח שהגרעין קבוע. הנה מה שעדיין מזיז את התמונה:

• ה-KV cache. זה הגדול, והוא מתועד ולא פולקלור. Qwen-Image-2.1 שומר במטמון את המפתחות והערכים של הטקסט ושל תמונת ההתייחסות לאחר הצעד הראשון; קוד המקור של ה-pipeline מסביר שזה תקף מפני שטוקני ההתניה אינם תלויים בצעד תחת ההתניה הסיבתית של המודל. ואז הוא אומר את הדבר שחשוב לכל מי שמנסה לשחזר תמונה: הפעלה או כיבוי של המטמון "אינם משחזרים את אותה תמונה בדיוק ביט-אחר-ביט בדיוק מופחת", מפני שצעד הפענוח מבצע attention בפריסת רצף שונה מזו של שלב ה-prefill, השניים מחלקים לאריחים באופן שונה ונוחתים על עיגול שונה — והפרש של ULP אחד בבלוק הראשון מוגבר על ידי 32 בלוקים ובכל צעד דגימה, כך ש"שתי ההגדרות נותנות דגימות תקפות באותה מידה אך נבדלות חזותית". ההוראה של המקור עצמו היא: קבעו דגימה על ידי קביעת הדגל הזה. ב-ComfyUI הדגל נמצא על Qwen Image 2.1 Cache צומת, בתור device (auto, gpu, cpu, off) ו-dtype (default, int8, int4).

• היסטוריית השחרורים של צומת המטמון עצמו. הוא לא היה קיים לפני 25 בספטמבר 2026, ולכן לתהליך עבודה מיום אפס אין הגדרה כזו והוא אינו מתנהג כמו זה של היום. וגם off — ההגדרה היחידה שפוסלת את המטמון — "מחשבת מחדש את הקידומת בכל צעד, וזה איטי יותר אבל זו הדרך היחידה לפסול את המטמון".

• אילו קבצי מודל. התבנית טוענת מודל דיפוזיה int8 ומקודד טקסט int8. החליפו אחד מהם בקובץ bf16 — והרי שיניתם את החשבון. הערות ההורדה מפרטות את שניהם, עם הגדלים שלהם, בדיוק מפני שהבחירה אמיתית.

• משפר הפרומפט, אם הוא מופעל. כאשר refine_prompt מופעל, מודל התמונות דוגם מהפרומפט המשוכתב, לא מזה שהקלדת — והשכתוב נוצר על ידי Generate Text נפרד עם פרמטרי הדגימה שלו: temperature 1.0, top_k 20, top_p 0.95, שדה seed משלו, ותקציב טוקנים של max_length. ה-seed של KSampler שלך לא מכסה שום דבר מזה. רכיב ה-Preview Any שבתוך תת-הגרף מציג את הפרומפט שהגיע בפועל למודל התמונות, וזו הדרך היחידה לדעת מה בדיוק שחזרת.

• גרסת ה-Build של ComfyUI. התבניות נושאות אזהרה משלהן: צמתים חסרים בעת טעינת תהליך עבודה בדרך כלל מעידים שהבנייה קודמת לצמתים, ו-Desktop ו-Cloud עוקבים אחר מהדורות יציבות ועלולים לפגר אחרי גרסת nightly.

אז שחזור תמונת Qwen-Image-2.1 של מישהו אחר אינו החלפת seed. זהו מהדורת התבנית, שני קבצי המודל, הגדרת הרזולוציה, הצעדים, ה-cfg, ה-sampler, ה-scheduler, התקן המטמון וה-dtype, מצב ההפעלה/כיבוי של ה-enhancer וה-seed שלו — ולגרף העריכה, גודל תמונת ההתייחסות הראשונה. ComfyUI אינה מפרסמת שום הבטחת שחזוריות seed עבור זרימות עבודה אלו, ומקור ה-diffusers אומר בפשטות ששינוי במטמון משנה את הדגימה; התייחסו להתאמה מדויקת כאל משהו שאתם מרכיבים בכוונה ולא כאל משהו ש-seed נותן לכם.

יותר מתמונה אחת, ולאן הזיכרון הולך

הגרף מפיק תמונה אחת בכל הרצה בתצורה המסופקת, והמתג לשינוי זה אינו זוהר: EmptyLatentImage הקלט השלישי של הצומת, גודל אצווה, מחווט ל-1. העלאתו היא מה שגורם לדוגם לפלוט כמה תמונות מתור אחד.

מה שזה עולה — כאן נעשים הדברים כנים. התבניות אומרות לך בדיוק היכן המטמון יושב — auto משתמש ב-VRAM פנוי ואחר כך בזיכרון המערכת; cpu מבצע prefetch מאחורי החישוב, והתיעוד מתאר אותו כעולה מעט בלבד במהירות; off מחשב מחדש את הקידומת בכל צעד והוא איטי יותר. את צד הדיוק הם מכמתים: int8 מחצית את גודל המטמון בדיוק של בערך bf16, ו-int4 מרבע אותו אך בערך מכפיל את השגיאה לכל צעד. מה שהם לא מפרסמים הוא טבלה של גודל אצווה מול VRAM, וגם לא התיעוד של ComfyUI. אם אתם מחשבים גודל אצווה לכרטיס, התשובה הכנה היא שאף נתון רשמי של המפתחת לא מכסה זאת; הידיות שעבורן פורסמו השפעות הן התקן המטמון וה-dtype, ויעד הרזולוציה, שמעלה גם את מספר הלטנטים וגם את הקידומת שנשמרת במטמון.

שתי מלכודות של אצווה נמצאות מעבר לגדר, בצינור ה-diffusers, ושתיהן כדאי להכיר כי גרף ה-ComfyUI מסתיר אותן. שם, num_images_per_prompt מכפיל את האצווה, ואם מעבירים רשימת מחוללים, האורך שלה חייב להתאים בדיוק לגודל האצווה האפקטיבי, אחרת הצינור זורק שגיאה. ורשימה של תמונות תנאי היא "קבוצה אחת של תמונות שמשותפת לכל פרומפט באצווה, ולא ערך אחד לכל פרומפט" — אי אפשר לתת לכל פרומפט באצווה תמונת ייחוס משלו; ההוראה של המקור היא לקרוא לצינור פעם אחת לכל פרומפט במקום זאת. לתת-גרף העריכה יש אותה צורת אילוץ במקום אחר: ה-BatchImagesNode שלו מקבץ עד עשר תמונות ייחוס אל תוך מקודד הטקסט, וזה קיבוץ של קלטים, לא של פלטים. עשר תמונות ייחוס לא נותנות לך עשר תמונות.

תמונה-לתמונה מאותו גרף

אתה לא צריך גרף אחר בשביל זה. תבנית עריכת התמונה היא שרשרת ה-text-to-image שבה הלטנט הריק הוחלף בפלט הלטנט של מקודד הטקסט, שני צמתי LoadImage שמזינים image_1 ו-image_2 אל חריצי ההתייחסות של תת-הגרף, וצומת ImageCompare בסוף כדי שתוכל לראות את הקלט לצד הפלט. שים תמונה אחת ב-image_1, השאר את image_2 ריק, כתוב הוראה, וזו image-to-image: התמונה שלך היא ההקשר שהמודל קורא, ולא לטנט התחלתי שהוא מבצע עליו דנוז חלקי. אין בנתיב הזה סליידר strength או denoise להגדיר, כי היעד מתחיל מרעש וההתייחסות שלך נכנסת דרך המקודד וה-VAE במקום.

הנה הגבול, במשפט אחד לכל אחד, כי שני אלה נמצאים במרחק חיפוש אחד זה מזה, ואנשים נוטים לפנות אל הלא־נכון.

• תמונה לתמונה זה כאשר אתה רוצה וריאציה: אתה נותן למודל תמונה ותיאור, והוא מצייר תמונה חדשה שדומה לשלך, על קנבס שאתה בוחר.

• עריכה היא כאשר רוצים שינוי: מעבירים למודל תמונה והוראה שמציינת מה צריך להיות שונה, ובאופן אופציונלי גם מסכה או סימנים מצוירים, והמודל שומר על שאר הפריים.

הסימן המסגיר נמצא במשפט שאתה עומד להקליד. "תעשה שזה ייראה ככה אבל בלילה" זה i2i; "שנה את הג'קט לאדום, השאר את כל השאר" זו עריכה, ובגרף הזה נתיב העריכה הוא המקום שבו נמצאים מסכות, עשרת חריצי הייחוס והתנהגות העריכה הממוקמת. השאלה השכנה הזו היא הנושא של עמוד אחר, וזו עוצרת בקו כדי שתוכל לדעת על איזה מהם אתה נמצא.

נקודת הביקורת של הטורבו, בפסקה אחת

הפניה מוצלבת אחת, כי האיות turbo יושב בתוך משפחת השאילתות הזו והקורא ייתקל בו. Qwen-Image-2.1-Turbo הוא checkpoint נפרד בעל 8 שלבים של אותה ארכיטקטורת יצירה חזותית בת 7B, ששוחרר ב-9 באוקטובר 2026 וננטע על ידי אותו QwenImage21Pipeline. כרטיס המודל שלו עצמו אומר שה-checkpoint "כולל את לוח הדגימה המומלץ שלו, כך שהוא מוכן לשימוש בלי להגדיר את ה-scheduler באופן ידני", שדגימה משתמשת כברירת מחדל ב-CFG 1, ושהגדרת num_inference_steps לבדה אינה עוקפת את לוח הזמנים השמור — ארגומנט מפורש בזמן קריאה בשם sigmas כן עוקף. שום דבר מזה לא משנה את שרשרת הצמתים בעמוד הזה: אותם loaders, אותו מקודד, אותו צומת sampler. מה שכן משתנה הוא מאיפה מגיע לוח הזמנים, וזה הדבר היחיד ששווה לבדוק בגרף שלך לפני שאתה משווה הרצת 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 שהיית עליו כדי שלהשוואה תהיה משמעות.