GPU کے ساتھ Amazon SageMaker ملٹی ماڈل اینڈ پوائنٹس کا استعمال کرتے ہوئے ماڈل سرونگ کے لیے پیمانے پر اعلی کارکردگی حاصل کریں۔

ایمیزون سیج میکر ملٹی ماڈل اینڈ پوائنٹس (MMEs) مشین لرننگ (ML) ماڈلز کی ایک بڑی تعداد کو تعینات کرنے کے لیے ایک قابل توسیع اور سرمایہ کاری مؤثر طریقہ فراہم کرتے ہیں۔ یہ آپ کو ایک ہی اختتامی نقطہ کے پیچھے ایک ہی سرونگ کنٹینر میں متعدد ML ماڈلز کو تعینات کرنے کی صلاحیت فراہم کرتا ہے۔ وہاں سے، SageMaker آپ کے ٹریفک پیٹرن کی بنیاد پر آپ کی جانب سے ماڈلز کی لوڈنگ اور ان لوڈنگ اور اسکیلنگ کے وسائل کا انتظام کرتا ہے۔ آپ ہوسٹنگ کے وسائل کو بانٹنے اور دوبارہ استعمال کرنے سے فائدہ اٹھائیں گے اور ماڈلز کی ایک بڑی مقدار کو منظم کرنے کے آپریشنل بوجھ کو کم کریں گے۔

نومبر 2022 میں، MMEs نے GPU کے لیے تعاون شامل کیا۔s، جو آپ کو ایک ہی GPU ڈیوائس پر متعدد ماڈلز چلانے اور ایک اختتامی نقطہ کے پیچھے GPU مثالوں کو پیمانے کی اجازت دیتا ہے۔ یہ ڈیپ نیورل نیٹ ورک (DNN) ماڈلز کی مضبوط MME مانگ کو پورا کرتا ہے جو GPUs کے ساتھ تیز رفتار کمپیوٹ سے فائدہ اٹھاتے ہیں۔ ان میں کمپیوٹر ویژن (CV)، نیچرل لینگویج پروسیسنگ (NLP)، اور جنریٹیو AI ماڈلز شامل ہیں۔ طلب کی وجوہات میں درج ذیل شامل ہیں:

• DNN ماڈل عام طور پر سائز اور پیچیدگی میں بڑے ہوتے ہیں اور تیز رفتاری سے بڑھتے رہتے ہیں۔ مثال کے طور پر NLP ماڈلز کو لے کر، ان میں سے بہت سے اربوں پیرامیٹرز سے تجاوز کرتے ہیں، جس میں کم تاخیر اور اعلی تھرو پٹ کی ضروریات کو پورا کرنے کے لیے GPUs کی ضرورت ہوتی ہے۔
• ہم نے انفرادی صارفین کو ہائپر پرسنلائزڈ تجربات فراہم کرنے کے لیے ان ماڈلز کو حسب ضرورت بنانے کی بڑھتی ہوئی ضرورت کا مشاہدہ کیا ہے۔ جیسے جیسے ان ماڈلز کی مقدار میں اضافہ ہوتا ہے، بہت سے ماڈلز کو پیمانے پر تعینات کرنے اور چلانے کے لیے ایک آسان حل کی ضرورت ہے۔
• GPU مثالیں مہنگی ہیں اور آپ GPU کے استعمال کو زیادہ سے زیادہ کرنے اور آپریٹنگ لاگت کو کم کرنے کے لیے ان مثالوں کو زیادہ سے زیادہ دوبارہ استعمال کرنا چاہتے ہیں۔

اگرچہ یہ تمام وجوہات DNN ماڈلز کے لیے ایک مثالی اختیار کے طور پر GPU والے MMEs کی طرف اشارہ کرتی ہیں، لیکن یہ مشورہ دیا جاتا ہے کہ صحیح اینڈ پوائنٹ کنفیگریشن تلاش کرنے کے لیے لوڈ ٹیسٹنگ کریں جو آپ کے استعمال کے کیس کی ضروریات کو پورا کرتی ہے۔ بہت سے عوامل لوڈ ٹیسٹنگ کے نتائج کو متاثر کر سکتے ہیں، جیسے مثال کی قسم، مثالوں کی تعداد، ماڈل کا سائز، اور ماڈل فن تعمیر۔ اس کے علاوہ، لوڈ ٹیسٹنگ خودکار اسکیلنگ کی حکمت عملیوں کی رہنمائی میں مدد کر سکتی ہے نہ کہ تکراری آزمائش اور غلطی کے طریقوں کی بجائے صحیح میٹرکس کا استعمال کرتے ہوئے۔

