ایمیزون سیج میکر کے ساتھ فالکن ماڈلز کی کارکردگی کو بہتر بنائیں | ایمیزون ویب سروسز

ٹیکسٹ تیار کرنے والے جنریٹیو AI ایپلی کیشنز کے لیے بڑے لینگویج ماڈلز (LLMs) کی میزبانی کے لیے بہترین فریم ورک اور کنفیگریشن کیا ہے؟ LLMs کی خدمت کے لیے اختیارات کی کثرت کے باوجود، ماڈلز کے سائز، مختلف ماڈلز کے فن تعمیر، ایپلی کیشنز کی کارکردگی کے تقاضے اور مزید بہت کچھ کی وجہ سے اس کا جواب دینا ایک مشکل سوال ہے۔ دی ایمیزون سیج میکر بڑا ماڈل انفرنس (LMI) کنٹینر مختلف فریم ورکس اور تکنیکوں کو اکٹھا کر کے LLMs کی خدمت کرنا آسان بناتا ہے جو LLMs کی تعیناتی کو بہتر بناتے ہیں۔ LMI کنٹینر میں ایک طاقتور سرونگ اسٹیک ہے جسے کہتے ہیں۔ DJL پیش کر رہا ہے۔ جو کہ بنیادی LLM کے لیے agnostic ہے۔ یہ سسٹم لیول کنفیگریشن پیرامیٹرز فراہم کرتا ہے جو کسی دیے گئے LLM کے لیے ہوسٹنگ انفراسٹرکچر کی بہترین کارکردگی کو نکالنے کے لیے بنایا جا سکتا ہے۔ اس میں حالیہ آپٹیمائزیشنز کے لیے بھی سپورٹ ہے جیسے مسلسل بیچنگ، جسے تکراری بیچنگ یا رولنگ بیچنگ بھی کہا جاتا ہے، جو تھرو پٹ میں نمایاں بہتری فراہم کرتا ہے۔

پہلے سے ہی پوسٹ، ہم نے دکھایا کہ آپ کس طرح LMI کنٹینر کو SageMaker پر ماڈلز کے Falcon خاندان کو تعینات کرنے کے لیے استعمال کر سکتے ہیں۔ اس پوسٹ میں، ہم یہ ظاہر کرتے ہیں کہ مسلسل بیچنگ جیسی تکنیکوں کے ساتھ Falcon-40B کی خدمت کے تھروپپٹ اور تاخیر کو کیسے بہتر بنایا جائے۔ ہم SageMaker LMI کنٹینر کے ذریعہ فراہم کردہ کنفیگریشن پیرامیٹرز کی بدیہی تفہیم بھی فراہم کرتے ہیں جو آپ کی حقیقی دنیا کی ایپلی کیشن کے لیے بہترین کنفیگریشن تلاش کرنے میں آپ کی مدد کر سکتی ہے۔

LLMs کے لیے ٹیکسٹ جنریٹیو انفرنس کے بنیادی اصول

آئیے سب سے پہلے چند بنیادی باتوں کو دیکھتے ہیں کہ ٹیکسٹ جنریشن کے لیے LLMs کے لیے کیسے اندازہ لگایا جائے۔

فارورڈ پاس، ایکٹیویشنز، اور KV کیشے

ٹوکنز کی ایک ان پٹ ترتیب کو دیکھتے ہوئے، وہ a میں چلائے جاتے ہیں۔ forward pass اگلا ٹوکن بنانے کے لیے LLM کی تمام پرتوں میں (جیسے Falcon)۔ اے forward pass آؤٹ پٹ پیدا کرنے کے لیے اعصابی نیٹ ورک کے ذریعے ان پٹ ڈیٹا کو منتقل کرنے کے عمل سے مراد ہے۔ ٹیکسٹ جنریشن کے معاملے میں، فارورڈ پاس میں زبان کے ماڈل میں ابتدائی بیج یا سیاق و سباق کو کھانا کھلانا اور ترتیب میں اگلا کریکٹر یا ٹوکن بنانا شامل ہے۔ متن کی ترتیب پیدا کرنے کے لیے، یہ عمل اکثر تکراری طور پر کیا جاتا ہے، یعنی اسے آؤٹ پٹ ترتیب میں ہر قدم یا پوزیشن کے لیے دہرایا جاتا ہے۔ ہر تکرار پر، ماڈل اگلا کریکٹر یا ٹوکن تیار کرتا ہے، جو تیار کردہ ٹیکسٹ کا حصہ بن جاتا ہے، اور یہ عمل اس وقت تک جاری رہتا ہے جب تک کہ متن کی مطلوبہ لمبائی پیدا نہ ہو جائے۔

