השג ביצועים בקנה מידה גבוה עבור הגשת מודלים באמצעות NVIDIA Triton Inference Server ב-Amazon SageMaker

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

דפוס נפוץ להנעת זמני תגובה נמוכים יותר מבלי להתפשר על התפוקה הכוללת הוא אירוח דגמים אלה באותו מופע יחד עם ההיגיון העסקי הקל המוטמע בו. מודלים אלה יכולים להיות מובלעים במיכלים בודדים או מרובים באותו מופע על מנת לספק בידוד לתהליכים הפועלים ולשמור על זמן אחזור נמוך. בנוסף, השהיה הכוללת תלויה גם בלוגיקה של יישומי הסקת מסקנות, אופטימיזציות של מודלים, התשתית הבסיסית (כולל מחשוב, אחסון ורשת), ושרת האינטרנט הבסיסי מקבל בקשות להסקת מסקנות. NVIDIA Triton Inference Server היא תוכנה לשרת מסקנות בקוד פתוח עם תכונות למקסום התפוקה וניצול החומרה עם זמן השהייה נמוך במיוחד (מילישניות חד ספרתיות). יש לו תמיכה רחבה במסגרות ML (כולל TensorFlow, PyTorch, ONNX, XGBoost ו-NVIDIA TensorRT) ותשתיות אחוריות, כולל GPUs, CPUs, ו Afer Inferentia. בנוסף, Triton Inference Server משולב עם אמזון SageMaker, שירות ML מנוהל במלואו מקצה לקצה, המספק אפשרויות מסקנות בזמן אמת כולל יחיד ו רב דגם אירוח. אפשרויות מסקנות אלו כוללות אירוח של מספר דגמים בתוך אותו מיכל מאחורי a נקודת קצה בודדת, ואירוח מספר דגמים עם מספר מיכלים מאחורי נקודת קצה אחת.

בנובמבר 2021 הודענו השילוב של Triton Inference Server ב- SageMaker. AWS עבדה בשיתוף פעולה הדוק עם NVIDIA כדי לאפשר לך לקבל את המיטב משני העולמות ולהפוך את פריסת הדגמים עם Triton ב-AWS לקלה יותר.

בפוסט זה, אנו מסתכלים על שיטות עבודה מומלצות לפריסת דגמי שנאים בקנה מידה על GPUs באמצעות Triton Inference Server ב- SageMaker. ראשית, אנו מתחילים עם סיכום של מושגי מפתח סביב חביון ב- SageMaker, וסקירה כללית של הנחיות כוונון ביצועים. לאחר מכן, אנו מספקים סקירה כללית של Triton והתכונות שלו, כמו גם קוד לדוגמה לפריסה ב- SageMaker. לבסוף, אנו מבצעים בדיקות עומס באמצעות SageMaker Inference Recommend ולסכם את התובנות והמסקנות מבדיקת עומס של דגם שנאי פופולרי שסופק על ידי Hugging Face.

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

כוונון ביצועים ואופטימיזציה להגשת דגמים ב- SageMaker

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

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

מסקנות והשהייה בזמן אמת ב- SageMaker

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

• זמן אחזור של מיכל – הזמן שלוקח לשלוח את הבקשה, להביא את התגובה מהמיכל של הדגם ולהשלים מסקנות בקונטיינר. מדד זה זמין ב- Amazon CloudWatch כחלק מה- מדדי פנייה פורסם על ידי SageMaker.
• חביון מודל – הזמן הכולל שלוקח כל מכולות SageMaker ב- צינור מסקנות. מדד זה זמין ב- Amazon CloudWatch כחלק מה- מדדי פנייה פורסם על ידי SageMaker.
• חביון תקורה – נמדד מרגע קבלת הבקשה של SageMaker ועד להחזרת תגובה ללקוח, בניכוי חביון הדגם. מדד זה זמין ב- Amazon CloudWatch כחלק מה- מדדי פנייה פורסם על ידי SageMaker.
• זמן אחזור מקצה לקצה – נמדד מרגע שהלקוח שולח את בקשת ההסקה ועד לקבלת תשובה בחזרה. לקוחות יכולים לפרסם זאת כמדד מותאם אישית באמזון CloudWatch.

התרשים הבא ממחיש רכיבים אלה.

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

