הפעל וייעל הסקת מסקנות מרובות מודלים עם נקודות קצה מרובי דגמים של Amazon SageMaker

אמזון SageMaker נקודת קצה מרובת מודלים (MME) מאפשרת לך לפרוס ולארח דגמים מרובים בנקודת קצה אחת באופן חסכוני ולאחר מכן לשנות את קנה המידה אופקית של נקודת הקצה כדי להשיג קנה מידה. כפי שמודגם באיור הבא, זוהי טכניקה יעילה ליישום ריבוי דירות של מודלים בתוך תשתית למידת מכונה (ML) שלך. ראינו שעסקים בתוכנה כשירות (SaaS) משתמשים בתכונה זו כדי ליישם היפר-פרסונליזציה במודלים של ML שלהם תוך השגת עלויות נמוכות יותר.

לסקירה ברמה גבוהה של אופן הפעולה של MME, בדוק את הסרטון של AWS Summit קנה מידה של ML לשלב הבא: אירוח אלפי דגמים ב- SageMaker. למידע נוסף על מקרי השימוש המותאמים אישית, מרובי דיירים, ש-MME מאפשרת, עיין כיצד להתאים מסקנות למידת מכונה עבור מקרי שימוש ב-SaaS מרובי דיירים.

בהמשך הפוסט הזה, אנו צוללים עמוק יותר לתוך הארכיטקטורה הטכנית של SageMaker MME ומשתפים שיטות עבודה מומלצות לאופטימיזציה של נקודות הקצה מרובות הדגמים שלך.

השתמש במקרים המתאימים ביותר עבור MME

נקודות קצה מרובי דגמי SageMaker מתאימות היטב לאירוח של מספר רב של דגמים שתוכלו להגיש באמצעות מיכל הגשה משותף ואין צורך לגשת לכל הדגמים בו זמנית. בהתאם לגודל הזיכרון של מופע נקודת הקצה, מודל עשוי להיפרק מדי פעם מהזיכרון לטובת טעינת מודל חדש כדי למקסם את השימוש היעיל בזיכרון, לכן היישום שלך צריך להיות סובלני כלפי עליות חביון מזדמנות בדגמים שלא נטענו.

MME מיועד גם לאירוח משותף של מודלים המשתמשים באותה מסגרת ML מכיוון שהם משתמשים בקונטיינר המשותף לטעינת דגמים מרובים. לכן, אם יש לך שילוב של מסגרות ML בצי הדגמים שלך (כגון PyTorch ו-TensorFlow), נקודות קצה ייעודיות של SageMaker או אירוח מרובה מכולות הן בחירה טובה יותר.

לבסוף, MME מתאים ליישומים שיכולים לסבול קנס של זמן השהיית התחלה קרה מדי פעם, מכיוון שדגמים נטענים בהזמנה ראשונה וניתן להוריד דגמים בשימוש נדיר מהזיכרון לטובת טעינת דגמים חדשים. לכן, אם יש לך שילוב של מודלים שנכנסים אליהם לעתים קרובות ולעתים רחוקות, נקודת קצה מרובת דגמים יכולה לשרת ביעילות את התעבורה הזו עם פחות משאבים וחיסכון גבוה יותר בעלויות.

ראינו גם כמה תרחישים שבהם לקוחות פורסים אשכול MME עם מספיק קיבולת זיכרון מצרפית כדי להתאים לכל הדגמים שלהם, ובכך נמנעים לחלוטין מהורדת מודלים ועדיין משיגים חיסכון בעלויות בגלל תשתית ההסקה המשותפת.

דגם מיכלי הגשה

כאשר אתה משתמש ב- SageMaker Inference Toolkit או במיכל הגשה מדגם SageMaker בנוי מראש התואם ל-MME, למכולה שלך יש את שרת רב מודל (תהליך JVM) פועל. הדרך הקלה ביותר לשילוב של Multi Model Server (MMS) במיכל ההגשה של הדגם שלך היא להשתמש מכולות הגשה מדגם SageMaker תואם ל-MME (חפש את אלה עם סוג עבודה=מסק ו-CPU/GPU=CPU). MMS הוא כלי קוד פתוח וקל לשימוש להגשת מודלים של למידה עמוקה. הוא מספק REST API עם שרת אינטרנט לשרת ולנהל מספר דגמים על מארח יחיד. עם זאת, אין חובה להשתמש ב-MMS; אתה יכול ליישם שרת מודל משלך כל עוד הוא מיישם את ממשקי API נדרשים על ידי MME.

