MiniMax Music 3をVRAM 16GBで動かす｜RTX 5080実測、ピークVRAMは必要量ではない

結論: 動くか、どれだけ待つか、日本語は歌えるか

測定条件と、手元の構成が16GB単体と異なる場合にどこまで当てはまらないかは「測定の前提と、測っていない軸」にまとめている。

MiniMax Music 3とは何か

MiniMax Music 3はオープンウェイトで公開されている音楽生成モデルで、ComfyUIから使う重みはComfy-Org/MiniMax-Music-3で配布されている（2026年8月時点）。ComfyUI側の対応はv0.33.1のリリースノートに記載があり、タグ付きリリースに含まれている（v0.33.1は2026年8月13日公開）。

公称の構成は、Qwen3-8Bから初期化した8BのGlobal LLM（公式ブログはQwen3.5-8Bと記載しており、モデルカードとGitHubのREADMEのQwen3-8Bとで公式内の表記が分かれる）と、ランダム初期化された0.6BのLocal LLM、2.4Bのflow-matchingモジュール、123MのFlow-VAEからなる。これは公式ブログの記載であり、本記事で内部構造を実測したわけではない。

出力仕様について、公式チュートリアルは「It outputs 32 kHz, 16-bit stereo audio.」と記載している。これは公称。一方、ComfyUIのMP3書き出しノードで保存されたファイルを読み込み、コンテナが報告する値を確認すると次のようになった。

項目	公称（公式チュートリアル）	出力ファイルの実測
サンプリングレート	32 kHz	44,100 Hz
チャンネル数	ステレオ	2（ステレオ）
ビット深度	16-bit	MP3のため確認できず

これはMP3として書き出されたファイルに対する確認で、モデル内部の生成レートを直接測った値ではない。ビット深度はMP3から読み取れないため、公称の16-bitに対応する実測値は手元に無い。この項目まで確かめたい場合は、MP3以外の形式で書き出したファイルを見ることになる。

ライセンスは無条件の自由利用ではない。MiniMax-Music3 COMMUNITY LICENSE 第3項は、このソフトウェアを使う商用の製品・サービスから得られる年間売上が、自社と関連会社の合算で2,000万米ドルを超える場合に、MiniMaxからの事前の書面による許諾を求めている。閾値がかかる対象は企業全体の年商ではなく、当該ソフトウェアを使う製品・サービスから生じる売上である。

これとは別の条件として、売上規模にかかわらず、このソフトウェアを使う商用の製品・サービスのユーザーインターフェース上に「MiniMax-Music3」を目立つ形で表示することが求められる（条文は prominently display）。生成物を商用利用した場合に掛かる条件ではなく、ソフトウェアを使う製品・サービスのUIに掛かる条項である。

商用かどうかに関わらず掛かる条件もある。ライセンスは、使用が適用法令に従うことに加えて Exhibit A の Acceptable Use Policy に従うことを求めている。この AUP には、公開の場に情報やコンテンツを生成・流通させる際に、それが機械生成であることを明確かつ目立つ形で開示せずに行うことを禁じる項目が含まれる。生成した曲を公開の場に出すなら、売上規模とは無関係にこの条件が掛かる。

さらに、第三者に生成させる製品・サービスやホスティングを提供する場合は、提供前と運用期間を通じて、ライセンス違反にあたるアクセス・利用・出力を防ぎ緩和するための、合理的で相応な技術的・組織的セーフガードを実装し、維持し、テストし、定期的に見直すことが求められる。

公式のVRAM記載はあるが、ComfyUI構成のものではない

MiniMax公式のモデルカードにはVRAMの記載がある。フル精度で24GB未満（”The full precision fits under 24GB of VRAM.”）、自動CPUオフロードを併用すると約22GB（”With automatic CPU offloading, generation takes in ~22 GB”）、さらに言語モデルを層ごとにストリーミングすれば8GBのビデオカードにも収まる（”additionally streaming the language model layer by layer makes it fit even 8 GB video cards”）という内容である。

ただし、これはモデルカードがdiffusersでの実行について示している値であって、ComfyUI構成に対する要件ではない。2026年8月15日に確認した範囲では、ComfyUI公式チュートリアルにComfyUI構成でのVRAM数値は見当たらない。VRAMへの言及は「Longer songs take more time and VRAM.」や、後述する低VRAM GPU向けの推奨といった定性的なものにとどまる。

