P-H3-ImageをVRAM 16GBで動かす｜ComfyUIで8MP生成、RTX 5080・5060 Tiの実測とw4a8・int8の選び方

P-H3-ImageはVRAM 16GBで動くか

VRAM 16GB の RTX 5080 と RTX 5060 Ti のどちらでも、P-H3-Image の 8MP (2912×2912) の生成は最後まで通った。2本目の時間は RTX 5080 で 21.0秒 (w4a8) / 20.7秒 (int8)、RTX 5060 Ti で 39.4秒 / 40.9秒だった。本体 (拡散モデル) のファイルは w4a8 と int8 の2種類を試し、16GB のカードでは、速さとメモリで見て w4a8 の本体から始めやすい。

Windows 11 で ComfyUI 0.44.0 を、VRAM の扱いや計算の精度を変える起動オプションを付けずに動かし、w4a8 と int8 のどちらの本体でも止まらずに画像が出た。この答えの元にしたのはテキストから画像を作る正方形の生成で、各条件2本ずつ生成し、1本目はモデルの読み込みを含む。測定機のメインメモリは 96GB。測定日は2026年11月6日。

配布元は、いちばん軽い w4a8 の一式 (VAE は int8) でも、8MP の生成で VRAM のピークが 21GB になると書いている。この値を見ると 16GB のカードでは動かないように読めるが、測った2枚では最後まで通った。生成の間に共有 GPU メモリがほとんど増えなかったのは w4a8 の本体で、大きく増えたのは int8 の本体だった。メモリの使われ方は、生成時間とメモリの節に表でまとめた。

VRAM が足りていても、GPU の世代で使えないことがある。配布元によると、int8 と w4a8 の量子化ファイルは comfy-kitchen の INT8 カーネルで動き、NVIDIA の Ampere 以降か、AMD の RDNA3 / RDNA4 が要る。bf16 の一式についてはこの条件は書かれていない。この記事で測ったのは NVIDIA の2枚だけだ。

P-H3-Image の元になった動画モデルを 16GB で動かした結果は「MiniMax H3をVRAM 16GBで動かす｜ComfyUIでの導入手順とRTX 5080・5060 Ti実測」で読める。16GB のカードで動く別の画像生成モデルを探しているなら、Qwen-Image 2.1 を VRAM 16GB で動かした記事も比べる材料になる。

P-H3-Imageとは

P-H3-Image は、Pruna AI が MiniMax H3 を元に作った、テキストからの画像生成と画像の編集のためのモデルだ。配布元は「8MP の画像を CFG なしの8ステップで描く」と書いている。

ComfyUI では、2026年11月4日に GitHub のリリースページで公開された v0.44.0 のリリースノートに「Support PH3Image」という変更が入っている。P-H3-Image を使うには ComfyUI を 0.44.0 以降にする。本体だけでなく、使っている配布形態の手順どおりに依存パッケージも更新する (この記事の環境は comfy-kitchen 0.2.40・comfy-aimdo 0.6.0)。この記事の測定もこのバージョンで行った。配布元の Hugging Face のページには workflows/ のフォルダがあり、テキストからの生成は p-h3-image_text_to_image.json、編集は p-h3-image_edit.json のワークフローが入っている。同じ ComfyUI 0.44.0 で MiniMax H3 側に入った機能は「MiniMax H3をVRAM 16GBで速くする｜latent upscaler・context windows・軽いVAEはどれを使うか」にまとめた。

配布元が推奨する設定は次のとおりと書かれている。

• 解像度は、テキストからの生成が 8MP (正方形なら 2912×2912)、編集が 4MP か 8MP (4MP の正方形は 2048×2048)
• サンプラーは euler、ManualSigmas で8ステップ
• ネガティブプロンプトは使わない

P-H3-Image の重みは MiniMax H3 Community License で配られている。配布元によると、テキストエンコーダのうち Qwen3-VL-4B の部分と、Qwen3.5-9B が元のプロンプト拡張は Apache License 2.0 だ。MiniMax H3 Community License の対象地域からは欧州連合・英国・韓国・米国が外されていて、MiniMax から別のライセンスを受けない限り、これらの地域でモデルや生成した画像を使う・複製する・配布する・表示することは認められていない (V.4)。生成する場所だけでなく、画像を公開・配布する先も確かめておきたい。

