تحسين أداء نماذج Falcon باستخدام Amazon SageMaker | خدمات ويب أمازون

ما هو الإطار والتكوين الأمثل لاستضافة نماذج اللغات الكبيرة (LLMs) لتطبيقات الذكاء الاصطناعي المولدة للنص؟ على الرغم من وفرة الخيارات لخدمة ماجستير إدارة الأعمال، إلا أن هذا سؤال يصعب الإجابة عليه نظرًا لحجم النماذج وبنيات النماذج المختلفة ومتطلبات أداء التطبيقات والمزيد. ال الأمازون SageMaker حاوية استدلال النموذج الكبير (LMI). يجعل من السهل خدمة LLMs من خلال الجمع بين مجموعة من الأطر والتقنيات المختلفة التي تعمل على تحسين نشر LLMs. تحتوي حاوية LMI على مكدس خدمة قوي يسمى خدمة دي جي إل هذا لا أدري إلى LLM الأساسي. فهو يوفر معلمات التكوين على مستوى النظام التي يمكن ضبطها لاستخراج أفضل أداء للبنية التحتية للاستضافة لبرنامج LLM معين. كما أنه يدعم التحسينات الحديثة مثل الدفع المستمر، المعروف أيضًا باسم الدفع التكراري أو الدفع المتجدد، والذي يوفر تحسينات كبيرة في الإنتاجية.

في وقت سابق بريد.. اعلاني، لقد أظهرنا كيف يمكنك استخدام حاوية LMI لنشر مجموعة نماذج Falcon على SageMaker. في هذا المنشور، نوضح كيفية تحسين الإنتاجية وزمن الوصول لخدمة Falcon-40B باستخدام تقنيات مثل التجميع المستمر. كما نقدم أيضًا فهمًا بديهيًا لمعلمات التكوين التي توفرها حاوية SageMaker LMI والتي يمكن أن تساعدك في العثور على أفضل تكوين لتطبيقك في العالم الحقيقي.

أساسيات الاستدلال توليد النص للماجستير في القانون

دعونا نلقي نظرة أولاً على بعض الأساسيات حول كيفية إجراء الاستدلال لـ LLMs لإنشاء النص.

التمريرة الأمامية وعمليات التنشيط وذاكرة التخزين المؤقت KV

نظرًا لتسلسل إدخال الرموز المميزة، يتم تشغيلها في ملف forward pass عبر جميع طبقات LLM (مثل Falcon) لإنشاء الرمز المميز التالي. أ forward pass يشير إلى عملية إدخال بيانات يتم تمريرها عبر شبكة عصبية لإنتاج مخرجات. في حالة إنشاء النص، يتضمن التمرير الأمامي تغذية بذرة أولية أو سياق أولي في نموذج اللغة وإنشاء الحرف أو الرمز المميز التالي في التسلسل. لإنشاء تسلسل نصي، غالبًا ما تتم العملية بشكل متكرر، مما يعني تكرارها لكل خطوة أو موضع في تسلسل الإخراج. في كل تكرار، يقوم النموذج بإنشاء الحرف أو الرمز المميز التالي، والذي يصبح جزءًا من النص الذي تم إنشاؤه، وتستمر هذه العملية حتى يتم إنشاء الطول المطلوب للنص.

يتم إنشاء النصوص باستخدام نماذج اللغة مثل Falcon أو GPT autoregressive. وهذا يعني أن النموذج يُنشئ رمزًا مميزًا واحدًا في كل مرة أثناء تكييف الرموز المميزة التي تم إنشاؤها مسبقًا. بمعنى آخر، في كل تكرار، يأخذ النموذج النص الذي تم إنشاؤه مسبقًا كمدخل ويتنبأ بالرمز المميز التالي بناءً على هذا السياق. كما ذكر في vLLM: عرض LLM سهل وسريع ورخيص مع PagedAttention، في عملية فك التشفير الانحداري التلقائي هذه، تنتج جميع الرموز المميزة المدخلة إلى LLM مفتاح الانتباه وموترات القيمة الخاصة بها، ويتم الاحتفاظ بهذه الموترات في ذاكرة وحدة معالجة الرسومات لإنشاء الرموز المميزة التالية. غالبًا ما يشار إلى موترات القيمة والمفتاح المخزنة مؤقتًا باسم KV cache.

