LFM3-1.7B לעומת Granite 4.2 30B: שני מודלי סוכנים שמפצלים את הכרעתם לפי ציר

הציבו LFM3-1.7B וGranite 4.2 30B באותו עמוד, והממוצעים המצטברים מצביעים בכיוונים מנוגדים בהתאם לשורה שתקראו. בלוח Berkeley Function Calling Leaderboard V4, המודל של Liquid AI עם 1.73 מיליארד פרמטרים מקבל 71.39 לעומת 61.39 של IBM — ניצחון של עשר נקודות למודל קטן פי 17 בערך. ב-SWE-bench Verified, Granite מקבל 57.00 לעומת 43.40 של LFM3-1.7B, ניצחון של 13.6 נקודות בכיוון ההפוך. ניתוב אינו מוסיף מרווח למחיר המחירון של ספק. מחירי המחירון של הספקים מועברים ב0% תוספת.

שני המודלים בנויים לסוכנים, שניהם הושקו בתוך חודשיים זה מזה ב-2026, ושני הספקים מפרסמים מספיק בנצ'מרקים חופפים כדי שאפשר יהיה לערוך השוואה אמיתית ולא קולאז'. זה הופך את זה להתמודדות הנדירה שבה השאלה המעניינת היא לא איזה מודל טוב יותר אלא על איזה ציר עומס העבודה שלך באמת חי. מעט מאוד משימות זקוקות גם לציון BFCL של 71 וגם לציון SWE-bench של 57, ואלה שכן לא מקבלות שירות טוב מאף אחד מהמודלים לבדו.

שני המספרים שמצטלבים

Granite 4.2 30B הושק ב-25 באוגוסט 2026 תחת Apache 2.0, מודל dense בגודל ~30B שנבנה על הבסיס Granite 4.1 30B ואומן על כ-15 טריליון טוקנים. המיצוב של IBM הוא ארגוני: שלושה מצבי חשיבה ניתנים להגדרה, קריאה מקורית לכלים מול סכימת OpenAI, שתים עשרה שפות שנבדקו, וצינור אימון בן שלושה שלבים המסתיים בלמידת חיזוק GRPO רב-שלבית.

LFM3-1.7B הגיע חודשיים לאחר מכן, הוכרז ב-27 באוקטובר 2026, ואומן לאחר מכן ספציפית על רתמות סוכניות — Liquid מזכירה את Hermes Agent, PI ו-OpenClaw בכרטיס המודל. זהו מודל צפוף בנפח 1.73B עם הקשר של 256K, והוא ממוצב במפורש עבור סוכנים מקומיים וקריאה לכלים ולא עבור הסקה כללית.

החציה בין הבנצ'מרקים אינה מקריות של מספר חלש אחד. כל הטבלה שפרסמה LFM3-1.7B נוטה לצד הסוכני: 71.39 BFCL V4, 80.36 ToolSandbox, 68.01 τ³-bench, 45.60 LiveClaw, 38.42 WebArena-Verified. הטבלה של Granite נוטה לצד ההנדסי: 57.00 SWE-bench Verified, 33.29 SWE-bench Pro, 41.89 SWE-bench Multilingual, 38.76 SciCode, 29.24 ב-TerminalBench 2.1. כל ספק ביצע אופטימיזציה להגדרה אחרת של "סוכן", והטבלאות של הבנצ'מרקים כנות לגבי איזו הגדרה.

τ³ ב-68.01 מול 68.05 הוא הכותרת האמיתית

מתחת לשתי הפערים הדרמטיים מסתתר תיקו. ב-τ³-bench, הערכת השימוש בכלים שמודדת השלמת משימות רב-סיבוביות עם סימולטורי משתמשים ומדיניות תחומית, LFM3-1.7B מקבל 68.01 ו-Granite 4.2 30B מקבל 68.05 — הבדל של ארבע מאיות הנקודה, שלא ניתן להבחין בינו לבין רעש.

זהו תוצאה מעניינת יותר משני הפערים הגדולים, כי τ³ הוא אמת המידה הקרובה ביותר למה שרוב פריסות הסוכנים עושות בפועל: לנהל שיחה, לפעול לפי מדיניות, לקרוא לפונקציה הנכונה, להתאושש מטעות. אם מודל של 1.73B משתווה למודל צפוף של 30B בנקודה הזו, מספר הפרמטרים קונה משהו אחר מאשר שימוש מוסמך בכלי שיחה מרובת תורות.

