استنتاج ML مقرون به صرفه با مدل‌های چند چارچوبی در Amazon 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 همیشه در سرویس و در حافظه هستند، بنابراین هنگام فراخوانی نقطه پایانی شروع سردی وجود ندارد. MCE ها همچنین استفاده از نقطه پایانی را بهبود می بخشند و هزینه ها را بهبود می بخشند زیرا مدل ها در پشت یک نقطه پایانی مستقر می شوند و نمونه محاسباتی اساسی را به اشتراک می گذارند، به جای اینکه هر مدل منابع محاسباتی جداگانه را اشغال کند.

بیایید به چند مورد استفاده نگاه کنیم و ببینیم چگونه می‌توانید از SageMaker MCE برای بهینه‌سازی استنتاج ML استفاده کنید.

از موارد برای MCE های SageMaker استفاده کنید

فرض کنید شما دو مدل برای طبقه‌بندی احساسات دارید، یکی برای زبان انگلیسی و دیگری برای زبان آلمانی، و این مدل‌ها در مناطق جغرافیایی مختلف با ترافیک در زمان‌های مختلف در روز خدمت می‌کنند. به جای داشتن دو نقطه پایانی که به صورت 24 ساعته در حال اجرا هستند، می توانید هر دوی آنها را با استفاده از 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 instance به شما امکان می دهد خط لوله استنتاج متشکل از یک دنباله خطی از چهار ظرف را تعریف کنید که درخواست های استنتاج روی داده ها را پردازش می کند. کانتینرها در یک نمونه قرار گرفته اند و شما را قادر می سازد استنتاج را با تأخیر کم اجرا کنید.

مقیاس‌بندی نقاط پایانی چند مدل برای تعداد زیادی مدل

مزایای نقاط پایانی چند مدل 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.

ما همچنین می‌توانیم MCEهای SageMaker را بر اساس معیارهای سفارشی خودمان، مانند CPUUtilization, MemoryUtilization, GPUUtilization, GPUMemoryUtilization، یا DiskUtilization، برای افزایش یا کاهش تعداد نمونه ها بر اساس استفاده از یک منبع خاص. برای اطلاعات بیشتر مراجعه کنید مقیاس خودکار Amazon SageMaker Models.

توصیه می شود که مدل در هر کانتینر الزامات محاسباتی و تأخیر مشابهی را در هر درخواست استنتاج نشان دهد، زیرا اگر ترافیک به MCE از یک مدل استفاده از CPU بالا به یک مدل استفاده از CPU پایین تغییر کند، اما حجم کلی تماس ثابت باقی بماند، نقطه پایان است. بزرگ نمی شود و ممکن است نمونه های کافی برای رسیدگی به تمام درخواست های مدل استفاده بالای CPU وجود نداشته باشد.

MCE های امن

برای MCE هایی با فراخوانی مستقیم، چندین کانتینر در یک نمونه واحد با اشتراک حافظه و حجم ذخیره سازی میزبانی می شوند. مهم است که کانتینرها را ایمن کنید، نقشه‌برداری صحیح درخواست‌ها برای کانتینرهای هدف را حفظ کنید و دسترسی صحیح به کانتینرهای هدف را برای کاربران فراهم کنید. می توانید محدود کنید 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*"]
                }
            }
        }
    ]
}

با استفاده از معیارهای آمازون CloudWatch، نقاط پایانی چند مدل را رصد کنید

برای ایجاد معاوضه قیمت و عملکرد، می‌خواهید نقاط پایانی چند مدلی را با مدل‌ها و ترافیک نماینده برنامه خود آزمایش کنید. SageMaker معیارهای بیشتری را در اختیار شما قرار می دهد CloudWatch آمازون برای نقاط پایانی چند مدلی، بنابراین می توانید میزان استفاده از نقطه پایانی و نرخ ضربه حافظه پنهان را تعیین کنید و نقطه پایانی خود را بهینه کنید. معیارها به شرح زیر است:

• ModelLoadingWaitTime - فاصله زمانی که یک درخواست فراخوان منتظر می ماند تا مدل هدف دانلود یا بارگذاری شود تا استنتاج انجام شود.
• ModelUnloadingTime - فاصله زمانی که طول می کشد تا مدل از طریق کانتینر تخلیه شود UnloadModel تماس API.
• ModelDownloadingTime – فاصله زمانی که برای دانلود مدل از آمازون S3 طول می کشد.
• ModelLoadingTime - فاصله زمانی که طول می کشد تا مدل از طریق کانتینر بارگیری شود LoadModel تماس API.
• ModelCacheHit - تعداد InvokeEndpoint درخواست ها به نقطه پایانی که مدل قبلاً بارگیری شده بود ارسال می شود. گرفتن Average آمار نسبت درخواست هایی را که مدل قبلاً بارگذاری شده است را نشان می دهد.
• LoadedModelCount – تعداد مدل های بارگیری شده در ظروف در نقطه پایانی. این معیار برای هر نمونه منتشر می شود. این Average آمار با بازه زمانی 1 دقیقه میانگین تعداد مدل های بارگذاری شده در هر نمونه را به شما می گوید و Sum آمار به شما می گوید تعداد کل مدل های بارگذاری شده در تمام نمونه ها در نقطه پایانی. مدل هایی که این متریک ردیابی می کند لزوماً منحصر به فرد نیستند زیرا می توانید یک مدل را در چندین کانتینر در نقطه پایانی بارگیری کنید.

