انشر نماذج كبيرة على Amazon SageMaker باستخدام الاستدلال المتوازي لنموذج DJLServing و DeepSpeed

شهدت السنوات القليلة الماضية تطورًا سريعًا في مجال معالجة اللغة الطبيعية (NLP). على الرغم من تحسن الأجهزة ، كما هو الحال مع أحدث جيل من المسرعات من NVIDIA و Amazon ، لا يزال ممارسو التعلم الآلي المتقدم (ML) يواجهون مشكلات بانتظام في نشر نماذج اللغة الكبيرة الخاصة بهم. اليوم ، نعلن عن إمكانات جديدة في الأمازون SageMaker يمكن أن يساعدك: يمكنك تكوين الحد الأقصى لحجم وحدة تخزين Amazon EBS وحصص المهلة لتسهيل استنتاج النماذج الكبيرة. بالاقتران مع تقنيات الاستدلال المتوازي للنموذج ، يمكنك الآن استخدام إمكانات إدارة ونشر النموذج المُدار بالكامل لـ SageMaker عند العمل مع نماذج كبيرة بمليارات من المعلمات.

في هذا المنشور ، نوضح إمكانات SageMaker الجديدة هذه من خلال نشر نموذج NLP كبير ومدرب مسبقًا من Hugging Face عبر وحدات معالجة رسومات متعددة. على وجه الخصوص ، نستخدم تقنيات خدمة مكتبة جافا العميقة (DJL) والتوازي الموتر من DeepSpeed ​​لتحقيق زمن انتقال أقل من 0.1 ثانية في حالة استخدام إنشاء نص مع 6 مليارات معلمة GPT-J. أكمل المثال على مستودع GitHub قريبًا.

نماذج اللغة الكبيرة والضرورة المتزايدة للاستدلال الموازي للنموذج

لقد انفجرت نماذج اللغة مؤخرًا من حيث الحجم والشعبية. في عام 2018 ، بيرت كبير دخلت المشهد وبفضل معلماته البالغ عددها 340 مليونًا وبنية المحولات الجديدة ، حدد معيار دقة مهام البرمجة اللغوية العصبية. في غضون بضع سنوات فقط ، نما حجم نموذج البرمجة اللغوية العصبية الحديث بأكثر من 500 مرة ، مع نماذج مثل OpenAI's 175 مليار معلمة GPT-3 ومصدر مفتوح مماثل الحجم Bloom 176 B يرفع مستوى دقة البرمجة اللغوية العصبية . هذه الزيادة في عدد المعلمات مدفوعة بالعلاقة الإيجابية البسيطة والمثبتة تجريبياً بين حجم النموذج والدقة: المزيد هو الأفضل. مع سهولة الوصول من حدائق الحيوان النموذجية مثل Hugging Face وتحسين الدقة في مهام البرمجة اللغوية العصبية مثل التصنيف وإنشاء النص ، يتزايد وصول الممارسين إلى هذه النماذج الكبيرة. ومع ذلك ، فإن نشرها يمكن أن يمثل تحديًا.

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

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

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

في هذا المنشور ، نستخدم DeepSpeed ​​لتقسيم النموذج باستخدام تقنيات التوازي الموتر. يدعم DeepSpeed ​​Inference النماذج الكبيرة القائمة على المحولات مع مليارات من المعلمات. يسمح لك بخدمة النماذج الكبيرة بكفاءة من خلال التكيف مع أفضل استراتيجيات التوازي للاستدلال متعدد وحدات معالجة الرسومات ، مع مراعاة كل من زمن انتقال الاستدلال والتكلفة. لمزيد من المعلومات ، يرجى الرجوع إلى DeepSpeed: تسريع استدلال النموذج واسع النطاق والتدريب عبر تحسينات النظام والضغط وهذا استدلال DeepSpeed: تمكين الاستدلال الفعال لنماذج المحولات على نطاق غير مسبوق.

حل نظرة عامة

