Wan2.2をRunPodで動かす公開ComfyUIテンプレートを作りました｜T2V/I2Vを検証

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

要約

Wan2.2をRunPod上のComfyUIで動かすために、公開用のRunPodテンプレートを作りました。

2026年8月にテンプレートを v3.2.0 まで更新して、ComfyUIを 0.32.0 に上げ、CUDA 12.8版とCUDA 13.0版の2本立てにしています。

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

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

この記事では、公開テンプレートの使い方、テンプレートの中身、CUDA 12.8を既定にした理由、RTX 4090でT2V / I2V / TI2Vを動かした実測をまとめます。

はじめに

Wan2.2をRunPodで試そうとすると、モデル容量、ComfyUIの依存関係、LoRA、workflowのmissing modelなど、地味に準備が多いです。

そこで、Wan2.2用のComfyUI環境をすぐ起動できるRunPodテンプレートとしてまとめました。

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

Wan2.2用ComfyUIテンプレートの構成

作ったのは、Wan2.2を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...

github.com

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

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

Start Commandはシンプルにしています。

/opt/runpod/start.sh

image build時に、OS package、ComfyUI、Python dependenciesを入れておき、Pod起動時には必要なモデルをダウンロードしてComfyUIを起動するだけにしています。

モデルはimageに含めていません。imageが巨大化しすぎることと、モデル配布やライセンスの扱いを重くしないためです。

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

まず試すなら、CUDA 12.8版の ComfyUI-Wan2.2-cuda12.8-v3-FreeCraftLog を使います。

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

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

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

freecraftlog.com

2026.03.10

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

項目	推奨値
Template	ComfyUI-Wan2.2-cuda12.8-v3-FreeCraftLog
Container Disk	100 GB
Volume Mount Path	/workspace
Ports	8188/http, 22/tcp
Start Command	/opt/runpod/start.sh
WAN_VARIANT	t2v_a14b

Container Diskは、以前は200 GBを推奨していました。実測してみたところそこまで要らなかったので、2026年8月31日に100 GBへ下げています。

container imageはcontainer diskを消費しません。モデルをダウンロードする前の df -h / が 200G 60K 200G 1% で、container diskが持っているのは /workspace 以下の書き込み分だけでした。RunPodのドキュメントはcontainer diskを「OSやインストール済みパッケージを含むコンテナのファイルシステム」と説明しているので、ここは誤解しやすいところですね。

実際に積み上がるのはモデルのほうです。start.sh は WAN_VARIANT を切り替えても古いモデルを消さないので、使うほど増えていきます（RTX 4090 / 2026年8月31日の実測）。

使い方	累積
1 variantのみ	35.4 GB
t2v_a14b → i2v_a14b	64.3 GB
3 variantすべて	74.9 GB

WAN_VARIANTは、使いたいWan2.2の種類に合わせて変えます。

Value	用途
t2v_a14b	text-to-video 14B。既定値
i2v_a14b	image-to-video 14B
ti2v_5b	text/image-to-video 5B

v3.1.0 で環境変数が2つ増えています。どちらも既定のままで動くので、必要になったときだけ触ってください。

Name	Default	説明
COMFY_PINNED_MEMORY	auto	pinned memoryの扱い。auto はコンテナのメモリ上限をcgroupから読んで、ホストRAMより明らかに小さければ自動で無効化します。on で常に有効、off で常に無効
COMFY_EXTRA_ARGS	未設定	ComfyUIに渡す追加引数。--lowvram、--fast-disk、--cache-none、--reserve-vram 2 など。空白区切りで複数指定できます

COMFY_PINNED_MEMORY が何をしているかは、後述の「大きなモデルを続けて積むと、コンテナごと落ちることがあります」とあわせて読むと分かりやすいと思います。

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

まずはCUDA 12.8版を使ってください。CUDA 13.0版は、CUDA 13.0対応のGPUを選んで使う場合の選択肢です。

v2.0.0 まではCUDA 12.4版を既定にしていましたが、v3.0.0 で廃止しました。ComfyUI 0.32.0 が要求する comfy-kitchen がPyTorch 2.5以上を前提としていて、CUDA 12.4ベースのPyTorch 2.4系ではComfyUI自体が起動しなくなったためです。

新しいCUDAのimageほど、動くホストは狭くなります

ここは直感と逆になるところなので、少し詳しく書きます。

NVIDIAのCUDA imageは、NVIDIA_REQUIRE_CUDA という指定でホスト側ドライバのCUDAバージョンを要求します。条件を満たさないホストでは、ComfyUIどころかコンテナが起動する前に失敗します。

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