مراحل التعبئة المسبقة وفك التشفير

في عملية فك التشفير الانحداري الذاتي، مثل تلك المستخدمة في إنشاء النص باستخدام نماذج اللغة مثل Falcon، هناك عادةً مرحلتان رئيسيتان: prefill المرحلة و decode مرحلة. تعتبر هذه المراحل حاسمة لإنتاج نص متماسك وذو صلة بالسياق.

تتضمن مرحلة التعبئة المسبقة ما يلي:

• السياق الأولي - تبدأ مرحلة التعبئة المسبقة بسياق أولي أو نص أولي يقدمه المستخدم. يمكن أن يكون هذا السياق الأولي جملة أو عبارة أو حتى مجرد كلمة واحدة. فهو يحدد نقطة البداية لإنشاء النص ويوفر السياق لما سيأتي بعد ذلك.
• تكييف النموذج – يتم استخدام السياق المقدم لتكييف نموذج اللغة. يأخذ النموذج هذا السياق كمدخل ويقوم بإنشاء الرمز المميز التالي (الكلمة أو الحرف) في التسلسل بناءً على فهمه للسياق.
• توليد الرمز المميز - يُنشئ النموذج رمزًا مميزًا واحدًا في كل مرة، ويتنبأ بما يجب أن يأتي بعد ذلك في النص. يتم إلحاق هذا الرمز بالسياق، مما يؤدي إلى توسيعه بشكل فعال.
• عملية تكرارية - يتم تكرار عملية إنشاء الرموز بشكل متكرر. في كل خطوة، يقوم النموذج بإنشاء رمز مميز مع الأخذ في الاعتبار السياق المحدث، والذي يتضمن الآن الرموز المميزة التي تم إنشاؤها في الخطوات السابقة.

تستمر مرحلة التعبئة المسبقة حتى يتم استيفاء شرط التوقف المحدد مسبقًا. يمكن أن يكون هذا الشرط الحد الأقصى لطول النص الذي تم إنشاؤه، أو رمزًا محددًا يشير إلى نهاية النص، أو أي معايير أخرى يحددها المستخدم أو التطبيق.

تتضمن مرحلة فك التشفير ما يلي:

• إتمام – بعد مرحلة التعبئة المسبقة، يكون لديك نص تم إنشاؤه جزئيًا وقد يكون غير مكتمل أو مقطوعًا في مرحلة ما. مرحلة فك التشفير هي المسؤولة عن إكمال النص لجعله متماسكًا وصحيحًا نحويًا.
• استمرار من الرمز الأخير - في مرحلة فك التشفير، يبدأ النموذج من آخر رمز مميز تم إنشاؤه خلال مرحلة التعبئة المسبقة. ويستخدم هذا الرمز المميز كسياق أولي ويقوم بإنشاء الرمز المميز التالي لمتابعة النص.
• الإكمال التكراري – كما هو الحال في مرحلة التعبئة المسبقة، فإن عملية إنشاء الرموز المميزة تكون متكررة مرة أخرى. يقوم النموذج بإنشاء رمز مميز واحد في كل مرة، مع تكييف الرموز المميزة السابقة في التسلسل.
• حالة التوقف - تحتوي مرحلة فك التشفير أيضًا على شرط التوقف، والذي قد يكون هو نفسه كما هو الحال في مرحلة التعبئة المسبقة، مثل الوصول إلى الحد الأقصى للطول أو مواجهة رمز مميز لنهاية النص. عند استيفاء هذا الشرط، تتوقف عملية الإنشاء.

يتيح الجمع بين مرحلتي التعبئة المسبقة وفك التشفير لنماذج الانحدار التلقائي إنشاء نص يعتمد على سياق أولي وينتج تسلسلات نصية متماسكة وذات صلة بالسياق ومتسقة سياقيًا.