מה שזה קונה בא לידי ביטוי ב-BFCL וב-SWE-bench, שמודדים דברים שונים. BFCL V4 בוחן נכונות של קריאה לפונקציה בתור יחיד מול סכימה — הציון 71.39 של LFM3-1.7B מרמז שאימון הפוסט-אימון של Liquid על מערכות הרצה אמיתיות של סוכנים השתלם ישירות. SWE-bench Verified בוחן תיקון של בעיית GitHub אמיתית מקצה לקצה, מה שדורש להחזיק מאגר קוד בהקשר, לתכנן על פני קבצים ולהפיק תיקון שעובר בדיקות — הציון 57.00 של Granite משקף מודל עם היכולת לעשות זאת וסט אימון שנבנה לשם כך.

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

ההקשר הוא המקום שבו המפרטים נבדלים זה מזה באופן החריף ביותר.

• הקשר — 262,144 טוקנים עבור LFM3-1.7B; 128K מקוריים עבור Granite 4.2 30B, עם הרחבה אפשרית ל-512K. ההרחבה אינה בחינם, ו-IBM מודה בכנות שמדובר בהרחבה ולא בחלון מקורי.

• שימור הקשר ארוך — 65.56 ב-RULER ב-128K עבור LFM3-1.7B לעומת 81.4 עבור Granite 4.2 30B באותה משפחת מבחנים. המודל הגדול יותר שומר על יותר ממסמך ארוך, וזה ההפך ממה שמספרי ההקשר הכותריים מרמזים.

• טביעת רגל — כ-1 GB ב-4 סיביות לעומת כ-30B של משקולות BF16, עם גרסאות רשמיות של FP8, NVFP4 ו-MXFP4. זהו מודל ל-GPU בודד, לא מודל למחשב נייד.

• שפות — שש עשרה עבור LFM3-1.7B לעומת שתים עשרה שנבדקו עבור Granite, עם חפיפה שונה. השתים עשרה של Granite כוללות צ'כית והולנדית; אלה של Liquid כוללות תאית, וייטנאמית ואינדונזית.

• מצבי חשיבה — Granite 4.2 30B מגיע עם מצב מלא, מצב מאמץ נמוך ומצב ללא חשיבה. ל-LFM3-1.7B אין תכונה כזו, והכרטיס שלו אומר שהוא לא מיועד מלכתחילה להסקה מורכבת מרובת שלבים.

• רישיון — Apache 2.0 עבור Granite מול LFM Open License v1.0, שהוא חינמי מתחת ל-10 מיליון דולר בהכנסות שנתיות ומחייב רישיון מסחרי מעל לכך.

אילו עלויות יש ל־30B dense שאין ל־1.73B

Granite 4.2 30B הוא מודל צפוף, כלומר כל שלושים מיליארד הפרמטרים פועלים על כל טוקן. אין כאן הנחה של פרמטרים פעילים: עלות החישוב לכל טוקן היא בערך פי שבעה עשר מזו של המודל הקטן, ועלות הזיכרון היא קובץ המשקלים המלא. IBM מספקת כימותים כדי להפוך זאת למעשי, אבל אין תצורה שבה הוא פועל על טלפון.

היתרון של LFM3-1.7B אינו בעיקר מהירות. הוא שהמודל נכנס לאותו תקציב זיכרון כמו שאר האפליקציה שלך. מודל בגודל 1 GB משאיר מקום למאגר מסמכים, למטמון ולמודל שני באותו מכשיר — וזה מה שהופך סוכן מקומי לאפשרי ולא רק למקומי באופן תיאורטי. Liquid מדווחת על פענוח מהיר פי 1.8 עד 2.8 מקודמיה בחומרה שנבדקה ועל מטמון KV בגודל 1.6 GB ב-128K, ושניהם חשובים לסוכן על-מכשיר שמנהל שיחה ארוכה.

מנגד, היכולת של 30B של Granite אכן עושה עבודה אמיתית בנתוני SWE-bench. אם תפקידו של הסוכן שלכם הוא לשנות קוד ברחבי מאגר, פער של 13.6 נקודות אינו משהו שמודל קטן יותר מפצה עליו באמצעות פרומפטים, והחיסכון בכוח מחשוב קונה לכם תוצאה גרועה יותר.

