Nagiging kapani-paniwala lang ang avatar video kung nananatiling pare-pareho ang itsura ng tao sa paglipas ng panahon. Kapag lumilihis ang mukha, nag-iiba ang ngipin, sumasablay ang lip sync, o biglang nagre-reset ang galaw sa pagitan ng mga clip, agad itong napapansin ng mga tao. Mas mahalaga ito para sa mga avatar kaysa sa maraming ibang gawain sa pagbuo ng video dahil pinapanood ng manonood ang isang partikular na tao na nagsasalita, kadalasan nang malapitan, at sa mahabang oras.

Sa mundo ng video generation ngayon, ang tagal ng video ay isa pa rin sa pinaka-kitang limitasyon. Maraming modelo at produkto ang naglalabas ng generation bilang fixed-length na clip — ilang segundo lang, at kakaunti ang mga sistema na kayang gumawa ng higit sa ilang minuto. Para sa mga avatar na produkto, direktang nakikita ang limitasyong ito sa mga workflow ng customer. Gusto ng mga customer ng mas mahahaba at konsistent na mga eksena/video para sa training videos, sales demos, product walkthroughs, edukasyon, support, at mga agent na dapat patuloy na nagsasalita hanggang matapos ang gawain, at gusto rin nila ng mabilis na preview para makapag-iterate sa prompts, galaw, at script.

Sa HeyGen, humantong iyon sa tatlong kongkretong pangangailangan:

1. Pagiging konsistent sa mahabang eksenaKailangang mapanatili ng avatar ang pagkakakilanlan, lip sync, ekspresyon, at tuloy-tuloy na galaw hindi lang sa isang maikling clip, kundi sa maraming magkakahiwalay na bahagi ng ginawang video.
2. Walang nakatakdang limit sa haba ng tagalMaaaring tumagal ang isang generation nang sampung segundo, sampung minuto, o maging isang bukas na real-time na session.
3. Mabilis na preview, realtime o mas mabilis pa sa realtime na pagbuo. Dapat agad magsimulang gumawa ng mga frame ang sistema at payagan pa na i-stream palabas ang mga nabubuong frame habang nagpapatuloy pa ang inference.

Tatalakayin sa post na ito ang inference framework na ginawa namin upang matugunan ang mga kinakailangang iyon.

Ang Batayang Arkitektura ng Modelo

Ang framework ay nakabatay sa mga avatar video generation model ng HeyGen — ang mga pamilya ng Avatar IV at Avatar V. Sa mataas na antas, kumukuha ang model ng reference na imahe/bidyo, driving audio, at opsyonal na text o scene conditioning, at pagkatapos ay lumilikha ito ng bidyo ng avatar na iyon na nagsasalita na may tamang pagkakakilanlan, ekspresyon, at galaw.

Ang pangunahing generation model ay isang Diffusion Transformer, o DiT, na sinanay gamit ang flow matching. Sa halip na i-compress ang isang tao sa isang maliit na identity embedding, ang modelo ay nagko-condition sa mayamang reference tokens para mapanatili ang mga detalyeng mahalaga para sa mga avatar: hugis ng mukha, ngipin, tekstura ng balat, galaw ng bibig, istilo ng kilos, at ritmo ng pagsasalita.

Ang production inference path ay may tatlong pangunahing yugto:

1. Pagbuo mula audio tungo sa video. Isang base na DiT ang lumilikha ng low-resolution na mga video latent mula sa reference na identity, mga audio feature, at mga conditioning signal. Nakatuon ang yugtong ito sa galaw, lip sync, at temporal na pagkakaugnay-ugnay.
2. Identity-aware super-resolution. Isang pangalawang modelo ang nagre-refine sa mga latent na iyon tungo sa high-resolution na output, na may dagdag na atensyon sa mga bahagi kung saan pinaka-sensitibo ang mga tao sa mga artifact, lalo na sa mukha at bibig.
3. Streaming VAE decodeAng isang VAE decoder ay nagko-convert ng high-resolution na mga latent sa mga RGB frame nang pira-piraso, para maipalabas na ang mga frame bago pa man matapos ang buong video.

Para makagawa ng mahahabang video, pinoproseso ng system ang data nang pira-piraso. Habang ang unang bahagi ay umaasa nang buo sa static na reference, ang mga kasunod na bahagi ay gumagamit ng boundary data mula sa naunang mga segment. Dahil dito, nagagawang magpatuloy magsalita ng avatar nang natural nang hindi kailangang i-reset mula sa simula ang postura o pagkakakilanlan nito.

Ang Streaming Framework at Pipeline Loop

Upang ma-accommodate ang chunk-based na pag-execute, gumagamit ang inference framework ng modular, tatlong-antas na arkitektura na gumagana sa mga lokal na window ng oras at agad na nagre-release ng resources pagkatapos ma-proseso ang bawat chunk.

