體驗 Lyrics To Song：讓地端 AI 音樂工作流唱出人聲
從 MiniMax Music 3 的失敗到 ACE-Step 1.5 的成功，記錄如何讓 AI Agent 在一台沒有顯卡的雲端主機上，做出一首會唱歌的中文歌。
這是一首 AI 唱出來的中文歌，三分鐘，女聲主唱，國樂編制。它是我為自己正在開發的水墨風三國自走棋遊戲寫的主題曲，叫做《落子無悔》。
它不是在什麼高階設備上生成的。整首歌從頭到尾，跑在一台沒有顯卡的雲端主機上，花了一百分鐘。
上一篇留下的缺口
在 用 Stable Audio 3 建立我的地端 AI 音樂工作流 那篇，我記錄了怎麼讓 AI Agent 幫我把音樂生成模型裝到雲端主機上，包成服務，最後用一句自然語言就能做出一段音樂。
那套流程到現在還在用。但它有一個很明確的天花板：只能做器樂，做不出人聲。
當鬧鐘音樂、遊戲背景音、影片配樂，它都很稱職。可是只要我想要一首「有歌詞、有人唱」的歌，這條路就走不通了。而在付費服務那一端，Suno 一直是這個領域的領先者，能把一段文字直接變成一首完整的歌。
聽說有個開源的挑戰者
前陣子聽說 MiniMax 開源了他們的音樂模型 Music 3，評價是效果不輸 Suno。
這正好打到我上一篇的動機：如果只是想探索這項技術，或者希望把工具放在自己能控制的環境裡，那麼一個「可以自己部署、而且會唱歌」的模型，就非常值得試。
所以我決定，在同一台雲端主機上把它裝起來。
一樣只用自然語言，讓 Agent 自己去裝
跟上次一樣，我沒有自己動手，只是把需求說清楚。原始指令中的路徑已改成泛稱：
我下給 Agent 的指令
參考主機上的音樂工具目錄，目前有一個 Stable Audio 的實作。
我想用 MiniMax Music 3 也作一版，先評估可行性。
接下來的事情我幾乎沒有插手。Agent 自己去確認這台主機的條件、找到適合的推論工具、編譯、下載八 GB 多的模型檔案、處理一路上冒出來的相依問題。中間卡了好幾關，它自己讀原始碼找出原因，再自己繞過去。
我想強調的是：這些工具的名字，我全都是從 Agent 的回報裡第一次看到的。 我沒有去查過任何一個該怎麼裝。
跑起來之後：不只是慢
裝好之後就是實測。結果讓人有點措手不及。
生成 18 秒的音樂，花了 3 小時 39 分鐘。
記憶體也幾乎見底 —— 這台主機只有 12 GB，跑的時候用掉將近 8 GB，中間任何一個其他程式來搶，都可能讓整個工作前功盡棄。
Agent 幫我把數字往上推算：照這個速度，一首 3 分鐘的歌，要跑 34 個小時。
它確實會唱歌，我給的歌詞也唱得出來。但這已經不是「慢」的問題了。跑一整天只為了一首歌，中間電腦不能做別的事，任何一次意外重開機都要重來 —— 這種東西沒辦法放進任何實際的工作流裡。
為什麼跑不動
我原本以為原因很單純：模型太大了嘛。但 Agent 給我的解釋，是我沒想過的角度。
每個 AI 模型的「體質」不一樣。 有的很吃運算速度，有的很吃記憶體的搬運速度，有的兩個都吃。而一台電腦的強項和弱項，也各自不同。
我這台雲端主機沒有顯卡，靠的是一般的 CPU 和記憶體。Agent 實際量過之後告訴我：它的運算能力還算堪用，但搬資料的速度很慢。
而 MiniMax Music 3 剛好就是那種「每做出一點點聲音，就要把整個模型重新搬一遍」的類型。它把主機最弱的地方，變成了每一步都要走過的關卡。
Agent 給了我一個很好懂的比喻：這就像每寫一個字，都要把整本字典搬到桌上翻一次；而另一種模型是搬一次上來，可以連續查上百個字。 字典一樣厚，但一天下來寫出的字數天差地遠。
上一篇的 Stable Audio 3 剛好是後者，所以同一台主機上它跑得順。
所以結論不是「MiniMax Music 3 不好」。放到有顯卡的機器上，它其實很快。是它需要的東西，我這台主機給不起。
那還有什麼選擇？
搞清楚原因之後，問題就變得具體多了。我回頭問 Agent：
我下給 Agent 的指令
那還有什麼開源模型可以做出人聲演唱？
Agent 把能找到的選項整理了一輪，最後給出的結論是 ACE-Step 1.5。
理由用一句話就能說完：它的體質剛好比較符合這台主機的長處，不會一直卡在搬資料上。
這是整件事情對我最有意義的地方 —— 因為前面弄清楚了「為什麼跑不動」，所以這次不是再賭一次運氣，而是帶著判斷標準去挑。
裝起來，讓 Agent 依機器條件調整
我下給 Agent 的指令
來試 ACE-Step。
裝好之後依這台主機的 CPU 與記憶體條件調整參數，找出實際可行的設定。
這一段幾乎全是 Agent 自己在做，而且做得比我原本想像的細：
- 調整成「用到哪一段才載入哪一段」，避免記憶體一次被塞爆
- 從 30 秒開始生成，往上試 60 秒、2 分鐘、3 分鐘，一路量記憶體用量，找出這台主機真正的極限
- 中間也試過一些後來證明沒用的方向。量完發現沒有效果，就把改動退回去，不留在系統裡
最後定案：3 分鐘就是這台主機一次能生成的上限。 再長就會記憶體不足。
我很喜歡這個過程的一點是：這些設定我一個都不需要知道。 我只說了「依這台主機的條件調整」，剩下的判斷都由實測數據決定。
成果：《落子無悔》
參數確定之後，就是真正要做歌的時候了。
我下給 Agent 的指令
這次你幫我生成一首中文歌曲，女聲主唱，曲式磅礴。
是我正在開發的水墨風三國自走棋遊戲主題曲。
跟上一篇一樣，Agent 沒有直接開始生成，而是先把歌詞和編曲描述寫出來讓我確認。編曲的部分它給的是：二胡獨奏開場，逐步加入古箏、笛子，再堆上戰鼓、弦樂與銅管，副歌加合唱。
歌詞是這樣：
墨落宣紙 暈開千里江山 一筆風起 三分天下未完 青鋒未出鞘 已聽見金戈 誰在棋盤之外 靜靜地看
落子無悔 一念定山河 兵臨城下 我心自巋然 水墨深處 有萬馬千軍 筆鋒所至 皆是我河山
烽火燒盡 多少英雄姓名 留白之處 藏著最深的疼 月照長江 水東流不回頭 把來時的路 走成了傳說
天下大勢 分久必合 我落下這一子 就不再問對錯
墨未乾 局未終 江山如畫 等我來重逢
「落子無悔」既是下棋，也是決斷；「筆鋒所至 皆是我河山」把畫筆和兵權疊在同一個畫面上；「留白之處 藏著最深的疼」用水墨的技法去講戰爭的代價。這些是 Agent 寫的，我只做了微調。
因為一首要跑一百分鐘，我就順手交代了一件事：
我下給 Agent 的指令
生成之後，若一切正常，你看看到早上九點之前還夠時間生成幾首就再生成幾首，記得用不同的隨機種子。
於是它自己排了整晚的工作，還設了保護機制：時間不夠就不開新的，免得留下半成品；如果記憶體不足失敗了，就自動改用比較短的長度重試，確保我早上至少有東西可以聽。
早上起床，三個版本都在，全部完整三分鐘。文章開頭那首就是其中之一。
順手修好的舊帳
還有一個意外的收穫。
在診斷 MiniMax 為什麼慢的過程中，Agent 把整台主機的能力都量了一遍。量完之後它告訴我：上一篇建立的那個 Stable Audio 服務，其實設定沒有調好。
它換了一種比較省資源的計算方式，結果同樣的曲子快了三倍多，記憶體還少用一半。我拿新舊兩版做了比對，聽起來幾乎沒有差別。
這個改動已經直接套進上一篇建立的服務裡了。所以這次的探索，除了多出一條能唱歌的路，也順便讓原本那條路變快了三倍。
結語：從「會用」到「會判斷」
上一篇我學到的是流程：先找到模型，再包成服務，最後讓 Agent 能用自然語言指揮它。
這一篇學到的是判斷。
以前看到一個新模型，我會問的是「它效果好不好」。現在我知道還要問另一個問題：它需要的東西，我的機器給不給得起？ 這兩個問題是獨立的 —— 一個很厲害的模型，放在不對的機器上，可能連跑都跑不完；而一個看起來普通的模型，反而可能剛好合身。
而 Agent 在這件事裡真正的價值，也不是幫我把東西裝起來而已。裝東西只解決這一次。它幫我把「跑不動」變成了「為什麼跑不動」 —— 後面這個，我可以用在下一次。
最後誠實說：這台主機做得到 3 分鐘的歌，做不到 5 分鐘。要更長、更快，還是得換設備。
但至少現在，我知道該換什麼，也知道為什麼要換。 對我來說，這比多做出一首歌更有價值。
本文由 Claude Opus 5 high協作撰寫