Avatar video only feels believable if the person stays consistent over time. When the face drifts, the teeth change, the lip sync slips, or the motion resets between clips, people notice immediately. This matters more for avatars than for many other video generation tasks because the viewer is watching a specific person speak, often at close range, for a long time.

En el mundo actual de generación de video, la duración sigue siendo una de las limitaciones más visibles. Muchos modelos y productos ofrecen la generación como un clip de longitud fija —unos pocos segundos, y muy pocos sistemas pueden generar más de unos cuantos minutos. En los productos de avatares, ese límite impacta directamente los flujos de trabajo de los clientes. Los clientes quieren escenas/videos más largos y consistentes para videos de capacitación, demostraciones de ventas, recorridos de producto, educación, soporte y agentes que deban seguir hablando hasta que la tarea termine, y además quieren una vista previa rápida para iterar sobre prompts, movimiento y guion.

At Heygen, that translated into three concrete requirements:

1. Coherencia en escenas largas. El avatar debe conservar la identidad, la sincronización labial, la expresión y la continuidad del movimiento no solo en un clip corto, sino a lo largo de muchos fragmentos de video generado.
2. Sin límite fijo de duraciónUna generación puede durar diez segundos, diez minutos o ser una sesión en tiempo real sin límite definido.
3. Fast preview, realtime or faster-than-realtime generation. The system should start producing frames quickly and even allow streaming out the generated frames while inference is still ongoing.

En esta publicación explicamos paso a paso el framework de inferencia que creamos para cumplir con esos requisitos.

La arquitectura subyacente del modelo

El framework se basa en los modelos de generación de videos con avatares de HeyGen — las familias Avatar IV y Avatar V. A grandes rasgos, el modelo toma una imagen/video de referencia, el audio que lo impulsa y texto opcional o condicionamiento por escena, y luego genera un video de ese avatar hablando con la identidad, expresión y movimiento correctos.

El modelo central de generación es un Diffusion Transformer, o DiT, entrenado con flow matching. En lugar de comprimir a la persona en una pequeña incrustación de identidad, el modelo se condiciona con tokens de referencia ricos para poder conservar los detalles que son importantes para los avatares: la forma de la cara, los dientes, la textura de la piel, el movimiento de la boca, el estilo de los gestos y el ritmo al hablar.

La ruta de inferencia en producción tiene tres etapas principales:

1. Generación de audio a video. Un modelo DiT base genera latentes de video de baja resolución a partir de la identidad de referencia, las características de audio y las señales de condicionamiento. Esta etapa se centra en el movimiento, la sincronización labial (lip-sync) y la coherencia temporal.
2. Súper resolución con reconocimiento de identidad. Un segundo modelo refina esos latentes para generar un resultado en alta resolución, con especial atención en las zonas donde las personas son más sensibles a los artefactos, en particular la cara y la boca.
3. Decodificación VAE en streaming. Un decodificador VAE convierte latentes de alta resolución en fotogramas RGB, por partes, para que los fotogramas se puedan emitir antes de que el video completo esté listo.

Para generar videos largos, el sistema procesa los datos por segmentos. Mientras que el primer segmento depende por completo de la referencia estática, los segmentos siguientes utilizan datos de los límites de los tramos anteriores. Esto permite que el avatar continúe hablando de forma natural sin reiniciar su postura ni su identidad desde cero.

El framework de streaming y el ciclo de la canalización

Para adaptarse a la ejecución basada en fragmentos, el framework de inferencia utiliza una arquitectura modular de tres niveles que opera sobre ventanas de tiempo localizadas y libera los recursos inmediatamente después de que se procesa cada fragmento.

• Módulo: un contenedor alrededor de un modelo específico y su checkpoint (por ejemplo, A2V DiT, Super-Resolution DiT, componentes VAE, codificadores de texto/audio).
• Etapa: una unidad de ejecución tipada que coordina uno o más módulos (por ejemplo, generación de contexto, superresolución).
• Flujo de procesamiento: el grafo de ejecución que conecta las etapas, administra el estado compartido y coordina los modos de ejecución en streaming o por lotes.

