نموذج LTX-2.5 بـ22 مليار معامل يعمل على RTX 3080 بذاكرة 10 غيغابايت، لكنه يستغرق 5 دقائق للقطة الواحدة

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

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

كيف تمر أوزان بحجم 39 غيغابايت عبر ذاكرة فيديو بسعة 10 غيغابايت

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

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

لا تختفي الذاكرة هنا، بل تنتقل من بطاقة الرسوميات إلى RAM. وبحسب تقدير الكاتب، يتطلب هذا الأسلوب 32 غيغابايت من الذاكرة العشوائية على الأقل (والأفضل 64) وملف تبديل لا يقل عن 32 غيغابايت. لذلك لا تكفي عبارة «يعمل على 10 غيغابايت» لوصف المتطلبات.

عقبتان: safetensors تحت Windows وتفريغ لا يفرّغ

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

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

أين يذهب الوقت فعلًا

لإعادة التشغيل ثمن. فبحسب قياسات أولية، تستغرق اللقطة الواحدة نحو خمس دقائق، وتستغرق إزالة الضوضاء نفسها نحو 25 ثانية. وهذا يتوافق مع حساب الخطوات: 8 خطوات بـ1,4 ثانية زائد 3 خطوات بـ5 ثوانٍ تعطي نحو 26 ثانية. ويذهب الوقت المتبقي في قراءة وتحضير نحو 65 غيغابايت من أوزان المحوّل ومشفّر Gemma، وفي كل لقطة من جديد.

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

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

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