כאשר משתמשים בהם כחלק מפלטפורמת MME, כל קריאות ה-API לחזות, לטעון ולפרוק ל-MMS או לשרת הדגם שלך מתועלות דרך בקר מישור הנתונים של MME. קריאות API מבקר מישור הנתונים מתבצעות דרך מארח מקומי בלבד כדי למנוע גישה לא מורשית מחוץ למופע. אחד היתרונות המרכזיים של MMS הוא שהוא מאפשר ממשק סטנדרטי לטעינה, פריקה והפעלת מודלים עם תאימות על פני מגוון רחב של מסגרות למידה עמוקה.

תצורה מתקדמת של MMS

אם תבחר להשתמש ב-MMS להגשת מודלים, שקול את התצורות המתקדמות הבאות כדי לייעל את המדרגיות והתפוקה של מופעי ה-MME שלך.

הגדל מקביליות מסקנות לכל דגם

MMS יוצר תהליכי עבודה של Python אחד או יותר לכל מודל בהתבסס על הערך של ה- default_workers_per_model פרמטר תצורה. עובדי Python אלה מטפלים בכל בקשת הסקת מסקנות בודדת על ידי הפעלת כל פונקציית עיבוד מקדים, חיזוי ועיבוד לאחר שתספק. למידע נוסף, ראה את מטפל בשירות מותאם אישית ריפו GitHub.

קיום יותר מעובד מודל אחד מגדיל את ההקבלה של התחזיות שניתן לשרת על ידי מודל נתון. עם זאת, כאשר מספר רב של דגמים מתארחים במופע עם מספר רב של מעבדים, עליך לבצע בדיקת עומס של ה-MME שלך כדי למצוא את הערך האופטימלי עבור default_workers_per_model כדי למנוע מיצוי של משאבי זיכרון או CPU.

עיצוב לקוצים בתנועה

לכל תהליך MMS בתוך מופע של נקודת קצה יש תור בקשות שניתן להגדיר עם גודל_תור_עבודה פרמטר (ברירת המחדל היא 100). זה קובע את מספר הבקשות ש-MMS יעמוד בתור כאשר כל תהליכי העבודה תפוסים. השתמש בפרמטר זה כדי לכוונן את ההיענות של מופעי נקודת הקצה שלך לאחר שהחלטת על מספר העובדים האופטימלי לכל דגם.

ביחס עובד לדגם אופטימלי, ברירת המחדל של 100 אמורה להספיק ברוב המקרים. עם זאת, במקרים שבהם תעבורת הבקשות לנקודת הקצה עולה באופן חריג, אתה יכול להקטין את גודל התור אם אתה רוצה שנקודת הקצה תיכשל במהירות כדי להעביר את השליטה ליישום או להגדיל את גודל התור אם אתה רוצה שנקודת הקצה תספוג את הספייק .

למקסם את משאבי הזיכרון לכל מופע

בעת שימוש במספר תהליכי עבודה לכל מודל, כברירת מחדל, כל תהליך עובד טוען עותק משלו של המודל. זה יכול להפחית את זיכרון המופעים הזמין עבור דגמים אחרים. אתה יכול לייעל את ניצול הזיכרון על ידי שיתוף מודל יחיד בין תהליכי עובד על ידי הגדרת פרמטר התצורה preload_model=true. כאן אתה מחליף מקביליות מופחתת של מסקנות (עקב מופע דגם יחיד) עם יותר יעילות זיכרון. הגדרה זו יחד עם תהליכי עבודה מרובים יכולה להיות בחירה טובה עבור מקרי שימוש שבהם זמן האחזור של המודל נמוך אבל יש לך עיבוד מקדים ואחרי עיבוד כבדים יותר (שנעשים על ידי תהליכי העבודה) לכל בקשת מסקנות.

הגדר ערכים עבור תצורות מתקדמות של MMS

MMS משתמש בקובץ config.properties לאחסון תצורות. MMS משתמש בסדר הבא כדי לאתר קובץ config.properties זה:

1. אם MMS_CONFIG_FILE משתנה סביבה מוגדר, MMS טוען את התצורה ממשתנה הסביבה.
2. אם --mms-config הפרמטר מועבר ל-MMS, הוא טוען את התצורה מהפרמטר.
3. אם יש config.properties בתיקייה הנוכחית שבה המשתמש מתחיל MMS, הוא טוען את config.properties קובץ מספריית העבודה הנוכחית.

אם אף אחד מהאפשרויות לעיל לא צוין, MMS טוען את התצורה המובנית עם ערכי ברירת מחדל.

להלן דוגמה של שורת פקודה להפעלת MMS עם קובץ תצורה מפורש:

multi-model-server --start --mms-config /home/mms/config.properties

מדדי מפתח לניטור ביצועי נקודות הקצה שלך

מדדי המפתח שיכולים לעזור לך לייעל את ה-MME שלך קשורים בדרך כלל לניצול מעבד וזיכרון וזמן השהייה להסקת מסקנות. המדדים ברמת המופע נפלטים על ידי MMS, ואילו מדדי ההשהיה מגיעים מה-MME. בסעיף זה, אנו דנים במדדים האופייניים שבהם אתה יכול להשתמש כדי להבין ולמטב את ה-MME שלך.