このようにVRAMへ載りきらない分をCPU側へ逃がす考え方は、ローカルLLMでも同じ形で出てくる（ローカルLLM常駐時のVRAM配分）。ComfyUI側の消費量を左右する既定の挙動としては、次の点が効く。ComfyUIは既定でモデルを使用後にCPUメモリへ退避する。加えて本記事の測定環境（NVIDIA GPU）では、dynamic VRAMと非同期の重みオフロードが有効だった。v0.33.1のコマンドライン定義では、非同期オフロードが “Enabled by default on Nvidia”、dynamic VRAMが “Enable dynamic VRAM on systems where it’s not enabled by default” と説明されており、既定の状態は環境に依存する。いずれもオプションで無効化できる。

低VRAMのGPU向けには、公式チュートリアルが「Use the INT8 diffusion model and tiled decode for long songs on low-VRAM GPUs」と推奨している。この推奨は低VRAMのGPUでメモリを収めるためのもので、速度について述べたものではない。速度の面は後述の段階別の比較で扱う。実際にComfyUI構成でどこまで使ったかは、次の実測1以降の数値で見ていく。

必要なファイルと置き場所

必要なファイルは拡散モデル・テキストエンコーダ・VAEで、拡散モデルにはFP16版とINT8版がある。ComfyUIで使う場合の配置先は次のとおり（ComfyUI v0.33.1の既定のディレクトリ構成。本記事の測定もこの配置で行っている）。

種別	配布ファイル	置き場所
拡散モデル（FP16）	minimax_music3_dit_fp16.safetensors	models/diffusion_models
拡散モデル（INT8）	minimax_music3_dit_int8_convrot.safetensors	models/diffusion_models
テキストエンコーダ	minimax_music3_text_encoder_pruned_int8_convrot.safetensors	models/text_encoders
VAE	minimax_music3_dav.safetensors	models/vae

同じリポジトリには、拡散モデルのFP32版（minimax_music3_dit_fp32.safetensors）と、テキストエンコーダのbf16版（通常版と枝刈り版）も置かれている。テキストエンコーダのFP32版は無い（2026年8月15日確認）。

ComfyUIそのものの扱いに慣れていない場合はComfyUIをPython不要・APIなしで自動化する方法が入口になる。入力はCaptionとLyricsの2系統。CaptionはGlobal Metadata・Vocal Details・Arrangementのブロックに分けて書き、Lyricsは[Intro]や[Chorus]等のタグで区切る、というのが公式チュートリアルの記載である。

測定の前提と、測っていない軸

本記事の実測値は2026年8月15日時点・RTX 5080 16GB単体・ComfyUI v0.33.1での測定に基づく。

環境は、RTX 5080 16GB単体（CUDA_VISIBLE_DEVICESで5080のみ可視）、ComfyUI v0.33.1、PyTorch 2.9.1+cu128、システムRAM 96GB。設定は公式テンプレートに揃え、サンプラーは30ステップ・cfg 1.7・euler・simple、テキストエンコード側はcfg_scale 1.7・top_k 50とした。中心となる条件は日本語歌詞・60秒指定で、各条件で異なるseedを使っている。

以降の表に出る「エンジン時間」は、ComfyUIが報告する実行時間（受付から完了まで）を指す。キュー待ちは含まない。すべての表で同じ指標である。

ピークVRAMはnvidia-smiが返すGPU全体の使用量で、デスクトップ常駐分を含む。以降の表で「専用VRAMのピーク」と書くのも同じ量を指し、共有メモリとは別枠で数えている。プロセス単位の内訳ではなく、ComfyUIがcudaMallocAsyncを使うためPyTorch側のプロセス別統計は取得できなかった。共有メモリのピークは、GPUがシステムRAM側に確保した領域をWindowsのパフォーマンスカウンタで毎秒記録したものである。

同一条件でもseedが変われば曲の長さと所要時間は動く。FP16・タイルdecodeなしの条件は別のseedで2回測っており、エンジン時間は365.0秒と376.5秒だった。実測1の表には376.5秒の回を載せている。

測っていない軸は次のとおり。手元の構成がここに当てはまる場合、この記事の数値はそのまま当てはまらない。