الرجوع إلى نظام الخدمة الموزعة للنماذج التوليدية القائمة على المحولات للحصول على شرح مفصل للعملية.

تحسين الإنتاجية باستخدام الخلط الديناميكي

حتى الآن، تحدثنا فقط عن إدخال واحد. من الناحية العملية، نتوقع التعامل مع الطلبات المتعددة الواردة بشكل عشوائي من عملاء التطبيق للاستدلال بشكل متزامن أو بطريقة متقطعة. بالطريقة التقليدية، يمكن استخدام التجميعات الأساسية لزيادة الإنتاجية والاستفادة من موارد الحوسبة الخاصة بوحدة معالجة الرسومات. التجميع هو الجمع بشكل فعال بين التمثيلات الرقمية لأكثر من طلب واحد في دفعة واحدة وتنفيذ عمليات تشغيل متوازية لتمريرات الانحدار التلقائي الأمامية. ويتم هذا الخلط الذكي في جانب التقديم. يمكن تكوين خادم DJLServing الخاص بـ SageMaker LMI لتجميع طلبات متعددة معًا لمعالجتها بالتوازي عن طريق تعيين المعلمات التالية في خدمة:

• max_batch_delay = 100 - الحد الأقصى لتأخير تجميع الدفعة بالمللي ثانية. القيمة الافتراضية هي 100 مللي ثانية.
• حجم الدفعة = 32 – حجم الدفعة الديناميكية. الافتراضي هو 1.

يوضح هذا بشكل أساسي أن DJLServing سيقوم بوضع الطلبات في قائمة الانتظار لمدة 100 مللي ثانية في المرة الواحدة أو إذا كان عدد الطلبات التي تم وضعها في قائمة الانتظار يصل إلى حجم الدُفعة المحدد، فستتم جدولة الدفعة للتشغيل إلى الواجهة الخلفية للاستدلال. ويعرف هذا باسم dynamic batching. إنه ديناميكي لأن حجم الدُفعة قد يتغير عبر الدُفعات اعتمادًا على عدد الطلبات التي تمت إضافتها في تلك المدة الزمنية. ومع ذلك، نظرًا لأن الطلبات قد يكون لها خصائص مختلفة، (على سبيل المثال، قد تكون بعض الطلبات على شكل 20 رمزًا مميزًا للإدخال و500 رمزًا مميزًا للمخرجات، بينما قد يتم عكس البعض الآخر، مع 500 رمزًا مميزًا للإدخال و20 رمزًا مميزًا للمخرجات فقط)، قد تكون بعض الطلبات إكمال المعالجة بشكل أسرع من الآخرين في نفس الدفعة. قد يؤدي هذا إلى قلة استخدام وحدة معالجة الرسومات أثناء انتظار جميع الطلبات أثناء الرحلة في الدفعة لإكمال مرحلة فك التشفير الخاصة بها، حتى لو كانت هناك طلبات إضافية في انتظار معالجتها في قائمة الانتظار. ويوضح الرسم البياني التالي هذه العملية.

تحسين الإنتاجية باستخدام الخلط المستمر

بدافع continuous batching، المعروف أيضا باسم iterative or rolling الخلط، نحن نستفيد من الاختلافات بين مراحل التعبئة المسبقة وفك التشفير. لتنشيط الدفع المستمر، يوفر DJServing التكوينات الإضافية التالية وفقًا لخصائص الخدمة:

• محرك=MPI – نحن نشجعك على استخدام محرك MPI للتجميع المستمر.
• option.rolling_batch=auto أو lmi-dist - نوصي باستخدام auto لأنه سيختار تلقائيًا خوارزمية الدفعة المتدرجة الأكثر ملاءمة بالإضافة إلى التحسينات الأخرى في المستقبل.
• option.max_rolling_batch_size=32 – هذا يحد من عدد الطلبات المتزامنة. الافتراضي هو 32.