配布元の説明には、このモデルを使った製品に「Powered by MiniMax H3」の表示が要るとあるが、ライセンス本文ではこの表示は推奨になっている。商用で使うときにライセンス本文が求めているのは、商用の製品・サービスの画面に「MiniMax H3」と目立つように表示することと、商用の製品・サービスの年間の売上が 2,000 万米ドルを超える場合に MiniMax から事前に書面の許可を得ること。このほか、再配布や、第三者に生成のサービスを出すときにも条件があり、モデルや生成した画像を MiniMax H3 とその派生モデル以外の AI モデルの改良に使うことは禁じられている (V.3)。ライセンスに含まれる利用規定では、生成した画像を公開の場に出すときは、機械で生成したものだとはっきり示すことになっている。ComfyUI の公式ドキュメントは、商用で使うなら Comfy を通してライセンスを申請するよう案内しているが、ライセンス本文にはこの手続きの記載が見つからない。ライセンス本文と ComfyUI のドキュメントの該当ページは参考資料に載せた。商用で使うなら、公開の前に権利元か Comfy に確かめておきたい。

配布されているファイルとこの記事で使った構成

配布元は、精度の違う3つの一式 (bf16・int8・w4a8) を用意している。配布元の表では、8MP の生成での VRAM のピークが bf16 の一式で 56GB、int8 の一式で 31GB、w4a8 の一式 (VAE は int8) で 21GB と書かれている。ダウンロードの量は順に 55GB・30GB・20GB で、これは本体・テキストエンコーダ・VAE の合計。プロンプト拡張は別に要る。どの GPU で測った値かは書かれていない。

この記事では、この中から5つのファイルを組み合わせて使った。使ったファイルと大きさを、構成表にまとめる。

役割	ファイル名	大きさ
本体 (w4a8)	p-h3-image_w4a8.safetensors	13.4GB
本体 (int8)	p-h3-image_int8_convrot.safetensors	21.2GB
テキストエンコーダ (w4a8)	p-h3-image_text_encoder_w4a8.safetensors	3.6GB
プロンプト拡張 (w4a8)	p-h3-image_prompt_upsampler_w4a8.safetensors	6.7GB
VAE (int8)	p-h3-image_vae_int8_convrot.safetensors	3.1GB

構成表のファイルは Hugging Face の PrunaAI/P-H3-Image-Comfy から取得したもので、大きさはファイルのバイト数を GB (10の9乗) で表した値。

本体は w4a8 と int8 の2種類を入れ替えて測り、テキストエンコーダとプロンプト拡張は w4a8、VAE は int8 を、どちらの本体でも共通に使った。

VRAM 16GB のカードで最初に落とすのは、本体 w4a8 (13.4GB)・テキストエンコーダ w4a8 (3.6GB)・VAE int8 (3.1GB) の3つで、合計は約 20.1GB。置き場所は、本体が ComfyUI/models/diffusion_models、テキストエンコーダとプロンプト拡張が ComfyUI/models/text_encoders、VAE が ComfyUI/models/vae。int8 の本体は、w4a8 と比べたいときや、配布元が bf16 に近いと書く int8 の画像を試したいときに足す。

配布元のワークフローは、読み込みのノードが bf16 のファイルを選んだ状態で入っているので、開いたら落としたファイルに選び直す。ワークフローはどれもプロンプト拡張を通す作りで、配布元のワークフローを使うなら拡張のファイル (w4a8 で 6.7GB、4つ合わせて約 26.8GB) も置く。拡張を使わないなら、ワークフローの Use prompt upsampler を false にすると、拡張を通さずに依頼文が本体へ渡る。ただし ComfyUI は実行の前に、つながっているノードが指すファイルが置いてあるかを確かめるので、拡張のファイルを置かずに false にすると、拡張の読み込みのノードで止まる場合がある (ComfyUI 0.44.0 の実装からの見立てで、試してはいない)。false で使うときも、拡張のファイルは置いておくのが確実だ。この記事の拡張なしの測定は拡張のノードを入れないグラフで行っていて、false にした配布元のワークフローは試していない。

