Avatar-Videos wirken nur dann glaubwürdig, wenn die Person über die Zeit hinweg konsistent bleibt. Wenn das Gesicht verrutscht, sich die Zähne verändern, die Lippensynchronität nachlässt oder die Bewegung zwischen den Clips neu startet, fällt das den Menschen sofort auf. Für Avatare ist das noch wichtiger als bei vielen anderen Video-Generierungsaufgaben, weil die Zuschauer einer bestimmten Person zusehen, die oft aus nächster Nähe und über einen längeren Zeitraum spricht.

In der heutigen Welt der Videogenerierung ist die Dauer nach wie vor eine der sichtbarsten Einschränkungen. Viele Modelle und Produkte bieten die Generierung nur als Clip mit fester Länge an – ein paar Sekunden, wobei nur wenige Systeme mehr als ein paar Minuten erzeugen können. Bei Avatar-Produkten wirkt sich diese Begrenzung direkt auf die Workflows der Kund:innen aus. Sie wünschen sich längere, konsistente Szenen/Videos für Schulungsvideos, Vertriebsdemos, Produkt-Walkthroughs, Bildung, Support sowie für Agents, die so lange weiterreden sollen, bis die Aufgabe erledigt ist – und gleichzeitig möchten sie schnelle Vorschauen, um an Prompts, Bewegungen und Skript iterieren zu können.

Bei HeyGen führte das zu drei konkreten Anforderungen:

1. Konsistenz über lange Szenen hinweg. Der Avatar muss Identität, Lippensynchronität, Mimik und Bewegungsablauf nicht nur in einem kurzen Clip, sondern über viele aufeinanderfolgende Abschnitte des generierten Videos hinweg bewahren.
2. Keine feste ZeitbegrenzungEine Generierung kann zehn Sekunden, zehn Minuten oder eine offene Echtzeitsitzung dauern.
3. Schnelle Vorschau, Echtzeit- oder schneller-als-Echtzeit-Generierung. Das System sollte schnell mit der Erstellung von Frames beginnen und sogar das Streamen der generierten Frames ermöglichen, während die Inferenz noch läuft.

Dieser Beitrag erläutert das Inferenz-Framework, das wir entwickelt haben, um diese Anforderungen zu erfüllen.

Die zugrunde liegende Modellarchitektur

Das Framework basiert auf HeyGens Modellen zur Avatar-Videoerzeugung – den Avatar-IV- und Avatar-V-Modellfamilien. Auf hoher Ebene nimmt das Modell ein Referenzbild bzw. -video, die treibende Audiospur sowie optionale Text- oder Szenenbedingungen entgegen und erzeugt daraus ein Video des Avatars, der mit der richtigen Identität, Mimik und Bewegung spricht.

Das zentrale Generierungsmodell ist ein Diffusion Transformer (DiT), der mit Flow Matching trainiert wird. Anstatt die Person in eine kleine Identitätseinbettung zu komprimieren, basiert das Modell auf reichhaltigen Referenztokens, sodass es die für Avatare wichtigen Details bewahren kann: Gesichtsform, Zähne, Hauttextur, Mundbewegung, Gestenstil und Sprechrhythmus.

Der produktive Inferenzpfad umfasst drei Hauptphasen:

1. Audio-zu-Video-Generierung. Ein grundlegendes DiT-Modell erzeugt Video-Latents in niedriger Auflösung aus der Referenzidentität, Audio-Features und weiteren Konditionssignalen. In dieser Phase liegt der Schwerpunkt auf Bewegung, Lippensynchronität und zeitlicher Kohärenz.
2. Identitätsbewusste Superauflösung. Ein zweites Modell verfeinert diese Latents zu einem hochauflösenden Ergebnis, mit besonderer Aufmerksamkeit für Bereiche, in denen Menschen besonders empfindlich auf Artefakte reagieren – insbesondere im Gesichts- und Mundbereich.
3. Streaming-VAE-DekodierungEin VAE-Decoder wandelt hochauflösende Latents schrittweise in RGB-Frames um, sodass Frames bereits ausgegeben werden können, bevor das vollständige Video fertiggestellt ist.

Um lange Videos zu erzeugen, verarbeitet das System die Daten in einzelnen Abschnitten. Während sich der erste Abschnitt vollständig auf die statische Referenz stützt, verwenden die folgenden Abschnitte Randdaten aus den vorherigen Segmenten. So kann der Avatar natürlich weiter sprechen, ohne seine Haltung oder Identität jedes Mal von Grund auf neu setzen zu müssen.

Der Streaming-Framework- und Pipeline-Loop

Um eine ausführung in Blöcken zu ermöglichen, verwendet das Inferenz-Framework eine modulare Drei-Ebenen-Architektur, die auf lokal begrenzten Zeitfenstern arbeitet und Ressourcen unmittelbar nach der Verarbeitung eines Blocks wieder freigibt.

