במדריך הזה לשיטות מומלצות מוסבר על המדדים שזמינים ואיך לבחור מדדים מתאימים להגדרה של Horizontal Pod Autoscaler (HPA) לעומסי העבודה של ההסקה ב-GKE. HPA היא דרך יעילה לוודא ששרתי המודלים שלכם יתבצעו בהתאם לעומס. הדרך העיקרית להתאים את עלות החומרה שהוקצתה לדרישות התנועה כדי להשיג את יעדי הביצועים של שרת ההסקה היא לכוונן את ההגדרות של HPA.
דוגמאות לאופן ההטמעה של השיטות המומלצות האלה מופיעות במאמר הגדרת התאמה אוטומטית לעומס (automatic scaling) לעומסי עבודה של LLM במעבדי GPU באמצעות GKE.
מטרות
המדריך הזה מיועד ללקוחות של AI גנרטיבי, למשתמשי GKE חדשים או קיימים, למהנדסי ML ולמהנדסי LLMOps (DevOps) שרוצים לבצע אופטימיזציה של עומסי עבודה של מודלים גדולים של שפה (LLM) באמצעות מעבדי GPU עם Kubernetes.
אחרי שתקראו את המדריך הזה, תוכלו:
- הסבר על מדדי התאמה אוטומטית לעומס (auto-scaling) להסקת מסקנות של מודלים גדולים של שפה (LLM).
- הסבר על היתרונות והחסרונות של מדדים שונים שמשמשים להגדלת הקיבולת באופן אוטומטי.
סקירה כללית של מדדים להתאמה לעומס (autoscaling) עבור הסקת מסקנות (inferencing) של מודלים של שפה גדולה (LLM)
המדדים הבאים זמינים ב-GKE:
מדדי השרת
שרתי הסקת מסקנות פופולריים של LLM כמו TGI, vLLM ו-NVIDIA Triton פולטים מדדים של ביצועים ספציפיים לעומס העבודה. GKE מפשט את הגירוד ואת שינוי הגודל האוטומטי של עומסי עבודה על סמך המדדים האלה ברמת השרת. אפשר להשתמש במדדים האלה כדי לקבל תובנות לגבי מדדי ביצועים כמו גודל אצווה, גודל תור והשהיות של פענוח.
על סמך המדדים האלה, אפשר להגדיר את ההתאמה האוטומטית לעומס לפי מדדי הביצועים הרלוונטיים ביותר. מדדים מרכזיים ברמת השרת להתאמה לעומס (autoscaling) כוללים:
- גודל התור: מספר הבקשות שממתינות לעיבוד בתור של השרת. אפשר להשתמש בגודל התור כדי למקסם את קצב העברת הנתונים ולמזער את העלות במסגרת סף חביון יעד מסוים. מידע נוסף זמין בקטע בנושא שיטות מומלצות.
- גודל אצווה: מספר הבקשות שעוברות הסקה. אפשר להשתמש בגודל אצווה כדי להגיע לסף נמוך יותר של זמן האחזור המטרה מאשר גודל התור. מידע נוסף זמין בקטע בנושא שיטות מומלצות.
המדדים האלה בדרך כלל לא מושפעים משינויים בביצועים ובנפח התנועה, ולכן הם נקודת התחלה אמינה להתאמת קנה מידה אוטומטית במערכות מגוונות של חומרת GPU.
מדדי GPU
מעבדי GPU פולטים מדדים שונים של שימוש וביצועים, ומציעים התאמה אוטומטית לעומס ללא תלות בעומס העבודה לכל משימה שמבוססת על GPU, כולל עומסי עבודה של היקש שאין להם מדדים מותאמים אישית. איך מגדירים איסוף של DCGM
מדדי GPU נפוצים ב-GKE כוללים:
| מדד GPU | Usage | מגבלות |
|---|---|---|
ניצול המעבד הגרפי (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 כדי לעמוד ביעדי הביצועים של עומס העבודה של ההיקש, כדאי להשתמש בשיקולים ובשיטות המומלצות הבאים.
שיטה מומלצת: שימוש בגודל התור כדי למקסם את קצב העברת הנתונים ולמזער את העלות במסגרת סף מסוים של יעד זמן האחזור
מומלץ להשתמש בהתאמה אוטומטית לעומס של גודל התור כשמבצעים אופטימיזציה של תפוקה ועלות, וכשיעדי ההשהיה ניתנים להשגה עם התפוקה המקסימלית של גודל האצווה המקסימלי של שרת המודל.
גודל התור קשור ישירות לזמן האחזור של הבקשה. בקשות נכנסות נכנסות לתור בשרת המודל לפני שהן מעובדות, והזמן שנדרש להן להמתין בתור הזה מוסיף לזמן האחזור הכולל. גודל התור הוא אינדיקטור רגיש לעליות פתאומיות בעומס, כי העומס גדל במהירות וממלא את התור.
התאמה אוטומטית לעומס (auto-scaling) על סמך גודל התור ממזערת את זמן ההמתנה בתור על ידי הגדלת הקיבולת בזמן עומס, והקטנת הקיבולת כשהתור ריק. הגישה הזו קלה יחסית להטמעה ולא תלויה בעומס העבודה, כי גודל התור לא תלוי בגודל הבקשה, במודל או בחומרה.
אם אתם רוצים למקסם את קצב העברת הנתונים תוך התחשבות בהגדרות של שרת המודל, כדאי להתמקד בגודל התור. גודל התור עוקב אחרי בקשות בהמתנה, לא אחרי בקשות בתהליך. 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 בקוד פתוח.