اواتار ویڈیو تب ہی قابلِ یقین لگتی ہے جب وہ شخص وقت کے ساتھ مستقل اور ایک سا نظر آئے۔ جب چہرہ ہلنے لگے، دانت بدلتے ہوئے محسوس ہوں، لب کی ہم آہنگی (lip-sync) خراب ہو جائے یا کلپس کے درمیان موشن دوبارہ شروع ہو جائے تو لوگ فوراً نوٹس کر لیتے ہیں۔ یہ بات اواتارز کے لیے دوسری بہت سی ویڈیو جنریشن ٹاسکس کے مقابلے میں زیادہ اہم ہے، کیونکہ ناظر ایک خاص شخص کو بولتے ہوئے دیکھ رہا ہوتا ہے، اکثر بہت قریب سے اور کافی دیر تک۔

آج کی ویڈیو جنریشن کی دنیا میں، دورانیہ اب بھی سب سے نمایاں پابندیوں میں سے ایک ہے۔ بہت سے ماڈلز اور پروڈکٹس ویڈیو جنریشن کو ایک مقررہ دورانیے کے کلپ کے طور پر پیش کرتے ہیں — چند سیکنڈ، اور بہت کم سسٹمز چند منٹ سے زیادہ ویڈیو بنا سکتے ہیں۔ اواتار پروڈکٹس کے لیے یہ حد براہِ راست کسٹمر کے ورک فلو میں نظر آتی ہے۔ کسٹمرز ٹریننگ ویڈیوز، سیلز ڈیموز، پروڈکٹ واک تھروز، ایجوکیشن، سپورٹ، اور ایسے ایجنٹس کے لیے زیادہ طویل اور مستقل سینز/ویڈیوز چاہتے ہیں جو اس وقت تک بات کرتے رہیں جب تک کام مکمل نہ ہو جائے، اور ساتھ ہی وہ پرامپٹس، موشن اور اسکرپٹ پر تیزی سے نظرِ ثانی کے لیے فاسٹ پری ویو بھی چاہتے ہیں۔

HeyGen میں، اس کا نتیجہ تین واضح تقاضوں کی صورت میں نکلا:

1. طویل منظر میں یکسانیت۔ اواتار کو نہ صرف ایک مختصر کلپ کے لیے بلکہ بنائی گئی ویڈیو کے کئی حصوں میں شناخت، لب کی ہم آہنگی، تاثرات اور حرکت کی تسلسل کو برقرار رکھنا ہوتا ہے۔
2. دورانیے کی کوئی مقررہ حد نہیںایک جنریشن 10 سیکنڈ، 10 منٹ، یا ایک اوپن اینڈڈ ریئل ٹائم سیشن ہو سکتی ہے۔
3. تیز پری ویو، ریئل ٹائم یا ریئل ٹائم سے بھی تیز جنریشن۔ سسٹم کو چاہیے کہ وہ فریمز بہت جلدی بنانا شروع کرے اور یہاں تک کہ انفیرنس جاری ہونے کے دوران بھی بنائے گئے فریمز کو اسٹریم کرنے کی اجازت دے۔

یہ پوسٹ انفرینس فریم ورک کی وضاحت کرتی ہے جو ہم نے ان تقاضوں کو پورا کرنے کے لیے تیار کیا ہے۔

بنیادی ماڈل کی ساخت

یہ فریم ورک HeyGen کے اواتار ویڈیو جنریشن ماڈلز — Avatar IV اور Avatar V فیملیز — کے گرد بنایا گیا ہے۔ مجموعی طور پر، ماڈل ایک ریفرنس امیج/ویڈیو، ڈرائیونگ آڈیو، اور اختیاری ٹیکسٹ یا سین کنڈیشننگ لیتا ہے، اور پھر اس اواتار کی ایسی ویڈیو بناتا ہے جس میں درست شناخت، تاثرات اور حرکت کے ساتھ وہ بول رہا ہوتا ہے۔

