توسيع نطاق تقديم نماذج LoRA المضبوطة بدقة

في مجال نشر تطبيقات الذكاء الاصطناعي، برز توسيع نطاق خدمة النماذج المضبوطة بدقة كتحدٍ محوري. تخيل سيناريو: أنت شركة ناشئة في مجال البرمجيات كخدمة (SaaS) تخدم 500 عميل ذوي احتياجات متنوعة، وتتطلب تعديلات نماذج لغوية كبيرة (LLM) مضبوطة بدقة للدعم الداخلي ومحتوى التسويق المخصص. يستلزم هذا مهمة شاقة تتمثل في ضبط حوالي 1000 نموذج بدقة.

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

لكن التحدي الحقيقي يكمن في نشر هذه المحولات المضبوطة بدقة بفعالية.

إعداد التجربة

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

💡

لمزيد من الأفكار حول LoRAX من Predibase، ارجع إلى مدونتهم: LoRAX - خدمة مئات النماذج اللغوية الكبيرة المضبوطة بدقة بتكلفة نموذج واحد

الميزات الرئيسية لـ LoRAX

يتميز LoRAX بثلاث ركائز أساسية للتنفيذ:

1. التحميل الديناميكي للمحولات: يسمح بالتحميل الفوري لأوزان LoRA المضبوطة بدقة، مما يضمن عدم تعطيل الطلبات المتزامنة أثناء التشغيل.
2. التخزين المؤقت للأوزان متعدد المستويات: يسهل التبديل السريع لمحولات LoRA بين الطلبات، ويمنع مشاكل نفاد الذاكرة عن طريق تفريغ أوزان المحولات إلى وحدة المعالجة المركزية والقرص.
3. التجميع المستمر للمحولات المتعددة: تستخدم سياسة جدولة عادلة لتحسين الإنتاجية الكلية للنظام، وتوسع استراتيجيات التجميع المستمر عبر مجموعات متعددة من محولات LoRA بالتوازي.

تقييم الأداء باستخدام LoRAX

في تجربتنا، قمنا بتقييم أداء LoRAX بشكل شامل في إدارة مجموعة واسعة من المحولات المضبوطة بدقة باستخدام نموذج TinyLlama LLM. وخلال تجاربنا، قمنا بقياس كفاءته في معالجة العديد من الطلبات عبر محولات متعددة.

المتطلبات الأساسية لـ LoRAX الإعداد

لإعادة إنتاج تجاربنا، اتبع هذه المتطلبات الأساسية لإعداد LoRAX على خادمك:

docker run \
   --gpus all \
   --shm-size 1g \
   -p 8080:80 \
   -v $PWD/data:/data \
   ghcr.io/predibase/lorax:latest \
   --model-id TinyLlama/TinyLlama-1.1B-Chat-v0.6 # base model used for finetuning


بالإضافة إلى ذلك، قم بتثبيت عميل LoRAX لإجراء استدعاءات الاستدلال باستخدام:

pip install lorax-client


رؤى الاستدلال

لقد أتاح استخدام LoRAX لخدمة نماذج LoRA المضبوطة بدقة مزايا واضحة بفضل قدرته على استخدام وحدة معالجة رسوميات (GPU) واحدة لنموذج LLM الأساسي، مع تحميل كل محول ديناميكيًا لكل طلب. هذا النهج الديناميكي — الذي يستخدم وحدة معالجة رسوميات واحدة ويحمل المحولات فورًا — يجعل LoRAX حلاً أمثل لخدمة عدد كبير من نماذج LoRA المضبوطة بدقة.

مثال على كود الاستدلال:

from lorax import Client

client = Client("https://example.lorax.truefoundry.tech", timeout=10)
generated_text = client.generate(
   prompt,
   do_sample=False,
   max_new_tokens=10,
   adapter_id=adapter_id,
   adapter_source="local"
).generated_text


أثبتت نتائج تجاربنا بشكل قاطع الفوائد الجوهرية لاستخدام LoRAX لخدمة نماذج LoRA المضبوطة بدقة. فمن خلال التحميل الديناميكي للمحولات لكل طلب والاستخدام الفعال لوحدة معالجة رسومات A100 واحدة لنموذج LLM الأساسي، حقق LoRAX تحسينًا ملحوظًا في الأداء.

رؤى الأداء

