ACE-Step 1.5 XLをRunPodで動かす公開ComfyUIテンプレート

⚠️ 注意: AI画像生成時は著作権・肖像権にご注意ください。商用利用前には各サービスの利用規約をご確認ください。当ブログは生成された画像に関する責任を負いかねます。

📝 本記事にはアフィリエイトリンクが含まれています。

要約

ACE-Step 1.5 XLをRunPod上のComfyUIで動かすために、公開用のRunPodテンプレートを作りました。

2026年8月にテンプレートを v3.0.0 へ更新して、ComfyUIを 0.32.0 に上げ、CUDA 12.8版とCUDA 13.0版の2本立てにしました。その後も更新を重ねていて、執筆時点（2026年9月）の最新は v3.4.0 です。

同じ構成で試したい場合は、以下のDeployリンクから起動できます。

用途	テンプレート	Deploy
まずはこちら	`ComfyUI-ACE-Step1.5XL-cuda12.8-v3-FreeCraftLog`	RunPodでDeploy
CUDA 13.0のGPUを使いたい場合	`ComfyUI-ACE-Step1.5XL-cuda130-v3-FreeCraftLog`	CUDA 13.0版をDeploy

2026年9月からは同じ構成をRunPod Hubにも載せています（後述の「RunPod Hubからも起動できます」の項）。

RunPodのACE-Step 1.5 XL ComfyUIテンプレートDeploy画面 — 公開テンプレートから同じ構成でDeployできる

この記事では、公開テンプレートの使い方、base / SFT / turboの選び方、RTX 4090で30秒の楽曲を生成した時間、つまずいた点をまとめます。

2026年8月28日更新

テンプレートを v3.0.0 に更新した内容へ全面的に書き直しました。CUDA 12.4版は廃止したので、以前の記事を見て12.4版を探していた方はCUDA 12.8版を使ってください。生成時間も条件を揃えて測り直しています。

2026年9月15日更新

同じ構成をRunPod Hubにも公開しました。「RunPod Hubからも起動できます」の項を追加しています。

2026年9月18日更新

v3.4.0 で ACESTEP_LM を廃止しました。text encoderは qwen_0.6b と qwen_4b を常に配置します。以前の設定で ACESTEP_LM を指定していても、警告が出るだけで起動するので、そのままで問題ありません。経緯は「text encoderを選択式にしたのをやめた」に書いています。

数値について

Template IDやRunPodの料金は変わる可能性があります。記事内の数値は検証時点の参考として見てください。

はじめに

ACE-Step 1.5 XLは、ComfyUIからAI音楽生成を試せるモデルです。

ただ、RunPodで毎回モデルやtext encoderを確認しながら環境を作るのは手間でした。

そこで、ComfyUIのworkflow templateを選ぶだけでACE-Step 1.5 XLを実行できるRunPodテンプレートとしてまとめました。

モチベル

音楽生成って、画像生成より準備が違うの？

クーラット

diffusion modelだけじゃなくて、text encoderやVAEも必要になる。足りないとworkflowで止まるから、まとめて配置するテンプレートにしたよ。

この記事は、RunPodテンプレート作成シリーズのACE-Step 1.5 XL編です。Wan2.2用のRunPodテンプレートも同じ構成で公開しています。Wan2.2用ComfyUIテンプレート記事もあわせてどうぞ。

ACE-Step 1.5 XL用ComfyUIテンプレートの構成

作ったのは、ACE-Step 1.5 XLをRunPod上のComfyUIで試すための公開テンプレートです。

公開リポジトリはこちらです。

GitHub - RyoheiTanaka/runpod-templates: RunPod用スタートアップスクリプトテンプレート集（Wan2.2 / ACE-Step など）

RunPod用スタートアップスクリプトテンプレート集（Wan2.2 / ACE-Step など）. Contribute to RyoheiTanaka/runpod-templates development by creating an...

テンプレートでは、GHCRに置いた事前ビルド済みimageを使います。

用途	Container image
既定	`ghcr.io/ryoheitanaka/runpod-templates-acestep15xl:v3.4.0-cuda12.8`
CUDA 13.0版	`ghcr.io/ryoheitanaka/runpod-templates-acestep15xl:v3.4.0-cuda13.0`

