יצירת פרופילים בסביבות Multislice

הערה: הדף הזה רלוונטי ל-Cloud TPU API. ב-Ironwood ‏ (TPU7x), חובה להשתמש ב-Google Kubernetes Engine ‏ (GKE). מידע נוסף זמין במאמר מידע על TPU ב-GKE.

סביבות Cloud TPU Multislice מורכבות מכמה חלקי TPU שמתקשרים ביניהם דרך רשת מרכז הנתונים (DCN). אתם יכולים להשתמש בכלי Megascale stats ב-XProf כדי לראות מידע על מידת היעילות של השימוש בסביבת Multislice ברשת DCN. באופן ספציפי, הכלי 'נתונים סטטיסטיים של Megascale' מאפשר לכם:

• הצגה והסבר של ביצועי הרשת בין פרוסות על סמך נתונים שנאספו
• זיהוי צווארי בקבוק בביצועים
• אופטימיזציה של ביצועי המודל

כל המדדים בכלי הנתונים הסטטיסטיים של Megascale נוצרים על בסיס כל TPU. כדי להפעיל את הכלי הזה, פועלים לפי אותם השלבים ליצירת פרופיל במסגרת העבודה ומשתמשים בספריית XProfiler כדי להגדיר מופע TensorBoard XProf לצפייה בפרופילים. כל עוד עומס העבודה הופעל כעומס עבודה מרובה-פרוסות, TensorBoard יציג את הכלי 'נתונים סטטיסטיים של מגה-סקייל' לכל עומס עבודה מרובה-פרוסות.

לפרטים נוספים על כלי הנתונים הסטטיסטיים של Megascale ב-XProf, אפשר לעיין במדריך כלי הנתונים הסטטיסטיים של Megascale.

הסברים על המונחים

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

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

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

קולקטיב מתחיל כשמתרחשת פעולה מסוג send, ומסתיים כשמתרחשת פעולה תואמת מסוג recv-done.

Slack Time

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

בדוגמה הזו, הזמן הרזרבי מחושב כך:

זמן ההשהיה = t₁ + t₂ + t₃

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

משך ההשהיה

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

בדוגמה הזו, משך ההשהיה מחושב כך:

משך ההשהיה = t_send + t_send-done + t_recv + t_recv-done

משך הזמן המיועד

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

משך הזמן שנצפה מחושב כך:

משך הזמן שנמדד = t_send + t₁ + t_send-done + t₂ + t_recv + t₃ + t_recv-done

אירועים

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

משך זמן כולל מצטבר של עצירה

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

סך כל ההשהיות המצטבר = משך ההשהיה * מספר המקרים

גודל הנתונים שמועברים

כמות הנתונים שהועברו ברשת עבור הקולקטיב במהלך משך הפרופיל.

רוחב הפס הנדרש

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

רוחב הפס הנדרש = גודל הנתונים שמועברים חלקי זמן ההשהיה

סטטוס הכלי

בטבלה הבאה מוצגת הגרסה של TensorFlow או של TPU runtime שנדרשת לכל מדד שמוצג בכלי DCN Collective Stats.

DCN Collective Stats	גרסת TensorFlow נתמכת של זמן ריצת TPU
זמן פנוי	‫TensorFlow 2.15.0, ‏ tensorboard 2.15.1 ו-tensorboard-plugin-profile 2.15.0
משך ההשהיה	‫TensorFlow 2.15.0, ‏ tensorboard 2.15.1 ו-tensorboard-plugin-profile 2.15.0
משך הזמן המיועד	‫TensorFlow 2.15.0, ‏ tensorboard 2.15.1 ו-tensorboard-plugin-profile 2.15.0
אירועים	‫TensorFlow 2.15.0, ‏ tensorboard 2.15.1 ו-tensorboard-plugin-profile 2.15.0
משך זמן כולל מצטבר של עצירה	tf-nightly, tb-nightly, tbp-nightly
גודל הנתונים שמועברים	tf-nightly, tb-nightly, tbp-nightly
רוחב הפס הנדרש	tf-nightly, tb-nightly, tbp-nightly

איך מנתחים את הנתונים בכלי 'נתונים סטטיסטיים משותפים של DCN'

1. מריצים את שרת TensorBoard ועוברים לכרטיסייה Profile.

2. ממיינים את הטבלה בכלי לנתונים סטטיסטיים מצטברים של DCN לפי סה"כ מצטבר של השהיות בסדר יורד.

3. מזהים את השם הכולל של ה-DCN עם הערך הכי גבוה של Aggregated Total Stall. אם משך ההשהיה המצטבר של הקולקטיב הזה גבוה באופן משמעותי בהשוואה לקולקטיבים אחרים, יכול להיות שיש צוואר בקבוק בקולקטיב DCN.

4. מכפילים את רוחב הפס הנדרש של ה-DCN הקולקטיבי במספר הליבות. יש 8 ליבות לכל מארח TPU מדור v4, ולכן רוחב הפס הנדרש לקולקטיב הוא פי 8 מהערך שמוצג. אם רוחב הפס הנדרש גדול מרוחב הפס המקסימלי של רשת ה-TPU, יכול להיות שהרשת עמוסה. כדי להקטין את רוחב הפס הנדרש, אפשר לנסות לשנות את מנגנון הפיצול שבו אתם משתמשים. מידע נוסף על מנגנוני פיצול (sharding) זמין במאמר סקירה כללית על Cloud TPU ריבוי-פרוסות (Multislice).

5. יוצרים dump של HLO כדי לבדוק אם יש בעיות בקומפיילר. עדיף להשתמש בפעולות send ו-recv-done כדי לאפשר תזמון של יותר פעולות HLO חופפות. חפיפה של יותר פעולות HLO מקטינה את זמן ההמתנה של ה-TPU.

6. בודקים את משך הפעולות של recv-done ב-Trace Viewer עבור קולקטיב ה-DCN עם סך ההשהיות המצטבר המקסימלי. אם משך ההעברה ארוך, יכול להיות שיהיה צוואר בקבוק ברוחב הפס כי בדרך כלל הפעולות חסומות ברשת עד לקבלת הנתונים.recv-done

7. אם משך recv-done הפעולות לא גבוה מדי בהשוואה לזמן ההמתנה, יכול להיות שמדובר בבעיית חומרה.