見出し画像

Nvidia PiDはわりと凄い！けど何に使えばいいの？

ひろろひ🐈‍⬛Forge Neo推し

PiD (Pixel diffusion Decoder) は2026年5月下旬にNvidiaの研究チームが発表した技術です。ComfyUIでは2026/5/25、Forge Neoでは2026/6/19に対応されて利用できるようになりました。

私もComfyUIとForge Neoで一通り動かしてみて最初は「凄い！」と感じたのですが、細かく確認していくと粗が見えてきて、使い道がないと感じました。そのように感じている人が多いようで、ComfyUIが対応して数日間はredditで話題になったものの、その後は誰も取り上げていません。

とりあえず、PiDによって画像生成が劇的に変わるということは絶対にあり得ません。VAEが不要になることもありません。しかしせっかく色々と調べたり試したりしたので、記事にまとめました。

2026/7/17: PiD v1.5について追記
2026/6/27: Forge Neoが更新されPiD Integratedが実装されたことを追記
2026/6/23: 「処理時間」一覧表のSeedVR2 7b_fp16 x4の値を修正


概要

PiDがどのような技術なのかについては、Nvidia研究チームのプロジェクトページで解説されています。

私は以下の文章に仕組みの説明が集約されていると感じます。

reformulates latent decoding as conditional pixel diffusion
（Latentデコードをピクセル空間拡散モデルとして再定式化した）

https://research.nvidia.com/labs/sil/projects/pid/  より

使うだけなら以下の機能的なことだけ理解していれば大丈夫です。

  • Latent画像を入力として高速かつ省メモリに以下を同時に実施

    • ノイズ除去（再描画）

    • 4倍アップスケール（0.5Kx0.5K→2Kx2K or 1Kx1K→4Kx4K）

    • デコード（ピクセル画像化）

  • 各画像生成モデルのLatent形式 (VAE) 毎にモデル化（PiDモデル）

  • VAEは不要

処理内容はまったく異なりますが、入出力だけに着目するとLatent Upscaleを使った4倍Hires.fixと同様に使うことができます。

  • Latent Upscaleを使った4倍Hires.fix

```mermaid

%%{init: { 
  'themeVariables': { 'commitLabelFontSize': '18px' }
} }%%

graph LR
    classDef class1 fill:#ffa23e,fill-opacity:0.5

    A[txt2img] --> L1(Latent<BR>画像):::class1
    L1 --> Up["Latent<BR>Upscale<BR>(x4)"]

    subgraph Hires_fix [Hires.fix]
        Up --> L2(Latent<BR>画像):::class1
        L2 --> K[KSampler]
        K --> L3(Latent<BR>画像):::class1
        L3 --> V[VAE<BR>Decode]
    end

    V --> I(ピクセル<BR>画像):::class1
```

  • PiDによる4倍アップスケール

```mermaid

%%{init: { 
  'themeVariables': { 'commitLabelFontSize': '18px' }
} }%%

graph LR
    classDef class1 fill:#ffa23e,fill-opacity:0.5

    A[txt2img] --> B(Latent<BR>画像):::class1
    B --> C["PiD Decode<BR>(Denoise, x4 Upscale)"]

    subgraph PiD [PiD]
        C
    end

    C --> I(ピクセル<BR>画像):::class1
```

他の情報源としては、redditのスレッドも参考になりました。

使い方

PiDはComfyUIとForge Neoで使うことができます。
また軽いお試しであればHugging Face (HF) のSpacesで利用することもできます。

PiDモデルのダウンロード

HFのComfy-Orgリポジトリでsafetensors形式のPiDモデルが配布されています。ComfyUIだけでなくForge Neoもこちらのモデルを使います。

ディフュージョンモデル (diffusion_models) は、各画像生成モデルのLatent形式 (VAE) 毎に複数あります。どれを選べばよいかはファイル名から判断できると思います。分かりづらいのは以下くらいです。

  • Anima用： pid_qwenimage_*.safetensors を使用する

  • Z-Image用： pid_flux1_*.safetensors を使用する

テキストエンコーダー (text_encoders) は一種類のみです。

  • gemma_2_2b_it_elm_bf16.safetensors

当然ですがVAEはありません。

モデルの解説はHFのNvidiaリポジトリに記載されています。

ComfyUIでの使い方

ComfyUIはv0.23.0以降でPiDに対応しています。
試すだけならテンプレートにある ”PiD: Latent Upscale Decode" というワークフロー (WF) を使うのがもっとも早いです。シンプルなWFで使うためのカスタムノードもいくつか公開されていますが私は試してません。

