במדריך הזה לשיטות מומלצות מוסבר אילו מדדים זמינים ואיך לבחור מדדים מתאימים להגדרה של Horizontal Pod Autoscaler (HPA) לעומסי עבודה של הסקת מסקנות ב-JetStream במארח יחיד עם TPU ב-GKE. HPA היא דרך יעילה לוודא שהשרתים של המודל יתאימו את עצמם לעומס בצורה נכונה. הדרך העיקרית להתאים את עלות החומרה שהוקצתה לדרישות התנועה כדי להשיג את יעדי הביצועים של שרת ההסקה היא כוונון עדין של הגדרות ה-HPA.
דוגמאות לאופן ההטמעה של השיטות המומלצות האלה מופיעות במאמר הגדרת התאמה אוטומטית לעומס לעומסי עבודה של LLM ב-TPU באמצעות GKE.
סקירה מרוכזת של כל השיטות המומלצות ל-GKE זמינה במאמר שיטות מומלצות ל-GKE.מטרות
המדריך הזה מיועד ללקוחות של AI גנרטיבי, למשתמשי GKE חדשים או קיימים, למהנדסי ML ולמהנדסי LLMOps (DevOps) שרוצים לבצע אופטימיזציה של עומסי עבודה של JetStream במארח יחיד באמצעות TPU עם Kubernetes.
אחרי שתקראו את המדריך הזה, תוכלו:
- להבין את מדדי ההתאמה האוטומטית לעומס (autoscaling) העיקריים להסקת מסקנות ב-JetStream במארח יחיד.
- הסבר על היתרונות והחסרונות של מדדים שונים שמשמשים להגדלת הקיבולת באופן אוטומטי.
סקירה כללית של מדדים להתאמה לעומס (autoscaling) עבור הסקת מסקנות ב-JetStream
מומלץ להשתמש במדדים הבאים:
מדדי השרת
JetStream, כמו הרבה שרתים אחרים להסקת מסקנות של LLM, מספק מדדי ביצועים. GKE מפשט את המעקב אחרי JetStream ואת שינוי הגודל האוטומטי שלו על סמך המדדים האלה ברמת השרת. כדי להגדיר שינוי גודל אוטומטי, קודם צריך להבין איך צינור הבקשות של JetStream משפיע על מדדי ביצועים מרכזיים. כל הבקשות הנכנסות עוברות דרך תור של מילוי מראש, תור של העברה ותור של יצירה, ואז הופכות לבקשת פענוח. מערכת JetStream מקבלת בקשות לפענוח על בסיס מתגלגל ומעבדת אותן במקביל באמצעות מספר קבוע של שרשורי פענוח. אחוז מנועי הפענוח שתפוסים בטיפול בבקשת פענוח בנקודה מסוימת נמדד כמדד jetstream_slots_used_percentage.
לשינוי גודל של JetStream במארח יחיד יש שתי השלכות על זמן האחזור ועל קצב העברת הנתונים:
- אם קצב הבקשות הנכנסות נמוך מהקצב שבו משבצות הפענוח יכולות לעבד את הבקשות, הבקשות לא יתווספו לתור. אם אין ב-JetStream בקלוג, התפוקה תהיה פרופורציונלית לקצב הבקשות הנכנסות. זמן האחזור יישאר ברובו קבוע, אבל יעלה מעט באופן יחסי למספר בקשות הפענוח המקבילות, כי בקשות פענוח חדשות שיתקבלו יפריעו לפענוח.
- הבקשות יתווספו לתור ברגע שקצב הבקשות הנכנסות יעלה על הקצב שבו משבצות הפענוח יכולות לעבד את הבקשות. אם יש ל-JetStream עומס בקשות, זמן האחזור של הבקשות יגדל באופן משמעותי יותר, באופן יחסי למספר הבקשות שבעומס, בעוד שהתפוקה תישאר קבועה.
למדדי השרת הבאים תהיה הקורלציה החזקה ביותר עם מדדי הביצועים הרלוונטיים האלה, ולכן מומלץ להשתמש בהם לצורך התאמה אוטומטית לעומס:
-
jetstream_prefill_backlog_size: מספר הבקשות שממתינות לעיבוד בתור של השרת (backlog). יש קורלציה חזקה בין המדד הזה לבין זמן האחזור. מידע נוסף זמין בקטע בנושא שיטות מומלצות. jetstream_slots_used_percentage: מספר הבקשות שעוברות הסקה כאחוז מתוך המספר הכולל של הבקשות ש-JetStream יכול לטפל בהן. יש קורלציה חזקה בין המדד הזה לבין קצב העברת הנתונים. מידע נוסף זמין בקטע בנושא שיטות מומלצות.
המדדים האלה בדרך כלל לא מושפעים מתנו��ות בביצועים ובתעבורת נתונים, ולכן הם נקודת התחלה אמינה להתאמה אוטומטית לעומס במגוון תצורות חומרה של TPU.
מדדי TPU
הגורם שמגביל את הפעלת מודלים גדולים של שפה (LLM) הוא הזיכרון ולא המחשוב, ולכן מומלץ להרחיב את JetStream לפי השימוש בזיכרון ולא לפי מדדי TPU אחרים, כי הוא משקף בצורה הטובה ביותר את ניצול המשאבים של החומרה. מידע נוסף זמין בקטע בנושא שיטות מומלצות.
שיקולים לבחירת מדדים להתאמה אוטומטית לעומס
כדי לבחור את המדד הכי טוב להתאמה אוטומטית לעומס ב-GKE כדי לעמוד ביעדי הביצועים של עומס העבודה של ההיקשים, כדאי להשתמש בשיקולים ובשיטות המומלצות הבאים.
שיטה מומלצת: שימוש בגודל של יומן רישום (תור) למילוי מראש כדי למקסם את קצב העברת הנתונים ולמזער את העלות במסגרת סף מסוים של זמן אחזור
מומלץ להשתמש בהגדרה מראש של שינוי אוטומטי של גודל התור כשמבצעים אופטימיזציה של קצב העברת הנתונים והעלות, וכשיעדי ההשהיה ניתנים להשגה עם קצב העברת הנתונים המקסימלי של גודל אצווה לכל מכשיר בשרת המודל.
גודל התור של מילוי מראש קשור ישירות לזמן האחזור של הבקשה. בקשות נכנסות מתווספות לתור המילוי המקדים בשרתי המודל לפני שהן מעובדות, והזמן שמוקדש לתור הזה מתווסף לזמן האחזור הכולל. גודל התור הוא אינדיקטור רגיש לעליות פתאומיות בעומס, כי עומס מוגבר ממלא את התור במהירות.
התאמה אוטומטית לעומס (autoscaling) על סמך גודל התור של מילוי מראש מצמצמת את זמן ההמתנה בתור על ידי הגדלת הקיבולת בזמן עומס והקטנת הקיבולת כשהתור ריק. הגישה הזו קלה יחסית להטמעה כי גודל התור לא תלוי בגודל הבקשה, במודל או בחומרה.
אם רוצים למקסם את קצב העברת הנתונים של כל העתק של שרת המודל, כדאי להתמקד בגודל התור של מילוי אוטומטי. המדד 'גודל תור המילוי מראש' עוקב אחרי בקשות בהמתנה, ולא אחרי בקשות בתהליך. JetStream משתמשת באצווה רציפה, שממקסמת את הבקשות המקבילות ושומרת על תור קצר כשיש מקום לאצווה. התור גדל באופן משמעותי כשהמקום באצווה מוגבל, ולכן נקודת הצמיחה יכולה לשמש כאות להתחלת הגדלה. השילוב של התאמה אוטומטית לעומס של גודל התור עם אופטימיזציה של תפוקת אצווה מאפשר למקסם את תפוקת הבקשות.
קביעת ערך הסף האופטימלי של גודל התור ל-HPA
כדי לבחור את ערך הסף הנכון לגודל התור, מתחילים עם ערך בין 3 ל-5 ומגדילים אותו בהדרגה עד שהבקשות מגיעות לזמן האחזור המועדף. משתמשים בכלי locust-load-inference לבדיקה. אם הסף נמוך מ-10, כדאי לכוונן את ההגדרות של הגדלת הקיבולת ב-HPA כדי לטפל בעליות פתאומיות בתנועת הגולשים.
אפשר גם ליצור לוח בקרה מותאם אישית של Cloud Monitoring כדי להציג את התנהגות המדד.
מגבלות
חשוב לשים לב לסבילות HPA, שמוגדרת כברירת מחדל לטווח של 0.1 ללא פעולה סביב ערך היעד כדי לצמצם את התנודות.
גודל התור של מילוי מראש לא שולט ישירות בבקשות בו-זמניות, ולכן הסף שלו לא יכול להבטיח חביון נמוך יותר ממה שמאפשר גודל האצווה לכל מכשיר. כדי לעקוף את הבעיה, אפשר להקטין באופן ידני את גודל האצווה לכל מכשיר או להגדיר שינוי אוטומטי של גודל האצווה.
שיטה מומלצת: שימוש באחוז slots_used כדי להגיע לסף נמוך יותר של זמן אחזור יעד מאשר גודל התור
מומלץ לבחור בהגדרה slots_used based autoscaling אם יש לכם עומסי עבודה שרגישים לזמן האחזור, והגידול בקיבולת שמבוסס על תור לא מספיק מהיר כדי לעמוד בדרישות שלכם.
התאמה אוטומטית לעומס ב-slots_used מבטיחה שתפוקת עומסי העבודה תתרחב אנכית בהתאם לעומס כדי למקסם את מספר הבקשות שעוברות עיבוד במקביל בכל פעם, ותצטמצם אנכית בהתאם לעומס כשמספר הבקשות שעוברות עיבוד במקביל קטן. יש לכך שתי השלכות על זמן האחזור. קודם כל, מכיוון שהתאמה אוטומטית לעומס (autoscaling) שמבוססת על slots_used מתבצעת כדי להבטיח שיש משבצת לכל בקשה נכנסת, ככל שהסף קרוב יותר ל-1, כך גדל הסיכוי שבקשה תמתין בתור וכתוצאה מכך יהיה לה זמן אחזור גבוה יותר. שנית, גודל אצווה גדול יותר מגדיל את התפוקה, אבל גם מגדיל את זמן האחזור בגלל ששלב המילוי מראש של חלק מהבקשות מפריע לשלב הפענוח של בקשות אחרות בשרתי מודלים של אצווה רציפה. אתם יכולים לעקוב אחרי דפוסים של גודל אצווה ולהשתמש בהתאמה אוטומטית של נפח העבודה כדי לצמצם את מספר הבקשות המקבילות במהלך עליות חדות בעומס.
אם גודל התור כבר עומד ביעדי זמן הטעינה, כדאי לתת לו עדיפות לצורך התאמה אוטומטית לעומס. כך אפשר למקסם את התפוקה ואת היעילות הכלכלית. עם זאת, המדד slots_used חשוב לעומסי עבודה שרגישים לזמן האחזור.
מומלץ גם לכוונן את גודל האצווה לכל מכשיר לערך מתאים לפני שבודקים את שינוי הגודל האוטומטי על סמך slots_used. אפשר גם לשלב את זה עם שינוי גודל אוטומטי מבוסס-תור.
קביעת ערך הסף האופטימלי של אחוז ה-slots_used ל-HPA
כדי ל��חור את ערך הסף הנכון של גודל האצווה, צריך להגדיל את העומס על השרת באופן ניסיוני ולראות איפה גודל האצווה מגיע לשיא. מומלץ גם להשתמש בכלי locust-load-inference לצורך בדיקה. אחרי שמזהים את גודל האצווה האופטימלי לכל מכשיר שבו השימוש בזיכרון הוא מקסימלי, אפשר להגדיר את יעד אחוז המשבצות בשימוש. מגדירים את ערך היעד הראשוני קצת מתחת ל-1 ומקטינים אותו עד שמגיעים לזמן האחזור המועדף.
אפשר גם ליצור לוח בקרה מותאם אישית של Cloud Monitoring כדי להציג את התנהגות המדד.
מגבלות
חשוב לשים לב לסבילות HPA, שהיא טווח ברירת מחדל של 0.1 ללא פעולה סביב ערך היעד כדי להפחית את התנודות.
התאמה אוטומטית לעומס לפי אחוז השימוש ביחידות קיבולת, שימושית לשליטה בזמן טעינה, אבל יש לה מגבלות. הגודל של הבקשות משתנה, ויש מגבלות חומרה, ולכן קשה למצוא את אחוז הסף הנכון של slots_used. אם כלל ההתאמה מנסה לשמור על ממוצע של פחות מ-100% של slots_used, המשמעות היא שהוא מנסה לשמור על מספר חריצים זמינים שגדול מאפס. המשבצות הזמינות האלה מייצגות את נפח התפוקה הזמין שלא נמצא בשימוש, וזה לא אידיאלי אם אתם רוצים להפיק את המרב מהיחידות הזמינות של TPU.
שיטה מומלצת: שימוש בזיכרון TPU ברוחב פס גבוה (HBM) כדי למקסם את ניצול החומרה
השימוש בזיכרון HBM (זיכרון ברוחב פס גבוה) של TPU הוא המדד שמשקף בצורה הכי ישירה את ניצול החומרה, גם בהשוואה למדדים של המערכת, כי הם לא לוקחים בחשבון את גודל הבקשות. למרות שהגדלת מספר התורים מאפשרת למקסם את ניצול החומרה, היא עלולה להגדיל את זמן האחזור. אם אתם מעדיפים להסתמך על מדדי מערכת ולא על מדדי שרת, מומלץ להשתמש בשימוש ב-HBM כחלופה הטובה ביותר להתאמה אוטומטית לעומס עם slots_used, כי שניהם תואמים לתפוקה. מידע נוסף על זיכרון TPU זמין במאמר איך TPU פועל.
הגדלת גודל האצווה מעבר לנקודה האופטימלית משפרת את התפוקה, אבל גם מגדילה את הסיכון לשגיאות של חוסר זיכרון (OOM). מומלץ מאוד להגדיל את קנה המידה על סמך מדד ה-HBM כדי לאזן בין התפוקה לבין היציבות. לא מומלץ להגדיל את הקיבולת באמצעות גודל התור של מילוי מראש ושימוש ב-HBM בו-זמנית, כי ככל שהעומס גדל, השימוש ב-HBM יגדל ויפעיל את הגדלת הקיבולת קודם.
קביעת ערך הסף האופטימלי לשימוש ב-HBM ב-TPU עבור HPA
לפני שבוחרים את סף השימוש בזיכרון, מומלץ להגדיר את גודל האצווה לכל מכשיר לערך שממקסם את הזיכרון שנעשה בו שימוש כשפועלים בעומס המקסימלי הצפוי. הערה: צריך לקבוע את הערך הזה באופן ניסיוני, והוא תלוי מאוד בזיכרון ה-HBM הכולל וגם באורך הצפוי של ההנחיה והתשובה. מומלץ להשתמש בכלי locust-load-inference לניסויים ולבדיקות.
בדומה לגודל אצווה לכל מכשיר, מגדירים את הסף כדי למקסם את ניצול הזיכרון של TPU תוך צמצום הסיכון להתנהגות OOM.
אפשר גם ליצור לוח בקרה מותאם אישית של Cloud Monitoring כדי להציג את התנהגות המדד.
מגבלות
יש שני חסרונות שמפחיתים את הקשר בין זמן האחזור וקצב העברת הנתונים לבין השימוש ב-HBM, והם התנודתיות של השימוש ב-HBM וקצב הדגימה הנמוך יותר של מדדי TPU באופן כללי. בנוסף, למרות שעדיין יש קשר בין השימוש ב-HBM לבין זמן האחזור, העלייה בשימוש ב-HBM משפיעה על זמן האחזור הרבה פחות מהעלייה במספר הבקשות בתור.
שיטה מומלצת: אופטימיזציה של הגדרת ה-HPA
מומלץ להגדיר את אפשרויות ההגדרה הבאות של HPA:
- חלון ייצוב: אפשר להשתמש באפשרות ההגדרה הזו של HPA כדי למנוע שינויים מהירים במספר העותקים המשוכפלים בגלל תנודות במדדים. ערכי ברירת המחדל הם 5 דקות לצמצום הקיבולת (כדי למנוע צמצום מוקדם מדי) ו-0 להגדלת הקיבולת (כדי להבטיח היענות). משנים את הערך בהתאם לתנודתיות של עומסי העבודה ולרמת התגובה המועדפת.
- מדיניות שינוי הגודל: אפשר להשתמש באפשרות ההגדרה הזו של HPA כדי לכוונן את התנהגות ההגדלה וההקטנה. אפשר להגדיר את מגבלת המדיניות 'Pods' כדי לציין את המספר המוחלט של העותקים המשוכפלים שמשתנים לכל יחידת זמן, ואת מגבלת המדיניות 'Percent' כדי לציין את השינוי באחוזים.
מידע נוסף על האפשרויות האלה זמין במאמר Horizontal Pod Autoscaling במסמכי Kubernetes בקוד פתוח.