Viggle تفتح مصدر LoRA لنموذج MiniMax-H3: استبدال الأشخاص في الفيديو يعمل بذاكرة فيديو من 12 غيغابايت

نشرت Viggle مشروع Viggle Remake، وهو زوج من محوّلات LoRA المفتوحة، أي محوّلات مدمجة لنموذج الفيديو MiniMax-H3. تعيد هذه المحوّلات صياغة فيديو جاهز مع الحفاظ على ما يتعطل عادةً في التعديل التوليدي: تبقى الحركة ووضع الكاميرا والتوقيت والصوت من المقطع الأصلي. ولا يتغير إلا ما رسمتَه صراحةً على الإطارات المفتاحية. يمكن تشغيل المحوّلات محليًا: ففي ComfyUI تكفي بطاقة رسوميات بذاكرة 12 غيغابايت (VRAM) بدقة 832×480 وبأوزان مكمَّمة Q4_K_M أو Q8_0. الأوزان متاحة على HuggingFace، ويمكن تجربة النموذج دون جهاز خاص عبر تطبيق Viggle.

وضعان للعمل وكيفية استخدامهما

تتألف المجموعة من محوّلين. يتولى Swap استبدال الأشخاص والشخصيات، سواء كان شخصًا واحدًا أو عدة أشخاص دفعة واحدة. أما Edit فيتكفل بكل ما عدا ذلك: الأشياء والخلفية والطقس والإضاءة والأسلوب.

تم تدريب كلتا الـLoRA برتبة rank 256 على المحوّل (transformer) H3، ويبلغ حجم كل منهما 2,67 غيغابايت. ولمن يعاني من ضيق المساحة أو الذاكرة تتوفر نسخ low-rank بحجم 1,34 و0,67 غيغابايت. ووفق المطورين، فإن جودتها قريبة جدًا من النسخة الكاملة.

تُقدَّم إلى النموذج مدخلات هي الفيديو الأصلي، ومن إطار واحد إلى أربعة إطارات «مرسومة»، ونص توجيهي (prompt). وسير العمل بسيط: تأخذ إطارًا من المقطع الأصلي وتعدّله في أي محرر، فتضيف بطلًا جديدًا أو تحذف عنصرًا زائدًا أو ترسم عاصفة رعدية. ينقل النموذج من هذه الإطارات المظهر والأسلوب، ويأخذ الحركة والكاميرا من المقطع الأصلي.

وللمشاريع الطويلة أصدرت Viggle خادم MCP. بواسطته يستطيع وكيل مبني على Claude Code أو Codex أن يقسّم الفيلم إلى نوافذ، ويرسم الإطارات المفتاحية، ويصيّر المقاطع، ثم يدمجها مع الصوت بنفسه.

متطلبات العتاد

يكفي في ComfyUI حزمة العُقد (nodes) الخاصة بـViggle: توضع في custom_nodes، وتوضع LoRA في models/loras. وتتوفر في المستودع مسارات عمل (workflows) جاهزة لـswap وedit. وتوصيات ذاكرة الفيديو كالتالي:

• 12 غيغابايت — Q4_K_M أو Q8_0 مع الخيار --reserve-vram 8، بدقة 832×480؛
• 16 غيغابايت — int8 دون خيارات إضافية، بدقة 832×480؛
• 24 غيغابايت — int8 أو Q4 بدقة 832×480؛ ولدقة 1280×736 يلزم Q4 أو Q8 مع --reserve-vram 20؛
• 48 غيغابايت — Q8_0 بدقة 1280×736؛
• 80 غيغابايت — bf16 مع LoRA.

تحتاج الذاكرة العشوائية (RAM) إلى 47–55 غيغابايت عند دقة 832×480، وإلى 55–80 غيغابايت عند 1280×736. أما bf16 بدقة 1280×736 فيتطلب 127 غيغابايت. وثمة تحفظ مهم: إعدادات 12–24 غيغابايت اختُبرت بمحاكاة على B200 لا على بطاقات استهلاكية حقيقية، لذا قد تختلف الخيارات على العتاد الفعلي.

طول المقطع والسرعة

النافذة الواحدة مصمَّمة لما بين 90 و345 إطارًا. يُضبط المعامل --frames وفق الصيغة 17n+5، وينصح المطورون بعدم تجاوز 294 إطارًا، أي نحو 12 ثانية بمعدل 24 إطارًا في الثانية. أما المقاطع الأطول فيجب تقسيمها إلى نوافذ، ويتولى خادم MCP هذه المهمة الروتينية.

وبحسب القياسات على B200، يُصيَّر مقطع 832×480 من 226 إطارًا في نحو 95 ثانية في ComfyUI، وفي 58 ثانية عبر السكربت sample.py. ويستغرق التشغيل الأول في ComfyUI من 2,5 إلى 3 دقائق. وعند دقة 1280×736 يمتد التصيير إلى 510–585 ثانية.

ما الذي يعنيه ذلك عمليًا

أهم ما في الإصدار هو فصل الأدوار. فالحركة والكاميرا والصوت تأتي من تصوير حقيقي، بينما تقتصر مهمة الشبكة العصبية على الاستبدال البصري. وبالنسبة إلى المونتيرين وصنّاع الإعلانات والمقاطع الموسيقية، فهذا أنسب من توليد المقطع كاملًا من الصفر: إذ لا يتفكك الإيقاع ولا تركيب اللقطة.

والأرقام الزمنية مأخوذة من B200، لذا سيكون التصيير على البطاقات المنزلية أبطأ بوضوح. ومع ذلك يبدأ حد الدخول من 12 غيغابايت من ذاكرة الفيديو ومن النسخ المكمَّمة للنموذج، فلا تقتصر الأداة على الاستوديوهات التي تملك وحدات GPU من فئة الخوادم. وقد وضع المطورون التفاصيل الخاصة بكتابة التوجيهات (prompting) وإعداد ComfyUI في أدلة مستقلة داخل المستودع.