מסקנות ML חסכוניות עם דגמי ריבוי מסגרות באמזון SageMaker 

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

אמזון SageMaker נקודות קצה מרובות מכולות (MCEs) מאפשרות לנו לקבץ מודלים על מסגרות שונות ולפרוס אותם לאותו מארח, וליצור נקודת קצה אחת. אתה יכול לספק קונטיינרים למסגרות השונות שבהן אתה משתמש לבניית המודלים, ו- SageMaker לוקח את כל הקונטיינרים האלה ומציב אותם מאחורי נקודת קצה אחת. לדוגמה, אתה יכול לקבל מודל PyTorch ו-TensorFlow על שתי נקודות קצה ייעודיות המשרתות מקרי שימוש זהים או שונים לחלוטין, ולשני המודלים הללו יש תעבורה נכנסת לסירוגין שלא מנצלת משאבים עד קצה גבול היכולת. בתרחיש כזה, תוכל לרכז אותם יחד באמצעות קונטיינרים לנקודת קצה אחת באמצעות MCE, לשפר את ניצול המשאבים תוך הפחתת העלויות הכרוכות בכך ששני המודלים משרתים מנקודות קצה שונות.

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

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

דפוסי קריאת MCE

הפעלה ישירה של SageMaker MCE שימושית במקרים שבהם צירפת מודלים לא קשורים לנקודת קצה MCE או שאתה מפעיל בדיקת A/B בין הדגמים שמאחורי נקודת קצה MCE כדי לאמוד את הביצועים שלהם. אתה יכול לקרוא למיכל הספציפי ישירות בקריאת ה-API ולקבל את החיזוי מהמודל הזה.

עם הפעלה סדרתית, אתה יכול לחבר 2-15 מיכלים, והפלט של אחד מהם הופך לקלט של המיכל הבא ברצף. זהו מקרה שימוש אידיאלי אם, למשל, יש לך צינור חיזוי רב-שלבי שבו נעשה שימוש במודל של Scikit-learn עבור חיזוי ביניים והתוצאה מוזנת למודל של TensorFlow להסקה סופית. במקום לפרוס אותם כנקודות קצה שונות ויישום או עבודה אחרת לתזמר אותם ולבצע שיחות API מרובות, אתה יכול לפרוס אותם כ- SageMaker MCE, להפשט את ההיגיון ולהגדיר אותם להפעלה סדרתית, כאשר SageMaker מנהלת את העברת הנתונים בין מיכל אחד לאחר באופן אוטומטי ופולט את הפלט של הקונטיינר הסופי ללקוח שמבצע את בקשת ה-API.

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

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

בוא נסתכל על כמה מקרי שימוש ונראה איך אתה יכול להשתמש ב-MCE של SageMaker כדי לייעל מסקנות ML.

מקרי שימוש עבור SageMaker MCEs

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

englishModel = {
   'Image': container1,
   'ContainerHostname': englishModel }; ...
 
germanModel = {
   'Image': container2,
   'ContainerHostname': germanModel }; ...
 
sm.create_model(
   InferenceExecutionConfig = {'Mode': 'Direct'},
   Containers = [englishModel, germanModel], ...)
sm.create_endpoint_config(EndpointConfigName = ‘my-mce-epc’,
    ProductionVariants=[{
        'InstanceType':        ‘ml.m4.xlarge’,
        'InitialInstanceCount': 2,
        'InitialVariantWeight': 1,
        'ModelName':            ‘my-multi-model-name’,
        'VariantName':          'AllTraffic'}])
sm.create_endpoint(EndpointName = ‘my-mce-endpoint’, 
                  EndpointConfigName = ‘my-mce-epc’)

בדוגמה זו, יש לנו שני דגמים (englishModel ו germanModel), ואנו מגדירים את הקונטיינרים ב- SageMaker create_model לבנות ולהגדיר את InferenceExecutionConfig בתור 'ישיר'. כעת אנו יכולים לקרוא לנקודת הקצה להסקת מסקנות ולהגדיר את TargetContainerHostname כמו גם englishModel or germanModel בהתאם ללקוח שמבצע את קריאת ה-API:

sm.invoke_endpoint(        
   EndpointName = endpoint_name,
   TargetContainerHostname = englishModel,
   Body = body, ...)

אתה יכול גם להשתמש בהפעלה ישירה בתוך ה-MCE כדי להריץ מבחני A/B כדי להשוות את הביצועים בין הדגמים.

התרשים הבא ממחיש את הארכיטקטורה שלנו.

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

עבור מקרה שימוש זה, אנו משתמשים בקוד הבא:

sm_model = PipelineModel(name=model_name, role=aws_role, models=[Processing-1, Processing-2, Inference-1, Inference-2]) 

predictor = sm_model.deploy(initial_instance_count=1, instance_type="ml.c4.xlarge")                  
response = runtime.invoke_endpoint( 
EndpointName=predictor.endpoint,                                
    Body=body,...)

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

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

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

