Kubernetes لتنسيق وحدات GPU: إدارة مجموعات تضم آلاف وحدات GPU

تدير OpenAI نظام 25,000 وحدة GPU على Kubernetes بمعدل استخدام 97%. أتقن جدولة GPU والوعي بالطوبولوجيا والتوسع إلى ما بعد 5,000 عقدة.

Kubernetes لتنسيق وحدات GPU: إدارة مجموعات تضم آلاف وحدات GPU

Kubernetes لتنسيق وحدات GPU: إدارة مجموعات تضم آلاف وحدات GPU

آخر تحديث: 8 ديسمبر 2025

تحديث ديسمبر 2025: أصبح Dynamic Resource Allocation (DRA) في Kubernetes 1.31+ متاحاً للإنتاج، مما يتيح تقسيم GPU الدقيق والمشاركة الزمنية. يضيف NVIDIA GPU Operator 24.6+ دعم Blackwell وإدارة MIG المحسّنة. يصل Kueue (نظام قوائم انتظار الوظائف الأصلي في Kubernetes) إلى مرحلة النضج الإنتاجي لأحمال عمل الذكاء الاصطناعي. تُظهر Run:ai و CoreWeave مجموعات تضم أكثر من 50,000 وحدة GPU على Kubernetes. تتيح أدوات الاتحاد متعدد المجموعات (Liqo، Admiralty) تنسيق GPU عبر السحابات المتعددة. يتحسن دعم vGPU لنشر الاستدلال متعدد المستأجرين.

تدير OpenAI نظام 25,000 وحدة GPU عبر مجموعات Kubernetes متعددة لتدريب نماذج GPT، باستخدام مشغّلات مخصصة تتعامل تلقائياً مع أعطال GPU، وتعيد توازن أحمال العمل في الوقت الفعلي، وتحافظ على معدل استخدام 97% على الرغم من حدوث أعطال الأجهزة كل 2.5 ساعة في المتوسط.¹ اكتشف فريق البنية التحتية للشركة أن Kubernetes القياسي ينهار عند حوالي 5,000 عقدة دون تعديلات واسعة، مما أجبرهم على تنفيذ اتحاد مجموعات هرمي، وخوارزميات جدولة مخصصة، وتحجيم تلقائي واعٍ بـ GPU يتعامل مع كل H100 بقيمة 30,000 دولار كمورد ثمين يتطلب تتبعاً فردياً. تختلف إدارة GPU على نطاق واسع اختلافاً جوهرياً عن تنسيق CPU — فعطل GPU أثناء التدريب الموزع يمكن أن يهدر ملايين الدولارات من وقت الحوسبة، بينما الجدولة السيئة التي تفصل وحدات GPU المتصلة عبر NVLink تسبب تدهوراً في الأداء بمقدار 8 أضعاف. تُبلغ المؤسسات التي تدير آلاف وحدات GPU بنجاح على Kubernetes عن استخدام أفضل بنسبة 35%، وأوقات نشر أسرع بنسبة 60%، وتقليل في النفقات التشغيلية بنسبة 90% مقارنة بالإدارة على الخوادم المعدنية.²

يهيمن Kubernetes على تنسيق الحاويات بحصة سوقية 88%، لكن دعم GPU جاء متأخراً ويظل تحدياً على نطاق واسع.³ أحضر NVIDIA GPU Operator، الذي أُطلق في 2019، أخيراً إدارة GPU بمستوى المؤسسات إلى Kubernetes، مما أتاح ميزات مثل تثبيت برنامج التشغيل الديناميكي، ونشر إضافات الأجهزة التلقائي، ومراقبة صحة GPU. يجب على المؤسسات التي تشغّل أحمال عمل الذكاء الاصطناعي على Kubernetes التنقل بين تكوينات إضافات الأجهزة، وقواعد تقارب العقد، والجدولة الواعية بالطوبولوجيا، وحصص الموارد التي تمنع الفرق الفردية من احتكار موارد GPU. ومع ذلك، فإن أولئك الذين يتقنون Kubernetes لتنسيق GPU يكتسبون القدرة على التعامل مع آلاف وحدات GPU كمجموعة موارد واحدة قابلة للبرمجة، محققين معدلات استخدام وكفاءة تشغيلية مستحيلة مع مجدولات HPC التقليدية.