מדדים ברמת מופעי נקודת הקצה (מדדי MMS)

מ רשימה של מדדי MMS, CPUUtilization ו-MemoryUtilization יכולים לעזור לך להעריך אם המופע שלך או אשכול MME בגודל הנכון או לא. אם לשני המדדים יש אחוזים בין 50-80%, אזי ה-MME שלך בגודל הנכון.

בדרך כלל, ניצול CPU נמוך ושימוש בזיכרון גבוה הם אינדיקציה לאשכול MME שהוקצה יתר על המידה מכיוון שהוא מציין שמודלים המופעלים לעתים רחוקות אינם נפרקים. ייתכן שהסיבה לכך היא מספר גבוה מהאופטימלי של מופעי נקודת קצה שסופקו עבור ה-MME ולכן זיכרון מצטבר גבוה מהאופטימלי זמין עבור דגמים שנכנסים אליהם לעתים רחוקות כדי להישאר בזיכרון. לעומת זאת, קרוב ל-100% ניצול של מדדים אלה פירושו שהאשכול שלך אינו מסודר, ולכן עליך להתאים את מדיניות קנה המידה האוטומטי של אשכול.

מדדים ברמת הפלטפורמה (מדדי MME)

מ רשימה מלאה של מדדי MME, מדד מפתח שיכול לעזור לך להבין את זמן האחזור של בקשת ההסקה שלך הוא ModelCacheHit. מדד זה מראה את היחס הממוצע של בקשות הפעלה שעבורן המודל כבר נטען בזיכרון. אם יחס זה נמוך, זה מצביע על כך שאשכול ה-MME שלך אינו מסופק בחסר מכיוון שסביר להניח שאין מספיק קיבולת זיכרון מצטברת באשכול ה-MME למספר הפעלות המודל הייחודי, ולכן גורם לפריקת מודלים מהזיכרון לעתים קרובות.

לקחים מהשטח ואסטרטגיות לאופטימיזציה של MME

ראינו את ההמלצות הבאות מכמה מהשימושים בקנה מידה גבוה של MME על פני מספר לקוחות.

קנה מידה אופקי עם מופעים קטנים יותר עדיף על קנה מידה אנכי עם מופעים גדולים יותר

אתה עלול לחוות מצערת בקריאת מודל בעת הפעלת בקשות גבוהות לשנייה (RPS) בפחות מקרים של נקודות קצה. ישנן מגבלות פנימיות למספר הפניות לשנייה (טעינות ופריקות שיכולות להתרחש במקביל במופע), ולכן תמיד עדיף לקבל מספר גבוה יותר של מופעים קטנים יותר. הפעלת מספר גבוה יותר של מופעים קטנים יותר פירושה קיבולת מצטברת כוללת גבוהה יותר של מגבלות אלה עבור נקודת הקצה.

יתרון נוסף של קנה מידה אופקי עם מופעים קטנים יותר הוא שאתה מפחית את הסיכון למיצוי משאבי מעבד וזיכרון של מופע בעת הפעלת MMS עם רמות גבוהות יותר של מקביליות, יחד עם מספר גבוה יותר של דגמים בזיכרון (כפי שתואר קודם לכן בפוסט זה).

הימנעות מחבטות היא אחריות משותפת

חֲבָטָה ב-MME הוא כאשר מודלים נפרקים לעתים קרובות מהזיכרון ונטענים מחדש עקב חוסר זיכרון, בין אם במופע בודד או במצטבר באשכול.

מנקודת מבט של שימוש, עליך להתאים את הגודל הנכון של מופעי נקודת קצה בודדים ולהתאים את הגודל הכולל של אשכול ה-MME כדי להבטיח מספיק קיבולת זיכרון זמינה לכל מופע וגם במצטבר עבור האשכול עבור מקרה השימוש שלך. צי הנתבים של פלטפורמת MME גם ימקסם את הפגיעה במטמון.

אל תהיו אגרסיביים עם אריזות של יותר מדי דגמים בפחות מקרי זיכרון גדולים יותר

זיכרון הוא לא המשאב היחיד במופע שצריך להיות מודע אליו. משאבים אחרים כמו CPU יכולים להיות גורם מגביל, כפי שניתן לראות בתוצאות בדיקת העומס הבאות. בכמה מקרים אחרים, ראינו גם משאבי ליבה אחרים כמו מזהי תהליך מיצוי במופע, עקב שילוב של יותר מדי מודלים שנטענים ושל מסגרת ה-ML הבסיסית (כגון TensorFlow) השרצים לכל דגם שהיו כפולות של מודלים זמינים. מעבדי vCPU.