Start Commandは以下です。

/opt/runpod/start.sh

ACE-Step 1.5 XL RunPodテンプレートのContainer imageとStart Command設定 — GHCRの固定tag imageとStart Commandを確認する

image build時に、OS package、ComfyUI、Python dependencies、huggingface_hubを入れておき、Pod起動時にはモデル配置とComfyUI起動を行います。

公開テンプレートから使う方法

まず試すなら、CUDA 12.8版の ComfyUI-ACE-Step1.5XL-cuda12.8-v3-FreeCraftLog を使います。

ACE-Step 1.5 XLテンプレートをRunPodでDeployする

RunPod Hubからも起動できます

2026年9月から、同じ構成をRunPod Hubにも載せています。HubのDeployボタンからはPodのほかにServerless endpointとしても起動でき、モデルは初回起動時にダウンロードされます。既定はTurboで、Base版や全モデルはデプロイ画面のプリセットで切り替えられます。

Hub版はServerlessのqueue APIからworkflowを投げる使い方を想定して作ったものです。ComfyUIの画面を使いたい場合は、上のconsoleテンプレートを使ってください。

HubのPodではComfyUIの画面は開けません

HubのDeployでPodを選んでも、ComfyUIの画面は出てきません。Hubのlistingにはポートを宣言する場所が無く、開くのは 80/http と 443/tcp だけだからです。ComfyUIは8188で動いていますが、外には出ていません。https://POD_ID-8188.proxy.runpod.net を開くと404になります。HubのPodは、サーバーレスのワーカーをPodとして動かしたもので、ジョブAPIを 80 番で受ける形です（2026年9月18日に実機で確認）。

Hubに載せるまでの経緯はRunPod Hubにテンプレートを公開するまでにまとめています。

RunPodの登録やクレジット追加がまだの場合は、先にRunPodの始め方ガイドを参考にしてください。

RunPodの使い方｜登録からComfyUI起動まで実際にやった手順【2026年版】

RunPodは、GPUを時間単位で借りられるクラウドGPUサービスです。従量課金で月額固定はなく、のチャージから使えます。アカウント登録・クレジット購入・Pod起動・ComfyUI接続までを、実際にやった画面スクショつきで解説します。GPU選びや停止忘れ対策も初心者向けにまとめました。

Pod作成時に見るポイントは以下です。

項目	推奨値
Template	`ComfyUI-ACE-Step1.5XL-cuda12.8-v3-FreeCraftLog`
Container Disk	`100 GB`
Volume Mount Path	`/workspace`
Ports	`8188/http`, `22/tcp`
Start Command	`/opt/runpod/start.sh`
`ACESTEP_XL_VARIANT`	`all`

起動後はComfyUIを開き、workflow templateからACE-Step 1.5 XL系のワークフローを選んで実行します。

ACE-Step 1.5 XL自体の概要やComfyUIでの基本的な使い方は、ACE-Step 1.5 XLの解説記事でまとめています。

base / SFT / turboとtext encoderの選び方

このテンプレートでは、ACE-Step 1.5 XLのdiffusion modelを環境変数で切り替えられるようにしています。

環境変数	用途
`ACESTEP_XL_VARIANT=xl_base`	baseのみ
`ACESTEP_XL_VARIANT=xl_sft`	SFTのみ
`ACESTEP_XL_VARIANT=xl_turbo`	turboのみ
`ACESTEP_XL_VARIANT=all`	3種類すべて

text encoderのほうは選べません。qwen_0.6b（1.1 GiB）と qwen_4b（7.8 GiB）の2つを常に配置します。

ACE-Step 1.5 XLの公式ワークフローは、DualCLIPLoader でこの2つを一緒に読む作りになっているんです。base / SFT / turboのどれを選んでも同じで、片方だけでは動きません。だったら選択式にしておく意味がないので、v3.4.0 で環境変数ごと無くしました。この経緯は後述の「text encoderを選択式にしたのをやめた」に書いています。

以前の ACESTEP_LM を指定したままでも、警告が出るだけで起動します。消し忘れていても壊れません。

CUDA 12.8版とCUDA 13.0版の使い分け