فالکن یا جی پی ٹی جیسے زبان کے ماڈل کے ساتھ ٹیکسٹ جنریشن ہے۔ autoregressive. اس کا مطلب یہ ہے کہ ماڈل ایک وقت میں ایک ٹوکن تیار کرتا ہے جبکہ پہلے سے تیار کردہ ٹوکن پر کنڈیشنگ کرتا ہے۔ دوسرے الفاظ میں، ہر تکرار پر، ماڈل پہلے سے تیار کردہ متن کو بطور ان پٹ لیتا ہے اور اس سیاق و سباق کی بنیاد پر اگلے ٹوکن کی پیش گوئی کرتا ہے۔ جیسا کہ میں مذکور ہے۔ vLLM: آسان، تیز، اور سستا LLM پیجڈ توجہ کے ساتھ پیش کرنااس خود کار طریقے سے ضابطہ کشائی کے عمل میں، LLM کے تمام ان پٹ ٹوکن اپنی توجہ کی کلید اور ویلیو ٹینسر تیار کرتے ہیں، اور یہ ٹینسر اگلے ٹوکنز بنانے کے لیے GPU میموری میں رکھے جاتے ہیں۔ ان کیشڈ کلید اور ویلیو ٹینسرز کو اکثر کہا جاتا ہے۔ KV cache.

پری فل اور ڈی کوڈ مراحل

خود بخود ضابطہ کشائی کے عمل میں، جیسا کہ فالکن جیسے زبان کے ماڈلز کے ساتھ ٹیکسٹ جنریشن میں استعمال کیا جاتا ہے، عام طور پر دو اہم مراحل ہوتے ہیں: prefill مرحلہ اور decode مرحلہ یہ مراحل مربوط اور سیاق و سباق سے متعلقہ متن بنانے کے لیے اہم ہیں۔

پری فل مرحلے میں درج ذیل شامل ہیں:

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

پری فل کا مرحلہ اس وقت تک جاری رہتا ہے جب تک کہ رکنے کی ایک پہلے سے طے شدہ شرط پوری نہ ہو جائے۔ یہ حالت پیدا شدہ متن کے لیے زیادہ سے زیادہ لمبائی، ایک مخصوص ٹوکن جو متن کے اختتام کا اشارہ دیتا ہے، یا صارف یا ایپلیکیشن کے ذریعہ مقرر کردہ کوئی اور معیار ہو سکتا ہے۔

ڈی کوڈ مرحلے میں درج ذیل شامل ہیں:

• تکمیل - پہلے سے بھرنے کے مرحلے کے بعد، آپ کے پاس جزوی طور پر تیار کردہ متن ہے جو کسی وقت نامکمل یا کاٹ سکتا ہے۔ ڈی کوڈ مرحلہ متن کو مکمل کرنے کے لیے ذمہ دار ہے تاکہ اسے مربوط اور گرائمری طور پر درست بنایا جا سکے۔
• آخری ٹوکن سے تسلسل - ڈی کوڈ مرحلے میں، ماڈل پری فل مرحلے کے دوران تیار کردہ آخری ٹوکن سے شروع ہوتا ہے۔ یہ اس ٹوکن کو ابتدائی سیاق و سباق کے طور پر استعمال کرتا ہے اور متن کو جاری رکھنے کے لیے اگلا ٹوکن تیار کرتا ہے۔
• تکراری تکمیل - پہلے سے بھرنے کے مرحلے کی طرح، ٹوکن بنانے کا عمل ایک بار پھر تکراری ہے۔ ماڈل ایک وقت میں ایک ٹوکن تیار کرتا ہے، ترتیب میں پچھلے ٹوکنز پر کنڈیشنگ کرتا ہے۔
• رکنے کی حالت - ڈی کوڈ فیز میں رکنے کی حالت بھی ہوتی ہے، جو پہلے سے بھرنے کے مرحلے کی طرح ہوسکتی ہے، جیسے کہ زیادہ سے زیادہ لمبائی تک پہنچنا یا ٹیکسٹ کے اختتامی ٹوکن کا سامنا کرنا۔ جب یہ شرط پوری ہوجاتی ہے تو نسل کا عمل رک جاتا ہے۔

