פתרון בעיות ב-TensorFlow – TPU

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

מדריכים כלליים נוספים לשימוש ב-Cloud TPU:

סקירה כללית

בעיות נפוצות שנתקלים בהן ב-Cloud TPU מחולקות לקטגוריות הבאות:

  1. בעיות בהתחברות ל-TPU

  2. ניפוי באגים של שגיאות נפוצות

  3. צמצום השימוש בזיכרון

  4. שיפור מהירות האימון

  5. ניפוי באגים של ירידות ברמת הדיוק של המודל

בעיות בהתחברות לשרת TPU

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

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

  1. מריצים את הפקודה הבאה כדי להציג את יחידות ה-TPU הזמינות. מחליפים את zone ואת project-id באזור ובמזהה הפרויקט.

    (vm)$ gcloud compute tpus tpu-vm list --zone zone --project project-id

    הפלט שמתקבל הוא: 

    NAME       ZONE           ACCELERATOR_TYPE  NETWORK_ENDPOINT   NETWORK  RANGE          STATUS
TPU_NAME   us-central1-b  v2-8              10.240.1.2:8470    default  10.240.1.0  READY

  2. מוודאים שה-TPU הזה מופיע כ-READY.

  3. אם ה-TPU לא מופיע כ-READY או שעדיין יש בעיה בחיבור, מפעילים מחדש את השרת באופן ידני באמצעות הפקודה:

    (vm)$ gcloud compute tpus tpu-vm stop TPU_NAME && gcloud compute tpus tpu-vm start TPU_NAME

    הפעולה עשויה להימשך כמה דקות.

  4. מריצים מחדש את הפקודה gcloud compute tpus tpu-vm list ומחכים עד שמצב ה-TPU יהיה READY. הפעולה עשויה להימשך כמה דקות.

  5. מנסים להריץ את התוכנית שוב.

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

אם הקוד פועל בצורה תקינה אבל המודל עדיין מפסיק להגיב, הבעיה כנראה בצינור האימון. כדי לנפות באגים, מתחילים בהחלפת TPUStrategy בקוד באסטרטגיית ברירת המחדל. כשמשתמשים בשיטת ברירת המחדל, בכל מקום שבו משתמשים ב-strategy.scope() או ב-strategy.run(), המודל פועל ב-CPU (או ב-GPU אם הוא קיים) במקום ב-TPU. אם המודל פועל ב-CPU ולא ב-TPU, כנראה שיש בעיה ספציפית ב-TPU. אם הסקריפט עדיין לא פועל, מומלץ לנפות את הבאג ב-CPU.

החיבור ל-ssh נותק במהלך האימון

יכול להיות שחיבור ssh שלכם ל-Cloud TPU יפסיק לפעול במהלך אימון ארוך (במיוחד אם אתם משתמשים ב-Cloud Shell). בשלב הזה, לא מוצג פלט במסוף TPU, ויכול להיות שייראה כאילו האימון של ה-TPU הופסק. כדי להימנע מכך, מריצים את סשן האימון באמצעות כלי לניהול סשנים או כלי לריבוב טרמינלים, כמו tmux או screen. כך חיבור ssh יישאר פעיל לא משנה כמה זמן האימון יימשך.

ניפוי באגים בשגיאות נפוצות

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

אי אפשר ליצור TPU

יכול להיות שתופיע השגיאה הבאה כשיוצרים Cloud TPU:

googleapiclient.errors.HttpError: < HttpError 403 when requesting https://content-tpu.googleapis.com/v1/projects/{PROJECT}/locations/{ZONE}/nodes/{TPU_NAME}?alt=json returned "Request had insufficient authentication scopes."

זו בעיית הרשאות, ואפשר לפתור אותה על ידי הפעלת הפקודה הבאה:

gcloud auth login --update-adc

הפקודה הזו מעדכנת את Application Default Credentials (ADC) ואמורה לפתור את הבעיה. מידע נוסף זמין במאמר בנושא gcloud auth login.

אין תמיכה בצורות דינמיות

הודעת השגיאה

ValueError: shape [Shape] must have a fixed size for dimension
d that is known at graph construction time.

מסגרות והגדרות שמושפעות

ההודעה הזו מופיעה רק במהלך קומפילציה של XLA עם TensorFlow.

פרטים

כדי להריץ מודל ב-TPU, ‏ Cloud TPU מהדר את המודל באמצעות מהדר XLA. שלב הקומפילציה הזה משפר באופן משמעותי את מהירות האימון ואת השימוש בזיכרון, אבל צריך לדעת את הצורות (גדלי המימדים) של כל הטנסורים בתרשים בזמן הקומפילציה של התרשים. אם לא ניתן לקבוע את הצורות בזמן ההידור, הידור TPU ייכשל עם שגיאה כמו זו שמוצגת למעלה.