بنية إضافات أجهزة GPU

يتيح إطار عمل إضافات الأجهزة في Kubernetes اكتشاف GPU وتخصيصه ومراقبة صحته عبر المجموعات:

إضافة جهاز NVIDIA GPU تعمل كواجهة أساسية بين Kubernetes ووحدات NVIDIA GPU.⁴ تعمل الإضافة كـ DaemonSet على كل عقدة GPU، مسجّلةً وحدات GPU كموارد قابلة للجدولة مع kubelet. أثناء التهيئة، تستعلم الإضافة من NVIDIA Management Library (NVML) لاكتشاف وحدات GPU المتاحة، وسعة ذاكرتها، وقدرتها الحسابية، وطوبولوجيا الربط البيني. تُعلن الإضافة عن وحدات GPU للمجدول في Kubernetes باستخدام اسم المورد nvidia.com/gpu، مما يتيح للـ pods طلب وحدات GPU من خلال مواصفات الموارد القياسية.

تدفق تسجيل إضافة الجهاز: 1. تبدأ الإضافة وتكتشف وحدات GPU المحلية عبر NVML 2. تسجّل مع kubelet من خلال مقبس Unix في /var/lib/kubelet/device-plugins/ 3. تُعلن عن وحدات GPU المتاحة بمعرّفات أجهزة فريدة 4. تنفّذ Allocate() RPC لتعيين GPU للحاوية 5. تراقب صحة GPU وتُبلغ عن الأعطال إلى kubelet 6. تتعامل مع تنظيف GPU أثناء إنهاء pod

دعم Multi-Instance GPU (MIG) يتيح تقسيم وحدات A100 و H100 GPU إلى حالات معزولة.⁵ تظهر كل حالة MIG كوحدة GPU منفصلة لـ Kubernetes، مما يسمح بتخصيص موارد دقيق. تدير إضافة الجهاز ملفات تعريف MIG، وتتعامل مع إنشاء وحذف وتعيين الحالات. تحقق المؤسسات استخداماً أفضل لـ GPU بمقدار 7 أضعاف من خلال تقسيم وحدات GPU غير المستغلة بالكامل لأحمال العمل الأصغر. يتطلب تكوين MIG تخطيطاً دقيقاً حيث لا يمكن تغيير أوضاع التقسيم دون استنزاف العقد.

إضافات الأجهزة البديلة توفر تنوعاً في البائعين: - إضافة جهاز AMD تدعم وحدات GPU المُمكّنة بـ ROCm مثل MI250X - إضافة جهاز Intel تدير وحدات Intel GPU ومسرّعات Gaudi - إضافة جهاز Xilinx FPGA تنسّق موارد FPGA - إضافة جهاز Google TPU لمجموعات GKE

استراتيجيات الجدولة لأحمال عمل GPU

تعمل الجدولة الفعّالة لـ GPU على تعظيم الاستخدام مع الحفاظ على الأداء:

الجدولة الجماعية (Gang Scheduling) تضمن أن وظائف التدريب الموزعة تتلقى جميع وحدات GPU المطلوبة في وقت واحد. بدون الجدولة الجماعية، يسبب التخصيص الجزئي للموارد حالة جمود — تنتظر الوظائف إلى الأبد للحصول على وحدات GPU المتبقية التي لا تصبح متاحة أبداً. تنفّذ إضافات مجدول Kubernetes مثل Volcano و Apache YuniKorn الجدولة الجماعية من خلال PodGroups.⁶ تحدد الوظائف الحد الأدنى من متطلبات GPU، ويقوم المجدول إما بتخصيص جميع الموارد أو وضع الوظيفة بأكملها في قائمة الانتظار. تقلل الجدولة الجماعية من استخدام المجموعة بنسبة 10-15% لكنها تمنع تجويع وظائف التدريب.

الجدولة الواعية بالطوبولوجيا تحسّن وضع GPU بناءً على الروابط البينية للأجهزة. تحقق وحدات GPU المتصلة عبر NVLink عرض نطاق ترددي 600GB/s مقابل 32GB/s عبر PCIe.⁷ يفحص المجدول طوبولوجيا العقدة لوضع pods المرتبطة على وحدات GPU ذات الروابط البينية السريعة. يضع NVIDIA GPU Feature Discovery علامات على العقد بمعلومات الطوبولوجيا مما يتيح قواعد التقارب. تسبب قرارات الطوبولوجيا السيئة تدهوراً في الأداء بمقدار 3-8 أضعاف لأحمال العمل كثيفة الاتصال. يصبح الوعي بالطوبولوجيا حاسماً لما بعد 8 وحدات GPU لكل وظيفة.

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