بنیادی جنریشن ماڈل ایک Diffusion Transformer ہے، یا DiT، جسے flow matching کے ساتھ ٹرین کیا گیا ہے۔ کسی شخص کو ایک چھوٹے سے identity embedding میں سکیڑنے کے بجائے، ماڈل بھرپور reference tokens پر condition کرتا ہے تاکہ وہ اواتارز کے لیے اہم تفصیلات کو محفوظ رکھ سکے: چہرے کی ساخت، دانت، جلد کی بناوٹ، منہ کی حرکت، اشاروں کا انداز، اور بولنے کی لے۔

پروڈکشن انفیرنس کا راستہ تین بنیادی مراحل پر مشتمل ہے:

1. آڈیو سے ویڈیو کی تخلیق۔ ایک بنیادی DiT ریفرنس شناخت، آڈیو فیچرز اور کنڈیشننگ سگنلز سے کم ریزولوشن ویڈیو لیٹنٹس بناتا ہے۔ یہ مرحلہ حرکت، lip-sync اور زمانی ہم آہنگی پر توجہ دیتا ہے۔
2. شناخت سے باخبر سپر ریزولوشن۔ ایک دوسرا ماڈل ان لیٹنٹس کو بہتر بنا کر ہائی ریزولوشن آؤٹ پٹ میں تبدیل کرتا ہے، خاص طور پر اُن حصوں پر زیادہ توجہ دیتے ہوئے جہاں لوگ نقائص کے بارے میں سب سے زیادہ حساس ہوتے ہیں، خصوصاً چہرہ اور منہ۔
3. اسٹریمنگ VAE ڈیکوڈ۔ ایک VAE ڈیکوڈر ہائی ریزولوشن لیٹنٹس کو مرحلہ وار RGB فریمز میں تبدیل کرتا ہے، تاکہ پوری ویڈیو مکمل ہونے سے پہلے ہی فریمز نشر کیے جا سکیں۔

طویل ویڈیوز بنانے کے لیے، سسٹم ڈیٹا کو حصوں میں پروسیس کرتا ہے۔ جہاں پہلا حصہ مکمل طور پر سٹیٹک ریفرنس پر منحصر ہوتا ہے، وہیں بعد کے حصے پچھلے سیگمنٹس کے بارڈر/باؤنڈری ڈیٹا کو استعمال کرتے ہیں۔ اس سے اواتار بغیر ہر بار اپنی پوسچر یا شناخت کو شروع سے ری سیٹ کیے، قدرتی انداز میں بات چیت جاری رکھ سکتا ہے۔

اسٹریمنگ فریم ورک اور پائپ لائن لوپ

چنک پر مبنی execution کو سپورٹ کرنے کے لیے، inference فریم ورک ایک ماڈیولر، تین سطحی آرکیٹیکچر استعمال کرتا ہے جو وقت کے مقامی حصوں پر کام کرتا ہے اور ہر چنک کے پروسیس ہوتے ہی فوراً وسائل خالی کر دیتا ہے۔

• Module: کسی مخصوص ماڈل اور اس کے چیک پوائنٹ کے گرد بنایا گیا ریپر (مثلاً A2V DiT، Super-Resolution DiT، VAE کے اجزاء، text/audio encoders)۔
• اسٹیج: ایک ٹائپ شدہ ایکزیکیوشن یونٹ جو ایک یا ایک سے زیادہ ماڈیولز کو ہم آہنگ کرتا ہے (مثلاً context generation، super-resolution)۔
• پائپ لائن: وہ execution گراف جو stages کو آپس میں جوڑتا ہے، shared state کو منظم کرتا ہے، اور streaming یا batch execution modes کو ہم آہنگ کرتا ہے۔

ابتدائی مرحلہ ہر درخواست پر ایک بار ریفرنس شناخت کو لیٹنٹس میں انکوڈ کرتا ہے۔ اس کے بعد پائپ لائن باقی مراحل پر مسلسل لوپ چلاتی رہتی ہے، یہاں تک کہ ان پٹ آڈیو اسٹریم مکمل طور پر ختم ہو جائے۔