テンプレートにてpidで検索
”PiD: Latent Upscale Decode” WFの全体図
"Latent Upscale Decode (PiD)" サブグラフの中身

”PiD: Latent Upscale Decode” はZ-Image-Turbo (ZIT) 用です。ZITでtxt2imgしたLatent画像を（VAEデコードせずに）そのまま "Latent Upscale Decode (PiD)" に繋いでPiDで ”Save Image" で保存するものです。
VAEは不要のはずなのにこのWFはVAEを必要とします。これは "Preview Image" でのPiD処理前のプレビューと、"Compare Images" でのPiD処理前との比較で使用されているためです。"Save Image" に繋がるPiD処理本体のフローではVAEは使われていません。

ちなみにSDXLやAnimaで使いたい場合は以下を変更すればよいです。

  • "Text to Image (Z-Image-Turbo)" サブグラフ
    SDXLまたはAnimaそれぞれのtxt2img WFに置き換えます。

  • "Latent Upscale Decode (PiD)" サブグラフ
    PiDモデルをpid_sdxlまたはpid_qwenimageに変更し、latent_formatをそれぞれに合わせます。サブグラフを開いて変更する必要はありません。

また "Text to Image (Z-Image-Turbo)" をピクセル画像に置き換えてVAE Encodeを追加すれば、下図のようなimg2imgのWFにすることも簡単にできます。

```mermaid

%%{init: { 
  'themeVariables': { 'commitLabelFontSize': '18px' }
} }%%

graph LR
    classDef class1 fill:#ffa23e,fill-opacity:0.5

    A(ピクセル<BR>画像):::class1 --> V[VAE<BR>Encode] 
    V --> B(Latent<BR>画像):::class1
    B --> C["PiD Decode<BR>(Denoise, x4 Upscale)"]

    subgraph PiD [PiD]
        C
    end

    C --> I(ピクセル<BR>画像):::class1
```

Forge Neoでの使い方

Forge Neoは2.26以降でPiDに対応しています。
ここまでの解説を理解していれば、Wikiに掲載された下図を見てPiDの使い方も理解できると思います。

https://github.com/Haoming02/sd-webui-forge-classic/wiki/Inference-References#pid より

Forge NeoではComfyUIと違って以下の制約があります。

  • img2imgでのみ利用可能

  • エンコード用のVAEを選択する必要がある

PiDモデルとVAEは好きな組み合わせを使えばよいです。
Wiki画像はFlux.1の組合せを使っていますが、他の組み合わせでも構いません。

2026/6/27追記：
Forge Neoの2026/6/27のCommit 1028589とCommit 5ec654dでPiD Integratedが実装され、txt2imgでも使えるようになりました。なお、Hires.fixとの同時利用は不可です。

検証方法

主なアップスケール方法と4倍アップスケールで比較しました。

検証環境

  • GPU: RTX 5090

  • Driver: Game Ready 610.62 WHQL (2026/6/16)

  • Python: Python 3.12.12, torch 2.11.0+cu130, triton-windows 3.6.0.post25, sageattention 2.2.0+cu130torch2.9.0andhigher.post4

  • Soft: ComfyUI v0.25.1 (2026/6/19)
    --normalvram --preview-method auto --use-sage-attention

検証に使用した画像

WAI-illustrious-SDXL v16.0を使って896x1152サイズで生成した画像です。
アップスケールでどうなるのか知りたくて、文字と網タイツを描かせました。SDXLでは網タイツはうまく描けませんが。

WAI-illustrious-SDXL v16.0による検証画像 (896x1152)

検証手順

各種のアップスケール方法について以下を実施するWFを作成し、アップスケール後の画像と合計時間を比較しました。

  • WAI-Illustrious-SDXLで896x1152サイズのLatent画像を生成

  • Latent画像を入力としてアップスケール＋Latentデコード

  • アップスケール後の画像をPNG保存

比較するアップスケール方法

以下のアップスケール方法について比較しました。

比較したアップスケール方法の一覧

Latent Upscaleを使ったHires.fixと比較したほうが良かったかもしれませんが、検証画像からの乖離が大きくなるためUltimate SD Upscaleで代用しました。

検証結果

画像

完全な出力画像はPiDのみ掲載します。
他のアップスケーラーの出力画像は、顔、網タイツ、文字の３部分ごとに512 x 512サイズの切り抜きでまとめて掲載します。