پری فل اور ڈی کوڈ مراحل کا امتزاج خود بخود ماڈلز کو متن تیار کرنے کی اجازت دیتا ہے جو ایک ابتدائی سیاق و سباق پر بنتا ہے اور متن کے مربوط، سیاق و سباق کے لحاظ سے متعلقہ، اور سیاق و سباق کے مطابق تسلسل پیدا کرتا ہے۔

کا حوالہ دیتے ہیں ٹرانسفارمر پر مبنی جنریٹو ماڈلز کے لیے تقسیم شدہ سرونگ سسٹم عمل کی تفصیلی وضاحت کے لیے۔

متحرک بیچنگ کا استعمال کرتے ہوئے تھرو پٹ کو بہتر بنانا

اب تک، ہم نے صرف ایک ان پٹ کے بارے میں بات کی ہے۔ عملی طور پر، ہم توقع کرتے ہیں کہ ایپلیکیشن کلائنٹس کی جانب سے تصادفی طور پر آنے والی متعدد درخواستوں کو بیک وقت یا حیران کن انداز میں نمٹایا جائے گا۔ روایتی طریقے سے، بنیادی بیچنگ کو تھرو پٹ بڑھانے اور GPU کے کمپیوٹنگ وسائل کے استعمال کے لیے استعمال کیا جا سکتا ہے۔ بیچنگ مؤثر طریقے سے ایک بیچ میں ایک سے زیادہ درخواستوں کی عددی نمائندگی کو یکجا کرنا اور خود بخود آگے بڑھنے والے پاسوں کے متوازی رنز کو انجام دینا ہے۔ یہ ذہین بیچنگ سرونگ سائیڈ پر کی جاتی ہے۔ SageMaker LMI کے DJLServing سرور کو مندرجہ ذیل پیرامیٹرز کو ترتیب دے کر متوازی طور پر کارروائی کرنے کے لیے متعدد درخواستوں کو اکٹھا کرنے کے لیے ترتیب دیا جا سکتا ہے۔ serving.properties:

• max_batch_delay = 100 - ملی سیکنڈ میں بیچ جمع کرنے کے لیے زیادہ سے زیادہ تاخیر۔ پہلے سے طے شدہ قدر 100 ملی سیکنڈز ہے۔
• بیچ_سائز = 32 - متحرک بیچ کا سائز۔ پہلے سے طے شدہ 1 ہے۔

یہ بنیادی طور پر ظاہر کرتا ہے کہ DJLServing ایک وقت میں 100 ملی سیکنڈز کے لیے درخواستوں کی قطار لگائے گی یا اگر قطار میں لگی ہوئی درخواستوں کی تعداد مخصوص کردہ batch_size تک ہے، تو بیچ کو تخمینہ کے لیے بیک اینڈ پر چلانے کے لیے شیڈول کیا جائے گا۔ یہ کے طور پر جانا جاتا ہے dynamic batching. یہ متحرک ہے کیونکہ بیچ کا سائز تمام بیچوں میں تبدیل ہو سکتا ہے اس بات پر منحصر ہے کہ اس مدت میں کتنی درخواستیں شامل کی گئی تھیں۔ تاہم، کیونکہ درخواستوں میں مختلف خصوصیات ہو سکتی ہیں، (مثال کے طور پر، کچھ درخواستیں 20 ٹوکن آف ان پٹ اور 500 ٹوکن آؤٹ پٹ کی ہو سکتی ہیں، جب کہ دیگر کو الٹ دیا جا سکتا ہے، ان پٹ کے 500 ٹوکن لیکن آؤٹ پٹ کے لیے صرف 20)، کچھ درخواستیں ہو سکتی ہیں۔ ایک ہی بیچ میں دوسروں کے مقابلے میں تیزی سے پروسیسنگ مکمل کریں۔ اس کے نتیجے میں جی پی یو کو کم استعمال میں لایا جا سکتا ہے جب کہ بیچ میں تمام ان فلائٹ درخواستوں کا انتظار کرتے ہوئے اس کا ڈی کوڈ مرحلہ مکمل ہو جائے، یہاں تک کہ اگر قطار میں کارروائی کے لیے اضافی درخواستیں موجود ہوں۔ مندرجہ ذیل خاکہ اس عمل کی وضاحت کرتا ہے۔