• פרוטוקול בסיס (HTTP(s)/gRPC) המשמש לתקשורת עם שרת ההסקות
• תקורה הקשורה ליצירת חיבורי TLS חדשים
• זמן הסידריאליזציה של מטען הבקשה/תגובה
• בקש תכונות תור ואצווה המסופקות על ידי שרת ההסקות הבסיסי
• בקש יכולות תזמון הניתנות על ידי שרת ההסקות הבסיסי
• ביצועי זמן ריצה בסיסיים של שרת ההסקות
• ביצועים של ספריות עיבוד מקדים ואחרי עיבוד לפני קריאה לפונקציית חיזוי המודל
• הביצועים הבסיסיים של מסגרת ML Backend
• אופטימיזציות ספציפיות לדגם ולחומרה ספציפיות

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

השתמש בסקירת המקרים

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

בפוסט זה, אנו מודדים מקרה שימוש ב-NLP באמצעות נקודת קצה של SageMaker בזמן אמת המבוססת על מיכל Triton Inference Server וממליצים על אופטימיזציות של כוונון ביצועים עבור מקרה השימוש שלנו ב-ML. אנו משתמשים ב-Huging Face גדול ומאומן מראש מבוסס שנאי BERT גדול ללא מעטה דגם, בעל כ-336 מיליון פרמטרים של דגם. משפט הקלט המשמש למודל הסיווג הבינארי מרופד וקטוע לאורך רצף קלט מקסימלי של 512 אסימונים. מבחן עומס ההסקה מדמה 500 קריאות בשנייה (30,000 מקסימום קריאות לדקה) ו ModelLatency של פחות מ-0.5 שניות (500 מילישניות).

הטבלה הבאה מסכמת את תצורת המדד שלנו.

NVIDIA Triton Inference Server

Triton Inference Server תוכנן במיוחד כדי לאפשר פריסה ניתנת להרחבה, מהירה וקלה של מודלים בייצור. Triton תומך במגוון מסגרות AI עיקריות, כולל TensorFlow, TensorRT, PyTorch, XGBoost ו- ONNX. עם ה-Python ו-C++ backend מותאם אישית, אתה יכול גם ליישם את עומס העבודה שלך להסקת מקרי שימוש מותאמים אישית יותר.

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

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

אצווה דינמית

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

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

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

dynamic_batching { preferred_batch_size: 16 max_queue_delay_microseconds: 100 }

הפעלת דגמים במקביל

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

האיור הבא מציג כיצד תוכל להגדיר בקלות מדיניות פריסה של מודלים שונים עם מספר שורות של שינויים בקוד בלבד. לדוגמה, תצורה A (משמאל) מראה שאתה יכול לשדר את אותה תצורה של שני מופעי דגם של bert-large-uncased לכל ה-GPUs הזמינים. לעומת זאת, תצורה B (באמצע) מציגה תצורה שונה עבור GPU 0 בלבד, מבלי לשנות את המדיניות ב-GPUs האחרים. אתה יכול גם לפרוס מופעים של דגמים שונים על GPU יחיד, כפי שמוצג בתצורה C (מימין).

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

TensorRT

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

TensorRT מייעל את הגרף כדי למזער את טביעת הרגל של הזיכרון על ידי שחרור זיכרון מיותר ושימוש חוזר ביעילות בו. בנוסף, קומפילציה של TensorRT ממזגת את הפעולות הדלילות בתוך גרף המודל ליצירת ליבה גדולה יותר כדי למנוע את התקורה של השקות קרנל קטנות מרובות. כוונון אוטומטי של ליבה עוזר לך לנצל את החומרה במלואה על ידי בחירת האלגוריתם הטוב ביותר ב-GPU היעד שלך. זרמי CUDA מאפשרים לדגמים לפעול במקביל כדי למקסם את ניצול ה-GPU שלך לביצועים הטובים ביותר. אחרון חביב, טכניקת הקוונטיזציה יכולה להשתמש במלואה בתאוצת הדיוק המעורב של ליבות ה-Tensor כדי להפעיל את המודל ב-FP32, TF32, FP16 ו-INT8 כדי להשיג את ביצועי ההסקה הטובים ביותר.

טריטון על אירוח של SageMaker

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

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

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

SageMaker Inference Recommendence לבדיקת תוצאות בדיקות

אנו משתמשים ב- SageMaker Inference Recommender כדי להפעיל את הניסויים שלנו. SageMaker Inference Recommender מציע שני סוגים של עבודות: ברירת מחדל ומתקדמות, כפי שמוצג בתרשים הבא.

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

