كيفية اختيار المراقبة الشاملة لمصانع الذكاء الاصطناعي من NVIDIA

كيف تختار المراقبة الشاملة للمكدس لمصانع NVIDIA للذكاء الاصطناعي

عندما يمتد مصنع ذكاء اصطناعي عبر آلاف وحدات معالجة الرسومات NVIDIA، وشبكة InfiniBand، وتخزين موزّع، ومجدول يطلق وظائف دفعية على مدار الساعة، تتوقف مكدسات المراقبة العادية عن العمل. لم يعد لديك بضعة خوادم بعدد قليل من المقاييس؛ بل لديك آلة حيث يمكن لكل طبقة — السيليكون، البرنامج الثابت (firmware)، برنامج التشغيل (driver)، بيئة تشغيل الحاويات، إطار العمل، والتنسيق (orchestration) — أن تصبح عنق زجاجة في اليوم نفسه. سلوك صامت واحد، مثل GPU تبدأ في خنق ساعات الذاكرة (memory clocks)، يمكن أن يبطئ تشغيل تدريب كامل، ومع ذلك لن تكتشفه أي من لوحات المعلومات على مستوى التطبيق.

المراقبة الشاملة للمكدس لمصانع NVIDIA للذكاء الاصطناعي ليست مجرد لوحة معلومات أكبر. إنها اختيار مدروس حول البيانات التي يجب جمعها، وكيفية ربط هذه البيانات عبر الطبقات، ومن سيتصرف بناءً عليها. تعرض هذه المقالة إطار عمل عمليًا لاتخاذ القرار، وتوضح كيفية إنشاء مكدس مرجعي بسيط يدرك وحدات GPU ويطبّق نمط المكدس الكامل بأوامر حقيقية.

ماذا يعني «المكدس الكامل» في مصنع الذكاء الاصطناعي

في تكنولوجيا المعلومات التقليدية، تعني المراقبة الشاملة للمكدس عادةً ربط التطبيق وبيئة التشغيل ونظام التشغيل المضيف. يضيف مصنع الذكاء الاصطناعي عدة طبقات يسهل تفويتها:

• طبقة السيليكون: استخدام GPU، استخدام الذاكرة، درجة الحرارة، استهلاك الطاقة، خنق الساعة، والأخطاء التي تظهر عبر واجهتي NVML وDCGM من NVIDIA.
• طبقة النظام والشبكة: وحدة المعالجة المركزية وذاكرة المضيف، صحة NVMe، مشاكل ارتباط PCIe، وشبكة InfiniBand أو RoCE التي تربط وحدات GPU ببعضها البعض وبالتخزين. يمكن أن يتسبب ارتباط متدهور في إبطاء العمليات الجماعية دون ظهور أي خطأ في سجلات التطبيق.
• طبقة التشغيل والتنسيق: سلوك جدولة Kubernetes أو Slurm، صحة الحاويات، تقطيع زمن GPU أو عزل MIG، وانتظار الطوابير الذي يسبق كل تشغيل تدريب.
• طبقة التطبيق وإطار العمل: عدد خطوات التدريب في الثانية التي يحققها عبء العمل، إنتاجية محمل البيانات، منحنيات الخسارة، وصحة نقاط نهاية الاستدلال من Triton أو حاوية تقديم مخصصة.

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

متطلبات يجب حسمها قبل مقارنة الأدوات

قبل تقييم أي منتج، اكتب المتطلبات الملموسة. أربعة منها مهمة بشكل خاص لمصانع الذكاء الاصطناعي.

أولاً، حدد أهداف مستوى الخدمة (SLOs) التي تهتم بها فعليًا. بالنسبة للتدريب، فإن هدف مستوى الخدمة الرئيسي هو التقدم الأمامي الثابت: يجب أن تظل الخطوات في الثانية أعلى من عتبة معينة، ويجب ألا تتباطأ الوظيفة بصمت. بالنسبة للاستدلال، فإن أهداف مستوى الخدمة هي زمن الاستجابة والإنتاجية واستخدام GPU لأسطول التقديم. يجب تقييم أدوات المراقبة بناءً على ما إذا كانت قادرة على إنتاج هذه الإشارات الدقيقة، وليس مجرد حالة «النظام سليم» العامة.

