تولید یک کلیپ ۵ ثانیه‌ای با صدای هماهنگ، حالا به سخت‌افزاری با ابعاد غول‌آسا نیاز دارد. در ۶ اکتبر ۲۰۲۴، آزمایشگاه Kandinsky (Kandinsky Lab) مدل Kandinsky 6.0 را تحت مجوز MIT منتشر کرد. این مدل هم کد و هم وزن‌های خود را در اختیار عموم قرار داده است تا کاربران بتوانند پرامپت‌های متنی یا تصویری را به کلیپ‌های صوتی-تصویری هماهنگ تبدیل کنند.
این عرضه در حالی رخ می‌دهد که صنعت به سمت مدل‌های چندوجهی (Multimodal) — شبیه به انسانی که هم‌زمان می‌بیند، می‌شنود و می‌نویسد — با وزن‌های باز (Open Weights) حرکت می‌کند تا بتوان آن‌ها را به‌صورت محلی میزبانی کرد. برای توسعه‌دهندگان، چالش دیگر صرفاً نوشتن پرامپت نیست، بلکه مدیریت حافظه فیزیکی برای انتقال وزن‌ها از رم سیستم به واحد پردازش گرافیکی (GPU) در لحظه استنتاج (Inference) است. استنتاج در واقع همان لحظه‌ای است که مدل واقعاً جواب تولید می‌کند و شبیه به خودِ آشپزی است، نه دوره‌ی آموزش آشپز.
همان‌طور که در تحلیل‌های قبلی ما درباره‌ی مدل‌های مولد ویدیو اشاره کردیم، مدیریت VRAM همواره بزرگ‌ترین مانع در برابر دموکراتیزه شدن این ابزارها بوده است.
زمینه و جزئیات فنی
به نقل از مستندات فنی، Kandinsky 6.0 ترکیبی از چندین معماری برجسته است. این مدل برای بازنویسی پرامپت‌ها از Qwen2.5-VL علی‌بابا و برای تحلیل تصویر از CLIP شرکت OpenAI استفاده می‌کند. بخش تولید ویدیو بر پایه طراحی دکودر HunyuanVideo تنسنت است و تولید صدا توسط MMAudio و BigVGAN انویدیا مدیریت می‌شود. بهره‌وری این مدل مدیون روش distillation (تقطیر) به نام π-Flow و کتابخانه‌های توجهی پیشرفته است. از جمله این کتابخانه‌ها می‌توان به توجه برق‌آسا (FlashAttention 3) که توسط Tri Dao و همکارانش توسعه یافته و همچنین SageAttention (محصول گروه thu-ml دانشگاه تسینگ‌هوا) اشاره کرد.
در روز انتشار، این مدل توسط ابزارهایی مثل Diffusers، ComfyUI، vLLM-Omni، SGLang و FastVideo پشتیبانی شد. این اکوسیستم اجازه می‌دهد مدل از طریق پروتکل HTTP سرویس‌دهی شود، هرچند حجم عظیم وزن‌ها استراتژی استقرار خاصی را می‌طلبد. این رویکرد در استقرار مدل‌های سنگین، یادآور تلاش‌های اخیر برای بهینه‌سازی سرعت پردازش است، مشابه آنچه در بهبود سرعت توکنایزرهای Hugging Face برای رفع گلوگاه‌های CPU مشاهده کردیم.
بر اساس مستندات Kandinsky Lab، این مدل در دو اندازه متمایز عرضه شده است:
- Lite: دارای ۳ میلیارد پارامتر.
- Pro: دارای ۲۹ میلیارد پارامتر.
مکانیسم‌های حافظه و Offload
نسخه Pro یک غول سخت‌افزاری است که حدود ۹۰ گیگابایت فضای دیسک اشغال می‌کند. از آنجا که تنها بخش تولید فریم ۷۰ گیگابایت فضا می‌گیرد، مدل در اکثر GPUهای استاندارد جا نمی‌شود. در نتیجه، سیستم از مکانیسم «Offload» استفاده می‌کند؛ یعنی وزن‌ها در رم سیستم (Host RAM) می‌مانند و در حین تولید، به‌صورت تکه‌تکه به GPU منتقل می‌شوند.
- حالت Module: مخصوص کارت‌های H100، A100 و RTX PRO 6000 که هر بار یک جزء کامل از مدل را منتقل می‌کند.
- حالت Block: مخصوص کارت‌های گیمینگ که دو برش از تولیدکننده فریم را در GPU نگه می‌دارد و در حالی که برش بعدی در حال کپی شدن است، از این دو استفاده می‌کند.
از آنجا که هیچ تنظیم پیش‌فرضی گزینه --offload none را در خط فرمان (CLI) فعال نمی‌کند، رم سیستم به یک پیش‌نیاز حیاتی تبدیل شده است، هرچند حداقل مقدار رم منتشر نشده است. راهنمای vLLM-Omni صراحتاً ذکر کرده که حتی روی کارت‌های ۸۰ گیگابایتی نیز Offload «الزامی» است.
عملکرد سخت‌افزاری
عملکرد سخت‌افزاری بسته به این جابه‌جایی حافظه به‌شدت تغییر می‌کند. جدول زمان‌بندی Kandinsky Lab برای مدل‌های استاندارد که نویزهای تصادفی را طی ۵۰ پاس (پس از یک اجرای گرم‌کننده یا Warm-up) پاک می‌کنند — بدون احتساب زمان لود مدل و نوشتن فایل — نشان می‌دهد:
- H100 (80 GB): ۲۹۲ ثانیه برای هر کلیپ HD Pro (حدود ۱۲ کلیپ در ساعت).
- RTX 4090 (24 GB): ۱۱۹۴ ثانیه برای هر کلیپ HD Pro (حدود ۳ کلیپ در ساعت).
- RTX 5060 Ti (16 GB): ۲۷۱۶ ثانیه برای هر کلیپ HD Pro (حدود ۱.۳ کلیپ در ساعت).
نکته جالب این است که VRAM بیشتر همیشه به معنای سرعت بیشتر نیست. کارت RTX PRO 6000 با ۹۶ گیگابایت حافظه — ۱۶ گیگابایت بیشتر از H100 — برای تولید همان کلیپ به ۵۶۱ ثانیه زمان نیاز دارد. این موضوع نشان می‌دهد که سرعت خام تراشه و کتابخانه‌های توجهی خاص (مانند FlashAttention 3 در H100 در برابر SageAttention در سایرین) نقش بسیار مهم‌تری نسبت به ظرفیت کل حافظه ایفا می‌کنند. این تضاد بین حجم حافظه و سرعت استنتاج، ما را به یاد بهینه‌سازی‌های مدل‌های Jeff برای رسیدن به سرعت ۲۲ میلی‌ثانیه می‌اندازد که در آن معماری مدل بر حجم داده‌ها اولویت داشت.
شکاف تقطیر (Distillation Gap)
یک شکاف عملکردی پنهان در مستندات رسمی وجود دارد. دموی عمومی در Hugging Face از نسخه «تقطیر شده» (Distilled) Pro استفاده می‌کند. این نسخه به‌گونه‌ای آموزش دیده است که به‌جای ۵۰ پاس، در ۱۰ پاس به پایان برسد و ۸۱ گیگابایت فضا می‌گیرد (به جای ۹۰ گیگابایت).
اگرچه کاهش پاس‌ها به یک‌پنجم، از نظر تئوریک نویدبخش افزایش سرعت پنج برابری است، اما Kandinsky Lab زمان‌بندی رسمی برای این نسخه پیش‌فرض منتشر نکرده است. کاربران باید این بخش از داده‌های عملکردی را تا زمان دستیابی به اندازه‌گیری‌های واقعی، خالی بگذارند.
بزرگ‌نمایی (Upscaling) و صدا
برای رسیدن به کیفیت Full HD، یک خط لوله دو مرحله‌ای اجرا می‌شود. مدل ابتدا در ابعاد ۸۶۴ در ۴۸۰ تولید می‌کند و سپس یک مدل فراتفکیک‌پذیری (Super-resolution) مجزا — شبیه به ذره‌بین‌های دیجیتالی که جزئیات را با بازترسیم تک‌تک تایل‌ها بازسازی می‌کنند — نتیجه را بزرگ‌نمایی می‌کند. در H100، یک نسخه ۲ مرحله‌ای برای بزرگ‌نمایی ۲ برابر ۴۱ ثانیه و برای ۴ برابر ۱۱۸ ثانیه زمان می‌برد. چون این مرحله فقط روی فریم‌ها کار می‌کند، کاربر باید صدا را به‌صورت دستی از تولید اولیه جدا کرده و دوباره متصل کند. هیچ داده‌ای از زمان‌بندی این فرآیند برای کارت‌های گیمینگ وجود ندارد.
این معماری پیش‌فرض‌های استقرار هوش مصنوعی ویدیو را تغییر می‌دهد. دیگر نمی‌توان با این مدل مانند یک API هم‌زمان (Synchronous) برخورد کرد؛ این یک «کار دسته‌ای» (Batch Job) است. توسعه‌دهندگان باید الگویی را پیاده کنند که در آن کاربر یک درخواست ارسال کند، یک ID دریافت نماید و سپس برای دریافت نتیجه، وضعیت را نظارت (Poll) کند. این تغییر در مدل استقرار، شباهت زیادی به سیستم‌های اتوماسیون صف‌های ویدیو در Shadow دارد که برای مدیریت حجم بالای تولید محتوا طراحی شده‌اند.
چک‌لیست پیاده‌سازی
از دیدگاه عملی، برچسب «Pro» یک قمار است. مدل Pro بین ۱.۴ تا ۲.۸ برابر زمان GPU بیشتری نسبت به نسخه Lite می‌گیرد، اما در حال حاضر هیچ داده‌ای منتشر نشده که ثابت کند جهش کیفی، این هزینه زمانی را توجیه می‌کند.
برای اندازه‌گیری دقیق روی سخت‌افزار خود، باید پروفایلینگ را به‌صورت دستی فعال کنید. با کپی کردن یک Preset (مثلاً cp kandinsky/configs/devices/rtx-5090.yaml my-5090.yaml) و افزودن profile: mode: time_mem_module به فایل YAML، می‌توانید هزینه دقیق بخش‌های زیر را بسنجید:
- DiT: تولیدکننده فریم.
- Video VAE & Audio VAE: دکودرهایی که نتیجه را به فریم و صدا تبدیل می‌کنند.
- Vocoder: بخشی که صدا را به موج صوتی (Waveform) تبدیل می‌کند.
استفاده از فلگ --warmup باعث می‌شود اولین تولید نادیده گرفته شود و فقط دومی زمان‌بندی شود. توجه کنید که total_time شامل کدگذاری MP4، اتصال صدا و بازنویسی پرامپت توسط Qwen2.5-VL است، در حالی که جدول رسمی این موارد را حذف کرده است.
منتظر تلاش‌های جامعه متن‌باز برای فشرده‌سازی باشید. در حالی که وزن‌های رسمی حجیم هستند، نسخه‌های فشرده‌شده‌ای از مدل Pro توسط مشارکت‌کنندگانی مانند realrebelai در حال ظهور است تا مدل برای کارت‌های مصرف‌کننده کوچک‌تر کاربردی شود.
گام بعدی شما
- اگر کارت گرافیکی با VRAM پایین دارید، به‌جای نسخه Pro، ابتدا نسخه Lite را برای تست گردش‌کار خود به کار ببرید.
- برای استقرار در محیط تولید، معماری سیستم خود را از حالت Synchronous به Queue-based (صف‌بندی) تغییر دهید.
- در گیت‌هاب به دنبال نسخه‌های Quantized یا فشرده‌شده توسط جامعه توسعه‌دهندگان بگردید تا نیاز به ۹۰ گیگابایت دیسک کاهش یابد.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو