שיטות מומלצות: מאגרי עובדים ב-Cloud Run עם GPU

בדף הזה מפורטות שיטות מומלצות לאופטימיזציה של הביצועים כשמשתמשים במאגר עובדים של Cloud Run עם עומסי עבודה של AI, כמו אימון מודלים גדולים של שפה (LLM) באמצעות מסגרות מועדפות, כוונון עדין וביצוע הסקה (inference) אופליין או הסקה של קבוצות נתונים במודלים גדולים של שפה. כדי ליצור מאגר עובדים ב-Cloud Run שיכול לבצע משימות שדורשות הרבה משאבי מחשוב או עיבוד באצווה בזמן אמת, צריך:

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

דרכים מומלצות לטעינת מודלים גדולים של למידת מכונה ב-Cloud Run

‫Google ממליצה להוריד מודלים של ML מ-Cloud Storage ולגשת אליהם דרך Google Cloud CLI. אפשרות נוספת היא לאחסן מודלים בתוך קובצי אימג' בקונטיינר, אבל השיטה הזו מתאימה בעיקר למודלים קטנים יותר, בגודל של פחות מ-10GB.

הפשרות שצריך לעשות כשמאחסנים וטוענים מודלים של למידת מכונה

השוואה בין האפשרויות:

מיקום הדגם	זמן הפריסה	חוויית פיתוח	זמן ההפעלה של הקונטיינר	עלות האחסון
‫Cloud Storage, שהורדו בו-זמנית באמצעות הפקודה gcloud storage cp של Google Cloud CLI או Cloud Storage API, כמו שמוצג בדוגמת הקוד להורדה בו-זמנית של מנהל ההעברות.	הכי מהר. המודל הורד במהלך הפעלת המאגר. מוודאים שהוקצה מספיק זיכרון RAM למופע של Cloud Run כדי לאחסן את קובצי המודל.	ההגדרה קצת יותר מסובכת, כי צריך להתקין את Google Cloud CLI בתמונה או לעדכן את הקוד כדי להשתמש ב-Cloud Storage API. מידע נוסף על אחזור פרטי כניסה משרת המטא-נתונים זמין במאמר מבוא לזהות שירות.	מהיר כשמשתמשים באופטימיזציות של רשתות. קובץ המודל יורד באמצעות Google Cloud CLI במקביל.	עותק אחד ב-Cloud Storage.
‫Cloud Storage, נטען באמצעות טעינת נפח Cloud Storage FUSE	מהיר יותר. המודל הורד במהלך הפעלת המאגר.	ההגדרה לא מסובכת ולא דורשת שינויים בתמונת ה-Docker.	מהיר כשמשתמשים באופטימיזציות של רשתות.	עותק אחד ב-Cloud Storage.
קובץ אימג' של קונטיינר	מהירות גבוהה. ייבוא של תמונה שמכילה מודל גדול ל-Cloud Run ייקח יותר זמן.	תצטרכו ליצור תמונה חדשה בכל פעם שתרצו להשתמש במודל אחר. שינויים בקובץ אימג' של קונטיינר יחייבו פריסה מחדש, שיכולה להיות איטית לקובצי אימג' גדולים.	תלוי בגודל המודל. למודלים גדולים מאוד, כדאי להשתמש ב-Cloud Storage כדי לקבל ביצועים צפויים יותר אבל איטיים יותר.	יכול להיות שיהיו כמה עותקים ב-Artifact Registry.
אינטרנט	איטי. המודל הורד במהלך הפעלת המאגר.	בדרך כלל פשוט יותר (הרבה מסגרות מורידות מודלים ממאגרים מרכזיים).	בדרך כלל נמוכה ובלתי צפויה: יכול להיות שמסגרות יחילו טרנספורמציות של מודלים במהלך האתחול. (מומלץ לעשות את זה בזמן הבנייה). יכול להיות שהמארח של המודל והספריות להורדת המודל לא יעילים. יש סיכון מהימנות שקשור להורדה מהאינטרנט. יכול להיות שההפעלה של מאגרי העובדים תיכשל אם יעד ההורדה מושבת, והמודל הבסיסי שהורד עשוי להשתנות, מה שיפגע באיכות. מומלץ לארח בקטגוריה של Cloud Storage משלכם.	תלוי בספק האירוח של המודל.

אחסון מודלים ב-Cloud Storage

כדי לייעל את הטעינה של מודלים של ML כשמטעינים מודלים של ML מ-Cloud Storage, באמצעות טעינת נפח של Cloud Storage או באמצעות Cloud Storage API או שורת פקודה, צריך להשתמש ב-Direct VPC עם הגדרת תעבורת נתונים יוצאת שמוגדרת לערך all-traffic, וגם ב-גישה פרטית ל-Google.

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

כדי לקצר את זמני הקריאה של המודל, אפשר לנסות את אפשרויות הטעינה הבאות כדי להפעיל תכונות של Cloud Storage FUSE:

• ‫cache-dir: הפעלת תכונת שמירת קבצים במטמון עם טעינת נפח אחסון בזיכרון לשימוש כספרייה הבסיסית לשמירת קבצים. מגדירים את הערך של אפשרות ההרכבה cache-dir לשם של אמצעי האחסון בזיכרון בפורמט cr-volume:{volume name}. לדוגמה, אם יש לכם נפח אחסון בזיכרון בשם in-memory-1 שבו אתם רוצים להשתמש כספריית מטמון, מציינים cr-volume:in-memory-1. כשמגדירים את הערך הזה, אפשר גם להגדיר file-cache דגלים אחרים שזמינים להגדרה עבור מטמון.
• ‫enable-buffered-read: מגדירים את השדה enable-buffered-read לערך true כדי לבצע אחזור מראש אסינכרוני של חלקים מאובייקט ב-Cloud Storage למאגר זמני בזיכרון. כך אפשר יהיה להציג קריאות עוקבות מהמאגר במקום לדרוש קריאות רשת. כשמגדירים את השדה הזה, אפשר גם להגדיר את השדה read-global-max-blocks כדי להגדיר את המספר המקסימלי של בלוקים שזמינים לקריאות עם מאגר זמני בכל ידיות הקבצים.