理由は後述しますが、PiDの結果はpid_sdxlではなくpid_qwenimageによるものを掲載しています。他と比べて色が違うこともいったん無視してください。

pid_qwenimageによる出力画像 (3584 x 4608)

１．顔

顔はさすがにWAI-illustrious-SDXL v16.0で描き直している5.Ultimate SD Upscaleがもっともよいと思います。
PiDは単体アップスケーラーよりは良く、SeedVR2には劣ると感じます。

２．網タイツ

いずれも解釈の違いという感じがしますが、PiDは網がシャープではなく、この中では一番良くない結果だと思います。

３．文字

2. RealESRGAN_x4+Anime6Bとそれを使用している5.Ultimate SD Upscaleはチョークではなくインクのような質感になってしまいました。
他は甲乙つけがたく、PiDは少しぼやけていますがこういう解釈もありだと思います。

処理時間

処理時間は下表の結果となりました。

$$
\begin{array}
{r|l|r|r}
\bf{No.} & \bf{Method} & \bf{×4} & \bf{×2} \\
& & \bf{(3584} & \bf{(1792} \\
& & \bf{×4608)} & \bf{×2304)} \\
\hline
\text{1} & \text{Lanczos} & \text{3.83s} & \text{3.16s} \\
\hline
\text{2} & \text{RealESRGAN\_x4+Anime6B} & \text{4.06s} & \text{3.98s} \\
\hline
\text{3} & \text{4x-UltraSharp} & \text{5.24s} & \text{5.08s} \\
\hline
\text{4} & \bf{PiD} & \bf{10.15s} & \bf{9.58s} \\
\hline
\text{5} & \text{Ultimate SD Upscale} & \text{28.20s} & \text{10.95s} \\
\hline
\text{6} & \text{SeedVR2 3b\_fp8\_e4m3fn} & \text{20.64s} & \text{9.65s} \\
\hline
\text{7} & \text{SeedVR2 7b\_fp16} & \text{30.20s} & \text{18.73s} \\
\end{array}
$$

4倍だけではなく、2倍アップスケールについても計測しました。
2. RealESRGAN_x4+Anime6B, 3. 4x-UltraSharp, 4. PiDは4倍固定アップスケールのため、2倍アップスケールについてはLanczosによる0.5倍ダウンスケールを追加してあります。
ダウンスケール処理が追加されているのに2倍の方が時間が短いのは、PNG保存の時間がかなり短くなるためです。
ちなみにWAI-Illustrious-SDXLでの画像生成時間は3秒未満です。

PiDは、4倍アップスケールのまま使うなら品質と処理時間のバランスが取れていると思います。しかし2倍アップスケールならUltimate SD UpscaleまたはSeedVR2 3b_fp8_e4m3fnを使ったほうが良さそうです。

評価

👍速度と品質のバランスが良い

PiDは、4倍アップスケールとしてそのまま使うなら、速度と品質のバランスは良いと思います。
メモリ数値を取得しなかったため検証結果は示せませんが、メモリ消費も少ないため、RTX 5090であれば4K x 4Kクラスの画像処理でもTile分割不要です。Hires.fix (Ultimate SD Upscale) ではTile分割しないとVRAMから溢れるため結構凄いことです。

4倍アップスケールにおけるざっくりとした評価は以下のような感じです。

  • 速度
    単体アップスケーラー >> PiD >> SeedVR2 3b >> Hires.fix

  • 品質
    Hires.fix > SeedVR2 >> PiD >> 単体アップスケーラー

しかし2倍アップスケールとして使う場合は異なりますし、品質にも大きな問題があります。

👎4倍アップスケール固定である

最大の問題点です。
個人的に4K x 4K (16MP) などという高解像度は必要としていません。一般的にも4Kモニター相当の4K x 2K (8MP) に収まれば現状は十分ではないでしょうか。
しかもモニターのアスペクト比である16:9のような横長画像を生成することは稀です。普通は3K x 2K (6MP) くらいで十分だと思います。そうすると4倍であれば、768 x 512で生成して3072 x 2048にアップスケールする計算になります。

しかしSDXLでは512 x 512のような低解像度で生成すると、学習解像度とモデルの特性から、構図や表現がかなり制約された画像になります。Animaなどの次世代モデルでは低解像度でもそこそこよいですが、以下を比較すると後者のほうが圧倒的に品質がよいです。

  • 768 x 512生成 → 3072 x 2048への4倍アップスケール

  • 1536 x 1024生成 → 3072 x 2048への2倍アップスケール