• Module: Isang balot sa isang partikular na modelo at checkpoint nito (hal., A2V DiT, Super-Resolution DiT, mga bahagi ng VAE, mga text/audio encoder).
• Yugto: Isang uri ng execution unit na nagkokoordina ng isa o higit pang mga module (hal., context generation, super-resolution).
• Pipeline: Ang execution graph na nag-uugnay sa mga stage, namamahala ng shared state, at nagko-coordinate ng streaming o batch na mga mode ng execution.

Sa yugto ng inisyal na pag-setup, ini-encode ang reference identity sa mga latent nang isang beses bawat request. Pagkatapos, nagpapatakbo ang pipeline ng tuloy-tuloy na loop sa natitirang mga yugto hanggang sa maubos ang input audio stream:

• Pagbuo ng Konteksto: Ginagawang mga feature ang papasok na mga segment ng audio, pinagsasama ang mga ito sa text o scene conditioning, at inihahanda ang mga target na noise tensor.
• Audio-to-Video: Isinasagawa ang isang multi-hakbang na diffusion pass upang makabuo ng low-resolution na mga latent. Sa yugtong ito, iniaangkop ang kasalukuyang bahagi batay sa mga boundary frame ng naunang bahagi upang mapanatili ang tuloy-tuloy na galaw.
• Super-Resolution: Ina-upscale ang motion latents sa full resolution sa isang hakbang lang, na inuuna ang mas detalyadong itsura ng mukha.
• VAE Decode-and-Publish: Dina-decode ang mga high-resolution na latent sa mga RGB frame at direktang isinusulat ang mga ito sa output encoder (H.264 / AAC) para sa agarang pag-save o live na pag-playback.

Pagpapatuloy sa Hangganan at Pagkakapare-pareho ng mga Chunk

Ang pagbuo ng video sa magkakahiwalay na segment ay maaaring magdulot ng mga posibleng pagkakabaha-bahagi o hindi pagkakakonekta sa mga hangganan. Binabawasan ito ng framework sa pamamagitan ng paggamit ng dalawang magkaibang uri ng chunk classifications:

• N Chunks: Mga segment na bumubuo sa pangunahing timeline ng avatar.
• I Chunks (Interpolation): Mga segment na idinisenyo upang pakinisin ang mga transition sa pagitan ng sunud-sunod na N chunks.

Ang pagkakasunod-sunod ng pagpapatupad ay nakaayos tulad ng sumusunod:

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

Ang isang I chunk ay nalilikha lamang kapag tapos na ang nauna at kasunod nitong mga N chunk. Ginagamit nito ang huling frame ng naunang N chunk at isang maagang frame ng kasalukuyang N chunk bilang mga anchor frame upang kalkulahin ang transitional motion. Pagkatapos ng pagbuo, itinatapon ang mga sobrang anchor prediction, at ang natitira lamang ay ang maayos na na-interpolate na transition. Nililimitahan ng mekanismong ito ang kinakailangang context window habang pinapanatili ang temporal consistency.

Palagiang paggamit ng memorya sa buong tagal

Ang isang karaniwang video pipeline ay nag-iipon ng mga latent, na-decode na mga frame, at attention context habang tumatakbo, na nagdudulot sa paggamit ng GPU memory na tumaas nang proporsyonal sa haba ng video.

Para paganahin ang open-ended na pagbuo, nagpapanatili ang framework na ito ng mahigpit na rolling state. Itinatago lang ng sistema ang static na reference conditioning at isang minimal na set ng anchor tensors na kailangan para sa mga transition sa pagitan ng mga chunk. Lahat ng intermediate assets—kabilang ang mga audio feature, noise tensor, internal activation, at raw na RGB frames—ay agad na binubura mula sa memory pagkatapos ma-decode at maisulat ang isang chunk.

Bilang resulta, nananatiling pare-pareho ang pinakamataas na paggamit ng GPU memory kahit gumagawa ng maikling clip o mahabang sequence; ang paggamit ng resources ay sumusunod sa itinakdang laki ng chunk sa halip na sa kabuuang tagal ng session.

Mga yugto ng Paglo-load/Pag-offload sa loob ng pipeline

Bawat request ay tumatakbo sa isang 8-GPU node. Ginagamit namin ang FSDP para hati-hatiin ang malalaking model parameters sa iba’t ibang GPU. Bawat rank ay may hawak lang na bahagi ng weights, kinukuha ang mga parameter na kailangan nito para sa isang computation, at pagkatapos ay nire-release muli ang mga iyon. Ito ang nagpapahintulot na magkasya ang maraming malalaking modelo — ang base DiT, ang super-resolution DiT, ang text encoder, ang audio encoder, at ang VAE — sa iisang node.

