جدولة المهام لمجموعات الذكاء الاصطناعي: SLURM، وKubernetes، وRay، ومعرفة متى لا تحتاج إلى أي منها

يُحدد مُجدول المهام أي مهمة تُنفذ على أي وحدة معالجة رسومية، ومتى، وعلى من يتحمل التكلفة. بدون مُجدول، يتحول نظام الحوسبة المشتركة إلى مجرد تبادل رسائل بين المستخدمين على منصة سلاك للاستفسار عما إذا كان أي منهم يستخدم العقدة رقم 3. أما مع المُجدول غير المناسب، فستُهدر ساعات عمل المهندسين على ملفات YAML أكثر من العمل على النماذج.

تقارن هذه المقالة بين أدوات جدولة المهام التي يختارها المستخدمون فعليًا - SLURM، وKubernetes (مع Kueue أو Volcano)، وRay وKubeRay، والخيارات التجارية Run:ai وDetermined - وتتناول بصراحة الحالة التي يكون فيها الخيار الأمثل هو "لا شيء، فقط SSH". وقد قرأ الجمهور كيه01 , كيه02 و كيه03 وهو الآن بصدد تحديد ما سيضعه فوق مجموعة من 1 إلى 32 عقدة.

ما يفعله المجدول فعلياً

ثلاث مهام، مرتبة تقريبًا حسب صعوبتها: وضع العمل على الموارد المتاحة، ووضع العمل الذي لم يُدرج بعد في قائمة الانتظار، وتنسيق مهام متعددة العقد - يتطلب التدريب الموزع أن تبدأ جميع الرتب N في وقت واحد (جدولة عمل المجموعة), لأن PyTorch dist.barrier() يتم حظرها إلى أجل غير مسمى إذا لم تظهر رتبة واحدة أبدًا (انظر كيه06 ).

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

الانقسام الكبير: مهام الدفعات مقابل الخدمات طويلة الأمد

هذا هو الإطار الأكثر أهمية على الإطلاق. وظائف الدفعات قم بالتدريب لمدة 8 ساعات ثم اخرج، أو قم بتشغيل مسح المعلمات الفائقة لـ 200 مهمة قصيرة، أو قم بمعالجة مجموعة بيانات طوال الليل - ابدأ، وانتهي، واحصل على النتيجة، لا شيء يجيب على HTTP. خدمات طويلة الأمد هي نقطة نهاية vLLM تخدم الاستدلال على مدار الساعة طوال أيام الأسبوع، وقاعدة بيانات ذاكرة المشهد، ومجموعة مراقبة - من المفترض أن تظل تعمل إلى الأبد، وتعيد التشغيل عند حدوث عطل.

صُممت SLURM لمعالجة البيانات على دفعات. وصُممت Kubernetes للخدمات طويلة الأمد. أما باقي الأنظمة فهي عبارة عن استخدام أحد النظامين لأداء النصف الآخر.

إذا كانت مجموعتك تقوم بأحد هذين الأمرين فقط، فالخيار سهل. أما إذا كانت تقوم بالأمرين معاً - وهو أمر شائع بشكل متزايد - فالسؤال هو أي مُجدوِل أنت على استعداد لدفع التكلفة التشغيلية له.

SLURM - الخيار الافتراضي للحوسبة عالية الأداء الذي لا يزال الأفضل للتدريب الخالص

يُشغّل برنامج SLURM أكثر من 65% من أجهزة الكمبيوتر العملاقة ضمن قائمة أفضل 500 جهاز، ويُشغّل معظم عمليات التدريب الرائدة المنشورة. بالنسبة لأعباء العمل التي تبدو وكأنها "إرسال مهمة تدريبية، انتظار النتائج، الحصول على نقطة التحقق"، فقد كان هو الحل الأمثل على مدى عشرين عامًا.

النموذج الذهني بسيط: أ تقسيم هي مجموعة عقد مُسماة (gpu-5090, cpu-only, bigmem); أ وظيفة هو برنامج نصي شل مع #SBATCH التوجيهات، المقدمة مع sbatch; جريس (الموارد العامة) تتبع وحدات معالجة الرسومات (GPUs) — --gres=gpu:rtxpro6000:2 يطلب بطاقتين محددتين؛ جدولة عمل المجموعة مدمج.

الحد الأدنى slurm.conf بالنسبة لمجموعة مكونة من 4 عقد مع 8 وحدات RTX Pro 6000 Blackwell لكل عقدة:

ClusterName=kentino-lab
SlurmctldHost=head01

SchedulerType=sched/backfill
SelectType=select/cons_tres
SelectTypeParameters=CR_Core_Memory
GresTypes=gpu

# GPU accounting — without these two lines, fair-share runs on CPU-seconds and is meaningless
AccountingStorageType=accounting_storage/slurmdbd
AccountingStorageTRES=gres/gpu
PriorityType=priority/multifactor
PriorityDecayHalfLife=7-0
PriorityWeightFairshare=10000
PriorityWeightAge=1000

# cgroups isolate the GPUs a job is allowed to see
ProctrackType=proctrack/cgroup

NodeName=node[01-04] CPUs=128 RealMemory=1024000 Sockets=2 \
    CoresPerSocket=64 ThreadsPerCore=1 Gres=gpu:rtxpro6000:8 State=UNKNOWN

PartitionName=train Nodes=node[01-03] Default=YES MaxTime=48:00:00 State=UP
PartitionName=interactive Nodes=node04 MaxTime=04:00:00 \
    PriorityTier=10 State=UP

المطابقة gres.conf على كل عقدة:

AutoDetect=nvml
NodeName=node[01-04] Name=gpu Type=rtxpro6000 File=/dev/nvidia[0-7]

AutoDetect=nvml يستعلم مباشرة عن مكتبة إدارة NVIDIA، ويلتقط شرائح MIG تلقائيًا، ويوفر عليك عناء إنشاء مسارات ملفات الجهاز يدويًا.

يقوم أحد المستخدمين بإرسال ما يلي:

#!/bin/bash
#SBATCH --job-name=qwen-finetune
#SBATCH --partition=train
#SBATCH --nodes=2
#SBATCH --ntasks-per-node=8
#SBATCH --gres=gpu:rtxpro6000:8
#SBATCH --time=12:00:00
#SBATCH --output=logs/%j.out

srun python -m torch.distributed.run \
    --nnodes=2 --nproc-per-node=8 \
    --rdzv-backend=c10d \
    --rdzv-endpoint=$(scontrol show hostnames | head -1):29500 \
    train.py --config configs/qwen72b.yaml

يتكامل PyTorch Elastic وSLURM بسلاسة: SLURM يمتلك التخصيص، srun يقوم بتشغيل عملية واحدة لكل مهمة، torch.distributed.run بالإضافة إلى ذلك، يتولى نظام الالتقاء الخلفي عملية تحديد الرتب. عند فقدان عقدة، --max-restarts on torchrun المزيد --requeue on #SBATCH يتعافى من نقطة التفتيش الأخيرة. الجميع يسلك هذا الطريق.

ما تحصل عليه مجانًا: جدولة المجموعات، وتخفيض الحصة العادلة، وإعادة التعبئة، والمحاسبة (كل ثانية من وحدة معالجة الرسومات يتم تسجيلها في sacct)، ودلالات بسيطة - لا توجد تعريفات موارد مخصصة، ولا وحدة تحكم، ولا مخطط كائنات YAML. ما لا تحصل عليه: خدمات طويلة الأمد مع إعادة تشغيل تلقائية، ودخول HTTP، وتحديثات متدرجة، وحاويات جانبية، وحالة تعريفية. SLURM هو مُجدول دفعات. معاملته مثل Kubernetes ستضر به.

يكون نظام SLURM صحيحًا عندما: تقوم بتشغيل التدريب، أو الاستدلال الدفعي، أو المحاكاة؛ ويكتب المستخدمون البرامج النصية؛ ويمكن لمهندس موثوقية الموقع بدوام جزئي تشغيله.

حيث يصل مشروع SLURM إلى أقصى حدوده

ثلاثة أماكن. خدمات على غرار الويب — لا يوجد مفهوم "التشغيل إلى الأبد، وإعادة التشغيل عند الموت، وكشف المنفذ 8000". يمكنك إدخال vLLM في مهمة SLURM طويلة الأمد، ولكن فحص الحالة والتحديثات المتدرجة وموازنة الأحمال ستصبح مشكلتك. أعباء عمل غير متجانسة — يفترض SLURM وجود مجموعة موارد واحدة؛ مجموعة تقوم بتشغيل التدريب + الاستدلال + Jupyter + المراقبة + إعداد البيانات تريد ضوابط أكثر دقة. عزل صارم بين المستأجرين المتعددين — تعمل مجموعات التحكم (cgroups) على عزل وحدة المعالجة المركزية والذاكرة؛ ويعتمد عزل وحدة معالجة الرسومات (GPU) على CUDA_VISIBLE_DEVICES ويجب أن يلتزم كود المستخدم بذلك. لا توجد مساحات أسماء، ولا سياسة شبكة لكل مهمة، ولا نظام تأجير على مستوى الحاويات. مناسب للمختبرات؛ غير مناسب لخدمة مستضافة متعددة العملاء.

