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