LFM3-1.7B על vLLM: כעבור תשעה ימים, התמיכה הנייטיבית עדיין שני PRs פתוחים

של Liquid AILFM3-1.7Bהושק ב-27 באוקטובר 2026 עם כרטיס מודל שמציג את vllm serve "LiquidAI/LFM3-1.7B" כאילו היה פקודה רגילה. תשעה ימים לאחר מכן, ל-vLLM במעלה הזרם אין ארכיטקטורת Lfm3ForCausalLM שתאפשר להריץ אותו. מה שקיים במקום הוא בקשת תכונה שנפתחה ב-30 באוקטובר, בקשת משיכה אחת של kernel שכל השאר נשען עליה, ושש בקשות משיכה פתוחות למודלים — שתיים מהן מיישמות את אותו מודל טקסט LFM3-1.7B בשתי דרכים שונות, ואף אחת מהן לא מוזגה.

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

הכרטיס אומר vLLM. טבלת הדגמים הנתמכים אומרת LFM2.

תיעוד המודלים הנתמכים של vLLM עצמו מפרט שלוש ארכיטקטורות של Liquid AI: Lfm2ForCausalLM, Lfm2MoeForCausalLM ו-Lfm2VlForConditionalGeneration. אין רשומה של LFM3. לעומת זאת, בכרטיס של LFM3-1.7B נאמר שה-checkpoint "עובד עם vLLM, SGLang, ובנייני llama.cpp תואמי LFM3", וניתנת פקודת הגשה ללא דגלים.

ההתאמה נמצאת בקונפיגורציה של ה-checkpoint עצמו.‏ LFM3-1.7B נושא auto_map שמצביע על modeling_lfm3.py המצורף איתו, כך שהקוד בצד של Hugging Face קיים ומשכפל את עצמו אל תוך loaders שמתירים קוד מרוחק. גיליון המעקב של vLLM עבור ההעברה, #64645 — "[Feature]: Support LiquidAI LFM3 models", שנפתח ב-30 באוקטובר על ידי abhijithneilabraham — חד וברור לגבי התוצאה: "אין ל-vLLM ‏Lfm3ForCausalLM." החלופה המופיעה בו היא פתח המילוט שרוב האנשים יגיעו אליו בסופו של דבר החודש: "להריץ את LFM3 דרך הקוד המרוחק של ה-checkpoint עם ה-backend של Transformers. זה מוותר על paged attention ועל מטמון מצב ה-conv."

הפשרה הזו ראויה להיאמר במפורש, מפני ש"פועל על vLLM" ו"פועל על ה-backend של transformers של vLLM" הם מוצרים שונים. Paged attention הוא המנגנון שמאפשר ל-vLLM לקבץ בקשות באורכים שונים מאוד ללא בזבוז זיכרון KV; מטמון מצב הקונבולוציה (conv state cache) הוא אותו רעיון מיושם בשכבות הקונבולוציה הקצרות של ארכיטקטורה זו. הסר את שניהם ותקבל endpoint עובד שוויתר על שתי הסיבות לקיומו של vLLM. עבור מודל 1.7B המוגש בעומס מקבילי נמוך זה אולי סוף שבוע קביל, לא תצורת ייצור קבילה.

מדוע מודל 1.7B זקוק בכלל לעבודת קרנל

LFM3-1.7B אינו כיוונון מחדש פשוט של משפחת LFM2 שכבר מוגשת על ידי vLLM. זהו מודל היברידי בעל עשרים וארבע שכבות עם שלושה סוגי שכבות ולא שניים: 13 שכבות קונבולוציה קצרות עם שער, 5 שכבות קשב עם חלון הזזה בגודל 256 טוקנים, ו-6 שכבות קשב מלא. קונפיגורציית ה-checkpoint מפרטת את הגאומטריה במפורש — conv_L_cache: 7, sliding_window: 256, אוצר מילים של 128K — ורשימת ההבדלים של ה-issue ב-vLLM מוסיפה QK RMSNorm, שער פלט קשב סיגמואידי לכל ראש, נרמול סנדוויץ', ו-RoPE חלקי (partial_rotary_factor: 0.5) בשכבות הקשב המלא, בפריסה באותה צורת "זנב אפס" שבה משתמשת Gemma 4.