مسلسل بیچنگ کا استعمال کرتے ہوئے تھرو پٹ کو بہتر بنانا

ساتھ continuous batching، اس نام سے بہی جانا جاتاہے iterative or rolling بیچنگ، ہم پری فل اور ڈی کوڈ مراحل کے درمیان فرق سے فائدہ اٹھاتے ہیں۔ مسلسل بیچنگ کو چالو کرنے کے لیے، DJServing serving.properties کے مطابق درج ذیل اضافی کنفیگریشنز فراہم کرتا ہے:

• انجن=MPI - ہم آپ کو مسلسل بیچنگ کے لیے MPI انجن استعمال کرنے کی ترغیب دیتے ہیں۔
• option.rolling_batch=auto یا lmi-dist - ہم آٹو استعمال کرنے کی تجویز کرتے ہیں کیونکہ یہ مستقبل میں دیگر اصلاحوں کے ساتھ خود بخود موزوں ترین رولنگ بیچ الگورتھم کا انتخاب کرے گا۔
• option.max_rolling_batch_size=32 - یہ ہم آہنگی کی درخواستوں کی تعداد کو محدود کرتا ہے۔ پہلے سے طے شدہ 32 ہے۔

مسلسل بیچنگ کے ساتھ، سرونگ اسٹیک (DJLServing) اپنے ڈی کوڈ مرحلے کو مکمل کرنے کے لیے بیچ میں تمام ان فلائٹ درخواستوں کا انتظار نہیں کرتا ہے۔ بلکہ، منطقی وقفوں پر (ڈی کوڈ مرحلے میں ایک تکرار کے اختتام پر)، یہ اضافی درخواستوں کو کھینچتا ہے جو قطار میں انتظار کر رہی ہیں جب کہ موجودہ بیچ ابھی بھی پروسیسنگ کر رہا ہے (لہذا نام رولنگ بیچ)۔ یہ ڈی کوڈ مرحلے کے ہر تکرار کے اختتام پر زیر التواء درخواستوں کی جانچ پڑتال کرتا ہے۔ یاد رکھیں، ہر درخواست کے لیے، ہمیں پری فل اسٹیج کو چلانے کی ضرورت ہے جس کے بعد ترتیب وار ڈی کوڈ اسٹیج ہوگا۔ چونکہ ہم درخواست کے ابتدائی پرامپٹ سے اس کے پہلے سے بھرنے کے مرحلے کے متوازی طور پر تمام ٹوکنز پر کارروائی کر سکتے ہیں، اس لیے جب بھی کوئی نئی درخواست داخل کی جاتی ہے، تو ہم بیچ کی ان فلائٹ درخواستوں کے ڈی کوڈ مرحلے کو عارضی طور پر روک دیتے ہیں۔ اور میموری میں ایکٹیویشنز اور نئی درخواستوں کے پری فل اسٹیج کو چلائیں۔

اس کیش کے سائز کو درج ذیل آپشن کے ساتھ کنفیگر کیا جا سکتا ہے۔

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