ثانيًا، قرر ما إذا كنت بحاجة إلى رؤية فورية أم رؤية لاحقة. مصنع الذكاء الاصطناعي هو بيئة عالية الأبعاد (high-cardinality): كل وظيفة لها مجموعتها الخاصة من الحاويات ووحدات GPU والعمليات. تحتاج إلى تحديد عدد المقاييس في الثانية التي يمكن للخط أن يدعمها ومدة الاحتفاظ بالبيانات. القياسات عن بُعد كاملة الدقة على فترات 15 ثانية عبر 10,000 وحدة GPU تختلف تمامًا عن القياسات المعاينة التي تُحتفظ بها لمدة شهر.

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

رابعًا، حدد المالك التشغيلي. تفشل المراقبة الشاملة للمكدس عندما لا يملك أحد المكدس الكامل. عمليًا، يملك مسؤولو المجموعة مقاييس السيليكون والشبكة، وتمتلك فرق منصة التعلم الآلي مقاييس إطار العمل، وتمتلك فرق التطبيق منحنيات التدريب. يجب أن تحدد الأداة المختارة حدود ملكية واضحة مع السماح لفريق واحد بالتنقل من ارتفاع في الخسارة مباشرةً إلى رسالة خطأ XID.

ما الذي يجب قياسه: من أخطاء XID إلى إنتاجية البيانات

من الأخطاء الشائعة قياس استخدام GPU فقط. يكشف DCGM من NVIDIA عن مجموعة أغنى بكثير من المقاييس، بما في ذلك استخدام الذاكرة، وإشغال SM، واستهلاك الطاقة، ودرجة الحرارة، وأسباب خنق الساعة، وعدادات الأخطاء. على Linux، يمكنك فحص صحة وحدات GPU على العقدة بسرعة باستخدام واجهة إدارة النظام من NVIDIA:

# How to Choose Full-Stack Observability for NVIDIA AI Factories
nvidia-smi

# List detailed metrics for every GPU in JSON format
nvidia-smi --query-gpu=index,uuid,temperature.gpu,utilization.gpu,utilization.memory,power.draw,clocks.sm --format=csv

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

# Run DCGM's diagnostic suite once to identify hardware issues
dcgmi diag -r 1

توضح هذه الأوامر لماذا تتعلق مسألة المكدس الكامل بـ تصنيف المقاييس بقدر ما تتعلق بالأدوات. قبل اختيار مورد، حدد أيًا من هذه الإشارات إلزامي:

• أخطاء XID والأعطال على مستوى برنامج التشغيل، والتي تشير إلى حالات خطأ في الأجهزة أو البرامج؛
• أسباب الخنق، لأن GPU يمكن أن تكون عند 100% من استخدام الحوسبة ولكنها لا تزال مخنوقة إلى 70% من ساعتك؛
• أخطاء الشبكة، المصنفة إما مصححة (حميدة) أو غير مصححة (قاتلة)؛
• معدلات قراءة/كتابة PCIe وHBM، والتي تكشف تشبع عرض النطاق الترددي للذاكرة؛
• البيانات الوصفية على مستوى الوظيفة من المجدول، بحيث يمكن نسب كل مقياس إلى مالك عبء العمل.

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

التثبيت المرجعي خطوة بخطوة

لا يوجد مكدس مراقبة «صحيح» واحد، ولكن يوجد نمط مفتوح المصدر معروف يُظهر جميع المبادئ المذكورة أعلاه: DCGM-Exporter لمقاييس GPU، وPrometheus للجمع والتخزين، وGrafana للوحات المعلومات. الأوامر أدناه هي تنفيذ مرجعي توضيحي. استخدم مساحة اسم مخصصة للمراقبة وثبّت الإصدارات الدقيقة لصور الحاويات في بيئتك الخاصة، لأن الإصدارات تتغير كثيرًا.

الخطوة 1 — تشغيل مُصدِّر مقاييس GPU.