ان وجوہات کی بناء پر، ہم نے یہ پوسٹ آپ کو GPU کے ساتھ MMEs پر مناسب لوڈ ٹیسٹنگ انجام دینے اور آپ کے ML کے استعمال کے کیس کے لیے بہترین ترتیب تلاش کرنے میں مدد کرنے کے لیے رکھی ہے۔ ہم NLP اور CV میں کچھ مقبول ترین DNN ماڈلز کے لیے اپنے لوڈ ٹیسٹنگ کے نتائج کو مختلف مثالوں کی اقسام پر MMEs کا استعمال کرتے ہوئے ہوسٹ کرتے ہیں۔ ہم اپنے ٹیسٹ کے نتائج سے حاصل کردہ بصیرت اور نتیجہ کا خلاصہ کرتے ہیں تاکہ آپ کی اپنی تعیناتیوں کو ترتیب دینے کے بارے میں باخبر فیصلہ کرنے میں آپ کی مدد کی جا سکے۔ راستے میں، ہم GPU پر MMEs کے لیے لوڈ ٹیسٹنگ انجام دینے کے لیے اپنے تجویز کردہ نقطہ نظر کا اشتراک بھی کرتے ہیں۔ تجویز کردہ ٹولز اور تکنیک ان ماڈلز کی زیادہ سے زیادہ تعداد کا تعین کرتی ہے جو فی مثال کی قسم لوڈ کیے جاسکتے ہیں اور قیمت کی بہترین کارکردگی حاصل کرنے میں آپ کی مدد کرتے ہیں۔

حل جائزہ

GPU کے ساتھ MMEs اور MMEs کے تعارف کے لیے، رجوع کریں۔ ایک ملٹی ماڈل اینڈ پوائنٹ بنائیں اور Amazon SageMaker ملٹی ماڈل اینڈ پوائنٹس کے ساتھ GPU پر متعدد ڈیپ لرننگ ماڈلز چلائیں۔. اس پوسٹ میں لوڈ ٹیسٹنگ کے سیاق و سباق کے لیے، آپ ہمارے نمونے کوڈ سے ڈاؤن لوڈ کر سکتے ہیں۔ GitHub repo نتائج کو دوبارہ پیش کرنے کے لیے یا اپنے ماڈلز کو بینچ مارک کرنے کے لیے اسے بطور ٹیمپلیٹ استعمال کریں۔ ریپو میں دو نوٹ بک فراہم کی گئی ہیں: ایک لوڈ ٹیسٹنگ CV ماڈلز کے لیے اور دوسری NLP کے لیے۔ مختلف سائز اور آرکیٹیکچرز کے متعدد ماڈلز کو مختلف قسم کے GPU مثالوں پر بینچ مارک کیا گیا تھا: ml.g4dn.2xlarge، ml.g5.2xlarge، اور ml.p3.2xlarge۔ اسے ہر ایک مثال اور ماڈل کی قسم کے لیے درج ذیل میٹرکس میں کارکردگی کا ایک معقول کراس سیکشن فراہم کرنا چاہیے:

• ماڈلز کی زیادہ سے زیادہ تعداد جنہیں GPU میموری میں لوڈ کیا جا سکتا ہے۔
• ہر ایک استفسار کے لیے کلائنٹ کی طرف سے اختتام سے آخر تک جواب میں تاخیر کا مشاہدہ کیا گیا۔
• فی سیکنڈ سوالات کا زیادہ سے زیادہ تھرو پٹ جس پر اختتامی نقطہ بغیر کسی غلطی کے کارروائی کر سکتا ہے۔
• ایک ناکام درخواست دیکھنے سے پہلے فی مثال زیادہ سے زیادہ موجودہ صارفین

درج ذیل جدول میں جانچے گئے ماڈلز کی فہرست دی گئی ہے۔

درج ذیل جدول میں جانچ کی گئی GPU مثالوں کی فہرست دی گئی ہے۔

جیسا کہ پہلے ذکر کیا گیا ہے، کوڈ کی مثال دوسرے ماڈلز اور مثال کی اقسام میں اپنایا جا سکتا ہے۔

