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