במדריך הזה לשיטות מומלצות מוסבר על המדדים שזמינים ואיך לבחור מדדים מתאימים להגדרה של Horizontal Pod Autoscaler (HPA) לעומסי העבודה של ההסקות ב-GKE. HPA היא דרך יעילה לוודא ששרתי המודלים שלכם יתבצעו בהתאם לעומס. הדרך העיקרית להתאים את עלות החומרה שהוקצתה לדרישות התנועה כדי להשיג את יעדי הביצועים של שרת ההסקה היא לכוונן את ההגדרות של HPA.
דוגמאות לאופן ההטמעה של השיטות המומלצות האלה מופיעות במאמר הגדרת התאמה אוטומטית לעומס לעומסי עבודה של LLM במעבדי GPU באמצעות GKE.
סקירה מרוכזת של כל השיטות המומלצות ל-GKE זמינה במאמר שיטות מומלצות ל-GKE.מטרות
המדריך הזה מיועד ללקוחות של AI גנרטיבי, למשתמשי GKE חדשים או קיימים, למהנדסי ML ולמהנדסי LLMOps (DevOps) שרוצים לבצע אופטימיזציה של עומסי עבודה של LLM באמצעות GPU עם Kubernetes.
אחרי שתקראו את המדריך הזה, תוכלו:
- הסבר על מדדי התאמה אוטומטית לעומס (autoscaling) להסקת מסקנות של LLM.
- הסבר על היתרונות והחסרונות של מדדים שונים שמשמשים להגדלת הקיבולת באופן אוטומטי.
סקירה כללית של מדדים להתאמה לעומס (autoscaling) עבור הסקת מסקנות (inferencing) של מודלים של שפה גדולה (LLM)
המדדים הבאים זמינים ב-GKE:
מדדי השרת
שרתי היקש פופולריים של LLM כמו TGI, vLLM ו-NVIDIA Triton פולטים מדדים של ביצועים שספציפיים לעומס העבודה. GKE מפשט את הגירוד ואת ההתאמה האוטומטית לעומס של עומסי עבודה על סמך המדדים האלה ברמת השרת. אפשר להשתמש במדדים האלה כדי לקבל תובנות לגבי אינדיקטורים של ביצועים כמו גודל אצווה, גודל תור והשהיות של פענוח.
על סמך המדדים האלה, אפשר להגדיר את ההתאמה האוטומטית לעומס על סמך מדדי הביצועים הרלוונטיים ביותר. המדדים המרכזיים ברמת השרת להתאמה לעומס (autoscaling) כוללים:
- גודל התור: מספר הבקשות שממתינות לעיבוד בתור של השרת. אפשר להשתמש בגודל התור כדי למקסם את קצב העברת הנתונים ולמזער את העלות במסגרת סף חביון יעד מסוים. מידע נוסף זמין בקטע בנושא שיטות מומלצות.
- גודל אצווה: מספר הבקשות שעוברות הסקה. אפשר להשתמש בגודל אצווה כדי להגיע לסף נמוך יותר של זמן האחזור המטרה מאשר גודל התור. מידע נוסף זמין בקטע בנושא שיטות מומלצות.
המדדים האלה בדרך כלל לא מושפעים משינויים בביצועים ובתעבורת נתונים, ולכן הם נקודת התחלה אמינה להתאמה אוטומטית לעומס במגוון רחב של תצורות חומרה של GPU.
מדדי GPU
יחידות ה-GPU פולטות מדדים שונים של שימוש וביצועים, ומציעות התאמה אוטומטית לעומס ללא תלות בעומס העבודה לכל משימה שמבוססת על GPU, כולל עומסי עבודה של הסקת מסקנות שאין להם מדדים מותאמים אישית. איך מגדירים איסוף של DCGM
דוגמאות למדדי GPU נפוצים ב-GKE:
| מדד GPU | Usage | מגבלות |
|---|---|---|
ניצול המעבד הגרפי (GPU) (DCGM_FI_DEV_GPU_UTIL) |
המדד הזה מודד את מחזור הפעילות (Duty cycle), שהוא משך הזמן שבו ה-GPU פעיל. | לא נמדדת כמות העבודה שמתבצעת בזמן שה-GPU פעיל. כך קשה למפות מדדי ביצועים שמבוססים על הסקה, כמו זמן אחזור וקצב העברת נתונים, לסף של ניצול GPU. |
השימוש בזיכרון ה-GPU (DCGM_FI_DEV_FB_USED) |
מדד שבודק כמה זיכרון GPU נמצא בשימוש בנקודת זמן מסוימת. האפשרות הזו שימושית לעומסי עבודה שמיישמים הקצאה דינמית של זיכרון GPU. | עבור עומסי עבודה שמקצים מראש זיכרון GPU או אף פעם לא מבטלים הקצאה של זיכרון (כמו עומסי עבודה שפועלים ב-TGI וב-vLLM), המדד הזה פועל רק להגדלת הקיבולת, ולא יקטין את הקיבולת כשתנועת הגולשים תפחת. |
מדדי מעבד (CPU)
ב-GKE, HPA פועל מחוץ לקופסה עם שינוי גודל אוטומטי שמבוסס על מעבד וזיכרון. עבור עומסי עבודה שפועלים במעבדים, מדדי הניצול של המעבד והזיכרון הם בדרך כלל מדדי הסקייל האוטומטי העיקריים.
כשמריצים עומסי עבודה של הסקת מסקנות ב-GPU, לא מומלץ להסתמך רק על השימוש ב-CPU ובזיכרון כדי להעריך את כמות המשאבים שמשימה צורכת, כי עומסי עבודה של הסקת מסקנות מסתמכים בעיקר על משאבי GPU. לכן, שימוש במדדי CPU בלבד לצורך שינוי גודל אוטומטי עלול להוביל לביצועים ולעלויות לא אופטימליים.
שיקולים לבחירת מדדים להתאמה אוטומטית לעומס
כדי לבחור את המדד הכי טוב להתאמה אוטומטית לעומס ב-GKE, כך שתוכלו לעמוד ביעדי הביצועים של עומס העבודה של ההסקות, כדאי להשתמש בשיקולים ובשיטות המומלצות הבאים.
שיטה מומלצת: שימוש בגודל התור כדי למקסם את קצב העברת הנתונים ולמזער את העלות במסגרת סף מסוים של יעד זמן האחזור
מומלץ להשתמש בהתאמה אוטומטית לעומס של גודל התור כשמבצעים אופטימיזציה של תפוקה ועלות, וכשיעדי זמן הטעינה ניתנים להשגה עם התפוקה המקסימלית של גודל האצווה המקסימלי של שרת המודל.
גודל התור קשור ישירות לזמן האחזור של הבקשה. בקשות נכנסות נכנסות לתור בשרת המודל לפני שהן מעובדות, והזמן שהן ממתינות בתור הזה מתווסף לזמן האחזור הכולל. גודל התור הוא אינדיקטור רגיש לעליות פתאומיות בעומס, כי עומס מוגבר ממלא את התור במהירות.
התאמה אוטומטית לעומס (autoscaling) על סמך גודל התור מצמצמת את זמן ההמתנה בתור על ידי הגדלת הקיבולת בזמן עומס, והקטנת הקיבולת כשהתור ריק. הגישה הזו קלה יחסית להטמעה ולא תלויה בעומס העבודה, כי גודל התור לא תלוי בגודל הבקשה, במודל או בחומרה.
אם רוצים למקסם את קצב העברת הנתונים תוך התחשבות בהגדרות של שרת המודל, כדאי להתמקד בגודל התור. גודל התור עוקב אחרי בקשות בהמתנה, לא אחרי בקשות בתהליך. vLLM ו-TGI משתמשים באצווה רציפה, שממקסמת את מספר הבקשות המקבילות ושומרת על תור קצר כשיש מקום לאצווה. התור גדל באופן משמעותי כשהמרחב של העיבוד באצווה מוגבל, ולכן נקודת הצמיחה משמשת כאות להתחלת הגדלה. השילוב של התאמה אוטומטית של גודל התור עם תפוקת אצווה אופטימלית מאפשר לכם למקסם את תפוקת הבקשות.
קביעת ערך הסף האופטימלי של גודל התור ל-HPA
חשוב לשים לב לסבילות של HPA, שמוגדרת כברירת מחדל כטווח של 0.1 ללא פעולה סביב ערך היעד כדי למנוע תנודות.
כדי לבחור את ערך הסף הנכון לגודל התור, מתחילים עם ערך בין 3 ל-5 ומגדילים אותו בהדרגה עד שהבקשות מגיעות לזמן האחזור המועדף. אפשר להשתמש בכלי locust-load-inference לבדיקה. בספים מתחת ל-10,
כדאי לשנות את ההגדרות של הגדלת הקיבולת ב-HPA כדי לטפל בעליות פתאומיות בתנועת הגולשים.
אפשר גם ליצור לוח בקרה מותאם אישית של Cloud Monitoring כדי להציג את התנהגות המדד.
מגבלות
גודל התור לא שולט ישירות בבקשות בו-זמניות, ולכן הסף שלו לא יכול להבטיח חביון נמוך יותר ממה שמאפשר גודל האצווה המקסימלי. כפתרון עקיף, אפשר להקטין ידנית את גודל האצווה המקסימלי או להגדיר שינוי אוטומטי של גודל האצווה.
שיטה מומלצת: שימוש בגודל אצווה כדי להגיע לסף נמוך יותר של זמן אחזור יעד מאשר גודל התור
מומלץ לבחור התאמה אוטומטית לעומס על סמך גודל אצווה אם יש לכם עומסי עבודה שרגישים לזמן טעינה, ושינוי גודל על סמך תור לא מספיק מהיר כדי לעמוד בדרישות שלכם.
גודל האצווה קשור ישירות לתפוקה ולזמן האחזור של בקשה נכנסת. גודל האצווה הוא אינדיקטור טוב לעליות פתאומיות בעומס, כי עלייה בעומס גורמת להוספה של עוד בקשות לאצווה הקיימת, וכך גודל האצווה גדל. ככלל, ככל שגודל האצווה גדול יותר, כך זמן האחזור ארוך יותר. התאמה אוטומטית לעומס (automatic scaling) של גודל אצווה מבטיחה שעומס העבודה יגדל כדי למקסם את מספר הבקשות שעוברות עיבוד במקביל בבת אחת, ויצטמצם כשמספר הבקשות שעוברות עיבוד במקביל יהיה קטן יותר.
אם גודל התור כבר עומד ביעדי זמן הטעינה, כדאי לתת לו עדיפות לצורך התאמה אוטומטית לעומס. כך אפשר למקסם את התפוקה ואת היעילות הכלכלית. עם זאת, גודל האצווה חשוב לעומסי עבודה (workloads) שרגישים לזמן האחזור. גדלים גדולים יותר של אצווה מגדילים את התפוקה, אבל גם מגדילים את זמן האחזור בגלל שלב המילוי המקדים של חלק מהבקשות שמשבש את שלב הפענוח של בקשות אחרות בשרתי מודלים של אצווה רציפה. אתם יכולים לעקוב אחרי דפוסים של גודל אצווה ולהשתמש בהתאמה אוטומטית לעומס כדי לצמצם את מספר הבקשות המקבילות במהלך עליות פתאומיות בעומס.
אם שרת המודל מאפשר זאת, מומלץ להתאים אישית את גודל האצווה המקסימלי כמנגנון כוונון נוסף. אפשר גם לשלב את זה עם שינוי גודל אוטומטי מבוסס-תור.
קביעת ערך הסף האופטימלי של גודל אצווה ל-HPA
חשוב לשים לב לסבילות HPA, שהיא טווח ברירת מחדל של 0.1 ללא פעולה סביב ערך היעד כדי למנוע תנודות.
כדי לבחור את ערך הסף הנכון של גודל האצווה, מגדילים באופן ניסיוני את העומס על השרת ומסתכלים איפה גודל האצווה מגיע לשיא. מומלץ גם להשתמש בכלי locust-load-inference לצורך בדיקה. אחרי שמזהים את גודל האצווה המקסימלי, מגדירים את ערך היעד הראשוני קצת מתחת למקסימום הזה ומקטינים אותו עד שמגיעים לזמן האחזור המועדף.
אפשר גם ליצור לוח בקרה מותאם אישית של Cloud Monitoring כדי להציג את התנהגות המדד.
מגבלות
התאמה אוטומטית לעומס של גודל אצווה, למרות שהיא עוזרת לשלוט בזמן טעינה, מגיעה עם מגבלות. הגודל של הבקשות משתנה, ויש אילוצים שקשורים לחומרה, ולכן קשה למצוא את גודל האצווה הנכון.
שיטה מומלצת: אופטימיזציה של הגדרת ה-HPA
מומלץ להגדיר את אפשרויות ההגדרה הבאות של HPA:
- חלון ייצוב: אפשר להשתמש באפשרות ההגדרה הזו של HPA כדי למנוע שינויים מהירים במספר העותקים עקב תנודות במדדים. ערכי ברירת המחדל הם 5 דקות להקטנת הקיבולת (כדי למנוע הקטנה מוקדמת) ו-0 להגדלת הקיבולת (כדי להבטיח היענות). כדאי להתאים את הערך בהתאם לתנודתיות של עומס העבודה ולרמת התגובה המועדפת.
- מדיניות שינוי גודל: אפשר להשתמש באפשרות ההגדרה הזו של HPA כדי לכוונן את ההתנהגות של הגדלת הגודל והקטנת הגודל. אפשר להגדיר את מגבלת המדיניות 'Pods' כדי לציין את המספר המוחלט של העותקים שהשתנו לכל יחידת זמן, ואת מגבלת המדיניות 'Percent' כדי לציין את השינוי באחוזים.
מידע נוסף על האפשרויות האלה זמין במאמר התאמה אופקית של קבוצות Pod לעומס במסמכי Kubernetes בקוד פתוח.