مع الدفع المستمر، لا تنتظر حزمة الخدمة (DJLServing) جميع الطلبات على متن الطائرة في دفعة واحدة لإكمال مرحلة فك التشفير الخاصة بها. بدلاً من ذلك، عند الفواصل المنطقية (في نهاية تكرار واحد في مرحلة فك التشفير)، فإنه يسحب طلبات إضافية تنتظر في قائمة الانتظار بينما لا تزال الدفعة الحالية قيد المعالجة (ومن هنا جاء الاسم دفعة المتداول). يقوم بهذا التحقق من الطلبات المعلقة في نهاية كل تكرار لمرحلة فك التشفير. تذكر أنه لكل طلب، نحتاج إلى تشغيل مرحلة التعبئة المسبقة تليها مرحلة فك التشفير التسلسلي. نظرًا لأنه يمكننا معالجة جميع الرموز المميزة من الموجه الأولي للطلب بالتوازي مع مرحلة التعبئة المسبقة الخاصة به، في أي وقت يتم فيه سحب طلب جديد، فإننا نقوم مؤقتًا بإيقاف مرحلة فك التشفير للطلبات أثناء الرحلة للدُفعة - ونحفظ مؤقتًا ذاكرة التخزين المؤقت KV الخاصة بها والتنشيط في الذاكرة وتشغيل مرحلة التعبئة المسبقة للطلبات الجديدة.

يمكن تكوين حجم ذاكرة التخزين المؤقت هذه باستخدام الخيار التالي:

عند اكتمال التعبئة المسبقة، نقوم بدمج الطلبات الجديدة والطلبات القديمة المتوقفة مؤقتًا في دفعة متجددة جديدة، والتي يمكن أن تستمر في مرحلة فك التشفير الخاصة بها بالتوازي. لاحظ أن الطلبات القديمة المتوقفة مؤقتًا يمكن أن تستمر في مرحلة فك التشفير الخاصة بها من حيث توقفت وستبدأ الطلبات الجديدة من أول رمز مميز جديد لها.

ربما تكون قد أدركت بالفعل أن التجميع المستمر هو أسلوب مشابه تقريبًا نقوم من خلاله بشكل طبيعي بموازاة المهام في حياتنا اليومية. لدينا رسائل ورسائل بريد إلكتروني وإشعارات هاتفية (طلبات جديدة محتملة) تأتي في أوقات عشوائية (مماثلة للطلبات المتعددة الواردة بطريقة عشوائية متقطعة لوحدات معالجة الرسومات). يحدث كل هذا أثناء قيامنا بإكمال مهامنا على متن الطائرة، مثل إنشاء رسائل البريد الإلكتروني والبرمجة والمشاركة في الاجتماعات (على غرار مهام المعالجة الحالية في وحدات معالجة الرسومات). في فترات الراحة المنطقية، نوقف مهامنا على متن الطائرة مؤقتًا ونتحقق من إشعاراتنا لتحديد ما إذا كان هناك بعض الإجراءات المطلوبة من جانبنا، وإذا كان هناك بعض الإجراءات المطلوبة، فإننا نضيفها إلى مهامنا على متن الطائرة (دفعة متجددة حقيقية)، أو وضعه في قائمة المهام (قائمة الانتظار).

تجميع كل ذلك معًا: كيفية التفكير في استخدام ذاكرة وحدات معالجة الرسومات

يوصى بتحميل اختبار النموذج الخاص بك لمعرفة التكوين الأكثر فعالية من حيث التكلفة لحالة استخدام عملك. لبناء فهم، دعونا نتصور أثر الذاكرة لوحدات معالجة الرسومات أثناء تحميل النموذج ومع معالجة الطلبات المتعاقبة في دفعة متجددة. في هذا المنشور، لنفترض أننا نقوم بتحميل نموذج Falcon-40B على أحد مثيلات أنواع مثيلات G5 المثبتة مع وحدات معالجة الرسومات NVIDIA A10G، ولكل منها ذاكرة 24 جيجابايت. لاحظ أن فهمًا مشابهًا ينطبق على أنواع المثيلات p3، وp4، وp5، والتي تأتي مع سلسلة وحدات معالجة الرسومات V100، وA100، وH100.

