כלי הנתונים הסטטיסטיים של Megascale

אתם יכולים להשתמש בכלי Megascale Stats כדי לנתח את ביצועי התקשורת בין חלקי TPU שונים בעומסי עבודה שמתפרסים על פני כמה חלקי TPU ומתקשרים ברשת של מרכז הנתונים (DCN).

כל המדדים שמוצגים בכלי Megascale Stats נוצרים על בסיס כל TPU.

פלטפורמות נתמכות

כלי הנתונים הסטטיסטיים של Megascale נתמך רק ב-TPU.

מונחים שקשורים לקהילות

בכלי מוצגים מדדים שקשורים לתקשורת בין חלקי TPU, שכוללת את הפעולות הבאות:

• ‫send: קוטע את הפעולה של המארח כדי להתחיל גישה ישירה לזיכרון (DMA) ומספק למארח מאגר מלא כדי להתחיל בהעברת נתונים.
• ‫send-done: אות שמסמן למארח שהעברת הנתונים הושלמה.
• ‫recv: מספק מאגר ריק למארח כדי למלא אותו בנתונים שהועברו.
• ‫recv-done: אות שמציין למארח שהנתונים התקבלו.

פעולה קולקטיבית מתחילה בפעולה send ומסתיימת בפעולה recv-done התואמת. השליחה בפועל של הנתונים מתבצעת אחרי שהפעולה send מסתיימת. הפעולה send-done מתרחשת אחרי שהנתונים נשלחים. באופן דומה, הנתונים מתקבלים אחרי שהפעולה recv מסתיימת. הפעולה recv-done מתרחשת אחרי קבלת הנתונים.

רכיבי ממשק

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

• שם קולקטיבי של DCN: מוקצה על ידי XLA.
• שם פעולת הקבלה: שם הפעולה של TPU‏ recv-done. כך אפשר לחפש בקלות ב-Trace Viewer את הפעולות המתאימות של TPU.
• שם הפעולה לשליחה: שם הפעולה של TPU‏ send.
• זמן השהייה: מוגדר כזמן שאינו תלוי ברשת, שבו יש לכלל להעביר את הנתונים. המדד הזה מייצג את הזמן שזמין לקולקטיב לשליחה ולקבלה של נתונים, לא כולל הפעולות send, send-done, recv או recv-done. הגדלת הזמן הפנוי מפחיתה את הסיכויים לעיכוב של ה-TPU עבור קולקטיב. לדוגמה, אם ציר הזמן הוא כזה:

Slack time is calculated in this example as:

Slack time = t<sub>1</sub> + t<sub>2</sub> + t<sub>3</sub>

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

Observed duration is calculated as:

Observed duration = t<sub>send</sub> + t<sub>1</sub> + t<sub>send-done</sub> + t<sub>2</sub> + t<sub>recv</sub> + t<sub>3</sub> + t<sub>recv-done</sub>

• משך ההשהיה: משך הזמן שבו ה-TPU מושהה. זהו משך הזמן הכולל שנדרש לביצוע הפעולות send, send-done, recv ו-recv-done, לא כולל הזמן שנדרש להעברת הנתונים. לדוגמה, אם ציר הזמן הוא כזה:

Stall duration is calculated in this example as:

Stall duration = t<sub>send</sub> + t<sub>send-done</sub> + t<sub>recv</sub> + t<sub>recv-done</sub>

• מספר המקרים: המספר הכולל של הפעמים שבהן קבוצה התחילה והסתיימה במהלך משך הפרופיל. כדי שהמדד הזה יכלול את הפעולה send ואת הפעולה התואמת recv-done, הן צריכות להתרחש במהלך משך הזמן של הפרופיל.
• השהיה כוללת מצטברת: משך הזמן הכולל שבו קולקטיב מעכב TPU במהלך משך הפרופיל. הנוסחה לחישוב סך כל העיכובים באגרגציה:
  • משך זמן כולל מצטבר של השהיה = משך השהיה * מספר המקרים
• גודל הנתונים שמועברים: כמות הנתונים שמועברת ברשת עבור האוסף, מחושבת על סמך צורת הפעולה של XLA.
• רוחב פס נדרש: רוחב הפס שנדרש להעברת הנתונים במסגרת הזמן שנקבע. אתם יכולים להשתמש במדד הזה כדי לראות את מספר הקולקטיבים שמתחרים על רוחב הפס ברשת במהלך משך הפרופיל. רוחב הפס הנדרש מחושב כך:
  • רוחב הפס הנדרש = גודל הנתונים שמועברים / זמן ההשהיה

ניתוח נתונים בכלי Megascale Stats

כדי לנתח את הנתונים שמוצגים בכלי:

1. מיון הטבלה לפי Aggregated Total Stall בסדר יורד.
2. מזהים את השם הקולקטיבי של ה-DCN עם הערך הכי גבוה של Aggregated Total Stall. ערך גבוה באופן משמעותי בהשוואה לערכים אחרים עשוי להצביע על צוואר בקבוק.
3. מכפילים את Required Bandwidth של קבוצת ה-DCN במספר ליבות המעבד (לדוגמה, ‫8 לכל מארח TPU v4). אם הערך הזה גבוה מרוחב הפס המקסימלי של ה-TPU, יכול להיות שיש עומס ברשת. כדאי לנסות לשנות את מנגנון החלוקה כדי לצמצם את רוחב הפס הנדרש.
4. יוצרים dump של HLO כדי לבדוק אם יש בעיות בקומפיילר. הפצה של פעולות send ו-recv-done יכולה לאפשר תזמון של יותר פעולות HLO חופפות ולהפחית את זמן ההמתנה של TPU.
5. בודקים את משך הזמן של recv-done פעולות ב-Trace Viewer עבור האוסף עם סך ההשהיה המצטבר המקסימלי. משך העברה ארוך יכול להצביע על צוואר בקבוק ברוחב הפס, כי בדרך כלל פעולות recv-done נחסמות ברשת.
6. אם משך הפעולות של recv-done לא גבוה מדי בהשוואה לזמן ההמתנה, יכול להיות שמדובר בבעיית חומרה.