• 容量: 16GB未満のカード、および16GBを超えるカード。いずれも測定していない。12GB級で何が動くかはRTX 3060 12GBで始めるローカルAI、24GB級は中古RTX 3090 24GBはローカルAIに買いかで扱っている。
• 製品: RTX 5080以外のGPU（例としてRTX 5060 Ti）。
• 枚数: 複数枚での動作。測定は1枚だけを可視にした状態で行っている。2枚目を足したときの効果はAI用途にGPUは2枚必要かで別途測っている。
• システムRAM: 96GBの環境で測っている。これより少ない環境は範囲外。ローカルAI全般でRAMがどれだけ要るかはローカルAIにシステムRAMは何GB必要かで同じ96GB実機の測定をまとめている。

構成が異なる場合に参照すべきなのは、この記事の表ではなく、同じ条件で測られた値になる。同じMiniMaxの動画生成モデルを同じ16GB環境で測った記事としては、MiniMax H3をVRAM 16GBで動かすがある。

実測1: 16GBで動くか

拡散モデルの精度（FP16／INT8）とタイルdecodeの有無を組み合わせた4条件で、60秒指定・日本語歌詞の生成を行った。結果はいずれも成功している。

構成	ピークVRAM	エンジン時間	結果
INT8拡散モデル・タイルdecodeなし	15,940 MiB	416.3秒	成功
INT8拡散モデル・タイルdecodeあり	13,256 MiB	418.4秒	成功
FP16拡散モデル・タイルdecodeなし	15,900 MiB	376.5秒	成功
FP16拡散モデル・タイルdecodeあり	15,377 MiB	364.3秒	成功

ピークVRAMはGPU全体の使用量で、デスクトップ常駐分を含む値である点に注意が要る。プロセス単位の内訳は取れていない。FP16・タイルdecodeなしの行は2回測ったうちの376.5秒の回で、もう1回は365.0秒だった。同一条件でもseedが変われば曲の長さと所要時間は動く。

4条件の中で最も低いのはINT8・タイルdecodeありの13,256 MiB、最も高いのはINT8・タイルdecodeなしの15,940 MiB。ただし、この数字を「16GBが必要」と読むことはできない。理由は次の見出しで扱う。

観測したピークは「必要量」ではない

ComfyUIは既定でモデルを使用後にCPUメモリへ退避し、測定環境ではdynamic VRAMと非同期の重みオフロードが有効だった。dynamic VRAMは空き容量に応じて確保量を変える仕組みである。ただしreserve指定なしの同じ状態でも4条件のピークは13,256〜15,940 MiBに分かれており、空き容量だけで決まってはいない。低いのはINT8・タイルdecodeありで、タイルdecodeなしの2条件が高い側に来る。重みの大きさとdecode段の作業領域も同時に効いていると見えるが、分離しては測っていない。16GBのカードで15,940 MiBまで積み上がったことも、そこまで空いていた状態で走らせた結果として説明はつく。ただし空き容量を実際に削って確かめたのはINT8・タイルdecodeありの条件だけで、15,940 MiBが出たINT8・タイルdecodeなしの条件では削っていない。

この読み方が観測に合うかどうかは、空き容量を減らしたときにピークが追随するかで確かめられる。実際に削って測ったのが次の掃引である。

使えるVRAMを削るとどうなるか

ComfyUIから見える空き容量を--reserve-vramで段階的に削り、INT8拡散モデル・タイルdecode・60秒指定で生成した。

reserve指定	専用VRAMのピーク	共有メモリのピーク	エンジン時間	結果
なし	13,420 MiB	11,322 MiB	408.0秒	成功
4GB	13,413 MiB	11,298 MiB	376.2秒	成功
6GB	11,767 MiB	11,299 MiB	431.2秒	成功
8GB	9,702 MiB	11,309 MiB	460.5秒	成功
10GB	7,539 MiB	11,292 MiB	454.0秒	成功
12GB	6,335 MiB	11,276 MiB	477.7秒	成功
13GB	6,193 MiB	11,277 MiB	549.3秒	成功

掃引の起点にあたるreserveなしの回は13,420 MiBで、実測1に載せた同じ構成（INT8拡散モデル・タイルdecodeあり）の13,256 MiBとは別の実行になる。エンジン時間も408.0秒と418.4秒に分かれており、同一条件でも回ごとに振れる。reserve指定を13GBまで上げても生成は完了し、専用VRAMのピークは13,420 MiBから6,193 MiBへ、差にして7,227 MiB下がった。エンジン時間は408.0秒から549.3秒へ伸びる方向だが単調ではなく、4GBの回は376.2秒とreserveなしより短い。各条件はseedが異なるため、時間の差を指定量だけに帰することはできない。

