פתרון בעיות ב-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 נותק במהלך ההדרכה

יכול להיות שהחיבור שלכם ל-Cloud TPU‏ ssh יפסק בגלל חוסר פעילות במהלך אימון ארוך (במיוחד אם אתם משתמשים ב-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. יכול להיות שחלק מהדגימות האחרונות בקובץ יושמטו כדי לוודא שלכל אצווה יש צורה סטטית של batch_size. לדוגמה:

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 מדגם v2 יש זיכרון RAM (או HBM, זיכרון עם רוחב פס גבוה) בנפח 8GB, ול-TPU מדגם v3 יש זיכרון RAM בנפח 16GB. הזיכרון הזה משמש לאחסון טנסורים של משקלים (משתנים), וגם טנסורים של תוצאות ביניים שנדרשים לחישוב הגרדיאנט. אם המודל גדול מדי ולא נכנס ל-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 יוכל להשתמש ביחידות החישוב שלו ביעילות. הריווח הפנימי יכול להגדיל את השימוש בזיכרון וברוחב הפס של הזיכרון. בקטע בנושא ריפוד טנסורים מוסבר איך לפתור בעיות שקשורות לריפוד טנסורים.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 וירטואלית. אפשר להגדיר את משתני הסביבה הבאים לפני שמתחילים את האימון כדי לשנות את התנהגות הרישום ביומן:

‫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.