היכרות עם ערכת הכלים של Amazon SageMaker Serverless Inference Benchmarking

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

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

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

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

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

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

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

התקן את ערכת הכלים

ראשית התקן את ספריית ההשוואה בסביבת Python שלך באמצעות pip:

pip install sm-serverless-benchmarking

אתה יכול להריץ את הקוד הבא מ-an סטודיו SageMaker של אמזון למשל, מופע מחברת SageMaker, או כל מופע עם גישה פרוגרמטית ל-AWS והמתאים AWS זהות וניהול גישה הרשאות (IAM). הרשאות IAM הנדרשות מתועדות ב- GitHub ריפו. להנחיות נוספות ומדיניות לדוגמה עבור IAM, עיין ב כיצד עובד Amazon SageMaker עם IAM. קוד זה מריץ מדד עם ערכת ברירת מחדל של פרמטרים במודל המצפה לקלט CSV עם שתי רשומות לדוגמה. זה נוהג טוב לספק סט מייצג של דוגמאות כדי לנתח את הביצועים של נקודת הקצה עם עומסי קלט שונים.

from sm_serverless_benchmarking import benchmark
from sm_serverless_benchmarking.utils import convert_invoke_args_to_jsonl
model_name = ""
example_invoke_args = [
        {'Body': '1,2,3,4,5', "ContentType": "text/csv"},
        {'Body': '6,7,8,9,10', "ContentType": "text/csv"}
        ]
example_args_file = convert_invoke_args_to_jsonl(example_invoke_args,
output_path=".")
r = benchmark.run_serverless_benchmarks(model_name, example_args_file)

בנוסף, אתה יכול להפעיל את ה-benchmark כעבודת SageMaker Processing, שעשויה להיות אפשרות אמינה יותר עבור בנצ'מרקים ארוכי טווח עם מספר רב של קריאות. ראה את הקוד הבא:

from sm_serverless_benchmarking.sagemaker_runner import run_as_sagemaker_job
run_as_sagemaker_job(
                    role="",
                    model_name="",
                    invoke_args_examples_file="",
                    )

שים לב שזה יגרור עלות נוספת של הפעלת מופע של ml.m5.large SageMaker Processing למשך כל תקופת ההשוואה.

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

תצורת השוואת ביצועים

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

יש שתי אפשרויות תצורה מרכזיות: MemorySizeInMB ו MaxConcurrency. MemorySizeInMB מגדיר את כמות הזיכרון המוקצה למופע, ויכול להיות 1024 MB, 2048 MB, 3072 MB, 4096 MB, 5120 MB או 6144 MB. מספר ה-vCPUs גם משתנה באופן יחסי לכמות הזיכרון שהוקצתה. ה MaxConcurrency פרמטר מתאים כמה בקשות בו-זמנית שנקודת קצה מסוגלת לשרת. עם MaxConcurrency מתוך 1, נקודת קצה ללא שרת יכולה לעבד רק בקשה בודדת בכל פעם.

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

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

השוואת תפוקות

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

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

כאשר ההשוואה הושלמה, הכלי מייצר מספר תפוקות במפרט שצוין result_save_path ספרייה עם מבנה הספריות הבא:

├── benchmarking_report
├── concurrency_benchmark_raw_results
├── concurrency_benchmark_summary_results
├── cost_analysis_summary_results
├── stability_benchmark_raw_results
├── stability_benchmark_summary_results

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

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

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

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

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

הטבלה הבאה מציגה את המדדים שנלכדו על ידי CloudWatch עבור כל תצורת זיכרון.

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

הפלט הסופי של מדד העלות והיציבות הוא תצורת זיכרון מומלצת, יחד עם טבלה המשווה את העלות של הפעלת נקודת קצה ללא שרת מול מופע אירוח דומה של SageMaker. בהתבסס על הנתונים שנאספו, הכלי קבע שתצורת 2048 MB היא האופטימלית ביותר עבור דגם זה. למרות שתצורת 3072 מספקת חביון טוב יותר ב-10 אלפיות השנייה, זה מגיע עם עלייה של 30% בעלות, מ-$4.55 ל-$5.95 לכל מיליון בקשות. בנוסף, הפלט מראה שנקודת קצה ללא שרת תספק חיסכון של עד 1% בהשוואה למופע אירוח בזמן אמת, כאשר יש פחות ממיליון בקשות הזמנה חודשיות, ומפרקת עם נקודת קצה בזמן אמת לאחר 88.72 מיליון בקשות.

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

לדוגמה, על ידי הגדרת ה concurrency_benchmark_max_conc parameter ל [4, 8] ו concurrency_num_clients_multiplier עד [1, 1.5, 2], שתי נקודות קצה משוגרות: אחת עם MaxConcurency של 4 והשני 8. לאחר מכן כל נקודת קצה מסומנת עם (MaxConcurency מכפיל x) מספר לקוחות בו-זמניים מדומים, אשר עבור נקודת הקצה עם מקבילות של 4 מתורגם לממדים של בדיקת עומס עם 4, 6 ו-8 לקוחות במקביל.

הפלט הראשון של אמת מידה זה הוא טבלה המציגה את מדדי האחזור, חריגות המצערת ומדדי העסקאות בשנייה (TPS) המשויכים לכל אחד מהם. MaxConcurrency תצורה עם מספרים שונים של לקוחות במקביל. מדדים אלה עוזרים לקבוע את המתאים MaxConcurrency הגדרה לטיפול בעומס התעבורה הצפוי. בטבלה הבאה, אנו יכולים לראות שנקודת קצה שהוגדרה עם מקיפות מקסימלית של 8 הצליחה להתמודד עם עד 16 לקוחות במקביל עם שני חריגים בלבד מתוך 2,500 פניות שבוצעו בממוצע של 24 עסקאות בשנייה.

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

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

סיכום

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

משאבים נוספים

על המחברים

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

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

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