--reserve-vramはComfyUIに対して空き容量を申告する仕組みで、物理的に小容量のGPUを挿した状態とは別物になる。8GBや12GBのGPUでの動作を直接確かめた測定ではないため、この表から特定の容量のカードの可否を読むことはできない。掃引の条件もINT8拡散モデル・タイルdecode・60秒指定の1条件だけで、他の条件では行っていない。

手元のカードで確かめる場合は、同じ条件（INT8拡散モデル・タイルdecode・60秒指定）で専用VRAMと共有メモリの両方を記録すると、この表と直接突き合わせられる。

VRAMを削っても共有メモリの使用量は動かなかった

同じ掃引で共有メモリのピークを追うと、専用VRAMが7,227 MiB下がる間に11,276〜11,322 MiBの幅に収まっている。専用VRAMから減った分がこちらへ移ったわけではなく、reserve指定によらず一定量が置かれ続けた、という読み方が観測に合う。

その一定量が何に近いのかを見るため、重みファイルの合計サイズと並べた。

拡散モデル	重みファイル合計	共有メモリのピーク
INT8	11.10 GiB	11,276〜11,322 MiB（約11.03 GiB）
FP16	13.34 GiB	13,579 MiB（約13.26 GiB）

重みファイル合計は各ファイルサイズの単純合計で、共有メモリのピークとの近さは観測にとどまる。量子化でどこまでサイズを落とせるか、その代償に何が起きるかは量子化で27B級LLMはVRAM 16GBに載るかで別に扱っている。内訳を分解して確かめたものではない。

ここまでをまとめると、専用VRAMのピークは空き容量に追随して動いた一方、システムRAM側の使用量はほとんど動かなかった。INT8拡散モデル・タイルdecode・60秒指定の掃引では、reserve指定によらず11,276〜11,322 MiBが共有メモリとしてシステムRAM側に置かれ続けた（掃引していないFP16の回では13,579 MiB）。この範囲では専用VRAMの残量が動作の分かれ目にならなかった。システムRAMを減らした測定は行っていないため、そちらがどこで足りなくなるかは確かめていない。

実測2: 1曲あたりの所要時間

生成された音声の実長で割った、1秒あたりの所要時間を出した。FP16拡散モデル・日本語歌詞の2回で、タイルdecodeの有無は行ごとに異なる。

生成された長さ	タイルdecode	AR段	拡散段（30ステップ）	エンジン時間	音声1秒あたり
59.99秒	なし	315秒	36秒	365.0秒	約6.1秒
147.88秒	あり	786秒	91秒	893.4秒	約6.0秒

掛ける対象は生成された音声の実長であって、max_durationに指定した秒数ではない。約6秒という値もFP16拡散モデル2回から出したもので、全構成の目安として使えるものではない。INT8は60秒指定で416.3秒・418.4秒、生成された実長（いずれも約60秒）で割ると音声1秒あたり約7秒だった。

また、この表の2行はタイルdecodeの有無が異なる。あくまで音声1秒あたりの傾向を見るための並びで、タイルdecodeの効果を比較する材料にはならない。decodeそのものの比較は後述の対照で行っている。AR段の処理速度は全条件で毎秒4.6〜4.8ステップの範囲に収まった。

時間を決めているのは自己回帰（AR）段

テキストエンコード段は自己回帰で動作し、生成する音声1秒あたり25ステップを回す。ComfyUI v0.33.1の実装は毎秒25フレームで、ステップ数は生成された音声の秒数×25+1（max_durationに入れた秒数ではない）。実行ログのステップ数もこれと一致した。60秒なら1,501ステップが回る計算になる。

内訳を見ると、60秒・FP16・タイルdecodeなしの回はAR段315秒に対して拡散段（30ステップ）が36秒。147.88秒の回ではAR段786秒に対して拡散段91秒。曲が長くなるほどAR段が伸び、待ち時間の大半をここが占める。

ステップ数と所要時間の関係は、同じMiniMaxの動画生成モデルでも測っている（MiniMax H3 Turbo LoRAは何倍速い？）。ただしMiniMax Music 3のこの構成では、サンプラーのステップ数が効く範囲は36秒や91秒という拡散段の内側にとどまり、全体の時間を決めているのはAR段の側である。

max_durationは上限であって長さの指定ではない

max_durationに指定した秒数と、実際に生成された音声の長さを並べた。末尾の様子は0.25秒ごとのRMSを曲全体の中央値と比較して判定している。