تنشر NVIDIA صورة حاوية DCGM-Exporter. يقرأ القياسات عن بُعد من برامج تشغيل المضيف ويعرضها كمقاييس بتنسيق Prometheus على المنفذ 9400. الأمر التالي يشغله على عقدة مثبتة عليها برامج تشغيل NVIDIA:

# Start the DCGM-Exporter on the default port
docker run -d --gpus all --rm \
  --name dcgm-exporter \
  -p 9400:9400 \
  nvcr.io/nvidia/k8s/dcgm-exporter:latest

إذا كنت تفضل عدم تشغيل حاوية، يتوفر DCGM-Exporter أيضًا كملف تنفيذي مستقل من صفحة إصدار المشروع على GitHub. تحقق من أنه يعمل عن طريق استدعاء نقطة نهاية المقاييس الخاصة به باستخدام curl:

# Confirm that GPU metrics are being exported
curl -s http://localhost:9400/metrics | head -20

يجب أن ترى أسماء مقاييس تبدأ بـ DCGM_FI_DEV_، مثل DCGM_FI_DEV_GPU_UTIL وDCGM_FI_DEV_MEM_COPY_UTIL.

الخطوة 2 — تكوين Prometheus لجمع المقاييس من المُصدِّر.

أنشئ ملف تكوين Prometheus بسيطًا. التفصيل الأساسي هو إرفاق تسمية تحدد العقدة الفعلية، بحيث تظل مقاييس الوظيفة منسوبة إلى المضيف الصحيح عند تشغيل أي وظيفة على أي عقدة في المجموعة:

global:
  scrape_interval: 15s

scrape_configs:
  - job_name: "dcgm"
    static_configs:
      - targets: ["gpu-node-01:9400", "gpu-node-02:9400"]
        labels:
          cluster: "ai-factory-east"

ثم شغّل Prometheus:

# Run Prometheus with the configuration above
docker run -d --name prometheus \
  -p 9090:9090 \
  -v $(pwd)/prometheus.yml:/etc/prometheus/prometheus.yml \
  prom/prometheus:latest

الخطوة 3 — توفير لوحة معلومات Grafana.

يمكن لـ Grafana سحب المقاييس مباشرةً من مصدر البيانات، لذلك لا حاجة إلى وكيل خفي:

# Start Grafana and connect it to the Prometheus instance on port 9090
docker run -d --name grafana \
  -p 3000:3000 \
  -e GF_SECURITY_ADMIN_PASSWORD=admin \
  grafana/grafana:latest

بعد تشغيل الحاويات، افتح واجهة الويب الخاصة بـ Grafana على المنفذ 3000، وسجّل الدخول، وأضف مصدر بيانات Prometheus يشير إلى http://prometheus:9090، وأنشئ لوحة معلومات بها لوحات تستعلم عن مقاييس DCGM_FI_DEV_GPU_UTIL وDCGM_FI_DEV_POWER_USAGE.

أمثلة على الاستخدام

تظهر القيمة الحقيقية للمكدس عندما تبدأ في طرح أسئلة عبر الطبقات. إليك ثلاثة أنماط مفيدة.

1. اكتشاف خنق GPU الذي لا يظهر كاستخدام منخفض.

يمكن أن تعمل GPU عند 100% من حد الساعة الحالي وما تزال أبطأ من معدلها الأقصى المعلن. يمكن لبايثون، باستخدام واجهة برمجة تطبيقات Prometheus، إظهار هذا التناقض. المثال أدناه يستعلم عن إشغال ساعة SM وأسباب الخنق:

import requests

prometheus_url = "http://localhost:9090/api/v1/query"

queries = {
    "throttle_reasons": 'DCGM_FI_DEV_CLOCK_THROTTLE_REASONS',
    "sm_clock": 'DCGM_FI_DEV_SM_CLOCK',
}

for name, query in queries.items():
    response = requests.get(prometheus_url, params={"query": query}).json()
    for result in response["data"]["result"]:
        print(name, result["metric"].get("gpu_uuid"), result["value"][1])

قناع بتات لأسباب الخنق غير الصفري يخبرك بما يحد من الشريحة — حراريًا أو طاقة أو عوامل أخرى — وقيمة ساعة SM تخبرك بما قررت GPU فعله حيال ذلك.