המספר ששבר את היציאה הוא שבע. הקונבולוציה הקצרה של LFM2 היא ברוחב שלושה טפים; LFM3 הרחיב אותה לשבעה. קרנלי ה-causal_conv1d של Triton ב-vLLM פורשים קבוצה קבועה של רוחבים, וכפי שמנוסח ב-issue המעקב: "קרנל ה-prefill של causal_conv1d ב-Triton פורש רוחבים 2 עד 4 וקרנל ה-decode פורש 2 עד 6, כך שמודל ברוחב 7 אינו יכול לרוץ על CUDA היום."

אז ה-PR הראשון בערימה אינו מודל כלל. #64647, "[Kernel] Support width-7 causal conv1d", נפתח ב-30 באוקטובר על ידי abhijithneilabraham, נוגע בשני קבצים ומוסיף 186 שורות: הוא מרחיב את קרנל ה-prefill מרוחבים 2–4 ל-2–7 ואת קרנל ה-decode מ-2–6 ל-2–7, וגורם לשתי העטיפות להעלות ValueError עבור כל דבר מחוץ לטווח הזה. תיאור ה-PR עצמו מסביר מדוע הדחייה חשובה לא פחות מההרחבה: לפני השינוי, "משקל רחב יותר רץ בלי ענף מתאים והחזיר ערכים שגויים." השחתה מספרית שקטה היא כשל גרוע יותר מסירוב, והיא מסוג הדברים שמתגלים רק במודל שבמקרה ניסית.

אזהרה אחת ראויה ללוות את ה-PR הזה. מחברו מציין בפשטות שאין לו מכונת CUDA: מסלול הייחוס ב-CPU עובר 96 בדיקות, גרעיני ה-Triton נבדקו בניתוח סטטי על ה-AST של הגרעין, ואימות ה-GPU נותר ל-CI. זהו גילוי נאות ולא פגם, אך משמעות הדבר היא שהשינוי היחיד שכל שאר ה-PR-ים של LFM3 תלויים בו טרם נבחן על החומרה שעליה רוב הקוראים יריצו אותו.

שני מימושים של אותו מודל טקסט

בתוך שישה ימים, שתי קבוצות נפרדות כתבו תמיכה מקורית ב-LFM3 עבור vLLM. הן אינן וריאציות של טלאי אחד; אלו עיצובים עצמאיים שבמקרה מתקינים את אותו שם ארכיטקטורה.

PR #64959, "[מודל] הוספת LiquidAI LFM3 (Lfm3ForCausalLM)", נפתח ב-1 בנובמבר על ידי atmikshetty, הוא השמרני מביניהם: שבעה קבצים, ולפי תיאורו שלו הוא עושה שימוש חוזר ב-ShortConv ברוחב 7, ב-Lfm2MLP, בממפה המשקלים של LFM2 וב-RoPE הפרופורציונלי הקיים, מבלי לשנות רכיבי ליבה. הוא רושם את המודל במרשם, מוסיף אותו למערך בדיקות המודלים ההיברידיים ולטבלת המודלים הנתמכים, ומתעד — באופן שימושי למי שיצליח להריץ אותו — את דגלי ה-serving שאיתם אימת: --reasoning-parser qwen3 --tool-call-parser qwen3_coder --enable-auto-tool-choice. סעיף האימות שלו מדווח על 324 בדיקות kernel שעוברות על A100-SXM4-40GB ב-BF16, על בדיקות מרשם ואתחול שעוברות, ועל השוואת הסתברות לוגריתמית מול רפרנס ה-remote-code של Hugging Face.

PR #65826, "[Model] Add LFM3-Text", נפתח ב-5 בנובמבר על ידי paulpak58 — שהוא Liquid AI — הוא הגרסה של הספק עצמו: עשרה קבצים ו-829 שורות שהוספו, כולל מחלקת ה-config שלו תחת transformers_utils/configs/lfm3.py ומודול הבדיקות שלו. הוא נפתח כ-"[Model] Add LFM3" ושמו שונה באותו יום כאשר המשפחה פוצלה לארבעה PRs מוערמים: #65826 לטקסט, #65827 ל-vision-language, #65828 לאודיו ו-#65829 ל-omni, כאשר כל אחד נבנה על קודמו.

שני הדברים אינם נמצאים בסתירה אלא מקבילים זה לזה, והדיון מציג בבירור את רשת התלויות. ב-PR של ה-kernel, paulpak58 כתב ב-4 בנובמבר: "יש לנו PRs פנימיים משלנו עבור מודלי LFM3, אבל זו תוספת נקייה שאנחנו יכולים לתמוך בה." ב-PR הטקסט של הקהילה, abhijithneilabraham העלה שהמיזוג עשוי לדרוש קודם מיזוג של עבודת ה-transformers של Liquid — "אני מאמין שמיזוג ה-PR הזה דורש את ה-PR של transformers מ-@paulpak58" — ועל כך השיב atmikshetty ש-Lfm3Config עדיין לא נמצא בגרסת transformers, ולכן הענף "טוען את התצורה דרך trust_remote_code מהנקודת ביקורת, וההרצה משתמשת במודל vLLM המקורי." זהו השער השני שרוב הקוראים לא היו חושבים עליו: אפילו PR ממוזג של vLLM זקוק למחלקת תצורה שמגיעה במקום כלשהו.

בצד של transformers ה-PR המקביל הוא #50322, "[Model] LFM3 Family: LFM3-Text", שנפתח ב-3 בנובמבר ועדיין פתוח, ופוצל מ-PR משפחתי גדול יותר. ההערה שלו עצמו על הקונבולוציה תואמת את ה-issue ב-vLLM: ה-conv הקצר הוא "torch-only ב-LFM3 (קרנלי causal_conv1d ב-Hub משרתים רוחבים 2-4, LFM3 משתמש ב-7)".

גם ראייה-שפה משוכפל. מלבד #65827 של Liquid, PR עצמאי של LFM3-VL (#65450, נפתח ב-3 בנובמבר) עדיין פתוח ותלוי ב-PR הטקסט של הקהילה. לכן נכון להיום יש שישה PR-ים פתוחים של LFM3 בשני מחנות, ואף אחד מהם לא מוזג.

מה שבאמת פועל היום

בלי הספקולציות, התמונה המעשית ב-5 בנובמבר נראית כך.

• vLLM, נייטיבי — לא אפשרי בבנייה סטנדרטית. אין Lfm3ForCausalLM ברישום, אין שורה של LFM3 בטבלת המודלים הנתמכים, וה-PR שיוסיף אותה טרם מוזג.

• vLLM, backend של transformers — הפתרון המתועד, תוך שימוש בקוד המרוחק המצורף של ה-checkpoint וב-trust_remote_code. אתה מאבד paged attention ואת מטמון מצב ה-conv; אתה שומר על השרת התואם ל-OpenAI.

• SGLang — נתיב השרת של הספק עצמו. פרסום ההשקה של Liquid מודד את נתוני התפוקה שלו על NVIDIA B300 בודד ב-BF16 עם SGLang, כולל 3.6 מיליארד טוקנים ליום ב-1,024 בקשות במקביל. vLLM מופיע באותו פרסום רק כריצה שעליה הוגשו מודלים מתחרים.

• llama.cpp — הכרטיס מתייחס ל"גרסאות בנייה תואמות LFM3 של llama.cpp", שזו הסתייגות אמיתית ולא מלל תבניתי; הנתונים של Liquid על המכשיר הם llama.cpp ב-Q4_0 עם חלון הקשר של 32K.

• MLX — הערות השחרור 0.33.0 של פרויקט vLLM-Metal הנפרד מפרטות נקודות שמירה (checkpoints) של טקסט LFM3 ב-MLX, מאחורי --trust-remote-code. מדובר בבסיס קוד שונה מ-vLLM במעלה הזרם, והוא אינו מרמז על תמיכה ב-CUDA.

• מתארח — ה-API ומגרש המשחקים של Liquid עצמה. הכרטיס אינו מספק מחירון, ולכן עלות לכל טוקן אינה משהו שניתן לתקצב על סמך חומר ציבורי.

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

מה היה משנה את זה, לפי הסדר

שרשרת התלויות נקייה באופן יוצא דופן, מה שהופך את מה ששווה לעקוב אחריו לספציפי במיוחד. ראשית #64647 חייב להתמזג, כי כל PR אחר של LFM3 או כולל את אותו קומיט או מוערם עליו. אחר כך אחד משני PR-י הטקסט חייב לנצח בסקירה — לזה של הקהילה יש רשומת אימות מלאה יותר, ולזה של Liquid יש את המחבר שגם אחראי על צד ה-transformers. אחר כך Lfm3Config חייב להיכנס למהדורה של transformers, אחרת כל פריסה תמשיך להעביר trust_remote_code. רק לאחר מכן LFM3-VL-2B, LFM3-Audio-2B ו-LFM3-Omni-2B הופכים למציאותיים, והם נמצאים מאחורי PR-ים נוספים שמניחים שמודל הטקסט כבר בפנים.

