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 Lippensynchronisation nicht mehr stimmt oder sich die Bewegung zwischen den Clips zurücksetzt, fällt das den Leuten sofort auf. Für Avatare ist dies noch wichtiger als für viele andere Aufgaben der Videogenerierung, weil die Zuschauer einer bestimmten Person zuschauen, die oft aus nächster Nähe und über längere Zeit spricht.

In der heutigen Welt der Videoerstellung mit KI ist die Dauer nach wie vor eine der sichtbarsten Einschraenkungen. Viele Modelle und Produkte bieten die Generierung nur als Clip mit fester Laenge an – ein paar Sekunden, und nur wenige Systeme koennen mehr als einige Minuten erzeugen. Bei Avatar-Produkten wirkt sich diese Grenze direkt auf die Workflows der Kundinnen und Kunden aus. Sie wuenschen sich laengere, konsistente Szenen/Videos für Schulungsvideos, Sales-Demos, Produkt-Walkthroughs, Bildung, Support und Agenten, die so lange weiterreden sollen, bis die Aufgabe erledigt ist – und gleichzeitig moechten sie eine schnelle Vorschau, um Prompts, Bewegung und Skript iterativ zu optimieren.

Bei HeyGen hat sich das in drei konkrete Anforderungen uebersetzt:

1. Konsistenz in langen Szenen. Der Avatar muss Identitaet, Lippensynchronisation, Mimik und Bewegungs­kontinuitaet nicht nur in einem kurzen Clip, sondern ueber viele 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 erlauben, waehrend die Inferenz noch laeuft.

Dieser Beitrag fuehrt Sie durch das Inferenz-Framework, das wir entwickelt haben, um diese Anforderungen zu erfuellen.

Die zugrunde liegende Modellarchitektur

Das Framework basiert auf den KI-Video-Generierungsmodellen von HeyGen – den Avatar-IV- und Avatar-V-Modellfamilien. Auf hoher Ebene nimmt das Modell ein Referenzbild oder -video, die treibende Audiospur sowie optionale Text- oder Szenen-Conditioning-Informationen und generiert daraus ein Video dieses Avatars, der mit der passenden Identität, Mimik und Bewegung spricht.

Das zentrale Generierungsmodell ist ein Diffusion Transformer (DiT), der mit Flow Matching trainiert wird. Anstatt die Person in ein kleines Identitaetsembedding zu komprimieren, arbeitet das Modell mit reichhaltigen Referenztokens, sodass es die fuer Avatare wichtigen Details bewahren kann: Gesichtsform, Zaehne, Hauttextur, Mundbewegung, Gestenstil und Sprechrhythmus.

Der produktive Inferenzpfad umfasst drei Hauptphasen:

1. Audio-zu-Video-Generierung. Ein Basis-DiT generiert Video-Latents mit niedriger Aufloesung aus der Referenzidentitaet, Audio-Features und weiteren Condition-Signalen. In dieser Phase liegt der Fokus auf Bewegung, Lippensynchronisation und zeitlicher Koharenz.
2. Identitaetsbewusste Superauflösung. Ein zweites Modell verfeinert diese Latents zu einem hochaufgelösten Ergebnis, mit besonderer Aufmerksamkeit für Bereiche, in denen Menschen besonders empfindlich auf Artefakte reagieren, insbesondere im Gesichts- und Mundbereich.
3. Streaming VAE decode. A VAE decoder converts high-resolution latents into RGB frames chunk by chunk, so frames can be emitted before the full video is complete.

Um lange Videos zu erstellen, verarbeitet das System die Daten in einzelnen Segmenten. Während sich das erste Segment vollständig auf die statische Referenz stützt, verwenden die folgenden Segmente Randdaten aus den vorhergehenden Abschnitten. So kann der Avatar natürlich weitersprechen, ohne seine Körperhaltung oder Identität von Grund auf zurücksetzen zu müssen.

Das Streaming-Framework und der Pipeline-Loop

Um eine aus Teilabschnitten bestehende Ausfuehrung zu ermoeglichen, verwendet das Inferenz-Framework eine modulare Drei-Ebenen-Architektur, die auf lokalisierte Zeitfenster wirkt und Ressourcen unmittelbar nach der Verarbeitung eines Abschnitts wieder freigibt.

• Module: A wrapper around a specific model and its checkpoint (e.g., A2V DiT, Super-Resolution DiT, VAE components, text/audio encoders).
• Stage: Eine typisierte Ausfuehrungseinheit, die ein oder mehrere Module koordiniert (z. B. Kontextgenerierung, Super-Resolution).
• Pipeline: The execution graph that wires stages together, manages shared state, and coordinates streaming or batch execution modes.

Die Initialisierungsphase kodiert die Referenzidentitaet einmal pro Anfrage in Latents. Die Pipeline fuehrt anschliessend eine kontinuierliche Schleife ueber die verbleibenden Stufen aus, bis der eingehende Audiostream vollstaendig verarbeitet ist:

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

Grenzkontinuitaet und Chunk-Konsistenz

Das Erstellen von Videos in separaten Segmenten kann zu potenziellen Diskontinuitaeten an den Uebergangsgrenzen fuehren. Das Framework mildert dies, indem es zwei unterschiedliche Chunk-Klassifikationen verwendet:

• N-Chunks: Segmente, die die primäre Zeitleiste des Avatars generieren.
• I Chunks (Interpolation): Segmente, die dazu dienen, Uebergaenge zwischen aufeinanderfolgenden N Chunks zu glätten.

Die Ausfuehrungsreihenfolge 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 sauber interpolierte Übergangssequenz übrig bleibt. Dieser Mechanismus begrenzt das erforderliche Kontextfenster und erhält gleichzeitig die zeitliche Konsistenz.