آپ نے پہلے ہی محسوس کیا ہوگا کہ لگاتار بیچنگ تقریباً اسی طرح کا طریقہ ہے جس کے ساتھ ہم فطری طور پر اپنی روزمرہ کی زندگی میں کاموں کو متوازی بناتے ہیں۔ ہمارے پاس پیغامات، ای میلز، فون کی اطلاعات (ممکنہ طور پر نئی درخواستیں) بے ترتیب وقت پر آتی ہیں (جی پی یوز کے لیے بے ترتیب حیرت زدہ انداز میں آنے والی متعدد درخواستوں کے مشابہ)۔ یہ سب کچھ اس وقت ہو رہا ہے جب ہم اپنے اندرونِ پرواز کاموں کو مکمل کرتے ہیں — ای میلز لکھنا، کوڈنگ کرنا، میٹنگز میں حصہ لینا (جی پی یو میں موجودہ پروسیسنگ کے کاموں کے مشابہ)۔ منطقی وقفوں پر، ہم اپنے اندرونِ پرواز کاموں کو روکتے ہیں اور اپنی اطلاعات کی جانچ پڑتال کرتے ہیں تاکہ یہ فیصلہ کیا جا سکے کہ آیا ہماری طرف سے کچھ کارروائی کی ضرورت ہے، اور اگر ہے تو، ہم اسے اپنے اندرونِ پرواز کاموں (حقیقی زندگی میں رولنگ بیچ) میں شامل کرتے ہیں، یا اسے کرنے کی فہرست (قطار) میں ڈالیں۔

یہ سب ایک ساتھ رکھنا: GPUs کے میموری استعمال کے بارے میں کیسے سوچا جائے۔

یہ دیکھنے کے لیے اپنے ماڈل کو لوڈ کرنے کی سفارش کی جاتی ہے کہ آپ کے کاروباری استعمال کے معاملے کے لیے کون سی کنفیگریشن سب سے زیادہ سستی ہے۔ تفہیم پیدا کرنے کے لیے، آئیے GPUs کے میموری فوٹ پرنٹ کو دیکھتے ہیں جیسا کہ ماڈل لوڈ ہوتا ہے اور جیسا کہ ایک رولنگ بیچ میں لگاتار درخواستوں پر کارروائی ہوتی ہے۔ اس پوسٹ کے لیے، فرض کریں کہ ہم Falcon-40B ماڈل کو G5 مثال کی قسموں میں سے ایک پر لوڈ کر رہے ہیں جو NVIDIA A10G GPUs کے ساتھ انسٹال ہے، ہر ایک 24 GB میموری کے ساتھ۔ نوٹ کریں کہ اسی طرح کی تفہیم p3، p4، اور p5 مثال کی اقسام کے لیے لاگو ہوتی ہے، جو V100، A100، اور H100 GPU سیریز کے ساتھ آتی ہیں۔

Falcon-40B کی خدمت کے لیے درکار کل میموری کی تخمینی قیمت حاصل کرنے کا جائزہ درج ذیل ہے۔

• ماڈل سائز = ماڈل پیرامیٹرز کی تعداد (Falcon-40B کے لیے 40 بلین) x 4 بائٹس فی پیرامیٹر (FP32 کے لیے) = 160 GB
• تخمینہ کے لیے Falcon-40B لوڈ کرنے کے لیے درکار کل میموری = ماڈل سائز (=160 جی بی) + کے وی کیشے (توجہ کیش) (=*20 جی بی) + ایم ایل فریم ورکس کے ذریعہ اضافی میموری اوور ہیڈ (تقریباً 2 جی بی)

Falcon-40B کے لیے، اگر ہم ماڈل کو bfloat16 (2 بائٹس) ڈیٹا کی قسم میں کوانٹائز کر کے ماڈل کو کمپریس کرتے ہیں، تو ماڈل کا سائز تقریباً 80 GB ہو جاتا ہے۔ جیسا کہ آپ دیکھ سکتے ہیں، یہ اب بھی ایک ایکسلریٹر ڈیوائس کے ذریعے سپورٹ کردہ میموری سے بڑا ہے، اس لیے ہمیں ایک خصوصی کے ساتھ ماڈل پارٹیشننگ (شارڈنگ) تکنیک اپنانے کی ضرورت ہے۔ ٹینسر متوازی (TP) ایک سے زیادہ ایکسلریٹر ڈیوائسز پر ماڈل کو اپروچ اور شارڈ کریں۔ آئیے فرض کریں کہ ہم نے g5.24xlarge کا انتخاب کیا ہے، جس میں 4 A10G GPU ڈیوائسز ہیں۔ اگر ہم DJLServing (serving.properties) کو مندرجہ ذیل کے ساتھ تشکیل دیتے ہیں، تو ہم توقع کر سکتے ہیں کہ ماڈل کے وزن کے 80 GB کو تمام 4 GPUs میں یکساں طور پر تقسیم کیا جائے گا:

