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

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

בחודש נובמבר 2022, MMEs הוסיפו תמיכה עבור GPUs, המאפשר לך להריץ מספר דגמים על התקן GPU יחיד ולהתאים מופעי GPU מאחורי נקודת קצה אחת. זה עונה על הדרישה החזקה של MME למודלים של רשתות עצביות עמוקות (DNN) הנהנות ממחשוב מואץ עם GPUs. אלה כוללים ראייה ממוחשבת (CV), עיבוד שפה טבעית (NLP) ומודלים של בינה מלאכותית. הסיבות לדרישה כוללות את הדברים הבאים:

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

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

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

סקירת פתרונות

למבוא ל-MMEs ו-MMEs עם GPU, עיין ב צור נקודת קצה מרובת דגמים ו הפעל מספר מודלים של למידה עמוקה ב-GPU עם נקודות קצה מרובי דגמים של Amazon SageMaker. להקשר של בדיקת עומס בפוסט זה, אתה יכול להוריד את הקוד לדוגמה שלנו מה- GitHub ריפו כדי לשחזר את התוצאות או להשתמש בה כתבנית כדי לסמן מודלים משלך. ישנן שתי מחברות המסופקות ב-repo: אחת לדגמי קורות חיים לבדיקת עומס ואחרת ל-NLP. מספר דגמים בגדלים וארכיטקטורות משתנים סומנו על סוגים שונים של מופעי GPU: ml.g4dn.2xlarge, ml.g5.2xlarge ו-ml.p3.2xlarge. זה אמור לספק חתך סביר של ביצועים על פני המדדים הבאים עבור כל מופע וסוג מודל:

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

הטבלה הבאה מפרטת את הדגמים שנבדקו.

הטבלה הבאה מפרטת את מופעי ה-GPU שנבדקו.

כאמור, דוגמת קוד ניתן לאמץ לדגמים וסוגי מופעים אחרים.

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

הליך ההשוואה מורכב מהשלבים הבאים:

1. אחזר דגם מאומן מראש ממרכז דגם.
2. הכן את חפץ הדגם להגשה ב-MME של SageMaker (ראה הפעל מספר מודלים של למידה עמוקה ב-GPU עם נקודות קצה מרובי דגמים של Amazon SageMaker לפרטים נוספים).
3. פרוס SageMaker MME על מופע GPU.
4. קבע את המספר המרבי של דגמים שניתן לטעון לזיכרון ה-GPU בתוך סף מוגדר.
5. השתמש ב-Locst Load Testing Framework כדי לדמות תעבורה שמפעילה באופן אקראי מודלים שנטענו במופע.
6. אסוף נתונים ונתח את התוצאות.
7. לחלופין, חזור על שלבים 2-6 לאחר הידור של המודל ל- TensorRT.

שלבים 4 ו-5 מחייבים מבט עמוק יותר. דגמים בתוך SageMaker GPU MME נטענים לזיכרון בצורה דינמית. לכן, בשלב 4, אנו מעלים חפץ מודל ראשוני אל שירות אחסון פשוט של אמזון (Amazon S3) והפעל את הדגם כדי לטעון אותו לזיכרון. לאחר ההפעלה הראשונית, אנו מודדים את כמות זיכרון ה-GPU הנצרכת, יוצרים עותק של הדגם הראשוני, מפעילים את העותק של הדגם כדי לטעון אותו לזיכרון, ושוב מודדים את הכמות הכוללת של זיכרון ה-GPU שנצרך. תהליך זה חוזר על עצמו עד שמגיעים לסף אחוז מסוים של ניצול זיכרון GPU. עבור המדד, הגדרנו את הסף ל-90% כדי לספק מאגר זיכרון סביר להסקת מסקנות על אצווה גדולה יותר או השארת מקום לטעינת דגמים אחרים בשימוש פחות תדיר.

הדמיית תעבורת משתמשים

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

Locust תומך בצורות בדיקת עומס מותאמות אישית המאפשרות לך להגדיר דפוסי תנועה מותאמים אישית. הצורה שבה נעשה שימוש במדד זה מוצגת בתרשים הבא. ב-30 השניות הראשונות, נקודת הסיום מתחממת עם 10 משתמשים במקביל. לאחר 30 שניות, משתמשים חדשים נוצרים בקצב של שניים בשנייה, ומגיעים ל-20 משתמשים בו-זמנית בסימן של 40 שניות. לאחר מכן, נקודת הקצה מסומנת בהתמדה עם 20 משתמשים בו-זמנית עד ל-60 שניות, ובשלב זה לוקוס שוב מתחילה להגדיל משתמשים בשניים בשנייה עד ל-40 משתמשים במקביל. דפוס זה של עלייה ובדיקות יציבות חוזר על עצמו עד שנקודת הקצה מוגדלת ל-200 משתמשים בו זמנית. בהתאם למקרה השימוש שלך, ייתכן שתרצה להתאים את צורת בדיקת העומס ב-locust_benchmark_sm.py כדי לשקף בצורה מדויקת יותר את דפוסי התנועה הצפויים שלך. לדוגמה, אם אתה מתכוון לארח דגמי שפה גדולים יותר, ייתכן שבדיקת עומס עם 200 משתמשים בו-זמנית לא תהיה ריאלית עבור מודל שמתארח במופע בודד, ולכן ייתכן שתרצה להפחית את ספירת המשתמשים או להגדיל את מספר המופעים. ייתכן שתרצה גם להאריך את משך בדיקת העומס כדי לאמוד בצורה מדויקת יותר את יציבות נקודת הקצה על פני תקופה ארוכה יותר.

