Avatarvideo känns bara trovärdig om personen är konsekvent över tid. När ansiktet glider, tänderna förändras, läppsynken halkar efter eller rörelsen startar om mellan klipp märker människor det direkt. Det här är extra viktigt för avatarer jämfört med många andra typer av videogenerering, eftersom tittaren följer en specifik person som pratar, ofta på nära håll och under en längre stund.

I dagens värld av videogenerering är längden fortfarande en av de mest synliga begränsningarna. Många modeller och produkter låter dig skapa video som klipp med fast längd – några sekunder, och få system kan generera mer än några minuter. För avatarprodukter märks den begränsningen direkt i kundernas arbetsflöden. Kunder vill ha längre, konsekventa scener/videor för utbildningsvideor, säljdemos, produktgenomgångar, utbildning, support och agenter som ska fortsätta prata tills uppgiften är klar, och de vill också ha snabba förhandsvisningar för att kunna iterera på prompts, rörelser och manus.

På HeyGen innebar det tre konkreta krav:

1. Konsekvens i längre scener Avataren måste bevara identitet, läppsynk, uttryck och rörelsekontinuitet inte bara i ett kort klipp, utan genom många segment av genererad video.
2. Ingen fast tidsgränsEn generering kan vara tio sekunder, tio minuter eller en pågående session i realtid.
3. Snabb förhandsvisning, generering i realtid eller snabbare än realtid. Systemet ska börja skapa bildrutor snabbt och till och med tillåta att de genererade bildrutorna strömmas ut medan inferensen fortfarande pågår.

Det här inlägget går igenom det inferensramverk vi har byggt för att uppfylla dessa krav.

Den underliggande modellarkitekturen

Ramverket är uppbyggt kring HeyGens modeller för att skapa avatarvideor – familjerna Avatar IV och Avatar V. På en övergripande nivå tar modellen en referensbild/-video, styrande ljud och valfri text- eller scenkonditionering och skapar sedan en video där avataren talar med rätt identitet, uttryck och rörelse.

Den centrala genereringsmodellen är en Diffusion Transformer, eller DiT, tränad med flow matching. I stället för att komprimera personen till en liten identitets‑embedding använder modellen rika referenstoken som villkor, så att den kan bevara detaljer som är viktiga för avatarer: ansiktsform, tänder, hudtextur, munrörelser, geststil och talrytm.

Produktionsinfernsvägen har tre huvudsteg:

1. Audio-till-video-generering. En grundläggande DiT skapar videolatenter med låg upplösning utifrån referensidentiteten, ljudfunktioner och styrsignaler. Det här steget fokuserar på rörelse, läppsynk och tidsmässig koherens.
2. Identitetsmedveten superupplösning. En andra modell förfinar dessa latenta representationer till högupplöst output, med extra fokus på områden där människor är som mest känsliga för artefakter, särskilt ansikte och mun.
3. Strömmande VAE-avkodningEn VAE-avkodare omvandlar högupplösta latenta representationer till RGB-bildrutor bit för bit, så att bildrutor kan skickas ut innan hela videon är färdig.

För att skapa långa videor bearbetar systemet data i delar. Medan den första delen enbart bygger på den statiska referensen, använder efterföljande delar gränsdata från föregående segment. Det gör att avataren kan fortsätta tala naturligt utan att behöva återställa hållning eller identitet från början.

Strömningsramverket och pipeline-loopen

För att stödja körning i delar använder inferensramverket en modulär arkitektur i tre lager som arbetar på lokala tidsfönster och frigör resurser direkt efter att en del har bearbetats.

• Modul: Ett hölje runt en specifik modell och dess checkpoint (t.ex. A2V DiT, Super-Resolution DiT, VAE-komponenter, text-/ljudenkodare).
• Steg: En typad exekveringsenhet som samordnar en eller flera moduler (t.ex. kontextgenerering, superupplösning).
• Pipeline: Exekveringsgrafen som kopplar ihop steg, hanterar delat tillstånd och samordnar strömmande eller batchbaserade exekveringslägen.

Initieringsfasen kodar referensidentiteten till latenta representationer en gång per förfrågan. Pipen kör sedan en kontinuerlig loop genom de återstående stegen tills den inkommande ljudströmmen är förbrukad:

• Kontextgenerering: Omvandlar inkommande ljudsegment till funktioner, kombinerar dem med text- eller scenbaserad konditionering och förbereder de måltensorer som innehåller brus.
• Audio-to-Video: Utför en flerstegsdiffusion för att skapa latenta representationer i låg upplösning. I det här steget kopplas den aktuella delen till kantbilderna från den föregående delen för att behålla rörelsekontinuitet.
• Superupplösning: Skalar upp rörelselatenterna till full upplösning i ett enda steg, med fokus på detaljer i ansiktet.
• VAE Decode-and-Publish: Avkodar högupplösta latenter till RGB-bildrutor och skriver dem direkt till utgångskodaren (H.264 / AAC) för omedelbar lagring eller direktuppspelning.

Kontinuitet vid gränser och konsistens mellan segment

Att skapa video i separata segment kan leda till potentiella gränsbrott. Ramverket motverkar detta genom att använda två olika typer av chunk‑klassificering:

• N-chunkar: Segment som skapar avatarens primära tidslinje.
• I Chunks (Interpolation): Segment som är utformade för att jämna ut övergångar mellan sekventiella N Chunks.

Körningssekvensen är strukturerad enligt följande:

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

