מהו TensorCast, ולמה הוא עשוי לשנות את תשתיות ה-AI?

TensorCast היא הצעה לשכבת Tensor-as-a-Service (TaaS) — מערכת מבוזרת וניתנת לתכנות שמנהלת את מחזור החיים של טנסורים: זיהוי, בעלות, מיקום, העברה, שינוי, שכפול ושיתוף. הרעיון המרכזי הוא להוציא את ניהול מצב הטנסורים ממנוע החישוב שמייצר אותם או משתמש בהם. 1

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

הבעיה ש-TensorCast מנסה לפתור

מודלי שפה גדולים משתמשים בכמה סוגים של מצב טנסורי:

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

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

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

איך המערכת בנויה?

טנסורים כאובייקטים מן השורה הראשונה

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

פעולות שניתן להרכיב למדיניות

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

הפרדה בין מדיניות למנגנון ביצוע

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

הפרדה בין מישור הבקרה למישור הנתונים

רכיב ה-Global Store (GS) מנהל מטא-דאטה של האשכול — למשל מצב השרתים וה-Workers, מיקום הטנסורים, הבעלות עליהם ומידע הנדרש לתזמון. ה-Workers עצמם מבצעים את העברת המידע בפועל.

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

לסוגי נתונים שונים מוצעות גם אסטרטגיות מטא-דאטה שונות. משקלים, שהם אובייקטים מעטים ויציבים יחסית, יכולים להיות מנוהלים באופן מרכזי. לעומתם, KV Cache הוא מצב דינמי ורב-פריטים, ולכן הוא מחולק בין Workers; Worker ייעודי לכל חלוקה מנהל בעלות ועקביות באמצעות חוזי lease ואסימוני fencing. 1

מה תפקיד ה-RDMA והגישה ללא העתקות מיותרות?

TensorCast מנסה לצמצם את מספר ההעתקות הנדרשות בעת מימוש טנסור בזיכרון של יעד. העתקים מקומיים יכולים לחשוף זיכרון GPU באמצעות CUDA IPC, או זיכרון CPU באמצעות ידיות מקומיות מסוג memfd. כאשר המקור מרוחק, המערכת תומכת בכתיבה ישירה באמצעות RDMA — גישה שמאפשרת להעביר נתונים ישירות ליעד במקרים המתאימים. 6

התוצאה האפשרית היא שיתוף יעיל יותר בין תהליכים ובין GPUs, וכן מסלולי העברה מקומיים או ישירים כאשר החומרה והתצורה מאפשרות זאת. 6

מדוע העברת KV Cache נעשית פשוטה יותר?

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

ב-TensorCast, מדיניות יכולה לזהות את אובייקטי ה-KV של אותה שיחה, לבקש למקם ולממש אותם אצל ה-Worker היעד, ואז להפנות אליו את הבקשות הבאות. סביבת מחזור החיים מטפלת באיתור הנתונים, בהעברתם ובחיבורם לזיכרון היעד. 1

היתרון אינו בכך שההעברה הופכת לחינמית. העלות של העברת נתונים עדיין קיימת. החידוש הוא שהמדיניות נכתבת פעם אחת בשכבת מחזור החיים, במקום להיות משוכפלת בכמה רכיבים התלויים זה בזה. כך קל יותר לבנות מדיניות שמביאה בחשבון בו-זמנית את קרבת ה-KV Cache, שימוש חוזר במשקלים ומיקום משותף של מצבים קשורים. 1

מה הראו הניסויים?

החוקרים שילבו את TensorCast עם שני מנועי הסקה מוכרים, vLLM ו-SGLang, ובחנו טעינת משקלים לזיכרון, סנכרון משקלים, ניהול KV Cache וניתוב בקשות שניתן לתכנת. 1

לפי תוצאות המחקר:

• ביצועי ניהול ה-KV Cache היו תחרותיים מול Mooncake, מערכת ייעודית לניהול מטמון כזה, תוך שמירה על היכולת ליישם מדיניות שחוצה כמה רכיבי תוכנה. 1
• בהפעלת מופע של Qwen3-235B-A22B, מודל הכולל 235 מיליארד פרמטרים, מתוכם 22 מיליארד פרמטרים פעילים, זמן האתחול היה מהיר עד פי 228.6 בהשוואה למערכות קבצים מבוזרות נפוצות. 12
• בעומסי עבודה של סוכנים מרובי-סבבים ובמקביליות גבוהה, מדיניות TensorCast ניתנת לתכנות הפחיתה לפי הדיווח את זמן ההמתנה החציוני עד לטוקן הראשון (TTFT) בשיעור של עד 93.2%. 1

מה המשמעות לתשתיות AI?

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

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