במדריך הזה לשיטות מומלצות מוסבר על המדדים שזמינים ואיך לבחור מדדים מתאימים להגדרה של Horizontal Pod Autoscaler (HPA) לעומסי עבודה של הסקת מסקנות ב-JetStream במארח יחיד עם TPU ב-GKE. HPA היא דרך יעילה לוודא ששרתי המודלים שלכם משתנים בהתאם לעומס. הדרך העיקרית להתאים את עלות החומרה שהוקצתה לדרישות התנועה כדי להשיג את יעדי הביצועים של שרת ההסקה היא כוונון עדין של הגדרות ה-HPA.
דוגמאות להטמעה של השיטות המומלצות האלה מופיעות במאמר הגדרה של התאמה לעומס (autoscaling) של עומסי עבודה של 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 אם יש לכם עומסי עבודה שרגישים לזמן האחזור, והתאמה אוטומטית לעומס לפי תור לא מספיק מהירה כדי לעמוד בדרישות שלכם.
התאמה אוטומטית לעומס (automatic scaling) ב-slots_used מבטיחה שקצב העברת הנתונים של עומסי העבודה יגדל כדי למקסם את מספר הבקשות שעוברות עיבוד במקביל בכל רגע, ויקטן כשמספר הבקשות שעוברות עיבוד במקביל קטן. יש לכך שתי השלכות על זמן האחזור. קודם כל, מכיוון שהתאמה אוטומטית לעומס (autoscaling) שמבוססת על slots_used מתבצעת כדי להבטיח שיש משבצת לכל בקשה נכנסת, מידת הקרבה של ערך הסף ל-1 תתאים לסיכוי שבקשה תמתין בתור וכתוצאה מכך יהיה לה זמן אחזור גבוה יותר. שנית, גודל אצווה גדול יותר מגדיל את התפוקה, אבל גם מגדיל את זמן האחזור, כי שלב המילוי מראש של חלק מהבקשות מפריע לשלב הפענוח של בקשות אחרות בשרתי מודלים של אצווה רציפה. אתם יכולים לעקוב אחרי דפוסי גודל האצווה ולהשתמש בהתאמה אוטומטית לעומס (automatic scaling) כדי לצמצם את מספר הבקשות המקבילות במהלך עליות חדות בעומס.
אם גודל התור כבר עומד ביעדי זמן האחזור שלכם, כדאי לתת לו עדיפות בהגדרה של שינוי גודל אוטומטי. כך אפשר למקסם את קצב העיבוד ואת היעילות מבחינת עלויות. עם זאת, slots_used הוא ערך חשוב לעומסי עבודה שרגישים לזמן אחזור.
מומלץ גם לכוונן את גודל האצווה לכל מכשיר לערך מתאים לפני שבודקים את ההתאמה האוטומטית לעומס על סמך slots_used. אפשר גם לשלב את זה עם התאמה אוטומטית לעומס (scaling) שמבוססת על תור.
קביעת ערך הסף האופטימלי של אחוז slots_used ל-HPA
כדי לבחור את ערך הסף הנכון של גודל האצווה, צריך להגדיל את העומס על השרת באופן ניסיוני ולראות איפה גודל האצווה מגיע לשיא. מומלץ גם להשתמש בכלי locust-load-inference לצורך בדיקה. אחרי שמזהים את גודל האצווה האופטימלי לכל מכשיר שבו השימוש בזיכרון הוא מקסימלי, אפשר להגדיר את יעד אחוז המשבצות בשימוש. מגדירים את ערך היעד ההתחלתי קצת מתחת ל-1 ומקטינים אותו עד שמגיעים לזמן האחזור המועדף.
אפשר גם ליצור לוח בקרה מותאם אישית של Cloud Monitoring כדי להציג את התנהגות המדד.
מגבלות
חשוב לשים לב לסבילות של HPA, שהיא טווח ברירת מחדל של 0.1 ללא פעולה סביב ערך היעד כדי להפחית את התנודות.
התאמה אוטומטית לעומס לפי אחוז השימוש ביחידות קיבולת, שימושית לשליטה בזמן טעינה, אבל יש לה מגבלות. הגודל של הבקשות משתנה, ויש אילוצים שקשורים לחומרה, ולכן קשה למצוא את אחוז הסף הנכון של slots_used. אם כלל ההרחבה מנסה לשמור על ממוצע של פחות מ-100% של slots_used, המשמעות היא שכלל ההרחבה מנסה לשמור על מספר חריצים זמינים שגדול מאפס. המשבצות הזמינות האלה תואמות לנפח עיבוד זמין שלא נמצא בשימוש, וזה לא אידיאלי אם אתם רוצים להפיק את המקסימום מיחידות ה-TPU הזמינות.
שיטה מומלצת: שימוש בזיכרון ברוחב פס גבוה (HBM) של TPU כדי למקסם את ניצול החומרה
השימוש בזיכרון ברוחב פס גבוה (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' כדי לציין את השינוי באחוזים.
למידע נוסף על האפשרויות האלה, קראו את המאמר התאמה אופקית של קבוצות Pod לעומס במסמכי התיעוד של Kubernetes בקוד פתוח.