העבודה המתקדמת מציעה יותר פקדים לשיפור הביצועים. בקרות אלה מדמים את הסביבה האמיתית ואת דרישות הייצור. בין הפקדים הללו ניתן למצוא את דפוס התעבורה, שמטרתו לביים את דפוס הבקשות עבור המדדים. אתה יכול להגדיר רמפות או תנועה קבועה על ידי שימוש במספר השלבים של דפוס התנועה. לדוגמה, א InitialNumberOfUsers של 1, SpawnRate מתוך 1, ו DurationInSeconds של 600 עלול לגרום לתנועת רמפה של 10 דקות עם משתמש אחד במקביל בהתחלה ו-1 בסוף. בנוסף, על הפקדים, MaxInvocations ו ModelLatency Thresholds הגדירו את סף הייצור, כך שכאשר חריגה מאחד הספים, ההשוואה נעצרת.

לבסוף, מדדי המלצות כוללים תפוקה, זמן השהייה בתפוקה מקסימלית ועלות לכל מסקנות, כך שקל להשוות ביניהם.

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

הגדרת הניסוי

אנו משתמשים בתכונת בדיקת העומס המותאמת אישית של SageMaker Inference Recommender כדי לסמן את פרופיל ה-NLP המתואר במקרה השימוש שלנו. תחילה אנו מגדירים את התנאים המוקדמים הבאים הקשורים למודל ה-NLP ולמטלת ML. SageMaker Inference Recommender משתמש במידע זה כדי למשוך ממנה תמונת Docker מסקנת מסקנות מרשם מיכל אלסטי של אמזון (Amazon ECR) ורשום את הדגם עם רישום הדגמים של SageMaker.

תצורות דפוס התנועה ב- SageMaker Inference Recommender מאפשרות לנו להגדיר שלבים שונים עבור מבחן העומס המותאם אישית. מבחן הטעינה מתחיל בשני משתמשים ראשוניים ומוליד שני משתמשים חדשים בכל דקה, למשך כולל של 25 דקות (1500 שניות), כפי שמוצג בקוד הבא:

"TrafficPattern": { "TrafficType": "PHASES", "Phases": [ { "InitialNumberOfUsers": 2, "SpawnRate": 2, "DurationInSeconds": 1500 }, ],
}

אנו מתנסים בבדיקת עומסים של אותו דגם בשני מצבים שונים. הניסויים המבוססים על PyTorch משתמשים במודל PyTorch הסטנדרטי, ללא שינוי. עבור הניסויים המבוססים על TensorRT, אנו ממירים את מודל PyTorch למנוע TensorRT מראש.

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

תוצאות בדיקות ותצפיות

ערכנו מבחני עומס עבור שלושה סוגי מופעים בתוך אותה משפחת g4dn: ml.g4dn.xlarge, ml.g4dn.2xlarge ו-ml.g4dn.12xlarge. לכל סוגי המופעים של g4dn יש גישה ל-NVIDIA T4 Tensor Core GPUs ולמעבדי Intel Cascade Lake מהדור השני. ההיגיון מאחורי בחירת סוגי המופעים היה שיהיה גם מופע עם GPU אחד זמין בלבד, וגם מופע עם גישה למספר GPUs - ארבעה במקרה של ml.g2dn.4xlarge. בנוסף, רצינו לבדוק אם הגדלת קיבולת ה-vCPU במופע עם GPU זמין אחד בלבד תניב שיפור ביחס עלות-ביצועים.

בואו נעבור תחילה על המהירות של האופטימיזציה האישית. הגרף הבא מראה שאופטימיזציה של TensorRT מספקת הפחתה של 50% בהשהיית המודל בהשוואה לזה המקורי ב- PyTorch במופע ml.g4dn.xlarge. הפחתת זמן ההשהיה הזו גדלה ליותר מפי שלושה במופעי ריבוי GPU של ml.g4dn.12xlarge. בינתיים, שיפור התפוקה של 30% עקבי בשני המקרים, וכתוצאה מכך עלות-תועלת טובה יותר לאחר החלת אופטימיזציות של TensorRT.

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

באופן דומה, ביצוע מודל במקביל מאפשר לנו להשיג שיפור של בערך פי 3-4 בתפוקה על ידי מיקסום ניצול ה-GPU במופע ml.g4dn.xlarge ושיפור בערך פי 2 גם במופע ml.g4dn.2xlarge וגם במופע הרב-GPU של ml. g4dn.12xlarge.. הגדלת התפוקה הזו מגיעה ללא כל תקורה בהשהיה.

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

