DanceGAI 是 ManiaGAI 背後的團隊，ManiaGAI 是一個 AI osu! mania beatmap 生成器。DanceGAI 正在打造把音樂變成可玩體驗的 AI 基礎設施，而 ManiaGAI 是它的第一個產品：你上傳一首歌，它就會生成一組完整、可以玩的 osu! mania mapset——timing、音符和一整組難度——打包成標準的 .osz。歌曲可以是上傳的音訊檔，也可以是你連結的 osu! beatmapset 的歌曲；不論哪一種，都只會使用音訊，絕不會使用原有的譜面。系統的第 2 版已在本站上線。osu! mania 是第一個輸出格式：這套系統是為廣義的下落式節奏遊戲（VSRG）而打造的。
這一頁說明它如何運作，以及為什麼要這樣設計。我們公開架構和工程上的決策；但不公開別人重建這套系統所需的細節。尚未公開的數字，這一頁會直接說明，而不是用猜的。
技術摘要
| 任務 | 音訊 → 可以玩的 osu! mania mapset（.osz），每次執行產出一整組難度 |
|---|---|
| 範圍 | 下落式節奏遊戲（VSRG）——先從 osu! mania 開始；其他 VSRG 格式規劃中 |
| Timing | Beat This 激活值 → 自有的格線擬合方法（支援變速）。在我們的基準測試中，2,501 首固定速度的 Ranked 歌曲裡，有 97.1% 的 timing 與 mapper 的誤差在 40 ms 以內 |
| 音樂表示 | MERT-v1-95M，逐拍對齊到 timing 格線 |
| 規劃器 | 針對逐段玩法狀態的高斯擴散模型，約 6M 參數 |
| 音符模型 | MaskGIT 式的非自迴歸 transformer，處理配置 token，約 51M 參數 |
| 控制項 | 4K–9K · ★1–10 目標 · 5 個風格維度（LN 比例、LN 反轉、jack、Mini LN、delay） |
| 訓練資料 | 150,622 張人類製作的譜面 · 86,255 首歌曲 · 約 14,500 位 mapper · 4,227 小時的音訊 |
| 驗證 | timing 格線檢查、無效音符清理、靜音防護、osu! 星數實測、mapset 一致性 |
| 訓練 | 一張 RTX 4070 Ti SUPER · 正式模型的整個演進過程共記錄約 580 GPU 小時 |
| 生成 | 所要求的難度在同一次批次 GPU 運算中一起生成 · 一整組 mapset 約 20 秒的 GPU 運算 |
| 服務部署 | 從記憶體快照還原的 serverless GPU worker；音訊在瀏覽器中正規化 |
beatmap 不是採譜
說到自動生成 beatmap，最直覺的想法是「音訊進去、經過神經網路、音符出來」。實際上，這種想法做出來的譜面雖然技術上有跟著音樂走，打起來卻很不舒服。一張好的 osu! mania 圖更接近編曲而不是採譜：mapper 要決定哪些聲音值得放音符、一個段落應該有多密、jack 或長條要放在哪裡、配置如何在雙手之間流動，以及這一切在 Easy 和 Expert 難度之間要如何變化。
因此，ManiaGAI 把 beatmap 生成拆成一連串不同的問題——理解音樂、規劃玩法、放置音符，以及檢查結果：
- 音樂
- 理解
- 規劃
- 生成
- 修整
- Beatmap
1. 音樂理解
後面的每一步，都取決於對歌曲的精確掌握。第一階段會把原始音訊轉換成兩樣東西：一條 timing 格線，以及歌曲每個時刻的高解析度音樂表示。
Timing。拍點與強拍的激活值來自 Beat This，一個開源的節拍追蹤模型。把這些激活值轉換成 osu! 的 timing 格線——BPM 和 offset，包括會變速的歌曲——則是我們自有的格線擬合方法，它產出的格線和生成模型訓練時所用的屬於同一類。Timing 是玩家最先注意到的部分：一張譜面只要偏離拍點幾毫秒，配置再好也沒辦法玩，所以我們把它當成首要問題來處理，而不是一個前處理步驟。
音樂特徵。音訊會用 MERT-v1-95M（一個自監督的音樂表示模型）編碼，並對齊到 timing 格線——讓模型能逐拍「看見」音樂：起音、音色質地、強度，以及它們在整首歌中的變化。靜音的段落會另外偵測，確保不會在上面放音符。
2. beatmap 規劃
ManiaGAI 的核心設計選擇，是把「應該發生什麼」和「音符怎麼放」分開。
一個專門的規劃模型會讀取音樂表示，在任何音符出現之前，先決定整首歌的玩法結構：每個段落應該多密、哪些類型的配置該放在哪裡、難度該如何起伏，以及這一切如何配合所要求的難度和風格。它的輸出是一份逐段描述譜面的規劃——局部難度，以及長條、jack 和其他配置類型的比例——而不是音符。
規劃器是一個高斯擴散模型（約 6M 參數）。它會以音樂、鍵數，以及目標難度和風格為條件，一次性地為整首歌的每個段落生成規劃。擴散模型很適合這項工作：規劃是對一首歌平滑、連續的描述，把它當作整體來生成，能讓規劃器同時兼顧整首歌的平衡。
在這個層級做規劃，讓系統擁有逐音符模型所缺少的東西：對整首歌的全局視野。副歌可以被規劃得比前面的主歌更重；間奏可以被規劃得讓人喘口氣。
3. 音符生成
第二個模型會把規劃轉換成實際的音符配置——放在哪些軌道、哪些是單點、哪些是長條、配置之間如何銜接。規劃決定結構；音符生成則把這個結構變成可以玩的音符，同時遵循規劃和音訊。
音符模型是一個 MaskGIT 式的非自迴歸 transformer（約 51M 參數）。譜面以離散的配置 token 表示，模型不是從頭到尾一個一個寫出來，而是先填滿整張譜面，再經過好幾輪修整——確定有把握的音符，並重新檢視其餘的部分。每一輪都能看到每個段落前後兩側的脈絡，這正是讓整首歌的配置保持一致的關鍵。這些修整輪次如何在整首歌中安排，是我們自有的修整方法。
ManiaGAI 為什麼採用 Planner + Noter（英文）→
4. 可控的生成
ManiaGAI 不是「生成完再祈禱」的系統。同一首歌可以在明確的控制條件下生成，而這些控制項正是模型在訓練時就學會遵循的：
- 鍵數——4K 到 9K。
- 難度——從 ★1 到 ★10 任意選擇星數。一首歌在一次執行中就能產出一整組 mapset，從 Easy 到 Expert。
- 風格——玩法特性，例如長條的比例，以及譜面中 jack、反轉 LN、短 LN 和 delay 配置的多寡，每一項都能在生成器上調整。
- 密度——由目標難度和規劃決定，而不是套用固定的規則。
每個難度都是從對歌曲的同一份理解生成的，所以一組 mapset 讀起來是同一家族的譜面，而不是毫不相干的幾張。接下來，我們正朝著「學習出來的風格表示」努力——用範例來描述作譜風格，而不是只靠幾個滑桿。
5. 驗證與品質控管
在譜面送到你手上之前，系統會先檢查它：
- Timing——寫入的 timing 點會和偵測到的格線比對。
- 無效和無法遊玩的音符——重疊的音符、損壞的長條，以及遊戲無法呈現的配置都會被處理掉，明顯靜音的音訊上也不會放音符。
- 實測難度——每張譜面的星數都會用與 osu! 相同的星數演算法實測，難度名稱依實測值命名，而不是依要求的數值。
- 整組 mapset 的一致性——如果一張譜面比原本應該在它下面的那張還簡單，或和相鄰難度幾乎一樣，就會被捨棄，而不是照樣交出去。在生成器上，你會看到哪些星數被捨棄以及原因。
- 輸出的有效性——結果會打包成標準的 .osz，包含音訊、背景和 hitsound，可以直接匯入 osu!。
數字一覽
- 訓練集中的歌曲
- 86,255
- 訓練譜面
- 150,622
- Mapper
- 約 14,500
- 不重複音訊
- 4,227 小時
- 磁碟上的訓練特徵
- 約 0.7 TB
- 訓練運算量（已記錄，正式模型演進過程）
- 約 580 GPU 小時
- 音符模型最終訓練
- 約 4 天
- 模型參數
- 約 57M（音符 51M + 規劃器 6M）
- 整組 mapset 生成
- 約 20 秒
- 鍵數模式
- 4K–9K
- 難度範圍
- ★1–★10
- 每次執行的難度數
- 最多 10 個（長歌曲較少）
訓練資料
正式模型的學習來源是 150,622 張人類製作的 osu! mania 譜面，橫跨 86,255 首歌曲——4,227 小時的不重複音訊——由大約 14,500 位 mapper 製作。這類系統大部分的工作不在模型，而在資料：決定什麼樣的譜面值得學習、確保每個訓練樣本的 timing 都正確，以及用能抓住「好玩」關鍵的形式來表示譜面。
評估：timing 準確度
我們把自己的 timing 和人類的 timing 做了基準比較，對象是所有我們能評估的、單一固定速度的 Ranked osu! mania mapset——2,501 首歌曲——同時比較開源工具 Mapperatorinator 的 timing 模式，以及我們前一代的偵測器 ManiaGAI v1。當 BPM 與 mapper 的一致（允許半速／倍速），且拍點相位誤差在指定容許範圍內時，該首歌才算正確。
| 方法 | ≤10 ms | ≤20 ms | ≤40 ms | BPM 正確 | 單一 timing 線 |
|---|---|---|---|---|---|
| ManiaGAI v2 | 71.4% | 92.3% | 97.1% | 98.0% | 100% |
| Mapperatorinator | 78.0% | 90.9% | 91.7% | 92.6% | 11.0% |
| ManiaGAI v1 | 74.8% | 88.0% | 90.7% | 94.0% | 92.8% |
僅限固定速度的 Ranked 歌曲；「單一 timing 線」= 這首歌和 mapper 一樣只用一條 timing 線（在固定速度的歌曲上多出一條線，就是錯誤的變速）。測量所用的設定接近、但不完全等同於實際上線的版本。
訓練
規劃器和音符模型是分開訓練的，各自使用它所處理的表示方式——規劃器是以高斯擴散模型，針對每個段落玩法經高斯化後的描述進行訓練；音符模型則是以遮罩 token 預測的方式，針對配置 token 進行訓練。訓練樣本會在各鍵數和難度等級之間取得平衡，讓 8K 和 ★10 的譜面不會被 4K 和 ★4 淹沒；音符模型則以混合精度訓練。
每一項變更都是以生成出來的譜面本身來評斷——timing 準確度、實測難度與目標的差距、可玩性——而不只看訓練損失。
推論與效能
一個實用的 AI 系統不只要看模型品質，也必須快到能夠使用。一次 ManiaGAI 請求的執行流程如下：
- 在你的瀏覽器中：你一選好檔案，歌曲就會被解碼、做響度正規化並重新編碼，而你這時還在選擇設定——所以 GPU 從不需要等待音訊處理。
- 音樂理解在 GPU 上進行：Beat This 和 MERT，同時格線擬合在 CPU 上與 MERT 並行執行。
- 規劃與音符生成：所有要求的難度在同一次批次運算中完成。
- 驗證——星數實測、一致性檢查。
- .osz 打包，然後下載。
GPU worker 從預先載入的快照啟動，所以即使是冷啟動的 worker，也能在幾秒內就緒，而不必把時間花在載入模型上。以一般歌曲來說，一整組 mapset 大約需要 20 秒的 GPU 運算時間——不含上傳、排隊和下載；一首實測長度 2:50、五個難度的歌曲，在 NVIDIA T4 上花了 12.7 秒——timing 與音樂特徵 3.8 秒（並行執行）、規劃 1.0 秒、五個難度的音符生成 6.1 秒。
我們不公開的部分
我們公開架構原則、背後的工程決策，以及系統能做和不能做的事——包括我們所建立在其上的開放模型（Beat This、MERT），以及我們自己模型所屬的模型家族（高斯擴散、MaskGIT）。我們不公開自行開發的方法，也不公開能讓別人重現這套系統的細節：timing 格線如何擬合、速度區段如何合併，音符模型的修整輪次如何在整首歌中安排，模型如何設定條件，精確的架構、損失函數和超參數，以及訓練資料如何取得、篩選和建構。這就是「對我們打造的東西保持透明」和「把配方交出去」之間的界線。當我們對品質做出主張時，我們打算用公開的基準測試來佐證——而不是用形容詞。
接下來
不只是 osu! mania。ManiaGAI 是圍繞著一種不限於 osu! mania 的玩法表示來設計的：分布在各軌道上的音符和長條，放在 timing 格線上，並以目標難度為條件。osu! mania 是第一個輸出格式，而不是這套系統的邊界。
深入閱讀
深入了解 ManiaGAI 背後的研究與工程：