שינוי קנה המידה של נקודות הקצה של MCE הוא גם פשוט באמצעות SageMakerVariantInvocationsPerInstance מדד מוגדר מראש, שנותן את מספר הפעמים הממוצע בדקה שכל מופע עבור נקודת קצה של מודל מופעל כדי להגדיר TargetScaling מְדִינִיוּת. SageMaker מתאים באופן דינמי את מספר המופעים המסופקים עבור מודל בתגובה לשינויים בעומס העבודה שלך. כאשר עומס העבודה גדל, קנה מידה אוטומטי מביא יותר מופעים לאינטרנט ונטען עם דגמי היעד והמכולות כדי להמשיך ולשרת את הבקשות. כאשר עומס העבודה יורד, קנה מידה אוטומטי מסיר מופעים מיותרים ומוריד את מיכלי הדגם כך שהמכולות לא יאכלו את המשאבים, ואתה לא משלם על מופעים שאתה לא משתמש בהם. הזמן להשלמת הבקשה הראשונה כנגד דגם נתון חווה חביון נוסף (נקרא התחלה קרה) להורדת הדגם ממנו שירות אחסון פשוט של אמזון (Amazon S3) וטען אותו לזיכרון. שיחות עוקבות מסתיימות ללא תקורה נוספת מכיוון שהדגם כבר נטען. ראה את הקוד הבא:

# AutoScaling client
asg = boto3.client('application-autoscaling')

# Resource type is variant and the unique identifier is the resource ID.
resource_id=f"endpoint/{endpoint_name}/variant/AllTraffic"

# scaling configuration
response = asg.register_scalable_target(
    ServiceNamespace='sagemaker', #
    ResourceId=resource_id,
    ScalableDimension='sagemaker:variant:DesiredInstanceCount', 
    MinCapacity=1,
    MaxCapacity=4
)
#Target Scaling
response = asg.put_scaling_policy(
    PolicyName=f'Request-ScalingPolicy-{endpoint_name}',
    ServiceNamespace='sagemaker',
    ResourceId=resource_id,
    ScalableDimension='sagemaker:variant:DesiredInstanceCount',
    PolicyType='TargetTrackingScaling',
    TargetTrackingScalingPolicyConfiguration={
        'TargetValue': 70.0, # Threshold
        'PredefinedMetricSpecification': {
            'PredefinedMetricType': 'SageMakerVariantInvocationsPerInstance',
        },
        'ScaleInCooldown': 300, # duration until scale in
        'ScaleOutCooldown': 60 # duration between scale out
    }
)

בעקבות תצורת המדיניות לדוגמה הקודמת, אנו משתמשים ב- SageMakerVariantInvocationsPerInstance מדד מוגדר מראש כדי להתאים את מספר מופעי הגרסה כך שלכל מופע יש InvocationsPerInstance מדד של 70.

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

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

MCE מאובטחים

עבור MCEs עם הפעלה ישירה, קונטיינרים מרובים מתארחים במופע אחד על ידי שיתוף זיכרון ונפח אחסון. חשוב לאבטח את הקונטיינרים, לשמור על מיפוי נכון של בקשות למיקוד קונטיינרים ולספק למשתמשים את הגישה הנכונה לקונטיינרים. אתה יכול להגביל invoke_endpoint גישה לסט מוגבל של מכולות בתוך MCE באמצעות ה sagemaker:TargetContainerHostname AWS זהות וניהול גישה מפתח תנאי (IAM). SageMaker משתמש תפקידי IAM לספק מדיניות מבוססת זהות של IAM שבה אתה משתמש כדי לציין פעולות ומשאבים מותרים או דחויים ואת התנאים שבהם פעולות מותרות או נדחות. המדיניות הבאה מציגה כיצד להגביל שיחות למכולות ספציפיות בתוך נקודת קצה:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "sagemaker:InvokeEndpoint"
            ],
            "Effect": "Allow",
            "Resource": "arn:aws:sagemaker:region:account-id:endpoint/endpoint_name",
            "Condition": {
                "StringLike": {
                    "sagemaker:TargetContainerHostname": ["customIps*", "common*"]
                }
            }
        }
    ]
}

מעקב אחר נקודות קצה מרובות דגמים באמצעות מדדי Amazon CloudWatch

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

• ModelLoadingWaitTime – מרווח הזמן שבו בקשת הפניה ממתינה להורדה או הטעינה של מודל היעד לביצוע ההסקה.
• ModelUnloadingTime – מרווח הזמן שלוקח לפרוק את הדגם דרך המכולה UnloadModel שיחת API.
• זמן הורדה של דגם - מרווח הזמן שלוקח להוריד את הדגם מאמזון S3.
• ModelLoadingTime – מרווח הזמן שלוקח לטעון את הדגם דרך המכולה LoadModel שיחת API.
• ModelCacheHit - מספר ה InvokeEndpoint בקשות שנשלחו לנקודת הקצה שבה המודל כבר נטען. לוקח את ה Average סטטיסטיקה מציגה את יחס הבקשות שבהן המודל כבר נטען.
• LoadedModelCount – מספר הדגמים הטעונים במכולות בנקודת הקצה. מדד זה נפלט בכל מופע. ה Average סטטיסטיקה עם פרק זמן של דקה 1 אומר לך את המספר הממוצע של דגמים נטענים לכל מופע, ואת Sum סטטיסטיקה אומרת לך את המספר הכולל של מודלים שנטענו בכל המופעים בנקודת הקצה. המודלים שמדד זה עוקב אחריהם אינם בהכרח ייחודיים מכיוון שניתן לטעון מודל במספר מיכלים בנקודת הקצה.

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

סיכום

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

• אירוח מודלים על פני מסגרות שונות (כגון TensorFlow, PyTorch ו-Scikit-learn) שאין להם מספיק תעבורה כדי להרוות את מלוא הקיבולת של מופע
• אירוח מודלים מאותה מסגרת עם אלגוריתמים שונים של ML (כגון המלצות, חיזוי או סיווג) ופונקציות מטפל
• השוואות של ארכיטקטורות דומות הפועלות על גרסאות מסגרת שונות (כגון TensorFlow 1.x לעומת TensorFlow 2.x) עבור תרחישים כמו בדיקות A/B

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

על המחברים

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

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

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