چندین معیار دیگر نیز وجود دارد که توسط هر کانتینری که روی یک نمونه اجرا می شود، استفاده می شود، مانند Invocations با نشان دادن تعداد InvokeEndpoint درخواست‌هایی که به یک کانتینر در یک نقطه پایانی ارسال می‌شوند، ContainerLatency دادن زمانی که یک نقطه پایانی برای کانتینر هدف یا همه کانتینرهای یک فراخوانی سریال برای پاسخ دادن همانطور که از SageMaker مشاهده شده است، و CPUUtilization و MemoryUtilizaton واحدهای CPU و درصد حافظه را نشان می دهد.

نتیجه

در این پست، بحث کردیم که چگونه نقاط پایانی چند کانتینری SageMaker می توانند در بهینه سازی هزینه ها و استفاده از منابع مفید باشند. نمونه هایی از زمان استفاده از MCE شامل موارد زیر است، اما محدود به آنها نیست:

• میزبانی مدل‌ها در چارچوب‌های مختلف (مانند TensorFlow، PyTorch، و Scikit-learn) که ترافیک کافی برای اشباع ظرفیت کامل یک نمونه ندارند.
• میزبانی مدل‌ها از چارچوب یکسان با الگوریتم‌های مختلف ML (مانند توصیه‌ها، پیش‌بینی یا طبقه‌بندی) و توابع کنترل‌کننده
• مقایسه معماری‌های مشابه در حال اجرا بر روی نسخه‌های چارچوب مختلف (مانند TensorFlow 1.x در مقابل TensorFlow 2.x) برای سناریوهایی مانند آزمایش A/B

SageMaker MCE از استقرار حداکثر 15 کانتینر در نقاط پایانی بلادرنگ و فراخوانی مستقل آنها برای استنتاج با تاخیر کم و صرفه جویی در هزینه پشتیبانی می کند. مدل‌ها می‌توانند کاملاً ناهمگن باشند، با پشته سرویس مستقل خود. شما می توانید این کانتینرها را به صورت متوالی یا مستقل برای هر درخواست فراخوانی کنید. میزبانی ایمن چندین مدل، از چارچوب‌های مختلف، در یک نمونه می‌تواند در مقایسه با مدل‌های میزبانی در نقاط پایانی اختصاصی تک نمونه، تا ۹۰ درصد در هزینه شما صرفه‌جویی کند.

درباره نویسندگان

داوال پاتل یک معمار اصلی یادگیری ماشین در AWS است. او با سازمان‌هایی از شرکت‌های بزرگ گرفته تا استارت‌آپ‌های متوسط ​​در زمینه مشکلات مربوط به محاسبات توزیع‌شده و هوش مصنوعی کار کرده است. او بر یادگیری عمیق، از جمله NLP و حوزه های بینایی کامپیوتر تمرکز می کند. او به مشتریان کمک می کند تا به استنباط مدل با عملکرد بالا در Amazon SageMaker دست یابند.

ویکرام الانگو یک معمار ارشد راه حل های تخصصی AI/ML در خدمات وب آمازون، مستقر در ویرجینیا، ایالات متحده است. Vikram با طراحی و رهبری فکری به مشتریان جهانی صنعت مالی و بیمه کمک می‌کند تا برنامه‌های یادگیری ماشینی را در مقیاس بسازند و به کار گیرند. او در حال حاضر روی پردازش زبان طبیعی، هوش مصنوعی مسئول، بهینه‌سازی استنتاج و مقیاس‌بندی ML در سراسر سازمان متمرکز است. او در اوقات فراغت خود از مسافرت، پیاده روی، آشپزی و کمپینگ با خانواده لذت می برد.

ساوراب تریکاند مدیر محصول ارشد Amazon SageMaker Inference است. او مشتاق کار با مشتریان است و هدفش دموکراتیک کردن یادگیری ماشین است. او روی چالش‌های اصلی مربوط به استقرار برنامه‌های پیچیده ML، مدل‌های ML چند مستاجر، بهینه‌سازی هزینه‌ها و در دسترس‌تر کردن استقرار مدل‌های یادگیری عمیق تمرکز می‌کند. Saurabh در اوقات فراغت خود از پیاده روی، یادگیری در مورد فن آوری های نوآورانه، دنبال کردن TechCrunch و گذراندن وقت با خانواده خود لذت می برد.