指定	歌詞	実際の長さ	終わり方
30秒	平易・短い	29.99秒	音量が乗ったまま断ち切り
60秒	平易・短い	59.84秒	フェードして終了
60秒	漢字混じり・密	59.99秒	音量が乗ったまま断ち切り
180秒	平易・長い	128.03秒	フェードして終了
300秒	平易・長い	147.88秒	フェードして終了

300秒を指定しても、出てきたのは147.88秒だった。実装上の最大長は360秒に相当する（音声フレーム上限9000、毎秒25フレーム）。公称としては、公式チュートリアルに「the model supports up to about 300 seconds / 5 minutes」という記載があり、実装上の定数から出る値とは異なる。

指定を上げても同じだけ伸びるわけではなく、同一条件でもseedが違えば長さは変わる。同じ「平易・長い」歌詞でも、180秒指定と300秒指定でそれぞれ128.03秒と147.88秒に分かれており、実長を決めている要因は系統的に測っていない。歌詞量との関係を確かめたい場合は、歌詞だけを変えて同じ設定で回数を重ねる形になる。

待ち時間の見積もりに使うのも、指定秒数ではなく実長のほう。実長147.88秒に対するエンジン時間は893.4秒だった（FP16拡散モデル・タイルdecodeあり）。

INT8は重み側のメモリが小さいが、この構成では拡散段が遅い

拡散モデルの違いによる段階別の差を、60秒指定・日本語歌詞・タイルdecodeなしで比べた。

拡散モデル	AR段	拡散段（30ステップ）	エンジン時間
INT8	324秒	83秒	416.3秒
FP16	315秒	36秒	365.0秒

AR段は324秒と315秒でほぼ変わらない。テキストエンコーダはINT8構成でもFP16構成でも同一のファイルを使うため、拡散モデルの精度がAR段の計算そのものを変えることはない。表に出た差も、全条件で観測された毎秒4.6〜4.8ステップという処理速度の振れの内側にある。分かれたのは拡散段で、INT8が83秒、FP16が36秒。エンジン時間では416.3秒と365.0秒になった。なおFP16の行は、先の所要時間の表の1行目と同じ実行を別の切り口で再掲したものである。

メモリ側は逆向きになる。重みファイル合計はINT8が11.10 GiB、FP16が13.34 GiB。共有メモリのピークも約11.03 GiBと約13.26 GiBで、INT8のほうが小さい。専用VRAMのピークは、この表と同じタイルdecodeなしの条件ではINT8 15,940 MiB・FP16 15,900 MiBとほぼ並ぶ（タイルdecodeありでは13,256 MiBと15,377 MiBに分かれる）。タイルdecodeなしで比べるかぎり、INT8を選ぶメモリ側の根拠になるのは重みファイル合計と共有メモリのほうである。

公式チュートリアルの推奨は、低VRAMのGPUで長い曲を作るときにメモリを収めるためのもので、速度について述べたものではない。16GB・60秒指定というこの構成では、INT8は拡散段が遅くなる方向に出た。音質の差については、比較した音源が別のseedで生成された別の曲であるため、本記事では比較していない。

実測3: 日本語ボーカルはどこまで実用か

公式ブログが提示している楽曲例は中国語と英語で、公式ブログ本文の範囲では日本語への言及が見当たらない。これは日本語に対応しないことを示すものではなく、本記事の測定では日本語の歌詞がそのまま歌われている。

歌唱がどれだけ入力どおりかを見るため、生成した歌唱をWhisper large-v3-turboで書き起こし、入力歌詞と比較した。日本語は入力がひらがな・書き起こしが漢字混じりになるため、双方を読み（ひらがな）に正規化してから突き合わせている。

条件	一致率	備考
60秒・平易な日本語歌詞（INT8）	0.983	入力どおり。差は「日」の読みを正規化側がどう取るかによるもの
60秒・平易な日本語歌詞（FP16）	0.978	入力どおり
60秒・漢字混じりの密な日本語歌詞	0.942	「上着」が「浮気」、「足取り」が「足通り」等、濁音と語境界の揺れ。加えて書き起こしが入力歌詞の末尾（最終行の後半）まで到達せずに終わっている
30秒・平易な日本語歌詞	0.583	書き起こしが3行で終わる。曲自体が尺切れで断ち切られているため
60秒・平易な日本語歌詞（FP16・タイルdecodeあり）	0.814	書き起こしに無音区間で定型句が混入した。ASR側の破綻
60秒・英語歌詞	0.313	書き起こしが同一語を数百回反復した。ASR側の破綻で、英語の歌唱品質を示すものではない