RTX 5080・5060 Tiでの生成時間とメモリ

4MP (2048×2048) と 8MP の両方で、2枚の GPU と2種類の本体を組み合わせた8条件を測った。時間とメモリの実測表で、条件ごとの1本目・2本目の時間と、メモリのピークを見る (どの区間の値かは表の下に書いた)。

解像度	本体	GPU	1本目	2本目	VRAMのピーク	共有GPUメモリのピーク	メインメモリ (作業セット) のピーク
4MP (2048×2048)	w4a8	RTX 5080	12.1秒	9.3秒	15,413MiB	556MiB	5.8GiB
4MP (2048×2048)	w4a8	RTX 5060 Ti	23.6秒	16.4秒	14,910MiB	272MiB	5.5GiB
4MP (2048×2048)	int8	RTX 5080	12.9秒	9.9秒	15,345MiB	7,503MiB	10.8GiB
4MP (2048×2048)	int8	RTX 5060 Ti	22.6秒	16.9秒	14,920MiB	6,744MiB	10.0GiB
8MP (2912×2912)	w4a8	RTX 5080	22.0秒	21.0秒	15,342MiB	661MiB	6.1GiB
8MP (2912×2912)	w4a8	RTX 5060 Ti	43.1秒	39.4秒	14,920MiB	272MiB	5.7GiB
8MP (2912×2912)	int8	RTX 5080	22.6秒	20.7秒	15,377MiB	7,570MiB	11.0GiB
8MP (2912×2912)	int8	RTX 5060 Ti	45.0秒	40.9秒	14,908MiB	6,891MiB	10.3GiB

測定の構成は ComfyUI 0.44.0 / PyTorch 2.14.0+cu130 / テキストエンコーダ w4a8・VAE int8・プロンプト拡張なし / euler・8ステップで、各条件2本 (1本目はモデルの読み込みを含む)。VRAM と共有 GPU メモリは2本目の間のピーク、メインメモリ (作業セット) は ComfyUI を起動してから2本目が終わるまでのピークで、1本目のモデルの読み込みを含む。どれも一定の間隔で取った値の最大で (VRAM は nvidia-smi で約0.5秒ごと、共有 GPU メモリは約1秒ごと、プロセスのメモリは0.25秒ごと)、間に挟まった短い山は取りこぼしうる。VRAM のピークはカード全体の使用量の最大値で、RTX 5080 は画面出力にも使っているので、その分を含む。共有 GPU メモリは Windows のパフォーマンスカウンタ (GPU Adapter Memory の Shared Usage) の値、メインメモリは ComfyUI のプロセスの作業セット (物理メモリに載っている分)。

2本目の時間を条件ごとに並べると、生成時間の図のようになる。

8MPは2枚とも通り、RTX 5060 Tiは2倍近くかかる

8MP は RTX 5060 Ti を含む2枚のどちらでも、w4a8 と int8 の両方の本体で最後まで通った。同じ条件の2本目どうしで比べると、RTX 5060 Ti は RTX 5080 の約1.7〜2.0倍の時間がかかった。この倍率は、拡張なしの4条件 (4MP・8MP × w4a8・int8) の2本目から出したもの。RTX 5080 は PCIe 5.0 x16、RTX 5060 Ti は OCuLink 経由の PCIe 4.0 x4 でつないでいて、この倍率には GPU の差と接続の差の両方が入っている (どちらがどれだけかは分けていない)。

1本目はモデルの読み込みなどの初回の処理を含み、どの条件でも2本目より長かった。2本目はテキストの条件付けなどの結果もキャッシュから使うので、この差はモデルの読み込みの時間だけではない。OS のファイルキャッシュも消していないので、ディスクから初めて読む時間とも限らない。条件ごとに ComfyUI を起動し直して測っていて、たとえば w4a8 の 4MP では、RTX 5080 が 12.1秒 (2本目 9.3秒)、RTX 5060 Ti が 23.6秒 (2本目 16.4秒) だった。ComfyUI を起動して最初の1枚は、2本目より待つ時間が延びる。

