تشغيل نموذج فيديو بـ22 مليار معامل على RTX 3080 بذاكرة 10 غيغابايت

شغّل صاحب بطاقة RTX 3080 بذاكرة فيديو 10 غيغابايت نموذج الفيديو LTX-2.5 بـ22 مليار معامل، أي 22 مليار رقم قابل للتدريب هي أوزان النموذج. يشغل المحوّل وحده، وهو الجزء الرئيسي من النموذج، 39 غيغابايت، ويضيف مشفّر النصوص Gemma 24,5 غيغابايت أخرى. نظريًا لا تتسع بطاقة بذاكرة 10 غيغابايت لهذه الحزمة. وعمليًا تعمل، لكنها تدفع الثمن من الذاكرة العشوائية والوقت وعناء إعداد البيئة. ويصف المؤلف جميع قياسات الوقت في هذه المادة بأنها ملاحظات أولية، وليست اختبار أداء قابلًا لإعادة الإنتاج.

كيف تمرّ 65 غيغابايت من الأوزان عبر 10 غيغابايت من ذاكرة الفيديو

يجمّع المؤلف مقاطع عمودية من 6–8 لقطات. وتعمل عدة نماذج على جهاز واحد بالتتابع:

• Gemma عبر llama.cpp تساعد في كتابة السيناريو؛ • FLUX.2 [klein] يرسم الإطارات بوجه البطل نفسه؛ • LTX-2.5 يحرّك الإطارات؛ • Qwen3-TTS يتولى التعليق الصوتي؛ • ACE-Step يؤلّف الموسيقى؛ • ffmpeg يجمع المونتاج.

يتلقى LTX صورة جاهزة ويحوّلها إلى لقطة فيديو قصيرة. ويستخدم المؤلف نسخة distilled، أي النسخة المبسّطة والأسرع. يجري التوليد على مرحلتين. أولًا 8 خطوات من إزالة الضوضاء (التنقية التدريجية للصورة من الضوضاء) بدقة منخفضة، بنحو 1,4 ثانية للخطوة. ثم يضاعف مكبّر كامن (latent upscaler) الدقة. بعد ذلك تأتي 3 خطوات إضافية بالدقة الكاملة 576×1024، بمعدل 5 ثوانٍ للخطوة.

يتسع كل ذلك في الذاكرة بفضل مفتاحين من مستودع Lightricks/LTX-2:

• --quantization fp8-cast: تُخزَّن الأوزان بصيغة bf16 وتُحوَّل إلى fp8 عند تحميلها على GPU. تنخفض الحاجة إلى الذاكرة إلى النصف، ولا حاجة إلى نقطة حفظ fp8 منفصلة. • --offload cpu: تبقى كتل المحوّل في الذاكرة العشوائية وتُمرَّر إلى بطاقة الرسوميات واحدة تلو الأخرى أثناء الحساب. • المتغيّر PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True يزيل أخطاء نفاد الذاكرة الناجمة عن التجزئة في اللقطات الطويلة.

لا تختفي الذاكرة هنا، بل تنتقل إلى مكان آخر. يلزم 32 غيغابايت على الأقل من الذاكرة العشوائية، والأفضل 64، وملف تبديل لا يقل عن 32 غيغابايت. وعبارة «يعمل على 10 غيغابايت» دون هذه التحفظات مضلِّلة.

عقبتان: safetensors على Windows وذاكرة لا تتحرر

لم يصل التشغيل الأول إلى مرحلة التوليد أصلًا. فقد انتهى بخطأ access violation (وصول مخالف إلى الذاكرة) عند فتح الأوزان، دون رسالة مفهومة. وفي بيئة المؤلف تبيّن أن السبب هو قراءة ملفات safetensors الكبيرة على Windows. فقد حاولت المكتبة تعيين الملف في الذاكرة بالكامل، وتعطلت مع الملفات التي يتجاوز حجمها نحو 2 غيغابايت.

تجاوز المؤلف ذلك باستبدال الدالة safe_open. فبدل القراءة القياسية يعمل np.memmap للقراءة فقط. يُحلَّل رأس الملف يدويًا، وتُسلَّم التنسورات على شكل عروض (views) فوق الملف المعيَّن في الذاكرة. لا توجد نسخة منفصلة من الأوزان في ذاكرة commit، وتبقى الواجهة كما هي، ولم تكن هناك حاجة إلى تعديل شيفرة LTX. يوضع التصحيح في site-packages، ويستبدل ملف .pth الذي يحتوي import ltx_sft_patch الوحدة عند إقلاع المفسّر.

المشكلة الثانية هي تفريغ النماذج. في البداية كان كل نموذج يعيش في عملية عاملة (worker) دائمة: ينتهي من عمله، ثم يُستدعى unload، وتُسلَّم البطاقة للنموذج التالي. لكن مع CPU-offload بقي جزء من ذاكرة الفيديو والذاكرة العشوائية المثبَّتة مشغولًا بعد هذا التفريغ، فلم يتسع النموذج التالي. ولم ينجح بشكل موثوق إلا إنهاء العملية بالكامل. لذلك صار لكل نموذج عملية خاصة وبيئة venv خاصة، أما LTX فتُطلَق عمليته عند كل لقطة. وتحل البيئات المنفصلة مشكلة أخرى أيضًا: فالنماذج تحتاج إلى إصدارات متعارضة من torch وdiffusers.

خمس دقائق للقطة و25 ثانية للحساب

تكلفة إعادة تشغيل العمليات تُدفع من الوقت. وبحسب القياسات الأولية، تستغرق اللقطة الواحدة نحو خمس دقائق، بينما تستغرق إزالة الضوضاء نفسها نحو 25 ثانية فقط، أي أقل من 10% من الوقت. أما بقية الوقت فيذهب في قراءة نحو 65 غيغابايت من أوزان المحوّل ومشفّر Gemma وتجهيزها. ويتكرر ذلك مع كل لقطة.

استنتاجات لمن يبني خط معالجة مشابهًا:

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

ويشارك المؤلف كذلك حيلًا للحصول على حركة صالحة للاستخدام:

• يجب أن يُظهر الإطار الأول الحالة السابقة للفعل. فإذا كان الباب مفتوحًا أصلًا بينما يطلب الوصف النصي (prompt) فتحه، يبدأ النموذج بتخمين ما يجري. • يُقسَّم تلامس اليدين مع الأشياء إلى لقطتين. في الأولى تمتد اليد نحو المقبض، وبعد القطع يكون الباب مفتوحًا. أما اللحظة التي تخترق فيها الأصابع المقبض فتبقى خارج الكادر. • إذا كانت نهاية الحركة مهمة، يُمرَّر الإطار الأخير كمعامل ثانٍ عبر --image. • لمزامنة الشفاه مع الكلام تلزم خطة أخرى: النموذج الكامل غير distilled، وdistilled-LoRA، وفرع الصوت a2vid_two_stage. ويؤخذ من النتيجة الفيديو فقط، ويبقى الصوت من التعليق الصوتي.

الخلاصة: يعطي نموذج فيديو بـ22 مليار معامل على بطاقة منزلية بذاكرة 10 غيغابايت نتيجة عملية للمقاطع القصيرة. كل شيء يجري محليًا، دون سحابة ودون اشتراكات. والقيود معروفة: حاجة كبيرة إلى الذاكرة العشوائية، وتحميل طويل للأوزان عند كل لقطة، وبيئات منفصلة لكل نموذج.