אחת מהפעולות הנפוצות שמחזירות צורה דינמית היא dataset.batch(batch_size), כי מספר הדגימות שנותרו בזרם עשוי להיות קטן מגודל האצווה. לכן, כשמבצעים אימון ב-TPU, צריך להגדיר drop remainder=True ל-dataset.batch. יכול להיות שחלק מהדגימות האחרונות בקובץ יושמטו כדי לוודא שלכל אצווה יש צורה סטטית של גודל אצווה. לדוגמה:

dataset = tf.data.Dataset.range(8)
dataset = dataset.batch(3, drop_remainder=True)

אופרטור TensorFlow לא זמין

הודעת השגיאה

NotFoundError: No registered 'OpName' OpKernel for XLA_TPU_JIT
devices compatible with node

מסגרות והגדרות שמושפעות

ההודעה הזו יכולה להופיע כשמבצעים אימון באמצעות TensorFlow.

פרטים

המודל משתמש באופרטור TensorFlow שלא זמין ב-TPU.

רשימת הפעולות שזמינות ב-TPU, יחד עם תוכניות לתמיכה עתידית והצעות לפתרונות עקיפים, מופיעה במדריך פעולות TensorFlow זמינות.

הודעת שגיאה לגבי חוסר זיכרון

הודעת השגיאה

ResourceExhaustedError: Ran out of memory in memory space hbm; used:
YYY; limit: 7.48G.

מסגרות והגדרות שמושפעות

ההודעה הזו יכולה להופיע כשמבצעים אימון באמצעות TensorFlow,‏ PyTorch או JAX.

פרטים

כל Cloud TPU מורכב משמונה ליבות TPU. ל-TPU מדור שני יש 8GB ול-TPU מדור שלישי יש 16GB של RAM (או HBM, זיכרון עם רוחב פס גבוה). הזיכרון הזה משמש לאחסון טנסורים של משקלים (משתנים), וגם טנסורים של תוצאות ביניים שנדרשים לחישוב הגרדיאנט. אם המודל גדול מדי ולא נכנס ל-RAM של TPU, האתחול נכשל והודעת השגיאה מודפסת. מידע נוסף זמין בקטע בנושא צמצום השימוש בזיכרון.

טיפים להפחתת השימוש בזיכרון:

בעיות בעצירת הביצוע

אם TensorFlow נתקל בשגיאה במהלך ההרצה של TPU, לפעמים נראה שהסקריפט מפסיק להגיב במקום לצאת אל המעטפת. במקרה כזה, מקישים על CTRL+C במקלדת כדי להפעיל SIGQUIT, מה שגורם ל-Python לצאת באופן מיידי.

באופן דומה, לחיצה על CTRL+C במהלך הרצת TPU לא תגרום לסגירה מיידית של TensorFlow, אלא להמתנה עד לסיום של לולאת האיטרציה הנוכחית כדי לצאת בצורה מסודרת.

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

gcloud compute tpus tpu-vm stop tpu-name --zone=zone
gcloud compute tpus tpu-vm start tpu-name --zone=zone

כאשר tpu-name נלקח מהעמודה הראשונה שמוצגת על ידי הפקודה gcloud compute tpus tpu-vm list, ו-zone הוא האזור שמוצג בעמודה השנייה.

ריפוד טנסור מוגזם

סיבה אפשרית לבעיה בזיכרון

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

איך מצמצמים את השימוש בזיכרון

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

  • הגודל הכולל של אצווה צריך להיות כפולה של 64 (8 לכל ליבת TPU), ומימדי התכונות צריכים להיות כפולה של 128,

    או

  • הגודל הכולל של אצווה צריך להיות כפולה של 1,024 (128 לכל ליבת TPU), והממדים של התכונות צריכים להיות כפולה של 8.

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

צמצום השימוש בזיכרון

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

הדרכים הכי יעילות לצמצם את השימוש בזיכרון הן:

  • הפחתת ריפוד טנסור מוגזם
  • הקטנת גודל האצווה

גודל האצווה או המודל גדול מדי

סיבה אפשרית לבעיה בזיכרון

כשמבצעים אימון של רשת נוירונים במעבד (CPU), ב-GPU או ב-TPU, השימוש בזיכרון מגיע משני מקומות:

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

לכן, הזיכרון שנדרש למודל תלוי במידה רבה בגודל של אצווה.

הזיכרון שנדרש למודל תלוי במספר השכבות ברשת.

זמן הריצה של TPU מנסה לבצע אופטימיזציה של אופרטורים כדי להתאים את המודל לזיכרון (התהליך נקרא rematerialization, בדומה לgradient checkpointing), אבל הוא לא תמיד מצליח לעשות את זה.

איך מצמצמים את השימוש בזיכרון

מקטינים בהדרגה את גודל האצווה עד שהיא נכנסת לזיכרון, ומוודאים שהגודל הכולל של האצווה הוא כפולה של 64 (גודל האצווה לכל ליבה צריך להיות כפולה של 8). חשוב לזכור שגודל קבוצת קבצים גדול יותר יעיל יותר ב-TPU. בדרך כלל, גודל אצווה כולל של 1,024 (128 לכל ליבה) הוא נקודת התחלה טובה.

אם אי אפשר להריץ את המודל ב-TPU גם עם גודל קבוצת נתונים קטן (לדוגמה, 64), כדאי לנסות לצמצם את מספר השכבות או את גודל השכבות.

שיפור מהירות האימון

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

מעט מדי שלבים בכל הרצה בכל לולאת אימון

תיאור הבעיה בביצועים

העברת הארגומנט steps_per_execution אל Model.compile קובעת כמה שלבי אימון יבוצעו בין קריאות חוזרות (callback) של המארח. כל קריאה חוזרת (callback) של המארח דורשת תקשורת משמעותית בין המעבד המארח של שרת ה-TPU לבין מכשיר ה-TPU, ולכן אם steps_per_execution קטן מדי, הוא עלול להאט את האימון.

איך יודעים אם המודל מושפע

אם פרופיל TPU חושף קריאות חוזרות תכופות של CPU מארח בין שלבי מכשיר TPU, אז האימון יכול להפיק תועלת מערך steps_per_execution גדול יותר.

איך לצמצם את הסיכון

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

צוואר בקבוק בעיבוד הקלט

תיאור הבעיה בביצועים

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

איך יודעים אם המודל מושפע

כדי לראות את ניתוח צינור הנתונים של הקלט ב-TensorBoard, פועלים לפי ההוראות במאמר Cloud TPU Tools: Input Pipeline Analyzer.

תמונה

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

איך לצמצם את הסיכון

יש כמה דרכים לצמצם את הסיכון כשמעלים נתונים באמצעות Dataset API:

  1. אחסון הנתונים כקולקציה של מבני tf.train.Example בקובצי TFRecord וטעינתם באמצעות TFRecordDataset. דוגמאות אפשר לראות במדריך בנושא Dataset API או במדריך בנושא ResNet.
  2. כדי ליצור מאגר זמני לנתוני הקלט, משתמשים בשיטה dataset.cache() או dataset.prefetch(). כך נמנע מצב שבו גישה לקבצים תגרום ליצירת צוואר בקבוק.
  3. מציינים את הפרמטר num_parallel_calls של הפונקציה dataset.map() כדי להפעיל פעולות map() מרובות-הליכים. אפשר להשתמש במספר ליבות המעבד הזמינות כערך של num_parallel_calls.
  4. כדאי לבצע עיבוד מקדים יקר של נתונים במצב אופליין כעלות חד-פעמית, במקום לשלם על העיבוד בכל תקופת אימון.

כל עיבוד הקלט מתבצע במעבדי CPU שנמצאים בשרת TPU, ולא במחשב המקומי, כך שהמהירות של המחשב המקומי לא משפיעה.

זמני צעד איטיים ושימוש נמוך ב-MXU

תיאור הבעיה בביצועים

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

איך יודעים אם המודל מושפע

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

איך לצמצם את הסיכון

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

ריפוד טנסור מוגזם

תיאור הבעיה בביצועים

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

תפוקה נמוכה ושימוש נמוך בזיכרון

תיאור הבעיה בביצועים

ככלל, שימוש בגדלים גדולים יותר של קבוצות נתונים מוביל למהירות אימון גבוהה יותר ב-TPU, במונחים של דגימות לשנייה.

איך יודעים אם המודל מושפע

גודל האצווה של כל מודל צריך להיות תמיד לפחות 64 (8 לכל ליבת TPU), כי ה-TPU תמיד מוסיף אפסים לטנסורים עד לגודל הזה. גודל האצווה האידיאלי כשמבצעים אימון ב-TPU הוא 1,024 (128 לכל ליבת TPU), כי כך נמנעים מחוסר יעילות שקשור להעברת זיכרון ולריפוד.