VRAMはほぼ埋まり、int8の本体は共有GPUメモリを大きく使う

どの条件でも VRAM のピークは 14,908〜15,413MiB で、16GB のカードの9割以上が使われた。共有 GPU メモリ (GPU からも使えるメインメモリの領域) のピークは、w4a8 の本体で 272〜661MiB、int8 の本体で 6,744〜7,570MiB だった。ComfyUI のプロセスのメインメモリ (作業セット) のピークは、w4a8 で 5.5〜6.1GiB、int8 で 10.0〜11.0GiB。

この共有 GPU メモリの値は GPU 全体のカウンタで、生成を始める前から使われている分を含む。各回の最初に取った値からの増え方で見ると、w4a8 の本体では1本の生成の間に最大で約 220MiB、int8 の本体 (21.2GB) では1本目の生成の間に約 6,500〜7,100MiB 増えた。測定時の ComfyUI は、起動ログで DynamicVRAM と非同期のオフロードが有効と出ていて、このカウンタだけでは、モデルがどこまで VRAM に載っていたかや、メインメモリとの間でどれだけ転送したかは分からない。

この VRAM のピークはカード全体の使用量で、P-H3-Image を動かすのに要る最小の量ではない。配布元の 21GB とは測り方が同じか確かめておらず、差の理由は分かっていない。測定機のメインメモリは 96GB で、ComfyUI のプロセスのコミット量 (確保を約束したメモリの量) のピークは、w4a8 で約 20〜21GiB、int8 で約 26〜27GiB だった。作業セットもコミット量も、PC に要るメインメモリの量そのものではない。メインメモリが 32GB 以下の PC では測っていないので、とくに int8 の本体ではメインメモリに余裕を見ておきたい。

VRAM に載りきらない分をメインメモリへ逃がす仕組みと、ComfyUI の起動オプションで何が変わるかは「ComfyUIの起動オプション実測ガイド｜dynamic VRAM時代のVRAM設定」で詳しく測っている。

w4a8とint8の本体はどちらを使うか

速さはほぼ同じで、int8はメモリとファイルが重い

2本目の時間で比べると、int8 の本体が w4a8 より速かったのは RTX 5080 の 8MP の 0.3秒だけで、ほかの3条件は w4a8 より遅かった。2本目は各条件1本なので、この程度の差はばらつきの範囲かもしれない。

一方で int8 の本体は、共有 GPU メモリのピークが 6,744〜7,570MiB に達し、メインメモリ (作業セット) のピークも w4a8 より約4.5〜5.0GiB 多い。ファイルも 21.2GB と、w4a8 の 13.4GB より大きい。

速さで目立つ差は無く、メモリとダウンロードの負担は増えるので、16GB のカードでは w4a8 の本体から始めやすい。この判断は、テキストエンコーダ w4a8・VAE int8 の構成で、正方形の 4MP と 8MP を各2本測った範囲のもので、画像の質は判断に入れていない。配布元は、int8 の一式は bf16 にごく近く、ほぼ画素単位で一致することも多い一方、w4a8 の一式は品質を保ちながらも細部が変わり、構図が変わることもあると書いている。この記事は bf16 の出力を測っておらず、画像の良し悪しは比べていない。

本体の精度やGPUを変えると、同じseedでも画像は一致しなかった

同じ seed で作った2枚がどれだけ同じ画像になるかを、PSNR で比べた。PSNR の比較表は、同じ seed の出力どうしを RGB 8bit・全画素で比べた値を並べている。

比べた2枚	seed 12345	seed 12346
w4a8 と int8 (RTX 5080・4MP)	14.8dB	15.2dB
w4a8 と int8 (RTX 5080・8MP)	15.5dB	14.9dB
w4a8 と int8 (RTX 5060 Ti・4MP)	13.5dB	15.5dB
w4a8 と int8 (RTX 5060 Ti・8MP)	14.3dB	13.9dB
RTX 5080 と RTX 5060 Ti (w4a8・4MP)	17.1dB	20.6dB
RTX 5080 と RTX 5060 Ti (w4a8・8MP)	16.6dB	19.1dB
長いプロンプトの直接入力 と 短い依頼文の拡張 (RTX 5080・w4a8・8MP)	9.2dB	10.4dB