مكتبة جافا العميقة (DJL) عبارة عن إطار عمل جافا مفتوح المصدر وعالي المستوى وغير محدد بالمحرك للتعلم العميق. تم تصميم DJL باستخدام مفاهيم Java الأصلية فوق أطر التعلم العميق الحالية. تم تصميم DJL ليكون محرك التعلم العميق. يمكنك تبديل المحركات في أي وقت. يوفر DJL أيضًا خيارًا تلقائيًا لوحدة المعالجة المركزية / وحدة معالجة الرسومات بناءً على تكوين الأجهزة.

على الرغم من أن DJL مصمم في الأصل لمطوري Java لبدء استخدام ML ، فإن DJLServing هو نموذج عالمي عالي الأداء يقدم حلًا مدعومًا من DJL وهو لغة برمجة حيادية. يمكن أن يخدم أنواع النماذج الشائعة ، مثل نموذج PyTorch TorchScript ، وحزمة TensorFlow SavedModel ، ونموذج Apache MXNet ، ونموذج ONNX ، ونموذج TensorRT ، ونموذج نص Python. يدعم DJLServing التجميع الديناميكي والتحجيم التلقائي للعمال لزيادة الإنتاجية. يمكنك تحميل إصدارات مختلفة من النموذج على نقطة نهاية واحدة. يمكنك أيضًا تقديم نماذج من أطر ML مختلفة في نفس الوقت. علاوة على ذلك ، يدعم DJLServing أصلاً تعدد GPU من خلال إعداد تكوينات MPI وتوصيلات المقابس للاستدلال. هذا يحرر الرفع الثقيل لإعداد بيئة متعددة GPU.

يستخدم حلنا المقترح إمكانات SageMaker المعلنة حديثًا ، DJLServing و DeepSpeed ​​Inference ، لاستدلال نموذج كبير. حتى كتابة هذه السطور ، كل شيء محوليتم دعم النماذج المستندة. هذا الحل مخصص للاستدلال المتوازي باستخدام نموذج واحد على مثيل واحد.

تم بناء DJLServing مع طبقات متعددة. تم بناء طبقة التوجيه فوق Netty. تتم معالجة الطلبات البعيدة في طبقة التوجيه لتوزيعها على العاملين ، إما سلاسل في Java أو العمليات في Python ، لتشغيل الاستدلال. تم تعيين إجمالي عدد سلاسل عمليات Java على 2 * cpu_core من الجهاز للاستفادة الكاملة من طاقة الحوسبة. يمكن تكوين أرقام العمال لكل طراز أو الاكتشاف التلقائي لـ DJL على الأجهزة. يوضح الرسم البياني التالي هندستنا.

استنتاج النماذج الكبيرة على SageMaker

توضح الخطوات التالية كيفية نشر نموذج gpt-j-6B في SageMaker باستخدام خدمة DJL. أصبح هذا ممكنًا من خلال القدرة على تكوين حجم وحدة تخزين EBS ، ووقت انتهاء مهلة تنزيل النموذج ، ووقت انتهاء مهلة فحص صحة بدء التشغيل. يمكنك تجربة هذا العرض التوضيحي عن طريق تشغيل الكمبيوتر الدفتري التالي.

اسحب صورة Docker وادفعها إلى Amazon ECR

صورة Docker djl-serving:0.18.0-deepspeed هي حاوية تقديم DJL الخاصة بنا مع DeepSpeed ​​المدمجة. ثم ندفع هذه الصورة إلى سجل الأمازون المرنة للحاويات (Amazon ECR) للاستخدام لاحقًا. انظر الكود التالي:

docker pull deepjavalibrary/djl-serving:0.18.0-deepspeed

قم بإنشاء ملف النموذج الخاص بنا

أولاً ، نقوم بإنشاء ملف يسمى serving.properties يحتوي على سطر واحد فقط من التعليمات البرمجية. هذا يخبر خادم نموذج DJL لاستخدام Rubikon المحرك. Rubikon عبارة عن حزمة دعم نموذج كبير طورتها AWS. في هذا العرض التوضيحي ، يسهل إعداد خيوط MPI وتوصيل المقبس. يقوم أيضًا بتعيين عدد وحدات معالجة الرسومات (رقم تشريح الطراز) من خلال قراءة ملف TENSOR_PARALLEL_DEGREE المعلمة المحددة في model.py ملف في الفقرة التالية. يحتوي الملف على الكود التالي:

engine=Rubikon

بعد ذلك ، نقوم بإنشاء ملف model.py ملف ، والذي يعرّف نموذجنا على أنه gpt-j-6B. في الكود الخاص بنا ، نقرأ في TENSOR_PARALLEL_DEGREE متغير البيئة (القيمة الافتراضية هي 1). هذا يحدد عدد الأجهزة التي يتم توزيع الوحدات المتوازية عليها. يرجى ملاحظة أن DeepSpeed ​​يوفر بعض منطق الأقسام المضمنة ، و gpt-j-6B هو واحد منهم. نستخدمها بالتحديد replace_method و relpace_with_kernel_inject. إذا كان لديك نموذجك المخصص وتحتاج إلى DeepSpeed ​​للتقسيم بشكل فعال ، فأنت بحاجة إلى التغيير relpace_with_kernel_inject إلى خطأ وإضافة injection_policy لجعل قسم وقت التشغيل يعمل. لمزيد من المعلومات ، يرجى الرجوع إلى التهيئة للاستدلال.

from djl_python import Input, Output
import os
import deepspeed
import torch
from transformers import pipeline, AutoModelForCausalLM, AutoTokenizer

predictor = None

def get_model():
    model_name = 'EleutherAI/gpt-j-6B'
    tensor_parallel = int(os.getenv('TENSOR_PARALLEL_DEGREE', '1'))
    local_rank = int(os.getenv('LOCAL_RANK', '0'))
    model = AutoModelForCausalLM.from_pretrained(model_name, revision="float32", torch_dtype=torch.float32)
    tokenizer = AutoTokenizer.from_pretrained(model_name)
    
    model = deepspeed.init_inference(model,
                                     mp_size=tensor_parallel,
                                     dtype=model.dtype,
                                     replace_method='auto',
                                     replace_with_kernel_inject=True)
    generator = pipeline(task='text-generation', model=model, tokenizer=tokenizer, device=local_rank)
    return generator


def handle(inputs: Input) -> None:
    global predictor
    if not predictor:
        predictor = get_model()

    if inputs.is_empty():
        # Model server makes an empty call to warmup the model on startup
        return None

    data = inputs.get_as_string()
    result = predictor(data, do_sample=True, min_tokens=200, max_new_tokens=256)
    return Output().add(result)

نقوم بإنشاء دليل يسمى gpt-j ونسخ model.py و serving.properties إلى هذا الدليل:

mkdir gpt-j
cp model.py gpt-j
cp serving.properties gpt-j

أخيرًا ، نقوم بإنشاء ملف النموذج وتحميله إلى خدمة تخزين أمازون البسيطة (أمازون إس 3):

tar cvfz gpt-j.tar.gz gpt-j
aws s3 cp gpt-j.tar.gz s3://djl-sm-test/deepspeed/

قم بإنشاء نموذج SageMaker

نقوم الآن بإنشاء ملف نموذج SageMaker. نستخدم صورة ECR التي أنشأناها سابقًا ونموذج الأداة من الخطوة السابقة لإنشاء نموذج SageMaker. في إعداد النموذج ، نقوم بتكوين TENSOR_PARALLEL_DEGREE=2، مما يعني أن النموذج سيتم تقسيمه على طول وحدتي GPU. انظر الكود التالي:

aws sagemaker create-model 
--model-name gpt-j 
--primary-container 
Image=<account_id>.dkr.ecr.us-east-1.amazonaws.com/djl-deepspeed:latest,ModelDataUrl=s3://djl-sm-test/deepspeed/gpt-j.tar.gz,Environment={TENSOR_PARALLEL_DEGREE=2} 
--execution-role-arn <IAM_role_arn>