نوٹ کریں کہ MMEs فی الحال صرف ایک GPU مثالوں کو سپورٹ کرتے ہیں۔ معاون مثال کی اقسام کی فہرست کے لیے، رجوع کریں۔ تعاون یافتہ الگورتھم، فریم ورک، اور مثالیں۔.

بینچ مارکنگ کا طریقہ کار درج ذیل مراحل پر مشتمل ہے:

1. ماڈل ہب سے پہلے سے تربیت یافتہ ماڈل بازیافت کریں۔
2. SageMaker MMEs پر پیش کرنے کے لیے ماڈل آرٹفیکٹ تیار کریں (دیکھیں۔ Amazon SageMaker ملٹی ماڈل اینڈ پوائنٹس کے ساتھ GPU پر متعدد ڈیپ لرننگ ماڈلز چلائیں۔ مزید تفصیلات کے لیے).
3. GPU مثال پر SageMaker MME تعینات کریں۔
4. ماڈلز کی زیادہ سے زیادہ تعداد کا تعین کریں جنہیں GPU میموری میں ایک مخصوص حد کے اندر لوڈ کیا جا سکتا ہے۔
5. لوکسٹ لوڈ ٹیسٹنگ فریم ورک کو ٹریفک کی نقل کرنے کے لیے استعمال کریں جو مثال کے طور پر لوڈ کیے گئے ماڈلز کو تصادفی طور پر طلب کرتا ہے۔
6. ڈیٹا اکٹھا کریں اور نتائج کا تجزیہ کریں۔
7. اختیاری طور پر، TensorRT پر ماڈل مرتب کرنے کے بعد 2-6 مراحل کو دہرائیں۔

مراحل 4 اور 5 گہری نظر کی ضمانت دیتے ہیں۔ SageMaker GPU MME کے اندر ماڈلز کو متحرک انداز میں میموری میں لوڈ کیا جاتا ہے۔ لہذا، مرحلہ 4 میں، ہم ایک ابتدائی ماڈل نمونے کو اپ لوڈ کرتے ہیں۔ ایمیزون سادہ اسٹوریج سروس (ایمیزون S3) اور اسے میموری میں لوڈ کرنے کے لیے ماڈل کو طلب کریں۔ ابتدائی درخواست کے بعد، ہم استعمال شدہ GPU میموری کی مقدار کی پیمائش کرتے ہیں، ابتدائی ماڈل کی ایک کاپی بناتے ہیں، ماڈل کی کاپی کو میموری میں لوڈ کرنے کے لیے طلب کرتے ہیں، اور استعمال شدہ GPU میموری کی کل مقدار کی دوبارہ پیمائش کرتے ہیں۔ یہ عمل اس وقت تک دہرایا جاتا ہے جب تک کہ GPU میموری کے استعمال کی ایک مخصوص حد تک نہ پہنچ جائے۔ بینچ مارک کے لیے، ہم نے بڑے بیچوں پر اندازہ لگانے کے لیے یا کم استعمال ہونے والے دوسرے ماڈلز کو لوڈ کرنے کے لیے کچھ جگہ چھوڑنے کے لیے ایک معقول میموری بفر فراہم کرنے کے لیے حد کو 90% پر سیٹ کیا ہے۔

صارف ٹریفک کی نقل کریں۔

ماڈلز کی تعداد کا تعین کرنے کے بعد، ہم استعمال کرکے لوڈ ٹیسٹ چلا سکتے ہیں۔ ٹڈی لوڈ ٹیسٹنگ فریم ورک. لوڈ ٹیسٹ بے ترتیب ماڈلز کے لیے صارف کی درخواستوں کی تقلید کرتا ہے اور خود بخود میٹرکس کی پیمائش کرتا ہے جیسے ردعمل میں تاخیر اور تھرو پٹ۔