PSNR は2枚の画素の差から出す指標で、構図の似かたや画像の良し悪しを直接表すスコアではない。bf16 の出力は測っていない。

w4a8 と int8 の本体の出力は、同じ seed でも PSNR が 13.5〜15.5dB で、同じ画像にはならなかった。目で見た範囲 (RTX 5080 の w4a8 と int8、RTX 5060 Ti の w4a8 の 4MP) では、構図・人物・傘・提灯は同じで、提灯や看板の位置と形が少しずつ違った。破綻は無く、4MP では看板の文字が崩れるのも3枚とも同じだった。bf16 の出力を測っていないので、w4a8 と int8 のどちらが元のモデルに近いかは言えない。

本体が同じでも、RTX 5080 と RTX 5060 Ti の出力は一致しなかった。同じ w4a8 の本体・同じ seed で、2枚の出力どうしの PSNR は 16.6〜20.6dB だった (4MP・8MP と seed 2つの組み合わせの4組)。同じカードで同じ seed を2回回して一致するかは測っていないが、seed を控えておいても、別のカードで同じ画像になるとは限らない。

プロンプト拡張を使うと何秒増え、画像はどう変わるか

配布元のワークフローには、短い依頼文から詳しいプロンプトを書き起こすプロンプト拡張 (prompt upsampler、Qwen3.5-9B が元) が入っている。配布元は、P-H3-Image はプロンプトに敏感で、短い依頼より、具体的に書き込んだプロンプトのほうがずっとよく描くと書いている。一方で、誇張した語や非常に長いプロンプトは画像を悪くするとも書き、拡張をグラフに残す使い方を勧めている。配布元のワークフローはどれも拡張を通す作りだ。

配布元の説明では、拡張は貪欲法で生成し、出力はキャッシュされる。スイッチ Use prompt upsampler を false にすると、依頼文がそのまま本体へ渡る。拡張のピーク VRAM は、配布元の値で bf16 が約21GB、int8 が約12GB、w4a8 が約9GB とされている。配布元が勧めるのは bf16 の拡張で、量子化すると書き起こすプロンプトも変わり、w4a8 は bf16 との差がいちばん大きいとしている。小さいファイルは 21GB に収まらないときだけ使うよう書かれていて、この記事では VRAM 16GB のカードで試すため w4a8 の拡張を使った。

時間は新しい依頼文のときに増える

本体 w4a8・8MP に w4a8 のプロンプト拡張を入れ、短い英文の依頼文1つで各 GPU 2本ずつ生成した。拡張の設定は配布元のワークフローと同じで、thinking を有効にし、貪欲法 (sampling_mode は off)・max_length 2048 で生成した。拡張ありの時間表で、拡張のノードの時間と、拡張なしとの差を見る。

GPU	拡張あり 1本目	うち拡張のノードの時間	拡張あり 2本目	拡張なし 2本目 (比較)	生成されたプロンプト	メインメモリ (作業セット) のピーク
RTX 5080	28.3秒	4.3秒	22.1秒	21.0秒	909字	7.2GiB
RTX 5060 Ti	50.4秒	6.4秒	40.2秒	39.4秒	924字	7.0GiB

2本目は同じ依頼文なので、拡張の出力はキャッシュから使われた (拡張のノードは動いていない)。拡張のノードの時間は TextGenerate の実行時間で、拡張のファイルを読み込むノードの時間は入っていない。拡張なしの値は、同じ GPU・w4a8・8MP・拡張なしの2本目。拡張ありと拡張なしでは本体へ渡るプロンプトの中身も長さも違うので、総時間の差は拡張の処理だけの差ではない。

拡張ありの2本目は、拡張なしの2本目とほとんど変わらなかった。同じ依頼文・同じ設定の2本目では拡張のノードがキャッシュから使われて動かなかったので、依頼文などの入力や設定を変えたときや、キャッシュが消えたときには、また拡張のノードの時間がかかると考えられる。この記事で測ったのは依頼文1つの1本目 (RTX 5080 で 4.3秒、RTX 5060 Ti で 6.4秒) で、別の依頼文に変えて測り直してはいない。配布元は L40S で w4a8 の拡張に1プロンプト約11秒と書いていて、依頼文によって変わりうる。メインメモリ (作業セット) のピークは、拡張なしの同じ条件より 1.1〜1.3GiB 多かった。

