Comment nous avons rendu la génération de beatmaps par IA assez rapide pour être interactive

Un générateur qu’on attend pendant des minutes, c’est un traitement par lots. Vous envoyez une musique, vous allez faire autre chose, et vous revenez voir ce qu’il a produit — et si ça ne vous plaît pas, essayer un autre style ou une autre sélection de difficultés vous coûte une nouvelle attente. Un générateur qui répond en quelques secondes est un outil : vous essayez, écoutez, ajustez et recommencez.

C’est pour cette différence que, pour la version 2 de ManiaGAI, nous avons traité la latence comme une contrainte de conception dans tout le système, plutôt que comme quelque chose à optimiser à la fin. La version 1 prenait une minute ou plus pour un mapset. La version 2 demande environ 20 secondes de calcul GPU pour un mapset complet sur une musique typique — en général de 13 à 25 secondes, selon la musique et les difficultés demandées. Voici où passe ce temps, et les décisions qui ont éliminé le reste.

Anatomie d’une requête

1. Votre navigateur
2. Timing ∥ caractéristiques musicales
3. Planner
4. Noter
5. Validation
6. Téléchargement

Une exécution réelle mesurée en production au lancement de la v2 : une musique de 2:50, 5 difficultés, sur un GPU NVIDIA T4 — 12,7 secondes au total.

Temps de calcul GPU pour une musique sur le système de lancement de la v2 (1er octobre 2026), sans compter l’envoi, la file d’attente ni le téléchargement.

1. Traiter l’audio avant que quiconque appuie sur Créer

Chaque musique importée doit être décodée, normalisée en volume et réencodée dans un format unique avant que les modèles puissent l’utiliser. Sur un serveur, c’est quelques secondes de travail pendant lesquelles le GPU attendrait. Dans ManiaGAI, cela se passe dans votre navigateur, dès que vous choisissez le fichier — pendant que vous choisissez encore un nombre de touches et des difficultés. Au moment où vous appuyez sur Créer, le travail est généralement déjà fait. Si la préparation de la musique sur un appareil lent prend plus de 20 secondes, c’est le serveur qui prend le relais, pour que l’optimisation ne retarde jamais personne.

2. Lancer le timing et la compréhension musicale côte à côte

Deux choses doivent être connues sur la musique avant que la planification commence : sa grille de timing (issue du modèle open source Beat This et de notre propre ajustement de grille) et ses caractéristiques musicales (issues du modèle musical MERT). Elles ne dépendent pas l’une de l’autre, donc elles ne s’attendent pas : le GPU fait tourner Beat This et MERT pendant que l’ajustement de la grille tourne en même temps sur le CPU. Dans l’exécution ci-dessus, toute l’étape de compréhension a pris 3,8 secondes.

3. Générer toutes les difficultés en une passe

Un mapset ManiaGAI compte jusqu’à dix difficultés. Les générer l’une après l’autre multiplierait le temps par le nombre de difficultés. À la place, toutes les difficultés demandées sont planifiées et générées ensemble, en une seule passe GPU par lots — elles partagent la même musique et les mêmes caractéristiques musicales, seules les cibles diffèrent. C’est ainsi que la génération des notes de cinq difficultés tient en 6,1 secondes dans l’exécution ci-dessus.

4. Affiner le chart entier au lieu de l’écrire note par note

Le modèle de notes est non autorégressif : il produit le chart entier en un nombre fixe de passes de raffinement, au lieu d’un token à la fois du début à la fin de la musique — le nombre d’étapes du modèle est donc fixe, quel que soit le nombre de notes du chart final. (Pourquoi le modèle fonctionne ainsi est une histoire à part : l’article sur Planner + Noter.)

5. Partir d’un snapshot, pas de zéro

La génération tourne sur des workers GPU serverless, ce qui veut dire qu’un worker n’est pas toujours actif quand une requête arrive. Charger les modèles et tout préchauffer à partir de rien ajouterait de nombreuses secondes à cette première requête. À la place, les workers sont restaurés depuis un snapshot mémoire pris une fois que tout est chargé et préchauffé : un nouveau worker est prêt en environ une seconde au lieu de passer ce temps à charger les modèles.

6. Ne pas attendre sur la ligne d’arrivée

Les dernières étapes ajoutaient leur propre délai. Désormais, le .osz téléchargeable est assemblé dès que les charts sont prêts, et une map terminée est enregistrée dans Mes maps à l’instant où la génération se termine — même si vous avez quitté la page. La progression affichée dans le générateur indique l’étape réelle où en est chaque génération : l’attente n’est jamais un mystère.

Encore plus rapide, avec des charts identiques

Le 8 octobre 2026, nous avons déployé une implémentation plus rapide du système de génération : les maps se génèrent désormais environ deux fois plus vite, et les charts sont exactement les mêmes — même entrée, même sortie. Nous en avons fait une règle stricte pour ce changement : une accélération qui modifie ce qu’écrit le modèle est un changement de modèle, et doit être jugée comme tel. Seule l’attente a raccourci.

Ce qu’apporte la vitesse

La vitesse change la façon dont on utilise ManiaGAI. Elle fait d’un deuxième style ou d’une autre sélection de difficultés une affaire de secondes, rend naturel le parcours aperçu-puis-téléchargement, et permet de maintenir une offre gratuite. C’est aussi pour cela que nous optimisons la requête entière — du navigateur au téléchargement — plutôt que le modèle seul : les joueurs ressentent l’attente, pas le temps GPU.

Pour voir où se situent ces étapes dans le système, consultez la page Technologie ; pour savoir ce qui a changé et quand, le journal des modifications.