فيما يلي نظرة عامة حول الحصول على قيمة تقريبية لإجمالي الذاكرة المطلوبة لخدمة Falcon-40B:

• حجم النموذج = عدد معلمات النموذج (40 مليار لـ Falcon-40B) × 4 بايت لكل معلمة (لـ FP32) = 160 جيجابايت
• إجمالي الذاكرة التقريبية المطلوبة لتحميل Falcon-40B للاستدلال = حجم النموذج (=160 جيجابايت) + ذاكرة التخزين المؤقت KV (ذاكرة التخزين المؤقت للانتباه) (=*20 جيجابايت) + سعة الذاكرة الإضافية بواسطة ML Frameworks (حوالي 2 جيجابايت)

بالنسبة لـ Falcon-40B، إذا قمنا بضغط النموذج عن طريق تكميم النموذج إلى نوع البيانات bfloat16 (2 بايت)، يصبح حجم النموذج حوالي 80 جيجابايت. كما ترون، لا يزال هذا أكبر من الذاكرة التي يدعمها جهاز تسريع واحد، لذلك نحن بحاجة إلى اعتماد تقنية التقسيم النموذجي (التقسيم) مع خاص التوازي الموتر (TP) نهج النموذج وتقسيمه عبر أجهزة تسريع متعددة. لنفترض أننا اخترنا g5.24xlarge، الذي يحتوي على 4 أجهزة GPU A10G. إذا قمنا بتكوين DJLServing (serving.properties) بما يلي، فيمكننا أن نتوقع أن يتم تقسيم أوزان النموذج البالغة 80 جيجابايت بالتساوي عبر جميع وحدات معالجة الرسومات الأربعة:

بدافع tensor_parallel_degree عند ضبطه على 4، يتم بالفعل استخدام حوالي 20 جيجابايت من ذاكرة وحدة معالجة الرسومات (GPU) التي تبلغ سعتها 24 جيجابايت (حوالي 84%) حتى قبل معالجة طلب واحد. سيتم استخدام نسبة 16% المتبقية من وحدة معالجة الرسومات لذاكرة التخزين المؤقت KV للطلبات الواردة. من الممكن أن يكون 2-3 جيجابايت من الذاكرة المتبقية أكثر من كافية بالنسبة لسيناريو عملك ومتطلبات زمن الاستجابة والإنتاجية. إذا لم يكن الأمر كذلك، فيمكنك زيادة حجم المثيل إلى g5.48xlarge، الذي يحتوي على 8 وحدات معالجة رسوميات ويستخدم Tensor_parallel_degree مضبوطًا على 8. في مثل هذه الحالة، يتم استخدام ما يقرب من 10 جيجابايت فقط من الذاكرة المتوفرة البالغة 24 جيجابايت لكل وحدة معالجة رسومات لأوزان النماذج ونحن لديك حوالي 60٪ من وحدة معالجة الرسومات المتبقية لعمليات التنشيط وذاكرة التخزين المؤقت KV. بشكل بديهي، يمكننا أن نرى أن هذا التكوين قد يسمح لنا بالحصول على إنتاجية أعلى. بالإضافة إلى ذلك، نظرًا لأن لدينا مخزنًا مؤقتًا أكبر الآن، يمكننا زيادة max_rolling_batch_prefill_tokens و max_rolling_batch_size المعلمات لزيادة تحسين الإنتاجية. ستتحكم هاتان المعلمتان معًا في التخصيصات المسبقة لعمليات التعبئة المسبقة للتنشيط وذاكرة التخزين المؤقت KV للنموذج. سيرتبط عدد أكبر من هاتين المعلمتين بإنتاجية أكبر، على افتراض أن لديك مخزنًا مؤقتًا كافيًا لذاكرة التخزين المؤقت KV في ذاكرة وحدة معالجة الرسومات.