מבחן הביצועים הבא מדגים דוגמה של אילוץ CPU המשפיע על זמן השהיית המודל. בבדיקה זו, נקודת קצה של מופע בודד עם מופע גדול, בעוד שיש לו יותר ממספיק זיכרון כדי לשמור את כל ארבעת הדגמים בזיכרון, יצרה השהיות מודל גרועות יותר באופן יחסי תחת עומס בהשוואה לנקודת קצה עם ארבעה מופעים קטנים יותר.

זמן השהייה של מודל נקודת קצה של מופע יחיד

מופע יחיד של נקודת קצה וניצול זיכרון

השהיה של מודל נקודות קצה בארבעה מקרים

ניצול מעבד וזיכרון בארבע מופעים

כדי להשיג גם ביצועים וגם עלות-יעילות, גודל נכון את אשכול ה-MME שלך עם מספר גבוה יותר של מופעים קטנים יותר שבמצטבר נותנים לך את הזיכרון ואת קיבולת ה-CPU האופטימליים תוך שוויון יחסית לעלות עם פחות מופעי זיכרון גדולים יותר.

מודל מנטלי לאופטימיזציה של MME

ישנם ארבעה מדדי מפתח שאתה תמיד צריך לקחת בחשבון בעת ​​התאמה נכונה של ה-MME שלך:

• מספר וגודל הדגמים
• מספר הדגמים הייחודיים שהופעלו בזמן נתון
• סוג וגודל המופע
• ספירת המופעים מאחורי נקודת הקצה

התחל עם שתי הנקודות הראשונות, כי הן מודיעות לשלישית והרביעית. לדוגמה, אם אין מספיק מופעים מאחורי נקודת הקצה עבור המספר או הגודל של הדגמים הייחודיים שיש לך, הזיכרון המצטבר עבור נקודת הקצה יהיה נמוך ותראה יחס פגיעה במטמון נמוך יותר ופגיעה ברמת נקודת הקצה בגלל ה-MME יטען ופרוק דגמים בזיכרון ומחוצה לו בתדירות גבוהה.

באופן דומה, אם הפניות למודלים ייחודיים גבוהות מהזיכרון המצטבר של כל המופעים מאחורי נקודת הקצה, תראה פגיעה נמוכה יותר במטמון. זה יכול לקרות גם אם גודל המופעים (במיוחד קיבולת הזיכרון) קטן מדי.

קנה מידה אנכי עם מופעי זיכרון גדולים באמת עלולים להוביל לבעיות מכיוון שלמרות שהמודלים עשויים להשתלב בזיכרון, משאבים אחרים כמו תהליכי מעבד וקרנל ומגבלות שרשור עלולים להתכלות. טען קנה מידה אופקי של בדיקת קנה מידה בקדם-ייצור כדי לקבל את המספר והגודל האופטימליים של מופעים עבור ה-MME שלך.

<br> סיכום

בפוסט הזה, קיבלת הבנה מעמיקה יותר של פלטפורמת MME. למדת לאילו מקרי שימוש טכניים MME מתאים וסקרת את הארכיטקטורה של פלטפורמת MME. השגת הבנה מעמיקה יותר של התפקיד של כל רכיב בארכיטקטורת MME ואילו רכיבים אתה יכול להשפיע ישירות על הביצועים של. לבסוף, הסתכלת לעומק על פרמטרי התצורה שאתה יכול להתאים כדי לייעל את ה-MME למקרה השימוש שלך ואת המדדים שאתה צריך לעקוב אחריהם כדי לשמור על ביצועים מיטביים.

כדי להתחיל עם MME, בדוק Amazon SageMaker Multi-Model Points באמצעות XGBoost ו ארח מספר דגמים במיכל אחד מאחורי נקודת קצה אחת.

על המחבר

סייד ג'פרי הוא אדריכל פתרונות ראשי עם AWS. הוא עובד עם מגוון חברות מארגונים בינוניים, ארגונים גדולים, שירותים פיננסיים ו-ISVs כדי לעזור להם לבנות ולתפעל יישומי AI/ML חסכוניים וניתנים להרחבה בענן.

סאוראב טריקאנדה הוא מנהל מוצר בכיר עבור Amazon SageMaker Inference. הוא נלהב לעבוד עם לקוחות ומוטיבציה היא המטרה של דמוקרטיזציה של למידת מכונה. הוא מתמקד באתגרי ליבה הקשורים לפריסת יישומי ML מורכבים, מודלים של ML מרובי דיירים, אופטימיזציות עלויות והפיכת פריסת מודלים של למידה עמוקה לנגישה יותר. בזמנו הפנוי, סאוראב נהנה לטייל, ללמוד על טכנולוגיות חדשניות, לעקוב אחר TechCrunch ולבלות עם משפחתו.