Locust اپنی مرضی کے مطابق لوڈ ٹیسٹ کی شکلوں کی حمایت کرتا ہے جو آپ کو اپنی مرضی کے مطابق ٹریفک پیٹرن کی وضاحت کرنے کی اجازت دیتا ہے. اس بینچ مارک میں استعمال ہونے والی شکل مندرجہ ذیل چارٹ میں دکھائی گئی ہے۔ پہلے 30 سیکنڈ میں، اختتامی نقطہ 10 ہم آہنگ صارفین کے ساتھ گرم ہو جاتا ہے۔ 30 سیکنڈ کے بعد، نئے صارفین کو دو فی سیکنڈ کی شرح سے پیدا کیا جاتا ہے، جو 20 سیکنڈ کے نشان پر 40 ساتھی صارفین تک پہنچ جاتے ہیں۔ اس کے بعد اختتامی نقطہ کو 20 ہم آہنگ صارفین کے ساتھ 60 سیکنڈ کے نشان تک مستقل طور پر بینچ مارک کیا جاتا ہے، اس مقام پر Locust دوبارہ صارفین کو دو فی سیکنڈ کی رفتار سے بڑھانا شروع کر دیتا ہے جب تک کہ 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 repo اب بھی اس بات کا تعین کرنے کے لیے استعمال کیا جا سکتا ہے کہ آیا MMEs پر متضاد ماڈل پیش کرنے سے مطلوبہ کارکردگی اور استحکام حاصل ہو گا۔

سی وی ماڈلز کے بینچ مارک کے نتائج

کمپیوٹر ویژن ماڈلز کے لیے لوڈ ٹیسٹنگ چلانے کے لیے cv-benchmark.ipynb نوٹ بک استعمال کریں۔ آپ پہلے سے تربیت یافتہ ماڈل کے نام اور مثال کی قسم کے پیرامیٹرز کو مختلف ماڈل اور مثال کی قسم کے امتزاج پر کارکردگی لوڈ ٹیسٹنگ میں ایڈجسٹ کر سکتے ہیں۔ ہم نے جان بوجھ کر تین CV ماڈلز کو مختلف سائز کی حدود میں چھوٹے سے بڑے تک آزمایا: resnet50 (25M) convnext_base (88M)، اور vit_large_patch16_224 (304M)۔ اگر آپ اس فہرست سے باہر کوئی ماڈل چنتے ہیں تو آپ کو کوڈ میں ایڈجسٹ کرنے کی ضرورت پڑ سکتی ہے۔ مزید برآں، نوٹ بک ان پٹ امیج کی شکل کو 224x224x3 امیج ٹینسر پر ڈیفالٹ کرتی ہے۔ اگر آپ کو مختلف سائز کی تصویر لینے والے ماڈلز کو بینچ مارک کرنے کی ضرورت ہو تو اس کے مطابق ان پٹ کی شکل کو ایڈجسٹ کرنا یاد رکھیں۔

پوری نوٹ بک کو چلانے کے بعد، آپ کو کارکردگی کے تجزیہ کے کئی تصورات ملیں گے۔ پہلے دو تفصیلی ماڈل کی کارکردگی کے ساتھ ساتھ صارفین کو بڑھانے کے حوالے سے۔ مندرجہ ذیل اعداد و شمار مثال کے طور پر تخلیق کردہ تصورات ہیں۔ ResNet50 ml.g4dn.2xlarge پر چلنے والا ماڈل، PyTorch (بائیں) بمقابلہ TensorRT (دائیں) کا موازنہ کرتا ہے۔ ٹاپ لائن گرافس y-axis پر ماڈل کی تاخیر اور تھرو پٹ کو دکھاتے ہیں جس کے ساتھ ساتھ کلائنٹ کے کارکنوں کی بڑھتی ہوئی تعداد x-axis پر ظاہر ہوتی ہے۔ نیچے بار چارٹس کامیاب اور ناکام درخواستوں کی گنتی دکھاتے ہیں۔

ہم نے جانچے تمام کمپیوٹر وژن ماڈلز کو دیکھتے ہوئے، ہم نے مندرجہ ذیل مشاہدہ کیا:

