Uso del empaquetado de contexto de fotogramas de entrada en modelos de predicción del siguiente fotograma para generación de video
(lllyasviel.github.io)- FramePack es un enfoque basado en Next-Frame Prediction para usar un modelo de difusión de video de 13B en la generación de videos largos incluso con 6 GB de memoria GPU en una laptop
- En lugar de tratar los fotogramas de entrada con la misma longitud, asigna distintos patchifying kernel por fotograma para destinar más recursos de GPU a los fotogramas importantes más cercanos al objetivo de predicción
- En HunyuanVideo, un fotograma de 480p puede reducirse desde unos 1536 tokens con
(1, 2, 2)hasta 192 tokens con(2, 4, 4), y la complejidad de cómputo en streaming es O(1) - FramePack Scheduling ajusta la importancia de los fotogramas y la tasa de compresión, y en image-to-video también permite una programación que trata los fotogramas iniciales con la misma importancia
- Para reducir el drifting causado por errores acumulados en la generación de videos largos, usa muestreo bidireccional que rompe la causalidad, y el inverted anti-drifting sampling es adecuado para image-to-video
Empaquetado de contexto de fotogramas de entrada en FramePack
- FramePack es un método en el que un modelo de Next-Frame o Next-Frame-Section Prediction recibe varios fotogramas de entrada y genera nuevos fotogramas mediante difusión
- El rendimiento objetivo y las condiciones de uso son los siguientes
- Generación de miles de fotogramas a 30 fps con un modelo de 13B en una GPU de laptop con 6 GB de memoria
- Fine-tuning de un modelo de video 13B con batch size 64 en un único nodo de 8xA100/H100
- Generación a 2.5 segundos por fotograma antes de la optimización en una RTX 4090 personal, y 1.5 segundos por fotograma usando teacache
- Sin timestep distillation
- La clave es que, en lugar de simplemente concatenar las imágenes de entrada, se colocan distintas longitudes de contexto por fotograma dentro de un layout lógico de memoria GPU
- La longitud de contexto de cada fotograma se controla con distintos patchifying kernel
- En HunyuanVideo, un fotograma de 480p tiene unos 1536 tokens al usar un patchifying kernel de
(1, 2, 2) - Si se cambia a un patchifying kernel de
(2, 4, 4), pasa a 192 tokens por fotograma
- En HunyuanVideo, un fotograma de 480p tiene unos 1536 tokens al usar un patchifying kernel de
- A los fotogramas más importantes, como los que están más cerca del objetivo de predicción del siguiente fotograma, se les asigna un contexto más largo
- La complejidad de cómputo en streaming es O(1), no O(nlogn) ni O(n)
Programación y prevención del drifting
- FramePack Scheduling soporta casos donde la importancia de los fotogramas no sigue un patrón simple, donde cambia la tasa de compresión, o donde los fotogramas indicados por el usuario deben tratarse como más importantes
- En image-to-video, como el primer fotograma es importante, puede usarse una programación que haga que los fotogramas iniciales tengan la misma importancia
- Toda la programación es O(1), y la evaluación de varios esquemas de programación está incluida en el Paper
- En los modelos de Next-Frame Prediction, el drifting, donde la calidad cae a medida que el video se vuelve más largo, es un problema común
- Si se repite como entrada el último fotograma generado para crear un video largo, el resultado se degrada rápidamente tras 5 o 6 iteraciones, y puede deteriorarse gravemente después de unas 10 iteraciones
- Este problema también se conoce como error accumulation o exposure bias
- El paper también incluye experimentos sobre métodos existentes como history noise augmentation, special cfg guidance y rolling diffusion timesteps
- Para abordar el drifting de forma fundamental, hay que romper la causalidad y hacer que el muestreo sea bidireccional
- Solo vanilla sampling es un método causal
- anti-drifting sampling e inverted anti-drifting sampling son métodos bidireccionales
- inverted anti-drifting sampling trata el primer fotograma como objetivo aproximado en toda la inferencia y es adecuado para image-to-video
Condiciones de la demo y materiales de referencia
- Los resultados de la demo se calcularon con una laptop RTX 3060 6GB y la variante HY de 13B
- image-to-5-seconds: 30fps, 150 fotogramas
- image-to-60-seconds: 30fps, 1800 fotogramas
- Para ajustarse al repositorio de GitHub, los videos se comprimieron con h264crf18
- Como materiales relacionados se ofrecen Paper, Code, FramePack-P1 Preview
1 comentarios
Opiniones de Hacker News
Esta persona es un genio. Tal vez algunos no lo sepan, pero ControlNet también lo creó él.
Es muy significativo porque es el primer modelo de generación de video realmente usable que corre en hardware de consumo, y espero que pronto también llegue el soporte de poses de ControlNet.
Seguramente las grandes empresas le hicieron ofertas enormes; de verdad tiene un talento excepcional.
Es gracioso cómo parece empeñado en hacer que la gente baile. Incluso una persona sentada para una entrevista empieza a bailar sin levantarse.
En imágenes estáticas siempre terminamos buscando ojos, y en video siempre terminamos buscando baile.
Los ejemplos son bastante impresionantes, pero los recursos usados para crearlos en realidad son prácticamente mínimos. Parece que la inferencia podría correr incluso en hardware de consumo de la generación anterior.
Algún día me gustaría ver cifras de throughput de inferencia en una 5090.
¿Se podría hacer esto también en la dirección espacial? Por ejemplo, me pregunto si sería posible generar una imagen de arriba hacia abajo en vez de generarla de una sola vez.
¿Se podría usar esto para interpolación de video en lugar de extrapolación?
Sorprendente. ¿Podría volverse más rápido con más recursos, como RAM? También me da curiosidad si en una H100 o H200 se podría exprimir más velocidad.
Parece que, en la práctica, la única acción que puede hacer es bailar.