ساتھ tensor_parallel_degree 4 پر سیٹ کیا گیا، 20 GB GPU میموری میں سے تقریباً 24 GB (تقریباً 84%) پہلے سے ہی استعمال ہو چکی ہے یہاں تک کہ ایک درخواست پر کارروائی ہونے سے پہلے ہی۔ GPU کا بقیہ 16% آنے والی درخواستوں کے لیے KV کیشے کے لیے استعمال کیا جائے گا۔ یہ ممکن ہے کہ آپ کے کاروباری منظر نامے اور اس کی تاخیر اور تھرو پٹ کی ضروریات کے لیے، بقیہ میموری کا 2–3 GB کافی سے زیادہ ہو۔ اگر نہیں۔ ایکٹیویشنز اور KV کیشے کے لیے باقی GPU کا تقریباً 5.48% ہے۔ بدیہی طور پر، ہم دیکھ سکتے ہیں کہ یہ کنفیگریشن ہمیں زیادہ تھرو پٹ حاصل کرنے کی اجازت دے سکتی ہے۔ مزید برآں، کیونکہ اب ہمارے پاس ایک بڑا بفر ہے، ہم اس میں اضافہ کر سکتے ہیں۔ max_rolling_batch_prefill_tokens اور max_rolling_batch_size تھرو پٹ کو مزید بہتر بنانے کے لیے پیرامیٹرز۔ ایک ساتھ، یہ دونوں پیرامیٹرز ماڈل کے لیے ایکٹیویشن پری فلز اور KV کیشے کے پہلے سے مختص کو کنٹرول کریں گے۔ ان دو پیرامیٹرز کے لیے ایک بڑی تعداد کا تعلق ایک بڑے تھرو پٹ سے ہو گا، یہ فرض کرتے ہوئے کہ آپ کے پاس GPU میموری میں KV کیشے کے لیے کافی بفر ہے۔

PagedAttention کے ساتھ مسلسل بیچنگ

PagedAttention UC Berkeley کی طرف سے تیار کردہ ایک نیا آپٹیمائزیشن الگورتھم ہے جو فکسڈ سائز کے صفحات یا بلاکس میں میموری کو مختص کر کے توجہ کیش (KV کیشے) کو غیر متصل رہنے کی اجازت دے کر مسلسل بیچنگ کے عمل کو بہتر بناتا ہے۔ یہ آپریٹنگ سسٹم کے ذریعے استعمال ہونے والے ورچوئل میموری اور پیجنگ کے تصورات سے متاثر ہے۔

اس کے مطابق vLLM کاغذ، ٹوکنز کے ہر تسلسل کے توجہ کیش کو بلاکس میں تقسیم کیا جاتا ہے اور بلاک ٹیبل کے ذریعے فزیکل بلاکس میں میپ کیا جاتا ہے۔ توجہ کی گنتی کے دوران، ایک PagedAttention کرنل بلاک ٹیبل کو استعمال کر سکتا ہے تاکہ مؤثر طریقے سے بلاکس کو جسمانی میموری سے حاصل کیا جا سکے۔ اس کے نتیجے میں میموری کے فضلے میں نمایاں کمی واقع ہوتی ہے اور یہ بڑے بیچ سائز، GPU کے استعمال میں اضافہ، اور زیادہ تھرو پٹ کی اجازت دیتا ہے۔

کارکردگی کا موازنہ

