גוגל, Red Hat ו-IBM משיקות את llm-d 1.0: תשתית פתוחה להרצת מודלי שפה בקנה מידה גדול
גוגל, Red Hat ו-IBM שחררו את llm-d 1.0, מחסנית בקוד פתוח שמריצה מודלי שפה גדולים על גבי Kubernetes ומפזרת את העבודה בין שרתים רבים. הגרסה כוללת ניתוב שמתחשב במטמון, בקרת עומסים לכמה לקוחות במקביל, שדרוגים בלי השבתה ותמיכה גם ב-TPU וגם ב-GPU.
גוגל, Red Hat ו-IBM השיקו את llm-d 1.0. מדובר במחסנית תוכנה בקוד פתוח (open source) להרצה מבוזרת של מודלי שפה גדולים (LLM), שנבנתה מראש לעבודה בתוך Kubernetes. זה לא מודל חדש. llm-d היא שכבת התשתית שמחליטה איך מודלים קיימים ירוצו על צי של מאיצים: לאיזה שרת תגיע כל בקשה, איך מחלקים משאבים בין כמה לקוחות, ואיך מעדכנים את המערכת בלי להשבית אותה.
מה יש בגרסה
לפי הדיווח ב-MarkTechPost, הגרסה מוסיפה כמה יכולות מרכזיות:
- ניתוב מודע-מטמון (cache-aware routing): הבקשות מנותבות לפי מה שכבר נמצא בזיכרון המטמון של כל שרת.
- בקרת זרימה מרובת-דיירים (multi-tenant flow control): ניהול עומסים כשכמה לקוחות או אפליקציות חולקים את אותה תשתית.
- שדרוגים ללא השבתה (zero-downtime upgrades): אפשר לעדכן את המערכת בלי להפסיק לשרת משתמשים.
- ניתוב מודע-סוכנים (agent-aware routing): ניתוב שמותאם לעומסי עבודה של סוכני AI.
המחסנית עובדת עם שני מנועי הרצה פופולריים בקוד פתוח, vLLM ו-SGLang, ותומכת גם במעבדי TPU של גוגל וגם ב-GPU.
למה מטמון משנה כל כך הרבה
כדי להבין את הניתוב המודע-מטמון צריך מעט רקע. כשמודל שפה מעבד טקסט, הוא שומר חישובי ביניים בזיכרון. אם אותה הנחיית מערכת, אותו מסמך ארוך או אותה שיחה חוזרים בבקשה הבאה, אפשר להשתמש שוב בחישובים האלה במקום לבצע אותם מחדש. מנתב רגיל, שמפזר בקשות בין שרתים בלי לדעת מה כל אחד מהם כבר חישב, מפספס את החיסכון הזה. ניתוב שמכוון כל בקשה לשרת שכבר מחזיק את המידע הרלוונטי יכול לקצר את זמני התגובה ולחסוך בכוח חישוב. ההנחה הזו עומדת בבסיס הגישה, אם כי המקור לא מפרט נתוני ביצועים.
סביר שהדגש על סוכנים קשור לאותו היגיון. סוכן AI שולח בדרך כלל רצף ארוך של בקשות שכל אחת נשענת על ההקשר של קודמתה. זה בדיוק התרחיש שבו שימוש חוזר במטמון אמור להשתלם במיוחד.
שלושה שחקנים, תשתית אחת
השותפות עצמה מעניינת. Kubernetes, מערכת הניהול של קונטיינרים שגוגל פיתחה במקור, הפכה לסטנדרט בפריסת תוכנה בענן. Red Hat, שנמצאת בבעלות IBM, היא אחת השחקניות הבולטות בעולם ה-Kubernetes הארגוני. הצירוף של השלוש יוצר ככל הנראה מסה קריטית מספיק כדי ש-llm-d תהפוך לשכבת ברירת מחדל להרצת מודלים בארגונים שכבר עובדים עם Kubernetes.
התמיכה בשני סוגי המאיצים ראויה לתשומת לב. מבחינת גוגל, כלי פתוח שמריץ עומסים גם על TPU וגם על GPU מקטין את החיכוך במעבר לחומרה שלה. לקוחות לא יצטרכו לכתוב מחדש את שכבת הפריסה כדי לנסות אותה.
המשמעות
בשנים האחרונות התחרות ב-AI התמקדה בעיקר במודלים עצמם. אבל בארגון שמריץ מודל עבור אלפי משתמשים, החשבון הכלכלי נקבע במידה רבה בשכבת ההרצה: כמה בקשות כל מאיץ מצליח לשרת, כמה חישובים מבוצעים פעמיים בלי צורך, וכמה זמן המערכת מושבתת בזמן עדכונים.
מספר הגרסה 1.0 מאותת ככל הנראה שהפרויקט נחשב בשל לשימוש בסביבות ייצור. אם llm-d תיקלט בתעשייה, היא עשויה לעשות להרצת מודלי שפה את מה ש-Kubernetes עשתה לקונטיינרים, ולהפוך פתרונות פנימיים שכל חברה בנתה לעצמה לתקן פתוח ומשותף.