تقليديًا، كان تغيير عدد وحدات GPU في خدمة vLLM يتطلب إضافة أو إزالة نسخ كاملة من النموذج أو إعادة تشغيل المحرك بعدد مختلف من وحدات GPU. ومع ازدياد حجم النماذج، تحتاج كل نسخة إلى المزيد من وحدات GPU، لذا فإن التوسّع عبر النسخ يضيف أو يزيل وحدات GPU بزيادات أكبر على نحو متزايد. كانت إعادة تشغيل vLLM لتوسيع DeepSeek V4 Pro من 16 إلى 20 وحدة GB200 GPU توقف الخدمة لمدة 197 ثانية (انظر قسم الأداء للتفاصيل)، تاركةً تلك وحدات GPU المكلفة مخصصة دون توليد أي رموز.
في منشورنا الأول حول Elastic EP، عرضنا كيف يمكن لـ vLLM إضافة أو إزالة وحدات GPU من نشر DEP قيد التشغيل (انتباه متوازٍ بالبيانات مع MoE متوازٍ بالخبراء) دون إعادة تشغيله. ورغم أننا تجنبنا إعادة التشغيل، استمر توقف الخدمة طوال إعادة التهيئة بينما كنا نُهيئ العاملين الجدد، ونجهّز مجموعات الاتصال الموسعة، ونحمّل أوزان النموذج، ونكرر تسخين النوى (kernel warmup) والتقاط رسوم CUDA البيانية. في معيار الأداء الخاص بنا لـ DeepSeek V4 Pro، استمر هذا التوقف لمدة 100 ثانية عند التوسيع من 16 إلى 20 وحدة GPU و 56 ثانية عند التقليص مجددًا إلى 16 وحدة GPU (التفاصيل الكاملة في قسم الأداء).
. في هذا المنشور، نصف كيف مكّن التحضير غير المتزامن و NIXL EP من إعادة تهيئة Elastic EP بوقت تعطل شبه صفري. في المعيار نفسه، قلّصنا وقت التعطل إلى 0.82 ثانية عند التوسيع من 16 إلى 20 وحدة GPU و 1.96 ثانية عند التقليص مجددًا إلى 16 وحدة GPU، مما سمح لنا بالتوسيع والتقليص مع تأثير شبه معدوم على أداء الخدمة.
تراكب تحضير الهيكل مع تقديم الخدمة
أعدنا تنظيم مسار إعادة التهيئة في vLLM إلى مرحلتين: تحضير في الخلفية والتزام قصير. يستخدم العاملون الحاليون خيوطًا خلفية منفصلة لتحضير وتسخين الاتصال المستهدف، ونقل أوزان النموذج، ومزامنة المعلومات المتعلقة بالتنفيذ (مثل نتائج الضبط التلقائي) مع العاملين المنضمين، مع الاستمرار في خدمة الطلبات بمجموعات الاتصال ورسوم CUDA البيانية الحالية. وعلى التوازي، يُهيئ العاملون المنضمون أنفسهم، ويستلمون أوزان النموذج، ويجهزون اتصالاتهم وتنفيذ GPU الخاص بهم. خلال مرحلة الالتزام، يوقف vLLM جدولاته باختصار، ويُفعّل الهيكل المُحضّر، ثم يستئنف الخدمة. قُدّمت هذه التغييرات في التحضير غير المتزامن و تحسينات التحضير/الالتزام.
يشمل التحضير أربع مهام رئيسية:
- تهيئة العاملين المنضمين. بدء عملياتهم وتخصيص التخزين للنموذج والتنفيذ.
- تحضير الاتصال. إعداد مجموعات الاتصال الهدف وتوسيع المُتواصل EP communicator.
- نقل أوزان النموذج. نقل الأوزان المطلوبة من العُقد العاملة القائمة إلى العُقد العاملة المنضمة عبر NVLink أو RDMA.
- التحضير للتنفيذ. إكمال التجميع المطلوب وتسخين النوى (kernel warmup) وإعداد الضبط وبناء رسوم CUDA البيانية على العُقد العاملة المنضمة.
بعد مرحلة الالتزام، يتيح موازنة التحميل المتوازي للخبراء غير المتزامنة (EPLB) للعُقد العاملة الجديدة البدء في معالجة الانتباه بينما تتولى العُقد العاملة القائمة معالجة حسابات الخبراء. ثم يعيد EPLB توزيع الخبراء عبر المجموعة الموسعة في الخلفية.
التحدي الرئيسي هو تهيئة الاتصال وتنفيذ GPU دون إشراك العُقد العاملة التي تخدم الطلبات أو تعطيلها.
توسيع اتصال EP في مكانه
قبل NIXL EP، كانت أطر اتصال EP المتاحة في vLLM تستخدم عضوية ثابتة: كانت كل نسخة تُنشأ لمجموعة معينة من الرتب (ranks). وإضافة الرتب أو إزالتها تتطلب نسخة جديدة. وحتى عندما يمكن إنشاء تلك النسخة في الخلفية، تبقى مشكلتان.
أولاً، تحتاج النسختان القديمة والجديدة إلى مخازن اتصال منفصلة وموارد أخرى، بما في ذلك تسجيلات الذاكرة ومقابض IPC وأزواج طوابير RDMA (QPs). والإبقاء على النسختين معًا يزيد من استهلاك ذاكرة الاتصال ويتطلب تكرار الإعداد بدلاً من إعادة استخدام الموارد القائمة.
ثانيًا، يؤدي تبديل مُتواصلات EP إلى تغيير المخازن وحالة الاتصال المستخدمة من قبل نوى اتصال EP. وهذا يُبطل رسوم CUDA البيانية الملتقطة سابقًا، والتي يجب إعادة التقاطها قبل استئناف الخدمة. ويتطلب ذلك تكرار التسخين وبناء الرسوم البيانية للعديد من أشكال الدفعات عبر جميع العُقد العاملة المحتفَظ بها. في معيار الأداء DeepSeek V4 Pro لدينا، حتى مع التحضير غير المتزامن، أدى إجراء التسخين وإعادة التقاط الرسوم البيانية أثناء مرحلة الالتزام إلى توقفات في الخدمة بلغت 58 ثانية أثناء التوسع و 44 ثانية أثناء التقليص.
لحل هذه المشكلات، صممنا NIXL EP، وهي مكتبة اتصال EP مصممة خصيصًا لـ Elastic EP. فهي تضيف الرتب أو تزيلها في مكانها، معادةً استخدام وكيل NIXL نفسه والمخازن نفسها والاتصالات نفسها. ويمكن توصيل الأطراف الجديدة بينما تواصل العُقد العاملة القائمة الخدمة، ولا تحتاج إلا الأطراف المنضمة إلى اتصالات وتسجيلات جديدة. كما يحافظ NIXL EP على صحة مدخلات الإرسال (dispatch) والدمج (combine) الملتقطة لـ EP عبر عمليات إعادة التهيئة، مما يتيح للعُقد العاملة المحتفَظ بها إعادة استخدام رسوم CUDA البيانية القائمة لديها.
أثناء التحضير، يتصل خيط vLLM الخلفي بنظراء الانضمام دون تفعيلهم. ثم تقوم مرحلة الالتزام (commit) بتفعيل النظراء المُحضَّرين دون استبدال أداة الاتصال.
الشكل 1. ربط نظراء EP الجدد وتفعيلهم. الرتب الخضراء نشطة؛ والرتب الرمادية متصلة لكنها مُقنَّعة. أثناء مرحلة الالتزام، يتم تفعيل النظراء الجدد دون استبدال الوكيل أو المخازن المؤقتة.
لا يزال vLLM ينشئ مجموعات تنسيق DP جديدة ومجموعات EPLB للطوبولوجيا الهدف، لكن اتصالاتها تعمل خارج مرور التمرير الأمامي للموديل الملتقَطلذا فإن التبديل إليها لا يُبطل رسوم CUDA البيانية.
الحفاظ على رسوم CUDA البيانية في العاملين الحاليين
تسجّل الرسمة البيانية CUDA (CUDA graph) عمليات GPU بحيث يستطيع vLLM إعادة تشغيل تمرير أمامي دون إطلاق كل عملية من وحدة المعالجة المركزية مرارًا وتكرارًا. تتضمن عقدة النواة الملتقَطة إعدادات إطلاقها وقيم وسائطها، بما في ذلك المؤشرات إلى موترات الإدخال والإخراج. يمكن أن تتغير محتويات الذاكرة بين عمليات إعادة التشغيل، لكن المؤشرات المسجّلة يجب أن تبقى صالحة. هذه المتطلبات جزء من عقد تنفيذ رسوم CUDA البيانية.
يلتقط vLLM رسومًا بيانية منفصلة لأشكال الدُفعات وأوضاع التنفيذ المختلفة ويشغّل تمارير تمرير أمامي تحضيرية قبل كل عملية التقاط.
يتطلب الحفاظ على رسوم CUDA البيانية الملتقَطة أكثر من مجرد إبقاء كائن أداة الاتصال حيًا. كما تحافظ NIXL EP على إعدادات إطلاق النوى، ووسائط الاتصال المرئية للرسم البياني، وعناوين موترات الإدخال والإخراج مستقرة عبر عمليات إعادة التهيئة. تقرأ نواها عضوية المجموعة النشطة من حالة الجهاز التي يمكن تحديثها في مكانها.
كما غيّرنا vLLM لإبقاء الوسائط الملتقَطة وإعدادات الإطلاق وعناوين موترات الإدخال والإخراج لنوى الحوسبة المحيطة مستقرة عبر عمليات إعادة التهيئة:
- نعيد استخدام كائنات تنفيذ fused-MoE المحتفَظ بها من العاملين بدلاً من إعادة بنائها لحجم EP نشط مختلف.
- نُبقي عناوين وتخطيطات مساحات العمل المرئية للرسم البياني ومخرجات الإرسال (dispatch) مستقرة عبر إعادة التهيئة حتى تتمكن نوى الخبراء الملتقَطة من مواصلة استخدامها. كما تُستخدم مخرجات الإرسال كمدخلات لحساب الخبراء. لو تغيّرت عناوينها أو تخطيطاتها مع حجم EP، لظلّت نوى الخبراء الملتقَطة تستخدم المؤشرات والإزاحات القديمة.
- نحافظ على وحدة التخزين الداعمة لموترات توجيه الخبراء ونحدّث التعيينات في مكانها. هذا يسمح لـ EPLB بتغيير محتويات التعيين دون تحريك الموترات المستخدمة من قبل النوى الملتقَطة.
تسمح هذه التغييرات مجتمعةً للعاملين المحتفَظ بهم بـ إعادة استخدام رسوم CUDA البيانية الحالية بعد التوسّع والتقليص معًا.
تحضير عمال الانضمام بشكل مستقل
العمال الحاليون لديهم رسوم بيانية يريدون الحفاظ عليها. أما عمال الانضمام فلا يملكون أيًّا منها.
يحضّر عمال الانضمام عادةً بتشغيل تمارير تمرير أمامي للموديل مع إرسال ودمج EP، بالإضافة إلى تبادل معلومات الدُفعة مع العمال الآخرين. تتطلب هذه الخطوات مشاركة العمال الآخرين، لكن العمال الحاليين مشغولون بالفعل بخدمة طلبات حقيقية على الطوبولوجيا الحالية.
تتيح NIXL EP لكل عامل انضمام أن يقنّع مؤقتًا كل نظير EP بعيد أثناء التحضير والتحضير للرسوم البيانية. تكون رتبته المحلية وحدها نشطة لاتصالات EP. كما عدّلنا vLLM بحيث لا تنتظر هذه التمارير التحضيرية معلومات الدُفعة من DP من عمال آخرين. يتيح هذا لعمال الانضمام تشغيل دفعاتهم الوهمية والتقاط رسوم CUDA البيانية دون الحاجة إلى مشاركة العمال الحاليين.
الشكل 2. الرتب الخضراء نشطة لاتصالات EP؛ والرتب الرمادية مُقنَّعة. يخدم العمال الحاليون معًا بينما يُقنّع كل عامل انضمام جميع نظراء EP البعيدين أثناء التحضير.
بعد الالتقاط، تستطيع NIXL EP إعادة تفعيل النظراء دون إبطال الرسوم البيانية. يعيد عمال الانضمام استخدام رسومهم البيانية الملتقَطة محليًا عندما يبدأون الخدمة كجزء من المجموعة الموسّعة.
الأداء على DeepSeek V4 Pro
جميع التجارب في هذا القسم استخدمت DeepSeek V4 Pro على وحدات GPU من نوع GB200، مع TP=1 وأحجام DP/EP تبلغ 16 و20. تم تنزيل أوزان الموديل مسبقًا بصيغة safetensors على تخزين Lustre المشترك وتم تحميلها باستخدام --load-format autoالافتراضي. استُخدمت في القياسات ذاكرات تخزين مؤقت دافئة لتجميع النوى (Triton وTileLang وFlashInfer).
توقيتات التوسع والتقليص
يوضح الجدول المراحل التي تعمل أثناء إيقاف الخدمة مؤقتاً والتي تعمل في الخلفية بينما يواصل العاملون الحاليون تقديم الخدمة.
| المرحلة | A: حاجب | B: تحضير غير متزامن | C: تحضير غير متزامن + إعادة استخدام الرسم البياني |
|---|---|---|---|
| تهيئة العاملين المنضمين | الخدمة متوقفة مؤقتاً | الخلفية | الخلفية |
| تجهيز الاتصال الهدف | إيقاف الخدمة مؤقتًا | في الخلفية | في الخلفية |
| نقل أوزان النموذج | إيقاف الخدمة مؤقتًا | في الخلفية | في الخلفية |
| التسخين والتقاط الرسم البياني على العُقد العاملة المنضمة | إيقاف الخدمة مؤقتًا | إيقاف الخدمة مؤقتًا | في الخلفية |
| التسخين والتقاط الرسم البياني على العُقد العاملة الحالية | إيقاف الخدمة مؤقتًا | إيقاف الخدمة مؤقتًا | غير ضروري (الرسوم البيانية الحالية تبقى صالحة) |
| تنشيط الطوبولوجيا الهدف | إيقاف الخدمة مؤقتًا | إيقاف الخدمة مؤقتًا | إيقاف الخدمة مؤقتًا |
التكوين C مدعوم بواسطة NIXL EP فقط.
- وقت التوقف: انقطاع الخدمة الملحوظ، عندما تتوقف الطلبات قيد التنفيذ عن التقدم ولا يتم قبول طلبات جديدة.
- الوقت الإجمالي: مدة عملية التوسيع الكاملة، بما في ذلك التجهيز.
تُقاس المددتان بشكل منفصل.
| المقياس | A: حجب | B: تجهيز غير متزامن | C: تجهيز غير متزامن + إعادة استخدام الرسم البياني |
|---|---|---|---|
| من 16 إلى 20 GPU: وقت التوقف | 99.62 ثانية | 58.04 ثانية | 0.82 ثانية |
| من 20 إلى 16 وحدة معالجة رسومية: التوقف عن العمل | 56.25 ثانية | 44.07 ثانية | 1.96 ثانية |
| من 16 إلى 20 وحدة معالجة رسومات: الوقت الإجمالي | 99.72 ثانية | 97.27 ثانية | 92.34 ثانية |
| من 20 إلى 16 وحدة معالجة رسومية: الوقت الإجمالي | 56.21 ثانية | 51.46 ثانية | 9.32 ثانية |
اجتازت جميع التكوينات فحوصات الصحيحة الرقمية، بما في ذلك فحوصات كل عامل انضمام.
الحفاظ على اتفاقية مستوى الخدمة (SLO) مع إضافة وحدات معالجة الرسوميات (GPUs)
قمنا بتشغيل DeepSeek V4 Pro على 16 وحدة معالجة رسومية، ثم زدنا تدريجيًا معدل الطلبات الواردة من حوالي 8 إلى 16 طلبًا في الثانية. أعادنا تشغيل نفس السيناريو المكون من 11,391 طلبًا مقابل ثلاث عمليات نشر: ظلّت الأولى على 16 وحدة معالجة رسومية، وأُعيد تشغيل الثانية بـ 20 وحدة معالجة رسومية، بينما توسّعت الثالثة إلى 20 وحدة معالجة رسومية باستخدام Elastic EP مع NIXL EP. كان هدف مستوى الخدمة (SLO) هو أن يبقى زمن أول رمز (p95) المتجدد أقل من 5 ثوانٍ.
الشكل 3. الخدمة من طرف إلى طرف تحت حمل طلبات متزايد. تُظهر المنحنيات نتائج p95 المتداولة لكل 30 ثانية، مع إسناد عقوبة مدتها 30 ثانية للطلبات الفاشلة بدلاً من TTFT مقاس.
- أكمل Elastic EP جميع الطلبات البالغة 11,391 طلبًا وبقي تحت SLO طوال السيناريو.
- أثناء التحضير، طابق Elastic EP أداء الخدمة لنشر الـ 16 GPU الثابت، دون أي تدهور مرئي بسبب التحضير في الخلفية.
- بعد التوسيع، طابق Elastic EP أداء نشر الـ 20 GPU المستعاد، دون أي تدهور مرئي بعد التوسيع.
جرّب Elastic EP
التحضير في الخلفية، وإعادة استخدام CUDA graphs، والالتقاط المستقل للـ graphs على العاملين المنضمين، كلها متوفرة اليوم في أحدث إصدارات vLLM و NIXL . ثبّتها باستخدام pip وابدأ في استخدام Elastic EP.
للحصول على مثال استخدام كامل، راجع cuda_graphs_heavy_nixl_ep حالة اختبار Elastic EP في vLLM. يتضمن المثال إعداد الخادم واستدعاءات واجهة API الخاصة بالتوسيع. إنه يتوسع من وحدتي GPU إلى أربع والعكس أثناء إرسال الطلبات، مع التحقق من الخدمة أثناء التحضير ودقة النموذج حول كل عملية تغيير حجم.
ماذا بعد
استعادة العاملين الدافئين باستخدام Dynamo Snapshot
لقد حللنا فعليًا مشكلة انقطاع الخدمة الطويل. التحدي التالي هو تجهيز السعة الجديدة بسرعة أكبر. نخطط لدمج Dynamo Snapshot حتى يتمكن العمال المنضمون من استعادة العملية المهيأة وحالة CUDA بدلاً من تكرار الترجمة (compilation) والإحماء الأولي للنوى (kernel warmup) وبناء الرسوم البيانية وغيرها من أعمال بدء التشغيل.
يجب تهيئة الاتصال للطوبولوجيا المستهدفة بشكل منفصل لأنه لا يُستعاد من اللقطة. يمكن أن تسيطر استعادة أوزان النماذج الكبيرة من مخزن نقاط التحقق على زمن الاستعادة، لذلك نخطط للاحتفاظ بنقل أوزان GPU-to-GPU الخاص بـ Elastic EP من العمال الحاليين بدلاً من ذلك.
تحقيق أداء اتصال EP رائد من مستواه العالمي مع NIXL EP
نحن نهدف إلى تحقيق أداء رائد من مستواه العالمي في الإرسال (dispatch) والدمج (combine) مع NIXL EP مع الحفاظ على الدعم الكامل لـ Elastic EP والتسامح مع الأخطاء. التحديث القادم لأداء NIXL EP هو الخطوة التالية نحو تحقيق ذلك الهدف (انظر NIXL EP roadmap RFC).
ربط Elastic EP بتنسيق Dynamo وllm-d
مع توفر القدرة على مستوى المحرك، فإن الخطوة التالية هي استخدام Elastic EP من مجدّيات التوسع التلقائي في المنسق (orchestrator autoscalers). العمل على هذا التكامل جارٍ بالفعل عبر مجتمعات vLLM وDynamo وllm-d.
تشمل هذه الجهود عمل vLLM على موازن التحميل الخارجي و مقترح Elastic EP في Dynamo.
إذا كنت تشغّل الاستدلال على نطاق واسع، فنشجعك على تجربة Elastic EP ومشاركة أحمال العمل والمتطلبات التشغيلية الخاصة بك. وإذا كنت تبني بنية تحتية للاستدلال، فنرحّب بمساهماتكم في vLLM Elastic EP وNIXL EP. لنجعل Elastic EP يعمل في بيئات الإنتاج.
شكر وتقدير
- تايلر مايكل سميث وسايج مور من Red Hat على ملاحظاتهم القيّمة ومراجعاتهم الدقيقة على مدار هذا العمل.
- لينوي جيفا (NVIDIA) على عملها في أداء الخدمة خلال فترة التحضير.
- فريق NIXL بأكمله على جهودهم في NIXL EP.
- تسو-لينغ كان، وجوليان مانكوسو، وفريق Dynamo بأكمله على جهودهم لدعم Elastic EP في Dynamo.