• Modul: Eine Hülle um ein bestimmtes Modell und dessen Checkpoint (z. B. A2V DiT, Super-Resolution DiT, VAE‑Komponenten, Text-/Audio-Encoder).
• Stufe: Eine typisierte Ausführungseinheit, die ein oder mehrere Module koordiniert (z. B. Kontextgenerierung, Superauflösung).
• Pipeline: Der Ausführungsgraph, der Stages miteinander verbindet, den gemeinsamen Zustand verwaltet und Streaming- oder Batch-Ausführungsmodi koordiniert.

In der Initialisierungsphase wird die Referenzidentität einmal pro Anfrage in Latents kodiert. Anschließend führt die Pipeline eine kontinuierliche Schleife über die verbleibenden Stufen aus, bis der eingehende Audiostream erschöpft ist:

• Kontextgenerierung: Wandelt eingehende Audiosegmente in Merkmale um, kombiniert sie mit Text- oder Szenen-Conditioning und bereitet die Ziel-Rausch-Tensoren vor.
• Audio-zu-Video: Führt einen mehrstufigen Diffusionsdurchlauf aus, um latente Repräsentationen in niedriger Auflösung zu erzeugen. In dieser Phase wird der aktuelle Abschnitt anhand der Randbilder des vorherigen Abschnitts konditioniert, um eine durchgängige Bewegungsdarstellung sicherzustellen.
• Super-Resolution: Skaliert die Bewegungs-Latents in einem einzigen Schritt auf die volle Auflösung hoch und priorisiert dabei räumliche Details im Gesicht.
• VAE Decode-and-Publish: Dekodiert die hochauflösenden Latents in RGB-Frames und schreibt sie direkt in den Ausgabe-Encoder (H.264 / AAC) für die sofortige Speicherung oder Live-Wiedergabe.

Grenzkontinuität und Chunk-Konsistenz

Die Erstellung von Videos in getrennten Segmenten kann zu potenziellen Diskontinuitäten an den Übergängen führen. Das Framework mildert dies, indem es zwei unterschiedliche Chunk-Klassifizierungen verwendet:

• N‑Chunks: Segmente, die die primäre Zeitleiste des Avatars erzeugen.
• I-Chunks (Interpolation): Segmente, die dazu dienen, Übergänge zwischen aufeinanderfolgenden N-Chunks zu glätten.

Die Ausführungsreihenfolge ist wie folgt aufgebaut:

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

Ein I-Chunk wird erst erzeugt, nachdem die vorhergehenden und nachfolgenden N-Chunks abgeschlossen sind. Er verwendet den letzten Frame des vorherigen N-Chunks und einen frühen Frame des aktuellen N-Chunks als Anker-Frames, um die Übergangsbewegung zu berechnen. Nach der Generierung werden die redundanten Anker-Vorhersagen verworfen, sodass nur die glatt interpolierte Übergangssequenz übrig bleibt. Dieser Mechanismus begrenzt das benötigte Kontextfenster und erhält gleichzeitig die zeitliche Konsistenz.

Konstanter Speicherbedarf über die Dauer

Eine herkömmliche Videopipeline sammelt während der Ausführung Latents, dekodierte Frames und Aufmerksamkeitskontext an, wodurch der GPU-Speicherverbrauch linear mit der Videodauer ansteigt.

Um eine offene, fortlaufende Generierung zu ermöglichen, hält dieses Framework einen strikt rollierenden Zustand aufrecht. Das System behält nur die statische Referenz-Conditioning-Information und einen minimalen Satz von Anker-Tensoren, die für Übergänge zwischen den Chunks erforderlich sind. Alle Zwischenartefakte – einschließlich Audio-Features, Rausch-Tensoren, interner Aktivierungen und roher RGB-Frames – werden unmittelbar nach dem Dekodieren und Schreiben eines Chunks aus dem Speicher entfernt.

Dadurch bleibt das maximale GPU-Speicherprofil unverändert, egal ob ein kurzer Clip oder eine längere Sequenz erzeugt wird; die Ressourcenauslastung skaliert mit der definierten Chunk-Größe und nicht mit der Gesamtdauer der Sitzung.

Lade- und Entladephasen innerhalb der Pipeline

Jede Anfrage wird auf einem 8-GPU-Knoten ausgeführt. Wir verwenden FSDP, um die Parameter großer Modelle über die GPUs zu sharden. Jeder Rank besitzt nur einen Bruchteil der Gewichte, sammelt die Parameter, die er für eine Berechnung benötigt, und gibt sie anschließend wieder frei. Dadurch können mehrere große Modelle – das Basis-DiT, das Super-Resolution-DiT, der Text-Encoder, der Audio-Encoder und das VAE – auf einem einzigen Knoten Platz finden.

Dabei gibt es einen Kompromiss. FSDP verursacht während der Inferenz zusätzlichen Kommunikationsaufwand, weil die Parameter bei den Forward-Pässen eingesammelt werden müssen. Wir nutzen eine Kombination verschiedener Techniken, um diesen Overhead zu verbergen und gemeinsam platzierte Modelle von der GPU fernzuhalten, wenn sie nicht verwendet werden:

• Vorwärts-Prefetching. Das AllGather der Parameter des nächsten Blocks wird frühzeitig ausgelöst und mit der Berechnung des aktuellen Blocks überlappt, sodass die Latenz des Gather-Vorgangs auf dem kritischen Pfad verborgen wird.
• Träges, blockweises Unsharding von der CPU. Wenn ein Modell aus dem gepinnten CPU-Speicher zurückgeholt wird, laden wir nicht den vollständigen Parametersatz im Voraus. Jeder Transformer-Block wird unmittelbar vor seinem Forward-Pass ent-sharded (Host-zu-Device-Kopie + AllGather), sodass die H2D-Übertragung von Block n+1 mit der Berechnung von Block n überlappt.
• Auslagerung auf gepinnte CPU zwischen den Stufen. Die Parameter eines Modells, das gerade nicht ausgeführt wird, werden im gepinnten CPU-Speicher gehalten, sodass gemeinsam laufende Modelle (Basis-DiT, Super-Resolution-DiT, Text-Encoder, Audio-Encoder, VAE) ihre Gewichte nicht gleichzeitig im GPU-Speicher vorhalten müssen. Gepinnter Speicher sorgt dafür, dass die H2D-Kopien schnell genug sind, um sich mit der Berechnung zu überlappen.
• NUMA-bewusste Prozessplatzierung. Jeder Prozess wird an denselben NUMA-Knoten wie seine zugewiesene GPU gebunden, sodass CPU↔GPU-Übertragungen mit voller PCIe-/NVLink-Bandbreite erfolgen können, ohne die sockelübergreifende Interconnect-Verbindung zu kreuzen.

Modellwechsel zwischen den Phasen in unter 10 ms

Der praktische Nutzen der oben beschriebenen Techniken besteht darin, dass die Übergabe der GPU von einem Modellstadium zum nächsten – zum Beispiel A2V DiT → Super-Resolution DiT oder SR DiT → VAE-Decoder – praktisch ohne zusätzlichen Aufwand erfolgt. Da das ausgehende Modell asynchron ausgelagert wird und der erste Block des eingehenden Modells just-in-time unsharded wird, sind sowohl die H2D-Kopie als auch das AllGather hinter bereits laufenden Berechnungen verborgen. Über die gesamte Pipeline hinweg liegt der tatsächlich messbare Overhead pro Modellwechsel unter 10 ms – also deutlich unter dem Budget für ein einzelnes Frame bei unseren anvisierten Bildraten. Konkret ist es genau das, was es der Streaming-Pipeline-Schleife (Context Gen → A2V → SR → VAE Decode-and-Publish) ermöglicht, pro Chunk mehrere große Modelle zu durchlaufen, ohne dass der Modellwechsel selbst jemals zum Engpass wird.

Echtzeit-Streaming-Veröffentlichung

Um das Modell schnell genug für das Streaming in Echtzeit zu machen, haben wir zahlreiche Inferenz-Optimierungen vorgenommen, bitte siehe https://www.heygen.com/research/avatar-v-inference für weitere Details zu diesem Teil.

Sobald die Pipeline das Video in Echtzeit Stück für Stück ausgibt, wird die Streaming-Auslieferung zu einer natürlichen Erweiterung der Inferenz, anstatt einen separaten Nachbearbeitungsschritt darzustellen.

Für den broadcastartigen Echtzeitpfad veröffentlichen wir die generierten Frames in Amazon Kinesis Video Streams (KVS). KVS wird üblicherweise im Zusammenhang mit Kameras, IoT-Geräten und hochgeladenen Medien betrachtet. In unserem Fall ist die „Kamera“ jedoch die Inferenz-Pipeline selbst: Die Frames werden vom Modell erzeugt, sofort enkodiert und als Livestream in KVS eingespeist.

Der Output-Writer empfängt dekodierte RGB-Frames vom Streaming-VAE und leitet sie in eine GStreamer-Pipeline weiter. Das Video wird als H.264 und das Audio als AAC kodiert, anschließend werden beide Spuren an kvssink, den KVS-Producer-Sink, übergeben. Von dort aus können Zuschauer die Session als Livestream abspielen, während sie noch generiert wird.

Ergebnisse und Erkenntnisse

Das Framework hat die Generierung von Avatar IV und Avatar V von einer festen Szenen-Renderpipeline auf eine offene, kontinuierliche Streaming-Generierung umgestellt. Das wichtigste Ergebnis ist einfach: Wir haben die Begrenzung der Szenendauer für Avatar IV und Avatar V entfernt. Für die Echtzeitgenerierung von Avatar IV haben wir eine Time-to-First-Frame von unter 5 Sekunden erreicht und erzeugen 27+ Frames pro Sekunde für 720p-Avatar-IV-Videos – schneller als die Wiedergabe in Echtzeit.