DuoMatching: vídeo few-step con dos profesores y el matiz del 80%

TL;DR

• Verificado contra fuentes primarias (arXiv 2610.03543, v1 del 02/10/2026, HTML completo y Tables 1-4 leídas; repo GitHub con código real —train.py, inference.py, configs— y pesos en Hugging Face): DuoMatching (ByteDance + CUHK/HKUST; preprint sin peer review, 5 días de vida al 07/10/2026) destila Wan2.1-T2V-1.3B a 1-4 pasos añadiendo a la destilación por matching de distribución (DMD) un segundo profesor de imagen congelado —Qwen-Image— que da supervisión frame-level.
• El titular «preferencia superior al 80% contra todos los baselines» es real pero estrecho: es solo la columna Overall de su estudio humano (2AFC, 23 participantes, 40 pares por evaluador). Contra Causal Forcing++ roza el umbral: 80,87%. En la dimensión Temporal & Motion hay empate técnico (49,57% vs Causal Forcing++, 51,30% vs CausVid). El propio paper lo formula con honestidad: “largely preserving motion dynamics”.
• Lo que gana es calidad visual y semántica: en VBench (chunk 4 pasos), 83,51 de total vs 82,79 del mejor baseline (+0,72), con la misma NFE. Sin profesor de imagen, el total cae a 80,67 y el score semántico a 68,42 (vs 72,84 con Qwen-Image).
• En movimiento no gana: 76,67 de Dynamic vs 80,56 de Causal Forcing++ en chunk 4. La ventaja está en frames, no en la coreografía.
• Código Apache-2.0 y checkpoint público (2 pasos, student 1.3B): la inferencia es ejecutable hoy con una GPU NVIDIA CUDA. Reproducir el entrenamiento completo son 8 GPUs. Los pesos upstream mantienen sus propias licencias.

El problema: igualar la distribución conjunta de frames no basta

La familia de destilación DMD (CausVid, Self Forcing, Reward Forcing, Causal Forcing++) comprime un generador de vídeo por difusión a 1-4 pasos igualando la distribución conjunta de los frames del vídeo: el student aprende a producir secuencias completas que el teacher de vídeo no distinga de vídeo real. Este matching conjunto es lo que mitiga la deriva en rollouts autoregresivos —sin él, cada frame generado condiciona al siguiente y los errores se acumulan—. El precio, según el paper (§1): “limitations remain in visual quality and semantic alignment”. El vídeo few-step gana velocidad pero pierde detalle visual y adherencia al prompt.

La observación de DuoMatching (§3.2): la supervisión conjunta no dice nada granular sobre cada frame aislado. Un generador de imágenes, en cambio, está optimizado exactamente para eso. La formulación joint-marginal añade al matching conjunto un término marginal que supervisa frames individuales usando un profesor de imagen, transfiriendo sus priors visuales y semánticos al student de vídeo. Dos profesores: uno enseña cómo se mueve la secuencia, el otro cómo debe verse cada fotograma.

El encaje técnico: LatentBridge y Latent Variation Sampling

Hay dos problemas de ingeniería entre la idea y su ejecución, y el paper les dedica §3.3 y §3.4.

El mismatch de latentes. El student de vídeo trabaja en un espacio latente comprimido temporalmente; el profesor de imagen (Qwen-Image) en su propio espacio latente de imagen. No se puede aplicar el término marginal directamente: la ablación de Table 4 lo cuantifica. Aplicar DMD marginal “Direct” sobre los latentes de vídeo comprimidos sube el total a 81,78 pero hunde la métrica Dynamic de 94,44 a 76,94 —el término marginal, mal aplicado, castiga justo lo que el matching conjunto protegía—. La alternativa “Decode-Encode” (decodificar a RGB y re-codificar con la VAE de imagen manteniendo gradientes) no cabe en memoria: OOM. La solución, LatentBridge, es un módulo puente minúsculo: 8 bloques residuales FiLM con 256 canales ocultos, 10,75M de parámetros entrenables, entrenado aparte sobre 29.400 vídeos de OpenVid a 480p (3.000 iteraciones, ~15 minutos en ocho GPUs de 80 GB). Con LatentBridge, Dynamic se recupera a 93,61 y el total llega a 83,53, con 59,41 GB de pico por iteración de entrenamiento.