التجميع المستمر مع PagedAttention

PagedAttention عبارة عن خوارزمية تحسين جديدة تم تطويرها بواسطة جامعة كاليفورنيا في بيركلي تعمل على تحسين عملية التجميع المستمرة من خلال السماح لذاكرة التخزين المؤقت للانتباه (ذاكرة التخزين المؤقت KV) بأن تكون غير متجاورة من خلال تخصيص الذاكرة في صفحات أو كتل ذات حجم ثابت. وهذا مستوحى من الذاكرة الافتراضية ومفاهيم الترحيل التي تستخدمها أنظمة التشغيل.

وفقا ل vLLM ورقيًا، يتم تقسيم ذاكرة التخزين المؤقت للانتباه لكل تسلسل من الرموز المميزة إلى كتل وتعيينها إلى كتل فعلية من خلال جدول الكتل. أثناء حساب الاهتمام، يمكن لنواة PagedAttention استخدام جدول الكتل لجلب الكتل بكفاءة من الذاكرة الفعلية. يؤدي هذا إلى تقليل كبير في هدر الذاكرة ويسمح بحجم أكبر للدفعة، وزيادة استخدام وحدة معالجة الرسومات، وإنتاجية أعلى.

مقارنة الأداء

لضمان اختبار الحمل الفعال لتكوين النشر الخاص بك، يوصى بالبدء بالنظر في سيناريو العمل وتحديد خصائص المدخلات والمخرجات للتطبيق المستند إلى LLM بوضوح. على سبيل المثال، إذا كنت تعمل على حالة استخدام تلخيص مركز الاتصال، فقد يتكون الإدخال من نص أكبر، مثل نص محادثة مكون من 500 رمز مميز بين وكيل خدمة العملاء والعميل، ولكن قد يكون الإخراج أصغر نسبيًا، حوالي 100 الرموز التي تمثل ملخصًا للنص. من ناحية أخرى، إذا كنت تعمل على سيناريو إنشاء التعليمات البرمجية، فقد يكون الإدخال قصيرًا حتى 15 رمزًا مميزًا، مثل "اكتب تنفيذًا فعالاً في Python لوصف جميع موارد EC2، بما في ذلك ترقيم الصفحات"، ولكن يمكن أن يكون الإخراج كثيرًا أكبر، حيث تصل إلى 500 رمز. من المهم أيضًا مراعاة ما إذا كان تحقيق زمن استجابة أقل أو زيادة الإنتاجية هو الأولوية القصوى للسيناريو المحدد لديك.

بعد الحصول على فهم شامل لسيناريو العمل، يمكنك تحليل وتحديد التكوين الأمثل لبيئة الاستضافة الخاصة بك. في هذا السياق، تشتمل بيئة الاستضافة على عناصر أساسية مختلفة، بما في ذلك نوع المثيل ومعلمات التكوين الأخرى مثل Tensor_parallel_degree, max_rolling_batch_size, max_rolling_batch_prefill_tokens، و اكثر. هدفنا هو تحديد الإعداد الأكثر فعالية لدعم وقت الاستجابة والإنتاجية ومتطلبات جودة مخرجات النموذج.

في تحليلنا، قمنا بقياس الأداء لتوضيح فوائد الخلط المستمر على الخلط الديناميكي التقليدي. استخدمنا التكوينات المفصلة في الجدول التالي في خصائص العرض للتجميع الديناميكي والتجميع التكراري، باستخدام حاوية LMI في SageMaker.

الخلط الديناميكي	الخلط المستمر	التجميع المستمر مع PagedAttention
المحرك = بايثون option.model_id=tiiuae/falcon-40b option.tensor_parallel_degree=8 option.dtype=fp16 Batch_size=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 يوفر تحسينًا في الإنتاجية بمقدار 10 مرات أكبر في السيناريو 1 و2.3 مرة في السيناريو 2 مقارنة باستخدام الدفع الديناميكي على SageMaker أثناء استخدام حاوية LMI.

وفي الختام

