MOSS-Image לעומת FLUX 3: שתי דרכים להכניס תיבת תיחום לפרומפט

הדבר המעניין ביותר בהשוואה בין MOSS-Image ל-FLUX 3 הוא ששניהם, בתוך החודש האחרון, הגיעו לאותה מסקנה — שהדרך לשלוט במודל תמונות היא לכתוב קואורדינטות לתוך הפרומפט — ואז לא הסכימו לגבי מערכת הקואורדינטות. ב-16 באוקטובר 2026, OpenMOSS שחררה את MOSS-Image-Base ואת MOSS-Image-SFT תחת Apache 2.0: טרנספורמר דיפוזיה בגודל 5B, ניתן להורדה, עם פורמט פריסת JSON שממקם אלמנטים לפי היסטי פיקסלים מוחלטים הנמדדים ממרכז הקנבס. Black Forest Labs הקדימה עם Flux 3 Image, פעיל מאז 1 באוקטובר עם מחירון מפורסם, שלוקח כל תיבה בתור [top, left, bottom, right] במספרים שלמים מ-0 עד 1000, ביחס לרשת קבועה. אותו רעיון, דקדוק לא תואם, ורק אחד מהשניים נותן לך קובץ שאפשר לשמור.

ההבדל הזה — לא איכות התמונה — הוא מה שמכריע את ההתמודדות הזו עבור רוב הצוותים, והוא מכריע אותה מהר יותר מכל בנצ׳מרק. לכן ההשוואה שלהלן מאורגנת סביבו. כל נתון של MOSS-Image הוא של OpenMOSS עצמה, נלקח מהודעת ההשקה ומהדוח הטכני שלה, ואף אחד לא שחזר אותם. כל נתון של Flux 3 הוא מתוך המחירון והחומרים שפרסמה Black Forest Labs בעצמה. אין השוואה ישירה ובלתי תלויה בין שני המודלים האלה, וגם לא תהיה כזו בזמן הקרוב.

מה שכל צד בפועל סיפק

MOSS-Image הוא זוג צ'קפוינטים, MOSS-Image-Base ו-MOSS-Image-SFT, עם משקלים וקוד הסקה תחת רישיון Apache 2.0, מראה של ModelScope, Gradio Space, pipeline מותאם אישית של Diffusers, ותוסף ComfyUI נייטיבי. תמיכת הליבה של ComfyUI הגיעה באותו יום שבו הגיעו המשקלים. אין נקודת קצה מתארחת מ-OpenMOSS ואין מחיר מפורסם, כי אין מה לתמחר — אתה מריץ את זה או שאתה לא.

F​lux 3 הוא הצורה ההפוכה. Black Forest Labs הכריזה עליו ביולי 2026 כארכיטקטורה יחידה שאומנה על פני וידאו, תמונה ואודיו, ושכבת התמונות הסטטיות — F​lux 3 Image — נפתחה עם תמחור ציבורי של תשלום לפי שימוש ב-1 באוקטובר. המקבילה במשקולות פתוחות, FLUX 3 Image Klein, הגיעה ב-15 באוקטובר תחת רישיון FLUX Kommunity, שמתיר שימוש מסחרי בחינם רק מתחת לתקרת הכנסות. כך ש-B​FL אכן מציעה כעת גם מסלול של שכירות וגם מסלול של הורדה, אבל אלה מודלים שונים עם רישיונות שונים, וההורדה היא האח הקטן ולא ספינת הדגל.

אף אחד משני המודלים אינו בקטלוג שלנו. OrcaRouter מספק יותר מ-200 מודלים וגם MOSS-Image אינו אחד מהם, ולכן אין לפרש את הדברים כאן כאילו שאנחנו מציעים אותו — הדבר נכון גם לגבי Flux 3. התועלת של הראוטר בהשוואה הזו היא בחצי השני של הלולאה: כאשר אתם רוצים להעמיד צ'קפוינט באירוח עצמי מול מודלי תמונות מתארחים על אותם פרומפטים, הצד המתארח נגיש דרך מפתח API אחד, במחיר המחירון של הספק ללא תוספת מצדנו, עם מעבר אוטומטי בין ספקים אם אחד מהם מתדרדר באמצע הריצה.

