780MでMiniMax Music 3を動かす：ComfyUIでローカル音楽生成
背景
MiniMaxは2026年8月13日にMiniMax Music 3をオープンウェイトのモデルとして公開しました。階層型の自己回帰音楽生成モデルで、長距離構造は80億パラメータのグローバルLLMが担い、フレーム単位の音響detailは6億パラメータのローカルLLMが受け持ちます。合成そのものはFlow MatchingとFlow-VAEの組み合わせで行われます。テキストのキャプションと歌詞から、最長およそ300秒、32kHz・16bit・ステレオの楽曲を丸ごと生成します。ComfyUIは同じ週のうちにネイティブ対応を追加していて、カスタムノードのパッケージなしのコアノードとして、v0.33.0から入っています。こちらの780Mはまだ0.32.0のままでした。
インストール
ComfyUIの更新は、既存のComfyUI-TheRockのチェックアウトに対してgit pullするだけです。requirements.txtの差分は小さく、ピン留めされたパッケージが3つ(comfyui-frontend-package、comfyui-workflow-templates、comfy-kitchen)更新されているのと、バージョン指定のないtorchの行が1つ増えていました。ピン留めされている分だけを明示的にインストールしました。
pip install "comfyui-frontend-package==1.49.6" \
"comfyui-workflow-templates==0.11.43" \
"comfyui-embedded-docs==0.5.10" "comfy-kitchen==0.2.31"pip install -r requirements.txtは意図的に避けました。あのファイルの中のバージョン指定なしのtorchの行は、間違ったインタプリタに対して実行すると、既存のROCmビルドの上に素のCPU/CUDAホイールを平気で解決してしまいます。ピンポイントのインストール後、torch.version.hipが変わっていないこと(2.12.0+rocm7.15.0a20260728)を確認しました。
モデルはHugging FaceのComfy-Org/MiniMax-Music-3から、いつものComfyUIのモデルフォルダに配置します。
| ファイル | サイズ | フォルダ |
|---|---|---|
minimax_music3_dit_int8_convrot.safetensors | 2.50 GB | diffusion_models/ |
minimax_music3_text_encoder_pruned_int8_convrot.safetensors | 9.20 GB | text_encoders/ |
minimax_music3_dav.safetensors | 0.22 GB | vae/ |
FP16(4.9GBのdiffusionモデル)や16〜18GBのテキストエンコーダーのバリエーションではなく、INT8(convrot量子化)を選びました。780Mが持つ共有VRAMは合計およそ14.8GBで、大きい方のファイルを載せる余地がなかったからです。このROCmビルドが使っているeagerコンパイルバックエンド(アクセラレートされたhip kitchenバックエンドはこの環境向けにビルドされていません)は、convrotのint8量子化・逆量子化の演算に対応していることを確認済みで、低VRAMの経路がここでも成立します。
ノードグラフはノード一覧に出てこない
ComfyUIのUI上に見える「MiniMax Music 3」のブロックは、フロントエンドだけの折りたたまれたサブグラフで、実行可能なノードの型ではありません。/promptのAPIリクエストを手で組み立てるには、その裏にある本物のグラフを見つける必要があります。これはcomfyui-workflow-templates-jsonパッケージの中(templates/audio_minimax_music_3.json、definitions.subgraphs以下)にバンドルされています。
UNETLoader → MiniMaxMusic3TextEncode → ConditioningZeroOut (negative)
↓ (also outputs a FLOAT "seconds")
CLIPLoader (type="minimax") ↗ EmptyMiniMaxMusic3LatentAudio
VAELoader ────────────────────────────────────↓
KSampler → VAEDecodeAudioTiled → SaveAudioAdvancedこれを手で配線する前に知っておく価値のある点が2つあります。
- 本物のネガティブプロンプトは存在しません。「negative」の入力は、同じpositiveのconditioningから
ConditioningZeroOutを通してゼロ埋めした埋め込みで、テキストの入力欄ではありません。パーカッションを除外したいといった、望まない要素を避けたいときは、positive側のキャプションに明示的な除外表現として書く必要があります。 SaveAudioAdvancedのformatは動的なコンボです。{"format": "mp3", "quality": "V0"}を送るとバリデーションでRequired input is missing: quality (input_name: "format.quality")というエラーになります。実際のキーは、入れ子のオブジェクトではなく、フラットなJSONの中の"format.quality"というリテラルな文字列そのものです。
生成時間はどこにかかっているか
MiniMaxMusic3TextEncodeは単純なエンコード処理ではありません。KSamplerのdiffusionパスが始まる前に、ARモデルの自己回帰サンプリングを丸ごと内部で実行していて、AR sampling: N/Mという進捗バーとしてそれが見えます。ARのステップ数はmax_durationに比例して増え、目安として目標秒数1秒あたりおよそ25ステップ、このGPUでは1.4〜1.7 it/s前後で安定して進みます。
| max_duration | ARステップ数 | ARフェーズ | KSampler(30ステップ) | 合計 |
|---|---|---|---|---|
| 20秒 | 501 | 約5分 | 約5秒/ステップ、約2.5分 | 約8.5分 |
| 60秒 | 1501 | 約16分 | 約14秒/ステップ、約7分 | 約24分 |
| 90秒 | 2251 | 約23分 | 約24秒/ステップ、約12分 | 約35〜40分 |
| 120秒 | 3001 | 約30分 | 約25〜35秒/ステップ、約15分 | 約45〜55分 |
KSamplerのnum_inference_stepsは、長さにかかわらず30で固定です。オーディオのlatentが長くなる分、1ステップあたりのコストが上がる形で効いてきます。素のVAEDecodeAudioノードの代わりにVAEDecodeAudioTiled(tile_size=1536、overlap=64)を使うと、長い尺でもデコードのVRAMを扱いやすい範囲に保てました。ドキュメントにも、低VRAMのGPUではこちらが推奨経路だと書かれています。
GPUのコンテキストにまつわる実話の教訓
120秒の生成中、KSamplerのあるステップで、次のエラーとともに処理が止まりました。
CUDA error: HIPBLAS_STATUS_INTERNAL_ERROR when calling
`rocBLASStatusToHIPStatus(rocblas_gemm_ex(...))`同じプロンプトを投げ直すと0.08秒で完了し、そのあと同じノードで別のエラー(invalid configuration argument)にぶつかりました。ComfyUIのインメモリのノード出力キャッシュは機能していて、約23分かかるARフェーズはまるごとスキップされ、キャッシュからそのまま再利用されていました。そして、ROCm/HIPがこの種の内部エラーを一度投げると、そのプロセスのデバイスコンテキストは以降ずっと汚染されたままになり、その後のGPU側の処理は中身を問わずほぼ即座に失敗するようになります。これを解消できたのはComfyUIのプロセスを丸ごと再起動したときだけで、それは同時に、あの同じインメモリキャッシュを失うということでもあります。クリーンなプロセスから投げ直すと、次の試行では成功しました。何がこれを引き起こすのかについて、「長いセッションの後半で、より重い生成のときに起きやすい」以上のパターンは見つかっていません。ここでは、再現可能なバグとしてではなく、実際に起きた、いまのところ原因不明の間欠的な不具合として記録しておきます。
参照音源・メロディ条件付け: ここでは使えない
MiniMaxのホスティングAPIは、音源を参照にした「カバー」生成に対応しています。楽曲を渡すと、ASRで抽出した歌詞つきで作り直したバージョンが返ってきます。登録済みのComfyUIノードとモデルのソース(comfy/ldm/minimax_music/、comfy_extras/nodes_minimax_music.py)の両方を確認しましたが、こちら側でオーディオの入力を公開しているものは見つかりませんでした。この機能はMiniMaxの有料ホスティングAPI側だけにあり、オープンウェイトのチェックポイントにもComfyUIの現行のノード構成にも入っていません。ローカルではテキストのキャプションと歌詞だけが選択肢になります。
結果
780M上での生成は、INT8のdiffusionモデル、INT8で枝刈りされたテキストエンコーダー、VAEDecodeAudioTiledの組み合わせで問題なく通っていて、--reserve-vram 6 --cpu-vaeも既存の起動設定のままです。構造化されたキャプション(Global Metadata、Vocal Details、Arrangementの各セクション)は、スタッカートやスピッカートの弦を明示的に除外するといった細かい奏法の指定まで含めて、スタイルや楽器選びを何度生成してもぶれずに制御できました。生成時間が実質的なトレードオフです。120秒の楽曲は、このハードウェアではさっと終わるようなものではなく、ウォールクロックでおよそ45〜55分に近い時間がかかり、しかもそのコストは、聴いて判断できる音がまだ何もない段階のARフェーズに前倒しでのしかかってきます。