بعد تشغيل الأمر السابق ، سترى إخراجًا مشابهًا لما يلي:

{
    "ModelArn": "arn:aws:sagemaker:us-east-1:<account_id>:model/gpt-j"
}

قم بإنشاء نقطة نهاية SageMaker

يمكنك استخدام أي حالات مع وحدات معالجة رسومات متعددة للاختبار. في هذا العرض التوضيحي ، نستخدم مثيل p3.16xlarge. في الكود التالي ، لاحظ كيف قمنا بتعيين ملف ModelDataDownloadTimeoutInSeconds, ContainerStartupHealthCheckTimeoutInSecondsو VolumeSizeInGB معلمات لاستيعاب حجم النموذج الكبير. ال VolumeSizeInGB المعلمة قابلة للتطبيق على مثيلات GPU التي تدعم مرفق وحدة تخزين EBS.

aws sagemaker create-endpoint-config 
    --region us-east-1 
    --endpoint-config-name gpt-j-config 
    --production-variants '[
      {
        "ModelName": "gpt-j",
        "VariantName": "AllTraffic",
        "InstanceType": "ml.p3.16xlarge",
        "InitialInstanceCount": 1,
        "VolumeSizeInGB": 256,
        "ModelDataDownloadTimeoutInSeconds": 1800,
        "ContainerStartupHealthCheckTimeoutInSeconds": 3600
        }
    ]'

أخيرًا ، قمنا بإنشاء نقطة نهاية SageMaker:

aws sagemaker create-endpoint 
--endpoint-name gpt-j 
--endpoint-config-name gpt-j-config

تراها مطبوعة في الكود التالي:

{
    "EndpointArn": "arn:aws:sagemaker:us-east-1:<aws-account-id>:endpoint/gpt-j"
}

قد يستغرق بدء نقطة النهاية بعض الوقت. يمكنك المحاولة عدة مرات إذا واجهت InsufficientInstanceCapacity خطأ.

ضبط الأداء

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

الاستدلال في الوقت الحقيقي من SageMaker مثالي للاستدلال على أعباء العمل حيث يكون لديك متطلبات في الوقت الفعلي وتفاعلية وزمن انتقال منخفض. هناك أربعة مقاييس شائعة الاستخدام لمراقبة وقت استجابة طلب الاستدلال لنقاط نهاية استدلال SageMaker:

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

يعتمد زمن انتقال الحاوية على عدة عوامل ؛ فيما يلي أهمها:

• البروتوكول الأساسي (HTTP (s) / gRPC) المستخدم للتواصل مع خادم الاستدلال
• النفقات العامة المتعلقة بإنشاء اتصالات TLS جديدة
• وقت إلغاء تسلسل حمولة الطلب / الاستجابة
• طلب ميزات قائمة الانتظار والتجميع التي يوفرها خادم الاستدلال الأساسي
• طلب قدرات الجدولة التي يوفرها خادم الاستدلال الأساسي
• أداء وقت التشغيل الأساسي لخادم الاستدلال
• أداء مكتبات ما قبل المعالجة والمعالجة اللاحقة قبل استدعاء وظيفة التنبؤ النموذجية
• أساس أداء الواجهة الخلفية لإطار تعلم الآلة
• التحسينات الخاصة بالطراز والأجهزة الخاصة

في هذا القسم ، نركز بشكل أساسي على زمن انتقال الحاوية وعلى وجه التحديد على تحسين تشغيل DJLServing داخل حاوية SageMaker.

اضبط محرك ML للاستدلال متعدد الخيوط

تتمثل إحدى مزايا DJL في دعم الاستدلال متعدد الخيوط. يمكن أن يساعد في زيادة إنتاجية الاستدلال على وحدات المعالجة المركزية ووحدات معالجة الرسومات متعددة النواة وتقليل استهلاك الذاكرة مقارنة ببيثون. تشير إلى تحسين أداء الاستدلال لمزيد من المعلومات حول تحسين عدد الخيوط لمحركات مختلفة.

لحن نيتي