דקדוקי התיבה, זה לצד זה

כאן השניים מתפצלים באופן שקובץ תצורה יבחין בו.

• מרחב קואורדינטות — M​OSS-Image: פיקסלים מוחלטים הנמדדים ממרכז הקנבס, באמצעות bbox_coord_space: "abs_centralized", כך שעל קנבס בגודל 1024×1024 כל ציר נע בין −512 ל־+512. F​lux 3 Image: מספרים שלמים מנורמלים 0 עד 1000 הנמדדים מהפינה השמאלית העליונה.

• סדר קואורדינטות — M​OSS-Image: bbox_format: "yxyx", כלומר [y_min, x_min, y_max, x_max]. F​lux 3 Image: [top, left, bottom, right], שהם אותם ארבעה מספרים באותו סדר בשם שונה.

• איך זה מגיע למודל — MOSS-Image: אובייקט JSON יחיד שמועבר כמחרוזת הפרומפט, עם summary בלוק עבור סצנה וסגנון בתוספת items מערך שבו כל פריט נושא תווית, כיתוב, ועבור רכיבי טקסט את המחרוזת המילולית שרוצים להציג. Flux 3 Image: מערך JSON של תיבות שנכתב לתוך פרומפט רגיל, בלי צורך בפרמטר נוסף.

• צימוד רזולוציה — הקואורדינטות של MOSS-Image הן פיקסלים, ולכן הן נכונות רק עבור הרוחב והגובה שביקשת; אם תשנה את גודל הפלט, תגזור מחדש כל תיבה. הרשת 0–1000 של Flux 3 אינה תלויה ברזולוציה מעצם בנייתה: [0, 0, 500, 500] הוא הרבע השמאלי-עליון של כל קנבס שתבקש.

• לשם מה נועד התיבה — M​OSS-Image מוצג בראש ובראשונה כשליטה ביצירה, כשהספק מציין שעריכת הכיתוב של רכיב או הזזת התיבה שלו מתאימות את אותו חלק מהקומפוזיציה, ומתואר כניסיוני. F​lux 3 Image משלבת פריסה עם עריכה רב-סבבית מוגבלת לתיבה כיכולת מרכזית.

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

רינדור טקסט, שבו המספרים היחידים הם של הספק

היכולת המובילה של MOSS-Image היא טקסט קריא, והיצרן בנה שני בנצ'מרקים כדי למדוד אותה. ב-LongLongTextBench — 240 משימות רינדור טקסט ספרותי באורך מטרה ממוצע של כ-1,340 תווים — MOSS-Image משיג 96.3 ב-Mean-6 כיסוי טקסט, לעומת 64.9 של Qwen-Image-2512. השורה שמעליו באותה טבלה היא GPT Image 2 עם 99.0 ו-Nano Banana Pro עם 96.6, מה שראוי לציון: OpenMOSS פרסמה טבלה שבה המתחרים עדיין מנצחים.

Black Forest Labs לא פרסמה כלל בנצ'מרק לרינדור טקסט עבור Flux 3 Image. אין שום מספר להציב לצד 96.3, משני הצדדים כאחד, ולהמציא השוואה מתוך תמונות לדוגמה יהיה בדיוק מסוג הדברים שהבלוג הזה לא צריך לעשות. מה שכן ניתן לומר הוא שה-VAE של FLUX.2 הוא זה שבו משתמשת MOSS-Image — כרטיס המודל של MOSS-Image עצמו מציין שהיא טוענת את המפענח הקטן של FLUX.2 — כך ששתי המשפחות אינן זרות זו לזו ברמת הפיקסל, אף שהמחוללים אינם קשורים זה לזה.

עלות: מספר אחד לעומת חמישה

• M​OSS-Image — חינם להורדה, Apache 2.0, ללא סף הכנסות וללא דרג מסחרי. העלות היא חומרה: מאגר ה-SFT מסתכם בכ-27.2 GB, מתוכם כ-16.8 GB בארבעה שברים הם מקודד הטקסט הקפוא Qwen3.5-9B וכ-10.2 GB בשלושה הם השנאי. הקצו תקציב למקודד, לא לתג.

