שיטות מומלצות לאחסון לעומסי עבודה של 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 הווירטואלית
אתם יכולים להתאים אישית את סביבת מערכת ההפעלה של האורח במכונת TPU וירטואלית באמצעות סקריפטים להפעלה או על ידי יצירת תמונות בהתאמה אישית. התאמה אישית של דיסק האתחול שימושית בתרחישים הבאים:
- טעינה מראש של תוכנה וספריות: התקנה של מסגרות ספציפיות של 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יכול למנוע את עצירת המערכת אם הדיסק לא נמצא, אבל צריך לוודא שהאפליקציה יכולה לטפל במצב שבו נקודת ההרכבה לא זמינה.- מומלץ:
ניהול חבילות: מומלץ לנקוט משנה זהירות כשמוסיפים מאגרי צד שלישי. חשוב לוודא שהם מהימנים ותואמים לתמונת מערכת ההפעלה הבסיסית. להבין את יחסי התלות של כל חבילה שמתקינים ואת ההשפעה הפוטנציאלית שלה על ספריות המערכת.
מקום בכונן: מעקב אחרי השימוש בדיסק האתחול. רישום נרחב ביומן או התקנות גדולות של תוכנה עלולים למלא את דיסק האתחול ולמנוע את הפעלת המכונה הווירטואלית.
רישום ביומן: צריך להגדיר את האפליקציות והסקריפטים כך שיירשמו ביומן באופן מפורט במסוף הטורי, כי זה הכלי העיקרי לאבחון בעיות באתחול של מכונות וירטואליות של TPU.
תכנון קיבולת האחסון
חשוב לתכנן את נפח האחסון שנדרש לעומס העבודה כדי להשתמש במאיצים באופן מלא. זה כולל את נפח האחסון ואת רוחב הפס של נקודת הבדיקה.
אומדן נפח האחסון
ההערכות הבאות יכולות לשמש כנקודת התחלה להערכת נפח האחסון שנדרש לכם:
| סוג עומס העבודה | אחסון מערכי נתונים | אחסון של נקודות ביקורת |
|---|---|---|
| אימון מראש של LLM | 2TB לכל TPU | 200GB לכל TPU |
| אימון מולטי-מודאלי | 12TB לכל TPU | 1TB לכל TPU |
| הסקת מסקנות | 1TB לכל TPU | 1GB לכל TPU |
הערכת רוחב הפס של נקודת הביקורת
אפשר להעריך את רוחב הפס המינימלי של נקודות הביקורת שנדרש לאימון עומסי עבודה באמצעות הנוסחה הבאה. אם אתם קוראים נתונים, מריצים כמה אימונים או מריצים אימונים והסקת מסקנות, כדאי להגדיל את דרישות רוחב הפס המשוערות באופן יחסי.
- גודל נקודת הבדיקה: מספר הפרמטרים × בייטים לכל פרמטר (בערך 12-16 בייטים לכל פרמטר עבור FP16 + מצב האופטימיזציה). מוסיפים מאגר (בערך פי 3) למצבי האופטימיזציה ולדיוקים שונים.
- מרווח בין נקודות ביקורת: התדירות שבה שומרים נקודת ביקורת (לדוגמה, כל 15 דקות).
- רוחב הפס הנדרש: גודל נקודת הביקורת ÷ מרווח נקודות הביקורת.
בדוגמה הבאה אפשר לראות איך מעריכים את רוחב הפס המינימלי של יצירת נקודות ביקורת עבור Qwen3-72B:
- גודל נקודת הבדיקה: 72 מיליארד פרמטרים × 12 בייט ≈ 864GB לכל נקודת בדיקה. עם מאגר זמני, 3 × 864 GB ≈ 2.5 TB.
- מרווח הזמן בין נקודות הבידוק: 2 דקות = 120 שניות.
- רוחב הפס הנדרש: 2.5TB ÷ 120 שניות ≈ 20GBps.
מתכונים לדוגמה
דוגמאות להגדרות אחסון לחומרה ולעומסי עבודה ספציפיים מופיעות במתכונים הבאים:
- TPU7x inference:
- TPU7x training:
מכסות ומגבלות רוחב פס
רוחב הפס של מוצרי Cloud Storage ו-Compute Engine מוגבל על ידי מכסות ברירת המחדל. אם חורגים ממכסה, יכול להיות שיוגבלו בקשות הקלט והפלט.
מידע על מכסות ב-Cloud Storage ועל בקשות להגדלת המכסות זמין במאמר מכסות ומגבלות במסמכי Cloud Storage. מידע על מכסות של Compute Engine ל-Hyperdisk ולדיסק מתמשך זמין במאמר בנושא מכסות של דיסקים.
המאמרים הבאים
- אפשרויות אחסון לנתוני TPU
- קישור מכונות וירטואליות של TPU לקטגוריות של Cloud Storage
- צירוף אחסון בלוקים עמיד ל-TPU VM
- שיטות מומלצות לשיפור הביצועים של Cloud Storage FUSE