La redundancia temporal. Supervisar cada frame con el profesor de imagen sería absurdamente caro y redundante: los frames contiguos se parecen. Latent Variation Sampling (§3.4) detecta las transiciones fuertes en la secuencia latente, la particiona en segmentos temporales y samplea un frame por segmento. Es la estrategia por defecto en la config (qwen_image_teacher.frame_sampling: transition_segments).

El setup completo (§4): student Wan2.1-T2V-1.3B; teacher de vídeo Wan2.1-T2V-14B; teacher de imagen Qwen-Image congelado; vídeos de 81 frames a 480×832. El modo causal parte del checkpoint de consistency distillation de Causal Forcing++ y entrena DMD 1.000 pasos en VidProM; el bidireccional inicializa desde Wan2.1-T2V-1.3B y entrena 1.200 pasos en Mixkit. Nada de esto es coste extra en inferencia: el paper lo remarca (“without additional inference computation”), el student sigue siendo few-step.

Los números, con contexto

VBench en el modo chunk de 4 pasos, todos con el mismo teacher de vídeo (Wan2.1) — comparación justa por diseño, cifras autoreportadas de Table 1:

Método (chunk, 4 pasos)	Semantic ↑	Imaging ↑	Dynamic ↑	Total ↑
CausVid	68,69	66,97	55,83	80,19
Self Forcing	71,41	69,66	68,61	81,52
Reward Forcing	56,23	71,72	73,61	80,10
Causal Forcing++	70,84	70,13	80,56	82,79
DuoMatching	71,61	72,41	76,67	83,51

+0,72 de total sobre el mejor baseline. Modesto en agregado, más interesante por dónde viene: el score semántico sube y la calidad de imaging también. En Dynamic, DuoMatching queda 3,89 puntos por debajo de Causal Forcing++. En los otros modos el patrón se repite: frame-wise a 1 paso, 82,65 vs 82,09 de One-Forcing (+0,56); a 2 pasos, 83,53 vs 80,67 de Causal Forcing++ (+2,86), con Dynamic 93,61 vs 94,44.

La ablación del profesor de imagen (Table 3) es el experimento que sostiene la tesis: sin profesor, total 80,67; con Wan2.1-14B como profesor de imagen, 81,43; SDXL, 81,47; FLUX.2-4B, 82,64; Qwen-Image, 83,53. El ranking de estudiantes replica el ranking de profesores medido por HPSv3 (5,87 / 6,57 / 8,86 / 9,05): mejor generador de imágenes, mejor student. Y el salto semántico es lo más acusado del paper: 68,42 → 72,84 (+4,42) solo por añadir el término marginal bien encauzado.

La trampa del «80% de preferencia»

El estudio humano (Table 2) es un 2AFC: 23 participantes, 40 pares de vídeos por evaluador, preferencia por método. Lo que circula como «preferido en más del 80% frente a todos los baselines» es exclusivamente la columna Overall:

Comparación	Calidad visual	Alineación semántica	Temporal y movimiento	Overall
vs CausVid	92,17%	89,13%	51,30%	91,30%
vs Causal Forcing++	81,30%	79,57%	49,57%	80,87%
vs One-Forcing	93,48%	91,74%	90,87%	94,35%
vs Reward Forcing	83,91%	82,61%	60,87%	83,91%