May kapalit ito. Nagdadagdag ang FSDP ng karagdagang komunikasyon habang nag-i-inference dahil kailangang pagsama-samahin ang mga parameter sa bawat forward pass. Gumagamit kami ng kombinasyon ng iba’t ibang teknik para itago ang overhead na iyon at panatilihing wala sa GPU ang mga co-located na modelo kapag hindi sila ginagamit:

• Forward prefetching. Ang AllGather ng mga parameter ng susunod na block ay isinasagawa nang mas maaga at isinasabay sa kasalukuyang computation ng block, kaya natatago ang pagkaantala ng pag-gather sa kritikal na landas.
• Tamad na per-block na pag-unshard mula sa CPUKapag ibinabalik ang isang modelo mula sa pinned na CPU memory, hindi namin agad inaakyat ang buong set ng weights. Bawat transformer block ay inu-unshard (host-to-device copy + AllGather) kaagad bago ang forward pass nito, kaya ang H2D transfer ng block n+1 ay na-o-overlap sa compute ng block n.
• Pinned CPU offload sa pagitan ng mga yugto. Ang mga parameter ng isang model na kasalukuyang hindi tumatakbo ay inilalagay sa pinned CPU memory, kaya hindi kailangang sabay-sabay na naka-load sa GPU ang mga weights ng mga magkasamang model (base DiT, super-resolution DiT, text encoder, audio encoder, VAE). Ang pinned memory ang dahilan kung bakit sapat ang bilis ng H2D copies para ma-overlap ang mga ito sa compute.
• NUMA-aware na paglalagay ng prosesoBawat proseso ay ipinapako sa parehong NUMA node ng nakatalagang GPU nito, kaya ang mga paglipat ng data sa pagitan ng CPU at GPU ay tumatakbo sa buong PCIe/NVLink bandwidth nang hindi dumadaan sa inter-socket interconnect.

Paglipat ng modelo sa loob ng mas mababa sa 10ms sa pagitan ng mga yugto

Ang praktikal na benepisyo ng mga teknik sa itaas ay na ang paglipat ng GPU mula sa modelo ng isang yugto papunta sa susunod — halimbawa, A2V DiT → Super-Resolution DiT, o SR DiT → VAE decoder — ay halos walang dagdag na gastos. Dahil ang papalabas na modelo ay ina-offload nang asynchronous at ang unang block ng papasok na modelo ay ina-unshard nang just-in-time, parehong natatago sa likod ng kasalukuyang tumatakbong compute ang H2D copy at AllGather. Mula umpisa hanggang dulo, ang nakikitang overhead sa bawat paglipat ay mas mababa sa 10ms — malayo sa isang frame budget sa target naming frame rates. Sa praktikal na usapan, ito ang nagbibigay-daan sa streaming pipeline loop (Context Gen → A2V → SR → VAE Decode-and-Publish) na umikot sa ilang malalaking modelo kada chunk nang hindi kailanman nagiging bottleneck ang mismong pagpalit ng modelo.

Realtime na pag-publish ng streaming

Para maging sapat na mabilis ang modelo para makapag-stream nang realtime, gumawa kami ng maraming inference optimizations, mangyaring sumangguni sa https://www.heygen.com/research/avatar-v-inference para sa higit pang detalye tungkol sa bahaging ito.

Kapag naglalabas na ang pipeline ng video nang pira-piraso sa real time, nagiging natural na karugtong na lang ng inference ang streaming delivery sa halip na hiwalay na post-processing na hakbang.

Para sa broadcast-style na realtime na daloy, inilalathala namin ang mga nabuong frame sa Amazon Kinesis Video Streams (KVS). Karaniwang pinag-uusapan ang KVS sa konteksto ng mga camera, mga IoT device, at mga na-upload na media. Sa kaso namin, ang “camera” ay ang inference pipeline mismo: ang mga frame ay ginagawa ng modelo, agad na ini-encode, at itinutulak sa KVS bilang isang live stream.

Tumatanggap ang output writer ng na-decode na mga RGB frame mula sa streaming VAE at ipinapadala ang mga ito sa isang GStreamer pipeline. Ang video ay ini-encode bilang H.264 at ang audio bilang AAC, pagkatapos ay itinutulak ang parehong track sa kvssink, ang KVS producer sink. Mula roon, maaaring i-play ng mga manonood ang session bilang isang live stream habang ito ay ginagawa pa lamang.

Mga resulta at natutunan

Binago ng framework ang pagbuo ng Avatar IV at Avatar V mula sa fixed-scene rendering tungo sa open-ended streaming generation. Pinakamahalagang resulta nito ay simple: tinanggal namin ang mga limitasyon sa haba ng eksena para sa Avatar IV at Avatar V. Para sa realtime na pagbuo ng Avatar IV, nakamit namin ang time to first frame na mas mababa sa 5 segundo at generation na 27+ frames per second para sa 720p Avatar IV videos — mas mabilis pa kaysa sa realtime playback.