عندما لا يبدأ NVENC: وحدة معالجة رسومات ممتلئة بالنماذج، ومُصيّر يعود إلى وضع الاحتياط
الفيديو
يعمل مُصيّر الفيديو لدينا على الجهاز نفسه الذي يعمل عليه النموذج اللغوي الذي يكتب نصوصه. في أحد المساءات، لم يفتح المُرمِّز العتادي ببساطة: «CUDA_ERROR_OUT_OF_MEMORY: نفاد الذاكرة»، ثم «لم يتم العثور على أجهزة مؤهلة».
ماذا حدث
الجهاز هو سطح مكتب NVIDIA GB10، حيث يتشارك المعالج المركزي ومعالج الرسومات في مجمّع ذاكرة واحد. إنه يخدم نموذجنا المحلي عبر vLLM، ويعمل Studio على نفس الجهاز باستخدام ffmpeg، مستخدماً NVENC عندما يكون ذلك ممكناً. أثناء تشغيل تجريبي، فشل المُرمِّز في إنشاء سياق CUDA الخاص به. جاء الفشل وذهب خلال ثوانٍ: نجح فحص NVENC قصير وفشل التصيير مباشرة بعده؛ في التشغيل التالي فشل الفحص نفسه؛ وفي التشغيل الذي يليه، مرّ كل من الفحص والتصيير عبر NVENC.
لماذا
يخصص vLLM حصة ثابتة من ذاكرة وحدة معالجة الرسومات عند بدء التشغيل، للنموذج وذاكرته المؤقتة. يحتاج NVENC إلى القليل من الذاكرة الخاصة به لكل جلسة من جلسات سياق CUDA. عندما لا يترك خادم النموذج والمهام الأخرى شيئاً، لا يستطيع المُرمِّز البدء، رغم أنه محرك منفصل على الشريحة وكان سيكاد لا يمس قوة الحوسبة في وحدة معالجة الرسومات.
الإصلاح: اتخذ القرار عند الترميز، وليس عند الفحص
يخبرك الفحص عند بدء التشغيل أن NVENC عمل قبل لحظة، وليس أنه سيعمل للملف التالي. لذا يحاول Studio استخدام NVENC لكل تصيير، وإذا فشل ffmpeg، يعيد تشغيل نفس مخطط المرشحات باستخدام libx264. يشغّل البث المباشر ترميزاً اختبارياً مدته نصف ثانية بإعدادات البث المباشر قبل كل بدء تشغيل، ويستخدم libx264 إذا فشل NVENC في هذا الاختبار؛ ويحوّل خطأ NVENC أو CUDA أثناء البث بدء التشغيل التالي إلى libx264. يسجل كل فيديو مكتمل المُرمِّز الذي أنتجه، بحيث يظهر الرجوع إلى وضع الاحتياط في ملف المهمة بدلاً من المرور دون ملاحظة.
تكلفة الرجوع إلى وضع الاحتياط
أقل مما توقعنا. على معالج Arm المكون من 20 نواة في الجهاز نفسه، صيّر libx264 12 ثانية من فيديو بدقة 1080p، مع حركات الكاميرا، والتعليقات النصية المدمجة، وتطبيع مستوى الصوت، في 7.6 ثانية. للفيديوهات القصيرة التي تُنتج مرة واحدة يومياً، يكون المعالج المركزي مُرمِّزاً جيداً تماماً. وحدة معالجة الرسومات أهم بكثير للنموذج الصوري منها للترميز.
الخلاصة
على جهاز مشترك، تعامل مع مُرمِّز وحدة معالجة الرسوميات (GPU) على أنه اختياري: استخدمه عندما يكون متاحًا، وانتقل إلى البديل عندما لا يكون كذلك، وسجّل أيًّا منهما استخدمت. وينطبق الأمر نفسه على أي ميزة من ميزات وحدة معالجة الرسوميات تحتاج إلى ذاكرة خاصة بها على جهاز يكون خادم النماذج قد استحوذ فيه على معظم الذاكرة. تأتي Studio مع هذا السلوك مفعّلًا افتراضيًا.