• کانٹیکسٹ جنریشنآنے والے آڈیو حصوں کو فیچرز میں تبدیل کرتا ہے، انہیں ٹیکسٹ یا سین کنڈیشننگ کے ساتھ جوڑتا ہے، اور ہدف شور ٹینسرز تیار کرتا ہے۔
• Audio-to-Video۔ کم ریزولیوشن لیٹنٹس بنانے کے لیے یہ مرحلہ کئی مراحل پر مشتمل diffusion پاس چلاتا ہے، اور حرکت کی تسلسل کو برقرار رکھنے کے لیے موجودہ حصے کو پچھلے حصے کے بارڈر فریمز پر condition کرتا ہے
• سپر ریزولوشن: ایک ہی مرحلے میں موشن لیٹنٹس کو مکمل ریزولوشن تک اپ اسکیل کرتا ہے، چہرے پر مکانی تفصیل کو ترجیح دیتے ہوئے۔
• VAE Decode-and-Publish: ہائی ریزولوشن لیٹنٹس کو RGB فریمز میں ڈی کوڈ کرتا ہے اور انہیں براہِ راست آؤٹ پٹ انکوڈر (H.264 / AAC) کو بھیجتا ہے تاکہ فوراً اسٹوریج یا لائیو پلے بیک کے لیے استعمال ہو سکیں۔

سرحدی تسلسل اور چنک کی مطابقت

ویڈیو کو الگ الگ حصوں میں بنا کر تیار کرنے سے سرحدی عدم تسلسل کے امکانات پیدا ہوتے ہیں۔ فریم ورک اس مسئلے کو دو مختلف قسم کی چنک درجہ بندی استعمال کر کے کم کرتا ہے:

• N Chunks: ایسے حصے جو اواتار کی بنیادی ٹائم لائن بناتے ہیں۔
• I Chunks (Interpolation): ایسے حصے جو مسلسل N chunks کے درمیان منتقلی کو ہموار بنانے کے لیے بنائے گئے ہیں۔

ایگزیکیوشن کا سلسلہ درج ذیل ترتیب کے مطابق منظم کیا گیا ہے۔

N0 -> N1 -> I0 -> N2 -> I1 -> N3 -> I2 -> ...

ایک I چنک صرف اس وقت تیار ہوتا ہے جب اس سے پہلے اور اس کے بعد آنے والے N چنکس مکمل ہو جائیں۔ یہ عبوری حرکت (transitional motion) کو حساب کرنے کے لیے پچھلے N چنک کے آخری فریم اور موجودہ N چنک کے ابتدائی فریم کو اینکر فریمز کے طور پر استعمال کرتا ہے۔ جنریشن کے بعد، غیر ضروری اینکر پریڈکشنز کو نکال دیا جاتا ہے، اور صرف ہموار طور پر انٹرپولیٹ کی گئی ٹرانزیشن باقی رہتی ہے۔ یہ میکانزم درکار کانٹیکسٹ ونڈو کو محدود رکھتے ہوئے وقتی تسلسل (temporal consistency) کو برقرار رکھتا ہے۔

دورانیے کے دوران مستقل میموری

روایتی ویڈیو پائپ لائن عمل کے دوران لیٹنٹس، ڈی کوڈ کی گئی فریمز اور اٹینشن کانٹیکسٹ کو جمع کرتی رہتی ہے، جس کی وجہ سے GPU میموری کا استعمال ویڈیو کے دورانیے کے ساتھ خطی طور پر بڑھتا جاتا ہے۔

اوپن اینڈڈ جنریشن کو ممکن بنانے کے لیے، یہ فریم ورک ایک سخت رولنگ اسٹیٹ برقرار رکھتا ہے۔ سسٹم صرف سٹیٹک ریفرنس کنڈیشننگ اور کم سے کم اینکر ٹینسرز محفوظ رکھتا ہے جو چنک ٹرانزیشنز کے لیے درکار ہوتے ہیں۔ تمام درمیانی اثاثے — جن میں آڈیو فیچرز، نوائز ٹینسرز، اندرونی ایکٹیویشنز، اور خام RGB فریمز شامل ہیں — کسی چنک کے ڈی کوڈ اور رائٹ ہوتے ہی فوراً میموری سے صاف کر دیے جاتے ہیں۔

نتیجتاً، GPU میموری کا زیادہ سے زیادہ استعمال ایک جیسا رہتا ہے، چاہے آپ ایک چھوٹی ویڈیو بنا رہے ہوں یا طویل سلسلہ؛ ریسورس کا استعمال سیشن کے کُل دورانیے کے بجائے متعین کردہ chunk سائز کے ساتھ تبدیل ہوتا ہے۔