عند مواجهة أي من هذه المشكلات، يكون الحل الأمثل عادةً هو إضافة طبقة ثانية - Kubernetes للخدمات - بدلاً من محاولة إصلاح SLURM. وتعتمد عروض CoreWeave المُدارة، SUNK و2026، على SLURM. on في نظام Kubernetes، تقوم نفس المجموعة بكلا الأمرين. أما على نطاق Kentino، فغالباً ما يكون استخدام مجموعتين صغيرتين منفصلتين أبسط.

Kubernetes للذكاء الاصطناعي: المسار السحابي الأصلي

صُممت Kubernetes للحفاظ على تشغيل خدمات الويب عديمة الحالة. أما بالنسبة لمجموعات الذكاء الاصطناعي، فيتم إضافة "كل شيء آخر" إليها. مجموعة التقنيات لعام 2026: مشغل GPU NVIDIA (برامج التشغيل، CUDA، NCCL، DCGM، ملحق الجهاز، تكوين MIG)، كويوي (طابور، حصة، قبول)، بركان (جدولة مُدركة للدفعات)، مدرب Kubeflow (PyTorchJob، TFJob، MPIJob CRDs)، كيوب راي (راي على K8s)، و كاربنتر أو أداة التوسيع التلقائي للمجموعات لتوفير العقد.

لماذا يُعدّ استخدام Kubernetes البسيط غير مناسب للذكاء الاصطناعي؟ يعتمد مُجدول kube الافتراضي على مبدأ FIFO دون أي دلالات للمجموعات. فهو يُشغّل 7 من أصل 8 وحدات (pods) لمهمة تدريب موزعة، ويترك الوحدة الثامنة في حالة انتظار بينما تُبقي الوحدات السبع الأخرى وحدات معالجة الرسومات (GPUs) في وضع الخمول. هذا ليس مجرد افتراض نظري، بل هو الخطأ الأكثر شيوعًا الذي ترتكبه فرق العمل عند محاولة تشغيل التدريب على مجموعة حاسوبية أنشأتها للاستدلال. يُمكن حل هذه المشكلة باستخدام Kueue (لقبول المهام على مستوى المهمة) وVolcano (لتحديد مواقع المجموعات على مستوى الوحدة). أفضل الممارسات الحالية هي استخدام كليهما: Kueue في الأعلى، وVolcano في الأسفل.

بركان

فولكانو هو مُجدول دفعات CNCF يتم تثبيته بجانب أو بدلاً من kube-scheduler. وهو يُضيف جدولة جماعية حقيقية مع minAvailable الدلالات (السماح بصفر أو N، وليس جزئيًا أبدًا)، وأولويات قائمة الانتظار والاستباق، واستراتيجيات المشاركة العادلة / التجميع الثنائي / الوعي بالطوبولوجيا، ودعم من الدرجة الأولى لـ PyTorchJob و TFJob و MPIJob و RayJob و SparkApplication.

قائمة انتظار قصيرة بالإضافة إلى مهمة تدريب PyTorch مجدولة جماعياً:

apiVersion: scheduling.volcano.sh/v1beta1
kind: Queue
metadata:
  name: training
spec:
  weight: 4
  capability:
    nvidia.com/gpu: 32
---
apiVersion: batch.volcano.sh/v1alpha1
kind: Job
metadata:
  name: qwen-finetune
spec:
  schedulerName: volcano
  minAvailable: 16          # gang: all 16 ranks or zero
  queue: training
  policies:
    - event: PodEvicted
      action: RestartJob
  tasks:
    - replicas: 16
      name: worker
      template:
        spec:
          containers:
            - name: pytorch
              image: kentino/pytorch:2.5-cuda13
              resources:
                limits:
                  nvidia.com/gpu: 1
              command: ["torchrun", "--nnodes=16", "--nproc-per-node=1", "train.py"]

