שיטות מומלצות לאחסון לעומסי עבודה של AI/ML במכונות TPU VM
כדי למקסם את הביצועים והיעילות של עומסי העבודה של AI/ML במכונות וירטואליות של TPU, צריך לבחור ולהגדיר את פתרון האחסון המתאים לעומס העבודה. הסרת צווארי בקבוק של קלט/פלט יכולה להפחית את משך הזמן שבו מאיצי ה-TPU לא פעילים, וכך לקצר את זמן האימון ולהפחית את העלויות.
במסמך הזה מפורטות המלצות לאחסון ספציפי לעומסי עבודה ושיטות מומלצות לאופטימיזציה של אימון, יצירת נקודות ביקורת, הצגה ואחסון במטמון במכונות וירטואליות של TPU. לפני שמיישמים את השיטות המומלצות האלה, כדאי לעיין באפשרויות האחסון של נתוני TPU. ההנחה במאמר הזה היא שאתם מכירים מכונות וירטואליות של TPU ויש לכם ניסיון בסיסי בהקצאת משאבים של Cloud Storage.
הנחיות ספציפיות לעומסי עבודה
בטבלה הבאה מפורטות המלצות לאחסון, לפי סדר העדיפות, עבור עומסי עבודה שונים:
| עומס עבודה | המלצה | אופטימיזציה וכלים (אם רלוונטי) |
|---|---|---|
| מערכי נתונים לאימון, כולל הכנת נתונים |
|
|
| שמירת נקודות ביקורת ומשקלים של למידת חיזוק |
|
ל-Rapid Bucket, משתמשים בפרופיל gcsfusecsi-checkpointing.
|
| אחסון והורדה של מודלים |
|
כדי להוריד מודלים, אפשר להשתמש ב-GKE Run:ai Model Streamer או ב-Cloud Storage FUSE עם נקודת טעינה נפרדת באמצעות פרופיל gcsfusecsi-serving.
|
| הפחתת עומס של מטמון זוגות מפתח/ערך (KV) |
|
אופטימיזציות של Cloud Storage
בקטעים הבאים מתוארות שיטות מומלצות לשיפור הביצועים כשמשתמשים ב-Cloud Storage עם מכונות וירטואליות של TPU.
הפעלת מרחב שמות היררכי לאופטימיזציה של מטא-נתונים
כדי לשפר את הביצועים של המטא-נתונים, מומלץ להפעיל מרחב שמות היררכי כשיוצרים קטגוריות אזוריות לעומסי עבודה של AI/ML. ביצועי המטא-נתונים מתייחסים למהירות שבה Cloud Storage יכול לעבד פעולות שכוללות חיפוש, רישום או שינוי של נתיבי אובייקטים ותיקיות, ולא קריאה או כתיבה של תוכן הקובץ עצמו.
בדליים שלא מופעל בהם מרחב שמות היררכי, תיקיות לא קיימות כמשאבים בפועל, אלא הן תיקיות מדומה שמיוצגות על ידי קידומות של שמות אובייקטים שמופרדות על ידי לוכסנים (/). בגלל זה, פעולות כמו הצגת רשימה של תוכן ספרייה או שינוי שם של ספריות מתבצעות לאט, כי המערכת צריכה לסרוק את כל האובייקטים עם הקידומת הזו. מרחב שמות היררכי מספק מבנה אמיתי של מערכת קבצים, וזה חשוב לעומסי עבודה של AI/ML מכמה סיבות:
- שינוי שם של ספריות באופן אטומי: מסגרות ML משתמשות בשינוי שם של ספריות כדי להשלים את נקודות הבדיקה. מרחב שמות היררכי תומך בשינוי שמות אטומי, כך שהשלמת נקודות הבדיקה מתבצעת במהירות.
- QPS ראשוני גבוה יותר: מרחב שמות היררכי תומך בעד פי שמונה יותר שאילתות ראשוניות בשנייה (QPS) לקריאות ולכתיבות בהשוואה לקטגוריות ללא מרחב שמות היררכי. כך נמנעים צווארי בקבוק כשמספר רב של יחידות TPU ניגשים לאחסון בו-זמנית.
- פעולות יעילות ברמת התיקייה: מציאת קבצים ורישום שלהם בספריות ספציפיות מהירים הרבה יותר, וכך מקצרים את זמני התגובה במהלך האימון וטעינת הנתונים.
קטגוריות אזוריות, שמוצעות דרך Rapid Bucket, משתמשות במרחב שמות היררכי כברירת מחדל. מידע נוסף זמין במאמר סקירה כללית על מרחב שמות היררכי.
שימוש ב-Cloud Storage FUSE עם פרופילים מתאימים
Cloud Storage FUSE הוא מתאם FUSE שמאפשר לטעון קטגוריות כמערכת קבצים מקומית. כשמשתמשים ב-Google Kubernetes Engine, מומלץ להשתמש במנהל התקן ה-CSI של Cloud Storage FUSE ובפרופילים של Cloud Storage FUSE כדי לבצע אופטימיזציה של הביצועים באופן אוטומטי.
מידע נוסף על שיטות מומלצות לשימוש ב-Cloud Storage FUSE זמין במאמר בנושא שיטות מומלצות לשיפור הביצועים.
התאמה אישית של דיסק האתחול של TPU VM
אתם יכולים להתאים אישית את סביבת מערכת ההפעלה של האורח ב-TPU VM באמצעות סקריפטים להפעלה או על ידי יצירת תמונות בהתאמה אישית. התאמה אישית של דיסק האתחול שימושית בתרחישים הבאים:
- טעינה מראש של תוכנה וספריות: התקנה של מסגרות ML ספציפיות, תלות או תוכנה בהתאמה אישית כדי לקצר את זמן ההפעלה של המכונה הווירטואלית ולהבטיח סביבות עקביות.
- שימוש בהפצות של מערכת הפעלה שאינן סטנדרטיות: שימוש בהפצה או בגרסה של מערכת הפעלה שלא נכללות ברשימה של Google.
- החלת הגדרות אבטחה ומעקב: החלת הגדרות אבטחה מותאמות אישית, התקנת סוכני מעקב או הגדרת משתני סביבה.
עם זאת, השחזור של דיסק האתחול של מכונות וירטואליות של TPU מוגבל. אי אפשר לנתק את דיסק האתחול או ליצור ממנו תמונת מצב לצורך תיקון במצב אופליין, לכן חשוב לפעול בזהירות כשמבצעים שינויים שמשפיעים על תהליך האתחול. השיטות המומלצות האלה יעזרו לכם לצמצם את הסיכון לכשלים בהפעלה כשאתם מבצעים התאמה אישית של סביבות TPU VM.
כשמתאימים אישית את דיסק האתחול, חשוב לזכור את העקרונות הבאים:
צמצום השינויים בדיסק האתחול: מומלץ להתקין אפליקציות ולאחסן נתונים בנפחי Persistent Disk או Hyperdisk, במקום לבצע שינויים משמעותיים בדיסק האתחול.
שימוש ב-UUID להרכבה: כשמוסיפים רשומות לקובץ
/etc/fstab, תמיד צריך להשתמש ב-UUID כדי לזהות דיסקים ומחיצות (UUID=...) ולא בשמות של מכשירים כמו/dev/sdb1. לא מובטח ששמות מכשירים שנוצרו אוטומטית יהיו יציבים אחרי הפעלה מחדש.
כדי להקטין את הסיכון לכשלים בהפעלה כשמבצעים שינויים במערכת, מומלץ לפעול לפי ההמלצות הבאות:
טיפול בשגיאות: מטמיעים בסקריפטים בדיקות שגיאות חזקות ומצבי כשל אלגנטיים. כדי לעזור בניפוי הבאגים, כדאי לרשום הודעות מפורטות בקונסולה הטורית וב-Cloud Logging.
תלות קריטית: חשוב לנקוט משנה זהירות כשמשנים קבצים שחיוניים להפעלה, כמו קובץ
/etc/fstab, הגדרות רשת או הגדרות של טוען האתחול. שגיאת תחביר או הזנה שגויה עלולות לגרום לכך שלא ניתן יהיה לאתחל את המכונה הווירטואלית.דיסקים משניים: אם הסקריפט מסתמך על דיסקים משניים, צריך לוודא שהוא מטפל במקרים שבהם הדיסק לא קיים או שלוקח לו יותר זמן מהצפוי להתחבר. אלא אם יש לכם סיבה טובה, אל תסתמכו על טעינות של דיסקים משניים בתהליך האתחול.
הנה דוגמאות לערכים מומלצים ולא מומלצים
/etc/fstabלטעינה של דיסק משני:- מומלץ:
UUID=a1b2c3d4-e5f6-7890-1234-567890abcdef /mnt/mydata ext4 defaults,nofail 0 2 - לא מומלץ:
/dev/sdb1 /mnt/mydata ext4 defaults 0 2
השימוש באפשרות
nofailיכול למנוע את עצירת המערכת אם הדיסק לא נמצא, אבל צריך לוודא שהאפליקציה יכולה לטפל במצב שבו נקודת ההרכבה לא זמינה.- מומלץ:
ניהול חבילות: כדאי להיזהר כשמוסיפים מאגרי צד שלישי. חשוב לוודא שהם מהימנים ותואמים לתמונת מערכת ההפעלה הבסיסית. להבין את יחסי התלות של כל חבילה שמתקינים ואת ההשפעה הפוטנציאלית שלה על ספריות המערכת.
נפח האחסון: מעקב אחרי השימוש בדיסק האתחול. רישום נרחב ביומן או התקנות גדולות של תוכנה עלולים למלא את דיסק האתחול ולמנוע את הפעלת המכונה הווירטואלית.
רישום ביומן: כדאי להגדיר את האפליקציות והסקריפטים כך שיירשמו ביומן באופן מפורט ב<b>קונסולה הטורית</b>, כי זה הכלי העיקרי לאבחון בעיות בהפעלה של מכונות וירטואליות של TPU.
תכנון קיבולת האחסון
חשוב לתכנן את נפח האחסון שנדרש לעומס העבודה כדי לנצל את המאיצים באופן מלא. זה כולל את נפח האחסון ואת רוחב הפס של נקודת הבדיקה.
אומדן נפח האחסון
האומדנים הבאים יכולים לשמש כנקודת התחלה להערכת נפח האחסון שנדרש לכם:
| סוג עומס העבודה | אחסון מערך הנתונים | אחסון של נקודות ביקורת |
|---|---|---|
| אימון מראש של LLM | 2TB לכל TPU | 200GB לכל TPU |
| אימון מולטי-מודאלי | 12TB לכל TPU | 1TB לכל TPU |
| הסקת מסקנות | 1TB לכל TPU | 1GB לכל TPU |
הערכת רוחב הפס של נקודת הביקורת
אפשר להעריך את רוחב הפס המינימלי של נקודות הביקורת שנדרש לאימון עומסי עבודה באמצעות הנוסחה הבאה. אם אתם קוראים נתונים, מריצים כמה אימונים או מריצים אימונים והסקת מסקנות, תצטרכו להגדיל את הדרישות המשוערות של רוחב הפס באופן יחסי.
- גודל נקודת הבדיקה: מספר הפרמטרים × בייטים לכל פרמטר (בערך 12-16 בייטים לכל פרמטר עבור FP16 + מצב האופטימיזציה). מוסיפים מאגר (בסביבות פי 3) למצבי האופטימיזציה ולדיוקים שונים.
- מרווח בין נקודות ציון: באיזו תדירות שומרים נקודת ציון (לדוגמה, כל 15 דקות).
- רוחב הפס הנדרש: גודל נקודת הבדיקה ÷ המרווח בין נקודות הבדיקה.
בדוגמה הבאה אפשר לראות איך מעריכים את רוחב הפס המינימלי של יצירת נקודות ביקורת (checkpointing) עבור Qwen3-72B:
- גודל נקודת הבדיקה: 72 מיליארד פרמטרים × 12 בייט ≈ 864GB לכל נקודת בדיקה. עם מאגר זמני, 3 × 864 GB ≈ 2.5 TB.
- Checkpoint interval: 2 minutes = 120 seconds.
- רוחב הפס הנדרש: 2.5TB ÷ 120 שניות ≈ 20GBps.
מתכונים לדוגמה
דוגמאות להגדרות אחסון לחומרה ולעומסי עבודה ספציפיים מופיעות במתכונים הבאים:
- TPU7x inference:
- TPU7x training:
מכסות ומגבלות רוחב פס
רוחב הפס של מוצרי Cloud Storage ו-Compute Engine מוגבל על ידי מכסות ברירת המחדל. אם חורגים ממכסה, יכול להיות שיוטלו מגבלות על בקשות הקלט והפלט.
מידע על המכסות של Cloud Storage ועל בקשות להגדלת המכסות זמין במאמר מכסות ומגבלות במסמכי Cloud Storage. מידע על מכסות של Compute Engine ל-Hyperdisk ולדיסק מתמשך זמין במאמר בנושא מכסות של דיסקים.
המאמרים הבאים
- אפשרויות אחסון לנתוני TPU
- קישור מכונות וירטואליות של TPU לקטגוריות של Cloud Storage
- צירוף אחסון בלוקים (block storage) קבוע ל-TPU VM
- שיטות מומלצות לשיפור הביצועים של Cloud Storage FUSE