Léelo así: la ventaja masiva está en calidad visual y alineación semántica. En Temporal & Motion, contra Causal Forcing++ el 49,57% es estadísticamente un empate (los jueces prefieren a cada método casi lo mismo), y contra CausVid el 51,30% tampoco es una victoria. Coherente con la tabla VBench: donde se juega la partida es en el fotograma, no en el movimiento. El resumen del propio abstract —“largely preserving motion dynamics”— es la frase correcta; «mejor en todo» no lo es.

Dos reservas de método: la evaluación es autoreportada (sin réplica de terceros, y los baselines comparados son todos de la misma familia DMD bajo el mismo teacher — diseño justo, pero cada cifra sale del laboratorio que propone el método), y las mejoras de total VBench de +0,6 a +2,9 puntos son marginales salvo en las dimensiones concretas (semántica, imaging) donde el término marginal actúa. Los 68 upvotes en Hugging Face al 07/10/2026 miden interés de la comunidad, no validación técnica.

Probarlo hoy: repo, pesos y comando

Lo que diferencia esta pieza de otros papers de la familia: hay código real y pesos publicados. El repo (Apache-2.0 el código; los pesos upstream conservan sus licencias) incluye train.py, inference.py, configs y los pesos de LatentBridge. El checkpoint publicado es un modelo de 2 pasos destilado desde Wan2.1-T2V-14B, con el student de 1.3B:

git clone --branch main https://github.com/JohnZhan2023/DuoMatching.git
cd DuoMatching
conda create -n duomatching python=3.10 -y && conda activate duomatching
pip install -r requirements.txt
pip install flash-attn==2.8.3.post1 --no-build-isolation
pip install -e . --no-deps

hf download Wan-AI/Wan2.1-T2V-1.3B --local-dir wan_models/Wan2.1-T2V-1.3B
hf download JohnZhan/DuoMatching --local-dir checkpoints/DuoMatching

python inference.py \
  --config_path configs/duomatching_inference.yaml \
  --checkpoint_path checkpoints/DuoMatching/model.pt \
  --use_ema \
  --data_path prompts/demos.txt \
  --output_folder outputs/demo \
  --end_index 1 \
  --num_output_frames 21 \
  --seed 0

Requisitos reales: GPU NVIDIA con CUDA, Python 3.10, PyTorch 2.6, flash-attn (el backbone causal usa además FlexAttention). La demo genera 21 frames; la evaluación del paper es a 81 frames y 480×832. No hay pesos 14B que ejecutar —ese es solo el teacher— ni 1080p ni vídeo largo. Reproducir el entrenamiento completo exige las 8 GPUs del torchrun --nproc_per_node=8; reentrenar LatentBridge, un manifest JSONL con tus vídeos y las mismas ocho GPUs (15 minutos de train, el coste está en preparar el caché de latentes).

Qué mirar desde aquí

Tres cosas dirán si esto trasciende al paper: si la formulación joint-marginal se adopta en la línea Causal Forcing (DuoMatching se construye sobre su código base, y Causal Forcing++ es a la vez su mejor baseline y su punto de partida); si aparece una réplica independiente de las tablas —hoy todo es autoreportado—; y si el truco generaliza a resoluciones y duraciones mayores, donde la supervisión frame-level de un profesor de imagen tiene más sitio donde aportar. La dirección es plausible: la ablación muestra que el techo del student lo marca la calidad del profesor de imagen, y ahí el mercado no ha dejado de mejorar. Para contexto de destilación —cuándo el matching on-policy vs off-policy importa en este tipo de pipelines— tenemos el análisis de la dirección KL en destilación; y si tu interés es generar imagen y vídeo sin difusión, MaLiang-Harness cubre el otro extremo del espectro.

Fuentes: arXiv 2610.03543 (abstract) · HTML v1 completo (Tables 1-4, §1-§5, Appendix A) · repo GitHub · pesos Hugging Face. Todas las cifras de este artículo son claims de la versión v1 del 02/10/2026 salvo indicación contraria; verificadas literalmente contra el HTML v1 el 07/10/2026.