عندما تفعل لست نحتاج إلى Volcano: مجموعة استدلالية خالصة تُشغّل عمليات نشر vLLM مستقلة. كل وحدة (pod) تمتلك وحدات معالجة الرسومات الخاصة بها، ولا يوجد تنسيق بين الوحدات، ومجدول kube الافتراضي مناسب. يُظهر Volcano كفاءته بمجرد دمج التدريب الموزع في المجموعة.

نظام الاقتراض القائم على نظام الحصص والترتيب

يتعامل Kueue مع طبقة لا يتعامل معها Volcano: من يُسمح له باستهلاك أي جزء من المجموعة، وماذا يحدث عندما يكون أحد الفرق خاملاً.

apiVersion: kueue.x-k8s.io/v1beta1
kind: ResourceFlavor
metadata:
  name: rtxpro6000
spec:
  nodeLabels:
    nvidia.com/gpu.product: "RTX-PRO-6000-Blackwell"
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: ClusterQueue
metadata:
  name: team-research
spec:
  cohort: "shared-gpu"
  resourceGroups:
    - coveredResources: ["nvidia.com/gpu"]
      flavors:
        - name: rtxpro6000
          resources:
            - name: "nvidia.com/gpu"
              nominalQuota: 16
              borrowingLimit: 8

يحصل كلا الفريقين في المجموعة على 16 وحدة معالجة رسومية مضمونة، ويمكنهما استعارة ما يصل إلى 8 وحدات من مجموعة الوحدات غير المستخدمة لدى الفريق الآخر. وتُعطى الأولوية للمهام ذات الأولوية العالية على السعة المستعارة. وتركز خارطة طريق Kueue لعام 2026 على MultiKueue (توزيع متعدد المجموعات) والاستباق التعاوني - حيث يمكن إخبار مهمة حفظ نقطة التفتيش "بحفظ الحالة والتوقف خلال 60 ثانية" بدلاً من إنهائها بشكل كامل.

مشاركة MIG و GPU

يستخدم مُلحق جهاز NVIDIA افتراضيًا تخصيصًا كاملًا لوحدة معالجة الرسومات. وهذا صحيح للتدريب والاستدلال واسع النطاق؛ أما للاستدلال صغير النطاق، أو دفاتر الملاحظات، أو أعمال التطوير، فهو مُهدر للموارد. ثلاثة أوضاع للمشاركة: MIG (ذاكرة الأجهزة وعزل الأعطال، والاستدلال متعدد المستأجرين في بيئة الإنتاج)، MPS (تعاوني، بدون عزلة)، تقسيم الوقت (بدون عزل، مخصص للمطورين فقط).

توجد تقنية MIG على H100/H200 و A100 و B200 - وليست موجودة على أي وحدة معالجة رسومات في تشكيلة Kentino. لا تدعم بطاقات RTX 5090 و RTX 4090 و RTX Pro 6000 Blackwell و L40 و L4 تقنية MIG. إذا كان تصميمك يتطلب أقسامًا معزولة لوحدة معالجة الرسومات، فإن ذلك يُقيد خياراتك من الأجهزة بمكونات SXM/مراكز البيانات التي لا تُصنّعها شركة Kentino. يُعلن تقسيم الوقت عن عدد N من وحدات معالجة الرسومات الافتراضية لكل وحدة معالجة رسومات فعلية، ولا يعلم المُجدول بوجود فائض في استخدامها - استخدمه لأغراض التطوير فقط.

ما يُجيده Kubernetes: خدمات الاستدلال طويلة الأمد (عمليات نشر vLLM المُوسّعة بواسطة HPA بناءً على عمق قائمة الانتظار، والتحديثات المتدرجة، وفحوصات السلامة - لا يوجد ما يُضاهيها في SLURM)، وأحمال العمل غير المتجانسة على مجموعة واحدة، والنظام البيئي (Prometheus، Grafana، Argo). ما تدفعه: تتكون حزمة Kubernetes + GPU Operator + Kueue + Volcano + Kubeflow العاملة من 20 مكونًا على الأقل. تقدير واقعي: Kubernetes 5-10 أضعاف الحمل التشغيلي لـ SLURM للتدريب الدفعي البحت.

يُعدّ Kubernetes الخيار الأمثل عندما: تقوم المجموعة بتشغيل خدمات الاستدلال جنبًا إلى جنب مع التدريب، أو لديك فريق منصة، أو كل شيء مهم بشكل تصريحي، أو تحتاج إلى قابلية نقل متعددة المجموعات.

Ray و KubeRay — الحوسبة الموزعة الأصلية للغة بايثون