تم بناء DJLServing مع طبقات متعددة. تم بناء طبقة التوجيه فوق Netty. Netty هو إطار عمل خادم عميل NIO الذي يتيح التطوير السريع والسهل لتطبيقات الشبكة مثل خوادم البروتوكول والعملاء. في نيتي ، Channel هي الحاوية الرئيسية يحتوي على ChannelPipeline ويرتبط بامتداد EventLoop (حاوية للخيط) من ملف EventLoopGroup. EventLoop هو في الأساس موضوع إدخال / إخراج ويمكن مشاركته بواسطة قنوات متعددة. ChannelHandlers تعمل على هذه EventLoop الخيوط. يعني نموذج الترابط البسيط هذا أنه لا داعي للقلق بشأن مشكلات التزامن أثناء تشغيل ملف ChannelHandlers. نضمن لك دائمًا عمليات تشغيل متسلسلة على نفس مؤشر الترابط لمرة واحدة عبر خط الأنابيب الخاص بك. DJLServing يستخدم Netty's EpollEventLoopGroup على لينكس. يتم تعيين إجمالي عدد مؤشرات ترابط Netty افتراضيًا على 2 * عدد وحدات المعالجة المركزية الافتراضية من الجهاز للاستفادة الكاملة من طاقة الحوسبة. علاوة على ذلك ، نظرًا لأنك لا تنشئ عددًا كبيرًا من سلاسل الرسائل ، فإن وحدة المعالجة المركزية الخاصة بك لا تثقلها تبديل السياق. يعمل هذا الإعداد الافتراضي بشكل جيد في معظم الحالات ؛ ومع ذلك ، إذا كنت تريد تعيين عدد سلاسل Netty لمعالجة الطلبات الواردة ، فيمكنك القيام بذلك عن طريق تعيين ملف SERVING_NUMBER_OF_NETTY_THREADS متغيرات البيئة.

ضبط إدارة عبء العمل (WLM) لـ DJLServing

DJLServing لديها WorkLoadManager، وهو المسؤول عن إدارة عبء العمل في مؤشر ترابط العامل. يدير تجمعات مؤشرات الترابط وقوائم انتظار الوظائف ، ويقيس الكمية المطلوبة من سلاسل العمليات لكل نموذج ML أو يزيدها. يحتوي على مقياس تلقائي ، والذي يضيف وظيفة استدلال إلى قائمة انتظار الوظائف للعامل المجاني التالي ويزيد من مجموعة مؤشرات ترابط العمال لهذا النموذج المحدد إذا لزم الأمر. يعتمد القياس بشكل أساسي على عمق قائمة انتظار المهام للنموذج ، وحجم الدُفعة ، والعدد الحالي لمؤشرات ترابط العاملين في التجمع. ال job_queue_size يتحكم في عدد وظائف الاستدلال التي يمكن وضعها في قائمة الانتظار في أي وقت. بشكل افتراضي ، يتم تعيينه على 100. إذا كانت لديك احتياجات التزامن أعلى لكل مثيل عرض للنموذج ، فيمكنك زيادة job_queue_size، وحجم تجمع مؤشرات الترابط ، والحد الأدنى أو الأقصى لعمال مؤشر الترابط لطراز معين عن طريق تعيين الخصائص في serving.properties، كما هو موضح في رمز المثال التالي:

serving.properties
# use minWorkers/maxWorkers for all devices
gpu.minWorkers=2
gpu.maxWorkers=3
cpu.minWorkers=2
cpu.maxWorkers=4

حتى كتابة هذه السطور ، لا يمكنك تكوين job_queue_size in serving.properties. القيمة الافتراضية job_queue_size يتم التحكم فيه بواسطة متغير بيئة ، ويمكنك فقط تكوين الإعداد لكل نموذج باستخدام registerModel API.

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

