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

שימו לב: הדף הזה מתייחס ל-Cloud TPU API, שכבר לא נמצא בפיתוח פעיל. ממשק Cloud TPU API יקבל רק תיקוני באגים ועדכוני אבטחה. מומלץ להשתמש ב-Google Kubernetes Engine בשביל Multislice. מידע נוסף זמין במאמר פריסת TPU Multislices ב-GKE.

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

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

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

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

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

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

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

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

תהליך איסוף נתונים מתחיל כשמתרחשת פעולה מסוג send, ומסתיים כשמתרחשת פעולה תואמת מסוג recv-done.

זמן פנוי

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

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

זמן רזרבה = t₁ + t₂ + t₃

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

משך ההשהיה

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

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

משך ההשהיה = 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	גרסת 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 ליבות לכל מארח v4 TPU, ולכן רוחב הפס הנדרש לקולקטיב הוא 8 כפול הערך שמוצג. אם רוחב הפס הנדרש גדול מרוחב הפס המקסימלי של רשת ה-TPU, יכול להיות שהרשת עמוסה. כדי להקטין את רוחב הפס הנדרש, אפשר לנסות לשנות את מנגנון השארדינג שבו אתם משתמשים. מידע נוסף על מנגנוני חלוקה לשברים זמין במאמר סקירה כללית על Cloud TPU Multislice.

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

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

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