Llm-D 1.0 ينطلق في مؤتمر PyTorch بحزمة استدلال جاهزة للإنتاج

أعلن المساهمون في مشروع llm-d عن llm-d 1.0 في 20 أكتوبر 2026، خلال مؤتمر PyTorch Conference North America، وهو حزمة لتقديم الاستدلال الموزع ومصممة للعمل أصليًا على Kubernetes، بحسب إعلان IBM Research. وقالت IBM إن الإصدار ينقل llm-d إلى ما بعد عرض تقنيات تحسين الأداء كلٌّ على حدة، ويهدف إلى مساعدة المؤسسات على استضافة نشر النماذج داخليًا مع ارتفاع تكاليف الاستدلال.

صُمم llm-d لنشر حزم الاستدلال لأي نموذج، وعلى أي مُسرِّع، وفي أي سحابة. وتتولى Red Hat وIBM وGoogle صيانة المشروع، وقد أسست هذه الجهات llm-d بالاشتراك مع CoreWeave وNVIDIA؛ وانضمت AMD وCisco وHugging Face وIntel وLambda وMistral AI إلى المشروع بوصفها جهات مساهمة. وتستضيف مؤسسة الحوسبة السحابية الأصلية (CNCF) llm-d بوصفه مشروعًا في مرحلة الحضانة. وتصف IBM ما نتج عن ذلك بأنه بديل مستقل عن المورّدين للمؤسسات التي تريد، وفق وصفها، أداء استدلال بمستوى النماذج الرائدة، من دون الاعتماد كليًا على مزود واحد لنموذج احتكاري أو سحابة أو منصة عتادية.

قال كارلوس كوستا، المهندس المتميز في IBM Research وأحد مؤسسي llm-d وكبير القائمين على صيانته، إن الإصدار 1.0 يضيف إلى المشروع مستوى النضج اللازم لتشغيله كأي خدمة حيوية أخرى، مشيرًا إلى واجهة برمجة تطبيقات مستقرة، وإمكان مشاركة عدة مستأجرين ذوي أولويات متنافسة للبنية التحتية نفسها، وإجراء ترقيات من دون تعطيل العمليات.

ما الذي يضيفه الإصدار 1.0

تتصدر ملاحظات إصدار v1.0.0 للمشروع، المنشورة على GitHub في 20 أكتوبر 2026 والمرفقة بوسوم موقعة ومتحقق منها، جودة الخدمة في البيئات متعددة المستأجرين: التحكم في تدفق الطلبات مع مراعاة الأولوية والإنصاف، وإدارة تخفيف الحمل، بما يشمل آلية قبول احتمالية، وإنصافًا يراعي البرامج، وتقييمًا لأولوية الأدوار؛ وذلك لتمكين الطلبات الحساسة لزمن الاستجابة وأحمال عمل الوكلاء المتدفقة على نحو مفاجئ من مشاركة مجموعة واحدة من الموارد من دون حرمان بعضها بعضًا عند زيادة الحمل. وقد جُمعت إعدادات التحكم في التدفق ضمن حقل واحد هو flowControl.

لضمان استمرار التشغيل من دون توقف، أُضيفت إلى الموجّه إتاحة عالية مع وضع الاستعداد الفوري والتحديثات التدريجية الآمنة، كما يتولى متحكم DisaggregatedSet إدارة نسخ التمهيد وفك الترميز بوصفها وحدة منطقية واحدة، مع عمليات نشر منسقة وترقيات متزامنة، وربط الجاهزية بلقطة Pod، وتوجيه أصلي بحسب المراجعة. وانتقلت واجهة برمجة تطبيقات إعدادات الموجّه إلى الإصدار v1، وأصبحت Responses API تدعم previous_response_id، كما عُزّز مسار طلبات منتقي نقاط النهاية لضمان الموثوقية والأداء وقابلية التوسع. ويتضمن الإصدار دليلًا للمُسرِّعات يراعي بنية النظام، خاصًا بـ DRA وDRANET.

تضيف خدمة الاستدلال المراعية للوكلاء مكوّنًا إضافيًا لإنتاج حالة الجلسة، وارتباطًا متطورًا بالجلسة لإبقاء المحادثات متعددة الأدوار قريبة من سياقها المخزّن مؤقتًا، إلى جانب جدولة تراعي أولوية الدور وحالة Responses API لمساعدة الوكلاء على إعادة استخدام السياق عبر الأدوار. ويوحّد الإصدار مكونات المشروع عند v1.0.0، ويضيف عناصر إلى المنظومة، منها تكامل مع ai-dynamo/modelexpress لتحميل أوزان النماذج من نظير إلى نظير، وحزمة llm-d-api-extensions، وأدوات التشخيص llm-d-pd-utils، كما يوقف تدريجيًا إنشاء صور الحاويات الخاصة بالمشروع llm-d-rocm. وتتضمن صور خوادم النماذج إصدارات مبنية من vLLM وSGLang لمختلف أنواع المُسرِّعات، وأصبح دليل فصل التمهيد عن فك الترميز يشترط LeaderWorkerSet v0.11.1 أو إصدارًا أحدث، مع تفعيل واجهة DisaggregatedSet API.

التقنيات الأساسية والتحكم في التدفق