پائپ لائن کے اندر لوڈنگ/آف لوڈنگ کے مراحل

ہر ریکویسٹ ایک 8-GPU نوڈ پر چلتی ہے۔ ہم بڑے ماڈل کے پیرامیٹرز کو GPUs پر تقسیم کرنے کے لیے FSDP استعمال کرتے ہیں۔ ہر رینک کے پاس ویٹس کا صرف ایک حصہ ہوتا ہے، وہ کمپیوٹیشن کے لیے درکار پیرامیٹرز اکٹھے کرتا ہے اور پھر انہیں دوبارہ خالی کر دیتا ہے۔ یہی طریقہ ہمیں یہ اجازت دیتا ہے کہ کئی بڑے ماڈلز — بیس DiT، سپر ریزولوشن DiT، ٹیکسٹ انکوڈر، آڈیو انکوڈر، اور VAE — ایک ہی نوڈ پر فِٹ ہو سکیں۔

یہ ایک سمجھوتا ہے۔ FSDP انفیرنس کے دوران کمیونیکیشن اوورہیڈ بڑھا دیتا ہے کیونکہ فارورڈ پاسز کے دوران پیرامیٹرز کو اکٹھا کرنا پڑتا ہے۔ ہم مختلف تکنیکوں کے مجموعے کا استعمال کرتے ہیں تاکہ اس اوورہیڈ کو چھپا سکیں اور جب کو-لوکیٹڈ ماڈلز استعمال میں نہ ہوں تو انہیں GPU سے ہٹا کر رکھیں:

• فارورڈ پری فیچنگ۔ اگلے بلاک کے پیرامیٹرز کا AllGather پہلے سے جاری کیا جاتا ہے اور موجودہ بلاک کی کمپیوٹیشن کے ساتھ اوورلیپ کیا جاتا ہے، جس سے اہم راستے پر گیادر کی تاخیر چھپ جاتی ہے۔
• CPU سے ہر بلاک کی سست (lazy) اَن شارڈنگ۔ جب کسی ماڈل کو pinned CPU میموری سے واپس لایا جاتا ہے، تو ہم شروع میں تمام ویٹس کا مکمل سیٹ لوڈ نہیں کرتے۔ ہر transformer بلاک کو اس کے forward پاس سے فوراً پہلے اَن شارڈ کیا جاتا ہے (host-to-device copy + AllGather)، تاکہ بلاک n+1 کی H2D ٹرانسفر بلاک n کی compute کے ساتھ اوورلیپ ہو جائے۔
• اسٹیجز کے درمیان pinned CPU offload۔ جو ماڈل اس وقت نہیں چل رہا ہوتا، اس کے parameters کو pinned CPU memory میں رکھا جاتا ہے، تاکہ ایک ہی سرور پر موجود دوسرے ماڈلز (base DiT، super-resolution DiT، text encoder، audio encoder، VAE) کو بیک وقت اپنی weights GPU پر رکھنے کی ضرورت نہ ہو۔ pinned memory ہی H2D copies کو اتنا تیز بناتی ہے کہ وہ compute کے ساتھ اوورلیپ ہو سکیں۔
• NUMA سے آگاہ پروسیس پلیسمنٹ۔ ہر پروسیس کو اس NUMA نوڈ کے ساتھ پِن کیا جاتا ہے جو اس کے مقررہ GPU سے منسلک ہوتا ہے، تاکہ CPU↔GPU ٹرانسفرز بغیر انٹر ساکٹ انٹرکنیکٹ کو کراس کیے مکمل PCIe/NVLink بینڈوڈتھ پر چل سکیں۔

اسٹیجز کے درمیان 10ms سے کم وقت میں ماڈل کی تبدیلی