في تجاربنا الأخيرة التي تضمنت التحميل الديناميكي لـ 100 محول، فحصنا عن كثب خصائص أدائها. نبع الكمون الأولي الذي لوحظ أثناء الطلب الأول بشكل أساسي من ضرورة تحميل نموذج LLM الأساسي في الذاكرة. ومع ذلك، أظهرت الطلبات اللاحقة انخفاضًا في الكمون بفضل قدرة LoRax على تبديل المحولات بسرعة وإجراء عمليات دمج في الوقت الفعلي للتنبؤات.

في السابق، ناقشنا في مدوناتنا عملية تحميل نماذج Lora المضبوطة بدقة باستخدام HuggingFace PEFT. ومع ذلك، أبرزت تجاربنا مشكلات كبيرة في هذا النهج:

1) تصاعد الكمون مع زيادة المحولات في ذاكرة وحدة معالجة الرسومات:
ظهرت المشكلة الأبرز عندما حاولنا وضع المزيد من المحولات في ذاكرة وحدة معالجة الرسومات. أدى ذلك إلى ارتفاع ملحوظ في الكمون. ومع كل محول إضافي، شهد الكمون زيادة كبيرة، مما أثر على الأداء العام.

2) سعة محدودة في ذاكرة وحدة معالجة الرسومات:
كان هناك قيد حرج آخر يتمثل في المجموعة المحدودة من المحولات التي يمكن استيعابها داخل ذاكرة وحدة معالجة الرسومات. أعاق هذا القيد قابلية التوسع وشكل عنق زجاجة في استيعاب عدد أكبر من المحولات في وقت واحد.

لزيادة توضيح الفروقات في الأداء، لننظر في المقارنات التالية:

معالجة 70 رمزًا (توكن) وتوليد 10 رموز على وحدة معالجة رسوميات A100:
HuggingFace PEFT: تراوح زمن الاستجابة بين 400-450 مللي ثانية.
LoRAX: أظهر متوسط زمن استجابة قدره 170 مللي ثانية.

تأثير المحولات على زمن الاستجابة:
HuggingFace PEFT: أدت إضافة 1000 محول Lora من نوع tinyllama إلى نموذج اللغة الكبير الأساسي (LLM) إلى ارتفاع زمن الاستجابة إلى 3500-4000 مللي ثانية، مما يمثل زيادة تقارب 700%.
LoRAX: ظل زمن الاستجابة ثابتًا وغير متأثر بعدد المحولات، بفضل آلية التحميل الديناميكي الخاصة به على وحدة معالجة الرسوميات (GPU)، مما يضمن زمن استجابة مستقرًا حتى مع وجود عدد أكبر من النماذج.

باختصار، بينما يسهل HuggingFace PEFT تكييف النماذج واستخدام المحولات، إلا أنه يواجه تحديات في الأداء مع زيادة عدد المحولات، مما يؤثر بشكل خاص على زمن الاستجابة وقابلية التوسع. في المقابل، يتميز LoRAX بقدرته على تحميل المحولات ديناميكيًا وتنفيذ التنبؤات في الوقت الفعلي، مما يضمن أداءً ثابتًا وقابلية للتوسع، حتى مع وجود عدد كبير من نماذج Lora المعدلة بدقة.

الخلاصة

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

من خلال الاستفادة من استراتيجيات LoRAX الفعالة لتحميل المحولات، يمكن للشركات توسيع نطاق خدماتها بثقة لتشمل آلاف نماذج LoRA المعدلة بدقة والمصممة خصيصًا، مع الحفاظ على نموذج أساسي موحد.

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

TrueFoundry هي منصة كخدمة (PaaS) لنشر تعلم الآلة (ML) تعمل فوق Kubernetes لتسريع سير عمل المطورين مع منحهم مرونة كاملة في اختبار ونشر النماذج، وضمان الأمان والتحكم الكامل لفريق البنية التحتية. من خلال منصتنا، نمكّن فرق تعلم الآلة من نشر ومراقبة النماذج في 15 دقيقة بموثوقية 100% وقابلية للتوسع، والقدرة على التراجع في ثوانٍ - مما يسمح لهم بتوفير التكلفة وإطلاق النماذج إلى الإنتاج بشكل أسرع، مما يحقق قيمة تجارية حقيقية.