2. ربط وظيفة بطيئة بطبقة تحميل البيانات.

افترض أن وظيفتك تعمل عند 300 خطوة في الثانية بدلاً من 450 المتوقعة. يبدو استخدام GPU جيدًا، وهذا مريب. الاستعلام أدناه يحسب متوسط استخدام نسخ الذاكرة لكل GPU خلال آخر خمس دقائق، وهو ما يكشف غالبًا عن توقف في تحميل البيانات:

import requests

prom = "http://localhost:9090/api/v1/query"
query = 'avg_over_time(DCGM_FI_DEV_MEM_COPY_UTIL[5m])'

response = requests.get(prom, params={"query": query}).json()
for result in response["data"]["result"]:
    metric = result["metric"]
    print(metric.get("kubernetes_pod_name"),
          metric.get("gpu_uuid"),
          round(float(result["value"][1]), 2))

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

3. بناء تنبيه بسيط لأعطال GPU الصامتة.

يمكن كتابة تنبيه موثوق مباشرةً في PromQL، باستخدام مقاييس dcgm_exporter لتمييز GPU الذي يزداد عداد أخطائه بمرور الوقت:

increase(DCGM_FI_DEV_XID_ERRORS[5m]) > 0

هذا التنبيه أكثر قابلية للتنفيذ بكثير من تنبيه «العقدة معطلة» العام لأنه يسمي GPU والوظيفة المشتركة معه عبر التسميات المرفقة.

ما الذي يجب توحيده ومن يملكه

أصعب جزء في اختيار مراقبة المكدس الكامل ليس التثبيت؛ بل توحيد الأسماء وتنظيم الملكية.

أولاً، وحد التسميات (labeling) عبر جميع المقاييس. إذا كان مُصدِّر GPU ومُصدِّر Kubernetes والمجدول يستخدمون جميعًا نفس معرّف الوظيفة، يمكنك ربطها وقت الاستعلام. اختر مجموعة صغيرة من التسميات — job_id وcluster وnode وgpu_uuid — وفرض الاتفاقية وقت الاستيعاب.

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

ثالثًا، فكر بعناية في المفاضلة بين عبء الجمع والدقة. مقاييس DCGM رخيصة الجمع، لكن مقاييس الشبكة ومستوى الإطار أكثر تكلفة. قم بقياس الطبقات العميقة فقط على العقد التي توجد بها وظائف تدريب نشطة، وليس على المجموعة بأكملها، وستبقى الأعباء قريبة من الصفر.

مخاطر يجب تجنبها

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

وهناك أيضًا خطأ إداري بحت: شراء منصة مراقبة وافتراض أنها ستحل المشكلة التنظيمية. لن تقرر الأداة من يعالج خطأ الشبكة؛ يجب أن يقوم فريق تشغيل المصنع بذلك. إذا كانت مؤسستك لا تستطيع بالفعل الإجابة على سؤال «من يملك شبكة الاتصال؟»، فلن يساعدك أي منتج في رؤية الشبكة بوضوح كافٍ لإصلاحها.

الخلاصة

المراقبة الشاملة للمكدس لمصانع NVIDIA للذكاء الاصطناعي هي قرار متعدد الطبقات. حدد أهداف مستوى الخدمة، وقرر القياسات التي يمكنك تحملها والمدة التي تحتاج إلى تخزينها، وتأكد من أن الأداة المرشحة تُبرز إشارات NVIDIA منخفضة المستوى مثل أسباب الخنق وأخطاء XID، ثم اربط هذه الإشارات ببيانات المجدول والتطبيق. مكدس مرجعي بسيط مبني من DCGM-Exporter وPrometheus وGrafana هو طريقة موثوقة لاختبار هذه المتطلبات في بيئتك الخاصة قبل الالتزام بنشر أوسع. ابدأ بمقاييس مستوى السيليكون، وأضف بيانات الشبكة والوظائف، وفرض اصطلاح تسمية صارمًا من اليوم الأول. يعمل مصنع GPU بوتيرة مختلفة عن البنية التحتية العادية لتكنولوجيا المعلومات، ويجب بناء مراقبته لتواكب ذلك.