En I-del genereras först när de föregående och efterföljande N-delarna är färdiga. Den använder den sista bilden i den föregående N-delen och en tidig bild i den aktuella N-delen som ankarramar för att beräkna den övergångsrörelse som behövs. Efter genereringen kastas de överflödiga ankarförutsägelserna bort, så att bara den jämnt interpolerade övergången återstår. Denna mekanism begränsar det nödvändiga kontextfönstret samtidigt som den bevarar den temporala konsistensen.

Konstant minnesanvändning över tid

En konventionell videopipeline samlar på sig latenta representationer, avkodade bildrutor och uppmärksamhetskontext under körning, vilket gör att GPU-minnesanvändningen ökar linjärt med videons längd.

För att möjliggöra öppen generering upprätthåller ramverket ett strikt rullande tillstånd. Systemet behåller bara den statiska referenskonditioneringen och en minimal uppsättning ankartensorer som krävs för övergångar mellan segment. Alla intermediära tillgångar – inklusive ljudfunktioner, brus-tensorer, interna aktiveringar och råa RGB-bildrutor – rensas omedelbart från minnet efter att ett segment har avkodats och skrivits.

Som ett resultat förblir den maximala GPU-minnesprofilen konstant oavsett om du genererar ett kort klipp eller en längre sekvens; resursanvändningen skalar med den definierade chunk-storleken snarare än den totala längden på sessionen.

Laddnings- och avlastningssteg i pipelinen

Varje förfrågan körs över en nod med 8 GPU:er. Vi använder FSDP för att dela upp stora modellparametrar mellan GPU:erna. Varje rank äger bara en del av vikterna, samlar in de parametrar den behöver för en beräkning och frigör dem sedan igen. Det är detta som gör att flera stora modeller – bas-DiT, superupplösnings-DiT, textkodaren, ljudkodaren och VAE:n – får plats på en enda nod.

Det finns en avvägning. FSDP innebär kommunikationsöverhead under inferens eftersom parametrar måste samlas in under framåtpasser. Vi använder en kombination av tekniker för att dölja den overheaden och för att hålla samlokaliserade modeller borta från GPU:n när de inte används:

• Förhandsinhämtning i framåtpass. AllGather för nästa blocks parametrar startas i förväg och överlappas med det aktuella blockets beräkning, vilket döljer insamlingsfördröjningen på den kritiska vägen.
• Lazad avshardning per block från CPU. När en modell tas tillbaka från pinnat CPU-minne förbereder vi inte hela uppsättningen vikter i förväg. Varje transformerblock avshardas (host-till-device-kopia + AllGather) precis före sin framåtriktade passering, så att H2D-överföringen för block n+1 överlappar beräkningen för block n.
• Pinned CPU-offload mellan steg. Parametrarna för en modell som inte körs just nu hålls i pinnat CPU-minne, så att samlokaliserade modeller (bas-DiT, superupplösnings-DiT, textencoder, ljudencoder, VAE) inte alla behöver ha sina vikter på GPU:n samtidigt. Pinnat minne är det som gör H2D-kopiorna tillräckligt snabba för att överlappa med beräkningen.
• NUMA-medveten processplacering. Varje process är bunden till samma NUMA-nod som sin tilldelade GPU, så CPU↔GPU-överföringar körs med full PCIe/NVLink-bandbredd utan att korsa inter-socket-interconnecten.

Modellväxling mellan steg på under 10 ms

Den praktiska vinsten med teknikerna ovan är att överlämningen av GPU:n från en etapps modell till nästa – till exempel A2V DiT → Super-Resolution DiT, eller SR DiT → VAE-avkodare – i praktiken är kostnadsfri. Eftersom den utgående modellen avlastas asynkront och den inkommande modellens första block avshardas just-in-time, döljs både H2D-kopian och AllGather bakom beräkningar som redan körs. Från början till slut är den observerbara overheaden per byte under 10 ms – klart under budgeten för en enskild bildruta vid våra målfrekvenser. Konkret är det detta som gör att streaming-pipelinen (Context Gen → A2V → SR → VAE Decode-and-Publish) kan loopa genom flera stora modeller per segment utan att själva modellbytet någonsin blir flaskhalsen.

Publicering av strömmande video i realtid

För att göra modellen tillräckligt snabb för att kunna strömma i realtid har vi gjort många inferensoptimeringar, se https://www.heygen.com/research/avatar-v-inference för mer information om den här delen.

När pipelinen skickar ut video bit för bit i realtid blir strömmad leverans en naturlig förlängning av inferensen i stället för ett separat efterbearbetningssteg.

För den sändningsliknande realtidsvägen publicerar vi genererade bildrutor till Amazon Kinesis Video Streams (KVS). KVS diskuteras vanligtvis i samband med kameror, IoT-enheter och uppladdade medier. I vårt fall är ”kameran” själva inferenspipelinan: bildrutorna skapas av modellen, kodas direkt och skickas till KVS som en direktsänd ström.

Output-skrivaren tar emot avkodade RGB-bildrutor från den strömmande VAE:n och skickar dem vidare till en GStreamer-pipeline. Video kodas som H.264 och ljud som AAC, sedan skickas båda spåren till kvssink, KVS-producentens sink. Därifrån kan tittare spela upp sessionen som en direktsänd ström medan den fortfarande genereras.

Resultat och lärdomar

Ramverket ändrade genereringen av Avatar IV och Avatar V från rendering av fasta scener till öppen, strömmande generering. Det viktigaste resultatet är enkelt: vi tog bort begränsningar för scenlängd för Avatar IV och Avatar V. För Avatar IV-generering i realtid har vi nått en tid till första bildruta på under 5 sekunder och generering i över 27 bildrutor per sekund för Avatar IV‑videor i 720p – snabbare än uppspelning i realtid.