La fase de inicialización codifica la identidad de referencia en latentes una vez por cada solicitud. Luego, el pipeline ejecuta un ciclo continuo a través de las etapas restantes hasta que se agota el flujo de audio de entrada:

• Generación de contexto: Convierte los segmentos de audio entrantes en características, los combina con texto o condicionamiento de escena y prepara los tensores de ruido objetivo.
• Audio a video: Ejecuta un proceso de difusión en múltiples pasos para generar latentes de baja resolución. En esta etapa se condiciona el fragmento actual con los fotogramas de borde del fragmento anterior para mantener la continuidad del movimiento.
• Súper resolución: aumenta la resolución de los latentes de movimiento a resolución completa en un solo paso, priorizando el detalle espacial en el rostro.
• VAE Decode-and-Publish: decodifica los latentes de alta resolución en fotogramas RGB y los envía directamente al codificador de salida (H.264 / AAC) para su almacenamiento inmediato o reproducción en vivo.

Continuidad de bordes y coherencia entre fragmentos

Generar video en segmentos diferenciados introduce posibles discontinuidades en los límites. El framework mitiga esto utilizando dos clasificaciones de fragmentos distintas:

• Fragmentos N: segmentos que generan la línea de tiempo principal del avatar.
• I Chunks (Interpolación): segmentos diseñados para suavizar las transiciones entre N Chunks secuenciales.

La secuencia de ejecución está estructurada de la siguiente manera:

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

Un fragmento I se genera solo después de que se completan los fragmentos N anteriores y posteriores. Utiliza el fotograma final del fragmento N previo y un fotograma temprano del fragmento N actual como fotogramas de anclaje para calcular el movimiento de transición. Después de la generación, se descartan las predicciones de anclaje redundantes, dejando únicamente la transición suavemente interpolada. Este mecanismo limita la ventana de contexto necesaria y, al mismo tiempo, preserva la consistencia temporal.

Memoria constante durante la duración

Una canalización de video convencional acumula latentes, cuadros decodificados y contexto de atención durante la ejecución, lo que hace que el consumo de memoria de la GPU aumente de forma lineal con la duración del video.

Para permitir una generación abierta, este framework mantiene un estado rodante estricto. El sistema conserva únicamente el condicionamiento de referencia estático y un conjunto mínimo de tensores ancla necesarios para las transiciones entre fragmentos. Todos los recursos intermedios —incluidas las características de audio, los tensores de ruido, las activaciones internas y los fotogramas RGB sin procesar— se eliminan de la memoria inmediatamente después de que un fragmento se decodifica y se escribe.

Como resultado, el perfil máximo de uso de memoria de la GPU se mantiene constante tanto si se genera un clip corto como una secuencia extendida; la utilización de recursos escala con el tamaño de bloque definido y no con la duración total de la sesión.

Etapas de carga y descarga dentro del flujo de procesamiento

Cada solicitud se ejecuta en un nodo con 8 GPU. Usamos FSDP para fragmentar los parámetros de modelos grandes entre las GPU. Cada rango posee solo una fracción de los pesos, reúne los parámetros que necesita para un cálculo y luego los libera de nuevo. Esto es lo que permite que varios modelos grandes —el DiT base, el DiT de superresolución, el codificador de texto, el codificador de audio y el VAE— quepan en un solo nodo.

Hay una compensación. FSDP introduce una sobrecarga de comunicación durante la inferencia porque es necesario reunir los parámetros durante las pasadas hacia adelante. Usamos una combinación de técnicas para ocultar esa sobrecarga y mantener los modelos ubicados en el mismo nodo fuera de la GPU cuando no están en uso:

• Prefetching hacia adelante. La operación AllGather de los parámetros del siguiente bloque se lanza por adelantado y se solapa con el cálculo del bloque actual, ocultando la latencia de recopilación en la ruta crítica.
• Desfragmentación perezosa por bloque desde la CPU. Cuando un modelo se trae de vuelta desde la memoria fijada de la CPU, no cargamos por adelantado todo el conjunto de pesos. Cada bloque del transformador se desfragmenta (copia de host a dispositivo + AllGather) justo antes de su pasada hacia adelante, de modo que la transferencia H2D del bloque n+1 se superpone con el cómputo del bloque n.
• Descarga en CPU fijada entre etapas. Los parámetros de un modelo que no se está ejecutando en ese momento se mantienen en memoria de CPU fijada, de modo que los modelos ubicados en el mismo servidor (DiT base, DiT de superresolución, codificador de texto, codificador de audio, VAE) no tienen que mantener todos sus pesos en la GPU al mismo tiempo. La memoria fijada es lo que hace que las copias H2D sean lo suficientemente rápidas como para solaparse con el cómputo.
• Ubicación de procesos optimizada para NUMA. Cada proceso se fija al mismo nodo NUMA que su GPU asignada, de modo que las transferencias CPU↔GPU se realizan al ancho de banda máximo de PCIe/NVLink sin cruzar el interconector entre sockets.

Cambio de modelo en menos de 10 ms entre etapas

El beneficio práctico de las técnicas anteriores es que pasar la GPU del modelo de una etapa al de la siguiente —por ejemplo, de A2V DiT → Super-Resolution DiT, o de SR DiT → decodificador VAE— es prácticamente gratuito. Como el modelo saliente se descarga de forma asíncrona y el primer bloque del modelo entrante se desfragmenta justo a tiempo, tanto la copia H2D como el AllGather quedan ocultos detrás del cómputo que ya se está ejecutando. De extremo a extremo, la sobrecarga observable por cada cambio de modelo es inferior a 10 ms —muy por debajo del presupuesto de un solo cuadro en nuestras tasas de cuadros objetivo. En concreto, esto es lo que permite que el ciclo del flujo de streaming (Context Gen → A2V → SR → VAE Decode-and-Publish) recorra varios modelos grandes por fragmento sin que el propio cambio de modelo se convierta nunca en el cuello de botella.

Publicación en streaming en tiempo real

Para que el modelo sea lo suficientemente rápido para transmitir en tiempo real, hemos realizado muchas optimizaciones de inferencia; por favor consulte https://www.heygen.com/research/avatar-v-inference para más detalles sobre esta parte.

Una vez que el pipeline emite el video por fragmentos en tiempo real, la transmisión se convierte en una extensión natural de la inferencia en lugar de ser una etapa de posprocesamiento independiente.

Para la ruta en tiempo real de tipo transmisión, publicamos los fotogramas generados en Amazon Kinesis Video Streams (KVS). KVS suele mencionarse en el contexto de cámaras, dispositivos IoT y contenido multimedia cargado. En nuestro caso, la “cámara” es la propia canalización de inferencia: los fotogramas son creados por el modelo, codificados de inmediato y enviados a KVS como una transmisión en vivo.

El escritor de salida recibe cuadros RGB decodificados desde el VAE de streaming y los envía a una canalización de GStreamer. El video se codifica en H.264 y el audio en AAC, luego ambas pistas se envían a kvssink, el sink productor de KVS. Desde allí, los espectadores pueden reproducir la sesión como una transmisión en vivo mientras todavía se está generando.

Resultados y aprendizajes

El framework cambió la generación de Avatar IV y Avatar V de un renderizado de escenas fijas a una generación continua y abierta por streaming. El resultado más importante es sencillo: eliminamos los límites de duración de escena para Avatar IV y Avatar V. Para la generación en tiempo real de Avatar IV, hemos logrado un tiempo hasta el primer cuadro de menos de 5 segundos y una generación de más de 27 cuadros por segundo para videos Avatar IV en 720p, más rápido que la reproducción en tiempo real.