تصل جميع الطلبات إلى جهاز التجميع الديناميكي أولاً قبل الدخول إلى قوائم انتظار الوظائف الفعلية لانتظار الاستدلال. يمكنك تعيين أحجام الدُفعات المفضلة لديك للجمع الديناميكي باستخدام ملف batch_size الإعدادات في serving.properties. يمكنك أيضًا تكوين ملفات max_batch_delay لتحديد الحد الأقصى لوقت التأخير في المُجمع لانتظار الطلبات الأخرى للانضمام إلى الدُفعة بناءً على متطلبات زمن الوصول.

يمكنك ضبط المعلمات التالية لزيادة الإنتاجية لكل نموذج:

• حجم الدفعة - حجم دفعة الاستدلال. القيمة الافتراضية هي 1.
• max_batch_delay - أقصى تأخير لتجميع الدُفعات. القيمة الافتراضية هي 100 مللي ثانية.
• ماكس وقت الخمول - أقصى وقت خمول قبل تصغير مؤشر ترابط العامل.
• الحد الأدنى للعمال - الحد الأدنى لعدد العمليات العاملة. بالنسبة لمحرك DeepSpeed ​​الخاص بـ DJL ، min_worker تم ضبطه على عدد وحدات معالجة الرسومات /TENSOR_PARALLEL_DEGREE.
• ماكس_وركر - الحد الأقصى لعدد العمليات العاملة. بالنسبة لمحرك DeepSpeed ​​الخاص بـ DJL ، max_worker تم تعيينه على mumber من وحدات معالجة الرسومات /TENSOR_PARALLEL_DEGREE.

درجة ضبط موتر التوازي

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

يمكنك تعيين عدد الأقسام للطراز الخاص بك عن طريق ضبط TENSOR_PARALLEL_DEGREE متغيرات البيئة. يرجى ملاحظة أن هذا التكوين هو إعداد عام وينطبق على جميع الطرز على المضيف. إذا كان TENSOR_PARALLEL_DEGREE أقل من العدد الإجمالي لأجهزة التسريع (GPUs) ، DJLServing تطلق مجموعات معالجة Python متعددة تعادل العدد الإجمالي لوحدات معالجة الرسومات /TENSOR_PARALLEL_DEGREE. تتكون كل مجموعة عمليات Python من عمليات Python المكافئة لـ TENSOR_PARALLEL_DEGREE. تحتفظ كل مجموعة معالجة بايثون بالنسخة الكاملة للنموذج.

نبذة عامة

في هذا المنشور ، عرضنا قدرة SageMaker التي تم إطلاقها حديثًا للسماح لك بتكوين وحدات تخزين EBS لمثيل الاستدلال ، ومهلة تنزيل النموذج ، ومهلة بدء تشغيل الحاوية. أظهرنا هذه القدرة الجديدة في مثال لنشر نموذج كبير في SageMaker. قمنا أيضًا بتغطية الخيارات المتاحة لضبط أداء DJL. لمزيد من التفاصيل حول SageMaker والإمكانيات الجديدة التي تم إطلاقها ، ارجع إلى [! Link] و [! Link].

عن المؤلفين

فرانك ليو هو مهندس برمجيات في AWS Deep Learning. يركز على بناء أدوات التعلم العميق المبتكرة لمهندسي البرمجيات والعلماء. في أوقات فراغه ، يستمتع بالتنزه مع الأصدقاء والعائلة.

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

تشينغوي لي هو متخصص في التعلم الآلي في Amazon Web Services. حصل على الدكتوراه. في بحوث العمليات بعد أن كسر حساب منحة مستشاره البحثي وفشل في تسليم جائزة نوبل التي وعد بها. يقوم حاليًا بمساعدة العملاء في مجال الخدمات المالية وصناعة التأمين في بناء حلول التعلم الآلي على AWS. في أوقات فراغه يحب القراءة والتعليم.

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

روبرت فان دوسين هو مدير أول للمنتجات في AWS.

آلان تان هو مدير أول للمنتجات مع جهود SageMaker الرائدة في الاستدلال على النماذج الكبيرة. إنه متحمس لتطبيق التعلم الآلي في مجال التحليلات. خارج العمل ، يستمتع بالخارج.