GPUの世代にかかわらず、まずはCUDA 12.8版を使ってください。

以前のこの記事では「RTX 3090 / 4090はCUDA 12.4版、RTX 5090はCUDA 12.8版」と書いていましたが、v3.0.0 でCUDA 12.4版を廃止したので、この出し分けはなくなりました。ComfyUI 0.32.0 が要求する comfy-kitchen がPyTorch 2.5以上を前提としていて、CUDA 12.4ベースのPyTorch 2.4系ではComfyUIが起動しなくなったためです。

RTX 3090でもCUDA 12.8や13.0のホストは割り当てられるので、古めのGPUが取り残されることはありません。

CUDA 13.0版は、CUDA 13.0対応のGPUを選んで使う場合の選択肢です。新しいCUDAのimageほど、起動できるホストは狭くなります。 imageはホスト側ドライバのCUDAバージョンを要求していて、条件を満たさないホストではコンテナが起動する前に失敗するためです。

image	ホストへの要求	起動できるホスト
`cuda12.8`	`cuda>=12.8`	12.8のホストと13.0のホストの両方
`cuda13.0`	`cuda>=13.0`	13.0のホストのみ

この経緯はWan2.2用ComfyUIテンプレート記事のほうで詳しく書いています。実際に引いたホストのばらつきやエラーメッセージも載せているので、CUDA 13.0版を使う前に目を通しておくと迷わないと思います。

テンプレートの仕組み

事前ビルドimageで何を済ませているか

事前ビルドimageでは、以下を済ませています。

git, git-lfs, curl, ffmpeg, libsndfile1 などをinstall
/opt/ComfyUI にComfyUI 0.32.0 をclone
ComfyUI requirementsをinstall
huggingface_hub をinstall
/opt/runpod/start.sh をimage内に配置

Pod起動時に毎回ComfyUIのinstallから始めると、起動時間と失敗要因が増えます。そこで、ComfyUI本体と依存関係はimage側で済ませ、Pod起動時はモデル配置とComfyUI起動に寄せました。

ダウンロード高速化の指定は HF_XET_HIGH_PERFORMANCE=1 を使っています。以前使っていた HF_HUB_ENABLE_HF_TRANSFER は現在は非推奨で、設定しても効きません。

Pod起動時に何をしているか

Pod起動時の start.sh では、主に以下を行います。

