وحدات معالجة الرسوميات المجزأة في Kubernetes

نظرة عامة

أدت ثورة الذكاء الاصطناعي التوليدي (GenAI) إلى زيادة هائلة في الطلب على وحدات معالجة الرسوميات (GPUs) في جميع أنحاء الصناعة. ترغب الشركات في تدريب النماذج اللغوية الكبيرة (LLMs) وضبطها ونشرها بكميات هائلة. وقد أدى ذلك إلى انخفاض التوفر وارتفاع أسعار أحدث وحدات معالجة الرسوميات. عانت الشركات التي تشغل أعباء العمل على السحابة العامة من ارتفاع الأسعار وزيادة عدم اليقين بشأن توفر وحدات معالجة الرسوميات.

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

خيارات مشاركة وحدات معالجة الرسوميات

لمشاركة وحدة معالجة رسوميات واحدة مع أعباء عمل متعددة في Kubernetes، هذه هي الخيارات المتاحة لدينا -

MIG

تتيح تقنية Multi-Instance GPU (MIG) تقسيم وحدات معالجة الرسوميات المستندة إلى معمارية NVIDIA Ampere (مثل NVIDIA A100) بشكل آمن إلى مثيلات GPU منفصلة لتطبيقات CUDA. كل قسم معزول تمامًا من حيث الذاكرة والحوسبة ويمكن أن يوفر إنتاجية وزمن انتقال يمكن التنبؤ بهما.

يمكن تقسيم وحدة معالجة رسوميات NVIDIA A100 واحدة إلى ما يصل إلى 7 مثيلات GPU معزولة. يظهر كل قسم كوحدة معالجة رسوميات منفصلة للبرامج التي تعمل على عقدة مقسمة. وحدات معالجة الرسوميات الأخرى المدعومة بتقنية MIG وعدد الأقسام المدعومة مدرجة هنا.
مزيد من المعلومات هنا

الإيجابيات

• عزل كامل للحوسبة والذاكرة يمكن أن يدعم زمن انتقال وإنتاجية يمكن التنبؤ بهما
• nvidia-device-pluginلـ Kubernetes يدعم MIG بشكل أصلي

السلبيات

• مدعوم فقط لوحدات معالجة الرسوميات الحديثة مثل A100 و H100 و A30. وهذا يحد من الخيارات المتاحة.
• عدد الأقسام له حد أقصى صارم يبلغ 7 لمعظم البنى. وهذا قليل جدًا إذا كنا نشغل أعباء عمل أصغر بمتطلبات ذاكرة ومعالجة محدودة.

تقسيم الوقت

يتيح تقسيم الوقت جدولة أعباء عمل متعددة على نفس وحدة معالجة الرسوميات (GPU). يتم مشاركة وقت المعالجة بين العمليات المتعددة وتتداخل العمليات زمنيًا. يمكن لمسؤول المجموعة تهيئة مجموعة أو عقدة للإعلان عن عدد معين من النسخ المتماثلة/وحدة معالجة الرسوميات، مما يعيد تهيئة العقد وفقًا لذلك.

المزايا

• لا يوجد حد أقصى لعدد الحاويات (pods) التي يمكنها مشاركة وحدة معالجة رسوميات واحدة
• يمكن أن يعمل مع الإصدارات الأقدم من وحدات معالجة الرسوميات من NVIDIA

العيوب

• لا يوجد عزل للذاكرة أو الأخطاء. لا توجد طريقة مدمجة للتأكد من أن عبء العمل لا يتجاوز الذاكرة المخصصة له.
• يوفر تقسيم الوقت وقتًا متساويًا لجميع العمليات الجارية. يمكن لحاوية (pod) تشغل عمليات متعددة أن تستحوذ على وحدة المعالجة المركزية (CPU) أكثر بكثير مما هو مقصود.

