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

מאמרים שאולי תרצו לקרוא אחרי זה:
🔗 האם בינה מלאכותית אמינה? סרטון ובוחן
גלו את אמינות הבינה המלאכותית באמצעות סרטון מרתק ובוחן אינטראקטיבי.
🔗 כיצד להשתמש בבינה מלאכותית בחיי היומיום
גלו דרכים מעשיות שבינה מלאכותית יכולה לפשט משימות ושגרות יומיומיות.
🔗 כיצד להשתמש בבינה מלאכותית בעבודה.
למדו דרכים מעשיות להשתמש בבינה מלאכותית לפרודוקטיביות חכמה יותר במקום העבודה.
🔗 האם בינה מלאכותית יכולה לחשוב בעצמה?
להבין האם בינה מלאכותית יכולה באמת לחשוב באופן עצמאי או להסיק היגיון.
במה זה שונה ממרכז נתונים "רגיל"
אולמות מסורתיים ממטבים את עצמם לעומסי עבודה מעורבים וזמן פעולה בהרבה שירותים קטנים. אכפת לכם מיתירות, בוודאי, ומ-PUE כקונספט - אנרגיה נוספת שהבניין שורף כדי לספק וואט של מחשוב. בדרך כלל לא מתכננים כל מסדרון סביב מתלה שמתנהג כמו חוות חימום ניידת.
אתרי בינה מלאכותית הופכים את היחסים. הצפיפות עולה. הרשת הופכת למארג שעבודת האימון לא יכולה להתקדם בלעדיו. אחסון צריך לשמור על נקודות בדיקה בתנועה או שמאיצים יישארו ללא פעילות, כמו סוסי מרוץ בפקק תנועה.
יש גם הבדל תרבותי. תפעול ארגוני חושב על כרטיסים וחלונות שינוי. תפעול בינה מלאכותית חושב על תורי עבודה ועל התחושה החולנית כשצומת מת מאוחר בטווח ארוך. אני מניח שעדיין אפשר לקרוא לשניהם "מרכזי נתונים" כי הם כאלה. התווית פשוט מסתירה את הצנרת.
| סוּג | למה הוא בנוי | חומרה בולטת | אופי הספק/קירור | למי זה מתאים | למה זה קיים |
|---|---|---|---|---|---|
| מרכז נתונים ארגוני מסורתי | מערכות מידע מעורבות: מסדי נתונים, מכונות וירטואליות, דוא"ל, קבצים | מעבדים, שרתים רגילים, אחסון מוכר | מופעל על ידי אוויר; צפיפות צנועה; PUE כנושא שיחה | חברות המפעילות מערכות יומיומיות | שמרו על אפליקציות העסק פעילות |
| אשכול אימון בינה מלאכותית | עבודות הכשרה ארוכות ומשולבות היטב | מדפי מאיץ צפופים; חיבורי GPU | קירור נוזלי בצפיפות גבוהה או [מחליפי חום בדלת האחורית](https://datacenters.lbl.gov/sites/default/files/rdhx-doe-femp.pdf) | מעבדות ובוני מודלים החיים בתורי עבודה | סיים את הריצה בלי להרעיב את הצ'יפס |
| מתקן הסקה של בינה מלאכותית | הגשת מודלים; תשובות בזמן אמת ובאצווה | מאיצים; מאזני עומסים שחשובים | עדיין חם, רק... פחות תיאטרלי; השהייה על פני צפיפות ברוטאלית | מוצרים שחייבים לענות עכשיו | שים את המודל ליד המשתמש |
| אולם בינה מלאכותית היברידי | הכשרה ושירות תחת קורת גג אחת; ובכן - סוג של | מתקני שטח מעורבים; בריכות מגודרות; משטח משותף | שתי אישיויות מגניבות בחדר צמחים אחד; זה נהיה מביך | קבוצות שלא יכולות להרשות לעצמן שני קמפוסים | הון הוא סופי; החיים לא מסודרים |
לא דירוג מוסרי. מכונות שונות, אותו שם משפחה.
מעבדים גרפיים, מאיצים והארון שאוכל חשמל
הולכים על קומה מוגבהת מסורתית והמדפים נראים כמעט מנומסים. הולכים על שורה של בינה מלאכותית והם נראים כאילו הם רוצים לבלוע את הבניין.
החומרה הבולטת אינה מעבד חכם. זהו מגש המאיץ: מעבדים גרפיים או שבבי בינה מלאכותית אחרים, ארוזים בשרתים, אחר כך בארונות תקשורת, ואז בשורות שחולקים מארג רוחב פס גבוה. חיבורי מעבדים גרפיים מחברים שבבים למשהו שיכול להתחזות למאיץ ענק אחד; מארג האשכול עושה את אותו הטריק בקנה מידה של שורות. אימון מקבילי עובד רק אם קישורים אלה נשארים שמנים וצפויים. אם תאבדו את זה, ה"אשכול" שלכם הוא ערימה של תחנות עבודה יקרות שחולקות מיקוד.
הכוח עוקב אחר השבבים. לא יחידת חשמל משולשת במשרד. מגה-וואט של עומס IT ברגע שאולם מתמלא - אני לא אמציא מספר. צפיפות לכל מתלה היא הטוויסט בעלילה. פחות מתלים. כל אחד מהם כבשן קטן. הגורם המגביל הוא לעתים קרובות תחנת המשנה, לא רשימת המשאלות של הכרטיסים הגרפיים. אתם יודעים איך זה: רכש רוצה יותר מאיצים; חברת החשמל רוצה שיחה ארוכה וצ'ק גדול מאוד.
מטאפורה קצת טיפשית שאני לא יכול להיפטר ממנה: המדף הוא חיה רעבה. אפשר לגדל חיה מהירה יותר. עדיין צריך להאכיל אותה, ועדיין צריך לסלק את החום. אם דלגו על כל אחת מהן, היא הופכת למשקולת נייר יקרה מאוד.
בעיית החשמל, החום והקירור
חשמל נכנס. חום יוצא. זאת כל הדת.
מדפים בצפיפות גבוהה פולטים חום בצורה שאוויר מעולם לא באמת התבקש להתמודד איתה. אפשר לדחוף את האוויר חזק יותר - מחליפי חום בדלת האחורית, מעברים חמים יותר, בלימה חכמה - וזה עובד עד לנקודה מסוימת. ואז נוזלים מופיעים:
-
לולאות נוזל קירור שגורמות לחדר המפעל להיראות כמו מפעל כימי
-
טבילה בכמה עיצובים, שעדיין מדהימה אנשים שחושבים שמים ומלצרים לא צריכים לחלוק משפט
שום דבר מזה לא זוהר. הכל המוצר, כי על דוושת גז שמצערת כבר שילמתם ואי אפשר להשתמש בה במלואו.
PUE עדיין חשוב. זהו יחס, לא אישיות. מפעילים רודפים אחריו כי כל וואט שמבוזבז על מאווררים ומשאבות הוא וואט שלא הלך למעבד גרפי. אני לא אצטט נתון "טיפוסי"; האקלים ואיך משרטטים את הגבול מזיזים אותו, ודיוק מזויף גרוע יותר מכלום. גם מים נמצאים בסיפור. יש צמחים לוגמים. יש בולעים. קירור אידוי יעיל עד שהנהר או בצורת הופכים אותו לפוליטי.
נטוורקינג: למה הבד חשוב כמו השבבים
אנשים מצלמים את המעבדים הגרפיים. הם צריכים לצלם את המתגים.
אימון הוא שיחה. אלפי מאיצים מחליפים גרדיאנטים, פרמטרים, רסיסי מודל, בסנכרון הדוק. אם המארג רוטט, כל העבודה ממתינה לקפיצה האיטית ביותר. זו הסיבה שבתי בינה מלאכותית מתעסקים באובססיה ברשתות בעלות רוחב פס גבוה, השהייה נמוכה וטופולוגיות שלא מתקפלות לשניים כאשר קישור נכשל. מארגים בסגנון אינפיניבנד, אתרנט באותו תפקיד, חיבורי GPU בתוך הקופסה, כבלים שחייבים להיות נכונים בפעם הראשונה.
הסקה היא נושא אחר. הגשת מודלים דואגת לזמן השהייה של הזנב - התשובה האיטית, לא הממוצעת. אצווה לעומת זמן אמת מפצל את האישיות. אשכול אימונים רוצה תנועה שמנה, קולקטיבית, של הכל-להכל. צי משרת רוצה בקשות קטנות רבות ובידוד, ללא פקק תנועה במאזן העומסים.
ההחמצה, כל עוד אני כאן: אנשים מתייחסים לרשת כאל אינסטלציה ולצ'יפס כאל המסעדה. בבניין הזה האינסטלציה היא המסעדה. החמצה של זה וקונים מטבח שלא יכול לקבל משלוחים.
אימון לעומת הסקה: שני מבנים, לפעמים פשוטו כמשמעו
אימון הוא קמפיין. אתה מרכיב אשכול, מזין אותו לנתונים, מבצע בדיקות באדיקות, רץ במשך שעות או שבועות, ומתפלל שהמארג יישאר ללא אירועים מיוחדים. כבד בקבוצות, צמא לרוחב פס, סבלני בשקט - עד שצומת כושל נוגס בקצב. מאיץ אחד מת במשימה מחוברת היטב יכול לעצור את כל המקהלה.
הסקה היא חנות ראווה. מודלים שכבר אומנו, עונים כעת על שאלות, מסווגים תמונות, יוצרים טקסט. זמן השהייה חשוב. מאיץ מעט ישן יותר ליד הלקוח יכול לנצח מאיץ זוהר שנמצא במרחק יבשת.
אז מקבלים פיצול. קמפוסי אימונים רודפים אחר כוח, קרקע וצפיפות. אתרי הסקה רודפים אחר השהייה ונוכחות. קיימים גם אולמות היברידיים, כי הון אינו אינסופי. ובכן - לא תמיד שני בניינים. לפעמים אולם אחד עם חבל קטיפה ושתי לולאות קירור.
זה גם המקום שבו קולוקציה (colocation), קמפוסים היפר-סקייל (hyperscarel campus) ו-on-prem fork (מזלג מקומי). היפר-סקיילרים בונים בקני מידה שגורמים לשארנו להיראות כאילו אנחנו מסדרים רהיטים. קולוס (Colos) מוכרים צפיפות לפי מדפים. On-prem עדיין מתרחש כאשר הנתונים לא יכולים לצאת.
תפוקת אחסון, נקודות ביקורת ושבבים רעבים
אף אחד לא שם את מערכת הקבצים המקבילים על כריכת החוברת.
נתוני אימון צריכים להגיע מהר מספיק כדי שמעבדים גרפיים לא יקישו ברגליים. נקודות בדיקה צריכות לנחות כדי שקריסה לא תבזבז שבוע לפח. משקולות מודל צריכות להיטען לפני שהעותק המגיש פעיל. תפוקת אחסון - לא רק קיבולת - היא צוואר הבקבוק השקט. אפשר להוציא הון תועפות על מאיצים ולהרעיב אותם עם מערך מנומס שנועד למכונות וירטואליות.
הדפוס מוכר: אשכול מבריק, תור עבודה, וקלט/פלט ממתין בוהה בחזרה כמו חשבונית גסה. חישוב אשכולות מבלי לאשכול את נתיב הנתונים הוא הדרך להשיג מצב סרק יקר מאוד. שמור על צריכת השבבים או תודו שקניתם פסל.
תוכנה, תזמור ושכבת התפעול הלא זוהרת
חומרה היא הסלבריטאית. מתזמני עבודה עושים את העבודה.
מרכז נתונים של בינה מלאכותית חסר תועלת אם משימות לא יכולות למצוא מעבדים גרפיים, אם שני צוותים לא יכולים לחלוק אשכול בלי קרב אגרופים, אם לא ניתן להחליף דרגה שנכשלה, אם הקושחה נסחפת עד שהמארג נכשל בהילוך איטי. תזמור, יכולת תצפית, הגבלת צריכת חשמל - שכבת התפעול הלא זוהרת, וזו הדרך לדעת שזה חשוב.
יש לי חיבה לשכבה הזו. וגם, כשכרטיס רשת שגוי מתחזה לבעיית קירור במשך אחר צהריים שלם... מגלים את זה בדרך הקשה.
כאשר צומת מת באמצע ריצה
צומת מת. חלונות שינוי עדיין מתנגשים עם ריצות אימון שלא אכפת להן מהלוח שנה שלך. אתה מתזמן עבודות גדולות בצורה קבוצתית, מגדר מאגרי הסקה, כותב ספרי ריצה לכשלים שנראים כמו "המשימה איטית" עד שהם נראים כמו "המשימה מתה". יתירות עדיין חשובה - כוח, קירור, נתיבים, אחסון - אבל מצב הכשל פחות מסודר מהשקופית הישנה של תשיעיות זמן פעולה. הסקה: שכפול, ניקוז הצומת החולה, המשך מענה. אימון רוצה נקודות בקרה, לא אופטימיות.
מיקום, מים, רשת חשמל ושכנים
לא זורקים אחד כזה ליד בקתה בשביל הנוף.
חיבור לרשת החשמל הוא לעתים קרובות תהליך בחירת האתר האמיתי. קרקע היא קלה בהשוואה לתחנת משנה ולחברת שירות שיש לה לקוחות אחרים. מים לקירור, אם משתמשים בהם, הופכים לבעיה של השכנים ברגע שהגשם עז. רעש. נפח ויזואלי. חום בגדר גבול. ועדות תכנון מגלות דעות על "הענן" ברגע שהוא זקוק לשדה ולנהר.
השהייה מושכת את הכיוון השני. הסקה אוהבת להיות ליד משתמשים וחיבורים. הדרכה יכולה להסתתר בשווקי חשמל זולים יותר ואקלים קריר יותר. התעשייה מדברת כאילו יש אתר אחד מושלם. אין. יש פשרה בהודעה לעיתונות.
חום שנותר והתנור הלא מוזמן
חוברות אוהבות את החלק הזה. להזרים את החום הבזבוז לבתים, לבריכות, לחממות; זה משפט מקסים. לפעמים הלולאה המחוזית אמיתית. לפעמים הקמפוס נמצא במקום הלא נכון והחום עדיין עולה לאוויר. אני סקפטי לגבי גרסת החוברת; אני לא סקפטי לגבי הפיזיקה.
מי צריך אחד (ומי צריך לשכור במקום)
רוב האנשים לא צריכים להיות בעלי אחד מהאולמות האלה.
הרשימה הבוטה:
-
היפר-סקיילרים, כי המוצר הוא הצי
-
מעבדות, כאשר זמן התור הוא צוואר הבקבוק, או שהנתונים אינם יכולים לצאת
-
בנק, קבוצת בתי חולים, ממשלה או יצרן עם מערך נתונים סודי - באתר או בקולורדו פרטי - יכול להיות רציונלי, גם אם מדובר בטיפשות
כל השאר צריכים לשכור. מיקום משותף עם צפיפות מוכנה לבינה מלאכותית. הזמנה בענן. אשכול מנוהל. אתם מקבלים את המאיצים בלי להפוך גם למפעיל תחנת כוח. הרומנטיקה דועכת בפעם הראשונה שמישהו שואל מי בתורנות ללולאת נוזל הקירור בשעה 3 לפנות בוקר.
יש עניין של גאווה, אני מודה. להיות בעלים של האשכול מרגיש כמו להיות בעלים של אמצעי חיזוי. ואז מגיעה חשבונית החשמל, והגאווה יושבת.
למה נועד הבניין
אז מהו מרכז נתונים מבוסס בינה מלאכותית? קמפוס ייעודי וצפיף גבוה שבו מאיצים, חשמל, קירור, מארג ואחסון מאורגנים סביב מודלים של הדרכה והגשה - לא IT למטרות כלליות עם כרטיס מסך בפינה. זה נראה כמו מחסן. זה מתנהג כמו תחנת כוח שעושה חישובים.
אם אתם לא זוכרים שום דבר אחר: השבבים מקבלים את התהילה; תחנת המשנה, נוזל הקירור והרשת מחליטים אם השבבים האלה היו רעיון טוב. אימון והסקה יכולים לחלוק קורת גג; הם עדיין רוצים נימוסים שונים. רוב הארגונים צריכים לשכור. מעטים צריכים לבנות. שכנים ישימו לב כך או כך.
לענן תמיד היה בניין. בימים אלה לבניין יש דעות.
דוגמה מהעולם האמיתי: תא אימון בעל שני מעמדים כאשר התמונות אינן יכולות לעזוב
תַרחִישׁ
תומוס הוא ראש תחום התשתיות ב-Kestrel Precision, יצרנית בת 400 עובדים במערב המידלנדס. כבר יש להם אולם קטן מקומי: ERP, שיתופי קבצים, מכונות וירטואליות, השכונה המעורבת שהמאמר הזה התחיל איתה. קירור אוויר. אתרנט רגיל. SAN שמתאים בצורה מושלמת לדיסקים משרדיים.
צוות ראיית המכונה צריך לאמן מודל בדיקה על תמונות סטילס של מפעל. התמונות לא יכולות לעזוב את האתר. הן מראות תהליך שהחברה לא תעביר לדיסק ענן, אפילו לא דיסק פרטי. הפתרון של מחלקת הרכש הוא ארבעה שרתי מאיץ כפול ושקופית שכותרתה "מרכז הנתונים של בינה מלאכותית". השרתים נכנסים לשני מתלים קיימים, כי יש מקום, והמקום הרגיש כמו אילוץ.
זה לא נכון. תוך שבועיים, המעבדים הגרפיים נשמעים עסוקים ואז מתעצמים בשקט. משימות זוחלות כאשר נקודת ביקורת פוגעת ב-SAN. צומת מת בשעה אחת עשרה והריצה פשוט... נעלמת. תומוס לא הכחיש רכישת שבבים. הוא קנה ערימת תחנות עבודה יקרות שחלקו מיקוד. הבניין היה עדיין אולם ארגוני.
הם לא צריכים קמפוס, תחנת משנה חדשה או נהר. הם צריכים תא קטן שמתנהג כמו מרכז נתונים של בינה מלאכותית במיניאטורה: חשמל שהמדפים יכולים להכיל בפועל, חום שיוצא מבלי לבשל את השבבים, בד שדרכו משימת האימון יכולה לדבר, אחסון שיכול להכיל נקודת ביקורת, ו-runbook למקרה שצומת מת. מכיוון שהתמונות לא יכולות לעזוב, השכרת כלוב קולו במרחק ארבעים דקות נסיעה אינה התשובה. שדרוג של שני מדפים כן.
מה התא צריך
-
תקציב צריכת חשמל מדוד בשורה זו, מה-PDUs, לא מרשימת המשאלות של ה-GPU. אם הקיבולת הפנויה לא יכולה להזין את ארבעת השרתים בעומס האימון, השיחה נעצרת שם והם מסתכלים על צבע צפוף יותר, לא נס
-
קירור האוויר מעולם לא התבקש לטפל בצפיפות זו: מחליפי חום בדלת האחורית אם האולם יכול לעמוד בהם, או לולאת נוזלים קטנה אם היא יכולה לעמוד בכך במקום זאת. אם אף אחד מהם לא, השרתים לא נכנסים
-
מארג ייעודי בעל רוחב פס גבוה בין ארבעת הצמתים, לא ה-Ethernet של המשרד. אם לספק יש רק מתג של 10 ג'יגה-בייט בקטלוג, זה לא אשכול
-
אחסון מקומי מהיר עבור נקודות ביקורת ושרידי אימון, לא עבור SAN של VM
-
מתזמן, מרווח נקודות ביקורת ונתיב הפעלה מחדש כתוב. חומרה היא הסלבריטאי. שכבה זו היא העבודה
-
תיבת הסקה מגודרת עבור קו הייצור, נפרדת משיחת האימון, מכיוון שההגשה רוצה השהיית זנב ובידוד, לא קולקטיבית
-
הרשאה לרישום צריכת חשמל, שעוני GPU, אירועי מצערת ושעון קיר של משימות. אם הם לא יוכלו לבדוק אותם, הם יצלמו את ה-GPU ויפספסו את המתגים
הוראה לדוגמה
תומוס מנסח זאת בתדריך המתקנים, בשפה רגילה:
אל תקראו לזה קמפוס בינה מלאכותית. בנו תא אימון בן שני מתלים באולם הקיים עבור ארבעה שרתי מאיץ כפול. תמונות היצרן נשארות באתר. הצלחה היא: ארבעת הצמתים משלימים מתכון אימון-בדיקה בן 12 תקופות ללא מצערת תרמית, כותבים נקודת ביקורת תוך דקות ולא עשרות דקות, וחוזרים מנקודת ביקורת זו כשאנחנו הורגים דרגה בכוונה. קירור חייב לשמור על המעבדים הגרפיים בשעוני האימון שלהם. רשת חייבת להיות מארג שארבע הקופסאות הללו חולקות, לא נתיב דרך מחסנית המשרד. אחסון חייב להזין את השבבים. אם מחליפי חום בדלת האחורית לא יתאימו, אמור זאת ועצור. אל תצטט PUE עבור שני מתלים באולם מעורב. מספר זה יהיה תיאטרון.
אחר כך הוא מכניס את זה לתפקיד ההדרכה עצמו:
נקודת ביקורת כל 30 דקות לבריכה המהירה המקומית. אם דרגה מתה, יש להתחיל מחדש מנקודת הביקורת האחרונה שהושלמה. אין להמתין ל-SAN. אין להמשיך באימון בזמן שהשעונים ירדו מהחום. יש לרשום את התוצאה ולעצור כדי שנוכל לראות את הדוכן.
שעה טובה נראית כך: כל שמונת המעבדים הגרפיים בשעוני אימון, קובץ נקודת הביקורת הגיע, העבודה עדיין בקצב אחיד. שעה רעה נראית כך: מאווררים בקצב מלא, שעונים ירדו, נקודת ביקורת 2% כתובה אחרי עשר דקות, ומישהו במשרד אומר "האשכול פעיל". פעיל זה לא אימון.
איך לבדוק את זה
הם כותבים את המבחן לפני השיפוץ, וזו כל העניין של חוסר אמון בהדגמה.
-
אותו מתכון בן 12 תקופות, אותם 120,000 תמונות סטילס לבדיקה, שמונה ריצות
-
התזמון הוא שעון קיר עד למתכון גמור, כולל כל הפעלה מחדש, הנמדד משליחת המשימה ועד לנקודת הביקורת האחרונה של תקופה 12
-
ויתור על חום: שעוני ה-GPU נשארים ביעד האימון במהלך הריצה. אירוע מצערת נחשב לכישלון גם אם העבודה מסתיימת בסופו של דבר
-
פסילה על אחסון: זמן כתיבה בנקודת ביקורת, חציון וגרוע מכל, מיומן העבודה
-
פסילת בד: העבודה לא יושבת בהמתנה קולקטיבית כל עוד דרגה תקינה. אם הם לא יכולים לראות את ההמתנה הזו, המכשור לא הסתיים
-
שתיים מתוך שמונה ריצות זוכות להרג של דרגה בשלב קבוע, בכוונה, כדי לבדוק את נתיב ההפעלה מחדש
-
הסקה היא בדיקה נפרדת של 200 תמונות מקו היצרן ועד לתיבת ההגשה המגודרת. הצלחה באימון אינה נחשבת להצלחה בהגשה
-
הם רושמים את הספק המדף מה-PDUs בדגימות של 15 דקות, כך שאף אחד לא צריך להמציא מגה-וואט
קבלה לקריאה לתא "מוכן לבינה מלאכותית": 8 מתוך 8 מתכונים הסתיימו; 0 מתוך 8 מציגים מצערת תרמית; שתי ההרצה שנתקעו מתחדשות; נקודות הביקורת נשארות תוך דקות. אם הם מפספסים את זה, עדיין יש להם חדר שרתים עם כרטיסי מסך מפוארים.
תוֹצָאָה
תוצאה להמחשה, ממבחן מומצא של שמונה ריצות, לא נתון Kestrel שפורסם.
הנחות: ארבעה שרתי מאיץ כפול בשני מתלים; מודל בדיקה אחד; 120,000 תמונות סטילס; שמונה ריצות של מתכון קבוע בן 12 תקופות; שעון קיר כולל הפעלה מחדש עד לסיום המתכון; מצערת פירושה ירידה רשומה משעון האימון; זמן נקודת הבדיקה הוא הכתיבה, לא הרצון; צריכת החשמל במדף היא דגימות PDU, לא PUE בקמפוס.
לפני השיפוץ, מעבדים גרפיים במארזים רגילים מקוררי אוויר על גבי ה-Ethernet של המשרד ועל גבי ה-VM SAN:
-
5 מתוך 8 ריצות הסתיימו בניסיון הראשון. זמן שעון קיר חציוני בקרב חמשת הריצות הללו: 14 שעות
-
3 מתוך 8 נאלצו להתחיל מחדש לאחר קיפאון בסביבות השעה 11 (שניים לאחר שצומת מת עם נקודת ביקורת תקינה, אחד לאחר שנקודת ביקורת מילאה את ה-SAN). ניסיון חוזר מיידי, ללא המתנה של לילה בשעון: 11 שעות מבוזבזות ועוד ניסיון שני של 14 שעות, או 25 שעות עד למתכון גמור בשלושת הפעמים הללו
-
זמן ממוצע עד לסיום מתכון בכל שמונה המנות, כולל הפעלות מחדש: 18 שעות. (חמש ב-14, שלוש ב-25. החציון של כל השמונה הוא עדיין 14, מה שיסתיר את ההפעלות מחדש. זו הסיבה שהממוצע הוא קו הבסיס כאן.)
-
מצערת תרמית נרשמה ב-7 מתוך 8 ריצות. זמן חציוני בשעון מופחת: 3 שעות בניסיון של 14 שעות
-
כתיבת נקודת ביקורת: חציון 22 דקות
-
הריגת דרגה לא הייתה מבחן שהם יכלו לעבור. לא היה להם ספר ריצה. שני מקרי המוות בשוגג היו הממצא
-
עומס שיא של IT על שני המדפים במהלך האימון: כ-18 קילוואט. לחתירה היו הוואטים הנדרשים. לא היה לה קירור או מבנה
לאחר מחליפי חום אחוריים בשני המדפים הללו, מארג ייעודי בין ארבעת הצמתים, מאגר NVMe קטן עבור נקודות ביקורת, נקודות ביקורת של 30 דקות והפעלה מחדש של ספר ריצה:
-
8 מתוך 8 סיימו בניסיון הראשון. זמן שעון קיר חציוני: 9 שעות
-
מצערת תרמית: 0 מתוך 8
-
כתיבת נקודת בדיקה: חציון 90 שניות. הגרוע ביותר בסט: 3 דקות
-
שתי הריגות המכוונות של דרגה חודשו מנקודת הביקורת האחרונה של 30 הדקות. שעון קיר נוסף בשני הריצות הללו: כ-40 דקות כל אחת, כולל אבחון, כך ששני הריצות הללו ישבו קרוב ל-9 שעות ו-40 דקות. ממוצע על פני שמונה סיבובי תנועה ל-9 שעות
-
עומס שיא של IT עדיין כ-18 קילוואט. אותם שבבים. התנהגות בניין שונה
במדגם זה, זמן הביצוע הממוצע של מתכון ירד מ-18 שעות ל-9 שעות, או 9 שעות כל אחת, 72 שעות על פני שמונה ריצות. זמן הסיום הראשון עלה מ-5 מתוך 8 ל-8 מתוך 8. המצערת עלתה מ-7 מתוך 8 ל-0 מתוך 8. המספר האחרון הוא זה שאומר אם הם קנו מאיצים או משקולות נייר. הם לא יגידו ששינוי הזמן חיסכון של 50% בייצור. שמונה ריצות הן קבוצה קטנה וקלה.
נתונים אלה הם הערכה לדוגמה המבוססת על הבדיקה המצוינת, מדגם קטן, מודל אחד ואולם מעורב אחד. הם אינם PUE, לא מגה-וואט בקמפוס, ואינם הוכחה לכך ש-Kestrel צריכה לבנות אתר אימונים בשדה. סקירת הרישומים הייתה בתוך 9 השעות; הם לא הסתירו זאת. הנתון של 18 קילוואט הוא קריאת PDU מעוגלת, לא חשבונית שירות. הם לא המירו את 72 השעות לעלות, מכיוון שתעריף החשמל המעורב של המפעל היה יוצר תרחיש עסקי מזויף.
בדיקת ההגשה הייתה נפרדת וקטנה יותר: 200 תמונות קו לתא המגודר, כולן באתר. זוהי הסקה, לא אימון. ערבוב של השניים היה טעות של אולם היברידי במיניאטורה.
מה יכול להשתבש
-
צוות הרכש ממשיך לכנות ארבעה שרתים "מרכז הנתונים של בינה מלאכותית". התווית מסתירה את הצנרת, והרכישה הבאה היא עוד כרטיסי מסך לאותו מעבר חולים
-
מחליפי חשמל בדלת האחורית נכנסים ואף אחד לא מפעיל את צד המים. המאווררים עדיין צועקים. השעונים עדיין צונחים
-
המארג הוא מתג יחיד ללא נתיב פנוי. קישור אחד שנכשל וה"אשכול" הוא שוב ארבע תחנות עבודה
-
נקודות ביקורת נשארות ב-SAN מכיוון שמאגר ה-NVMe היה "שלב שני". שלב שני לא מגיע לפני הצומת המת הבא
-
הם מציעים יחס PUE עבור שני מדפים באולם מעורב. האקלים, הגבולות ושאר שורת ה-ERP הופכים את היחס הזה לתחפושת
-
אימון והגשה חולקים את הבד. הצפה בנקודת ביקורת גורמת לקו הייצור לחכות. השהיית הזנב היא התוצר שם, לא הצפיפות
-
צומת מת ומישהו מתייחס אליו ככרטיס זמן פעולה במקום כהפעלה מחדש של נקודת ביקורת. פעולות ארגוניות ופעולות בינה מלאכותית מדברות זו מול זו במשך אחר צהריים שלם
-
הם יכלו לשכור כלוב, אלא שהתמונות לא יכולות לעזוב. שכחה של אילוץ זה שולחת אותם לשיחת ענן שהם יצטרכו להירגע
טייק אווי מעשי
מהו מרכז נתונים של בינה מלאכותית, בצורה כזו, אינו מחסן ואינו חשבונית GPU. זהו התא שמאפשר למאיצים לסיים את הריצה: כוח שהם יכולים להחזיק, חום שעוזב, מארג, נקודת בקרה, ומישהו שעובד כשדרגה מתה. קסטרל לא הייתה צריכה קמפוס. הם היו צריכים שני מתלים כדי להפסיק להעמיד פנים. רוב הקבוצות צריכות לשכור את ההתנהגות הזו. מעטות, עם מערך נתונים סודי ואולם שיכול לעמוד בחום, צריכות לבנות תא ולסרב להחליק.
שאלות נפוצות
מהו מרכז נתונים של בינה מלאכותית?
אתר מחשוב בצפיפות גבוהה שבו כוח, קירור, רשת ואחסון כפופים סביב אימון מקביל והגשת מודלים, ולא שורות מסודרות של שרתים לשימוש כללי. הוא מתוכנן כך שמספר עצום של מאיצים יוכלו לאמן ולשרת מודלים מבלי להתמוסס, להיתקע ברשת או להמתין בדיסק. אולם ארגוני רגיל הוא שכונה מעורבת. אולם בינה מלאכותית הוא מונוקולטורה שיחידת הערך שלה היא המאיץ, כגון GPU או שבבים בסגנון TPU. הוא נראה כמו מחסן ומתנהג כמו תחנת כוח שעושה מתמטיקה.
במה שונה מרכז נתונים מבוסס בינה מלאכותית ממרכז נתונים רגיל?
אולמות מסורתיים ממטבים לעומסי עבודה מעורבים ולזמן פעולה על פני הרבה שירותים קטנים. אתרי בינה מלאכותית הופכים את היחסים: הצפיפות עולה, הרשת הופכת למארג שעבודת האימון לא יכולה להסתדר בלעדיו, והאחסון צריך לשמור על נקודות בדיקה בתנועה או שמאיצים יישארו ללא פעילות. תפעול ארגוני חושב על כרטיסים וחלונות שינוי. תפעול בינה מלאכותית חושב על תורי עבודה ועל התחושה החולנית כאשר צומת מת באיחור בטווח ארוך. עדיין אפשר להתקשר לשני מרכזי הנתונים. התווית פשוט מסתירה את הצנרת.
מדוע מרכזי נתונים של בינה מלאכותית צורכים כל כך הרבה חשמל?
החומרה הבולטת אינה מעבד חכם. זהו מגש המאיץ: מעבדים גרפיים או שבבי בינה מלאכותית אחרים, ארוזים בשרתים, אחר כך במדפים, ואז בשורות שחולקות מארג בעל רוחב פס גבוה. צפיפות למדף היא הטוויסט בעלילה: פחות מדפים, כל אחד כתנור קטן. מגה-וואט של עומס IT מופיע ברגע שאולם מתמלא, אם כי המצאת נתון טיפוסי אינה משתלמת. הגורם המגביל הוא לעתים קרובות תחנת המשנה, לא רשימת המשאלות של מעבדים גרפיים.
כיצד מקררים מרכזי נתונים של בינה מלאכותית?
מדפים בצפיפות גבוהה פולטים חום בצורה שאוויר מעולם לא באמת התבקש להתמודד איתה. ניתן לדחוף את האוויר חזק יותר בעזרת מחליפי חום אחוריים, מעברים חמים יותר ובלימה חכמה. ואז מופיע נוזל: קירור ישיר לשבב, לולאות נוזל קירור, וטבילה בכמה עיצובים. מאיץ שמצמצם הוא כזה שכבר שילמתם עליו ואינכם יכולים לנצל במלואו. PUE עדיין חשוב מכיוון שכל וואט שמבוזבז על מאווררים ומשאבות הוא וואט שלא הלך לכרטיס מסך. גם מים נמצאים בסיפור: חלק מהמפעלים לוגמים, אחרים בולעים.
למה רשתות חשובות כמו כרטיסי מסך?
אימון הוא שיחה: אלפי מאיצים מחליפים גרדיאנטים, פרמטרים ורסיסים של מודל בסנכרון הדוק. אם המארג רוטט, כל העבודה ממתינה לקפיצה האיטית ביותר. זו הסיבה שבתי קולנוע ביתיים מתעסקים באובססיה ברשתות בעלות רוחב פס גבוה, השהייה נמוכה, מארגים בסגנון InfiniBand או Ethernet באותו תפקיד, וטופולוגיות שלא מתקפלות לשניים כאשר קישור נכשל. הסקה דואגת להשהיית זנב, לבקשות קטנות רבות ולבידוד. בבניין הזה, האינסטלציה היא המסעדה.
למה משמש מרכז נתונים של בינה מלאכותית: אימון או הסקה?
אימון הוא קמפיין: הרכבת אשכול, הזנתו נתונים, ביצוע בדיקות מדויקות, והרצה במשך שעות או שבועות. הסקה היא חזית חנות: מודלים שכבר אומנו, עונים כעת, עם השהייה שחשובה. קמפוסי אימון רודפים אחר כוח, קרקע וצפיפות. אתרי הסקה רודפים אחר השהייה ונוכחות. אולמות היברידיים קיימים משום שהון אינו אינסופי, לפעמים אולם אחד עם שתי לולאות קירור. מאיץ מעט ישן יותר ליד הלקוח יכול לנצח מאיץ זוהר במרחק יבשת.
למה אחסון חשוב במרכז נתונים מבוסס בינה מלאכותית?
נתוני אימון צריכים להגיע מהר מספיק כדי שמעבדים גרפיים לא יקישו ברגליים. נקודות בדיקה צריכות לנחות כדי שקריסה לא תבזבז שבוע לפח. משקולות מודלים צריכות להיטען לפני שהעותק המגיש פעיל. תפוקת אחסון, לא רק קיבולת, היא צוואר הבקבוק השקט. אפשר להוציא הון תועפות על מאיצים ולהרעיב אותם עם מערך מנומס שנועד למכונות וירטואליות.
מה קורה כאשר צומת מת באמצע ריצה?
מאיץ אחד מת במשימת אימון צמודה יכול לעצור את כל המקהלה. אימון רוצה נקודות ביקורת, לא אופטימיות. הסקה מרוקן את הצומת החולה, שומר על רפליקה עונה, ונשארת פעילה. חלונות שינוי עדיין מתנגשים עם ריצות אימון שלא אכפת להן מהלוח שלך. יתירות עדיין חשובה עבור צריכת חשמל, קירור, נתיבים ואחסון, אבל מצב הכשל פחות מסודר מהשקופית הישנה של תשיעיות זמן פעולה.
מהי השפעת מרכז נתונים מבוסס בינה מלאכותית על רשת החשמל, המים והשכנים?
חיבור לרשת החשמל הוא לעתים קרובות תהליך בחירת האתר האמיתי. קרקע היא קלה בהשוואה לתחנת משנה ולחברת שירות שיש לה לקוחות אחרים. מים לקירור, אם משתמשים בהם, הופכים לבעיה של השכנים ברגע שהגשם גס, יחד עם רעש, גוש ויזואלי וחום בגדר גבול. הכשרה יכולה להסתתר בשווקי חשמל זולים יותר ובאקלים קריר יותר. הסקה מעדיפה להיות ליד משתמשים. אין אתר אחד מושלם. יש פשרה בהודעה לעיתונות.
האם אני צריך להיות הבעלים של מרכז נתונים מבוסס בינה מלאכותית, או שמא כדאי לי לשכור?
רוב האנשים לא צריכים להיות בעלי אחד מהאולמות האלה. מעבדות היפר-סקיילר בונות כי המוצר הוא הצי. מעבדות בונות כאשר זמן התור הוא צוואר הבקבוק או שהנתונים לא יכולים לצאת. בנק, בית חולים, ממשלה או יצרן עם מערך נתונים סודי יכולים להפוך את תהליך הניהול של קולוקציה מקומית או פרטית לרציונלי. כל השאר צריכים לשכור: קולוקציה מוכנה לבינה מלאכותית, הזמנה בענן או אשכול מנוהל. אתם מקבלים את המאיצים מבלי להפוך למפעיל תחנת כוח.
הפניות
-
סוכנות האנרגיה הבינלאומית - www.iea.org
-
LBNL - datacenters.lbl.gov
-
הרשת הירוקה - www.thegreengrid.org
-
LBNL - datacenters.lbl.gov
-
LBNL - datacenters.lbl.gov
-
מכון זמן פעילות - journal.uptimeinstitute.com
-
NVIDIA - developer.nvidia.com
-
NVIDIA - docs.nvidia.com
-
NVIDIA - docs.nvidia.com
-
NVIDIA - docs.nvidia.com
-
גוגל קלאוד - docs.cloud.google.com