歌唱に対するASRは会話音声より精度が落ちる。一致率をそのまま音質や歌唱の巧拙に読み替えることはできない。一致率が0.9を下回った回は、いずれも書き起こし側の破綻（無音区間での定型句の混入、同一語の反復）か、曲そのものが尺切れで途中終了していたことによるもので、モデルが歌詞を誤って歌ったことを示す値ではない。歌唱の質を判断する材料としては、一致率よりも通しの試聴と、尺に対する歌詞量の関係のほうが手がかりになる。

通しで試聴した際の所見は次のとおり。測定器ではなく耳による観察のため、条件つきの記述に留める。

• 60秒指定・漢字混じりの密な歌詞（実際の長さ59.99秒）: 曲の途中で切れて聞こえ、フェードアウトはしていない
• 同一潜在をタイルdecodeあり／なしでdecodeした2本: 聞き分けられる差は分からなかった
• INT8拡散モデルとFP16拡散モデルの出力: 聞き分けられる差は分からなかった（別のseedによる別の曲どうしの比較）

いずれも主観的な観察であり、音質の優劣を測った結果ではない。比較した音源には別のseedで生成した別の曲が含まれるため、量子化による音質差の比較にもなっていない。

実際に入れた指示と歌詞、返ってきた書き起こし

一致率だけでは何が起きたか分からないため、入力と書き起こしをそのまま並べる。Captionは全条件で共通のものを使い、Lyricsだけを差し替えた。

Caption（全条件で共通）

Global Metadata: Japanese pop (J-pop), bright city-pop leaning. 96 BPM, C major,
major scale with sus2 color. Warm and hopeful throughout, lifting gently at the
chorus and settling softly at the end. Morning commute, window-seat, headphones-on
listening. Clean modern production: tight low end, airy top, light tape warmth.

Vocal Details: Female Japanese vocal, clear bright timbre, natural conversational
delivery with a soft head voice on high notes, light double-tracking on the chorus,
subtle plate reverb.

Arrangement: Lead electric piano and clean electric guitar, supportive synth pad,
round electric bass, crisp acoustic drum kit with brushed hi-hats, light shaker,
wide stereo backing harmonies.

公式チュートリアルが示すGlobal Metadata・Vocal Details・Arrangementの3ブロックに沿って書いている。日本語で歌わせるための指定は Vocal Details の「Female Japanese vocal」だけで、Caption自体は英語で書いた。

Lyrics その1（平易・ひらがな中心）

[Intro]

[Verse]
あさの ひかりが まどを たたく
ねむい めを こすって おきる
いつもの みちを あるきだす
きょうも いい ひに なりそう

[Chorus]
はしれ はしれ かぜの なかへ
ゆめは まだ とおくても
はしれ はしれ あしたへ
きっと とどく はずさ

[Outro]

これを60秒指定で生成し、出力をWhisperで書き起こすと次のようになった（INT8拡散モデル・タイルdecodeなしの回、一致率0.983）。

入力はひらがなで書いたが、書き起こしは漢字混じりで返る。読みとしては全行が対応しており、抜けも入れ替わりもない。

Lyrics その2（漢字混じり・1行が長い）

[Intro]

[Verse]
交差点の信号が青に変わる瞬間を待ちながら
昨日の後悔を上着のポケットに押し込んで歩く
見慣れた景色のはずなのに今日は少しだけ違って見える
理由はきっと自分でも説明できないままでいい

[Chorus]
走れ走れ 迷いごと全部抱えたままで
完璧じゃない足取りでも前に進んでいけるから
走れ走れ 明日の自分に手を伸ばして
いつか笑って話せる日まで

[Outro]

同じ60秒指定で生成した結果の書き起こしが次になる（FP16拡散モデル・タイルdecodeなしの回、一致率0.942）。

崩れ方に偏りがある。「交差点」が「校舎店」、「後悔」が「航海」、「上着」が「浮気」、「足取り」が「足通り」と、いずれも読みが近い別語に寄っている。文の骨格や語順は保たれており、行がまるごと抜けてはいない。ただし末尾の「話せる日まで」に相当する部分は書き起こしに出ていない。この回は60秒の枠を使い切って途中で終わっており、その扱いは次の見出しで分ける。