الأولوية والاستباق: تتلقى أحمال العمل الإنتاجية أولوية أعلى من وظائف التطوير. يستبق المجدول pods ذات الأولوية الأقل عندما تصبح الموارد شحيحة. يمنع التكوين الدقيق للأولوية وظائف البحث من حجب الاستدلال الإنتاجي. يضمن الاستباق مع نقاط الفحص عدم فقدان تقدم التدريب. تتراوح فئات الأولوية من الحرجة للنظام (1000000) إلى التطوير (100).

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

اعتبارات التوسع

يتطلب توسيع Kubernetes إلى آلاف وحدات GPU تعديلات معمارية:

قيود حجم المجموعة: تدعم مجموعات Kubernetes الفردية 5,000 عقدة كحد أقصى قبل أن يتدهور أداء etcd.⁸ يزداد حمل خادم API بشكل تربيعي مع عدد العقد بسبب آليات المراقبة. تتباطأ حلقات مصالحة مدير وحدة التحكم بعد 1,000 عقدة. تصبح سياسات الشبكة صعبة الإدارة على نطاق واسع. تحدّ معظم المؤسسات المجموعات بـ 500-1,000 عقدة GPU للاستقرار التشغيلي.

اتحاد المجموعات المتعددة: تستخدم النشرات الكبيرة مجموعات Kubernetes متعددة تُدار من خلال الاتحاد. يتيح Admiralty أو Virtual Kubelet الجدولة عبر المجموعات. تزامن أدوات GitOps مثل Flux أو ArgoCD التكوينات عبر المجموعات. توفر تقنيات شبكة الخدمات اتصال الشبكة عبر المجموعات. يضيف الاتحاد تعقيداً لكنه يتيح التوسع الأفقي إلى ما بعد حدود المجموعة الواحدة.

إدارة الموارد الهرمية: نظّم المجموعات هرمياً مع مجموعات إدارة تتحكم في مجموعات أحمال العمل. تشغّل مجموعات الإدارة مكونات مستوى التحكم ومنطق الجدولة. تستضيف مجموعات أحمال العمل pods GPU دون وحدات تحكم معقدة. يقلل التصميم الهرمي من نطاق تأثير الأعطال. يبسّط الفصل الواضح للمسؤوليات استكشاف الأخطاء وإصلاحها.

تعريفات الموارد المخصصة (CRDs) لأحمال عمل الذكاء الاصطناعي: - TrainingJob: يحدد مواصفات التدريب الموزع - InferenceService: يدير نشرات خدمة النموذج - GPUPool: يمثل تجميعات GPU المنطقية - Checkpoint: يتعامل مع استمرارية حالة التدريب - ModelVersion: يتتبع تكرارات النموذج وسلالته

تحسينات الأداء للتوسع: - تعطيل webhooks القبول غير المستخدمة لتقليل تأخر API - تنفيذ قيود انتشار طوبولوجيا pod للتوزيع المتساوي - استخدام SSD محلي لصور الحاويات لتجنب عنق زجاجة الشبكة - تمكين مدير CPU لتخصيص CPU المضمون - تكوين huge pages لمتطلبات ذاكرة النموذج الكبير

المراقبة والرصد

تمنع المراقبة الشاملة وقت خمول GPU بملايين الدولارات:

NVIDIA Data Center GPU Manager (DCGM) يوفر مقاييس خاصة بـ GPU غير متوفرة من خلال مراقبة Kubernetes القياسية.⁹ يصدّر DCGM أكثر من 100 مقياس بما في ذلك استخدام SM، وعرض نطاق الذاكرة، ودرجة الحرارة، واستهلاك الطاقة، وأخطاء ECC. يتيح التكامل مع Prometheus تخزين المقاييس طويل المدى والتنبيه. تصوّر لوحات معلومات Grafana أداء GPU عبر الأسطول بأكمله. تكتشف التنبيهات المخصصة وحدات GPU غير المستغلة بالكامل، والاختناق الحراري، وتدهور الأجهزة قبل حدوث الأعطال.