איך לצמצם את הסיכון

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

השכבות קטנות מדי

תיאור הבעיה בביצועים

גם אם מודל מבוסס בעיקר על כפל מטריצות או על קונבולוציות, יכול להיות שה-TPU לא יפעל ביעילות מלאה אם טנסורי הקלט קטנים. בהשוואה לחומרה אחרת, ה-TPU פועל בצורה הכי יעילה כשגודל האצווה וגודל השכבה גדולים (לדוגמה, ממד >= 512).

איך יודעים אם המודל מושפע

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

איך לצמצם את הסיכון

אם המטרה העיקרית שלכם היא להקטין את גודל השכבות במודל כדי להאיץ את האימון, כדאי לבצע שוב את הבדיקה של המודלים עם שכבות גדולות יותר ב-TPU. לדוגמה, הגדלת גודל הפלט של שכבה מ-256 ל-512 עשויה להגדיל את זמן האימון רק ב-20%, למרות שהמודל מבצע פי 2 חישובים.

יצירת פרופילים של מודלים ברמת האופרטור

לעתים קרובות כדאי למדוד את זמן הביצוע ואת השימוש בזיכרון ברמת הפעולה כדי לזהות צווארי בקבוק בביצועים. הוראות מפורטות מופיעות במדריך Cloud TPU Tools: Trace Viewer.

ניפוי באגים בנושא ירידות בדיוק המודל

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

הסבר על חלוקת נתונים (מקביליות נתונים)

אחת המטרות העיקריות של TensorFlow היא שכל פעולה תפיק תוצאות כמעט זהות, בין אם היא מבוצעת ב-CPU, ב-GPU או ב-TPU. יש כמה חריגים לכלל הזה, כמו פעולות אקראיות. באופן כללי, אם אתם מוצאים הבדל משמעותי בין הפלט של פעולות לא אקראיות ב-TPU וב-CPU, דווחו על כך כעל באג.

עם זאת, בצינור האימונים בשלמותו, יש הבדל משמעותי בין אימון ב-CPU/GPU לבין אימון ב-TPU. כשמבצעים אימון ב-TPU,‏ TensorFlow מבצע חלוקת נתונים. כל Cloud TPU מכיל 8 ליבות TPU שפועלות כיחידות עיבוד עצמאיות. בכל שלב באימון, כל ליבת TPU מקבלת אצווה של נתונים, מחשבת את שיפועי המשקלים, מחליפה את השיפועים עם ליבות ה-TPU האחרות ואז מחשבת את עדכון המשקל. כברירת מחדל, אובדן המידע מחושב כממוצע בין ליבות המעבד, אבל אפשר לחשב אותו כסכום על ידי שינוי הפרמטר של CrossShardOptimizer.

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

הפעולה הנפוצה ביותר שלא מתבצעת באופן עצמאי לכל דגימה היא נרמול של קבוצות (batch), שמתבצעת על כל קבוצה בנפרד לכל ליבה. לדוגמה, אם גודל האצווה הכולל הוא 128, גודל האצווה לכל ליבה הוא 16, וכל אחת מ-8 הליבות מבצעת נרמול אצווה על 16 הדגימות שלה. במקרים מסוימים, ביצוע נרמול של קבוצות קטנות (למשל, פחות מ-32) עלול לפגוע בדיוק. בתרחיש האידיאלי, הגודל הכולל של הקבוצה צריך להיות גדול (לדוגמה, 256 עד 1,024). אם גודל האצווה גדול מדי ולא נכנס לזיכרון, צריך להעריך את ההשפעה של הפיצול בכל מקרה לגופו.

ניפוי באגים באימון TPU מרובה ליבות

אם המודל משיג את אותו הפסד ב-CPU וב-TPU עם ליבה אחת, סביר להניח שהבעיה היא אחת מהבאות:

‫(א) הירידה באיכות נובעת מהשונות האקראית הטבעית שמתרחשת כשמאמנים מודלים של רשתות עצביות עם אתחולים שונים.

‫(ב) הירידה באיכות נובעת מבעיה שקשורה לחלוקת נתונים (sharding) ב-TPU.

כדי לבדוק אם (א) היא הבעיה, מאמנים מחדש את המודל המלא ב-CPU/GPU וב-TPU מרובה ליבות באמצעות אותה אתחול משקלים.

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

  1. אם המודל שלכם משתמש בנרמול של קבוצות, גודל קבוצה כולל של פחות מ-256 (לדוגמה, פחות מ-32 לכל ליבה) עלול להפחית את רמת הדיוק.
  2. פונקציות הפסד ברמת הקבוצה מושפעות מפיצול. פונקציות אובדן כאלה הן בדרך כלל מאוד ייעודיות. לדוגמה, Karras et al. 2017 משתמשים במפלה של קבוצת פריטים כשמאמנים רשת גנרטיבית יריבה.