في هذا المنشور، نظرنا في كيفية استخدام طلاب LLM للذاكرة وشرحنا كيف يعمل التجميع المستمر على تحسين الإنتاجية باستخدام حاوية LMI على SageMaker. لقد أظهرنا فوائد التجميع المستمر لـ Falcon-40B باستخدام حاوية LMI على SageMaker من خلال عرض نتائج قياس الأداء. يمكنك العثور على الكود على جيثب ريبو.

---

حول المؤلف

أبهي شيفاديتيا هو مهندس حلول أقدم في AWS ، حيث يعمل مع مؤسسات مؤسسية عالمية إستراتيجية لتسهيل اعتماد خدمات AWS في مجالات مثل الذكاء الاصطناعي والحوسبة الموزعة والشبكات والتخزين. تكمن خبرته في التعلم العميق في مجالات معالجة اللغة الطبيعية (NLP) ورؤية الكمبيوتر. يساعد Abhi العملاء في نشر نماذج التعلم الآلي عالية الأداء بكفاءة داخل نظام AWS البيئي.

ضوال باتل هو مهندس رئيسي لتعلم الآلة في AWS. لقد عمل مع مؤسسات تتراوح من المؤسسات الكبيرة إلى الشركات الناشئة متوسطة الحجم في المشكلات المتعلقة بالحوسبة الموزعة والذكاء الاصطناعي. يركز على التعلم العميق بما في ذلك مجالات البرمجة اللغوية العصبية ورؤية الكمبيوتر. إنه يساعد العملاء على تحقيق استدلال نموذج عالي الأداء على SageMaker.

بيناك بانيغراهي يعمل مع العملاء لبناء حلول تعتمد على التعلم الآلي لحل مشكلات العمل الإستراتيجية على AWS. عندما لا يكون منشغلًا بالتعلم الآلي، يمكن العثور عليه وهو يقوم بنزهة أو يقرأ كتابًا أو يشاهد الألعاب الرياضية.

أبهي السذاني يشغل منصب كبير مهندسي حلول الذكاء الاصطناعي/تعلم الآلة في AWS، حيث يتخصص في تقديم الخبرة الفنية والتوجيه بشأن حلول الذكاء الاصطناعي وتعلم الآلة للعملاء. ينصب تركيزه الأساسي على مساعدة الشركات الرقمية الأصلية في تحقيق الإمكانات الكاملة لتقنيات الذكاء الاصطناعي والتعلم الآلي، وتمكينها من تحقيق أهداف أعمالها بفعالية. إلى جانب مساعيه المهنية، يُظهر أبهي شغفًا قويًا بالمساعي الفكرية مثل القراءة، فضلاً عن الانخراط في الأنشطة التي تعزز الصحة البدنية والعقلية، مثل اليوغا والتأمل.

تشينغ لان هو مهندس تطوير برمجيات في AWS. لقد كان يعمل على العديد من المنتجات الصعبة في Amazon ، بما في ذلك حلول استدلال ML عالية الأداء ونظام تسجيل عالي الأداء. أطلق فريق Qing بنجاح أول نموذج مليار معلمة في إعلانات أمازون بزمن انتقال منخفض للغاية مطلوب. تتمتع Qing بمعرفة متعمقة حول تحسين البنية التحتية وتسريع التعلم العميق.

• محتوى مدعوم من تحسين محركات البحث وتوزيع العلاقات العامة. تضخيم اليوم.
• PlatoData.Network Vertical Generative Ai. تمكين نفسك. الوصول هنا.
• أفلاطونايستريم. ذكاء Web3. تضخيم المعرفة. الوصول هنا.
• أفلاطون كربون، كلينتك ، الطاقة، بيئة، شمسي، إدارة المخلفات. الوصول هنا.
• أفلاطون هيلث. التكنولوجيا الحيوية وذكاء التجارب السريرية. الوصول هنا.
• المصدر https://aws.amazon.com/blogs/machine-learning/improve-performance-of-falcon-models-with-amazon-sagemaker/