• تاخیر (ملی سیکنڈ میں) زیادہ ہے، اور بڑے ماڈلز کے لیے تھرو پٹ (درخواستیں فی سیکنڈ) کم ہے (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 ماڈل نے PyTorch سے TensorRT جانے والی GPU میموری سے تقریباً دوگنا استعمال کیا، جس کے نتیجے میں 50% کم ماڈل لوڈ ہوئے (46 بمقابلہ 23)۔ ہم مندرجہ ذیل سیکشن میں اس رویے کی مزید تشخیص کرتے ہیں۔

NLP ماڈلز کے لیے بینچ مارک کے نتائج

NLP ماڈلز کے لیے، لوڈ ٹیسٹ چلانے کے لیے nlp-benchmark.ipynb نوٹ بک استعمال کریں۔ نوٹ بک کا سیٹ اپ بہت ملتا جلتا نظر آنا چاہیے۔ ہم نے دو NLP ماڈلز کا تجربہ کیا: bert-base-uncased (109M) اور roberta-large (335M)۔ پہلے سے تربیت یافتہ ماڈل اور ٹوکنائزر دونوں ہیگنگ فیس ہب سے ڈاؤن لوڈ کیے جاتے ہیں، اور ٹیسٹ پے لوڈ نمونے کی تار کا استعمال کرتے ہوئے ٹوکنائزر سے تیار کیا جاتا ہے۔ زیادہ سے زیادہ ترتیب کی لمبائی 128 پر طے شدہ ہے۔ اگر آپ کو لمبی تاروں کی جانچ کرنے کی ضرورت ہے، تو اس پیرامیٹر کو ایڈجسٹ کرنا یاد رکھیں۔ NLP نوٹ بک کے ذریعے چلنے سے تصورات کا ایک ہی سیٹ تیار ہوتا ہے: Pytorch (بائیں) بمقابلہ TensorRT (دائیں)۔

ان سے، ہم نے NLP ماڈلز کے لیے TensorRT کے اور بھی زیادہ کارکردگی کے فوائد کا مشاہدہ کیا۔ لے جانا roberta-large مثال کے طور پر ایک ml.g4dn.2x بڑی مثال پر، انفرنس لیٹینسی ڈرامائی طور پر 180 ملی سیکنڈ سے کم ہو کر 56 ملی سیکنڈ (70% بہتری) ہو گئی ہے، جبکہ تھرو پٹ 406% فی سیکنڈ سے 33 درخواستوں سے 167 تک بہتر ہوا ہے۔ صارفین میں 50 فیصد اضافہ ہوا ناکام درخواستوں کا مشاہدہ اس وقت تک نہیں کیا گیا جب تک کہ ہم 180 ایک ساتھ استعمال کنندگان تک نہ پہنچ جائیں، جبکہ اصل PyTorch ماڈل کے 120 کے مقابلے۔ میموری کے استعمال کے لحاظ سے، ہم نے TensorRT (نو ماڈل سے آٹھ تک) کے لیے ایک کم ماڈل دیکھا۔ تاہم، منفی اثر اس کے مقابلے میں بہت چھوٹا ہے جو ہم نے CNN پر مبنی ماڈلز کے ساتھ دیکھا۔

میموری کے استعمال پر تجزیہ

مندرجہ ذیل جدول PyTorch سے TensorRT تک میموری کے استعمال کے اثرات پر مکمل تجزیہ دکھاتا ہے۔ ہم نے پہلے ذکر کیا کہ CNN پر مبنی ماڈلز زیادہ منفی طور پر متاثر ہوتے ہیں۔ دی ResNet50 ماڈل میں تینوں GPU مثالوں کی اقسام میں بھری ہوئی ماڈلز کی تعداد میں 50% سے زیادہ کمی تھی۔ 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 مثالیں انفرنس ورک بوجھ کے لیے بہترین قدر کو ظاہر کرتی ہیں۔

صاف کرو

اپنا بوجھ ٹیسٹ مکمل کرنے کے بعد، اضافی چارجز سے بچنے کے لیے پیدا کردہ وسائل کو صاف کریں۔ اہم وسائل ایمیزون S3 میں سیج میکر اینڈ پوائنٹس اور ماڈل آرٹفیکٹ فائلیں ہیں۔ آپ کے لیے آسان بنانے کے لیے، نوٹ بک فائلوں میں درج ذیل کلین اپ کوڈ ہوتا ہے تاکہ آپ انہیں حذف کر سکیں:

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

نتیجہ

اس پوسٹ میں، ہم نے GPU کے ساتھ SageMaker ملٹی ماڈل اینڈ پوائنٹس پر چلنے والے مختلف ڈیپ نیورل نیٹ ورک ماڈلز کے لیے اپنے ٹیسٹ کے نتائج اور تجزیے کا اشتراک کیا۔ ہم نے جو نتائج اور بصیرتیں شیئر کی ہیں انہیں مختلف میٹرکس اور مثال کی اقسام میں کارکردگی کا ایک معقول کراس سیکشن فراہم کرنا چاہیے۔ اس عمل میں، ہم نے GPU کے ساتھ SageMaker MMEs کے لیے بینچ مارک ٹیسٹنگ چلانے کے لیے اپنا تجویز کردہ طریقہ بھی متعارف کرایا۔ ہمارے فراہم کردہ ٹولز اور نمونہ کوڈ آپ کو اپنے بینچ مارک ٹیسٹنگ کو جلدی شروع کرنے اور تیز رفتار کمپیوٹ ہارڈویئر پر سیکڑوں DNN ماڈلز کی لاگت سے مؤثر طریقے سے میزبانی کرنے کے بارے میں مزید باخبر فیصلہ کرنے میں مدد کر سکتے ہیں۔ GPU کے لیے MME سپورٹ کے ساتھ اپنے ماڈلز کی بینچ مارکنگ شروع کرنے کے لیے، رجوع کریں۔ تعاون یافتہ الگورتھم، فریم ورک، اور مثالیں۔ اور GitHub repo اضافی مثالوں اور دستاویزات کے لیے۔

مصنفین کے بارے میں

جیمز وو AWS میں ایک سینئر AI/ML ماہر حل آرکیٹیکٹ ہے۔ AI/ML سلوشنز کو ڈیزائن اور بنانے میں صارفین کی مدد کرنا۔ جیمز کا کام ایم ایل کے استعمال کے کیسز کی ایک وسیع رینج پر محیط ہے، جس میں کمپیوٹر ویژن، گہری سیکھنے، اور پورے انٹرپرائز میں ایم ایل کی پیمائش میں بنیادی دلچسپی ہے۔ AWS میں شامل ہونے سے پہلے، جیمز 10 سال سے زائد عرصے تک ایک معمار، ڈویلپر، اور ٹیکنالوجی لیڈر تھے، جس میں 6 سال انجینئرنگ اور 4 سال مارکیٹنگ اور اشتہاری صنعتوں میں شامل تھے۔

وکرم ایلنگو ورجینیا USA میں مقیم Amazon Web Services میں AI/ML ماہر حل آرکیٹیکٹ ہے۔ وکرم مالیاتی اور انشورنس انڈسٹری کے صارفین کو ڈیزائن، سوچی سمجھی قیادت کے ساتھ مشین لرننگ ایپلی کیشنز کو بڑے پیمانے پر بنانے اور تعینات کرنے میں مدد کرتا ہے۔ وہ فی الحال پورے انٹرپرائز میں قدرتی لینگویج پروسیسنگ، ذمہ دار AI، انفرنس آپٹیمائزیشن اور اسکیلنگ ایم ایل پر مرکوز ہے۔ اپنے فارغ وقت میں، وہ اپنے خاندان کے ساتھ سفر، پیدل سفر، کھانا پکانے اور کیمپنگ سے لطف اندوز ہوتا ہے۔

سائمن زمرین ایک AI/ML سلوشنز آرکیٹیکٹ ہے جس کی بنیادی توجہ صارفین کو ان کے ڈیٹا اثاثوں سے قیمت نکالنے میں مدد کرنا ہے۔ اپنے فارغ وقت میں، سائمن کو فیملی کے ساتھ وقت گزارنے، سائنس فائی پڑھنے، اور مختلف DIY ہاؤس پروجیکٹس پر کام کرنا پسند ہے۔

سوربھ تریکنڈے Amazon SageMaker Inference کے لیے ایک سینئر پروڈکٹ مینیجر ہے۔ وہ صارفین کے ساتھ کام کرنے کا شوق رکھتا ہے اور مشین لرننگ کو جمہوری بنانے کے مقصد سے حوصلہ افزائی کرتا ہے۔ وہ پیچیدہ ایم ایل ایپلی کیشنز، ملٹی ٹیننٹ ایم ایل ماڈلز، لاگت کی اصلاح، اور ڈیپ لرننگ ماڈلز کی تعیناتی کو مزید قابل رسائی بنانے سے متعلق بنیادی چیلنجوں پر توجہ مرکوز کرتا ہے۔ اپنے فارغ وقت میں، سوربھ کو پیدل سفر کرنا، اختراعی ٹیکنالوجیز کے بارے میں سیکھنا، TechCrunch کی پیروی کرنا اور اپنے خاندان کے ساتھ وقت گزارنا پسند ہے۔

• SEO سے چلنے والا مواد اور PR کی تقسیم۔ آج ہی بڑھا دیں۔
• پلیٹو بلاک چین۔ 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/