פתרון בעיות בהגדרה של gcloud

בעיה
gcloud components update מוצגת הודעת השגיאה הבאה:
ERROR: (gcloud.components.update)
You cannot perform this action because the Cloud SDK component manager is
disabled for this installation.
פתרון

כדי להשתמש ב-Google Cloud CLI, צריך להשתמש בהתקנה שלא מנוהלת דרך מנהל חבילות.

  1. מריצים את הפקודה הבאה כדי להסיר את ההתקנה הנוכחית של ה-CLI של gcloud:

    sudo apt-get remove google-cloud-sdk

  2. פועלים לפי ההוראות להתקנת Google Cloud CLI.

בעיה

הפקודה gcloud compute tpus tpu-vm ssh TPU_NAME --zone ZONE מציגה את הודעת השגיאה הבאה:

Waiting for SSH key to propagate.
ssh: connect to host 34.91.136.59 port 22: Connection timed out
ssh: connect to host 34.91.136.59 port 22: Connection timed out
ssh: connect to host 34.91.136.59 port 22: Connection timed out
ERROR: (gcloud.compute.tpus.tpu-vm.ssh) Could not SSH into the instance.  It is possible that your SSH key has not propagated to the instance yet. Try running this command again.  If you still cannot connect, verify that the firewall and instance are set to accept ssh traffic.
פתרון

יכול להיות שמשהו השתבש בהפצה של מפתח ה-SSH. כדאי לנסות להעביר את המפתחות שנוצרו אוטומטית למיקום גיבוי כדי לאלץ את gcloud ליצור אותם מחדש:

mv ~/.ssh/google_compute_engine ~/.ssh/old-google_compute_engine
mv ~/.ssh/google_compute_engine.pub ~/.ssh/old-google_compute_engine.pub

יומני ניפוי באגים

הגישה למעבדי TPU במסגרות Cloud TPU הנתמכות, JAX, ‏ PyTorch ו-TensorFlow, מתבצעת באמצעות ספרייה משותפת בשם libtpu שנמצאת בכל מכונת TPU וירטואלית. הספרייה הזו כוללת את מהדר XLA שמשמש להידור תוכניות TPU, את זמן הריצה של TPU שמשמש להרצת תוכניות מהודרות ואת מנהל ההתקן של TPU שמשמש את זמן הריצה לגישה ברמה נמוכה ל-TPU.

בספריית libtpu נרשם מידע שיכול להיות שימושי לניפוי באגים. כברירת מחדל, היומנים האלה נכתבים אל /tmp/tpu_logs בכל מכונת Cloud TPU VM. אפשר להגדיר את משתני הסביבה הבאים לפני שמתחילים את האימון כדי לשנות את התנהגות הרישום ביומן:

‫TPU_LOG_DIR: הספרייה שאליה נכתבים היומנים
מיקום הספרייה הוא /tmp/tpu_logs כברירת מחדל. המדריך נוצר אם הוא לא קיים, אבל לא נוצרים מדריכים ברמת ההורה. אם יש שגיאה במציאה או ביצירה של הספרייה שצוינה, הודעה מודפסת ל-stderr, אבל היא לא תגרום לעצירה של התוכנית והרישום ביומן מושבת. כדי להשבית את הרישום ביומן לדיסק לגמרי, צריך להגדיר את שם הספרייה כ-disabled.
‫TPU_MIN_LOG_LEVEL: רמת החומרה המינימלית שתתועד בדיסק
האפשרויות הן 0 (מידע), 1 (אזהרה), 2 (שגיאה) ו-3 (קריטי). ערך ברירת המחדל הוא 0.
‫TPU_STDERR_LOG_LEVEL: רמת החומרה המינימלית שתתועד ב-stderr, בנוסף לדיסק, אם רלוונטי
האפשרויות זהות לאפשרויות של TPU_MIN_LOG_LEVEL. ערך ברירת המחדל הוא 3.
‫TPU_MAX_LOG_SIZE_MB: הגודל המקסימלי במגה-בייט של כל קובץ יומן
קובץ יומן חדש יתחיל באופן אוטומטי כשהקובץ הקודם יגיע לגודל הזה. ברירת המחדל היא 1024.