画像の違いには入力の違いが出た

拡張ありの画像は、拡張なしの画像と大きく違い、同じ seed どうしの PSNR は 9.2dB / 10.4dB だった。ここでの拡張なしは、拡張に通す短い依頼文とは別の、具体的な長い英文のプロンプトをそのまま本体へ渡したものだ。

目で見ると、拡張ありでは歩く人物が着物ではなくコートを着て鞄を下げ、通りの両側に提灯が増えた。seed 12346 の拡張なしの画像には「OPEN」の看板があり、拡張ありの画像には無かった。拡張なしに渡した長いプロンプトには着物と「OPEN」の看板の指定があり、拡張ありの依頼文には無い。拡張が書き起こしたプロンプトには、文字や看板を描かないという指定も加わっていた。どちらが良いかの比較ではなく、入力の違いが画像に出たものとみている。拡張だけの効果を切り分けた比較ではなく、見たのは RTX 5080・w4a8・8MP の2組に限られる。

依頼文に書かなかった服装や小物は、拡張が書き起こしたプロンプトの側で決まり、それが画像に出た。この記事で試したのは、短い依頼文を拡張に通した場合と、具体的な英文のプロンプトを拡張なしで渡した場合の2通りだけだ。配布元は拡張を残す使い方を勧めているので、拡張を外して自分でプロンプトを書き込む使い方がうまくいくかは、自分の題材で確かめたい。

画像の編集は何秒かかり、指示どおりになるか

編集は RTX 5080 だけで、本体 w4a8・4MP で2本測った。元の画像は、この記事の w4a8・4MP のテキストからの生成 (RTX 5080・seed 12345) の出力で、指示は「雪の冬の夕方に変え、構図と人物と赤い傘は残す」という英文。参照画像は元の画像1枚だけで、プロンプト拡張は使っていない。編集の結果表で、時間と、指示どおりになったかを見る。

seed	時間	うちサンプラー	VRAMのピーク	結果
12345 (1本目)	28.4秒	21.3秒	14,931MiB	雪は積もらず、色とコントラストが強くなっただけだった
12346 (2本目)	28.4秒	20.3秒	15,206MiB	屋根と道の端に雪が積もり、構図・人物・傘は元のまま

結果の列は2本を目で見たもの。1本目はモデルの読み込みを含む。VRAM のピークはカード全体の使用量 (画面出力の分を含む) で、この表は1本目と2本目それぞれの値。2本目だけを載せた生成時間とメモリの節の実測表とは扱いが違う。

編集は2本とも 28.4秒だった。同じ 4MP のテキストからの生成と比べると、2本目どうし (9.3秒) で約3倍、1本目どうし (12.1秒) で約2.3倍かかった。ただし編集の2本目は、元の画像を読み直して前処理と条件付けもやり直していて (条件付けだけで約2.8秒)、条件付けをキャッシュから使ったテキストからの生成の2本目とは条件が違う。このグラフで測った範囲では、テキストからの生成より待つ時間が長い前提で使うことになる。

指示どおりになったのは seed 12346 のほうで、屋根と道の端に雪が積もり、構図・人物・傘は元のままだった。seed 12345 では雪は積もらず、色とコントラストが強くなっただけだった。2本なので、どのくらいの割合で指示どおりになるかは言えない。seed の違う2本で結果が分かれたが、同じ seed を2回回す比較はしておらず、原因が seed だけかは分けていない。何本か作って、その中から選ぶ使い方がありうる。

測っていないこと

この記事で測っていないのは次のとおり。ここに挙げた条件での結果は、本文の数値から推し量らずに扱いたい。

• bf16 の一式
• 配布元の int8 の一式 (本体・テキストエンコーダ・VAE がどれも int8。プロンプト拡張は一式に入っていない)
• VRAM 12GB 以下のカード
• メインメモリが 32GB 以下の PC (測定機は 96GB)
• RTX 5060 Ti での編集
• 参照画像を複数使う編集
• プロンプト拡張を使った編集
• int8 の本体とプロンプト拡張の組み合わせ
• 正方形以外の大きさ
• 配布物に含まれる MiniMax H3 向けの LoRA
• bf16 の出力との画像の比較
• AMD の GPU
• Linux

