AI לא חי בענן ציבורי: למה ה־Bare-Metal חוזר למרכז הבמה?

AI חי על חומרה, לא על מושג שיווקי

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

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

אני אומר את זה מתוך כמעט 20 שנות עבודה עם שרתים, לינוקס, רשתות, אחסון, אבטחה ומערכות ייצור: AI אינו “חי בענן”. הוא חי על מעבדים, זיכרון, GPU, דיסקים ורשת. הענן הוא מודל צריכה וניהול מעל החומרה. הוא כלי חשוב, אבל הוא לא חוק טבע.

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

הענן הציבורי הוא כלי מצוין. הבעיה מתחילה כשהוא הופך לדת

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

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

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

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

למה דווקא ההסקה היא המקום שבו החשבון מתחיל לכאוב

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

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

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

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

החיסכון הגדול מתחיל בניצולת, לא במחיר החומרה

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

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

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

ביצועים: ה־GPU הוא רק חלק מהסיפור

אחת הטעויות הנפוצות היא לבחור תשתית AI לפי שם הכרטיס בלבד. שני שרתים עם אותו GPU יכולים להציג ביצועים שונים מאוד בגלל ארבע שכבות אחרות.

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

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

זה מתחבר גם למאמר על RTX Spark והרצת AI מקומית: ההחלטה אינה רק “איזה GPU לקנות”, אלא כמה זיכרון נגיש למודל, איך הנתונים זזים ומה קורה כשהמערכת עובדת לאורך זמן.

Bare Metal מודרני אינו אומר לוותר על וירטואליזציה

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

Proxmox או VMware יכולים לנהל את התשתיות הכלליות. שכבת ה־GPU יכולה לרוץ כצמתי Kubernetes פיזיים, או כמכונות וירטואליות עם העברת GPU ישירה כאשר נדרשת הפרדה חזקה. מדריך הניהול הרשמי של Proxmox VE מפרט את שכבות הווירטואליזציה, הקונטיינרים, האחסון והניהול שעליהן אפשר לבנות את החלק הכללי של הסביבה.

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

הקצאת GPU ישירות לקונטיינרים ב־Kubernetes

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

בשרת GPU מגדירים דרייברים, סביבת ריצה מתאימה ותוסף התקן. לאחר מכן Kubernetes יכול לזהות את הכרטיס כמשאב שה־Pod מבקש. התיעוד הרשמי להקצאת GPU בקוברנטיס מסביר גם איך לתייג צמתים לפי סוג מאיץ ולהצמיד עומס לחומרה המתאימה.

צריך להיזהר מהבטחה של “שיתוף GPU” כאילו מדובר במעבד רגיל. שני מודלים שמתחרים על אותו כרטיס יכולים לפגוע זה בזה בזיכרון ובזמן התגובה. התיעוד של NVIDIA על שיתוף GPU מבהיר את ההבדל בין חלוקת זמן, שאין בה בידוד זיכרון או תקלות, לבין MIG שמייצר מחיצות חומרה מוגדרות בכרטיסים תומכים.

כאן נכנסת העבודה התפעולית האמיתית. תזמון נכון כולל תוויות לפי סוג GPU ונפח זיכרון, מניעת עומסים כלליים מלהתיישב על שרתים יקרים, הצמדת שירותים לצמתים מתאימים ועדיפויות בזמן תחזוקה. Autoscaler יכול להוסיף Pods, אבל הוא לא מייצר GPU יש מאין. בתשתית פיזית קיבולת היא עובדה שצריך לתכנן.

איך מבצעים אופטימיזציה אמיתית לשרת AI ייעודי

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

אחר כך מגיעות הגדרות הקושחה וה־BIOS, התאמה בין גרסת Kernel, דרייבר GPU, סביבת הקונטיינרים וספריות התקשורת. בעולם AI קל ליצור “מרק גרסאות” שבו עדכון קטן שובר תאימות. לכן סביבת ייצור צריכה Image אחיד, תשתית כקוד וחלון שדרוג עם בדיקה מוקדמת.

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

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

יציבות מלאה היא תוצאה של תכנון, לא הבטחה של ספק

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

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

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

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

אבטחה ושליטה בנתונים

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

אבל “אצלנו” אינו אומר “מאובטח”. תשתית עצמאית דורשת הקשחה, הפרדת רשתות, ניהול זהויות, אימות רב־שלבי, ניהול סודות, עדכונים, סריקות חולשות ולוג ביקורת. ממשק ניהול של Hypervisor או BMC שנחשף בצורה לא נכונה הוא סיכון משמעותי.

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

מתי הענן עדיין הבחירה הנכונה

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

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

הארכיטקטורה החזקה ביותר היא לרוב היברידית

הדיון אינו חייב להסתיים בבחירה בין “הכול בענן” ל“הכול אצלנו”. ארכיטקטורה היברידית שמה כל עומס במקום שבו הוא נכון כלכלית ותפעולית.

שכבת ההסקה הקבועה יכולה לרוץ על שרתי Bare Metal. פיתוח, ניסויים ואימון זמני נשארים בענן. בעת קפיצה בביקוש אפשר להפנות חלק מהתעבורה לספק חיצוני. CDN, DNS והגנת DDoS יכולים להמשיך לפעול בענן גם כאשר מנוע ה־AI יושב בסביבה פרטית.

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

איך מקבלים החלטה לפני שמזמינים עוד GPU

לפני רכישת שרת או התחייבות נוספת לספק ענן, מתחילים במדידות של 30 עד 90 יום: שימוש ב־GPU, עומסי שיא, שעות פעילות, קצב גידול, זמן תגובה, נפח נתונים, תעבורה ועלות מלאה. לאחר מכן בונים תרחישים: המשך בענן, מעבר חלקי, מעבר מלא ומודל היברידי.

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

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

Bare Metal אינו חזרה לעבר. הוא שלב הבשלות של תשתית AI

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

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

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