Runpod تشرح كيفية نشر Llama 3.1 8B على vLLM دون خوادم خاصة

نشرت Runpod دليلًا تفصيليًا خطوة بخطوة لنشر Llama 3.1 8B Instruct على محرك vLLM داخل منصتها Serverless. يتحول النموذج، الذي يضم 8 مليارات معامل ويدعم سياقًا يصل إلى 128 ألف توكن، إلى نقطة وصول API تستيقظ عند ورود الطلبات، ولا تتطلب استئجار بطاقة رسوميات على مدار الساعة. والمادة تعليمات استخدام، وليست إطلاقًا لمنتج جديد. لكن موضوعها عملي: فهكذا تنقل الفرق الصغيرة اليوم النماذج المفتوحة إلى بيئة الإنتاج من دون بناء بنية تحتية خاصة بها.

صدر Llama 3.1 في يوليو 2024 بثلاثة أحجام: 8B و70B و405B. والنسخة ذات 8 مليارات معامل هي الأكثر إتاحة. وتشغل أوزانها بصيغة FP16 نحو 16 غيغابايت، ولذلك تتسع لها بطاقة واحدة بذاكرة 24 غيغابايت. ومع ذلك يجب تخصيص هامش منفصل لـ KV-cache عند التعامل مع السياقات الطويلة.

كيف تعمل هذه المنظومة

يُعد vLLM اليوم من أكثر محركات الاستدلال انتشارًا للنماذج المفتوحة. وهو مبني على PagedAttention: تُخصَّص ذاكرة KV-cache على شكل كتل، كما تُدار الصفحات في نظام التشغيل، فيقل التجزؤ. ومع continuous batching، حيث تُضاف الطلبات الجديدة إلى دفعة قيد التنفيذ أصلًا، ترتفع الإنتاجية على بطاقة واحدة. وثمة ميزة إضافية للمطورين: خادم vLLM متوافق مع صيغة OpenAI API، ولذلك يتغير كود العميل في أضيق الحدود.

تضيف Runpod Serverless طبقة إدارة. يُحزَّم النموذج في حاوية worker، وتدخل الطلبات في طابور، وتتولى المنصة بنفسها تشغيل الـ workers وإيقافها، ويُحتسب المبلغ على مدة عملها بدقة الثانية. وتوفر Runpod لـ vLLM قالبًا جاهزًا يُضبط بمتغيرات البيئة: اسم النموذج، ورمز Hugging Face، والحد الأقصى لطول السياق.

أبرز معلمات هذه المنظومة:

• النموذج: Meta Llama 3.1 8B Instruct، بنحو 8 مليارات معامل.
• السياق: حتى 128K توكن.
• الأوزان بصيغة FP16: نحو 16 غيغابايت.
• المحرك: vLLM مع PagedAttention وcontinuous batching.
• الواجهة: API متوافقة مع OpenAI.
• المنصة: Runpod Serverless، مع توسيع تلقائي للـ workers، بما في ذلك التقليص إلى الصفر.

العقبات المحتملة

أهمها البدء البارد. فإذا كان الـ worker متوقفًا، فعليه عند أول طلب تحميل نحو 16 غيغابايت من الأوزان في ذاكرة GPU، وسيلاحظ المستخدم ذلك. ويُخفَّف المشكلة بثلاث طرق: تضمين النموذج داخل صورة الحاوية، أو استخدام التخزين المؤقت على مستوى المنصة، أو إبقاء worker نشط واحد على الأقل. غير أن الخيار الأخير يلتهم جزءًا من التوفير الذي يُختار serverless من أجله.

أما الأمر الثاني فيتعلق بالوصول. يُوزَّع Llama 3.1 بموجب رخصة Meta، والنموذج على Hugging Face مقيّد الوصول: يجب قبول الشروط وتمرير الرمز إلى الـ worker. والثالث يتعلق بالذاكرة. فبشكل افتراضي قد يحجز vLLM مساحة لسياق 128K كاملًا، ولذلك ينبغي تقييد max model len بما يحتاجه التطبيق فعليًا. عندها تبقى مساحة أكبر للطلبات المتزامنة.

تعتمد جدوى serverless على نمط الحمل. ولا تتضمن المادة أسعارًا محددة، لذا يجب الحساب بنفسك وفق تعرفة Runpod الحالية. والقاعدة الإرشادية بسيطة: مع الطلبات النادرة وذات الذروات تتفوق المحاسبة بالثانية على البطاقة المخصصة، أما مع حمل مرتفع ومستقر فيكون الخادم المخصص عادةً أرخص.

من أين تبدأ

يكفي لتجربة أولية تسلسل قصير:

1. قبول رخصة Llama 3.1 على Hugging Face وإنشاء رمز وصول. 2. إنشاء نقطة وصول Serverless على قالب vLLM، مع تحديد النموذج والرمز. 3. اختيار GPU بهامش لا يقل عن 24 غيغابايت وتقييد الحد الأقصى لطول السياق. 4. ضبط الحد الأدنى والأقصى لعدد الـ workers، ومدة الخمول قبل الإيقاف. 5. توجيه عميل OpenAI الحالي إلى نقطة الوصول الجديدة وقياس زمن التوكن الأول على worker بارد وآخر دافئ.

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