stages = [
{"duration": 30, "users": 10, "spawn_rate": 5},
{"duration": 60, "users": 20, "spawn_rate": 1},
{"duration": 90, "users": 40, "spawn_rate": 2},
…
]

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

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

השתמש במחברת cv-benchmark.ipynb כדי להפעיל בדיקות עומס עבור דגמי ראייה ממוחשבת. אתה יכול להתאים את שם הדגם ופרמטרי סוג המופע שהוכשרו מראש לבדיקת עומס ביצועים בשילובי מודל וסוג מופע שונים. בדקנו בכוונה שלושה דגמי קורות חיים בטווחי גדלים שונים מהקטן לגדול ביותר: resnet50 (25 מיליון), convnext_base (88 מיליון), ו vit_large_patch16_224 (304 מיליון). ייתכן שיהיה עליך להתאים את הקוד אם תבחר דגם מחוץ לרשימה זו. בנוסף, המחברת מגדירה את צורת תמונת הקלט כברירת מחדל לטנזור תמונה בגודל 224x224x3. זכור להתאים את צורת הקלט בהתאם אם אתה צריך לסמן מודלים שלוקחים תמונה בגודל שונה.

לאחר ריצה על המחברת כולה, תקבל מספר הדמיות של ניתוח ביצועים. השניים הראשונים מפרטים את ביצועי הדגם ביחס להגדלת המשתמשים במקביל. האיורים הבאים הם הדמיות לדוגמה שנוצרו עבור ResNet50 דגם הפועל על ml.g4dn.2xlarge, משווה PyTorch (משמאל) לעומת TensorRT (ימין). גרפי השורה העליונה מציגים את זמן ההשהיה והתפוקה של המודל על ציר ה-y עם מספר גדל והולך של עובדי לקוח בו-זמניים המשתקפים על ציר ה-x. תרשימי העמודות התחתונים מציגים את ספירת הבקשות המוצלחות ונכשלו.

בהסתכלות על כל דגמי הראייה הממוחשבת שבדקנו, ראינו את הדברים הבאים:

• האחזור (במילישניות) גבוה יותר, והתפוקה (בקשות לשנייה) נמוכה יותר עבור דגמים גדולים יותר (resnet50 > convnext_base > vit_large_patch16_224).
• הגדלת האחזור היא פרופורציונלית למספר המשתמשים ככל שבקשות נוספות עומדות בתור על שרת ההסקות.
• מודלים גדולים צורכים יותר משאבי מחשוב ויכולים להגיע למגבלות התפוקה המקסימליות שלהם עם פחות משתמשים מדגם קטן יותר. זה נצפה עם vit_large_patch16_224 דגם, אשר רשם את הבקשה הראשונה שנכשלה ב-140 משתמשים בו-זמנית. בהיותו גדול משמעותית משני הדגמים האחרים שנבדקו, היו לו גם את מספר הבקשות הכושלות הכוללות במקביל גבוה יותר. זהו איתות ברור שנקודת הקצה תצטרך להתרחב מעבר למופע בודד אם הכוונה היא לתמוך ביותר מ-140 משתמשים במקביל.

בסוף ריצת המחברת, תקבל גם השוואה מסכמת של דגמי PyTorch לעומת TensorRT עבור כל אחד מארבעת מדדי המפתח. מבדיקת הבנצ'מרק שלנו, כל דגמי ה-CV ראו חיזוק בביצועי המודל לאחר הידור של TensorRT. לוקח את שלנו ResNet50 המודל כדוגמה שוב, זמן ההשהיה ירד ב-32% בעוד התפוקה גדלה ב-18%. למרות שהמספר המרבי של משתמשים בו-זמנית נשאר זהה עבור ResNet50, שני הדגמים האחרים ראו שניהם שיפור של 14% במספר המשתמשים במקביל שהם יכולים לתמוך בהם. שיפור הביצועים של TensorRT, לעומת זאת, בא על חשבון ניצול זיכרון גבוה יותר, וכתוצאה מכך פחות דגמים שנטענו על ידי MMEs. ההשפעה היא יותר עבור מודלים המשתמשים ברשת עצבית קונבולוציונית (CNN). למעשה, דגם ה-ResNet50 שלנו צרך בערך פי שניים מזיכרון ה-GPU במעבר מ-PyTorch ל-TensorRT, מה שגרם ל-50% פחות דגמים שנטענו (46 לעומת 23). אנו מאבחנים התנהגות זו בהמשך הסעיף הבא.

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

