#

النقاط الرئيسية

• توثّق AWS إعداد استدلال LLM بعقدتين على Amazon EKS.

• يستخدم الإعداد Ray LLM Deep Learning Containers.

• يفصل بين عقدتي prefill وdecode خلف نقطة نهاية واحدة متوافقة مع OpenAI.

• يناسب هذا النهج أنماط الاستدلال متعددة العقد مثل التوازي على مستوى tensor، والتوازي على مستوى pipeline، والتوازي على مستوى البيانات.

• يمكن أن تمتد عمليات نشر Ray Serve عبر عدة عقد.

ما الذي وثّقته AWS

نشر AWS Machine Learning Blog هذا التقرير في 12 أكتوبر 2026. يشرح المنشور كيفية نشر نموذج لغة كبير واحد عبر عقدتي GPU على Amazon Elastic Kubernetes Service، أو Amazon EKS. ويستخدم Ray LLM Deep Learning Containers متعددة العقد لتنفيذ ذلك. ويضع التصميم عقدتي prefill وdecode منفصلتين خلف نقطة نهاية واحدة متوافقة مع OpenAI.

يقدّم المنشور هذا على أنه نمط استدلال متعدد العقد. ويذكر أن هذا النوع من الإعداد شائع في أعباء عمل الاستدلال التي تعتمد على التوازي على مستوى tensor، والتوازي على مستوى pipeline، والتوازي على مستوى البيانات، وأعباء عمل الاستدلال التي تفصل بين prefill وdecode. وهذا يجعل المنشور مثالاً عملياً مفيداً على كيفية تنظيم الاستدلال الموزع على EKS.

كيف وُصف الإعداد

تقول AWS إن المنشور يبني على مثال سابق. في ذلك المنشور السابق، قدّمت الشركة Ray Serve DLC واستخدمته لتشغيل نموذج صغير خلف نقطة نهاية HTTP على عقدة GPU واحدة. وكان الحاوي يحافظ على توافق مكدس GPU، بما في ذلك مكتبات CUDA، لذلك لم تكن هناك حاجة إلى كتابة كود نمطي متكرر.

في المنشور الجديد، تمتد الفكرة العامة نفسها إلى عدة عقد. Ray هو إطار حوسبة موزعة، لذلك يمكن لعمليات نشر Ray Serve أن تمتد عبر أكثر من عقدة واحدة. ويستخدم المدونة هذه الخاصية لتوضيح كيف يمكن تقسيم نموذج واحد عبر عقدتي GPU مع الاستمرار في تقديم نقطة نهاية واحدة للعميل.

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

لماذا يستخدم العملاء Ray Serve متعدد العقد

تذكر AWS ثلاثة أسباب تجعل العملاء يستخدمون Ray Serve متعدد العقد. أولاً، يرغب بعضهم في تشغيل نماذج foundation أو open-weight كبيرة جداً بحيث لا تتسع لوحدة GPU واحدة. ثانياً، يحتاج بعضهم إلى معدل إنتاجية أعلى مما يمكن أن توفره نسخة واحدة. ثالثاً، يرغب بعضهم في فصل مرحلتي الاستدلال لتحسين الأداء.

تشير هذه الأسباب إلى موضوع تشغيلي مشترك. فالاستدلال متعدد العقد لا يتعلق فقط بالتوسّع، بل يتعلق أيضاً بمواءمة شكل النشر مع شكل عبء العمل. ويعرض المنشور فصل prefill وdecode كإحدى الطرق لتحقيق ذلك.

كما يسلّط المدونة الضوء على قيمة نهج الحاويات. فمن خلال الحفاظ على توافق مكدس GPU، تقلل Ray LLM Deep Learning Containers الحاجة إلى أعمال إعداد مخصصة. وهذا مهم عندما يكون الهدف الانتقال من مثال بعقدة واحدة إلى نشر متعدد العقد دون تغيير نموذج الخدمة الأساسي.

اعتبارات تشغيلية من المصدر

تدعم المادة المصدرية بعض الاعتبارات العملية. فالإعداد متعدد العقد يضيف تنسيقاً بين العقد. كما يضيف فصلاً بين أدوار prefill وdecode. وقد يساعد هذا الفصل في تحسين الأداء، لكنه يعني أيضاً أن النشر يجب أن يدير جزأين من مسار الاستدلال.

لا يصف المنشور المخاطر بالتفصيل. ولا يذكر معالجة الأعطال أو سياسات التوسّع أو المراقبة. لذا فإن القراءة الأكثر أماناً تقتصر على البنية نفسها. والنقطة التشغيلية الأساسية هي أن Ray Serve يمكنه توزيع الاستدلال عبر العقد مع الحفاظ على نقطة نهاية واحدة للعملاء.

الصلة بالمغرب

لا يورد المصدر أي حقيقة خاصة بالمغرب. وبالنسبة للقراء في أي سوق، فالعبرة العالمية بسيطة: إذا لم تكن عقدة GPU واحدة كافية، فقد يساعد تصميم خدمة متعدد العقد على مواءمة حجم النموذج واحتياجات الإنتاجية.

الخلاصة

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

بالنسبة للفرق التي تقيّم معمارية الاستدلال، فإن الرسالة الرئيسية في المنشور واضحة. يمكن لـ Ray Serve أن يمتد عبر العقد، وهذا يجعله مناسباً للنماذج الأكبر، والإنتاجية الأعلى، وتصاميم الاستدلال التي تفصل بين المراحل.