اوپر بیان کی گئی تکنیکوں کا عملی فائدہ یہ ہے کہ GPU کو ایک اسٹیج کے ماڈل سے اگلے اسٹیج کے ماڈل تک منتقل کرنا — مثلاً A2V DiT → Super-Resolution DiT یا SR DiT → VAE decoder — عملی طور پر بالکل مفت پڑتا ہے۔ کیونکہ جانے والا ماڈل غیر ہم وقت (asynchronously) انداز میں offload ہو رہا ہوتا ہے اور آنے والے ماڈل کا پہلا بلاک بالکل وقت پر (just-in-time) unshard کیا جاتا ہے، اس لیے H2D copy اور AllGather دونوں اُس compute کے پیچھے چھپ جاتے ہیں جو پہلے ہی چل رہا ہوتا ہے۔ شروع سے آخر تک، ہر سوئچ پر نظر آنے والا اضافی اوورہیڈ 10ms سے کم رہتا ہے — جو ہمارے ہدف فریم ریٹس پر ایک فریم کے بجٹ سے کہیں کم ہے۔ عملی طور پر یہی چیز streaming pipeline loop (Context Gen → A2V → SR → VAE Decode-and-Publish) کو یہ قابل بناتی ہے کہ وہ ہر chunk میں کئی بڑے ماڈلز سے گزر سکے، بغیر اس کے کہ خود ماڈل کا swap کارکردگی میں رکاوٹ بنے۔

ریئل ٹائم اسٹریمنگ پبلشنگ

ماڈل کو اتنا تیز بنانے کے لیے کہ وہ ریئل ٹائم میں اسٹریم ہو سکے، ہم نے انفیرنس میں بہت سی آپٹیمائزیشنز کی ہیں، براہ کرم رجوع کریں https://www.heygen.com/research/avatar-v-inference اس حصے کی مزید تفصیلات کے لیے۔

جب پائپ لائن ریئل ٹائم میں ویڈیو کو حصّہ بہ حصّہ خارج کرتی ہے، تو اسٹریمنگ ڈیلیوری الگ پوسٹ پروسیسنگ مرحلے کے بجائے خود بخود انفیرینس کا قدرتی تسلسل بن جاتی ہے۔

براڈکاسٹ اسٹائل ریئل ٹائم راستے کے لیے، ہم تیار کردہ فریمز کو Amazon Kinesis Video Streams (KVS) پر پبلش کرتے ہیں۔ KVS عموماً کیمروں، IoT ڈیوائسز اور اپ لوڈ کی گئی میڈیا فائلوں کے تناظر میں زیرِ بحث آتا ہے۔ ہماری صورت میں "کیمرہ" خود انفیرنس پائپ لائن ہے: فریمز ماڈل کے ذریعے بنائے جاتے ہیں، فوراً انکوڈ کیے جاتے ہیں، اور KVS میں لائیو اسٹریم کے طور پر بھیج دیے جاتے ہیں۔

آؤٹ پٹ رائٹر کو streaming VAE سے ڈی کوڈ کی گئی RGB فریمز ملتی ہیں اور وہ انہیں GStreamer پائپ لائن میں بھیجتا ہے۔ ویڈیو کو H.264 کے طور پر اور آڈیو کو AAC کے طور پر انکوڈ کیا جاتا ہے، پھر دونوں ٹریکس کو kvssink، یعنی KVS پروڈیوسر سنک، میں بھیج دیا جاتا ہے۔ وہاں سے ناظرین سیشن کو اسی وقت لائیو اسٹریم کے طور پر چلا سکتے ہیں جب وہ ابھی تخلیق ہو رہا ہوتا ہے۔

نتائج اور سیکھیں

اس فریم ورک نے Avatar IV اور Avatar V کی جنریشن کو فکسڈ سین رینڈرنگ سے اوپن اینڈڈ اسٹریمنگ جنریشن میں تبدیل کر دیا ہے۔ سب سے اہم نتیجہ بہت سادہ ہے: ہم نے Avatar IV اور Avatar V کے لیے سین کے دورانیے کی حدیں ختم کر دی ہیں۔ ریئل ٹائم Avatar IV جنریشن کے لیے، ہم نے پہلے فریم تک پہنچنے کا وقت 5 سیکنڈ سے کم حاصل کیا ہے اور 720p Avatar IV ویڈیوز کے لیے 27+ فریم فی سیکنڈ کی رفتار سے جنریشن حاصل کی ہے — جو ریئل ٹائم پلے بیک سے بھی تیز ہے۔