אין לקרוא את כל זה כביקורת על הקצב. תשעה ימים מהשקה ועד למערך PR שלם ומנוסה של קרנל ומודל הם מהירים, והעובדה ששני צוותים בלתי תלויים הפיקו מימושים עובדים בפחות משבוע אומרת יותר על עד כמה LFM3 נמצא קרוב ל-LFM2 מאשר על איזה עיכוב. אבל כרטיס מודל הוא הצהרת תאימות, והקריאה הכנה של מצבו של LFM3-1.7B היום היא "תואם ל-vLLM דרך ה-backend של transformers", לא "נתמך על ידי vLLM".

אם אתה זקוק למודל קטן לקריאת כלים השבוע

LFM3-1.7B הוא דבר מושך לרצות. המספרים שמדווח הספק חזקים בדיוק במקומות שבהם מודלים קטנים בדרך כלל נכשלים — 71.39 ב-BFCL V4, 80.36 ב-ToolSandbox, 96.66 ב-IFEval, 43.40 ב-SWE-bench Verified — לעומת ממוצע כולל של 49.37 שלדברי Liquid מקדים את ה-LFM2.5-2.6B שלה עצמה, שעומד על 31.55. אלו ההערכות של הספק עצמו, שנערכו על ידי החברה שבנתה את המודל, בלי שחזור בלתי תלוי ובלי רשומה ב-Artificial Analysis שמצאנו נכון להיום; יש להתייחס לדירוג כהשערה ולנתונים הבודדים כטענות. ההסתייגות הנלווית מגיעה מאותו מקור: כרטיס המודל ממליץ להימנע מקידוד סוכני ומהסקה מורכבת מרובת שלבים, ובנצ'מרקי הידע תומכים בהמלצה הזו — 63.37 ב-GPQA Diamond ו-65.56 ב-RULER ב-128K אינם המספרים של מודל כללי.

אז ההחלטה היא למעשה לא באמת לגבי המודל. היא לגבי השאלה אם אתה יכול להרשות לעצמך לבנות על מסלול הגשה שכרגע הוא בקשת משיכה פתוחה. אם אתה יכול להריץ SGLang או llama.cpp, אתה יכול להשתמש ב-LFM3-1.7B כבר היום ושאלת vLLM היא אקדמית. אם הסטאק שלך הוא vLLM לפי מדיניות, אתה בוחר בין היעדר paged attention ב-backend של transformers לבין המתנה.

יש אפשרות שלישית שראויה לציון עבור עומסי העבודה שלא יכולים להמתין: לנתב משהו אחר. OrcaRouter לא מציע את LFM3-1.7B — בדיקה של הקטלוג שלנו היום מחזירה יותר מ-200 מזהי מודלים, ואף אחד מהם אינו של Liquid — אז זו לא הצעה להפעיל אותו דרכנו. הנקודה הפשוטה יותר היא ש-PR קרנל שלא מוזג הוא נקודת כשל בודדת גרועה לנתיב ייצור. הצבת API אחד עם מעבר אוטומטי במקרה כשל לפני מודל מתארח עולה לכם שינוי תצורה, ומאפשרת לכם להחליף ל-LFM3-1.7B ביום שבו התמיכה המקורית בו תמוזג, ולא ביום שבו תסיימו להמר עליו. אם אתם משנים את המודל ולא רק קוראים לו, הגרסה שלנו LFM3-1.7B-abliterated היא אבלציה בכיוון סירוב של אותו checkpoint, והיא יורשת בדיוק את מצב ההגשה הזה.

הגרסה הקצרה

LFM3-1.7B יצא, קטן, ומתאים היטב למשימות קריאה לכלים בסיבוב בודד שאליהן אומן. התמיכה שלו ב-vLLM נכתבת ממש עכשיו, בידי שני צוותים, מעל הרחבת kernel שעדיין לא הורצה על CUDA בידי מי שכתב אותה. שימו לב קודם ל-#64647 — כאשר קונבולוציית הרוחב 7 תתמזג, שאר הסטאק יזוז מהר, וההצהרה "works with vLLM" בכרטיס המודל תפסיק להיות אמירה על קוד מרוחק ותתחיל להיות אמירה על paged attention ו-batching. עד אז, כל מי שמצטט "תמיכת vLLM מיום הראשון" עבור המודל הזה מצטט משהו שהמאגר עדיין לא מכיל.