つまり、CUDA 12.8版のほうが起動できるホストが広いです。僕は最初これを逆に理解していて、CUDA 13.0版を既定にしようとしていました。実機で条件を満たさないホストを引いて、以下のエラーで止まって気づきました。

nvidia-container-cli: requirement error: unsatisfied condition: cuda>=13.0,
please update your driver to a newer version, or use an earlier cuda container

RunPodでは、同じGPUを選んでも割り当てられるホストのCUDAバージョンが毎回同じとは限りません。RTX 4090をUS-NC-1で6回引いたところ、CUDA 13.0のホストに当たったのは2回でした。残りは12.4と12.8です。

CUDA 13.0版を使いたい場合は、GPU選択画面の Available CUDA versions を見て、13.0しか持たないGPUを選ぶのが確実です。検証時は NVIDIA RTX PRO 4500 Blackwell（32GB）が13.0のみで、一度で確保できました。このGPUでCUDA 13.0版を起動して、生成まで問題なく通っています。

テンプレートの仕組み

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

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

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

Pod起動時にすべてをセットアップすると、起動時の失敗要因が増えます。そこで、ComfyUI本体や依存関係はimage build時に済ませ、Pod起動時はモデルdownloadとComfyUI起動に寄せました。

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

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

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

1. /workspace/models/wan22、/workspace/logs、/workspace/outputs を作成
2. sshdを起動
3. WAN_VARIANT に応じて必要なWan2.2モデルをダウンロード
4. 必要なLightX2V LoRAをダウンロード
5. /opt/ComfyUI/models/* へsymlink
6. 0.0.0.0:8188 でComfyUIを起動

ComfyUIの起動は以下の形です。

python main.py --listen 0.0.0.0 --port "${COMFY_PORT}" --output-directory "${OUTPUT_DIR}"

RunPod上でComfyUIを開いた後の基本操作は、RunPodでComfyUIを使う方法でも整理しています。

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

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

経路	v1.0.0	v3.0.0
direct <ip>:<port>	Connection refused	接続できる
proxy ssh.runpod.io	Permission denied (publickey)	—

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

[start] sshd started

Hugging Face tokenは必須ではないが推奨

Wan2.2のComfyUI repackaged modelはpublicなので、HF_TOKENなしでもダウンロードできます。

ただし、大容量モデルを扱うため、未認証アクセスではrate limitやダウンロード速度の面で不利になる可能性があります。

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

つまずいた点と対処

RunPod proxyの403は、いまは出ません

v1.0.0 の頃は、Pod内でComfyUIが正常に起動しているのに、RunPod proxy URLから開くと403になることがありました。

RunPodのproxy URLは以下のような形式です。

https://<pod-id>-8188.proxy.runpod.net

当時はComfyUI側のcross-site request protectionに当たっていると考えて、起動オプションに --enable-cors-header "*" を足して開けるようにしていました。

このオプションは v2.0.0 で外しています。外したあとに v3.0.0 の実機で確認したところ、proxy URLへのGETは200で、ブラウザでComfyUIのUIも問題なく表示されました。CORSヘッダなしで開けています。

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

CORSより気にしたほうがいいのは、こちらだと思っています。

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

扱う内容によっては、8188/http を開かずにSSH port forward経由で使うほうが安全です。

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

これで手元のブラウザから http://localhost:8188 を開けます。

proxy経由でスクリプトからAPIを叩くと403になりました

ブラウザでは開けるのに、Pythonのスクリプトから同じproxy URLへ POST /prompt すると403が返ってきました。

これはComfyUIのCORSではなく、RunPod proxyの前段にいるCloudflareがUser-Agentで弾いていました。urllib の既定UAである Python-urllib/3.x が対象です。

ブラウザ相当のUser-Agentを付ければ通ります。

headers = {"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) ..."}

curl は既定のUser-Agentで通ってしまうので、curlで叩くと再現しません。ブラウザでもcurlでも動くのにPythonからだけ落ちる、という状態になって、切り分けに時間がかかりました。

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

1つのPodでモデルを切り替えながら回していると、tracebackも出さずにコンテナが再起動することがありました。Wan2.2では、2本目のエキスパートをロードした瞬間に再現しています。

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されます。

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

v3.1.0 からは、ここをテンプレート側で処理するようにしました。start.sh がcgroupからコンテナのメモリ上限を読んで、ホストRAMの80%を明らかに下回っていれば、ComfyUIに --disable-pinned-memory を付けて起動します。読者側で何かする必要は、通常はありません。

自動で無効化されたときは、起動ログにこう出ます。

[start] memory: container limit 38GB / host 125GB
[start] container limit is well below host RAM, disabling pinned memory
[start] set COMFY_PINNED_MEMORY=on to keep it enabled

挙動を自分で決めたい場合は、環境変数 COMFY_PINNED_MEMORY を使ってください。既定は auto で、on なら常に有効、off なら常に無効になります。なお v3.2.0 では、cgroupが「上限なし」を巨大な数値で返す環境で、この行の表示が桁の狂った値になっていたのを直しています。

この記事のサンプル動画は、この自動対処が入る前に撮ったものです。T2VとI2Vを回したマシンではhigh / lowのエキスパートを一度に積めなかったので、latentを保存して2回のプロンプトに分けて実行しました。動画自体は問題なく出せていますが、生成時間を秒単位で出していないのはこのためです。v3.1.0 以降は同じ手順を踏む必要はないはずですが、測り直してはいません。

バージョンを固定していても、ビルドした日で中身が変わりました

v2.0.0 が起動しなくなった原因がこれでした。

ComfyUIのバージョンは COMFYUI_REF=v0.19.3 で固定していました。それでも、5月にビルドしたimageは動いて、8月にビルドしたimageは起動しなくなりました。

ComfyUIの requirements.txt が comfy-kitchen>=0.2.8 のような範囲指定になっていたためです。固定しているのはComfyUI本体だけで、その先の依存はビルドした日の最新に動きます。

ValueError: infer_schema(func): Parameter kernel_size has unsupported type list[int]

ComfyUI 0.32.0 は comfy-kitchen==0.2.30 と == で固定しているので、v3.0.0 ではこの形の壊れ方はしません。

missing modelを潰した話

最初にT2V-A14Bを動かしたとき、workflow側からLightX2V 4-step LoRAがmissing modelとして出ました。

不足していたのは以下です。

wan2.2_t2v_lightx2v_4steps_lora_v1.1_high_noise.safetensors
wan2.2_t2v_lightx2v_4steps_lora_v1.1_low_noise.safetensors

T2Vの高速化workflowで必要になるため、t2v_a14b variantで一緒にダウンロードするようにしました。

I2Vでも、I2V用のLightX2V LoRAを追加しています。

wan2.2_i2v_lightx2v_4steps_lora_v1_high_noise.safetensors
wan2.2_i2v_lightx2v_4steps_lora_v1_low_noise.safetensors

さらにI2Vでは、最初に fp16 版を落としていましたが、実際のworkflowは fp8_scaled 版を要求していました。

そのため、I2V-A14Bは以下へ切り替えました。

wan2.2_i2v_high_noise_14B_fp8_scaled.safetensors
wan2.2_i2v_low_noise_14B_fp8_scaled.safetensors

この修正後、missing modelなしでworkflowを実行できる状態になりました。

動作確認と実測

v3.0.0 の全variantで、RTX 4090を使って生成まで確認しました。ComfyUI 0.32.0 / comfy-kitchen 0.2.30 / comfy-aimdo 0.4.13 です。

variant	生成設定	生成時間
t2v_a14b	832×480 / 81f（5秒 / 16fps）/ 4 steps	およそ1分強
i2v_a14b	832×480 / 81f（5秒 / 16fps）/ 4 steps	およそ1分強
ti2v_5b	1280×704 / 121f（5秒 / 24fps）/ 20 steps	193.7秒

t2v_a14b と i2v_a14b は、LightX2V 4-step LoRAをhigh / lowの両方に当てる公式構成で回しています。

14Bの2つは秒単位の数字を出していません。このときのマシンはRAMに余裕がなく、high / lowのエキスパート2本を一度に積めなかったため、latentを挟んで2回のプロンプトに分けて実行しているためです。分割して測った合計はマシン依存の値になるので、「5秒の動画で1分強」くらいの粒度で見てください。分割が必要になった理由は、後述の「大きなモデルを続けて積むと、コンテナごと落ちることがあります」で書いています。

ti2v_5b の193.7秒は分割なしで通っています。ただし1280×704の121フレームと重い条件なので、そのぶん時間がかかっています。

生成サンプル

まずT2V-A14Bです。テキストだけから5秒の動画を作っています。

次にI2V-A14Bですが、入力画像には上のT2Vで作った動画の最終フレームを使いました。

これで、T2Vで作ったカットの続きをI2Vで伸ばす、という使い方になります。

最後にTI2V-5Bです。5Bモデルなので14Bより軽く、そのぶん解像度とフレームレートを上げています。

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

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

同じ日、同じ構成で測っても以下のとおりです。

時刻 (UTC)	内容	実効速度
02:0x	約36GB / 53秒	約 680 MB/s
03:0x〜03:4x	6.7GB / 10分14秒	約 11 MB/s

速いときはPod作成から約1分30秒で生成できる状態になりました。混んでいるときは45分ほどかかったこともあります。

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

v3.2.0 でimageを小さくしました

ベースイメージをCUDAの devel から runtime に変えて、image sizeが 10.10GB → 4.81GB（52%減）になりました。nvccやヘッダはimage build後のComfyUIが使わないので、落としても動きます。

v3.2.0 のPod起動を1本測った内訳です（RTX 4090 / EUR-IS-1 / t2v_a14b）。

段階	所要
imageのpull + 展開	4分27秒（実効 約25 MB/s）
モデルのダウンロード	約50秒
ComfyUI起動	12秒
合計	5分28秒

このときは、モデルのダウンロードよりimageの取得のほうが長くかかっていました（全体の81%）。そこを削ったのが今回の変更です。

ただし、サイズと時間は比例しません。同じ日の観測で、サイズが52%減ったのに対してpullは30%減にとどまりました。runtime imageはレイヤの枚数が少なく（11枚 vs 34枚）、ダウンロードは並列化できても大きなレイヤの展開は直列になるためです。

pull速度自体もデータセンターで数倍振れます。同じ日・同じimage（4.81GB）でも、別のPodでは4分01秒でした。なので「imageを小さくしたので起動が何分速くなる」という書き方はできません。速ければ数分、混むと30分以上かかることがある、くらいの幅で見ておくのがよさそうです。

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

動画生成系の処理は、GPU利用時間が伸びやすいです。検証が終わったら、RunPod consoleでPodを停止または削除してください。

ComfyUIはHTTP proxyで外から開ける状態になるため、使わないPodを長時間起動したままにしないほうが安全です。

まとめ

Wan2.2用のRunPodテンプレートは、v3.2.0 で以下の構成になりました。

• ComfyUIは 0.32.0。依存は comfy-kitchen 0.2.30 などに固定されている
• CUDA 12.8版を既定にする。動くホストが広いため
• CUDA 13.0版は、Available CUDA versions が13.0のGPUを選んで使う
• ComfyUIはimage build時に /opt/ComfyUI へclone
• モデルは WAN_VARIANT に応じて必要分だけdownload
• LightX2V LoRAもvariantごとに配置
• I2Vはworkflowに合わせて fp8_scaled 版を使う
• sshdを起動するので、direct SSHで入れる

単にComfyUIが開くだけでなく、workflowのmissing modelを潰して、T2V / I2V / TI2Vで生成まで確認した状態です。同じ構成で試す場合は、公開テンプレートからDeployするのが早いです。ConoHa AI CanvasでWan2.2を試す場合はConoHa AI Canvas Wan2.2動画生成記事も参考にどうぞ。

関連記事

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

ACE-Step 1.5 XLをRunPod上のComfyUIで動かす公開テンプレートをv3.0.0に更新。base/SFT/turbo、qwen text encoder、CUDA 12.8と13.0の使い分け、RTX 4090での生成時間、つまずいた点まで実録でまとめます。

freecraftlog.com

2026.05.31

RunPodでComfyUIを使う方法｜モデル追加・ワークフロー実行・画像保存まで解説

RunPodでComfyUIを起動した後、何をすればいいか迷う人向け。最初の設定からモデル・LoRA・VAEの配置場所、ワークフローJSONの読み込み、画像生成と保存、Pod停止、よくあるエラー対処まで実際の画面で全手順を解説します。起動直後に何から手をつければいいか迷わないための実用ガイドです。

freecraftlog.com

2026.05.20

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

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

freecraftlog.com

2026.03.10

ConoHa AI CanvasでWan2.2動画生成を試した結果｜T2V・I2V・TI2Vの実行メモ

ConoHa AI CanvasのComfyUIでWan2.2動画生成テンプレートを実測検証。TI2V、T2V、I2Vの実行結果、生成時間、LoRAが必要だった点、初心者が最初に試しやすいテンプレート、YouTubeの生成動画リンクまでまとめます。

freecraftlog.com

2026.05.07