CUDA وcuDNN ومجموعة أدوات حاويات NVIDIA: مسار إعداد سليم لخادم الذكاء الاصطناعي

لديك خادم جديد مثبت في رف، مزود بأربعة أو ثمانية وحدات معالجة رسومية، ونظام تشغيل أوبونتو 22.04 أو 24.04، وبرنامج تشغيل NVIDIA مثبت (لكل L01)، و nvidia-smi إرجاع أرقام منطقية. هذا هو الحد الأدنى. وفوقه توجد مجموعة معقدة من المكونات - CUDA، وcuDNN، ومجموعة أدوات الحاويات، وبيئات التشغيل، وصور NGC - والتي تتجاهلها معظم الأدلة. تتناول هذه المقالة العملية من برنامج التشغيل وصولاً إلى النقطة التي docker run --gpus all يضيء كل بطاقة ويقوم حاوية vLLM بتقديم الرموز.

لديه رأي واضح بشأن المسار الذي يجب اتباعه، وصريح بشأن المسار الذي قد يكون ضاراً.

ثلاثي برنامج التشغيل / وقت التشغيل / مجموعة الأدوات

ثلاثة أشياء تُشحن تحت مظلة "CUDA" ويخلط الناس بينها باستمرار:

يُعدّ برنامج التشغيل هو العامل الأهم أثناء التشغيل. يدعم برنامج التشغيل... أقصى إصدار وقت تشغيل CUDA؛ يجب أن يكون وقت التشغيل هو هذا الإصدار أو إصدارًا أقدم. لا يلزم وجود مجموعة الأدوات إلا إذا كنت تقوم بتجميع كود CUDA بنفسك - في 95% من عمليات التثبيت، لن تحتاج إليها. nvcc على المضيف.

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

┌─────────────────────────────────────────────────┐
│ Container: PyTorch 2.9 + CUDA 13.0 runtime      │  ← shipped in image
│ Container: vLLM + CUDA 13.0 runtime             │  ← shipped in image
├─────────────────────────────────────────────────┤
│ Host: NVIDIA driver 570.x                       │  ← only thing host needs
│ Host: nvidia-container-toolkit                  │  ← bridges driver → container
└─────────────────────────────────────────────────┘

هذه الصورة هي الفرق بين قضاء فترة ما بعد الظهيرة في العمل وثلاثة أيام من جحيم الاعتماد على الآخرين.

CUDA 12.x أو 13.x - أيهما تختار؟

كلاهما قيد الاستخدام الفعلي في مايو 2026. المصفوفة الصادقة لأحمال العمل التي تشغلها خوادم كينتينو:

الإعداد الافتراضي لـ Kentino هو CUDA 13.0 في الإصدارات الجديدة. يدعم vLLM جميع وحدات معالجة الرسومات في هذه السلسلة (5090، 4090، RTX Pro 6000 Blackwell، L40، L4)، ويأتي الآن مع ملفات 13.0 بشكل افتراضي على PyPI و vllm/vllm-openai تستخدم الصورة الإصدار 13.0، وتم تصميم PyTorch 2.11 (الذي يأتي معه vLLM) للإصدار 13.0، وتستهدف الميزات الجديدة (FlashAttention 3 على Blackwell، ونوى تدريب FP8) الإصدار 13.x أولاً.

ابقَ على الإصدار 12.8 فقط في الحالات التالية: إعادة إنتاج معيار أداء مثبت، أو عدم تحديث حزمة تطوير البرامج (SDK) الخاصة بالمورد، أو بطاقات ما قبل بلاكويل حصراً. لا يوجد إصدار أقدم من 12.4 على عمليات التثبيت الجديدة - تم إصلاح الأخطاء في المصدر الرئيسي قبل عامين.

تثبيت برنامج التشغيل وCUDA بشكل سليم

أوبونتو 24.04 LTS (الإصدار 22.04 مطابق له). المسار النظيف هو CUDA من NVIDIA apt الريبو:

wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2404/x86_64/cuda-keyring_1.1-1_all.deb
sudo dpkg -i cuda-keyring_1.1-1_all.deb
sudo apt update

# Driver + CUDA runtime libs. No nvcc — only what apps need to run.
sudo apt install -y cuda-drivers-570 cuda-runtime-13-0

# Optional full toolkit (nvcc, headers). Only if you compile on the host.
# sudo apt install -y cuda-toolkit-13-0

sudo reboot

بعد إعادة التشغيل، nvidia-smi يجب أن يُبلغ عن برنامج التشغيل 570.x وCUDA 13.0. الأخطاء التي يجب تجنبها:

• لا تقم بتثبيت cuda حزمة ميتا إلا إذا كنت تريد كل شيء. يقوم البرنامج بسحب مجموعة الأدوات، والعينات، وGDS، وNsight، وتثبيت الحزم التي لم تكن تريدها. اختر. cuda-runtime-13-0 or cuda-toolkit-13-0 صراحة.
• قم بتثبيت السائق لذا لا يمكن لتحديثات النظام غير المراقبة تثبيت وحدة النواة: sudo apt-mark hold cuda-drivers cuda-drivers-570 nvidia-driver-570 nvidia-dkms-570 libnvidia-compute-570.
• فرع واحد من فروع السائق في كل مرة. يؤدي دمج حزمتي 550 و570 إلى إنتاج نظام يعمل ولكن أين nvidia-smi يُعيد هذا الخطأ الغامض عدم تطابق الإصدار. والحل هو apt purge '*nvidia*' '*cuda*' والبدء من جديد - من الأفضل عدم الوصول إلى هناك.

cuDNN — apt أم tarball؟

مكتبة cuDNN هي مكتبة أساسية للتعلم العميق، تشمل الالتفاف، والانتباه، والشبكات العصبية المتكررة. وتعتمد عليها كل من PyTorch وTensorFlow وJAX. ابتداءً من الإصدار 9.x، يوجد مساران للتثبيت.

مناسب (موصى به):

sudo apt install -y libcudnn9-cuda-13 libcudnn9-dev-cuda-13

يتم التثبيت على /usr/lib/x86_64-linux-gnu/، يتم التقاطها بواسطة الرابط الديناميكي، وتتكامل مع مدير الحزم بحيث يتم تمرير تحديثات الأمان. لا يمكن تثبيت سوى إصدار واحد من cuDNN 9 بتقنية CUDA في كل مرة - لا libcudnn9-cuda-12 و libcudnn9-cuda-13 جنبًا إلى جنب عبر الشقة.

كرة القطران:

# Fetch from the redist manifest at developer.download.nvidia.com/compute/cudnn/redist/
tar -xf cudnn-linux-x86_64-9.5.0.x_cuda13-archive.tar.xz
sudo cp -r cudnn-linux-x86_64-*/include/* /usr/local/cuda/include/
sudo cp -r cudnn-linux-x86_64-*/lib/* /usr/local/cuda/lib64/

يُعدّ استخدام ملف tarball خيارًا مناسبًا لتشغيل إصدارات متعددة من cuDNN على جهاز واحد، أو لحزم البرامج المعزولة عن الشبكة، أو لتثبيت إصدارات صغيرة. أما في الحالات الأخرى، فيُفضّل استخدام apt. توصي وثائق NVIDIA باستخدام حزم التوزيع كلما أمكن ذلك، فملف tarball ليس برنامج تثبيت، بل هو أرشيف لإعادة التوزيع.

إجابة صريحة: إذا كنت تستخدم حاويات NGC، فلا تقم بتثبيت cuDNN على المضيف إطلاقاً. فهو يأتي ضمن الصورة.

الحاويات مقابل المعدن الخام - متى نستخدم أيًا منهما

أهم قرار في هذه العملية، ولا يوجد حلٌّ واحدٌ يناسب الجميع. المفاضلة كما تُرى في نماذج كينتينو الحقيقية:

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

المعدن الخام: السعي وراء آخر 2-3% من أجل ورقة بحثية، وتصحيح أخطاء النواة باستخدام cuda-gdb / compute-sanitizer / Nsight حيث تكون طبقة الحاوية عائقاً، أو عملية واحدة تسيطر على الجهاز لسنوات.

الحاويات (الوضع الافتراضي في كينتينو): صناديق متعددة المستخدمين، PyTorch 2.5 و 2.11 جنبًا إلى جنب، تبديل أطر الاستدلال (vLLM، SGLang، TensorRT-LLM) دون إعادة بناء المضيف، أو عملية نشر يمكنك docker pull قم بنقله إلى خادم جديد وابدأ تشغيله في غضون خمس دقائق.

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

مجموعة أدوات nvidia-container-toolkit - ما هي وكيفية إعدادها

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

تثبيت:

curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey \
  | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg
curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list \
  | sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' \
  | sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list

sudo apt update && sudo apt install -y nvidia-container-toolkit
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

# Smoke test
docker run --rm --gpus all nvidia/cuda:13.0.0-base-ubuntu24.04 nvidia-smi

يجب أن يُظهر الأمر الأخير المضيف nvidia-smi إذا كان الناتج من داخل الحاوية، فهذا يعني أن المكدس موصول.

Podman

يستخدم بودمان نظام CDI:

sudo nvidia-ctk runtime configure --runtime=podman
sudo nvidia-ctk cdi generate --output=/etc/cdi/nvidia.yaml

podman run --rm --device=nvidia.com/gpu=all \
  nvcr.io/nvidia/pytorch:25.12-py3 nvidia-smi

يُعدّ نظام Podman + CDI بدون روت الإعداد الأمثل لأجهزة المستخدمين المتعددين حيث لا ترغب في وجود مستخدمين في docker المجموعة (التي هي فعلياً الجذر).

CDI مقابل وقت التشغيل القديم

وضعان لعرض وحدات معالجة الرسومات:

• إرث nvidia خطاف وقت التشغيل - ماذا --gpus all يستخدم Docker منذ سنوات. يقوم Docker باستدعاء خطاف يقوم بتثبيت مكتبات برامج التشغيل والأجهزة في الحاوية أثناء التشغيل.
• واجهة جهاز الحاوية (CDI) — مواصفات مفتوحة لإعلان الوصول إلى الجهاز. nvidia-ctk cdi generate يكتب ملف YAML يسرد وحدات معالجة الرسومات كأجهزة مسماة (nvidia.com/gpu=0, nvidia.com/gpu=all); أي بيئة تشغيل مدركة لـ CDI تستهلكها.

الوضع في منتصف عام 2026:

بالنسبة لتثبيت Docker على خادم واحد، لا يزال النظام القديم يعمل بكفاءة. أما بالنسبة لأي شيء يتعلق بـ Kubernetes أو ببيئة بدون صلاحيات الجذر أو ببيئة متعددة المستخدمين، فيُنصح بالتحويل إلى CDI - وهو المجال الذي تستثمر فيه NVIDIA. عملية الترحيل سلسة وغير معقدة: ما عليك سوى تثبيت مجموعة الأدوات، وإنشاء مواصفات CDI، ثم التبديل. --gpus all لـ --device=nvidia.com/gpu=allيمكن للنمطين أن يتعايشا.

تمرير وحدة معالجة الرسومات — ماذا؟ --gpus all هل يفعل ذلك فعلا

عندما تقوم بتشغيل docker run --gpus all my-image يقرأ خطاف وقت التشغيل NVIDIA_VISIBLE_DEVICES / NVIDIA_DRIVER_CAPABILITIES، حوامل /dev/nvidia* في الحاوية مع أذونات cgroup، يقوم بربط برنامج تشغيل المضيف .so الملفات في، والمجموعات LD_LIBRARY_PATH لذلك يجدها الرابط.

ما تتحكم به:

docker run --gpus all ...                                     # all GPUs
docker run --gpus '"device=0,1"' ...                          # by index
docker run --gpus '"device=GPU-abc123..."' ...                # by UUID
docker run --gpus all -e NVIDIA_DRIVER_CAPABILITIES=compute,utility ...
docker run --device=nvidia.com/gpu=0 --device=nvidia.com/gpu=1 ...  # CDI

بالنسبة لخادم مزود بـ 8 وحدات معالجة رسومية يقوم بتنفيذ vLLM بالتوازي الموتري، استخدم --gpus allبالنسبة لجهاز متعدد المستأجرين حيث يحصل المستخدمون على شرائح 4-GPU، قم بالتثبيت بواسطة UUID - التثبيت القائم على الفهرس يتعطل إذا قمت بإعادة توصيل الكابلات.

حاويات NGC - متى يتم استخدامها

يُوفر كتالوج NGC من NVIDIA (nvcr.io) صورًا لـ PyTorch وTensorRT وTensorRT-LLM وTriton وغيرها. حجمه كبير (5-15 جيجابايت)، ولكنه مُختَبَر ومُشحون مع مجموعات تشغيل cuDNN / NCCL / CUDA التي خضعت لاختبارات الجودة من NVIDIA. مايو 2026.

العلامات هي <year>.<month>-py3يتم قطعها شهرياً. ليست دقيقة تماماً من المصدر الأصلي - حيث يتم إصلاحها وإعادة بنائها - ولكنها تتبعها بشكل دقيق.

موقف صادق لصالح شركة NGC: إذا كنت تستخدم TensorRT-LLM أو Triton، فاستخدم صورة NGC. تم إنجاز مهمة مطابقة cuDNN وNCCL وTensorRT وCUDA. أما بالنسبة لـ PyTorch أو vLLM، فالصور العامة (pytorch/pytorch:..., vllm/vllm-openai:...) أصغر حجماً وأسرع في التحديث - إن NGC مبالغة.

ميج - ولماذا لا ينطبق ذلك على تشكيلة كينتينو

تقوم تقنية MIG بتقسيم وحدة معالجة الرسومات (GPU) الواحدة إلى ما يصل إلى سبع شرائح معزولة، لكل منها نطاق ذاكرة وحوسبة ونطاق أعطال خاص بها. وهي مفيدة للاستدلال متعدد المستخدمين - حيث يحصل خمسة مستخدمين على سُبع وحدة H100 مع عزل تام.

تقنية MIG غير متوفرة على بطاقات Blackwell المخصصة للمستهلكين (RTX 5090، 4090) أو بطاقات Blackwell الخاصة بمحطات العمل (RTX Pro 6000). يقتصر ذلك على وحدات التخزين المخصصة لمراكز البيانات - H100، H200، A100، B100، B200، GB200. لا توفر شركة كينتينو وحدات معالجة الرسومات (GPUs) المخصصة لمراكز البيانات ذات عامل الشكل SXM، لذا فإن MIG غير موجود في أي إصدار من كينتينو.

البديل الموجود على بطاقات المستهلك / محطة العمل هو خدمة متعددة العمليات (MPS) تتشارك عدة عمليات في مُجدول حساب وحدة معالجة الرسومات. على الرغم من أنها ليست معزولة مثل MIG (إذ قد تتسبب عملية واحدة معيبة في إيقاف الجهاز بسبب نفاد الذاكرة)، إلا أنها تعمل بكفاءة وتُعدّ حلاً مثالياً للاستدلال الموثوق متعدد المستأجرين دون أي تكلفة إضافية. إذا كنت بحاجة فعلية إلى MIG، فستحتاج إلى خط SKU الخاص بمركز البيانات من خلال مُكامل أنظمة آخر.

استكشاف الأخطاء وإصلاحها - الأخطاء التي تؤثر على الجميع

CUDA error: no kernel image is available for execution on the device (خطأ 209). لا يحتوي وقت تشغيل CUDA الخاص بالحاوية على نواة تدعم قدرات الحوسبة لوحدة معالجة الرسومات لديك - عادةً ما تكون صورة CUDA 12.4 على بطاقة Blackwell (sm_120) تتطلب الإصدار 12.8 أو أحدث. الحل: استخدام صورة أحدث، أو البناء باستخدام الإصدار الصحيح. TORCH_CUDA_ARCH_LIST.

CUDA error: forward compatibility was attempted on non supported HW (خطأ 100). برنامج تشغيل الجهاز المضيف أقدم من الإصدار المطلوب في بيئة التشغيل داخل الحاوية. الحل: قم بترقية برنامج تشغيل الجهاز المضيف، وثبّته من مستودع NVIDIA، وليس من الإصدار القديم المُضمّن في حزمة Ubuntu.

Failed to initialize NVML: Driver/library version mismatch. تم تحديث برنامج التشغيل عبر apt دون إعادة تشغيل الجهاز؛ وحدة النواة قديمة، ومساحة المستخدم جديدة. الحل: أعد تشغيل الجهاز. (إذا لم تتمكن من ذلك، rmmod وحدات إنفيديا و modprobe (أعدهم إليّ — لكن إعادة التشغيل أكثر أمانًا.)

nvidia-container-cli: initialization error: nvml error: driver not loaded. تم تثبيت مجموعة الأدوات، ولكن لم يتم تحميل وحدة نواة برنامج التشغيل. عادةً ما يكون التثبيت الجديد هو المكان الذي... nvidia-smi فشل الاتصال على المضيف بالفعل. أصلح المضيف أولاً، ثم الحاوية.

OCI runtime exec failed: ... no such file or directory on --gpus all. لم يتم تسجيل خطاف وقت التشغيل في Docker. أعد التشغيل sudo nvidia-ctk runtime configure --runtime=docker && sudo systemctl restart dockerإذا لم يتم إصلاحها، فتحقق /etc/docker/daemon.json ل "runtimes" منع.

البناء من المصدر مقابل البناء الجاهز

PyTorch وvLLM وllama.cpp وFlashAttention - جميعها تحتوي على ملفات وصور جاهزة. يُنصح بالبناء من المصدر فقط عند الحاجة إلى ميزة غير مُعلنة، أو عند استخدام قدرة حاسوبية لا تدعمها ملفات المصدر، أو عند التجميع باستخدام CUDA/cuDNN مُخصصة. يستغرق بناء PyTorch من المصدر من 30 إلى 90 دقيقة على معالجات EPYC دون أي تحسن في الأداء إلا في حال استخدام علامات CMake مُخصصة. البناء من المصدر هو الحل الأمثل لمشكلة مُحددة، وليس الخيار الافتراضي.

---

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