يُعدّ Ray مختلفًا تمامًا. فهو ليس مُجدوِلًا للمجموعات بالمعنى المتعارف عليه في SLURM/K8s، بل هو بيئة تشغيل بايثون موزعة تأتي مزودة بمُجدوِل، ومخزن كائنات، ومُوسِّع نطاق تلقائي. تكتب بايثون باستخدام @ray.remote يقوم المصممون وراي بتحديد مكان تنفيذ كل مهمة.

أين يناسب راي: ضبط فرط المعلمة (Ray Tune - مئات التجارب بالتوازي، واستبعاد التجارب السيئة مبكراً؛ حالة الاستخدام التي صُمم Ray من أجلها ولا يزال الأفضل في فئته)، تعزيز التعلم (RLlib - البيئات والمتعلمون كفاعلين، وهو ما يتوافق مع Ray بشكل جيد ومع وظائف SLURM الدفعية بشكل سيئ)، التدريب الموزع (Ray Train، الذي يغلف PyTorch DDP / FSDP / DeepSpeed)، نموذج الخدمة (Ray Serve، وPython الأصلي، وخطوط أنابيب مخصصة متعددة النماذج)، و معالجة البيانات (بيانات راي). ما لا يمثله راي: مُجدول دفعات متعدد المستأجرين لمجموعة مشتركة. يفترض راي أن تطبيقًا واحدًا يمتلك المجموعة.

كيوب راي هو المشغل الذي يدير Ray على Kubernetes. ثلاثة تعريفات موارد مخصصة (CRDs): RayCluster (طويل العمر)، RayJob (لقطة واحدة)، RayService (Ray Serve، تحديثات مستمرة). مجموعة RayCluster مصغرة:

apiVersion: ray.io/v1
kind: RayCluster
metadata:
  name: rl-cluster
spec:
  rayVersion: '2.55.0'
  headGroupSpec:
    rayStartParams: { dashboard-host: '0.0.0.0' }
    template:
      spec:
        containers:
          - name: ray-head
            image: rayproject/ray:2.55.0-py311-cu125
            resources:
              limits: { cpu: 8, memory: 32Gi }
  workerGroupSpecs:
    - groupName: gpu-workers
      replicas: 4
      minReplicas: 0
      maxReplicas: 8
      rayStartParams: {}
      template:
        spec:
          containers:
            - name: ray-worker
              image: rayproject/ray:2.55.0-py311-cu125
              resources:
                limits:
                  cpu: 16
                  memory: 128Gi
                  nvidia.com/gpu: 4

يقوم Kubernetes بتوسيع نطاق مجموعة العمال تلقائيًا بين minReplicas و maxReplicas استنادًا إلى رؤية Ray للمهام المعلقة. وبالجمع مع Kueue (جدولة RayJob + Kueue gang موثقة وتعمل)، ستحصل على Ray متعدد المستأجرين على مجموعة K8s متعددة المستأجرين - وهو إعداد الإنتاج الذي تستخدمه معظم "متاجر Ray" فعليًا.

عندما يكون استخدام Ray بشكل مستقل (بدون Kubernetes) مناسبًا: في مختبر بحثي صغير حيث يمتلك شخص واحد المجموعة الحاسوبية، وتكون الديناميكية أهم من تعدد المستخدمين، ويكون عبء العمل ثقيلًا على التعلم المعزز أو البحث عن المعلمات الفائقة. أما الحل الهجين الذي تتفق عليه معظم الفرق فهو: SLURM أو K8s كطبقة أساسية تمتلك العقد وتعدد المستأجرين؛ تم تشغيل Ray داخل مهمة SLURM أو مساحة اسم K8s طوال مدة عبء عمل مستخدم واحد. لا تقم بتثبيت Ray كجدول مهام رئيسي.

Run:ai و Determined — المستوى التجاري

هناك عرضان مدفوعان يظهران بشكل متكرر بما يكفي للتطرق إليهما. كلاهما يستهدف نفس المشكلة: استخدام K8s + Volcano + Kueue + GPU Operator يتطلب الكثير من ملفات YAML، وبعض المؤسسات تفضل الشراء على التطوير.

