Generar imagen y vídeo con código, sin difusión: MaLiang-Harness
TL;DR
- MaLiang-Harness (NUS, Fudan y Tencent; arXiv 2609.34309, v1 del 28-sep-2026) ataca lo que llaman P2V gap: un programa puede ejecutarse sin errores y aun así violar la composición, la apariencia o el movimiento pedidos. Su alternativa a la difusión: el modelo escribe código que se renderiza, se inspecciona y se revisa como un proceso persistente, no como un prompt único.
- El ganador de su benchmark es GPT-6-Astra: 100% de generación exitosa, con el 96,0% de las tareas de imagen y el 76,9% de las de vídeo cumpliendo todos los umbrales de calidad. Pero esa calidad la puntúa GPT-6-Sol, misma familia que el ganador, y el paper lo reconoce: “MLLM verdicts remain self-assessments rather than independent measures of perceptual quality”. No hay evaluación humana en la metodología.
- La desconexión entre benchmark general y capacidad visual es el dato más sólido: Kimi-K3 saca 44 puntos en el Intelligence Index de Artificial Analysis y cumple todos los criterios visuales solo en el 18% de las tareas (9 de 50). La correlación de Spearman entre índice y pass rate visual es ρ=0,65 — relacionada, pero lejos de ser un predictor.
- Lo que no puedes hacer hoy es reproducir el benchmark: el repo (14 estrellas en GitHub al 30-sep-2026, Python) no incluye los datasets del paper ni el pipeline de scoring visual, y el
reportpúblico no calcula los pass rates del paper. Lo que sí es jugable es el harness: demo offline sin API y generación con tu propia clave.
El P2V gap: el código compila y la imagen no
En generación por código —el modelo escribe un programa que dibuja o anima— el fallo típico no es una excepción de Python. Es un programa correcto que pone la taza a la derecha cuando el prompt la pedía a la izquierda, un zorro con tres patas o una animación donde el gato aparece de golpe en el teclado en vez de caminar hasta él. Los autores lo formalizan con un nombre: Program-to-Visual gap. Ejecutable no es sinónimo de visualmente correcto, y los checks de “el script terminó con código 0” no capturan nada de esto.
Es la misma objeción de fondo que aplica a cualquier pipeline agéntico: el éxito técnico de cada paso no implica que el resultado cumpla el requisito. Aquí, además, el requisito es visual, y por eso el paper construye toda la maquinaria alrededor de una idea: convertir la generación en un proceso persistente con revisión, donde se pueda mirar el render, editar el programa y volver atrás.
Para un sitio que cubre difusión —Stable Diffusion, MiniMax-H3, y compañía— esto es la otra vía: nada de denoising, solo código y un navegador que lo pinta. Los autores no la venden como sustituta general; reconocen en su propia discusión que el fotorrealismo y el refinamiento estancado siguen siendo problemas abiertos.
Cómo funciona: PEG, TGP y REV
Tres mecanismos, definidos en el paper y presentes en el repo:
- PEG (Persistent Executable Generation): el estado persistente —programa, contexto de tarea e historial— comparte una referencia de revisión común. Piensa en git para el proceso creativo: cada edición apunta a la revisión que modifica.
- TGP (Traceable Generation Process): conecta cada edición con su evidencia renderizada. La traza de tool calls y renders es inspeccionable, no se pierde entre mensajes del agente.
- REV (Revision-aware Editing and Verification): restauración a revisiones anteriores y verificación del estado actual antes de dar la tarea por terminada.
El modelo interroga ese estado con tool calls; el harness ejecuta el código y devuelve el render. Los backends de render, según README y paper:
| Backend | Para qué | Requisito |
|---|---|---|
| Canvas / SVG | Dibujo y animación 2D, parte del protocolo compartido | Chromium (Playwright) |
| Scene2D | Citado como backend del protocolo compartido | Chromium |
| Three.js | Animación 3D; módulos web precompilados | Chromium; no necesita Node en uso normal |
| Paint | Pinceladas por capas, presión, bordes suaves, difuminado y borrado | librería nativa libmypaint (opcional) |
| Pathtrace | Escenas quietas con materiales, luz y path tracing | WebGL; exporta solo PNG por ahora |
Todo el agente corre sobre Deep Agents, con el vendor pinneado en vendor/ (hay un UPSTREAM.json que fija el checkout): reproducible hoy, deuda de mantenimiento mañana.
Los números, y dónde están blandos
Setup verificado: 50 tareas de imagen (MaLiang-IBench) y 13 de vídeo (MaLiang-VBench). Los 11 modelos evaluados en imagen no son “11 modelos diversos”: son seis GPT, tres Kimi y dos DeepSeek. En vídeo solo evaluaron cuatro: GPT-6-Astra, GPT-5.6-Sol, Kimi-K2.6 y DeepSeek-V4.1-Flash. Tabla 3 del paper (IBench):
| Modelo | Éxito | Todos los criterios | Notas (alineación · estética · composición, 1-5) |
|---|---|---|---|
| GPT-6-Astra | 100% | 48/50 | 4,36 · 4,22 · 4,54 |
| GPT-6-Sol | 96% | 46/48 | 4,25 · 4,15 · 4,25 |
| GPT-6-Luna | 96% | 44/48 | 4,10 · 4,08 · 4,15 |
| GPT-5.6-Sol | 96% | 43/48 | 4,23 · 4,10 · 4,27 |
| GPT-5.6-Luna | 92% | 22/46 | 3,57 · 3,74 · 3,93 |
| GPT-5.6-Terra | 92% | 24/46 | 3,70 · 3,70 · 3,93 |
| Kimi-K2.7-Code | 40% | 12/20 | 3,75 · 3,60 · 3,70 |
| Kimi-K2.6 | 34% | 6/17 | 3,47 · 3,41 · 3,65 |
| Kimi-K3 | 18% | 9/9 | 4,56 · 4,22 · 4,33 |
| DeepSeek-V4-Pro | 18% | 8/9 | 4,11 · 3,89 · 4,11 |
| DeepSeek-V4.1-Flash | 12% | 6/6 | 4,33 · 4,00 · 4,17 |
Tres lecturas que el resumen del paper no destaca:
El bloque GPT gana por volumen de ejecución, no solo por calidad. Los seis GPT completan entre 46 y 50 imágenes; los Kimi entre 9 y 20; los DeepSeek, 6 y 9. Y las medias de calidad se calculan solo sobre las exitosas: el 4,56 de Kimi-K3 en alineación es la nota más alta de toda la tabla, pero sobre 9 imágenes —las 9 que logró, todas cumplen criterios—. Su problema no es que lo que dibuja sea malo; es que solo completa el 18% de las tareas. Comparar esa media con la de Astra sobre 50 imágenes es comparar medias con denominadores seis veces distintos.
DeepSeek-V4.1-Flash se estrella contra el presupuesto de tokens. Cero tareas de vídeo completadas de 13, y el agotamiento del presupuesto explica 5 de sus 13 fallos —el paper habla de “reasoning stagnation and unbounded agentic loops”. En imagen, 44 de sus 50 casos terminan en fallo. El harness le da herramientas y loop de revisión; el modelo las usa hasta quedarse sin tokens.
Vídeo: 13 tareas, un intento grabado por modelo. Astra cumple los 4 umbrales en 10 de 13; GPT-5.6-Sol en 5 de 7 exitosos; Kimi-K2.6 completa 3 y ninguna pasa todos los criterios; DeepSeek-V4.1-Flash, ninguno. Detalles de metodología que conviene conocer antes de citar cifras: el vídeo usa “un intento grabado por modelo y tarea”, los resultados de Astra provienen de runs históricos, y el batch de DeepSeek con límite de 32K tokens quedó excluido por incompleto (se reporta el de 64K).
La tabla “verificado vs claim” de lo que circula sobre este paper:
| Dato | Estado | Fuente |
|---|---|---|
| ”11 potentes MLLMs cerrados” | Verificado que son 11; falta el matiz: solo 3 familias (6 GPT, 3 Kimi, 2 DeepSeek) | Tablas 2-3 del paper |
| Astra: 100% éxito, 96,0% imagen / 76,9% vídeo con todos los umbrales | Verificado (abstract y tablas 3 y 5) | arXiv 2609.34309 |
| Kimi-K3: “44 en el índice AA pero solo 18/50 tareas” | Corregido: son 44 puntos y el 18% de tareas — 9 de 50 | Paper, §4.3 y Fig. 9 |
| La calidad la puntúa un MLLM | Verificado, y es GPT-6-Sol: misma familia que el ganador | Paper, §4.1 |
| ”MLLM verdicts remain self-assessments…” | Cita literal del paper | Paper, §3.3 |
| IBench “combina batches, reintentos y runs históricos” | Cita literal del paper sobre su propia agregación | Paper, apéndice (agregación de runs de IBench) |
| El repo permite reproducir el paper | Falso: sin datasets completos, sin resultados históricos, sin pipeline de scoring visual; el report no da los pass rates | README, “Relationship to the Paper’s Experiments” |
El problema del juez: GPT juzga a GPT
La metodología de calidad, en detalle: GPT-6-Sol puntúa de 1 a 5 la alineación con el prompt, la estética y la composición; en vídeo añade coherencia de movimiento sobre 12 frames ordenados temporalmente. “Cumplir todos los criterios” significa nota ≥4 en cada dimensión. No hay evaluadores humanos en ninguna parte de la metodología.
El paper dedica tres líneas a reconocer el problema —las ya citadas “self-assessments rather than independent measures of perceptual quality”— y sigue adelante. Es honestidad parcial: declarar el sesgo no lo corrige. Que el juez sea de la misma familia que el ganador no invalida el concurso, pero condiciona el reparto de premios, sobre todo entre familias: las comparativas GPT contra Kimi o DeepSeek dependen de los gustos de un modelo entrenado por el mismo laboratorio que el concursante que da ya un 96% de acierto.
A esto se suman dos detalles de configuración: DeepSeek-V4-Pro fue evaluado sin feedback visual (nota del propio paper en §4.1), e IBench “combina múltiples batches, reintentos y runs históricos en lugar de intentos uniformes de primera pasada” (apéndice, protocolo de evaluación). Nada de esto convierte los números en falsos; los convierte en comparaciones condicionales. Si vas a citarlas, cita las condiciones.
Probarlo tú: lo que sí y lo que no
Lo reproducible hoy, del README:
- Demo offline sin API:
python examples/scene_demo.py --project runs/scene-democorre con un modelo scripted. Sirve para entender el ciclo render → inspección → edición sin gastar un céntimo. - Generación con tu clave:
inference.pyhabla con la Responses API (o cualquier gateway compatible que soporte las tool calls y la interacción multimodal). Define modelo, presupuestos y canvas en el config; edición y reanudación por revisión incluidas (--edit-from runs/X --revision 3,--resume). - Tu propio benchmark:
python -m benchmarksconbenchmarks/models.local.json(hay example). Plan, run y report; el report resume finalización, validez técnica, tiempos y consumo sin llamar al modelo.
Lo que no está: los datasets completos del paper, los resultados históricos y el pipeline de scoring visual. El README lo dice sin ambigüedad: las completion rates del report público “no son los pass rates de calidad visual del paper”. Reproducir el experimento completo requeriría las tareas, versiones de modelo, presupuestos, adaptadores y protocolo de scoring exactos — y parte de eso no se ha publicado.
Contexto de repo, porque importa al decidir cuánto invertir: 14 estrellas al 30-sep-2026, primer push reciente, documentación con secciones en chino (las anclas del README lo delatan), Deep Agents vendor-pinneado. Es un release de investigación jugable, no un proyecto con comunidad. Instálalo sabiendo eso.
Cuándo te sirve esta vía y cuándo no
Te sirve si tu problema es control y edición: gráficos programáticos (diagramas, pixel art, escenas de UI, ilustración plana), assets que necesitas retocar sin regenerar desde cero, procesos donde la traza auditable importa, o vídeos cortos silenciosos donde el movimiento definido por código es suficiente. La capacidad de volver a una revisión anterior y ramificar es algo que la difusión no te da así de nativo.
No te sirve si necesitas fotorrealismo o riqueza visual difusa: el paper lo admite (“Photorealism and stalled refinement remain challenges”), y el refinamiento que se estanca es un modo de fallo real —el modelo revisa en círculos sin mejorar—. Para foto y vídeo rico, los modelos de difusión siguen siendo la herramienta; para eso los cubrimos aquí normalmente.
En coste, mira las trazas, no solo la nota. Astra gasta de media 6,34 calls, 142k tokens de entrada y 8,1k de salida por caso de imagen; Kimi-K2.7-Code llega a 1.056k tokens de entrada por caso. Con el pricing por token de cada API —el de Astra lo desglosamos en su pieza—, el bucle agéntico con revisión visual no es gratis, y los modelos que se atascan en loops pagan dos veces: tokens y tiempo.
Qué haría yo
Si generas gráficos programáticos con revisión, monta la demo offline hoy: es gratuita y te enseña si el paradigma encaja con tus casos. Si vas a evaluar modelos con este harness, usa tus propias tareas y un juez independiente de los evaluados —o un spot-check humano—; los rankings del paper son una foto de la familia GPT puntuada por la familia GPT. Y si solo querías un número para citar: cita el P2V gap y ρ=0,65, que sobrevivirán al juez.
La contribución duradera de MaLiang-Harness no es su leaderboard: es el planteamiento de la generación visual como proceso persistente con revisiones. El benchmark, ese, tómatelo como lo que el propio paper confiesa que es: autoevaluación.
Fuentes
- MaLiang-Harness: A Programmable Path to Image and Video Generation — arXiv 2609.34309 (v1, 28-sep-2026, CC BY 4.0; abstract, §3, §4 y tablas 3-5; autores de NUS, Fudan y Tencent)
- HTML completo del paper (citas literales de metodología y limitaciones)
- gulucaptain/MaLiang-Harness — GitHub (README: backends, quick start, “Relationship to the Paper’s Experiments”; 14 stars al 30-sep-2026)
- Página del paper en Hugging Face (229 upvotes al 30-sep-2026; autor verificado)
- Piezas relacionadas: GPT-6 Astra: precios y contexto de 1M · Kimi K3, primer modelo open-weight frontera · El benchmark WROP de permanencia en modelos de vídeo