منذ إطلاق المشروع، انصب تركيزه على خمسة أساليب لتحسين الاستدلال: التوجيه المراعي لذاكرة التخزين المؤقت للبادئات، الذي يوجّه الطلب إلى بنية تحتية قد تحتفظ بسياقه المشترك؛ وإلغاء تحميل ذاكرة التخزين المؤقت لمفاتيح وقيم KV، بنقل المعلومات المخزنة مؤقتًا بين موارد وحدات معالجة الرسومات ووحدات المعالجة المركزية والتخزين؛ وتحسين الاستدلال على دفعات؛ وفصل التمهيد عن فك الترميز، أي فصل قراءة الموجّه عن إنشاء الاستجابة؛ والتوازي الواسع للخبراء، الذي يوزع نماذج مزيج الخبراء الكبيرة على عدد كبير من المُسرِّعات. وهذه التقنيات سبقت الإصدار 1.0؛ ووفقًا لـ IBM، يتمثل الجديد في دمجها وما أُحيطت به من نضج تشغيلي، وفي انضباط عمليات اليوم الثاني الذي يحافظ على الأداء عند تغير حركة المرور، أو تعطل الأجهزة، أو تحديث البرمجيات، أو تنافس مستخدمين مختلفين على الموارد نفسها.

يُفترض أن يحول التحكم في التدفق والإنصاف وتحديد الأولويات، ضمن الإصدار 1.0، دون أن تطغى أحمال العمل المتدفقة على نحو مفاجئ على الخدمات الحساسة لزمن الاستجابة، سواء تشاركت هذه الأحمال الأجهزة نفسها أو امتدت عبر مزيج من المُسرِّعات. كما يمكن إبقاء الطلبات مرتبطة بالبنية التحتية المناسبة عبر أدوار متعددة للحفاظ على دفء ذاكرات البادئات المؤقتة. ويعمل llm-d مع محركات الاستدلال مثل vLLM أو SGLang، مضيفًا إمكانات التوجيه الموزع والتشغيل إلى هذه المحركات. وقال ستيفن وات، نائب الرئيس في مكتب كبير مسؤولي التكنولوجيا لدى Red Hat، إن llm-d يوحّد منظومتَي PyTorch وCNCF من خلال توفير تنسيق أصلي لـ Kubernetes مباشرةً لـ vLLM ومحركات الاستدلال الحديثة.

النتائج المعروضة والتكاليف المعلنة

في منشور عن الاختبارات المعيارية نُشر في 22 يوليو 2026، قاس المشروع أداء تقديم الخدمة الوكيلية لنموذج GLM-5.2، ووصفه المنشور بأنه نموذج مزيج من الخبراء يضم 744 مليار مُعامل، منها 39 مليار مُعامل نشط، ويتألف من 78 طبقة. واستند تحليل عبء العمل إلى 219 جلسة إنتاجية من Claude Code، بلغ فيها وسيط عدد رموز الإدخال في طلب الوكيل الرئيسي 195 ألفًا، وأعاد 317 رمزًا للإخراج، كما أعادت 96% من جولات الوكيل الرئيسي استخدام 90% على الأقل من مدخلاتها. ويذكر المنشور أن التوجيه المراعي للبادئات استعاد 96–97% من إعادة استخدام الذاكرة المؤقتة التي أتاحها عبء العمل. وبافتراض أن تكلفة استئجار H200 تبلغ 2.71 دولار لكل ساعة تشغيل لوحدة GPU، يقدّر المنشور تكلفة تقديم الخدمة المستضاف ذاتيًا، وفق تخطيطين يستخدم كل منهما 64 وحدة GPU، بنحو 0.05 إلى 0.08 دولار لكل مليون رمز إدخال، و1.92 إلى 3.55 دولار لكل مليون رمز إخراج. ويذكر المؤلفون أن هذه الأرقام تشمل تكلفة استئجار وحدات GPU فقط، وتفترض استمرار الحمل.

في عرض توضيحي منفصل، نشرت IBM وRed Hat نموذج GLM-5.2 على 544 وحدة GPU من طراز NVIDIA H100. ووصف حساب IBM Research النموذج بأنه مفتوح الأوزان، ويضم نحو 753 مليار مُعامل، منها قرابة 39 مليار مُعامل نشط. وتفيد IBM بأن النشر حقق، في ذروة الأداء، أكثر من 6.6 ملايين رمز إخراج في الدقيقة، مع خدمة ما يصل إلى 3,000 وكيل برمجة متزامن من دون أي استباقات، وأن نقطة التشغيل عند 2,500 وكيل حافظت على معدل 7,612 طلبًا في الدقيقة. وتقول IBM إن استضافة GLM-5.2 ذاتيًا على وحدات H100 GPU باستخدام llm-d تكلف، وفق أسعار استئجار الخدمات السحابية الحالية، أقل من التسعير التجاري المكافئ لواجهات API بمقدار يتراوح بين 5 و10 أضعاف لكل رمز. وقال مارون أيوب، وهو مهندس رئيسي أول للتعلم الآلي ضمن فريق هندسة الاستدلال في Red Hat: «إن تقديم الخدمة لآلاف الوكلاء المتزامنين من دون استباقات يمنح المشغّلين سبيلًا موثوقًا للانتقال من نتيجة اختبار معياري إلى نشر إنتاجي».

وبحسب الحساب نفسه، أنجز مستوى البيانات المفكك 6.2 ملايين عملية نقل لذاكرة التخزين المؤقت KV، بمتوسط 2.71 GiB لكل عملية نقل، من دون أي إخفاق في النقل؛ كما اكتملت جميع الاختبارات المعيارية من دون أخطاء في تقديم الخدمة.