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

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

تقارن هذه المقالة بين أدوات الجدولة التي يختارها المستخدمون فعليًا - SLURM، وKubernetes (مع Kueue أو Volcano)، وRay وKubeRay، والخيارات التجارية Run:ai وDetermined - وتتناول بصراحة الحالة التي يكون فيها الحل الأمثل هو "لا شيء، فقط SSH". وقد قرأ الجمهور المقالات K01 و K02 و K03 ، وهم الآن بصدد تحديد ما سيضعونه فوق مجموعة من 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 على Kubernetes، بحيث يقوم نفس نظام المجموعة بتنفيذ كليهما. على نطاق Kentino، غالبًا ما يكون استخدام نظامي مجموعة صغيرين منفصلين أبسط.

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

صُممت Kubernetes للحفاظ على تشغيل خدمات الويب عديمة الحالة. أما بالنسبة لمجموعات الذكاء الاصطناعي، فيتم إضافة كل شيء آخر بشكل منفصل. تتضمن حزمة 2026: مُشغّل وحدة معالجة الرسومات من NVIDIA (برامج التشغيل، CUDA، NCCL، DCGM، مُلحق الجهاز، تكوين MIG)، و Kueue (قائمة الانتظار، الحصص، القبول)، و Volcano (مُجدول مُدرك للدفعات)، و Kubeflow Trainer (تعريفات الموارد المخصصة PyTorchJob، TFJob، MPIJob)، و KubeRay (Ray على Kubernetes)، و Karpenter أو Cluster Autoscaler لتوفير العقد.

لماذا يُعدّ استخدام 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"]

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

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

يتعامل 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 + مُشغّل وحدة معالجة الرسومات + Kueue + Volcano + Kubeflow العاملة تتكون من 20 مُكوّنًا على الأقل. تقدير واقعي: يُشكّل Kubernetes عبئًا تشغيليًا أكبر من SLURM بمقدار 5 إلى 10 أضعاف للتدريب الدفعي البحت.

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

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

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

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

كيوب راي هو المشغل الذي يدير 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 أو Kubernetes كطبقة أساسية تمتلك العقد وتدعم تعدد المستخدمين؛ حيث يتم تشغيل Ray داخل مهمة SLURM أو مساحة اسم Kubernetes طوال مدة عبء عمل مستخدم واحد. لا تقم بتثبيت 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 وحدة معالجة رسومية وفريق عمل متخصص. أما عميل Kentino الواقعي، فيمتلك عادةً ما بين 1 إلى 4 عقد، و4 إلى 32 وحدة معالجة رسومية إجمالاً، و2 إلى 6 مستخدمين يعرفون بعضهم ويتواصلون فيما بينهم عبر Slack. في هذه الحالة، لا تحتاج إلى برنامج جدولة مهام.

# 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.