Konstanter Speicherbedarf über die Dauer

Eine herkoemmliche Video-Pipeline sammelt waehrend der Ausfuehrung Latents, dekodierte Frames und Aufmerksamkeitskontext an, wodurch der GPU-Speicherverbrauch linear mit der Videodauer ansteigt.

Um eine offene, fortlaufende Generierung zu ermoeglichen, haelt dieses Framework einen strikt rollierenden Zustand aufrecht. Das System behaelt nur die statische Referenz-Conditioning und einen minimalen Satz von Anker-Tensoren, die fuer Uebergaenge zwischen den Chunks erforderlich sind. Saemtliche Zwischenresultate – einschliesslich Audio-Features, Rausch-Tensoren, interner Aktivierungen und roher RGB-Frames – werden unmittelbar aus dem Speicher entfernt, sobald ein Chunk dekodiert und geschrieben wurde.

Dadurch bleibt das maximale GPU-Speicherprofil unverändert, egal ob ein kurzer Clip oder eine längere Sequenz generiert wird; die Ressourcennutzung skaliert mit der definierten Chunk-Groesse und nicht mit der gesamten Dauer der Session.

Lade- und Entladephasen innerhalb der Pipeline

Jede Anfrage lauft auf einem 8-GPU-Node. Wir verwenden FSDP, um grosse Modellparameter ueber mehrere GPUs zu sharden. Jeder Rank besitzt nur einen Teil der Gewichte, sammelt die Parameter, die er fuer eine Berechnung benoetigt, und gibt sie danach wieder frei. So koennen mehrere grosse Modelle – das Basis-DiT, das Super-Resolution-DiT, der Text-Encoder, der Audio-Encoder und das VAE – auf einem einzigen Node laufen.

Es gibt einen Zielkonflikt. FSDP verursacht während der Inferenz Kommunikations-Overhead, weil Parameter während der Forward-Passes zusammengeführt werden müssen. Wir verwenden eine Kombination von Techniken, um diesen Overhead zu verbergen und gemeinsam platzierte Modelle von der GPU fernzuhalten, wenn sie nicht verwendet werden:

• Forward 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.
• Lazyes, blockweises Unsharding von der CPU. Wenn ein Modell aus dem gepinnten CPU-Speicher zurueckgeholt wird, laden wir nicht im Voraus den gesamten Gewichtssatz. Jeder Transformer-Block wird unmittelbar vor seinem Forward-Pass ungeshardet (Host-zu-Device-Kopie + AllGather), sodass die H2D-Uebertragung von Block n+1 mit der Berechnung von Block n ueberlappt.
• Auslagerung auf gepinnte CPU zwischen den Stufen. Die Parameter eines Modells, das aktuell nicht ausgefuehrt wird, werden im gepinnten CPU-Speicher gehalten, sodass ko-lokalisierte Modelle (Base-DiT, Super-Resolution-DiT, Text-Encoder, Audio-Encoder, VAE) ihre Gewichte nicht alle gleichzeitig im GPU-Speicher halten muessen. Gepinnter Speicher sorgt dafuer, dass die H2D-Kopien schnell genug sind, um sich mit der Berechnung zu ueberschneiden.
• NUMA-bewusste Prozessplatzierung. Jeder Prozess wird an denselben NUMA-Knoten wie die ihm zugewiesene GPU gebunden, sodass CPU↔GPU-Transfers mit voller PCIe-/NVLink-Bandbreite erfolgen, ohne den Inter-Socket-Interconnect zu ueberqueren.

Modellwechsel zwischen Stufen in unter 10 ms

Der praktische Nutzen der oben beschriebenen Techniken besteht darin, dass die Uebergabe der GPU von einem Modell einer Stufe zum nächsten – zum Beispiel A2V DiT → Super-Resolution DiT oder SR DiT → VAE-Decoder – praktisch kostenlos ist. Da das ausgehende Modell asynchron ausgelagert wird und der erste Block des eingehenden Modells just-in-time ohne Sharding bereitgestellt wird, sind sowohl das H2D-Copy als auch das AllGather hinter bereits laufenden Berechnungen verborgen. End-to-End liegt der beobachtbare Overhead pro Wechsel unter 10 ms – also deutlich unter dem Budget für ein einzelnes Frame bei unseren angestrebten 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 grosse Modelle zu durchlaufen, ohne dass der Modellwechsel selbst jemals zum Engpass wird.

Echtzeit-Streaming-Veröffentlichung

Damit das Modell schnell genug ist, um in Echtzeit zu streamen, haben wir zahlreiche Inferenz-Optimierungen vorgenommen, bitte lesen Sie 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 ein separater Nachbearbeitungsschritt zu sein.

Fuer den Broadcast-ähnlichen Echtzeitpfad veröffentlichen wir die generierten Frames in Amazon Kinesis Video Streams (KVS). KVS wird normalerweise 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 encodiert und als Livestream in KVS eingespeist.

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

Ergebnisse und Erkenntnisse

Das Framework hat die Erstellung von Avatar IV und Avatar V von einer Rendering-Engine mit festen Szenen in eine offene, kontinuierliche Streaming-Generierung verwandelt. Das wichtigste Ergebnis ist einfach: Wir haben die Begrenzung der Szenendauer für Avatar IV und Avatar V entfernt. Bei der Avatar-IV-Generierung in Echtzeit haben wir eine Time-to-First-Frame von weniger als 5 Sekunden und eine Generierung mit über 27 Frames pro Sekunde für 720p-Avatar-IV-Videos erreicht – schneller als die Wiedergabe in Echtzeit.