NVIDIA Run:ai (تم الاستحواذ عليه في عام 2024، وتم تغيير علامته التجارية في عام 2025) هو جدولة GPU أصلية لـ K8s. تجزئة وحدة معالجة الرسومات يقوم بتقسيم وحدة معالجة الرسومات الواحدة بين أحمال العمل على مستوى الذاكرة — 0.5 GPU يدعم Run:ai الطلبات، وتغيير الحجم الديناميكي، وتعبئة الحاويات. يستحق Run:ai ثمنه في بيئات المؤسسات التي تضم أكثر من 10 فرق تعلم آلي تتنافس على وحدات معالجة الرسومات المشتركة. أما في البيئات الأقل تكلفة، فيغطي Kueue + GPU Operator معظم هذه الوظائف مجانًا.

Determined.AI (HPE، 2021) عبارة عن منصة تدريب مُدارة - تتبع التجارب، والبحث عن المعلمات الفائقة، وإدارة نقاط التفتيش، والتدريب الموزع في منتج واحد. وهي الأنسب لفرق البحث التي ترغب في لوحة تحكم متطورة دون الحاجة إلى دمج خمس أدوات بأنفسهم.

مشكلة دفتر الملاحظات التفاعلي

نمطٌ شائعٌ في معظم مجموعات وحدات معالجة الرسومات المشتركة: يرغب الباحثون في الوصول إلى وحدات معالجة الرسومات في JupyterHub لأغراض التطوير، ويجب أن يتزامن ذلك مع مهام تدريب طويلة الأمد تشغل عُقدًا كاملة. الحل البسيط - وحدة معالجة رسومات مخصصة لكل دفتر ملاحظات - يُهدر 80% من موارد المجموعة. أما الحل العملي - فيجعل الباحثين sbatch كل شيء — يدفعهم إلى استخدام أجهزة الكمبيوتر المحمولة مع نماذج الألعاب.

ثلاثة أنماط عملية: SLURM salloc + Jupyter على التخصيص (salloc --gres=gpu:1 --time=4:00:00ابدأ تشغيل خادم Jupyter على العقدة المخصصة، وقم بالربط عبر النفق؛ حد زمني صارم، وحساب وحدة معالجة الرسومات بشكل صحيح - الحل الأمثل لمجموعة SLURM). Kubernetes + JupyterHub + Kueue (يتم تمرير وحدات دفاتر الملاحظات عبر قائمة انتظار ذات أولوية منخفضة، وتقوم مهام التدريب بإيقاف دفاتر الملاحظات الخاملة)، أو تشغيل: الذكاء الاصطناعي مع تجزئة وحدة معالجة الرسومات (يحصل كل جهاز كمبيوتر محمول على 0.25 / 0.5 وحدة معالجة رسومية). أيهما تختار، حدد مدة زمنية للجلسات التفاعلية — يُعتبر جهاز الكمبيوتر المحمول الذي لا يحتوي على مهلة زمنية بمثابة وحدة معالجة رسومية (GPU) تم إخراجها نهائياً من المجموعة.

الواقع الصادق للفرق الصغيرة

تفترض معظم محتويات جدولة المهام على الإنترنت وجود مجموعة من 256 وحدة معالجة رسومية وفريق عمل متخصص. أما عميل كينتينو الواقعي، فيمتلك ما بين 1 إلى 4 عقد، و4 إلى 32 وحدة معالجة رسومية إجمالاً، و2 إلى 6 مستخدمين يعرفون بعضهم البعض ويتواصلون عبر سلاك. لهذا الإعداد، لست بحاجة إلى مُجدول.

# user 1
ssh node01
tmux new -s my-training
CUDA_VISIBLE_DEVICES=0,1,2,3 python train.py
# Ctrl-B D to detach

# user 2 — coordinates on Slack first
ssh node01
nvidia-smi                              # which GPUs are free?
tmux new -s other-training
CUDA_VISIBLE_DEVICES=4,5,6,7 python train.py

هذا هو نظام جدولة المهام بأكمله. يبدأ نظام SLURM في تغطية تكاليفه عند استخدام حوالي 16 وحدة معالجة رسومية أو 8 مستخدمين، أيهما أقرب. أما عند استخدام عدد أقل من ذلك، فإن التكاليف التشغيلية تتجاوز القيمة المرجوة. قم بتثبيت نظام جدولة عندما يفشل التنسيق البشري، وليس قبل ذلك.

عندما يكون كل أداة مناسبة — ملخص

---

هذا جزء من ويكي كينتينو، وهي سلسلة مرجعية حول الحوسبة الذكية، والروبوتات، والأنظمة التي تربط بينهما. نرحب بالتعليقات والتصويبات على info@kentino.com.