配布元は、VRAM 48GB の L40S で、bf16 の一式ではオフロードが必要になり 2048×2048 に 19秒かかるところ、w4a8 の一式なら 6.3秒で描けると書いている。この記事の実測とは GPU も測り方も違うので、数字どうしは比べていない。

検証環境と測り方

測定は 2026-11-06 に行った。Windows 11、ComfyUI 0.44.0、PyTorch 2.14.0+cu130、comfy-kitchen 0.2.40、comfy-aimdo 0.6.0、NVIDIA ドライバ 610.88 で、VRAM の扱いや計算の精度を変える起動オプションは付けていない (付けたのは、プレビューを出さない --preview-method none と、入出力先などの指定)。GPU は RTX 5080 (PCIe 5.0 x16) と RTX 5060 Ti (OCuLink 経由の PCIe 4.0 x4) で、どちらも VRAM 16GB。RTX 5080 は画面出力にも使っている。起動ログで、それぞれの GPU が CUDA のデバイスとして使われていることを確かめ、VRAM の使用量は nvidia-smi で記録した。測定機の構成の詳細は検証環境のページに載せている。使う GPU を指定して ComfyUI を動かす手順は「ComfyUIで使うGPUを指定する｜v0.34以降のWindowsは既定で1枚しか使わない」で扱った。

• 条件ごとに ComfyUI を起動し直し、同じ条件を2本続けて生成した (seed は 12345 と 12346)
• グラフは、配布元のワークフローの設定 (euler・8ステップ・ManualSigmas・CFG なし) に合わせて、API で送る形に組み直したもの
• 時間は ComfyUI の execution_start から execution_success までで、リクエストを送る時間や順番待ちの時間は含まない
• テキストからの生成のプロンプトは、雨上がりの夕暮れの京都の路地を赤い傘の老人が歩いていく場面を具体的に書いた英文1つ。プロンプトの全文と、API の形に組み直したグラフは載せていないので、この記事の数字をそのまま再現する材料は揃っていない

メモリの単位は、測った値の表示のまま載せている。VRAM と共有 GPU メモリは MiB、メインメモリは GiB、ファイルの大きさはバイト数を GB (10の9乗) で表した値。

本文の実測値は2026年11月6日に測定したもの。ComfyUI 0.44.0・PyTorch 2.14.0+cu130 で、ComfyUI やモデルの更新で変わりうる。

まとめ

VRAM 16GB 級のカードで使うなら (今回は Windows 11 の RTX 5080・RTX 5060 Ti で確認)、落とすのは本体 w4a8・テキストエンコーダ w4a8・VAE int8 の3ファイル (約 20.1GB) で、本体は w4a8 から始めやすい。配布元のワークフローをそのまま使うなら、プロンプト拡張のファイルも置き、読み込みのノードを落としたファイルに選び直す。テキストエンコーダ w4a8・VAE int8 の構成で測った範囲では、int8 の本体は速さで目立つ差が無く、共有 GPU メモリとメインメモリを多く使い、ファイルも大きかった。画像の良し悪しは比べていない。

プロンプト拡張は、配布元のワークフローではどれも使われていて、配布元も残す使い方を勧めている。新しい依頼文のときは拡張のノードの時間が加わる。今回見た2組では、拡張が書き起こした服装や小物が画像に出たが、拡張だけの効果を切り分けた比較ではない。

編集は、RTX 5080 で測った2本のうち1本が指示どおりにならず、色が変わるだけだった。2本では割合は言えないが、seed を変えて何本か作り、その中から選ぶ使い方が考えられる。

参考資料

• PrunaAI/P-H3-Image-Comfy — Hugging Face
• P-H3-Image-Comfy の LICENSE (MiniMax H3 Community License) — Hugging Face
• P-H3-Image — ComfyUI 公式ドキュメント
• ComfyUI v0.44.0 リリースノート