עבור דגמי ה-NLP, השתמש במחברת nlp-benchmark.ipynb כדי להפעיל את בדיקת העומס. ההגדרה של המחברת צריכה להיראות דומה מאוד. בדקנו שני דגמי NLP: bert-base-uncased (109M) ו-roberta-large (335M). הדגם המאומן מראש והטוקנייזר מורידים שניהם ממרכז Hugging Face, ומטען הבדיקה נוצר מהטוקנייזר באמצעות מחרוזת דוגמה. ברירת המחדל של אורך הרצף המקסימלי הוא 128. אם אתה צריך לבדוק מחרוזות ארוכות יותר, זכור להתאים את הפרמטר הזה. ריצה דרך מחברת ה-NLP מייצרת את אותה סט של הדמיות: Pytorch (משמאל) לעומת TensorRT (ימין).

מתוך אלה, ראינו יתרון ביצועים אפילו יותר של TensorRT עבור דגמי NLP. לוקח את ה roberta-large דגם על מופע ml.g4dn.2xlarge, למשל, זמן ההסקה ירד באופן דרמטי מ-180 מילישניות ל-56 מילישניות (שיפור של 70%), בעוד התפוקה השתפרה ב-406% מ-33 בקשות לשנייה ל-167. בנוסף, המספר המרבי של בו-זמנית המשתמשים גדלו ב-50%; בקשות כושלות לא נצפו עד שהגענו ל-180 משתמשים במקביל, לעומת 120 עבור דגם PyTorch המקורי. מבחינת ניצול זיכרון, ראינו דגם אחד פחות נטען עבור TensorRT (מתשעה דגמים לשמונה). עם זאת, ההשפעה השלילית קטנה בהרבה בהשוואה למה שראינו במודלים מבוססי CNN.

ניתוח על ניצול זיכרון

הטבלה הבאה מציגה את הניתוח המלא על ההשפעה על ניצול הזיכרון מ- PyTorch ל- TensorRT. הזכרנו קודם לכן שמודלים מבוססי CNN מושפעים לרעה יותר. ה ResNet50 לדגם היה ירידה של למעלה מ-50% במספר הדגמים שנטענו בכל שלושת סוגי מופעי ה-GPU. Convnext_base הייתה הפחתה גדולה עוד יותר בכ-70% בכל הלוח. מצד שני, ההשפעה על דגמי השנאים קטנה או מעורבת. vit_large_patch16_224 ו roberta-large הייתה ירידה ממוצעת של כ-20% ו-3%, בהתאמה, בעוד bert-base-uncased היה שיפור של כ-40%.

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

הטבלאות הבאות מפרטות את תוצאות ההשוואה המלאות שלנו עבור כל המדדים בכל שלושת סוגי מופעי ה-GPU.

הטבלה הבאה מסכמת את התוצאות בכל סוגי המופעים. המופע ml.g5.2xlarge מספק את הביצועים הטובים ביותר, ואילו המופע של ml.p3.2xlarge בדרך כלל מתפקד נמוך למרות היותו היקר ביותר מבין השלושה. מופעי g5 ו-g4dn מדגימים את הערך הטוב ביותר לעומסי עבודה.

לנקות את

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

delete_endpoint(sm_client, sm_model_name, endpoint_config_name, endpoint_name) ! aws s3 rm --recursive {trt_mme_path}

סיכום

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

על המחברים

ג'יימס וו הוא ארכיטקט פתרונות מומחה בינה מלאכותית/ML בכיר ב-AWS. עוזר ללקוחות לתכנן ולבנות פתרונות AI/ML. עבודתו של ג'יימס מכסה מגוון רחב של מקרי שימוש ב-ML, עם עניין עיקרי בראייה ממוחשבת, למידה עמוקה והרחבת ML ברחבי הארגון. לפני שהצטרף ל-AWS, ג'יימס היה אדריכל, מפתח ומוביל טכנולוגיה במשך למעלה מ-10 שנים, כולל 6 שנים בהנדסה ו-4 שנים בתעשיות שיווק ופרסום.

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

סיימון זמרין הוא אדריכל פתרונות AI / ML שהמוקד העיקרי שלו הוא לעזור ללקוחות להפיק ערך מנכסי הנתונים שלהם. בזמנו הפנוי שמעון נהנה לבלות עם המשפחה, לקרוא מדע בדיוני ולעבוד על פרויקטים שונים של בית DIY.

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

• הפצת תוכן ויחסי ציבור מופעל על ידי SEO. קבל הגברה היום.
• Platoblockchain. Web3 Metaverse Intelligence. ידע מוגבר. גישה כאן.
• מקור: https://aws.amazon.com/blogs/machine-learning/achieve-high-performance-at-scale-for-model-serving-using-amazon-sagemaker-multi-model-endpoints-with-gpu/