פרויקט llm-d פרסם ב־20 באוקטובר 2026 את גרסה 1.0 — תשתית קוד פתוח, מבוססת Kubernetes, שנועדה להפעיל מודלי שפה וסוכני AI בקנה מידה גדול על כמה שרתים ומאיצים. החידוש המרכזי אינו מודל חדש, אלא שכבת תזמור שמנסה להפוך inference מבוזר לשירות שניתן להפעיל, לשדרג ולנטר בסביבת ייצור.
תמונת המחשה: נוצרה באמצעות AI עבור ITPortal
מהו llm-d?
llm-d מחבר בין מנועי הגשת מודלים כמו vLLM ו־SGLang לבין Kubernetes. במקום לשלוח כל בקשה לשרת אקראי, המערכת יכולה להתחשב בעומס, במיקום ה־KV cache ובהקשר שכבר נמצא בזיכרון של כל replica. המטרה היא לצמצם חישוב חוזר ולנצל טוב יותר מאיצים יקרים.
לפי צוות הפרויקט, בגרסה 1.0 השתתפו יותר מ־500 תורמים מיותר מ־25 ארגונים. בין הגופים המעורבים בפרויקט נמצאים Google, Red Hat ו־IBM. הפרויקט נמצא ב־CNCF Sandbox, ולכן ארגונים צריכים לבחון את רמת הבשלות וההתאמה שלהם ולא להתייחס למספר גרסה 1.0 כהבטחה אוטומטית ליציבות בכל סביבה.
מה נוסף בגרסה 1.0?
- בקרת עומסים מרובת דיירים: תעדוף והוגנות בין בקשות אינטראקטיביות, עבודות רקע וסוכנים שמייצרים עומסים מתפרצים.
- API יציב בגרסת v1: בסיס מוגדר יותר לאוטומציה ולפריסה חוזרת.
- שדרוגים ללא השבתה מתוכננת: זמינות גבוהה של רכיב הניתוב ו־rolling updates המתואמים בין רכיבי prefill ו־decode.
- ניתוב שמודע לסוכנים: התחשבות בסשן ובהקשר בין צעדים, כדי להחזיר בקשות לשרתים שכבר מחזיקים את המידע הרלוונטי בזיכרון.
- תמיכה בתשתיות מעורבות: הפרויקט מציג עבודה עם GPU של כמה יצרנים ועם Google TPU, ובעננים ובסביבות מקומיות.
למה inference של סוכנים קשה יותר מצ'אט רגיל?
בצ'אט פשוט מתקבלת בקשה ונוצרה תשובה. סוכן יכול לבצע רצף ארוך של צעדים, להפעיל כלים, לחזור עם תוצאות ולשלוח בקשות נוספות שחולקות חלק גדול מאותו הקשר. כאשר כל צעד נשלח לשרת אחר, המערכת עלולה לטעון ולחשב שוב מידע שכבר עובד במקום אחר.
llm-d מנסה לפתור זאת באמצעות ניתוב שמכיר את ה־prefix ואת מיקום המטמון, הפרדה בין שלב ה־prefill הכבד בחישוב לבין שלב ה־decode שמושפע יותר מזיכרון, ואפשרות להעביר מטמון בין זיכרון המאיץ, זיכרון המארח ואחסון מהיר.
מה דיווחה Google על הביצועים?
Google הציגה בהדגמה 1,000 סוכנים מבודדים שפנו לנקודת קצה אחת מעל vLLM, SGLang ותמהיל של TPU ו־GPU. החברה דיווחה גם על שיפור של יותר מ־85% בחציון הזמן עד לטוקן הראשון ועל תפוקה גבוהה פי 2.4 בתרחיש agentic coding מסוים, בהשוואה ל־Kubernetes Service רגיל. אלו תוצאות שפורסמו על ידי Google בסביבה מוגדרת, ולא הבטחה לביצועים זהים אצל כל ארגון.
למי זה רלוונטי?
הפרויקט מתאים בעיקר לארגונים שמפעילים מודלים פתוחים בעצמם, מחזיקים כמה מאיצים או אשכול Kubernetes וצריכים לשרת משתמשים או סוכנים רבים. לצוות קטן שמריץ מודל יחיד על GPU אחד, המורכבות התפעולית עלולה להיות גבוהה מהתועלת.
לפני אימוץ כדאי למדוד זמן עד לטוקן ראשון, תפוקה, שיעור פגיעה במטמון, צריכת זיכרון, עלות לכל מיליון טוקנים והתנהגות תחת עומסי שיא. יש לבדוק גם בידוד בין דיירים, הרשאות, רישום לוגים ותהליך חזרה לאחור במקרה של שדרוג כושל.
לא פתרון קסם לעלות ה־AI
ניתוב חכם ומטמון משותף יכולים לשפר ניצול חומרה, אך הם אינם מחליפים תכנון קיבולת. מודלים גדולים עדיין דורשים זיכרון, רשת מהירה ותפעול Kubernetes ברמה גבוהה. הבחירה הנכונה תלויה בעומס, במודלים, בחומרה ובדרישות זמינות — ולא רק במספרי benchmark.
לקריאה נוספת על הפעלת מודלים על חומרה ייעודית, ראו את הכתבה שלנו על TorchNeuron ו־Trainium של AWS.
