Ingeniería

Cómo hicimos que la generación de beatmaps con IA fuera tan rápida que se siente interactiva

Un mapset completo de osu! mania en unos 20 segundos de GPU en lugar de un minuto o más: a dónde va el tiempo en una solicitud a ManiaGAI y las decisiones (del navegador a las dificultades por lotes) que lo recortaron.

Un generador al que esperas varios minutos es un trabajo por lotes. Envías una canción, te pones a hacer otra cosa y vuelves a ver lo que haya salido; y si no te gusta, probar otro estilo u otro conjunto de dificultades te cuesta otra espera. Un generador que responde en segundos es una herramienta: pruebas, escuchas, ajustas y vuelves a probar.

Por esa diferencia, en la versión 2 de ManiaGAI tratamos la latencia como una restricción de diseño en todo el sistema, y no como algo que optimizar al final. La versión 1 tardaba un minuto o más por mapset. La versión 2 tarda unos 20 segundos de GPU por un mapset completo en una canción típica: normalmente de 13 a 25 segundos, según la canción y las dificultades pedidas. Aquí está a dónde va ese tiempo, y las decisiones que eliminaron el resto.

Anatomía de una solicitud

  1. Tu navegador
  2. Timing ∥ características musicales
  3. Planner
  4. Noter
  5. Validación
  6. Descarga

Una ejecución de producción medida en el lanzamiento de la v2: una canción de 2:50, 5 dificultades, en una GPU NVIDIA T4: 12,7 segundos en total.

Tiempos por etapa de una generación de ManiaGAI v2
EtapaTiempo
Timing + características musicales (en paralelo)3,8 s
Planificación (todas las dificultades)1,0 s
Generación de notas (las 5 dificultades)6,1 s
Ejecución completa12,7 s

Tiempo de cómputo de GPU para una canción en el sistema de lanzamiento de la v2 (1 de octubre de 2026), sin contar la subida, la cola ni la descarga.

1. Hacer el trabajo de audio antes de que nadie pulse Crear

Cada canción subida tiene que decodificarse, normalizarse en volumen y recodificarse en un formato uniforme antes de que los modelos puedan usarla. En un servidor son unos segundos de trabajo que, si no, la GPU tendría que esperar. En ManiaGAI ocurre en tu navegador, en cuanto eliges el archivo, mientras todavía estás eligiendo el número de teclas y las dificultades. Para cuando pulsas Crear, el trabajo suele estar hecho. Si preparar la canción en un dispositivo lento tarda más de 20 segundos, el servidor se encarga en su lugar, así que esta optimización nunca retrasa a nadie.

2. Ejecutar el timing y la comprensión musical en paralelo

Hay dos cosas que se tienen que saber de la canción antes de empezar a planificar: su cuadrícula de timing (del modelo de código abierto Beat This más nuestro propio ajuste de la cuadrícula) y sus características musicales (del modelo musical MERT). No dependen la una de la otra, así que no se esperan: la GPU ejecuta Beat This y MERT mientras el ajuste de la cuadrícula se ejecuta en la CPU al mismo tiempo. En la ejecución de arriba, toda la etapa de comprensión tardó 3,8 segundos.

3. Generar todas las dificultades en una sola pasada

Un mapset de ManiaGAI tiene hasta diez dificultades. Generarlas una tras otra multiplicaría el tiempo por el número de dificultades. En cambio, todas las dificultades pedidas se planifican y se generan juntas, en una sola pasada por lotes en la GPU: comparten la misma canción y las mismas características musicales, y solo cambian los objetivos. Así es como la generación de notas de cinco dificultades cupo en 6,1 segundos en la ejecución de arriba.

4. Refinar el mapa completo en lugar de escribirlo nota por nota

El modelo de notas es no autorregresivo: produce el mapa completo en un número fijo de pasadas de refinamiento, en lugar de un token cada vez desde el principio de la canción hasta el final; así que el número de pasos del modelo es fijo, tenga el mapa las notas que tenga. (Por qué el modelo funciona así es otra historia: el artículo sobre Planner + Noter.)

5. Arrancar desde una instantánea, no desde cero

La generación se ejecuta en workers de GPU serverless, lo que significa que no siempre hay un worker en marcha cuando llega una solicitud. Cargar los modelos y calentarlo todo desde cero añadiría muchos segundos a esa primera solicitud. En su lugar, los workers se restauran desde una instantánea de memoria tomada cuando todo ya está cargado y calentado, así que un worker nuevo está listo en un segundo aproximadamente, en lugar de pasar ese tiempo cargando modelos.

6. No esperar en la línea de meta

Los últimos pasos solían añadir su propio retraso. Ahora el .osz descargable se arma en cuanto los mapas están listos, y un mapa terminado se guarda en Mis mapas en el instante en que acaba la generación, aunque hayas salido de la página. El progreso en el generador muestra la etapa real en la que está cada generación, así que una espera nunca es un misterio.

Aún más rápido, con mapas idénticos

El 8 de octubre de 2026 lanzamos una implementación más rápida del sistema de generación: ahora los mapas se generan unas dos veces más rápido, y los mapas son exactamente los mismos: misma entrada, misma salida. Para ese cambio nos pusimos una regla estricta: una aceleración que altera lo que escribe el modelo es un cambio de modelo, y tiene que juzgarse como tal. Solo se acortó la espera.

Lo que aporta la velocidad

La velocidad cambia cómo se usa ManiaGAI. Hace que probar un segundo estilo u otro conjunto de dificultades sea cuestión de segundos, hace natural el flujo de previsualizar y luego descargar, y hace posible mantener un plan gratuito. También es la razón por la que optimizamos la solicitud completa (del navegador a la descarga) y no solo el modelo: los jugadores sienten la espera, no el tiempo de GPU.

Para ver dónde encajan estas etapas en el sistema, consulta la página de Tecnología; para saber qué cambió y cuándo, el registro de cambios.