آپ کی تعیناتی کی ترتیب کی مؤثر لوڈ ٹیسٹنگ کو یقینی بنانے کے لیے، یہ تجویز کیا جاتا ہے کہ کاروباری منظر نامے پر غور کرکے اور LLM پر مبنی ایپلیکیشن کے لیے ان پٹ اور آؤٹ پٹ کی خصوصیات کو واضح طور پر بیان کرکے شروع کریں۔ مثال کے طور پر، اگر آپ کال سینٹر کے خلاصہ استعمال کے کیس پر کام کر رہے ہیں، تو ان پٹ بڑے متن پر مشتمل ہو سکتا ہے، جیسے کہ کسٹمر سروس ایجنٹ اور کسٹمر کے درمیان 500 ٹوکن چیٹ ٹرانسکرپٹ، لیکن آؤٹ پٹ نسبتاً چھوٹا ہو سکتا ہے، تقریباً 100۔ ٹوکنز، نقل کے خلاصے کی نمائندگی کرتے ہیں۔ دوسری طرف، اگر آپ کوڈ جنریشن کے منظر نامے پر کام کر رہے ہیں، تو ان پٹ 15 ٹوکنز تک مختصر ہو سکتا ہے، جیسے کہ "پیگنیشن سمیت تمام EC2 وسائل کو بیان کرنے کے لیے Python میں ایک موثر نفاذ لکھیں،" لیکن آؤٹ پٹ بہت زیادہ ہو سکتا ہے۔ بڑا، 500 ٹوکن تک پہنچ رہا ہے۔ اس بات پر غور کرنا بھی ضروری ہے کہ آیا آپ کے مخصوص منظر نامے کے لیے کم تاخیر یا زیادہ سے زیادہ تھرو پٹ کو حاصل کرنا اولین ترجیح ہے۔

کاروباری منظر نامے کی جامع تفہیم حاصل کرنے کے بعد، آپ اپنے ہوسٹنگ ماحول کے لیے بہترین ترتیب کا تجزیہ اور تعین کر سکتے ہیں۔ اس تناظر میں، ہوسٹنگ ماحول مختلف کلیدی عناصر کو گھیرے ہوئے ہے، بشمول مثال کی قسم اور ترتیب کے دیگر پیرامیٹرز جیسے tensor_parallel_degree, max_rolling_batch_size, max_rolling_batch_prefill_tokens، اور مزید. ہمارا مقصد ہمارے رسپانس ٹائم، تھرو پٹ، اور ماڈل آؤٹ پٹ کوالٹی کی ضروریات کو سپورٹ کرنے کے لیے سب سے موثر سیٹ اپ کی نشاندہی کرنا ہے۔

اپنے تجزیے میں، ہم نے روایتی متحرک بیچنگ پر مسلسل بیچنگ کے فوائد کو واضح کرنے کے لیے کارکردگی کو بینچ مارک کیا۔ ہم نے SageMaker پر LMI کنٹینر کا استعمال کرتے ہوئے متحرک بیچنگ اور تکراری بیچنگ کے لیے serving.properties میں درج ذیل جدول میں تفصیلی کنفیگریشنز کا استعمال کیا۔

متحرک بیچنگ	مسلسل بیچنگ	PagedAttention کے ساتھ مسلسل بیچنگ
انجن = ازگر option.model_id=tiiuae/falcon-40b option.tensor_parallel_degree=8 option.dtype=fp16 بیچ_سائز = 4 max_batch_delay=100 option.trust_remote_code = سچ	انجن = MPI option.model_id = {{s3_url}} option.trust_remote_code = سچ option.tensor_parallel_degree = 8 option.max_rolling_batch_size = 32 option.rolling_batch = آٹو option.dtype = fp16 option.max_rolling_batch_prefill_tokens = 1024 option.paged_attention = غلط	انجن = MPI option.model_id = {{s3_url}} option.trust_remote_code = سچ option.tensor_parallel_degree = 8 option.max_rolling_batch_size = 32 option.rolling_batch = آٹو option.dtype = fp16 option.max_rolling_batch_prefill_tokens = 1024 option.paged_attention = سچ

Falcon-40B کے لیے دو کنفیگریشنز کو FP16 ڈیٹا کی قسم کے ساتھ ml.g5.48xlarge پر متعین کیا گیا مختلف منظرناموں میں جو حقیقی دنیا کی ایپلی کیشنز کی نمائندگی کرتے ہیں:

• ان پٹ ٹوکنز کی ایک چھوٹی تعداد جس میں بڑی تعداد میں ٹوکن بنائے جا رہے ہیں۔ - اس منظر نامے میں، ان پٹ ٹوکنز کی تعداد 32 مقرر کی گئی تھی اور 128 نئے ٹوکن بنائے گئے تھے۔

بیچنگ کی حکمت عملی	تھرو پٹ (ٹوکن/سیکنڈ)	تاخیر p90 (سیکنڈ)
متحرک بیچنگ	5.53	58.34
مسلسل بیچنگ	56.04	4.74
PagedAttention کے ساتھ مسلسل بیچنگ	59.18	4.76

