בשנים האחרונות, ארגונים משקיעים סכומים משמעותיים בפיתוח יכולות AI מודלים מתקדמים, pipelines מורכבים, צוותים של data scientists ומהנדסי ML.
אבל ברגע האמת, כשהמערכות עולות לעומס אמיתי, מתחילים להופיע סימנים מטרידים: זמני training מתארכים, ניצול GPU נמוך מהצפוי, latency לא יציב ולעיתים גם קריסות לא מוסברות.
התגובה הראשונית היא בדרך כלל לבדוק את הקוד, את המודל או את הדאטה.
אבל בפועל, במקרים רבים, הבעיה עמוקה יותר היא נמצאת בתוך חוות השרתים או הדאטה סנטר שבו הכל רץ.
האשליה המרכזית: “יש לנו חוות שרתים, זה מספיק”
רוב חוות השרתים בישראל ובעולם נבנו בעידן שבו workloads היו מבוססי CPU, יחסית יציבים וצפויים.
המעבר ל-AI, במיוחד ל-GPU clusters מבוזרים, שינה את כל חוקי המשחק:
צריכת חשמל לא ליניארית, עומסי חום קיצוניים, ותעבורת רשת פנימית אינטנסיבית.
הפער הזה לא תמיד נראה בשלב התכנון.
הוא מתגלה רק כשהמערכת מתחילה לעבוד באמת.
חסם ראשון: שרשרת אספקת החשמל (Power Delivery) שלא תוכננה ל-GPU
אחד מצווארי הבקבוק הקריטיים ביותר נמצא בשכבה הפיזית ביותר החשמל.
GPU nodes מודרניים, במיוחד עם כרטיסים כמו H100, רגישים מאוד ליציבות מתח, transient spikes ולחלוקת עומסים מדויקת בין phases.
בחוות שרתים שלא תוכננה לכך מראש, מופיעות תופעות כמו:
- נפילות מתח רגעיות בזמן peak load
- חוסר איזון בין A/B feeds
- עומסים על PDU שאינם מותאמים לצפיפות גבוהה
התוצאה לא תמיד דרמטית מיד. לעיתים מדובר בירידה הדרגתית בביצועים throttling, errors ברמת הדרייבר או קריסות של nodes בודדים.
אבל בקלסטר מבוזר, גם תקלה קטנה יכולה להפיל training job שלם.
חסם שני: דינמיקה תרמית ו-hotspots מקומיים
AI לא סובל חום והוא גם לא סולח עליו.
כאשר מספר GPUs עובדים יחד באותו רק, נוצרת צפיפות חום גבוהה מאוד באזור קטן. מערכות קירור מבוססות אוויר מתקשות לפזר את החום בצורה אחידה.
הבעיה החריפה היא היווצרות של hotspots אזורים בתוך הרק שבהם הטמפרטורה גבוהה משמעותית מהממוצע.
במצבים כאלה:
- GPU מוריד clock frequency
- נכנס ל-thermal throttling
- ביצועי training נפגעים באופן ישיר
האתגר הוא שלא תמיד רואים את זה במערכות ניטור כלליות.
צריך מדידה granular ברמת רכיב.
חוות שרתים תת קרקעית יכולה לספק יציבות תרמית טובה יותר, אך ללא שילוב של פתרונות כמו Direct-to-Chip cooling או RDHx גם זה לא מספיק.
חסם שלישי: ארכיטקטורת רשת שלא בנויה ל-East-West Traffic
אחד השינויים הגדולים ב-AI הוא דפוס התעבורה.
במקום תעבורה של משתמש לשרת, אנחנו מקבלים תקשורת אינטנסיבית בין שרתים בתוך חוות השרתים עצמה.
ב-training מבוזר, nodes צריכים לסנכרן ביניהם מידע בקצב גבוה מאוד.
כאשר הרשת לא מתוכננת לכך למשל עם oversubscription גבוה או ללא InfiniBand / RoCEv2 נוצרים צווארי בקבוק:
- קפיצות latency
- איבוד חבילות
- jitter
גם עיכוב קטן מצטבר להשפעה משמעותית על זמן האימון הכולל.
חסם רביעי: שכבת Storage שלא עומדת בקצב
AI הוא data hungry.
מודלים גדולים דורשים קריאה וכתיבה של כמויות עצומות של דאטה, לעיתים בצורה אקראית ולא רציפה.
כאשר חוות שרתים מסתמכת על storage מסורתי:
- SAN קלאסי
- NAS ללא NVMe
נוצר מצב שבו GPUs פשוט ממתינים לדאטה.
התוצאה:
- ניצול GPU נמוך
- זמני training ארוכים
- בזבוז משאבים
פתרונות כמו NVMe over Fabrics, parallel file systems (Lustre, GPFS) ו-data prefetching הופכים להיות קריטיים.
חסם חמישי: מגבלות Topology וחוסר גמישות תפעולית
AI workloads אינם סטטיים. הם משתנים, מתרחבים, ולעיתים דורשים scaling מהיר.
חוות שרתים שתוכננה בצורה קשיחה עם מגבלות על power zoning או network topology — יוצרת חסמים שקשה מאוד לעקוף.
זה מתבטא בכך שכל שינוי קטן דורש התאמות פיזיות מורכבות, ולעיתים בלתי אפשריות.
דוגמה מהשטח: הכל נראה תקין אבל הביצועים לא שם
ארגון שמקים סביבת AI עם חומרה מתקדמת מאוד GPUs, storage מהיר, רשת טובה — אך בתוך חוות שרתים שלא תוכננה לעומסים האלה, יראה תוצאה מפתיעה:
- GPU utilization סביב 40–50%
- latency לא יציב
- training time כפול מהצפוי
לאחר מעבר לדאטה סנטר תת קרקעי ממוגן, עם תשתית חשמל מותאמת, קירור מתקדם ורשת ללא צווארי בקבוק אותם workloads מגיעים ל-80–90% utilization, וזמני האימון מתקצרים דרמטית.
בישראל: שכבת מורכבות נוספת
כאשר מדברים על חוות שרתים בישראל, נכנסים גם שיקולים שלא קיימים בכל אזור:
- רגולציה וריבונות מידע
- תלות בקישוריות בינלאומית
- מציאות ביטחונית
לכן, דאטה סנטר תת קרקעי ממוגן, עם network diversity ויכולת פעולה עצמאית, הופך להיות חלק בלתי נפרד מהתכנון.
סיכום
AI לא סלחני כלפי תשתיות.
הוא חושף כל צוואר בקבוק בחשמל, בקירור, ברשת וב-storage.
הכשל של רוב פרויקטי AI לא יהיה במודל, ולא בצוות.
הוא יהיה בחוות השרתים.
ומי שלא מזהה את החסמים האלה בזמן מגלה אותם כשהמערכת כבר בפרודקשן, כשהעלות של תיקון גבוהה משמעותית.