Cloud Storage Connector for PyTorch הוא כלי בקוד פתוח לשילוב ישיר בין Cloud Storage לבין PyTorch. המחבר הזה עוזר לכם לטעון נתוני אימון ולנהל נקודות ביקורת של מודלים לעומסי עבודה של בינה מלאכותית (AI) ולמידת מכונה (ML).
בדף הזה מוסבר איך להתקין את Cloud Storage Connector for PyTorch ולהתחיל להשתמש בו.
סקירה כללית
ל-Connector for PyTorch יש יתרונות גם בטעינת נתונים באימון וגם בבדיקת נקודות ביקורת ובטעינת מודלים:
כשמשתמשים ב-Connector for PyTorch כדי לטעון נתונים לאימון, נהנים מהיתרונות הבאים:
- Connector for PyTorch כולל אופטימיזציות שמאפשרות לאמן את המודל עד פי שלושה מהר יותר מאשר ב-PyTorch שמוגדר כברירת מחדל, במערכי נתונים שמורכבים בעיקר מקבצים קטנים מ-1MB.
- Connector for PyTorch מטמיע את הפרימיטיב של מערך הנתונים של PyTorch, שבעזרתו אפשר לטעון ביעילות נתוני אימון מקטגוריות של Cloud Storage.
- תמיכה במערכי נתונים בסגנון מפה לדפוסי גישה אקראית לנתונים, ובמערכי נתונים בסגנון איטרציה לדפוסי גישה לנתונים בסטרימינג.
- היכולת להמיר את הבייטים הגולמיים של הנתונים שהורדו לפורמט הרצוי, כך ש-PyTorch DataLoader יוכל לעבוד בצורה גמישה עם מערכי NumPy או עם טנזורים של PyTorch.
ל-Connector for PyTorch יש את היתרונות הבאים ביצירת נקודות ביקורת ובטעינת מודלים:
- ממשק לנקודות ביקורת שמאפשר לשמור נקודות ביקורת של מודלים ישירות בקטגוריה של Cloud Storage, ולטעון נקודות ביקורת של מודלים מהקטגוריה.
- Connector for PyTorch תומך בנקודות בקרה של PyTorch Lightning באמצעות ההטמעה של
DatafluxLightningCheckpointב-CheckpointIOשל PyTorch Lightning. - Connector for PyTorch מספק הטמעות של
StorageWriterו-StorageReaderלשימוש עם נקודות בקרה מבוזרות של PyTorch. ספריית ההדגמה של Connector for PyTorch כוללת קוד לדוגמה לשימוש בעומס עבודה של PyTorch Lightning FSDP. - נקודות הבדיקה של המחבר כוללות תמיכה בשמירת נקודות בדיקה אסינכרוניות גם ב-Lightning וגם ב-PyTorch הבסיסי.
מידע נוסף זמין בדף הנחיתה של Connector for PyTorch ב-GitHub.
Frameworks
Connector for PyTorch נתמך בגרסאות הבאות של מסגרת העבודה:
- Python 3.8 ואילך
- PyTorch Lightning 2.0 ואילך
- PyTorch 2.3.1 ואילך
תחילת העבודה
כדי להשתמש ב-Connector for PyTorch, צריך:
- קטגוריה של Cloud Storage שמכילה את הנתונים שאתם רוצים לעבוד איתם.
- במאמר שימוש באובייקטים מורכבים מפורטות הגדרות מומלצות נוספות לקטגוריה.
- ההרשאות הבאות לעבודה עם הנתונים שמאוחסנים בקטגוריה:
storage.objects.createstorage.objects.liststorage.objects.get-
storage.objects.delete, אם אתם מתכוונים להשתמש בהורדות מורכבות
צריך להעניק את ההרשאות האלה לחשבון שבו Connector for PyTorch ישתמש לאימות, באמצעות תפקיד IAM כמו Storage Object User.
התקנה
כדי להתקין את Connector for PyTorch, משתמשים בפקודה הבאה:
pip install gcs-torch-dataflux
הגדרות אישיות
כדי להשתמש ב-Connector for PyTorch, צריך לספק אימות באמצעות Application Default Credentials באחת מהשיטות הבאות:
- כשמפעילים את Connector for PyTorch במכונה וירטואלית של Compute Engine, כברירת מחדל, פרטי הכניסה של Application Default Credentials משתמשים באופן אוטומטי בחשבון השירות שמקושר למכונה הווירטואלית. מידע נוסף זמין במאמר בחירת שיטת אימות של עומסי עבודה.
- אפשר גם להגדיר את Application Default Credentials באופן ידני. אתם יכולים להיכנס ישירות באמצעות Google Cloud CLI:
gcloud auth application-default login
דוגמאות
בספריית ההדגמה של מאגר Connector for PyTorch ב-GitHub יש קבוצה מלאה של דוגמאות לעבודה עם Connector for PyTorch. דוגמאות:
- מסמך Jupyter Notebook בסיסי למתחילים (שמתארח ב-Google Colab).
- הדרכה מפורטת מקצה לקצה על עומס עבודה לאימון של חלוקת תמונות למקטעים.
- דוגמה מקצה לקצה ו-notebook לשילוב של PyTorch Lightning.
ביצועים
ל-Connector for PyTorch יש אופטימיזציות ספציפיות שמיועדות לעומסי עבודה של למידת מכונה, שיכולות לספק ביצועים טובים משמעותית בהשוואה לקריאות ישירות ל-API של Cloud Storage:
- כדי לשפר את הביצועים של הצגת האובייקטים ברשימה, Connector for PyTorch משתמש באלגוריתם fast listing שפותח כדי לאזן את עומס העבודה של הצגת האובייקטים ברשימה בין תהליכים מקבילים.
- כדי לשפר את ביצועי ההורדה של קבצים קטנים, Connector for PyTorch משתמש בפעולת הכתיבה כדי לשרשר קבוצות של אובייקטים קטנים יותר לאובייקטים גדולים יותר. האובייקטים המורכבים האלה מאוחסנים באותה קטגוריה כמו אובייקטי המקור, והשמות שלהם כוללים את הקידומת
dataflux-composed-objects/. - העלאה מרובת חלקים לכתיבת נקודת ביקורת מאפשרת לשפר את הביצועים עד פי 10 בהשוואה להעלאה רגילה של נקודת ביקורת.
ב-GitHub אפשר למצוא נתוני ביצועים לגבי:
- הדרכה מבוססת-טקסט של Lightning
- אימון תמונות מהיר
- נקודות ביקורת בצומת יחיד
- נקודות ביקורת בכמה צמתים
לתשומת ליבכם
צריך להביא בחשבון את הדברים הבאים לכל עומס עבודה.
פעולות מהירות של רישום פריטים
אלגוריתם הרישום המהיר של Connector for PyTorch גורם ל-Connector for PyTorch להשתמש ביותר פעולות רישום מאשר רישום רגיל ברצף. פעולות הצגה ברשימה מחויבות כפעולות ברמה A.
שימוש באובייקטים מורכבים
כדי להימנע מחיובים על אחסון עודף ומחיובים על מחיקה מוקדמת כשעובדים עם אובייקטים מורכבים זמניים, צריך לוודא שהקטגוריה משתמשת בהגדרות הבאות:
- מחיקה פשוטה מושבתת
- נעילת קטגוריה מושבתת
- ניהול גרסאות של אובייקטים מושבת
- Standard storage כסוג האחסון (storage class) של הקטגוריה ושל האובייקטים.
אובייקטים מורכבים שנוצרו על ידי Connector for PyTorch בדרך כלל מוסרים באופן אוטומטי בסוף לולאת האימון, אבל במקרים נדירים יכול להיות שהם לא יוסרו. כדי לוודא שהאובייקטים הוסרו מהקטגוריה, אפשר להריץ את הפקודה הבאה:
gcloud storage rm gs://<my-bucket>/dataflux-composed-objects/ --recursive
כדי להשבית את השימוש באובייקטים מורכבים, צריך לכלול את disable_compose=True או את max_composite_object_size=0 בחלק של ההגדרות בקבוצת הנתונים שאתם יוצרים. עם זאת, השבתת ההתנהגות הזו עלולה לגרום ללולאות האימון להימשך זמן רב יותר, במיוחד כשעובדים עם קבצים קטנים.
כשמשתמשים באובייקטים מורכבים, Cloud Storage מגיע למגבלות של QPS וקצב העברת נתונים בקנה מידה קטן יותר מאשר בהורדת קבצים ישירות. כדאי להשבית את השימוש באובייקטים מורכבים כשמפעילים בקנה מידה גדול של ריבוי צמתים, שבו מגיעים למגבלות ה-QPS או הקיבולת של הפרויקט גם בלי להשתמש באובייקטים מורכבים.
שגיאות 429 ופגיעה בביצועים
כשעובדים עם Connector for PyTorch, יכול להיות שתקבלו שגיאות 429 או שזמני הביצוע יהיו איטיים מהצפוי. יש כמה סיבות נפוצות לכך:
- בהרבה פרויקטים של למידת מכונה משתמשים במודל אימון מבוזר מאוד, בעזרת כלים כמו PyTorch Lightning ו-Ray. המודלים האלה תואמים ל-Connector for PyTorch, אבל לעיתים קרובות הם יכולים להפעיל את מגבלות הקצב של Cloud Storage.
- שגיאות 429 שמלוות בהודעות כמו "This workload is drawing too much egress bandwidth from Cloud Storage" או "This workload triggered the Cloud Storage Egress Bandwidth Cap" מצביעות על כך שקצב העברת הנתונים של עומס העבודה חורג מהקיבולת המקסימלית של הפרויקט ב- Google Cloud . כדי לפתור את הבעיות האלה:
- מוודאים שעומסי עבודה אחרים בפרויקט לא צורכים רוחב פס עודף.
- להגיש בקשה להגדלת המכסה.
- כדי לכוונן את ההשהיה לפני ניסיון חוזר ולשפר את הביצועים, משנים את האפשרויות
list_retry_configו-download_retry_configבקטע config של מערכי הנתונים שאתם יוצרים.
- מגבלות QPS יכולות להפעיל שגיאות 429 עם הודעה בגוף ההודעה שמציינת
TooManyRequests, אבל בדרך כלל הן מתבטאות בזמני ביצוע איטיים מהצפוי. צווארי בקבוק של QPS נפוצים יותר כשמפעילים נפחים גדולים של קבצים קטנים. מגבלות ה-QPS של הקטגוריה משתנות באופן טבעי לאורך זמן, כך שמתן תקופת חימום יכולה לעיתים קרובות להוביל לביצועים מהירים יותר. כדי לקבל פרטים נוספים על הביצועים של קטגוריית היעד, אפשר לעיין בכרטיסייה Observability כשמציגים את הקטגוריה במסוף Google Cloud . - אם עומס העבודה נכשל עם שגיאת
TooManyRequestsשכוללת את מילת המפתחdataflux-composed-objectsבהודעת השגיאה, השלב הראשון המומלץ לפתרון הבעיה הוא להשבית את השימוש באובייקטים מורכבים. כך אפשר להפחית את העומס של ה-QPS שנוצר על ידי פעולות הרכבה כשמשתמשים בהן בקנה מידה גדול.
צריכת זיכרון
כתיבה וטעינה של נקודות בקרה, כולל מודלים סופיים להסקת מסקנות, מועברות במלואן לזיכרון כדי לשפר את ביצועי ההעלאה וההורדה. בכל מכונה צריך להיות מספיק זיכרון RAM פנוי כדי להעביר את נקודת הבדיקה לזיכרון, כדי שתוכלו לנצל את השיפורים האלה בביצועים.
פנייה לתמיכה
בערוצי התמיכה הרשמיים שלGoogle Cloud אפשר לקבל תמיכה, לשלוח שאלות כלליות ולבקש תכונות חדשות. אפשר לקבל תמיכה גם באמצעות דיווח על בעיות ב-GitHub.