• ایک بڑا ان پٹ جس میں تھوڑے سے ٹوکن بنائے جا رہے ہیں۔ - یہاں، ہم ان پٹ ٹوکنز کی تعداد 256 پر طے کرتے ہیں اور LLM کو 32 ٹوکنز میں ان پٹ کا خلاصہ کرنے کا اشارہ کرتے ہیں۔

بیچنگ کی حکمت عملی	تھرو پٹ (ٹوکن/سیکنڈ)	تاخیر p90 (سیکنڈ)
متحرک بیچنگ	19.96	59.31
مسلسل بیچنگ	46.69	3.88
PagedAttention کے ساتھ مسلسل بیچنگ	44.75	2.67

ہم دیکھ سکتے ہیں کہ PagedAttention کے ساتھ مسلسل بیچنگ LMI کنٹینر کا استعمال کرتے ہوئے SageMaker پر متحرک بیچنگ استعمال کرنے کے مقابلے میں منظرنامہ 10 میں 1 گنا اور منظر نامہ 2.3 میں 2 گنا زیادہ تھرو پٹ بہتری فراہم کرتی ہے۔

نتیجہ

اس پوسٹ میں، ہم نے دیکھا کہ کس طرح LLMs میموری کا استعمال کرتے ہیں اور بتایا کہ کس طرح مسلسل بیچنگ SageMaker پر LMI کنٹینر کا استعمال کرتے ہوئے تھرو پٹ کو بہتر بناتی ہے۔ ہم نے بینچ مارک کے نتائج دکھا کر SageMaker پر LMI کنٹینر کا استعمال کرتے ہوئے Falcon-40B کے لیے مسلسل بیچنگ کے فوائد کا مظاہرہ کیا۔ آپ کوڈ پر تلاش کرسکتے ہیں۔ GitHub repo.

---

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

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

دھول پٹیل AWS میں پرنسپل مشین لرننگ آرکیٹیکٹ ہے۔ انہوں نے تقسیم شدہ کمپیوٹنگ اور مصنوعی ذہانت سے متعلق مسائل پر بڑے اداروں سے لے کر درمیانے درجے کے اسٹارٹ اپس تک کی تنظیموں کے ساتھ کام کیا ہے۔ وہ NLP اور کمپیوٹر ویژن ڈومینز سمیت گہری سیکھنے پر توجہ مرکوز کرتا ہے۔ وہ صارفین کو SageMaker پر اعلیٰ کارکردگی کے ماڈل کا اندازہ حاصل کرنے میں مدد کرتا ہے۔

پنک پانیگرہی۔ AWS پر اسٹریٹجک کاروباری مسائل کو حل کرنے کے لیے مشین لرننگ پر مبنی حل تیار کرنے کے لیے صارفین کے ساتھ کام کرتا ہے۔ جب وہ مشین لرننگ میں مشغول نہ ہو، تو اسے پیدل سفر کرتے ہوئے، کتاب پڑھتے ہوئے یا کھیل دیکھتے ہوئے پایا جاسکتا ہے۔

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

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

• SEO سے چلنے والا مواد اور PR کی تقسیم۔ آج ہی بڑھا دیں۔
• پلیٹو ڈیٹا ڈاٹ نیٹ ورک ورٹیکل جنریٹو اے آئی۔ اپنے آپ کو بااختیار بنائیں۔ یہاں تک رسائی حاصل کریں۔
• پلیٹوآئ اسٹریم۔ ویب 3 انٹیلی جنس۔ علم میں اضافہ۔ یہاں تک رسائی حاصل کریں۔
• پلیٹو ای ایس جی۔ کاربن، کلین ٹیک، توانائی ، ماحولیات، شمسی، ویسٹ مینجمنٹ یہاں تک رسائی حاصل کریں۔
• پلیٹو ہیلتھ۔ بائیوٹیک اینڈ کلینیکل ٹرائلز انٹیلی جنس۔ یہاں تک رسائی حاصل کریں۔
• ماخذ: https://aws.amazon.com/blogs/machine-learning/improve-performance-of-falcon-models-with-amazon-sagemaker/