רישוי, חתימה ושאלת הרכש

Apache 2.0 הוא הסיבה שארגון גדול יכול לאמץ את Granite 4.2 30B בלי סקירה משפטית. אין סף הכנסות, אין טריגר מסחרי, אין משא ומתן. IBM גם חותמת קריפטוגרפית על מודלי Granite ששוחררו מאז אפריל 2026, מה שנשמע כמו פרט קטן עד שאתה האדם שצריך להוכיח שהמשקלים בייצור הם המשקלים שנבדקו.

רישיון LFM Open License v1.0 של Liquid הוא באמת מתירני בהיקף של סטארט-אפ — חינמי לשימוש מסחרי מתחת ל-10 מיליון דולר בהכנסות שנתיות — אך מעל לקו הזה הוא מחייב רישיון מסחרי בתשלום. עבור מפתח יחיד או צוות קטן, זו אינה בעיה. עבור יחידה עסקית בתוך חברה גדולה יותר, זהו שיח שמתחיל לפני הפריסה הראשונה ועלול לא להסתיים במהרה. האסימטריה הזו אינה באה לידי ביטוי באף בנצ'מרק ולעיתים קרובות מכריעה את השאלה בעצמה.

מריץ את שניהם בלי להמר על אף אחד

התבנית המעשית לצוות שמעריך את שני אלה היא לא לבחור אחד קודם. שניהם במשקולות פתוחות ושניהם לא הוכחו על ידי מעריכים עצמאיים, כלומר המדד היחיד שחשוב הוא שלכם. העבירו את המודלים המועמדים דרך נקודת קצה אחת, הריצו את אותם עקבות סוכן דרך שניהם, והשוו לפי המשימה שלכם ולא לפי BFCL או SWE-bench.

OrcaRouter שימושי כאן פחות כמארח ויותר כמשטח בקרה: מפתח אחד וחשבון אחד על פני יותר מ-200 מודלים, מחירי המחירון של הספקים מועברים הלאה בתוספת של 0%, ומעבר כשל אוטומטי כך שריצת הערכה לא תיעצר בגלל שספק אחד חווה שעה רעה. לא LFM3-1.7B ולא Granite 4.2 30B נמצאים בקטלוג שלנו היום — שניהם הורדות במשקלים פתוחים, ואחסון עצמי הוא המסלול עבור כל אחד מהם. המקום שבו הניתוב מצדיק את מקומו הוא המערך הסובב: מודל החזית שאליו הסוכן שלך מטפס, או הדעה השנייה שאיתה אתה משווה כשהתיקון של המודל המקומי נכשל בבדיקות שלו.

מי צריך לקחת איזה?

בחרו ב-LFM3-1.7B אם הסוכן פועל על המכשיר של המשתמש, אם העבודה היא קריאה לכלים וחילוץ מובנה מול API, ואם הקשר של 256K עם טביעת רגל של 1 GB הוא הדבר שהופך את המוצר לאפשרי. קבלו את האזהרה של הספק עצמו שהוא אינו מיועד לתכנות סוכני, והשאירו מאחוריו מודל גדול יותר למקרים שזקוקים לכך.

בחרו ב-Granite 4.2 30B אם הסוכן נוגע בבסיס קוד, אם אתם זקוקים ל-Apache 2.0 ולמשקולות חתומות לצורכי רכש, אם עומס העבודה מרוויח ממאמץ חשיבה הניתן להגדרה, ואם יש לכם GPU שעליו ניתן להריץ אותו. החסרון ב-BFCL אמיתי אך צר: הוא מודד נכונות סכימה בקריאה בודדת, ומודל 30B עם סכימת כלים מעוצבת היטב סוגר הרבה מהפער הזה בפועל.

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

השאלה ששווה לעקוב אחריה היא אם מתכון ה-post-training האייג'נטי של Liquid עובר לצ'ק־פוינט גדול יותר. אם מודל LFM עתידי ישמור על התנהגות BFCL ברמת 71.39 ויוסיף יכולת לעבודה עם מאגרי קוד, פיצול הצירים קורס וההשוואה הזו הופכת להחלטת גודל פשוטה. עד אז, שני המודלים לא מתחרים על אותה עבודה — הם שני החצאים של שלם אחד.