ここで注意がいるのは、書き起こし側の崩れとモデル側の崩れを分離できていない点である。書き起こしはWhisperによるもので、歌唱に対するASRは会話音声より精度が落ちる。「校舎店」のような語が、実際にそう歌われたのか、正しく歌われたものを取り違えたのかは、この方法では判別できない。読みの近い語に寄っているという傾向までが、この測定で言える範囲になる。

歌詞が尺に入らないと断ち切られる

指定した尺に歌詞が収まらない回では、曲が終わりきらずに切れる。30秒指定・平易な日本語歌詞の回は、波形の末尾が音量の乗ったまま断ち切られ、ASRの書き起こしも歌詞の途中で終わって一致率0.583だった。この回で揃ったのは波形とASRの2つである。

60秒指定・漢字混じりの密な歌詞の回では、波形の終わり方が同じく断ち切りで、書き起こしは入力歌詞の末尾まで到達せず一致率0.942、通しの試聴でも曲の途中で切れて聞こえた。この回は波形とASRと試聴が同じ向きを示している。

一方、60秒指定・平易な歌詞の回はフェードして終わり、一致率も0.978と0.983。同じ歌詞でも30秒指定では断ち切られていることから、尺に対して歌詞が多いかどうかが終わり方の分かれ目になっている。ただし実長そのものを決めている要因までは測っていない。

タイル decodeの継ぎ目は出るか

同一のseedで生成した同一の潜在表現を、タイルdecodeあり／なしの2通りでdecodeして比べた。上流（テキストエンコード・拡散）はComfyUIのノードキャッシュで再利用され、decodeノードだけが実行されている。tile_sizeは公式テンプレートの1536、overlapは64。

音声の長さ	タイルdecode	タイルなしdecode
59.99秒	10.3秒 / ピーク5,976 MiB	測定していない
147.88秒	約16秒	96.3秒 / ピーク15,879 MiB

これはdecode単体の所要で、生成全体の時間ではない。147.88秒の音声では、タイルなしdecodeが96.3秒・ピーク15,879 MiBに対し、タイルdecodeは約16秒。59.99秒の音声側はタイルdecodeが10.3秒・ピーク5,976 MiBで、タイルなしdecodeは所要時間とピークを記録していない（後述の波形比較には、この潜在をタイルなしでdecodeしたファイルを使っている）。

音の側は波形で突き合わせた。同一潜在をタイルあり／なしでdecodeした2ファイルを44.1kHzでサンプル単位に比較し、0.25秒窓のRMS差を見ている。タイル境界の予測位置は17.83秒・35.67秒・53.50秒。

指標	値
2波形の相関	0.999993
差分RMS / 原音RMS	0.000521 / 0.128413
各タイル境界での差分の最大	0.00101 / 0.00116 / 0.00086
異常と判定するしきい値（中央値+4σ）	0.00164
差分が最大だった位置	9.85秒（タイル境界ではない）

境界での差分はいずれもしきい値0.00164を下回り、差分が最大だったのは9.85秒の位置で、タイル境界とは無関係の場所だった。通しの試聴でも聞き分けられる差は分からなかった。

ここで言えるのは60秒・tile_size 1536の1本についてであり、より長い曲や小さいtile_sizeでの挙動は別になる。なお公式チュートリアルはタイルdecodeについて「Slightly slower with a small risk of seams at tile boundaries.」と書いている。decode単体で比べた147.88秒の音声では、タイルありが約16秒・なしが96.3秒でタイルありのほうが速かった。ただし60秒指定の生成全体で見るとINT8はタイルあり418.4秒・なし416.3秒でほぼ変わらず、この記述と食い違う結果ではない。継ぎ目についても、しきい値を超える差が出なかったのは60秒・tile_size 1536の1本での結果であり、「小さなリスク」という記述を否定できる材料ではない。MP3経由での比較のため、全域にわずかな差が乗る点も条件に含まれる。別の条件で確かめる場合は、同一seedで対照を取り、境界の予測位置で差分を見るという同じ手順がそのまま使える。

構成別の選び方

実測の範囲で言えることを整理する。