هناك خيارات أخرى متاحة لنا لمشاركة وحدة معالجة الرسوميات مثل MPS وvGPUs، لكنها لا تحظى بدعم أصلي في `nvidia-device-plugin` ولن نناقشها هنا.

عرض توضيحي لتقسيم الوقت

دعنا نستعرض بإيجاز كيفية الاستفادة من مشاركة الوقت على خدمة Azure Kubernetes. نبدأ بمجموعة Kubernetes موجودة بالفعل.

1. أضف تجمع عقد (node pool) يدعم وحدات معالجة الرسوميات (GPU) في المجموعة

 
$ az aks nodepool add \
    --name <nodepool-name> \
    --resource-group <resource-group-name> \
    --cluster-name <cluster-name> \
    --node-vm-size Standard_NC4as_T4_v3 \
		--node-count 1

‍‍سيؤدي هذا إلى إضافة تجمع عقد جديد بعقدة واحدة إلى مجموعة AKS الموجودة مع وحدة معالجة رسوميات NVIDIA T4 واحدة. يمكن التحقق من ذلك بتشغيل ما يلي

 
$ kubectl get nodes <gpu-node-name> -o 'jsonpath={.status.allocatable.nvidia\.com\/gpu}'

2. قم بتثبيت عامل تشغيل وحدة معالجة الرسوميات (GPU operator)

$ helm repo add nvidia https://helm.ngc.nvidia.com/nvidia \
	&& helm repo update
$ helm install gpu-operator nvidia/gpu-operator \
-n gpu-operator --create-namespace \
--set driver.enabled=false \
--set toolkit.enabled=false \
--set operator.runtimeClass=nvidia-container-runtime

3. بمجرد تثبيت عامل التشغيل، نقوم بإنشاء تهيئة لتقسيم الوقت ونهيئ المجموعة بأكملها لتقسيم موارد وحدة معالجة الرسوميات حيثما تكون متاحة‍‍

$ kubectl apply -f - <<EOF
apiVersion: v1
kind: ConfigMap
metadata:
  name: time-slicing-config
data:
  any: |-
    version: v1
    flags:
      migStrategy: none
    sharing:
      timeSlicing:
        renameByDefault: false
        failRequestsGreaterThanOne: false
        resources:
          - name: nvidia.com/gpu
            replicas: 10
EOF

# Reconfigure gpu operator to pick up the config map
$ kubectl patch clusterpolicy/cluster-policy \
-n gpu-operator --type merge \
-p '{"spec": {"devicePlugin": {"config": {"name": "time-slicing-config", "default": "any"}}}}'

4. تحقق من أنه قد تم إعادة تكوين العقدة الموجودة بنجاح.‍

$ kubectl get nodes <gpu-node-name> -o 'jsonpath={.status.allocatable.nvidia\.com\/gpu}'
10

5. يمكننا التحقق من التكوين عن طريق إنشاء نشر (deployment) بـ 4 نسخ متماثلة، تطلب كل منها 2 من موارد nvidia.com/gpu.

$ kubectl apply -f - <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: time-slicing-verification
  labels:
    app: time-slicing-verification
spec:
  replicas: 4
  selector:
    matchLabels:
      app: time-slicing-verification
  template:
    metadata:
      labels:
        app: time-slicing-verification
    spec:
      tolerations:
        - key: nvidia.com/gpu
          operator: Exists
          effect: NoSchedule
      hostPID: true
      containers:
        - name: cuda-sample-vector-add
          image: "nvcr.io/nvidia/k8s/cuda-sample:vectoradd-cuda11.7.1-ubuntu20.04"
          command: ["/bin/bash", "-c", "--"]
          args:
            - while true; do /cuda-samples/vectorAdd; done
          resources:
           limits:
             nvidia.com/gpu: 1
EOF

تحقق من أن جميع حاويات (pods) هذا النشر قد بدأت العمل على نفس العقدة التي تم إنشاؤها بالفعل وأنها كانت قادرة على استيعابها.

الخاتمة

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