الفصل 11 — طبقة المنصة والتنسيق

المقالة الحادية عشرة من الجولة الفصلية لـ LLM Primer VI: توسيع أنظمة الذكاء الاصطناعي. الفصل الذي يُحاجج بأن اختيار المنصة ليس عن الميزات بل عن أي نموذج تشغيلي يُطابق ثقافة تشغيل الفريق القائمة.

لماذا يوجد هذا الفصل

يُغلِّف المحرك نموذجاً على GPU ويُنتج رموزاً. تلك وظيفته كاملةً. اللحظة التي يحتاج فيها الإنتاج إلى نسختَين خلف موازن حمل، أو محرَّكَين مختلفَين تحت نقطة نهاية واحدة، أو خط أنابيب يُشغِّل embed→retrieve→rerank→generate كاستدعاء منطقي واحد، أو نظام حصص يمنع مستأجراً من تجويع آخر، أو مُوسِّعاً تلقائياً يُضيف نسخاً مع ارتفاع عمق الطابور، ينفد جواب المحرك. يمشي الفصل 11 على المنصات الأربع المُهيمنة على تلك الوظيفة في 2026 — Ray Serve وKServe وBentoML وTriton Inference Server — ويُحاجج بأن الاختيار بينها سؤال ملاءمة لثقافة تشغيل الفريق، لا سؤال ميزات.

11.1 Ray Serve أولاً Python؛ KServe أولاً Kubernetes

Ray Serve هو المنصة التي تخرج حين يكون السؤال الأول «كيف سيكون شكل إطار تخديم لو لم أضطر أبداً لمغادرة Python لتأليف وتوسيع ونشر خط أنابيب نموذج؟». الإجابة فئات Python مُوسَّمة كممثِّلين، مُوصَّلة معاً باستدعاءات دوال Python، مُماثَلة ومُوضَّعة ومُوسَّعة تلقائياً من قِبل وقت تشغيل Ray. تتألَّف النشرات في خطوط أنابيب باستدعاء أساليب بعضها البعض؛ خط الأنابيب Python، وقابلية الرصد Python، وقصة التشغيل Python. إنه الاختيار الطبيعي حين يُشغِّل نفس العنقود بالفعل Ray للتدريب. KServe يخرج من نقطة البداية المعاكسة: أولاً Kubernetes، محايد المزوِّد، تعريفي. InferenceService في KServe هو CRD يلتقط أين تعيش الأوزان، أي وقت تشغيل يخدمها، وكيف يجب أن يسلك التوسع التلقائي. تُوصِّل المنصة الوحدات عبر Knative للتوسع إلى صفر وIstio لتوجيه حركة المرور، وتُعرِّض نقطة نهاية HTTP مستقرة. المقايضة هي التعبيرية — تأليف خطوط الأنابيب في KServe مدفوعاً بـ YAML أكثر من Ray Serve — مقابل النقل والتوحيد.

11.2 BentoML يحزم؛ Triton يُجمِّع نماذج مختلفة

BentoML يتَّخذ موقفاً ثالثاً: وظيفة المنصة الأولى جعل نموذج + كود + تبعيات قطعةً أثريّةً واحدة متماسكة — Bento — وجعل نشر تلك القطعة إلى أي مكان (Kubernetes وLambda وCloud Run وأو VM عادية) عملية بأمر واحد. إنه ما تُمثِّله صورة Docker للتطبيقات العامة، عند طبقة تخديم النماذج. تجربة التأليف مصاغة FastAPI في Python؛ وقصة النشر حركة القطعة الأثرية أولاً. أفضل ملاءمة قدمُ تشغيل صغيرة وفريقٌ يريد أسرع مسار من «فئة Python» إلى «نقطة نهاية منشورة تعمل أي مكان». Triton Inference Server هو المُجمِّع الديناميكي بدرجة المؤسسة الذي كان تاريخياً يهيمن على التخديم المُتوائم مع NVIDIA. يستضيف TensorFlow وPyTorch وONNX وTensorRT وTensorRT-LLM وواجهات Python جنباً إلى جنب، ويُطبِّق مُجمِّعه الديناميكي على أعباء عمل غير LLM (المُوصِّيات والمُصنِّفات والمُضمِّنات)، ويستخدم مُجَدوِل التجميع المستمر لـ LLM تحت خلفية TensorRT-LLM. أفضل ملاءمة أعباء عمل غير متجانسة أو فريق عميقٌ فعلاً في مكدس NVIDIA.

11.3 الاختيارات الأربعة تُقسَّم بحسب ملاءمة ثقافة التشغيل

تُقسَّم المنصات الأربع بنظافة. Python وRay كمركز ثقل ← Ray Serve. Kubernetes، بيانات تعريفية، نقل متعدِّد السحاب، عزل متعدِّد المستأجرين ← KServe. قدم تشغيل صغيرة، أسرع مسار من فئة إلى نقطة نهاية ← BentoML. أعباء عمل غير متجانسة أو متجر أولاً NVIDIA ← Triton. ليست حصرياً مُتبادلَة على المستوى التنظيمي: نمط شائع في المؤسسات الأكبر هو Triton لأعلى LLM إنتاجية إنتاج، وRay Serve لخطوط أنابيب RAG والوكيل التي تُؤلِّف عدة استدعاءات نموذج، وKServe كمظلَّة تُنفِّذ تعدُّد المستأجرين، وBentoML داخل بيئات المطوِّرين. التمرين المفيد عند الاختيار سرد ثلاث خصائص تشغيلية يحتاجها الفريق مطلقاً وثلاث يستطيع العيش بدونها مطلقاً، ثم ترتيب المنصات مقابل تلك القائمة. قاوم المنصة التي «تدعم كل شيء» — كل منصة تدعم لبَّها جيداً ومحيطها ضعيفاً، وتلك التي يتداخل لبُّها مع المطلوبات هي التي سيستمتع الفريق بتشغيلها.

ما يُمهِّد له الفصل 11

حد المحرك/المنصة نظيف عندما تكون وحدة النسخ pod تمتلك نموذجاً على عقدة GPU. يتوقَّف عن كونه نظيفاً اللحظة التي نُكرِّم فيها حقيقة الفصل 1 بأن التعبئة الأمامية وفك التشفير عبآ عمل متناقضان. يقسمهما الفصل 12 على تجمُّعَي GPU منفصلَين، ويشحن ذاكرة KV بين التجمُّعين عبر نسيج الشبكة، ويُعبِّر عن القسمة في بدائيّات Kubernetes — LeaderWorkerSet وPodCliqueSet من Grove وإدراك طوبولوجيا KAI Scheduler. طبقة المنصة هي ما يجعل القسمة قابلة للتشغيل؛ طبقة المنصة هي سبب كون القسمة قابلة للتعبير أصلاً.

التالي — الفصل 12: التخديم المُفصَّل وKubernetes. تقسيم التعبئة الأمامية وفك التشفير إلى pods منفصلة وبدائيّات Kubernetes التي تُعبِّر عن القسمة.