• 可否: RTX 5080 16GB単体・60秒指定であれば、FP16／INT8とタイルdecodeあり／なしの組み合わせはいずれも通った。タイルなしdecodeで通したのは180秒指定（実長128.03秒）の回まで。タイルdecodeなしでこれより長い実長を通したケースと、INT8での長尺は測っていない（実長147.88秒の通しはタイルdecodeありで行っている）。
• 速度: この構成ではFP16のほうが拡散段が速く、60秒指定・タイルdecodeなしでエンジン時間365.0秒に対しINT8は416.3秒。
• メモリ: 重みファイル合計と共有メモリのピークはINT8が小さい（11.10 GiBと約11.03 GiB、FP16は13.34 GiBと約13.26 GiB）。共有メモリはシステムRAM側の領域にあたる。
• 長い曲のdecode（同一潜在に対するdecode単体の対照）: 147.88秒の音声で、タイルなしdecodeは96.3秒・ピーク15,879 MiB、タイルdecodeは約16秒。
• 待ち時間の見積もり: 生成された実長に対して、FP16で音声1秒あたり約6秒、INT8で約7秒。指定した秒数ではなく実長に掛ける。ただし180秒指定の回はこの目安を上回り、内訳も埋まっていない。

16GB未満・16GB超・複数枚・システムRAMが少ない環境は測定範囲の外にあるため、この整理をそのまま持ち込むことはできない。近い構成での判断材料が要る場合は、同じ指定秒数・同じ精度で測られた値を探すことになる。

よくある質問

Q. 16GBより小さいVRAMのカードでも動くか

本記事では測っていない。ComfyUIから見える空き容量を削る掃引では、reserve 13GB（専用VRAMのピーク6,193 MiB）まで生成が通ったが、これはINT8拡散モデル・タイルdecode・60秒指定という1条件での結果であり、しかも空き容量の申告にすぎない。物理的に小容量のカードを挿した状態とは別物になる。MiniMax公式のモデルカードには、層ごとのストリーミングで8GBのビデオカードにも収まるという記載があるものの、これはMiniMax公式実装についての記述で、ComfyUI構成の値ではない。

Q. システムRAMはどれくらい要るか

測定は96GBの環境で行っている。共有メモリのピークはINT8で約11.03 GiB、FP16で約13.26 GiBで、それぞれ重みファイル合計11.10 GiB・13.34 GiBに近い値だった。RAMが少ない環境での可否は測っていないが、この量をシステムRAM側に置けるかどうかが、手元の構成を見積もる際の起点になる。

Q. 5分の曲を作りたい。どれくらい待つか

max_durationは上限であり、指定した秒数がそのまま出てくるわけではない。300秒を指定した回で実際に生成されたのは147.88秒だった。待ち時間は実長に掛ける形で、FP16なら音声1秒あたり約6秒、INT8なら約7秒。加えて180秒指定の回のように、内訳が説明できないまま時間が伸びた例もあるため、見積もりには幅を持たせておく必要がある。

Q. INT8とFP16で音は変わるか

本記事では比較していない。試聴した音源どうしは別のseedで生成された別の曲で、量子化の影響を切り分けられないためである。測った範囲で差が出たのは拡散段の所要時間（INT8 83秒・FP16 36秒）と、重みファイル合計および共有メモリのピークの側だった。

まとめ

• RTX 5080 16GB単体・ComfyUI v0.33.1で、60秒指定であれば、拡散モデルの精度とタイルdecodeの有無を問わず生成は完了した。タイルなしdecodeで通したのは180秒指定（実長128.03秒）の回まで。タイルdecodeなしでこれより長い実長を通したケースと、INT8での長尺は測っていない（実長147.88秒の通しはタイルdecodeありで行っている）。
• 観測したピークVRAM（13,256〜15,940 MiB）は必要量ではない。INT8拡散モデル・タイルdecode・60秒指定の1条件で空き容量を削った掃引では、専用VRAMのピークが6,193 MiBまで下がっても生成は通った。物理的に小容量のGPUでの可否は別途の測定が要る。
• 同じ掃引で共有メモリのピークは11,276〜11,322 MiBの幅に収まり、reserve指定によらず重みファイル合計に近い量が置かれ続けた。
• 待ち時間は生成された実長に掛ける。FP16で音声1秒あたり約6秒、INT8で約7秒。max_durationの指定秒数ではない。ただし180秒指定の回はこの目安を上回った。
• 日本語の歌詞は歌われた（60秒・平易な歌詞でASR一致率0.978と0.983）。尺に歌詞が収まらない回では曲が断ち切られる。

参考資料

• MiniMax 公式ブログ（MiniMax Music 3）
• MiniMax-Music3 モデルカード（VRAM記載・音声フレーム上限）
• ComfyUI 公式チュートリアル（MiniMax Music 3）
• Comfy-Org/MiniMax-Music-3（重みの配布元）
• MiniMax-Music3 ライセンス
• ComfyUI リリース一覧