[1] ספירת המופעים הראשונית בטבלה שלמעלה היא המספר המומלץ של מופעים לשימוש עם מדיניות קנה מידה אוטומטי כדי לשמור על דרישות התפוקה והשהייה עבור עומס העבודה שלך.

[2] עלות לשעה בטבלה לעיל מחושבת על סמך ספירת המופעים הראשוניים והמחיר עבור סוג המופע.

התוצאות מאמתות לרוב את ההשפעה שציפתה מתכונות שונות של אופטימיזציית ביצועים:

• להידור TensorRT יש את ההשפעה האמינה ביותר בכל סוגי המופעים. עסקאות לדקה למופע גדלו ב-30-35%, עם הפחתת עלויות עקבית של כ-25% בהשוואה לביצועי מנוע TensorRT לברירת המחדל PyTorch BERT (pt-base). הביצועים המוגברים של מנוע TensorRT מתווספים ומנוצלים על ידי תכונות כוונון הביצועים האחרות שנבדקו.
• טעינת שני דגמים על כל GPU (קבוצת מופעים) הכפילה כמעט לחלוטין את כל המדדים הנמדדים. הפניות לדקה למופע עלו בכ-80-90%, והניבו הפחתה בעלויות בטווח של 50%, כמעט כאילו אנו משתמשים בשני GPUs. למעשה, אמזון CloudWatch מדדים עבור הניסויים שלנו ב-g4dn.2xlarge (כדוגמה) מאשרים כי ניצול המעבד וה-GPU כפול כאשר אנו מגדירים קבוצת מופעים של שני דגמים.

טיפים נוספים לביצועים ולאופטימיזציית עלויות

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

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

אנו מצפים לבדוק ולהשוות את הטכניקות והתכונות הללו בפוסט עתידי, אז הישארו מעודכנים!

סיכום

בפוסט זה, בדקנו כמה פרמטרים שבהם אתה יכול להשתמש כדי למקסם את הביצועים של נקודת הקצה שלך בזמן אמת של SageMaker לשרת מודלים של PyTorch BERT עם Triton Inference Server. השתמשנו ב- SageMaker Inference Recommender כדי לבצע את מבחני ההשוואה כדי לכוונן את הפרמטרים הללו. פרמטרים אלו קשורים במהותם לאופטימיזציה של מודלים מבוססי TensorRT, המובילה לכמעט 50% שיפור בזמני התגובה בהשוואה לגרסה הלא מותאמת. בנוסף, הפעלת דגמים במקביל ושימוש באצווה דינמית של Triton הובילה לעלייה של כמעט 70% בתפוקה. כוונון עדין של פרמטרים אלה הוביל גם להפחתה כוללת של עלות ההסקה.

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

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

אתה יכול למצוא את המחברת המשמשת לבדיקת עומס ופריסה GitHub. אתה יכול לעדכן את תצורות ה-Triton ואת הגדרות SageMaker Inference Recommender כך שיתאימו בצורה הטובה ביותר למקרה השימוש שלך כדי להשיג עומסי עבודה חסכוניים ובעלי ביצועים טובים ביותר.

על הכותבים

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

ז'ואאו מורה הוא אדריכל פתרונות AI/ML מומחה בשירותי האינטרנט של אמזון. הוא מתמקד בעיקר במקרי שימוש ב-NLP ובעזרה ללקוחות לייעל את המודלים של Deep Learning והפריסה. הוא גם חסיד פעיל של פתרונות ML בקוד נמוך וחומרה מתמחה ב-ML.

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

דוואל פאטל הוא אדריכל ראשי למידת מכונה ב-AWS. הוא עבד עם ארגונים החל מארגונים גדולים ועד סטארט-אפים בינוניים על בעיות הקשורות למחשוב מבוזר ובינה מלאכותית. הוא מתמקד בלמידה עמוקה כולל תחומי NLP ו-Computer Vision. הוא עוזר ללקוחות להשיג מסקנות מודל עם ביצועים גבוהים על SageMaker.

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

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

• Coinsmart. בורסת הביטקוין והקריפטו הטובה באירופה.
• Platoblockchain. Web3 Metaverse Intelligence. ידע מוגבר. גישה חופשית.
• CryptoHawk. רדאר אלטקוין. ניסיון חינם.
• מקור: https://aws.amazon.com/blogs/machine-learning/achieve-hyperscale-performance-for-model-serving-using-nvidia-triton-inference-server-on-amazon-sagemaker/