• F​lux 3 Image — $0.041 ב-768×768, $0.048 בערך ב-1 מגה-פיקסל, $0.07 ב-1.5K, $0.10 ב-2K ו-$0.607 ב-4K, לתמונה, מכרטיס התעריפים של Black Forest Labs עצמה. הנחת השקה של 50% הייתה בתוקף מ-1 באוקטובר עד 8 באוקטובר ופגה, לכן כל מודל עלויות שנבנה עליה זקוק לשורה שנייה בתעריף מלא.

• FLUX 3 Image Klein — $0.008 ב-768×768, עולה ל-$0.036 ב-4K, ועלות טקסט-לתמונה ועריכה זהה. הוא זול באופן דרמטי מהורדת ה-5B שאיתה הוא מתחרה מבחינת עבודה, אם לא מבחינת רישיון.

הניסוח הישר הוא שאלו אינן אותה רכישה. MOSS-Image מחליף כסף בשעות GPU ובהנדסה; Flux 3 Image מחליף כסף בכך שמישהו אחר מריץ את הסטאק, והוא מתומחר לכל תמונה שנמסרת בתעריף שעולה בתלילות עם הרזולוציה.

מה שאף אחד מהצדדים לא פרסם

אין בנצ'מרק עצמאי ל-M​OSS-Image. גם אין בנצ'מרק עצמאי ל-F​lux 3 Image — B​FL השיקה את דרג התמונות בלי מספרי השוואה מול שום מודל תמונות אחר, בין אם הורצו על ידי ספק ובין אם לא. לאף אחד מהמודלים אין שורה בלוח דירוג נייטרלי שאפשר להצביע עליה. כששני הצדדים של השוואה חסרי ראיות, המסקנה הנכונה אינה שהם טובים באותה מידה; היא שאי אפשר כרגע לדעת, וששובר השוויון חייב להיות משהו שאפשר באמת למדוד — רישיון, פורמט, השהיה על החומרה שלך, והאם דקדוק ה-box תואם לקוד שכבר יש לך.

שני דברים היו משנים את זה. הרצה עצמאית של LongLongTextBench או RealLayoutArena בידי מישהו אחר מלבד OpenMOSS תהיה הראיה הממשית הראשונה לטענה המרכזית של MOSS-Image. השוואת בקרת פריסה מצד שלישי על רשת BFL תעשה את אותו הדבר עבור Flux 3 Image. אף אחד מהם עדיין לא קיים.

איזה אחד היית באמת בוחר?

בחר ב-MOSS-Image אם התוצר הוא עמוד מורכב — פוסטר, אינפוגרפיקה, מוקאפ מוצר — שבו טקסט מסוים צריך להתמקם במקומות מסוימים, ושבו אתה רוצה את המשקלים בתשתית שלך. רישיון Apache 2.0 מקצר את הסקירה המסחרית, צ'קפוינט Base הושאר בכוונה לא-מזוקק כדי שלאימון LoRA יהיה על מה להיאחז, ופריסת ה-JSON היא החלק של המודל שהספק מדד בקפידה הרבה ביותר. הקצה תקציב למקודד וצפה לספק JSON מובנה ולא פרוזה: בדיקת האבלציה של הספק עצמו הציבה פרומפטים של פריסת JSON ב-1622.87 Elo לעומת 1506.20 לשפה טבעית באותה מערכת — פער גדול והאות הברור ביותר בשחרור.

בחר ב-F​lux 3 Image אם אתה זקוק לנקודת קצה ניתנת לקריאה היום, אם הפלטים שלך משתנים ברזולוציה, או אם אתה רוצה עריכות מוגבלות-לתיבה על פני מספר סבבים כתכונה נתמכת ולא כניסיונית. הגריד 0–1000 אינו תלוי ברזולוציה, כרטיס התעריפים פומבי, ויש לצידו וריאנט זול במשקלים פתוחים אם תקרת הרישיון מקובלת.

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

הכשלים המתועדים של ה-AI ותקריות הסוכנים שמאחורי גרסאות כמו זו נאספים בארכיון תקריות ה-AI של OrcaRouter, שבו כל רשומה כוללת מקורות משלה, חומרה, דירוג מהימנות ודגל מחלוקת.