前者でPiDを使うと速度は後者より圧倒的に速いですが、品質の差を考えると使う気になりません。

私なら前者で常にPiDを使うよりも、後者でいったんアップスケール無しで画像生成し、厳選したもののみHires.fixかSeedVR2でアップスケールします。そのような使い方を考えると、Latent画像を直接処理できることもメリットと言えなくなってしまいます。

👎モデルによる品質差がある

本記事の検証はWAI-Illustrious-SDXLで生成した画像を使用したため、PiDモデルもpid_sdxlを使用しました。しかしpid_sdxlの出力品質はpid_flux1やpid_qwenimageの出力と比較すると明らかに劣っていました。

以下はpid_sdxlによる出力です。

Seedを変えても同様の傾向で、pid_flux1やpid_qwenimageに比べるとアーティファクトが多く劣化しているように見えます。
画像生成モデルによってLatentとVAEの形式は異なり、SDXLは古くてVAE（Latent形式）の精度が低いためかもしれませんが、チューニング不足だと思います。

とりあえずpid_sdxlは使わないほうがよいです。

👎色が変わる

標準のVAEに比べて明らかに色が変化します。
そもそもVAEは色にシビアで、各モデルで標準のVAEと異なる色になるよう調整されたVAEも存在しますが、PiDはもう少し標準のVAEの色に合わせられなかったのかなと思います。

今回の検証画像とpid_sdxl, pid_flux1, pid_qwenimageを並べて比較すると下図のようになります。

今回の検証画像ではpid_flux1の色変化がもっとも少ないですが、画像によってpid_flux1の色変化も大きくなります。

ちなみに、ComfyUIのColor Match系ノードを使うことで元画像の色に近付けることは可能です。
私のComfyUI環境には複数のColor Match系ノードがありました。使い方はどれもほとんど同じなので、こだわりが無ければComfyUI CoreのTransfer Colorノードを使うのがよいと思います。

ComfyUIのColor Match系ノード

下図はpid_qwenimageの出力画像をTransfer Colorノードのmkl_lab methodで補正した画像との比較です。

それでも元画像の色とは明らかに違ってますが。

2026/7/17追記：
PiD v1.5がリリースされ、色が改善されたようです。

- デコード時の色再現性を向上
- 画像の隅に見られたグリッドノイズを解消
- アニメや顔のディテールを向上

https://research.nvidia.com/labs/sil/projects/pid/comparison.html より翻訳

何に使うか？誰に向いているか？

個人的には今のままなら使うことは無いと思います。

性能が低いGPUを使っていて、もともと速度優先のため512 x 512クラスの解像度で生成してx2以下のHires.fixや単純アップスケールで我慢している人は、PiDのx4アップスケールを使うと恩恵があるかもしれません。

他の使い道があればコメントで教えてください。

まとめ

PiDを一通り動かしてみて最初は「凄い！」と感じたのですが、細かく確認していくと粗が見えてきて、使い道がないという話でした。
「AI驚き屋」のようにとりあえず「凄い！」と言ってインプレを稼いだ方がよいのでしょうかね。

PiDに関しては無駄に時間を使ってしまった感じですが、実はSeedVR2を使うのは今回が初めてで、その性能の高さを確認することができたのは収穫でした。処理時間も3bモデルであれば十分速く、7bモデルからの劣化も僅かです。

SDXLの場合はHires.fixで書き込みを増やすほうが良い気がしますが、Animaの場合はHires.fixで書き込みがあまり増えないので、Hires.fixでいろいろ悩むくらいならSeedVR2を使うのもありだと感じました。
Forge NeoのSeedVR2拡張機能について確認したほうがよいかも。

それにしてもアップスケールは沼ですね・・・。

最後に、
この記事をForge Neo開発者のHaoming02氏に捧げます。

https://github.com/Haoming02/sd-webui-forge-classic/issues/1238 より
ほとんどの人がPiDはク○という結論に達したことについて
Forge NeoのPiD対応のため3週間を無駄に費やしたことを嘆くコメント

このような感じで、技術的な内容を分かりやすく基本無料で解説しています。「スキ」「フォロー」「チップ」で応援よろしくお願いします。質問がありましたら遠慮なく「質問箱」へどうぞ。

関連記事

いいなと思ったら応援しよう！