אם משתמשים גם ב-cache-dir וגם ב-enable-buffered-read, המערכת תיתן עדיפות ל-cache-dir. שימו לב: הפעלת אחת מהתכונות האלה תשנה את חישוב המשאבים של תהליך Cloud Storage FUSE, כך שהם ייכללו במגבלות הזיכרון של הקונטיינר. כדאי להגדיל את מגבלת הזיכרון של מאגר התגים. הוראות להגדרת מגבלות זיכרון

אחסון מודלים בקובצי אימג' של קונטיינרים

אם מאחסנים את מודל ה-ML בקובץ האימג' של הקונטיינר, טעינת המודל תהנה מתשתית אופטימלית של סטרימינג של קונטיינרים ב-Cloud Run. עם זאת, בניית תמונות של קונטיינרים שכוללות מודלים של למידת מכונה היא תהליך שדורש הרבה משאבים, במיוחד כשעובדים עם מודלים גדולים. בפרט, תהליך build עלול להפוך לצוואר בקבוק בגלל תפוקת הרשת. כשמשתמשים ב-Cloud Build, מומלץ להשתמש במכונת בנייה חזקה יותר עם ביצועים משופרים של מחשוב ורשת. כדי לעשות זאת, יוצרים אימג' באמצעות קובץ תצורת build שכולל את השלבים הבאים:

steps:
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'IMAGE', '.']
- name: 'gcr.io/cloud-builders/docker'
  args: ['push', 'IMAGE']
images:
- IMAGE
options:
 machineType: 'E2_HIGHCPU_32'
 diskSizeGb: '500'
 

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

טעינת מודלים מהאינטרנט

כדי לבצע אופטימיזציה לטעינת מודלים של ML מהאינטרנט, מנתבים את כל התעבורה דרך רשת ה-VPC עם הגדרת היציאה שמוגדרת לערך all-traffic, ומגדירים Cloud NAT כדי להגיע לאינטרנט הציבורי ברוחב פס גבוה.

שיקולים לגבי build, פריסה, זמן ריצה ותכנון מערכת

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

בזמן ה-build

ברשימה הבאה מפורטים שיקולים שצריך לקחת בחשבון כשמתכננים את הפיתוח:

• בוחרים תמונה בסיסית טובה. מומלץ להתחיל עם תמונה מקונטיינרים של למידה עמוקה (Deep Learning) או ממאגר התמונות של NVIDIA לקונטיינרים, עבור מסגרת ה-ML שבה אתם משתמשים. התמונות האלה כוללות את חבילות הביצועים העדכניות ביותר. אנחנו לא ממליצים ליצור תמונה בהתאמה אישית.
• כדי למקסם את מספר הפעולות שמתבצעות בו-זמנית, מומלץ לבחור במודלים עם כימות של 4 ביט, אלא אם יש הוכחה לכך שהם משפיעים על איכות התוצאות. קוונטיזציה יוצרת מודלים קטנים ומהירים יותר, ומקטינה את כמות הזיכרון ב-GPU שנדרשת להפעלת המודל. היא גם יכולה להגדיל את המקביליות בזמן הריצה. מומלץ לאמן את המודלים בעומק הביט של היעד ולא לבצע קוונטיזציה כדי להגיע אליו.
• כדי לצמצם את זמן ההפעלה של הקונטיינר, כדאי לבחור פורמט מודל עם זמני טעינה מהירים, כמו GGUF. הפורמטים האלה משקפים בצורה מדויקת יותר את סוג הכימות של היעד, ונדרשים פחות טרנספורמציות כשמעלים אותם ל-GPU. מטעמי אבטחה, לא מומלץ להשתמש בנקודות ביקורת בפורמט pickle.
• יצירה של מטמון LLM וחימום שלו בזמן הבנייה. מפעילים את ה-LLM במכונת הבנייה בזמן בניית קובץ האימג' של Docker. כדאי להפעיל שמירה במטמון של הנחיות ולהזין הנחיות נפוצות או לדוגמה כדי לאכלס את המטמון לקראת שימוש בעולם האמיתי. שמירת הפלט שנוצר כדי לטעון אותו בזמן הריצה.
• שמירת מודל ההסקה שנוצר במהלך משך זמן של תהליך build. כך חוסכים זמן משמעותי בהשוואה לטעינת מודלים שמאוחסנים בצורה פחות יעילה ולהחלת טרנספורמציות כמו קוונטיזציה בהפעלת הקונטיינר.

בזמן הפריסה

הרשימה הבאה מציגה שיקולים שצריך לקחת בחשבון כשמתכננים את הפריסה:

• אי אפשר להפעיל שינוי גודל אוטומטי במאגרי עובדים של GPU. תחויבו על ה-GPU גם אם הוא לא מריץ אף תהליך.
• התמחור של מעבד וזיכרון למאגרי עובדים שונה מהתמחור של שירותים ומשימות. עם זאת, המחיר של מק"ט GPU זהה למחיר של שירותים ועבודות.

בזמן הריצה

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

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

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