AgentGarten: el mundo como código, la vista como modelo (32 H100)
TL;DR
- Verificado: en AgentGarten el renderer neural es el único binding entre lo que el agente ve y lo que el mundo hace. La simulación corre en motores reales —estado persistente, reglas ejecutables, terreno modificable— y el renderer convierte lo que cada motor exporta (profundidad, normales) en vídeo 480×832 a más de 35 fps en una sola H100. Ese renderer es lo publicado: código de entrenamiento e inferencia Apache-2.0 y checkpoints en Hugging Face.
- Verificado: agentes preentrenados, viendo solo píxeles renderizados, construyen refugios en la ronda 4 y cruzan muros con rampas en la ronda 10 del mismo hide-and-seek que el RL de 2019 necesitó ~25 y ~100 millones de episodios para descubrir. La comparación la matiza el propio paper: dos paradigmas de aprendizaje distintos, no un ratio de eficiencia muestral.
- Verificado: cada etapa de entrenamiento corrió en 32 NVIDIA H100. El paper no publica duración, así que el coste por run no se puede calcular: solo estimar por rangos de mercado, con la cuenta explícita más abajo.
- Claim del vendor: que esto acerca “agentes que siguen mejorando a través de experiencia interactiva”. El bucle que lo haría —mundos de código, rondas de práctica, playbooks operando en producción— no está liberado todavía; hoy es un renderer de vídeo condicionado a geometría, con sus recetas de entrenamiento.
El entorno como programa, la vista como modelo generativo
Dos propiedades conducen todo el report: faithful y realistic.
Un entorno faithful mantiene estado persistente y ejecuta reglas consistentes: la caja que empujas sigue ahí, la rampa construida en la ronda 3 existe en la ronda 4, y nada de eso se negocia con un modelo generativo. Un entorno realistic muestra observaciones con la distribución visual del mundo real: píxeles, no listas de objetos. Simuladores escritos a mano siempre han sido faithful; los world models de vídeo (la línea Genie → Genie 3, Matrix-Game 2.0/3.0, GameNGen) son realistic pero derivan el estado de los propios píxeles, con el coste de consistencia que eso arrastra. AgentGarten reparte el trabajo: código para lo dinámico, modelo generativo para lo visual. El abstract lo define así:
“couple[s] simulators and game engines with a shared neural renderer to build real-time interactive environments. Its simulation backends maintain persistent world state and execute program-defined interaction rules, while the renderer generates visual observations from structured conditions exported through a common interface.”
El cambio de modelado: el mundo sigue siendo un programa —un agente de código puede escribirlo, versionarlo y saber qué reglas tiene— y la dificultad se la come un modelo generativo que solo responde una pregunta visual: “dado el estado del motor y la cámara, ¿cómo se ve esto?”. Y hay una consecuencia directa, de las que se agradecen cuando has depurado agentes en entornos de texto: el agente ya no puede leer el estado del mundo. Ve lo que un modelo generativo produce, y puede creerle o no. Voyager exploraba Minecraft a través de una interfaz de texto al estado del juego — sus trayectorias eran legibles por definición. Aquí las observaciones son vídeo: las trayectorias no se leen, se ven.
Los números, verificados contra el paper
Todo lo de esta tabla está verbatim en el HTML v1 del report (arXiv 2610.12374, v1 del 08-oct-2026; consultado el 09-oct-2026):
| Qué | Número verbatim del paper | Dónde |
|---|---|---|
| Flota de entrenamiento | ”All stages run on 32 NVIDIA H100 GPUs with fully sharded data parallelism, one clip per GPU, and two gradient-accumulation steps, for 64 clips per optimizer update” | §4, antes de la Tabla 5 |
| Infra del renderer | Cosmos 3-Nano como base (36 capas transformer, width 4096, 32 query heads, 8 KV heads); torre de entendimiento (UND) congelada; autoencoder de vídeo Wan congelado; TAEHV como decoder rápido opcional | Apéndice A.1 |
| Replay exacto | ”Full-sequence FlexAttention replay differs from the cached rollout by 3.99% relative L2 error; block-by-block SDPA replay is bitwise identical” (y −5,4% de tiempo forward, +0,2% de memoria pico) | §3.4.2 / Tabla 1 |
| Streaming | Cache acotada: “five sink and 44 recent latent frames… each four-frame block attends to 49 frames of history”; un bloque de 16 frames: 438,8 ms de pared (414,4 ms de transformer) → 36,5 frames/s | §3.5 / Tabla 2 |
| Throughput | 480×832 a “over 35 frames per second on one NVIDIA H100”, incluyendo condicionamiento, 4 pasos de denoising, decode y host transfer | §3.5 |
| Milestones | ”shelters appeared by round 4 and ramp crossings by round 10” | Abstract y §5.2 (Tabla 3) |
| Alcance | hide-and-seek + “four further worlds” — 5 mundos mejoran con el mismo procedimiento | §5 / §5.4 |
Sobre el streaming, la lectura de ingeniero: 49 frames de historia, no 49 recientes — cinco sink frames anclan el contexto largo. Y el dato a subrayar no son los FPS sino el “bitwise identical” del replay: la cifra de FlexAttention (3,99% de error) existe para decir que si tomas la vía aproximada, el error es pequeño pero no es cero. Son números que solo aparecen cuando alguien probó la vía rápida, vio drift entre lo cacheado y lo recalculado, y lo midió.
El renderizador: Adversarial Forcing y replay exacto
La parte con más transferencia técnica del report resuelve un problema que solo existe cuando entrenas un modelo generativo dentro de un bucle: los gradientes tienen que fluir a través de la historia que el propio modelo generó.
El detalle: un renderer autoregresivo genera bloque a bloque (4 latent frames por bloque) con una KV cache acotada. En el Self Forcing estándar, los bloques completados se codifican en una KV cache detached: las pérdidas de los bloques posteriores supervisan la predicción a partir de esa cache, pero no el cálculo de prefill de la historia que produjo sus keys y values (§3.4.2). Si la historia que generó el estudiante difiere de la de su profesor, el gradiente no llega a quien la codificó.
La solución del paper (§3.4) es Adversarial Forcing: el replay de cada rollout es exacto — re-ejecutar la historia del estudiante reproduce sus latentes bit a bit (SDPA bloque a bloque, “bitwise identical”) — de modo que las pérdidas de bloques tardíos propagan gradiente hasta la codificación de la historia del propio estudiante. Sin doble backward a través de kernels fused de attention: el esquema R1/R2 exacto va sobre un discriminador con datos reales y backbone congelado. La Tabla 1 lo cuantifica: el replay FlexAttention de secuencia completa se desvía un 3,99% en L2 relativo del rollout cacheado; el SDPA bloque a bloque es idéntico bit a bit, un 5,4% más rápido en forward y solo un 0,2% más de memoria pico.
Por qué importa más allá de este paper: cualquier world model interactivo entrenado on-policy se enfrenta a lo mismo — el modelo aprende de sus propias salidas, así que los gradientes que no atraviesan la historia propia optimizan al profesor, no al agente. La idea “hacer el replay exacto para que el gradiente llegue a la historia” es la parte replicable aunque no entrenes vídeo: el patrón sirve para cualquier modelo generativo que consuma su propia salida como contexto.
El bucle de práctica: rondas y playbooks
Sobre ese mundo operan agentes preentrenados que solo ven píxeles. El procedimiento (§5.3): jugar la ronda, revisarla, y escribir playbooks que la siguiente tanda de agentes hereda. El paper los define como:
“library of short skill files, Markdown notes that may contain code, with one lesson per file”
Notas Markdown con una lección por fichero, heredadas entre rondas de agentes frescos: experiencia destilada en texto, no pesos. Si te suena, es la misma familia que las skills verificadas minadas de GitHub o los bucles de auto-mejora con destilación de experiencia, con un matiz que aquí aprieta: el agente escribe la lección a partir de píxeles que él mismo no puede verificar contra el estado real — el motor lo sabe, el agente no. Que la lección heredada sea cierta depende de que el renderer no le haya mentido en la ronda anterior.
Los resultados, en la Tabla 3 del paper: los escondites construyen refugios con paneles en la ronda 4; los buscadores usan rampas para cruzar muros en la ronda 10. El mismo hide-and-seek de OpenAI (2019) reportó construcción de refugios tras ~25 millones de episodios de self-play, y uso de rampas tras otros ~75 millones (≈100 millones en total). Y el propio paper hace la advertencia antes de que la hagamos tú (§5.2):
“Crucially, these numbers reflect two fundamentally different learning paradigms rather than a direct sample-efficiency ratio.”
Dos paradigmas: agentes de 2019 tabula rasa, con estado privilegiado y millones de episodios para descubrir la física desde cero; agentes de 2026 preentrenados, con el conocimiento físico ya en los pesos y solo aprendiendo a ejecutarlo en un cuerpo que ve por cámara. Lo que el experimento demuestra es que el conocimiento preentrenado se acopla a la ejecución física en pocas rondas — no que el renderer multiplique por millones la eficiencia muestral. “4 rondas frente a millones” es titular del abstract; el §5.2 es la letra pequeña, y honradamente está en el propio paper.
El coste: 32 H100 por run, sin duración publicada
La cifra de flota es la más incómoda del report: 32 H100 para cada etapa de entrenamiento (§4). Lo que el paper no publica es cuánto tiempo corrió cada etapa, así que el coste por run no es calculable — solo estimable. La cuenta es lineal y la puedes ajustar cuando aparezca la duración:
| Escenario (consulta 09-oct-2026, rangos de mercado publicados) | $/GPU-hora | Coste por hora ×32 | Coste por día ×32 |
|---|---|---|---|
| Cloud especializado, on-demand | ~1,5-4 $ | 48-128 $ | ~1.150-3.070 $ |
| Spot (referencia CoreWeave HGX) | ~2,46 $ | ~79 $ | ~1.890 $ |
| Hyperscaler on-demand | ~7-12 $ | 224-384 $ | ~5.380-9.220 $ |
Estimación mía, no del vendor: para semanas de entrenamiento, un run completo en el rango típico de cloud especializado se mueve en decenas de miles de dólares (p. ej. ~8.100-21.500 $/semana en el primer rango), y en hyperscaler on-demand puede pasar de 35.000 $/semana. Sin la duración real, cualquier cifra exacta sería ficción — la única cifra honesta es el orden de magnitud, y ese sí queda claro: el renderer realista es la parte cara de este diseño, y por eso es también lo único que han liberado con recetas y checkpoints: es lo que cuesta reproducir.
Para contrastar, la vía clásica (texto) de ejecutar agentes en entornos enjaulados no necesita renderizar nada: el coste de entorno se queda en CPU y las observaciones son tokens. Aquí el mundo se ve bien — y cada frame de esa apariencia lo paga un modelo de difusión corriendo en una H100. Fidelidad visual y coste de observación van de la mano; es un trade-off de diseño, no un detalle de implementación.
Qué puedes tocar hoy
Verificado contra el repo a 09-oct-2026 (creado el 08-oct, último push 09-oct 06:40 UTC; 97 ficheros, Apache-2.0, 104 estrellas):
| Pieza | Estado |
|---|---|
| Entrenamiento del renderer (bidireccional, autoregresivo, Adversarial Forcing) | Liberado — paquete wm/ (89 ficheros) |
Inferencia streaming con KV cache acotada y kernels de serving (Triton, CUDA graphs, sin torch.compile) | Liberado |
| Checkpoints del renderer | Hugging Face |
| Motor de renderizado en tiempo real (servidor streaming + frontend interactivo) | No liberado (pendiente en el README) |
| Mundos de código y bucle de práctica del agente | No liberado (pendiente en el README) |
Ojo con la letra pequeña de la licencia del checkpoint: el repo está en Apache-2.0, pero el modelo de HF hereda la licencia de Cosmos 3-Nano (license:other en la API de HF), no el Apache del repo. Léela antes de montar nada en producción.
Cuándo importa y cuándo no
Importa si construyes o evalúas agentes que necesitan percepción visual: la separación mundo/vista da un entorno evaluable con estado objetivo (el motor lo sabe) y observaciones realistas (el agente solo ve píxeles) — exactamente lo que falta para medir si un agente VLA alucina lo que ve. Importa también como indicación de dirección: los entornos de práctica de agentes se generan como código, no se escriben a mano, y el coste de generar mundos cae al coste de un coding agent.
No importa todavía si buscas el bucle completo de auto-mejora en producción: el motor interactivo y el bucle de práctica no están liberados, y los “4 rondas frente a millones” no son un ratio de eficiencia muestral sino la demostración de que el conocimiento preentrenado se acopla rápido a la ejecución física. Y no importa si tu agente trabaja en texto: para ese caso, un simulador de toda la vida sigue siendo faithful a coste cero de GPU.
Preguntas abiertas
- ¿Co-cheating con el curriculum generado? Si un coding agent escribe el mundo de práctica y otro agente lo resuelve, el generador puede crear entornos imposibles o triviales — y el que practica no puede distinguir un mundo roto de uno difícil, porque solo ve píxeles. El paper no aborda quién audita los mundos generados.
- ¿Consistencia geométrica a horizontes largos? El streaming mantiene 49 frames de historia con sink frames, pero ¿qué pasa en la ronda 20 de una partida, o en un mundo practicado durante días? El report mide rollouts de 769 frames; el bucle de práctica promete sesiones mucho más largas.
- ¿Coste de observación sostenible? Cada frame observado pasa por un modelo de difusión en H100. Para un agente que “vive” en el mundo a 35 fps, solo mirar cuesta una GPU por agente. El report no discute el coste de serving del bucle completo.
Fuentes: AgentGarten: Code Worlds for Evolving Agents (arXiv 2610.12374, v1 08-oct-2026; citas del HTML v1) · Repo MirroS-Lab/AgentGarten (Apache-2.0; commit 09-oct-2026) · Checkpoints MirroS-Lab/AgentGarten-renderer · Página del paper en HF (130 upvotes a 09-oct-2026) · Project page · Blog de MirroS. Rangos de precio H100: comparativas de mercado de CoreWeave, Lambda, RunPod, Vast.ai y hyperscalers (consulta 09-oct-2026; estimación propia, no afiliada). Piezas relacionadas: wrop-permanencia-objetos-world-models, code2skill-skills-minadas-github, rsi-agentes-auto-mejora-recursiva, openshell-sandbox-agentes-nvidia.