مقاييس GPU الرئيسية لمراقبة Kubernetes: - استخدام GPU: نسبة SMs النشطة (الهدف >90%) - استخدام الذاكرة: ذاكرة GPU المخصصة مقابل المتاحة - استهلاك الطاقة: الفعلي مقابل TDP مما يشير إلى الاختناق - درجة الحرارة: درجات حرارة GPU والذاكرة - عرض نطاق PCIe: معدلات نقل البيانات من وإلى GPU - حركة NVLink: عرض نطاق الاتصال بين وحدات GPU - مقاييس التدريب: منحنيات الخسارة، معايير التدرج، معدلات التعلم - مقاييس الاستدلال: الطلبات في الثانية، تأخر P99، أحجام الدفعات

التتبع الموزع يتتبع الطلبات عبر وحدات GPU والعقد المتعددة. يلتقط أداة OpenTelemetry أوقات خطوات التدريب، وتأخر تحميل البيانات، ومدد نقاط الفحص. يوفر Jaeger أو Tempo تخزين وتحليل التتبع الموزع. يحدد الربط بين التتبعات والمقاييس عنق الزجاجة في الأداء. تقلل الرؤية الشاملة متوسط وقت الحل بنسبة 70%.

تجميع السجلات يركّز السجلات من آلاف pods GPU. يجمع Fluentd أو Fluent Bit سجلات الحاويات بأقل حمل. يخزّن Elasticsearch السجلات مع فهرسة تلقائية وسياسات استبقاء. يتيح Kibana البحث في السجلات وتحليلها عبر المجموعة بأكملها. يبسّط التسجيل المنظم بتنسيقات متسقة استكشاف الأخطاء وإصلاحها. التنبيه على أنماط الأخطاء التي تشير إلى مشكلات نظامية.

تنشر Introl وتدير مجموعات Kubernetes لتنسيق GPU عبر منطقة التغطية العالمية الخاصة بنا، مع خبرة في التوسع إلى أكثر من 10,000 نشر GPU.¹⁰ نفّذت فرق هندسة المنصات لدينا مشغّلات مخصصة وتحسينات جدولة للاستخدام الأمثل لـ GPU.

أنماط النشر الإنتاجي

بنية مجموعة التدريب في Anthropic: - النطاق: 4,000 وحدة GPU عبر 8 مجموعات Kubernetes - الطوبولوجيا: اتحاد هرمي مع مجدول مركزي - التخزين: نظام ملفات Lustre الموزع لبيانات التدريب - الشبكات: نسيج RoCE v2 بسرعة 200Gbps لكل عقدة - الجدولة: مجدول جماعي مخصص مع وعي بالطوبولوجيا - المراقبة: DCGM + Prometheus مع فترات جمع 15 ثانية - النتيجة: استخدام GPU بنسبة 94%، تقليل وقت التدريب بنسبة 50%

منصة الاستدلال في Uber: - حمل العمل: 500 مليون تنبؤ يومياً - البنية التحتية: 2,000 وحدة T4 GPU عبر 20 منطقة - التنسيق: Kubernetes مع Knative للحوسبة بدون خوادم - التحجيم التلقائي: تحجيم تنبؤي بناءً على أنماط حركة المرور - موازنة الحمل: وكيل Envoy مع توجيه أقل تأخر - التحسين: تخزين النماذج مؤقتاً يقلل البداية الباردة إلى ثانيتين - النتيجة: تقليل التكلفة بنسبة 65% مقابل البنية السابقة

التدريب والاستدلال الهجين في Spotify: - وحدات GPU: أسطول مختلط من 3,000 وحدة V100/A100/T4 - الجدولة: مشاركة مقسّمة زمنياً للتطوير - العزل: حاويات Kata للأمان متعدد المستأجرين - Cos

[تم اقتطاع المحتوى للترجمة]

طلب عرض سعر_

أخبرنا عن مشروعك وسنرد خلال 72 ساعة.

> TRANSMISSION_COMPLETE

تم استلام الطلب_

شكراً لاستفسارك. سيقوم فريقنا بمراجعة طلبك والرد خلال 72 ساعة.

QUEUED FOR PROCESSING