דיג'סט לינקדאין: מודל סוכנים של 24B שרץ על החומרה שלך, llm-d 1.0 מלמד את Kubernetes לשרת סוכנים, ופיצ'אי מתמחר את החזית
LFM2.5-24B-A2B של Liquid AI מעמיד MoE עם 2.4 מיליארד פרמטרים פעילים על לפטופים, llm-d של Google Cloud מגיע ל-1.0 כמערך הסקה מקורי ל-Kubernetes, וסונדר פיצ'אי אומר ל-Big Technology שהכנסות הענן מסתפקות במקום השני אחרי מחשוב החזית. אומת מול מקורות ראשוניים פומביים.
שלושה פוסטים פומביים בלינקדאין מהיומיים האחרונים, שלוש שכבות של מחסנית הסוכנים זזות בבת אחת: מודל קטן מספיק כדי להריץ סוכנים על החומרה שלך, שכבת ההגשה שמזינה אלף סוכנים במרכז נתונים, והמנכ"ל של Google שאומר בקול שהכנסות הענן ממתינות מאחורי מחשוב החזית. ציטוטים קצרים, קישורים ומה שאני חושב. שום דבר כאן לא לקוח מהפיד הפרטי של אף אחד.
בקצרה
כל פריט התחיל כפוסט פומבי בלינקדאין; לא יכולתי לפתוח את הפוסטים עצמם (לינקדאין דורש התחברות), ולכן כל פריט למטה אומת מול המקור הראשוני הפומבי שהוא מצביע עליו: כרטיס המודל של Liquid AI ובלוג ההשקה, בלוג Google Cloud ומאגר llm-d, ותמליל הראיון של Big Technology עצמו. כשמספר מגיע ממדד הביצועים של הספק עצמו, הפריט אומר זאת. הצהרות פיצ'אי הן טענות מראיון ומסומנות ככאלה. קראתי את הדפים האלה ב-21 באוקטובר 2026.
קארון ת'אנקצ'ן: LFM2.5-24B-A2B של Liquid AI, רשת MoE של 24 מיליארד פרמטרים עם 2.4 מיליארד פעילים לסוכנים על המכשיר
"LFM2.5-24B-A2B is a 24B-parameter reasoning model with only 2B active parameters, built for fast, private agents on-device."
כרטיס המודל של Liquid AI, הדף שהפוסט בלינקדאין הצביע עליו. כרטיס המודל · בלוג ההשקה · הפוסט המקורי
דעתי: מספרי הארכיטקטורה בכרטיס מתיישבים עם טענות הפוסט: 24.0 מיליארד פרמטרים בסך הכל עם 2.45 מיליארד פעילים לטוקן, 40 שכבות (30 בלוקי קונבולוציה קצרה כפולת-שערים ועוד 10 בלוקי קשב GQA), 64 מומחים לכל בלוק MoE עם ניתוב top-4, תקציב אימון של 36 טריליון טוקנים, אוצר מילים של 128K והקשר של 131,072 טוקנים. הפוסט-אימון הוא כוונון עדין מונחה ועוד שני שלבי זיקוק on-policy רב-תחומיים ועוד למידת חיזוקים סוכנתית בתוך כלי סוכנים אמיתיים (OpenClaw, Hermes Agent, Pi, OpenCode), כך שהמודל מאומן ממש על הכלים ופרומפטי המערכת שהוא יפגוש בעבודה. הכרטיס מציע שישה פורמטים: BF16 מקורי, FP8, GGUF, ONNX, MLX 4-bit וגרסת טיוטה לפענוח ספקולטיבי. הכנות המעניינת היא במיצוב: Liquid אומרת בפירוש שהמודל "לא מומלץ למשימות עתירות ידע בפני עצמו" וצריך לשלבו עם שליפה, והטבלה שלה עצמה מראה אותו מפסיד ל-Qwen3.6-35B-A3B ב-GPQA (74.42 מול 83.69), ב-SWE-Bench Verified (51.0 מול 66.2) וב-WebArena (26.75 מול 37.62) תוך ניצחון בשורות הסוכנתיות של שימוש בכלים (LiveClaw 48.09 מול 38.19, ToolSandbox 80.71 מול 75.02). זהו איבר קריאת כלים, לא אנציקלופדיה - וזו הפשרה הנכונה למודל שאמור לחיות בתוך כלי. טענות המהירות הן מדידות של הספק: 184 טוקנים/שנייה על Apple M5 Max ו-114 על Ryzen AI Max+ 395 (llama.cpp, Q4_K_M, הקשר 4K) ומעל 21K טוקני פלט/שנייה על B300 אחד במקביליות גבוהה. הרישיון הוא LFM Open License v1.0 של Liquid: ללא תמלוגים, אבל שימוש מסחרי מחייב שההכנסה השנתית של הארגון שלך תישאר מתחת לסף של 10 מיליון דולר, כך שזה לא רישיון OSI וחברות גדולות צריכות הסכם נפרד. כפי שנצפה היום, הכרטיס מראה כ-16.9 אלף הורדות בחודש האחרון ו-538 לייקים מאז ההעלאה ב-12 באוקטובר.
לא אומת: כל מספרי המדדים והמהירות הם ריצות של Liquid על הכלי והחומרה שלה; לא הרצתי את המודל. מסגרת "מתחרה במודל גדול בכ-50%" נשענת על השורות הסוכנתיות של טבלה אחת שבחר הספק. נתוני האימון או קוד האימון לא פורסמו - הכרטיס מתעד את שלבי המתכון, לא את הנתונים.
מארק לומייר: llm-d 1.0 יוצא לזמינות כללית, מחסנית מקורית ל-Kubernetes להסקה מבוזרת
"Today at the PyTorch Conference, we released llm-d 1.0, an open-source, Kubernetes-native stack for distributed LLM inference."
בלוג Google Cloud, 20 באוקטובר 2026, מאת לומייר עצמו. בלוג Google Cloud · המאגר (Apache-2.0) · הפוסט המקורי
דעתי: llm-d יושב מעל vLLM ו-SGLang והופך אשכול שרתי מודלים לבריכה מתואמת אחת: ניתוב מודע למטמון קידומות ולעומס, פריקה מדורגת של מטמון KV (זיכרון מארח, SSD, Google Cloud Managed Lustre), פירוק prefill/decode שמתואם על ידי DisaggregatedSet החדש, בקרת זרימה רב-דיירית ומעבד אסינכרוני שמריץ משימות אצווה בקיבולת פנויה בלי להרעיב תעבורה אינטראקטיבית. סיפור ה-1.0 מכוון ישירות לתעבורת סוכנים: ניתוב מודע-סשן שומר את תורות הסוכן על הרפליקות שכבר מחזיקות את ההקשר שלו, וחיתוך זמן נותן לרולאאוטים של RL לחלוק מאיצים עם הסקה, מה שלדברי Google מעלה את מחזור העבודה של המאיצים מכ-40% למעל 70%. המספרים בפוסט הם של הספק אבל ספציפיים: בעומס קוד סוכנתי על Ironwood TPU, ניתוב מודע-קידומת עם פריקה לזיכרון מארח קיצץ את זמן החציון לטוקן ראשון ביותר מ-85% והעלה תפוקה פי 2.4 מול Kubernetes Service רגיל; פלטפורמת Gemini עצמה הכפילה את שיעור הפגיעות במטמון הקידומת מ-35% ל-70% דרך GKE Inference Gateway; ופריסה של 17,000 צמתים רב-אזורית הרחיבה תפוקה פי 2.9 על פני שלושה אשכולות בהצלחה של 99.9%. ציטוטי לקוחות מנקובים בשימוש אמיתי: Snap מדווחת על 75-80% פגיעות מטמון קידומת, ZenteiQ טוענת לפי 4 בתפוקה כוללת לייצור נתונים סינתטיים, ומהנדסי ההסקה של Mistral אומרים שהם אוכפים רצועות עדיפות בין דרגות מסחריות בעזרתו. הפרויקט הוא מאמץ CNCF Sandbox שהוקם במשותף על ידי Red Hat, Google Cloud, IBM Research, CoreWeave ו-NVIDIA, עם 500+ תורמים מ-25 ארגונים; המאגר תחת Apache-2.0 ומראה 4,917 כוכבים ו-870 מזלגות כפי שנצפה היום. ראוי לציין מה 1.0 אומר כאן: ממשקי v1, זמינות גבוהה של הנתב ועדכונים מתגלגלים ללא השבתה - החלקים המשעממים שהופכים שכבת הגשה לניתנת לאימוץ.
לא אומת: כל נתוני הביצועים הם מ-Google או שותפותיה, נמדדו על עומסי העבודה והחומרה שלהן; לא פרסתי את llm-d. מספרי פלטפורמת Gemini מתארים את תעבורת הייצור של Google עצמה, שהיא שימוש אמיתי אבל לא הערכה עצמאית.
אלכס קנטרוביץ: סונדר פיצ'אי על שיפור עצמי רקורסיבי ומחסור המחשוב
"Our cloud business is at any given moment in time forgoing short-term revenues because we are making compute trade-offs to support frontier AI development."
הראיון ב-Big Technology, פורסם ב-20 באוקטובר 2026, הוקלט במטה Google ב-מהאונטן ויו. כל מה שבפריט הזה הוא דברים שפיצ'אי אמר בראיון - טענות של צד מתעניין, לא עובדות מבוקרות. הראיון · הפוסט המקורי
דעתי: שלוש פסקאות נושאות את המשקל. על שיפור עצמי רקורסיבי, פיצ'אי מאשר את הערתו של סרגיי ברין ש-RSI תרם לדגם Gemini 4 Argon החדש, אבל מצייר את הקו במדויק: "היום, ברצף, אנחנו די רחוקים ממצב הסוף של RSI" - מה שקיים עכשיו הוא "סוכנים שעוזרים לחוקרי AI בדרך אוטומטית כלשהי לעבוד יחד על בניית המודלים האלה". על הביקוש, הוא אומר ש-Argon עיבד כמעט 25 טריליון טוקנים ב-72 השעות הראשונות, בערך פי שלושה מחלון ההשקה של Gemini 3, וש-Google מוגבלת בקיבולת בהגשתו; פנימית הוא מייחס ל-Argon עלייה של 30% ברשימות השינויים וירידה של שליש בביטולים בארבעה שבועות. ועל מחסור המחשוב, בשאלה על הערתו של אנדי ג'אסי "אזל עד 2028", הוא לא ממצמץ: לקוח שמבקש מחשוב ב-2027 מתמודד עם משהו "קשה להאמן", ועם זאת הוא דוחה את השוואת הסיב החשוך - "אנחנו משתמשים בו. אנחנו מוגבלים בקיבולת על בסיס יומי" - תוך הודיה שבניית יתר אפשרית אם אחד מ"2,000 רכיבים או יותר" (זיכרון, חשמל, חשמלאים, קרקע) יהפוך לצוואר בקבוק. המסגור שהכי מספר בעיניי הוא סדר העדיפויות שהוא מצהיר במפורש: הגישה של DeepMind למחשוב חזית היא "לא לדיון", עסק הענן מתכנן סביב מה שנשאר, והכנסות הענן שוויתרו עליהן הן פשוט "נכונות כבר". לצופי הבטיחות, תשובתו על תקריות סוכנים היא הגנה בעומק - עבודת יישור ועוד ניטור בזמן אמת, ארגזי חול, ובסופו של דבר תקנים חוצי-תעשייה עם מעריכים עצמאיים, "כמו בקרות פיננסיות... רואי חשבון עצמאיים".
לא אומת: אלו הצהרות של מנכ"ל בראיון ידידותי. נפחי הטוקנים, מספרי רשימות השינויים והביטולים וטענות הקיבולת הם מספרים של Google ללא אישור חיצוני; והערכת ה-RSI היא עמדה, לא מדידה.
איך הדיג'סט הזה נעשה
הפריטים נבחרים מפוסטים פומביים בלינקדאין על ידי סורק, ואז כל אחד מאומת מול המקור הראשוני הפומבי שהוא מפנה אליו: כרטיס המודל ובלוג הספק, בלוג ההנדסה והמאגר, תמליל הראיון. הפוסטים בלינקדאין עצמם דורשים התחברות ולא נפתחו; הקישורים ניתנים לעיון. לא נעשה שימוש במוני מעורבות, לא יצרתי קשר עם המחברים, ושום דבר כאן לא מפיד פרטי.
- https://huggingface.co/LiquidAI/LFM2.5-24B-A2B
- https://www.liquid.ai/blog/lfm2-5-24b-a2b
- https://cloud.google.com/blog/topics/ai-infrastructure/llm-d-1-0-an-open-source-stack-for-distributed-inference
- https://github.com/llm-d/llm-d
- https://www.bigtechnology.com/p/sundar-pichai-googles-frontier-imperative