この記事の要点
プロンプト拡張（短い指示を詳しい文に書き直す機能）を切った状態なら、測った組み合わせはどれもこの測定環境で最後まで生成でき、差はメインメモリの確保量と速さに出た。テンプレートの既定のファイルは画像モデル本体を大きい版にした組み合わせより速く、テキストエンコーダを最も小さい版に替えると確保量がさらに減った。
背景が透明な PNG は、解像度を上げた設定で抜けやすく、テンプレートを開いたままの解像度では抜けた枚が少なかった。
テンプレートで最初から有効になっているプロンプト拡張は、この測定環境では途中で止まった。文章の生成を速める設定（mtp）を切ると動いたが、書き直された文には背景を透明にする指示が残らなかった。
VRAM 16GBで動くか、どの組み合わせを選ぶか
測ったのは VRAM 16GB の RTX 50 シリーズ2枚（RTX 5080 と、後の節で扱う RTX 5060 Ti）で、ほかの世代の 16GB のカードは測っていない。メインメモリ96GB・Windows 11 の測定機で、プロンプト拡張を使わなければ、配布されているファイルから組める組み合わせのうち測った4つは、どれも RTX 5080 16GB で最後まで生成できた（テンプレートで enable_PE を off にしたときと同じ結線では Qwen3.8-27B が読み込まれないことを、API で確かめている）。4つの組み合わせは、画像モデル本体（int8_convrot / bf16）とテキストエンコーダ（int8_convrot / w4a8 / bf16）から組んだ int8_convrot＋int8_convrot、int8_convrot＋w4a8、bf16＋int8_convrot、bf16＋bf16 だ。違いが出たのはメインメモリの確保量と速さだった。プロンプト拡張を有効にしたテンプレートの既定のままでは、別の結果になった（後の節で扱う）。
選ぶときの材料は次のとおり。テンプレートの既定のファイル（int8_convrot 同士）は、画像モデル本体を bf16 にした組み合わせより速く、メインメモリの確保量も小さかった。テキストエンコーダを w4a8 に替えると、2枚目以降の速さは同程度のまま確保量がさらに小さくなった。画質は比べていないので、どの組み合わせの出来が良いかはこの記事では決めない。
int8_convrot・w4a8・bf16 は、重みの持ち方（量子化の方式）の違いだ。int8_convrot と w4a8 は量子化して小さくした版で、bf16 は量子化していない版。w4a8 は対応する層で、重みを4ビット、計算中の値（activation）を8ビットで扱う。同じ役割のファイルで比べると bf16 が最も大きく、テキストエンコーダでは w4a8 が最も小さい。
配布元の inclusionAI のモデルカードによると、Ming-Image-0.1-Design は UI・インフォグラフィック・ポスターなど文字の多いデザイン向けの 6B の画像生成モデルで、背景が透明な RGBA 出力に対応する。推奨設定は 2048×2048（速さを優先するなら 1024×1024）・12ステップ・CFG 1.0・BF16 で、検証済みの構成は VRAM 80GiB の CUDA GPU 1枚と記載されている。この記事は、ComfyUI 用に再配布された bf16 と量子化版のファイルを ComfyUI で 16GB のカードに載せて測ったもので、公式の推論コードの構成を 16GB で動かした結果ではない。
配布されているファイルと置き場所
ComfyUI 用のファイルは Comfy-Org/Ming-Image に再配布されている。中身は画像モデル本体（bf16 / int8_convrot）、テキストエンコーダの Ling mini 2.0（bf16 / int8_convrot / w4a8）、VAE の3種類だ。同じリポジトリにはレイヤー分解用の Layer のファイルもあるが、この記事では使っていない。テンプレートのプロンプト拡張に使う Qwen3.8-27B は別のリポジトリ（Comfy-Org/Qwen3.8-27B）にある。
| 役割 | ファイル名 | 大きさ | テンプレートの既定 |
|---|---|---|---|
| 画像モデル本体 | ming_image_0.1_design_int8_convrot.safetensors | 5.75GiB | 使う |
| 画像モデル本体 | ming_image_0.1_design_bf16.safetensors | 11.46GiB | — |
| テキストエンコーダ (Ling mini 2.0) | ming_image_0.1_ling_mini_2.0_int8_convrot.safetensors | 18.17GiB | 使う |
| テキストエンコーダ (Ling mini 2.0) | ming_image_0.1_ling_mini_2.0_w4a8.safetensors | 11.93GiB | — |
| テキストエンコーダ (Ling mini 2.0) | ming_image_0.1_ling_mini_2.0_bf16.safetensors | 34.16GiB | — |
| VAE | ming_image_vae_bf16.safetensors | 0.24GiB | 使う |
| プロンプト拡張 (Qwen3.8-27B) | qwen3.8_27b_w4a8.safetensors | 16.10GiB | 使う |
大きさは各ファイルのバイト数を GiB（2の30乗バイト）に直した値で、配布ページの GB（10の9乗バイト）表示とは数字が違って見える。たとえば画像モデル本体の int8_convrot は、配布ページでは 6.18GB、この表では 5.75GiB になる。測定に使ったファイルの sha256 は配布ページの値と一致した。
置き場所は次の3か所。
- 画像モデル本体:
ComfyUI/models/diffusion_models - テキストエンコーダ（プロンプト拡張の
qwen3.8_27b_w4a8.safetensorsも含む）:ComfyUI/models/text_encoders - VAE:
ComfyUI/models/vae
落とすファイルは、テンプレートの既定のまま使うなら表で「使う」とある4つになる。テキストエンコーダを w4a8 にする場合は、ming_image_0.1_ling_mini_2.0_w4a8.safetensors を int8_convrot の代わりに落とす。表の大きさを足すと、既定の4つで約40GiB、テキストエンコーダを w4a8 にした場合で約34GiB になる（後の表の「ファイル合計」はプロンプト拡張の qwen3.8_27b_w4a8.safetensors を含まない）。
プロンプト拡張を使わない場合でも、qwen3.8_27b_w4a8.safetensors は置いておく必要があった。テンプレートと同じつなぎ方（enable_PE が on のときだけプロンプト拡張を通す形）で enable_PE を off にしても、このファイルが無いと、ComfyUI は実行前の検証で拡張用の読み込みノードに「Value not in list」と出して止まった。ファイルを置いた状態で off にすると最後まで生成でき、そのとき Qwen3.8-27B は読み込まれなかった。これは2026年10月1日に RTX 5080・ComfyUI v0.38.0 で、API から同じ結線を投げて確かめた結果で、UI の画面での挙動は見ていない。
テンプレートの既定の組み合わせはファイルの合計が 16GB を超えるが、この測定機（メインメモリ96GB）では最後まで生成できた。ComfyUI はモデルを必要に応じて VRAM に載せる方式で動いていた。この点は後の「VRAMの使用量はどう読むか」で詳しく扱う。ファイルの合計はどの組み合わせでもかなり大きくなるので、ストレージに余裕が無い場合はローカルAIでSSDは何TB要るかで容量の考え方を確かめておける。
ライセンスは、Ming-Image-0.1-Design と ComfyUI 用の再配布ファイルが MIT。プロンプト拡張に使う Qwen3.8-27B の ComfyUI 用ファイルは Apache-2.0 で、Comfy-Org のモデルカードには、現在は文章の生成にだけ使われると書かれている。
導入の手順
- ComfyUI を v0.38.0 以降に更新する。この記事の動作確認は v0.38.0 で行っており、それより新しい版では確かめていない。
- 使う組み合わせのファイルを、前の節の置き場所へ置く。プロンプト拡張を使わない場合も
qwen3.8_27b_w4a8.safetensorsは置く。 - テンプレート
image_ming_image_01_design_t2iを開く。既定では12ステップで、画像モデル本体とテキストエンコーダは int8_convrot、Qwen3.8-27B（qwen3.8_27b_w4a8.safetensors）によるプロンプト拡張が有効（enable_PE）になっている。 - 解像度を決める。テンプレートでは、置かれている
ResolutionSelectorノード（1:1・megapixels1）の出力が解像度として使われるので、開いたままなら 1024×1024 になる。このノードは縦横比とmegapixelsから幅と高さを計算し（幅×高さ =megapixels×1024×1024）、1:1 なら 1.0 がおよそ 1024×1024 に当たる。megapixelsの上限は16で、1:1 のまま 4 にすると 2048×2048 になる。背景を透明にしたいなら 2048×2048 にする（理由は次の節）。テンプレートのノートも、2048×2048 を画質が最も良い設定、1024×1024 を速い設定として案内している。この記事の測定は、解像度をEmptyLatentImageとModelSamplingFluxに直接指定して行っており、megapixelsを 4 にする操作そのものは実行していない。 - プロンプト拡張を使わないなら
enable_PEを off にする。off にすると、入力した文がそのまま画像モデルへ送られる。拡張を使う場合は、TextGenerateノードのmtpに注意する。この測定環境では既定の auto のままだとTextGenerateで止まり、off にすると動いた。止まったらmtpを off にする。 - 背景を透明にしたいなら、プロンプトの先頭に透過の指示文を1つだけ置く（配布元の案内）。配布元の例では
RGBA, 4-channel, transparent backgroundがこれに当たる。プロンプト拡張を有効にしていると拡張後の文にはこの指示文が残らなかったので、指示文を自分で先頭に置くなら拡張は off にする。なお、この記事の測定では指示文なしでも 2048×2048 で背景が抜けた枚が多く、指示文の効果は確かめられていない。 - 背景が残ったら seed を変えて出し直す。この測定では、同じ解像度・同じ指示文なら、組み合わせや GPU を変えても背景が抜けるかどうかは seed ごとにほぼ同じだった（2048×2048・seed 4個・6条件）。一方、同じ seed でも解像度を変えると24個中19個で結果が変わり、1024×1024 のまま seed を変えても抜けた枚は24枚中3枚だった。
背景が透明なPNGは出るか
背景が抜けやすかったのは 2048×2048 で、テンプレートを開いたままの 1024×1024 では抜けた枚が少なかった。
配布元の GitHub の README は、アルファチャンネル付きの画像を作るには、決められた指示文のうち1つだけを選んでプロンプトの先頭に置き、複数を組み合わせないよう案内している。この記事ではその例にある RGBA, 4-channel, transparent background を使った（以下、透過の指示文）。
判定の仕方から説明しておく。出力の PNG は背景が抜けたかどうかにかかわらず全部 RGBA 形式で保存されたので、形式を見ても区別できない。そこで PNG の四隅（各 8×8 画素）のアルファ値で判定した。4か所すべての最大値が 32 以下なら「背景が抜けた」、4か所すべての最小値が 223 以上なら「背景が残った」、それ以外は「どちらとも言えない」とした。しきい値は全出力の四隅の値の分布を見てから置いた（分布は「検証環境と測り方」に記した）。見ているのは四隅だけで、被写体の位置や大きさ、縁の半透明の具合は見ていない。2048×2048 で背景が抜けた枚の中には、バッジが隅に小さく寄った構図のものもあった。
下の表は、RTX 5080・int8_convrot＋int8_convrot・12ステップ・プロンプト拡張なしで、seed 300〜323 の24個を題材3種に順に割り当て（各題材8個）、同じ24個の seed を4つの条件で共通に使った追加測定の結果だ。
| 条件 | 背景が抜けた (四隅が透明) | 背景が残った (四隅が不透明) | どちらとも言えない |
|---|---|---|---|
| 1024×1024・透過の指示文あり | 24枚中3枚 | 21枚 | 0枚 |
| 1024×1024・透過の指示文なし | 24枚中2枚 | 22枚 | 0枚 |
| 2048×2048・透過の指示文あり | 24枚中20枚 | 4枚 | 0枚 |
| 2048×2048・透過の指示文なし | 24枚中16枚 | 8枚 | 0枚 |
同じ seed どうしで突き合わせたのが次の表で、各行の4つの数を足すと24になる。
| 比べ方 (A と B) | 両方で抜けた | A だけで抜けた | B だけで抜けた | 両方で残った |
|---|---|---|---|---|
| A = 2048×2048、B = 1024×1024 (どちらも指示文あり) | 2 | 18 | 1 | 3 |
| A = 指示文あり、B = 指示文なし (どちらも 2048×2048) | 16 | 4 | 0 | 4 |
2048×2048 だけで抜けた seed が多く、1024×1024 だけで抜けた seed は少なかった。指示文ありだけで抜けた seed は4個あり、指示文なしだけで抜けた seed は無かったが、結果が食い違った seed は4個だけで、指示文に効果があるとまでは言えない。指示文なしでも 2048×2048 では多くの枚で背景が抜けている。これより前に seed 100〜111 で行った追加測定でも、2048×2048 のほうが抜けた枚が多い点は同じだった（指示文ありの 1024×1024 は12枚中3枚、2048×2048 は12枚中8枚で、どちらとも言えない1枚）。指示文の有無は、seed 100〜108 の9個で比べると指示文なしが9枚中8枚、指示文ありが9枚中7枚（どちらとも言えない1枚）で、上の偏りは再現しなかった。
組み合わせや GPU を変えると結果が変わるかも見た。次の表は、本測定のうち 2048×2048・透過の指示文ありの4枚（seed 43〜46）を、RTX 5080 の4組み合わせと RTX 5060 Ti の2組み合わせの6条件で比べたものだ。
| seed | 題材 | 背景が抜けた条件 | 背景が残った条件 | どちらとも言えない条件 |
|---|---|---|---|---|
| 43 | OPEN DAILY (円形) | 6条件中6 | 6条件中0 | 6条件中0 |
| 44 | RIDE SAFE (四角) | 6条件中6 | 6条件中0 | 6条件中0 |
| 45 | FRESH MARKET (六角形) | 6条件中6 | 6条件中0 | 6条件中0 |
| 46 | OPEN DAILY (円形) | 6条件中0 | 6条件中6 | 6条件中0 |
同じ seed なら、組み合わせや GPU を変えても背景の判定は6条件でそろった。これは判定が一致したという意味で、出力の画像が同一になるという意味ではない。seed 4つ・6条件だけの比較でもある。一方、同じ本測定の 1024×1024 で透過の指示文を付けた24枚（seed 43〜46、同じ6条件）は、24枚とも背景が残った。
Hugging Face のモデルカードには、公開の推論コードが text-to-image の解像度の指定を 1024 か 2048 の区分に寄せる、という記載もある。1024×1024 で抜けにくかった理由は、この記事では確かめていない。
題材は文字入りのステッカー風バッジ3種（OPEN DAILY の円形・RIDE SAFE の四角・FRESH MARKET の六角形）だけで、写真風の被写体などで同じ結果になるかは測っていない。背景が抜けた枚でも、縁の半透明の具合や合成したときの見え方は評価していない。同じように透過 PNG を出せる別の画像モデルでの結果は、Qwen-Image-2.1をVRAM 16GBで動かすで実測している。
公式テンプレートのプロンプト拡張を使う場合
テンプレートでは、既定でプロンプト拡張が有効になっている。Qwen3.8-27B で短い指示を詳しい文に書き直す機能だ。その中にある TextGenerate ノードの mtp は、文章の生成を速くするための設定で、既定は auto になっている。ComfyUI v0.38.0 のツールチップでは、mtp はチェックポイントの複数トークン予測ヘッドを使った投機的デコードの設定で、選択肢は auto / off / 2〜5、auto は下書きの深さを自動で変える、と説明されている。
測定は RTX 5080・int8_convrot＋int8_convrot・2048×2048・透過の指示文ありで、プロンプト拡張はテンプレートと同じ system prompt と TextGenerate の値（最大4,096トークン）にした。seed は 200〜202 で、設定ごとに ComfyUI を起動し直して3枚出している。拡張の秒数とトークン数は ComfyUI のログの進捗表示（Generating tokens）の最後の行から読んだもので、秒は整数の分解能だ。この測定は UI でテンプレートを開いて実行したものではなく、API でテンプレートと同じ値のノードを組んで投げたもので、解像度は 2048×2048 だけだ（テンプレートの既定の 1024×1024 では実行していない）。
| 設定 (TextGenerate の mtp と起動オプション) | 結果 | 1枚目 (読み込み込み) | 2枚目・3枚目 | うちプロンプト拡張 | 拡張後の文 | 背景が抜けた | メインメモリの確保量 (ピーク) |
|---|---|---|---|---|---|---|---|
| テンプレートの既定 (mtp: auto) | 3回とも TextGenerate で停止 (画像は出ない) | — | — | — | — | — | — |
| mtp: off | 3回とも画像が出た | 84.0秒 | 71.4秒・77.4秒 | 52〜61秒 (369〜423トークン、毎秒6.9〜7.1トークン) | テンプレートの指示どおりの JSON の文 (透過の指示文は3枚とも残っていない) | 3枚中1枚 | 32.0GiB |
| mtp: auto のまま、起動オプション –disable-cuda-graphs | 3回とも画像が出た | 715.4秒 | 723.8秒・724.1秒 | 684〜697秒 (3回とも4,096トークン、毎秒5.9〜6.0トークン) | 意味をなさない文字列が上限まで続いた | 3枚中1枚 | 35.4GiB |
この測定環境（RTX 5080・Windows・ComfyUI v0.38.0）では、テンプレートの既定の mtp: auto のまま、起動し直して3回試し、3回とも画像を出す前に TextGenerate ノードで止まった。表示された例外は、CUDA のグラフを記録（capture）している最中に失敗したことを示すもの（torch.AcceleratorError: operation failed due to a previous error during capture）だった。3回ともログではその前に、comfy_kitchen の int8 の重みを戻す処理で RuntimeError: CUDA error: CUBLAS_STATUS_INTERNAL_ERROR（cublasSgemm）が出ていた。止まった原因は突き止めていない。
mtp を off にすると3回とも画像が出たが、プロンプト拡張だけで1枚あたり1分前後かかった。ComfyUI には CUDA グラフを無効にする起動オプション --disable-cuda-graphs があり、これを付けると mtp: auto のままでも最後まで走った。ただし拡張後の文は意味をなさない文字列が上限まで続き、使える出力にはならなかった。表の3つの行は、mtp と起動オプションという別々の設定を変えたもので、止まる原因をどちらかに切り分けたものではない。
透過についても触れておく。mtp: off の3枚は、拡張後の文のどれにも透過の指示文が残っておらず、背景が抜けたのは3枚中1枚だった。ただしこの3枚は前の節の追加測定と seed が違い、枚数も少ないので、拡張が抜けやすさを下げるとは言えない。前の節のとおり、指示文なしでも 2048×2048 では多くの枚で抜けている。この測定から言えるのは、透過の指示文を確実にプロンプトの先頭に残せるのは拡張を off にしたとき、ということまでだ。
ここでの値は RTX 5080・Windows・ComfyUI v0.38.0 の1つの組み合わせで3枚ずつ出したもので、RTX 5060 Ti・1024×1024・ほかの組み合わせ・ほかの環境では試していない。同じ Qwen3.8-27B を llama.cpp の GGUF で 16GB のカードに載せたときの速さは、Qwen3.8-27BをVRAM 16GBで実測で測っている。ComfyUI のプロンプト拡張（w4a8 の safetensors）とは動かし方が違うので、数字はそのまま比べられない。
組み合わせごとの所要時間とメインメモリ (RTX 5080)
RTX 5080 で、プロンプト拡張なし・透過の指示文あり・12ステップの条件で、1つの組み合わせ×解像度ごとに ComfyUI を起動し直して4枚続けて出した結果だ。2〜4枚目は毎回題材（プロンプト）を変えたので、テキストエンコーダも毎回動いている。
| 組み合わせ (画像モデル＋テキストエンコーダ) | ファイル合計 (VAE込み) | 解像度 | 1枚目 (モデル読み込み込み) | 2枚目以降 (3枚の中央値と範囲) | メインメモリの確保量 (ピーク) | 物理メモリに載っていた量 (ワーキングセットのピーク) |
|---|---|---|---|---|---|---|
| int8_convrot＋int8_convrot | 24.16GiB | 1024×1024 | 9.8秒 | 5.6秒 (5.6〜5.7秒) | 25.8GiB | 9.4GiB |
| int8_convrot＋int8_convrot | 24.16GiB | 2048×2048 | 21.8秒 | 18.8秒 (18.7〜19.3秒) | 25.4GiB | 8.3GiB |
| int8_convrot＋w4a8 | 17.92GiB | 1024×1024 | 8.0秒 | 6.1秒 (5.6〜6.8秒) | 21.4GiB | 5.1GiB |
| int8_convrot＋w4a8 | 17.92GiB | 2048×2048 | 21.0秒 | 18.7秒 (18.7〜20.6秒) | 21.9GiB | 5.3GiB |
| bf16＋int8_convrot | 29.87GiB | 1024×1024 | 14.2秒 | 10.1秒 (10.0〜10.1秒) | 28.6GiB | 13.7GiB |
| bf16＋int8_convrot | 29.87GiB | 2048×2048 | 36.6秒 | 33.5秒 (33.1〜33.6秒) | 29.8GiB | 15.7GiB |
| bf16＋bf16 | 45.86GiB | 1024×1024 | 18.7秒 | 10.0秒 (9.6〜11.3秒) | 47.3GiB | 32.9GiB |
| bf16＋bf16 | 45.86GiB | 2048×2048 | 39.5秒 | 31.9秒 (31.3〜32.0秒) | 49.0GiB | 34.3GiB |
表の読み方は3つある。
- 2枚目以降の速さは、画像モデル本体が int8_convrot のもとでテキストエンコーダを int8_convrot と w4a8 で替えても、画像モデル本体が bf16 のもとで int8_convrot と bf16 で替えても、ほぼ変わらなかった。差が出たのは画像モデル本体のほうで、bf16 にすると（テキストエンコーダは int8_convrot のまま）、2枚目以降の1枚あたりは int8_convrot 同士より 1024×1024 でも 2048×2048 でも約1.8倍かかった。
- メインメモリの確保量は、おおむねファイル合計に近い値になり、bf16 同士では約49GiB に達した。物理メモリに載っていた量は、どの行でも確保量より小さかった。
- 1枚目はモデルの読み込みを含むぶん長い。ただし OS のファイルキャッシュを温めたり空けたりはしておらず、キャッシュの状態に左右される参考値だ。自分の PC で初めて生成するときは、ディスクからの読み込み時間がさらに加わりうる。
2つのメモリの列は意味が違う。確保量は ComfyUI のプロセスが OS から確保したメモリ（Windows のコミット）で、OS がメモリとページファイルで裏づける量だ。物理メモリに載っていた量はそのプロセスのワーキングセット（プロセスのアドレス空間のうち物理メモリに載っているページ。メモリにマップしたモデルのファイルのページも、載っていれば含まれうる）で、PC 全体の物理メモリの使用量ではない。どちらも ComfyUI のプロセスの値で、PC に積むべきメインメモリの上限や下限を示すものではなく、メインメモリ96GB のこの測定機での参考値として読む。確保量は0.25秒ごとに読んだコミットの最大値、物理メモリに載っていた量は OS が記録するワーキングセットの起動後のピーク（ComfyUI のプロセスごとの値の合計）で、別々の時刻のピークなので、2つを足し引きして読むことはできない。メインメモリを何GB積むかの考え方は、画像・動画生成でシステムRAMは何GB要るかで扱っている。
次の1枚の出し方でも時間が変わる。下の表の上の行は、上の所要時間の表と同じ回の値。下の行は、別に起動して同じプロンプトのまま seed だけ変えた2〜3枚目の値だ。
| 次の1枚の出し方 (RTX 5080・int8_convrot＋int8_convrot・2048×2048) | 1枚あたり (2枚目以降) |
|---|---|
| プロンプトを書き換える (テキストエンコーダがもう一度動く) | 18.8秒 (3枚の中央値) |
| 同じプロンプトで seed だけ変える | 15.9秒・16.0秒 (2枚) |
プロンプトを書き換えて次の1枚を出すと、テキストエンコーダがもう一度動くため、seed だけ変える場合より長くかかった。この比較は1つの組み合わせ・1つの解像度だけで行っている。
ここまでの値は単一の測定機・同じ3種の題材でのもので、画質や文字の正確さは比べていない。メインメモリ96GB の測定機で測っており、32GB や 64GB の PC で同じ組み合わせが動くか、同じ速さになるかは測っていない。
RTX 5060 Ti 16GBではどうなるか
RTX 5060 Ti 16GB では、int8_convrot 同士と int8_convrot＋w4a8 の2つの組み合わせを、RTX 5080 と同じ設定・同じ日に測った。
| 組み合わせ (画像モデル＋テキストエンコーダ) | ファイル合計 (VAE込み) | 解像度 | 1枚目 (モデル読み込み込み) | 2枚目以降 (3枚の中央値と範囲) | メインメモリの確保量 (ピーク) | 物理メモリに載っていた量 (ワーキングセットのピーク) |
|---|---|---|---|---|---|---|
| int8_convrot＋int8_convrot | 24.16GiB | 1024×1024 | 13.4秒 | 10.5秒 (10.5〜10.6秒) | 26.0GiB | 9.1GiB |
| int8_convrot＋int8_convrot | 24.16GiB | 2048×2048 | 46.1秒 | 43.8秒 (3枚とも43.8秒) | 25.4GiB | 8.3GiB |
| int8_convrot＋w4a8 | 17.92GiB | 1024×1024 | 14.0秒 | 10.5秒 (3枚とも10.5秒) | 21.6GiB | 4.9GiB |
| int8_convrot＋w4a8 | 17.92GiB | 2048×2048 | 45.6秒 | 43.8秒 (43.7〜43.8秒) | 21.6GiB | 5.0GiB |
RTX 5060 Ti でも、2つの組み合わせはどちらも最後まで生成できた。int8_convrot 同士で比べると、2枚目以降の1枚あたりは RTX 5080 より 1024×1024 で約1.9倍、2048×2048 で約2.3倍かかった。メインメモリの確保量は RTX 5080 とほぼ同じだった。
この RTX 5060 Ti は OCuLink（PCIe 4.0 x4）の外付け接続で測っており、内蔵接続とは接続の帯域が違うので、内蔵接続でも同じ値になるとは限らない。bf16 の組み合わせとプロンプト拡張は RTX 5060 Ti では測っていない。こちらも単一の測定機・同じ3種の題材での値で、画質や文字の正確さは比べておらず、メインメモリ96GB 以外の PC での動作も測っていない。
VRAMの使用量はどう読むか
RTX 5080 の所要時間の表と同じ回の全32枚（各解像度で4組み合わせ×4枚＝16枚ずつ）で、VRAM について2つの値を記録した。表の範囲は、カード全体と PyTorch の列が解像度ごとの16枚、「生成を始める前」の列が解像度ごとの4回の起動から取っている。
| 解像度 | カード全体の使用量のピーク (nvidia-smi) | PyTorch のメモリプールとして確保された量のピーク (max_memory_reserved) | 生成を始める前のカード全体の使用量 |
|---|---|---|---|
| 1024×1024 | 14,582〜15,460MiB | 3,194〜3,772MiB | 520〜711MiB |
| 2048×2048 | 14,858〜15,403MiB | 7,764MiB (全組み合わせで同じ) | 491〜639MiB |
nvidia-smi で見るカード全体の使用量は、生成中に繰り返し読んだ最大値で、画面表示など他のプロセスのぶんも含む。こちらはどの組み合わせでも満杯近くまで上がった。一方、ComfyUI のプロセス内で torch.cuda.max_memory_reserved を読んだ、PyTorch のメモリプールとして確保された量は、1024×1024 と 2048×2048 のどちらかでほぼ決まり、組み合わせ（ファイルの大きさ）ではほとんど変わらなかった。生成を始める前の値は、各組み合わせの1枚目の直前に読んでいる。
PyTorch の値は、PyTorch が GPU 上に確保したメモリプールの量（使い終わって再利用を待っているぶんも含む）で、メインメモリの「確保量」（Windows のコミット。物理メモリに載っているぶんも、載っていないぶんも含む）とは測っているものが違う。ただし PyTorch の外で確保されたメモリはこの値に入らない。また、2つの値は同じ時刻のピークとは限らない。
ComfyUI v0.38.0 は、この測定環境ではモデルを必要に応じて VRAM に載せる方式で動いていた（起動ログに DynamicVRAM support detected and enabled と表示された）。カード全体の使用量が満杯近くまで上がるのはそのためで、ピークの値をそのまま「このモデルに必要な VRAM」として読むことはできない。この読み込み方式と起動オプションの関係はComfyUIの起動オプション実測ガイドにまとめてある。ピークの VRAM が必要量と一致しないことは、MiniMax Music 3をVRAM 16GBで動かすでも別のモデルで確かめている。
検証環境と測り方
- 環境: GPU は RTX 5080 16GB（PCIe 5.0 x16 の内蔵接続・画面表示を兼ねる）と RTX 5060 Ti 16GB（OCuLink = PCIe 4.0 x4 の外付け接続・画面表示なし）。環境変数
CUDA_VISIBLE_DEVICESでどちらか1枚だけを見せて使い分けた。CPU は Intel Core i7-14700F、メインメモリ96GB、Windows 11。RTX 5060 Ti は内蔵接続とは帯域が違い、その影響は測っていない。 - バージョン: NVIDIA ドライバ 610.47、ComfyUI v0.38.0（PyTorch 2.14.0+cu130、comfy-kitchen 0.2.36）。ワークフローは公式テンプレート
image_ming_image_01_design_t2i（workflow_templates v0.11.70 の同名ファイル）と同じノードと値（12ステップ・euler・simple・BasicGuiderで CFG なし・ModelSamplingFlux1.15/0.5・attention は comfy kitchen attention）。プロンプト拡張の測定を除き、プロンプト拡張のノードは含めていない。解像度はEmptyLatentImageとModelSamplingFluxに直接指定した。起動オプションは、ポート・出力先・ユーザーデータの置き場などの隔離用のものだけを足し、速さやメモリの使い方を変えるものは足していない（--disable-cuda-graphsの行を除く）。 - 測り方: プロンプトは文字入りのステッカー風バッジ3種で、1枚ごとに次の順で繰り返し割り当てた。
- OPEN DAILY（円形）:
a flat vector sticker badge: a round coral badge with a white coffee cup icon and the text "OPEN DAILY" in bold white capital letters, clean edges - RIDE SAFE（四角）:
a flat vector sticker badge: a square teal badge with a white bicycle icon and the text "RIDE SAFE" in bold white capital letters, clean edges - FRESH MARKET（六角形）:
a flat vector sticker badge: a hexagonal mustard-yellow badge with a white leaf icon and the text "FRESH MARKET" in bold white capital letters, clean edges
透過の指示文ありの条件は先頭に
RGBA, 4-channel, transparent background,を付け、指示文なしの条件は上の文をそのまま使った。所要は API で投げてから画像が保存されるまで。メインメモリの確保量は ComfyUI のプロセスのコミットを0.25秒ごとに読んだ最大値、物理メモリに載っていた量は OS が記録するワーキングセットの起動後のピーク（プロセスごとの値の合計）で、2つは別々の時刻のピーク。モデルのファイルは取得時に全体を読み、sha256 を配布ページの値と照合した。背景の判定は、PNG の四隅（各 8×8 画素）のアルファ値の最大値がすべて 32 以下なら「抜けた」、最小値がすべて 223 以上なら「残った」とした。全出力の四隅の値は、抜けた側では最大値が 2〜29、残った側では最小値が 247〜254 に集まり、その間に入ったのは seed 105（2048×2048・指示文あり・seed 100〜111 の追加測定）の1枚だけで、四隅ごとに値がばらついたので「どちらとも言えない」とした。しきい値はこの空いている帯の中（255 の12.5%）に置いたが、抜けた側の最大の 29 は 32 に近い。 - OPEN DAILY（円形）:
- 試行回数: 1つの組み合わせ×解像度ごとに ComfyUI を起動し直し、4枚続けて生成した。2〜4枚目は毎回題材を変えた。透過の追加測定は seed 300〜323 の24個×4条件、プロンプト拡張は設定ごとに3枚（seed 200〜202）。
- 1枚目の定義: モデルの読み込みを含む。各測定の前に OS のファイルキャッシュを温めたり空けたりはしていないので、キャッシュの状態に左右される参考値で、ディスクからの初回読み込みを測ったものではない。
- ばらつき: 2枚目以降は3枚の中央値と範囲を表に載せた。単一の測定機での値で、ほかの PC での再現は取っていない。
本記事の実測値は2026年10月1日に、上記の測定機・設定で計測したもの。測定機の構成の詳細は検証環境のページに載せている。ほかの GPU やモデルでの実測はAIハードウェア実測データベースから探せる。
この記事で測っていないこと
- 画質・文字の正確さの比較
- メインメモリ32GB・64GB の PC での動作
- RTX 5060 Ti での bf16 の組み合わせとプロンプト拡張
- 1024×1024 と 2048×2048 以外の解像度・縦横比
- ステッカー3種以外の題材での透過
- 背景が抜けた画像の縁の具合と、合成したときの見え方
- 同じ Ming-Image 系の Layer（レイヤー分解）モデル
- 公式の推論コード（80GiB 構成）との比較
- ディスクから初めて読むときの時間
- UI でのテンプレートの実行と、1024×1024 でのプロンプト拡張
- RTX 50 シリーズ以外の GPU と Linux
よくある質問
メインメモリ32GB の PC でも動く？
測っていない。表の確保量はメインメモリ96GB のこの測定機での参考値で、搭載量が違う PC にそのまま当てはめることはできない。測った4つの中では、テキストエンコーダを w4a8 にした組み合わせが、確保量も物理メモリに載っていた量もいちばん小さかった。32GB の PC で動くかどうかは確かめていない。
1024×1024 で透過 PNG は出せない？
抜けた枚はあったが少なかった。RTX 5080・int8_convrot 同士・プロンプト拡張なしで、文字入りのステッカー風バッジ3種を出した追加測定では、透過の指示文ありの 1024×1024 で24枚中3枚の背景が抜けた。同じ条件で抜けやすかったのは 2048×2048 のほうだった。写真風の被写体などは測っていない。
int8_convrot と bf16 で画質は違う？
比べていない。気になる場合は、同じプロンプトと同じ seed で2つの組み合わせを並べて出すと、自分の用途で違いを見比べられる。