/workspace/models/acestep15xl、/workspace/logs、/workspace/outputs を作成
sshdを起動
ACESTEP_XL_VARIANT に応じてdiffusion modelをダウンロード
qwen text encoder（qwen_0.6b と qwen_4b）をダウンロード
ace_1.5_vae.safetensors をダウンロード
/opt/ComfyUI/models/* へsymlink
0.0.0.0:8188 でComfyUIを起動

モデルはimageに含めず、Pod起動時に /workspace/models/acestep15xl へ配置します。RunPod上でComfyUIを開いた後の基本操作は、RunPodでComfyUIを使う方法でも整理しています。

SSHで入れるようになりました

v1.0.0 のテンプレートは、SSHが繋がりませんでした。imageの CMD が公式イメージのentrypointを置き換えてしまっていて、PUBLIC_KEY は届いているのにsshdが起動していない状態だったためです。

v2.0.0 で start.sh がsshdを起動するように直しました。起動ログに以下が出ていれば動いています。

[start] sshd started

Hugging Face tokenは設定推奨

ACE-Step 1.5 XLは大きめのモデルやtext encoderを使います。未認証でも取得できるファイルがある場合でも、Hugging Face tokenを設定しておいたほうが、rate limitやダウンロード安定性の面で安心です。

テンプレートには HF_TOKEN=your-huggingface-token というplaceholderを入れています。本物のtokenを使う場合は、Pod作成時に差し替えてください。

トークンの取り扱い

HF_TOKENやRunPod APIキーはPod作成時にEnvironment Variableとして設定します。スクリーンショットを撮る際はこれらの値が画面に映らないよう注意してください。

proxy URLは認証なしで公開されます

8188/http のproxy URLには認証がありません。URLを知っていれば誰でもComfyUIを操作できますし、input/ と output/ の中身も見えます。

生成した音源を置いたまま長時間起動しておくのは避けて、必要ならSSH port forward経由で使うほうが安全です。

ssh -N -L 8188:localhost:8188 root@<pod-ip> -p <ssh-port> -i <秘密鍵>

動作確認と生成時間

RTX 4090 / CUDA 12.8版で、30秒の楽曲を生成した時間です。ComfyUI 0.32.0 / comfy-kitchen 0.2.30 / comfy-aimdo 0.4.13 で測っています。

3つのvariantで、text encoderは DualCLIPLoader（qwen_0.6b + qwen_4b）に揃えました。タグ、シード、尺、キー、BPMも共通です。違うのはstepsとcfgだけになります。

Variant	Steps / CFG	生成時間
XL Turbo	8 / 1.0	25.8秒
XL Base	20 / 5.0	28.6秒
XL SFT	20 / 5.0	28.3秒

生成サンプルです。3本とも同じタグとシードで、上の表と同じ条件で出しています。

ACE-Step 1.5 XL Turbo 生成サンプル（30秒 / 8 steps / RTX 4090）

ACE-Step 1.5 XL Base 生成サンプル（30秒 / 20 steps / RTX 4090）

ACE-Step 1.5 XL SFT 生成サンプル（30秒 / 20 steps / RTX 4090）

steps を2.5倍にしても3秒しか変わりませんでした

turboは8 steps、baseとSFTは20 stepsです。step数は2.5倍違うのに、生成時間の差は3秒ほどしかありませんでした。

理由は、generate_audio_codes のLLMパスが実行時間の大半を占めていて、拡散のstep数が支配的ではないためです。

裏付けになる測定もあります。同じturboの8 stepsでも、text encoderを qwen_1.7b 単体にすると16.5秒でした。qwen_4b に変えただけで25.8秒です。encoder側が9秒ほどを占めている一方、steps 12本分の差は3秒ほど（1 stepあたり0.25秒程度）ということになります。

モチベル

じゃあ「turboだから速い」とは言えないんだ？

クーラット

短い尺だとencoderの固定コストが効いて差が出にくいんだよね。長尺やstepsを増やす条件なら差が出るはずだけど、そこはまだ測ってないよ。

以前の記事の数値について

この記事の以前のバージョンには、turbo 41.95秒 / SFT 63.41秒 / Base 66.51秒（2分音源）という数値を載せていました。turboだけtext encoderが qwen_1.7b 単体になっていて、比較として成立していませんでした。条件を揃えて測り直した上の表を見てください。

起動時間は日によって大きく変わります

Pod作成から生成できる状態になるまでの時間は、モデルのダウンロードが大半を占めます。そしてこのダウンロード速度が、Hugging Face側の状況で大きく振れました。

速いときはPod作成から約1分30秒で生成できる状態になりました。混んでいるときは、同じ構成で45分ほどかかったこともあります。同じ日のうちに、実効速度が約680MB/sから約11MB/sまで落ちたこともありました。

これはテンプレート側ではなくHugging Face側の事情なので、リージョンを変えても改善しませんでした。時間に余裕を持って触るか、遅いと感じたら一度Podを作り直すくらいの構えでいるとよさそうです。

コスト感

RunPodはPodの稼働時間に対して課金されます。生成処理そのものは30秒前後で終わりますが、実際にはモデルのダウンロード、ComfyUIの操作時間、idle timeもすべて課金対象です。

GPU単価とストレージ単価は変動しますし、選ぶGPUやリージョンでも変わります。Pod作成画面の右側に時間あたりの合計が出るので、Deployする前にそこを確認するのが確実です。

生成が終わったらPodを止める、という運用にしておけば、この手の検証で大きく使ってしまうことはないと思います。

つまずいたところ

大きなモデルを続けて積むと、コンテナごと落ちることがあります

base を回した直後に sft を実行したら、tracebackも出さずにコンテナが再起動しました。クリーンな状態なら sft 単体は通るので、variant側の問題ではありません。

最初はVRAM不足だと思っていましたが、違いました。ComfyUIと comfy-aimdo はホスト側のRAMを見ていて、コンテナに割り当てられた上限を見ていません。起動ログにこう出ます。

Total VRAM 24081 MB, total RAM 257566 MB
Enabled pinned memory 231809.0

ホストRAMの231GBを前提にpinned memoryを確保しようとするため、2本目の大きなモデルを積んだところでコンテナ側の上限を超えてOOM killされます。Wan2.2のテンプレートでも、2本目のエキスパートをロードした瞬間に同じ落ち方をしました。

同じ操作でも、引いたマシン次第で起きたり起きなかったりします。落ちたマシンは total RAM 257566 MB、通ったマシンは 515790 MB でした。

対処としては以下です。

Podを作ったら /system_stats の ram_total を確認する
モデルを切り替えるときは /free を挟む、またはPodを分ける
落ちたら、RAMの大きいマシンを引き直す

RAMが小さいマシンでは、/free を挟んでも2本目で落ちることがありました。variantを比較したいときは、Podを分けてしまうほうが確実です。

huggingface-cliがdeprecatedだった

最初は huggingface-cli download を使っていましたが、以下の警告が出ました。

Warning: huggingface-cli is deprecated and no longer works. Use hf instead.

そのため、hf download を使う形に変更しました。

text encoderを選択式にしたのをやめた

最初は qwen_1.7b だけでよいと思っていました。しかし、workflow templateによっては qwen_0.6b や qwen_4b も参照します。そこで ACESTEP_LM=all を標準にして、text encoder不足で止まりにくい構成にしていました。

ここには続きがあります。all で止まらなくなったので、そのまま運用していたんですが、あとから公式ワークフローを全部読み直したら、「参照することがある」ではなく必ず2本読む作りでした。1枠目は qwen_0.6b で固定、2枠目がbase / SFT / turboとも qwen_4b。つまり all 以外のどれを選んでも生成できない構成になっていたわけです。

RunPod Hub版はもっと直接的で、既定値が qwen_0.6b でした。何も変えずにデプロイすると動かない状態だったことになります。

気づけなかった理由もはっきりしていて、Hubのテストが health_check の1本だけだったからです。ComfyUIが起動して system_stats を返すかしか見ていないので、モデルの組み合わせが間違っていてもテストは緑になります。起動と生成は別物でした。

v3.4.0 で ACESTEP_LM を廃止して、qwen_0.6b と qwen_4b を常に入れる形にしました。あわせて、公式のturboワークフローを実際に実行して曲が出るところまで見るテストを追加しています。

追加したテストも最初は動かなかった

生成テストのsaveノードを、ローカルのComfyUIのスキーマを見ながら書いたら、format と quality の入れ子を取り違えていて、Hubのビルドで弾かれました。実行せずに書いたから間違えたわけで、そのテストが防ごうとしていたミスを、テスト自身でやってしまった形です。最終的にはPodへ直接POSTして、4.4秒・330KBのmp3が返るのを確認してから入れました。

80GB diskでは薄かった

diffusion model 3本とtext encoderを入れると、モデル本体だけでかなり容量を使います。cacheや一時ファイルも考えると、80GBでは余裕が薄かったため、Container Diskは100GBにしました。

v3.4.0 で qwen_1.7b を落とさなくなったぶん、all のモデル合計は 40.5 GiB から 37.1 GiB に減っています。100GBはそのままにしています。

RTX 5090はCUDA 12.4でcontainer createに失敗した

v1.0.0 の頃の話です。RTX 5090では、CUDA 12.4 imageがsetup scriptに入る前のcontainer create段階で失敗しました。そのため当時はCUDA 12.8版を別に用意していました。

v3.0.0 ではCUDA 12.4版自体がなくなったので、この使い分けは不要になっています。

使い終わったらPodを止める

音楽生成も、GPUを起動したままにすると料金が発生します。生成が終わったら、RunPod consoleでPodの停止または削除を確認してください。

生成した音声ファイルを残したい場合は、Podを停止または削除する前に必ずダウンロードしておきます。

StopとTerminateの違い

StopはGPU課金を止めますが、Container Diskのデータは消えます。Volume DiskやNetwork Volumeのストレージ料金は継続します。TerminateはPodを完全削除し、Container DiskとVolume Diskのデータも消えます。RunPodの料金体系の詳細はRunPod料金・クレジットガイドで解説しています。