AWS تعرض طريقة تشغيل نموذج LLM واحد على عقدتي GPU في EKS عبر Ray LLM DLC

نشرت AWS دليلاً تفصيلياً خطوة بخطوة لتشغيل نموذج لغوي كبير واحد على عقدتي GPU في Amazon EKS. تنفّذ إحدى العقدتين مرحلة prefill وتنفّذ الأخرى مرحلة decode، بينما يبدو النظام من الخارج نقطة وصول واحدة متوافقة مع OpenAI. يقوم الحل على multi-node Ray LLM Deep Learning Containers، وهي صور جاهزة تضم حزمة الاستدلال كاملة. وبذلك يخرج تجميع المكوّنات من مهام الفريق، ولا يبقى سوى ضبط إعدادات النشر.

ما الذي يجري نشره تحديداً

المخطط مختصر: نموذج واحد، وعقدتا GPU في عنقود Amazon EKS، ومرحلتان مختلفتان لمعالجة الطلب موزعتان على جهازين منفصلين. لا يعرف تطبيق العميل شيئاً عن هذه البنية. فهو يتصل بعنوان واحد عبر بروتوكول OpenAI المألوف، وتواصل حزم SDK والأدوات الحالية عملها دون أي تعديل.

الجديد في هذا الإصدار ليس الفكرة نفسها، بل طريقة التغليف. كان بناء استدلال متعدد العقد يعني سابقاً أن يختار الفريق بنفسه إصدارات متوافقة من المحرك والمنسّق وبرامج التشغيل ومكتبات الشبكة. أما الآن فتقدّم AWS ذلك كله في حاوية مُجمَّعة مسبقاً ضمن سلسلة Deep Learning Containers. ودعم Ray في هذه الصورة منطقي: فقد استُخدم Ray منذ سنوات طبقةً لتنسيق الأحمال الموزعة، وصُممت إضافته الخاصة بـ LLM لتقديم النماذج عبر واجهة API واحدة.

لماذا يُفصل prefill عن decode

لتوليد النص مرحلتان بنمطي حمل مختلفين. تعالج مرحلة prefill موجّه الإدخال بالكامل، وهي حسابات كثيفة يحدّ منها أداء GPU. أما مرحلة decode فتُخرج الرموز واحداً تلو الآخر، وغالباً ما يحدّ منها عرض نطاق الذاكرة وحجم KV-cache.

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

المعلمات الرئيسية للمخطط

• النموذج: LLM كبير واحد موزع بين العقدتين.
• البنية: عقدتا GPU، إحداهما مخصصة لـ prefill والأخرى لـ decode.
• المنصة: Amazon EKS، أي Kubernetes العادي في صيغة مُدارة.
• الواجهة: نقطة وصول واحدة متوافقة مع OpenAI لجميع العملاء.
• التسليم: حاوية multi-node Ray LLM Deep Learning Container مُجمَّعة مسبقاً وتضم حزمة الاستدلال كاملة.
• نهج الإعداد: ضبط إعدادات النشر دون تجميع المكوّنات يدوياً.

من الناحية العملية: ما الذي يجب فحصه قبل التطبيق

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

يُستحسن قبل التجربة الأولية التحقق من عدة نقاط:

• الاتصال بين العقدتين. نقل KV-cache حساس لزمن الاستجابة وعرض النطاق، لذا ضع العقدتين في منطقة توافر واحدة، وراجع وثائق AWS بشأن أنواع الأجهزة (instances) ومحوّلات الشبكة المدعومة.
• المقاييس لكل مرحلة. تابع الزمن حتى أول رمز، وهو يعتمد على prefill، وتابع سرعة إخراج الرموز، وهي تعتمد على decode. فمتوسط زمن الاستجابة الإجمالي يخفي أي اختلال في التوازن.
• توازن العقد. عقدة واحدة لكل مرحلة تمثل نقطة بداية. وإذا تراكمت الطوابير في إحدى المرحلتين، فسيلزم توسيع نطاقها بصورة مستقلة.
• توافق العملاء. تسهّل واجهة API المتوافقة مع OpenAI عملية الانتقال، لكن من الأفضل اختبار سلوك معلمات الطلب النادرة ضمن سيناريوهاتك الخاصة.

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