MiniMax Music 3をApple Siliconのローカル環境で動かした実測
今回やったこと / この記事について
MiniMax Music 3を、Apple SiliconのM5 Pro・64GB・MPS環境へ導入し、どの構成で起動できるかと、曲の長さに対して処理時間がどう増えるかを確認した。音楽生成は「動いた」という一言だけでは常用できるか判断できない。テキストエンコーダやDiTなどのメモリ構成、ComfyUI周辺のバージョン、サンプラー設定、生成時間を同時に記録する必要がある。
今回の検証では、テキストエンコーダが16GB、DiTが4.6GB、VAEが207MBだった。bf16構成を使ったため、INT8パッチは不要だった。公式テンプレートのテキストエンコーダを差し替え、euler / simple、30 step、CFG 1.7で起動した。
起動時に詰まった箇所
ComfyUI本体はv0.33.0が必要だった。古いcomfy-kitchen 0.2.26では int8_attention_is_available のAttributeErrorが発生したため、0.2.31へ更新した。モデル本体だけを合わせても、周辺のノード実装が古いと起動できない。音楽生成の導入では、モデルの説明に書かれた構成だけでなく、ワークフローが要求するComfyUIと拡張の組み合わせを確認する必要がある。
常用ポートとの衝突もあったため、検証は8189で行った。これは性能に関する設定ではないが、既存の生成環境を止めずに試すには重要だった。検証環境では、次のように変更点を固定してから結果を比較した。
| 項目 | 検証値 |
|---|---|
| 実行環境 | M5 Pro / 64GB / MPS |
| ComfyUI | v0.33.0 |
| comfy-kitchen | 0.2.31 |
| サンプラー | euler / simple |
| steps | 30 |
| CFG | 1.7 |
| 検証ポート | 8189 |
曲の長さと処理時間
10秒曲は10分24秒、87秒曲は1時間24分33秒だった。処理時間は、曲の実時間に対しておよそ60倍になった。短いサンプルだけで「ローカルでも実用的」と判断すると、長尺化したときの待ち時間を見落とす。処理時間を支配したのはARの3001 stepで、音の長さを伸ばすほど、生成前に想定した以上の待ち時間が発生する構成だった。
10秒曲 → 10分24秒
87秒曲 → 1時間24分33秒
支配的な工程 → AR 3001 step
この結果から、短い試聴用クリップと、完成版の長い曲を同じ運用枠で扱わない方がよいと判断できる。常用する場合は、生成時間を許容できる長さに抑え、長尺生成は予約処理に分けるなど、待ち時間を前提にした設計が必要になる。速度改善を断言できる測定は今回の素材にはないため、ここでは設定変更の効果を推測しない。
入力形式も実測対象にする
captionはGlobal Metadata、Vocal Details、Arrangementの3部構成だった。lyricsはタグで構造を指定する。つまり、生成速度だけを調整しても入力が曖昧なら結果を比較しにくい。曲ごとにcaptionの区切りとlyricsのタグを揃え、終了条件を明示して初めて、モデル・設定・処理時間を比較できる。
ローカルで動かす利点は、設定を細かく固定し、失敗した条件を手元で再実行できることにある。反対に、メモリ容量が足りることと、短時間で生成できることは別問題である。今回の実測では、起動に成功したことよりも、87秒の生成に1時間24分33秒かかったことの方が、運用判断に直接効く情報だった。
やってみてわかったこと
音楽生成の導入は、モデルを読み込めた時点では終わらない。ComfyUIと拡張のバージョンを合わせ、ポートを分離し、入力形式を固定し、曲の長さごとの処理時間を測る必要がある。特に長尺化は、短いテストの延長として扱わない方がよい。今回の構成は動作確認済みだが、常用には待ち時間を受け入れる運用設計が必要である。
更新履歴
- 2026-09-21: 初稿作成。
訂正履歴
現時点で訂正なし。