لا تنتقل أدوات مراقبة CPU والذاكرة إلى وحدات معالجة الرسوميات GPU على Kubernetes بالسهولة نفسها. فبينما توفر المنصة عادةً مقاييس الاستخدام على مستوى الحاوية أو الـPod، تحتاج فرق المنصات عند مشاركة GPU إلى بناء معظم طبقات الرؤية والتخصيص والفوترة بنفسها، بدءاً من جمع البيانات وانتهاءً بتحديد حصة كل فريق من التكلفة.
تنبع أهمية المشكلة من أن GPU يمثل عادةً أغلى بند في فاتورة البنية التحتية. ويشير التحليل إلى أن تكلفة التشغيل لا تقتصر على سعر العقدة، بل تشمل أيضاً وقت الهندسة اللازم لتعويض فجوات القياس، والتحقق من دقة الأرقام، ومنع الأحمال من تجاوز ما خصصه Kubernetes لها.
لماذا لا تكفي المقاييس المعتادة؟
تقدم أداة NVIDIA DCGM exporter، التي يبدأ بها كثير من المشغلين، بيانات على مستوى الجهاز الفعلي افتراضياً. وعندما يمتلك Pod وحدة GPU كاملة قد يكون ذلك كافياً، لكن الوضع يختلف عند استخدام time-slicing أو MPS لمشاركة الجهاز. في هذه الحالة قد تظهر القيمة نفسها لكل Pod يستخدم GPU واحداً، فيبدو وكأن ثلاثة أحمال استهلكت 300% من وحدة غير موجودة فعلياً.
المشكلة أن الرسوم البيانية قد تبدو سليمة رغم أن البيانات الأساسية غير صالحة للإسناد. ولذلك يمكن للفرق أن تبني تقارير ولوحات متابعة كاملة على أرقام لا تميز فعلياً بين المستهلكين.
ما الذي يتغير عملياً لفرق المنصات؟
يختلف GPU أيضاً عن CPU في نموذج تخصيص الموارد. يظهر GPU في Kubernetes عادةً كمورد صحيح مثل nvidia.com/gpu: 1، ولا يتيح المجدول التعامل مع الأجزاء الكسرية بالطريقة المعتادة مع المعالجات. أما المشاركة الفعلية فتحدث أسفل مستوى المجدول عبر time-slicing أو MPS أو MIG، ما يجعل مقارنة ما طلبه الحمل بما استخدمه أكثر تعقيداً.
وتحتاج الفرق كذلك إلى ضوابط مستقلة للتأكد من أن ما سجله Kubernetes على أنه مخصص يطابق ما يستطيع التطبيق الوصول إليه فعلاً. فمتغير البيئة NVIDIA_VISIBLE_DEVICES قد يؤدي، إذا لم يتغلب عليه إعداد مناسب، إلى رؤية الحاوية لكل وحدات GPU في العقدة، حتى لو خصص لها المجدول وحدة واحدة فقط.
كما أن عبارة “استخدام GPU بنسبة 80%” لا تحمل معنى واحداً بالضرورة. قد تقيس فقط وجود نواة تعمل خلال جزء من نافذة العينة، من دون أن توضح استهلاك القدرة الحسابية أو عرض نطاق الذاكرة. وفي بعض أطر العمل، مثل vLLM، قد تُحجز معظم ذاكرة GPU عند بدء التشغيل، ما يجعل الذاكرة أو عرض النطاق مؤشراً أهم من رقم الاستخدام العام.
الفوترة: الذاكرة أكثر قابلية للإسناد من الحوسبة
يمكن لمكتبة NVIDIA NVML إظهار مقدار الذاكرة الذي يحتفظ به كل process، ثم ربط العملية بالـPod والفريق المسؤول عنها، مع ملاحظة أن مجموع القيم لن يساوي كامل ذاكرة البطاقة بسبب الجزء الذي يحتفظ به التعريف لنفسه.
أما إسناد وقت الحوسبة بين أحمال تعمل بالتوازي فمحدود الدقة. قد يظهر حملان وكأن كلاً منهما نشط بنسبة 90%، من دون أن توضح المقاييس أيهما استهلك 70% من القدرة وأيهما استهلك 30%. لذلك يطرح التحليل استخدام ذاكرة GPU أساساً عملياً للفوترة الداخلية، مع التعامل مع قياس الحوسبة كمؤشر تشغيلي لا كمرجع دقيق لفرض الرسوم.
اختيار نموذج المشاركة يغير الحسابات
لا تعني مشاركة GPU نموذجاً واحداً. فـtime-slicing يتناوب على الجهاز من دون عزل، وMPS يسمح بتشغيل نوى من عمليات مختلفة في الوقت نفسه، بينما يقسم MIG العتاد إلى أجزاء ثابتة. ومع ذلك، قد تفرض الخدمات السحابية رسوماً على GPU الفيزيائي كاملاً حتى عند استخدام جزء منه، كما أن بطاقات فئة A100 وH100 يمكن تقسيمها إلى سبع حالات كحد أقصى وفق المادة.
أما Dynamic Resource Allocation (DRA)، فيتجه ليكون المسار المستقبلي لإدارة الموارد، لكنه لا يزال في مرحلة نضج، كما أن الأدوات المحيطة به، ومنها أدوات التوسع مثل Karpenter، تلاحق هذا التطور.
لماذا يهم هذا الخبر؟
على AWS، يبلغ سعر أرخص GPU متوافق مع MIG من فئة A100 نحو 22 دولاراً في الساعة، أو حوالي 14 دولاراً عند استخدام التسعير الفوري، مقابل نحو 5 دولارات في الساعة لمثيل مقارن يعتمد على CPU فقط، بحسب المادة. لذلك فإن الخطأ في إسناد الاستخدام لا يمثل مشكلة محاسبية صغيرة، بل قد يؤثر مباشرة في قرارات السعة والتكلفة وعدالة تحميل الفرق.
الخلاصة التحريرية أن تشغيل GPU على Kubernetes ما زال يتطلب نموذجاً تشغيلياً مختلفاً عن نموذج CPU والذاكرة. وعلى فرق المنصات تحديد ما يمكن قياسه بدقة، ووضع قواعد واضحة لتوزيع التكلفة، وتجنب بناء قرارات محاسبية على مؤشر GPU عام لا يصف الاستهلاك الحقيقي. وفي المقابل، يشير المصدر إلى أن نضج DRA وتقسيم العتاد قد يقللان الفجوة تدريجياً، لكن توقيت ذلك وحدود الأدوات الحالية يظلان سؤالين مفتوحين.
كيف أعددنا هذا الخبر؟
اعتمد الخبر على المصدر الأصلي الموضح أعلاه. قد نستخدم أدوات آلية للمساعدة في الاستخراج والتصنيف والصياغة،
لكن النشر يخضع لقواعد تمنع المحتوى المكرر والقصير أو الروتيني منخفض القيمة.
اقرأ سياستنا التحريرية.