こんにちは、パレイド技術部です。
前回 4/16 は Juggernaut XL Jugg_XI by_RunDiffusion (通常版) を取り上げ、Ragnarok と「品質ほぼ同等・構図素直・1 段速い」というキャラ分けが見えました。
1 世代前のJugg_XI をわざわざ選ぶ最大の理由は、ここに公式 Lightning 派生があること。
本記事ではその Jugg_XI Lightning by_RD において、30 step → 4 step の蒸留チェックポイントで、Jugg_XI の絵柄がどこまで保たれるか。前回と完全に同じプロンプト・同 seed で 9 枚並べて比較します。
このチェックポイントは「RunDiffusion 作者推奨」と「ByteDance SDXL-Lightning 公式」という 2 系統の推奨パラメータが存在します。本記事では両方を実測して 同じ画像を 2 セット並列で並べる 構成にしました。
本記事はローカル LLM による自動執筆パイプラインで生成されました。現段階ではクラウド AI（Claude 等）の補助や人間の編集が介在していますが、pareido.jp では最終的に AI が自律的にコンテンツを制作できる仕組みの構築を目指しています。
派生の出自 — SDXL-Lightning 4-step 蒸留
Jugg_XI by_RunDiffusion (通常版) に ByteDance の SDXL-Lightning 4-step LoRA をマージしたのが本記事の主役です。
| 項目 | 値 |
|---|---|
| ベース | Jugg_XI by_RunDiffusion |
| 蒸留方法 | SDXL-Lightning 4-step LoRA をマージ |
| 配布 | CivitAI version 920957 |
| ファイル | juggernautXL_juggXILightningByRD.safetensors (約 6.6 GB) |
SDXL-Lightning は SDXL の 4-step / 8-step 化を狙う蒸留手法で、通常 30 step を 4 step に圧縮しつつ品質を保つことを目標としています。
Juggernaut ファミリーで Lightning 派生が公式に出ているのは V9+RDPhoto2 と XI の 2 系統のみで、最新の Ragnarok には Lightning がありません。Lightning に蒸留できる SDXL の “現役最終世代” が、この XI 系です。
比較方針 — 「2 つの公式」推奨値を試す
このチェックポイントの推奨パラメータはRunDiffusionから発表されていますが、技術的にはByteDanceのLightning系にあたるため、より「攻めた」系統として、そちらも試してみたいと思います。
| 推奨元 | Sampler | Scheduler | CFG | Steps | 狙い |
|---|---|---|---|---|---|
| RunDiffusion 作者 (CivitAI) | DPM++ SDE | karras | 1-2 | 4-6 | merge モデルの画質を引き出す正攻法 |
| ByteDance Lightning 公式 | Euler | sgm_uniform | 0 (厳密) / 1 (実用下限) | 4 | 蒸留 LoRA の最大速度を引き出す |
本記事はチェックポイントレビューなので、RunDiffusion 作者推奨を主、ByteDance Lightning 公式を補足ベンチとして併記します。連載統一の固定値は:
- RunDiffusion 側: DPM++ SDE / karras / CFG=1.5 (推奨レンジ 1-2 の中央) / 4 step
- ByteDance 側: Euler / sgm_uniform / CFG=1.0 / 4 step
ByteDance 側が CFG=0 ではなく 1.0 なのは、Juggernaut Lightning が merge モデルだから。実測すると CFG=0 は意味不明な文字列だけが浮かぶほぼ白画像で破綻します (Juggernaut 本体が CFG > 1 前提で訓練されているため、unconditional 経路だけでは成立しない)。実用下限は CFG=1.0 になります。
ライセンス差分
通常版 Jugg_XI と同じ CreativeML Open RAIL++-M ライセンス。SDXL-Lightning の LoRA は ByteDance が Apache-like な許諾で公開していて、本ファイルは Juggernaut 本体の RAIL++-M に統合されています。
| 軸 | 判定 | 通常版との差分 |
|---|---|---|
| 商用利用 | ○ | 同じ |
| 生成物の販売 | ○ | 同じ |
| モデル再配布 | ○ | 同じ |
| 派生 (merge / LoRA) | ○ | 同じ |
| 学習データ透明性 | △ | 同じ (merge ベース慣習) |
| pareido.jp で安心して使えるか | ○ | 同じく安心 |
派生による条項の追加・縮小はありません。「Lightning だから商用 NG」 (= DreamShaper XL Turbo の SDXL Turbo Non-Commercial 継承のような事例) という注意点は本派生では発生しない点が重要です。
環境とセットアップ
| 項目 | 値 |
|---|---|
| GPU | RTX 4070 12GB |
| ComfyUI | 0.19.3 / PyTorch 2.11.0+cu130 |
| ファイル | juggernautXL_juggXILightningByRD.safetensors (約 6.6 GB) |
入手先は前章の「派生の出自」表に記載 (CivitAI version 920957)。
ベンチマーク 主軸 — RunDiffusion 作者推奨 (DPM++ SDE / CFG=1.5)
連載統一条件 + RunDiffusion 推奨 上書き:
| 項目 | 通常版 (4/16 Jugg_XI) | Lightning RD 推奨 (本記事 主軸) |
|---|---|---|
| seed | 42 | 42 (同じ) |
| 解像度 | 1264 × 848 | 同じ |
| ネガティブ | (連載既定) | 同じ |
| サンプラ | dpmpp_2m / karras | dpmpp_sde / karras |
| steps | 30 | 4 |
| cfg | 4.0 | 1.5 |
判定軸: ○ 安定 / △ ばらつき or 品質懸念 / × 破綻・OOM
| プロンプト | GPU 占有 | 生成秒 | 結果 (RD 推奨) | 通常版 4/16 結果 | 所見 |
|---|---|---|---|---|---|
| 01_workspace_en (英語写実) | ~5.0 GB | 8.9 s | ○ | ○ (26.8 s) | 暖色照明、モニタにグラフ・ワールドマップ・データ表示が明確に乗る。通常版に近い描き込み密度 |
| 02_workspace_ja_title (日本語タイトル) | ~4.2 GB | 6.9 s | × | × (41.7 s) | 「縎詞〒卞」風の崩壊文字。SDXL の日本語限界は変わらない。ただし 2 枚額装 + 植栽 + 椅子の構図密度は通常版に近い |
| 03_abstract_neural (抽象 + 中央空け) | ~5.0 GB | 7.1 s | △ | △ (36.1 s) | 中央空け指示に近づく構図、ニューラル網の密度は十分。アイキャッチ用途で実用 |
| 04_comic_panel (マンガ調 + 「実測！」) | ~4.8 GB | 7.2 s | △ | △ (31.8 s) | キャラ + ヘッドフォン + 吹き出しの構図維持。背景モニタや机上の小物まで通常版に近い |
| 05_iso_cityscape (アイソメ) | ~5.0 GB | 6.0 s | ○ | ○ (30.4 s) | サーバラックが整然と並んだ「データセンター」構図。プロンプト忠実度高い |
| 06_poster_mixed (日英混在ポスター) | ~4.8 GB | 8.7 s | × | × (32.7 s) | ノート画面に “ernie” 風の文字断片、テキストは崩壊だが書こうとした形跡は残る |
実際の出力 (RunDiffusion 推奨 4-step)
ベンチマーク 補足 — ByteDance Lightning 公式 (Euler / CFG=1.0)
Lightning 蒸留 LoRA を最大速度で引き出す ByteDance 公式案内に近い設定。RD 推奨と比べて 約 2 倍速になりますが、描き込み密度は一段控えめになります。
| 項目 | RD 推奨 (本記事 主軸) | BD 公式 (補足ベンチ) |
|---|---|---|
| サンプラ | dpmpp_sde / karras | euler / sgm_uniform |
| cfg | 1.5 | 1.0 |
| プロンプト | GPU 占有 | 生成秒 | 結果 (BD 公式) | 所見 |
|---|---|---|---|---|
| 01_workspace_en | ~5.1 GB | 3.9 s | ○ | 暗めの色調、モニタは控えめだが構図は通常版と同等 |
| 02_workspace_ja_title | ~5.1 GB | 3.2 s | × | 「凡腲冄艮」風の崩壊文字、構図はシンプル化 |
| 03_abstract_neural | ~5.1 GB | 3.0 s | △ | 中央空け指示に近づくが、ニューラル網の密度は RD より一段薄い |
| 04_comic_panel | ~5.0 GB | 3.7 s | △ | キャラの構図は維持、背景のモニタ等は簡素 |
| 05_iso_cityscape | ~5.0 GB | 3.4 s | ○ | サーバラック感は薄れ、ミニチュアの都市寄り |
| 06_poster_mixed | ~5.1 GB | 3.7 s | × | ノート画面はピンク単色、文字は描かない (RD 側より省略強い) |
実際の出力 (ByteDance 公式 4-step、補足)
結果のサマリ — RD は実用性あり、BD は速度二倍で描き込み一段控えめ
判定の比率は両パターンとも通常版と同じ (○ 2 / △ 2 / × 2)。4-step 蒸留でも構図・トーン・破綻有無の傾向は通常版と一致しており、6 プロンプトを横断して両設定とも用途によっては実用に耐えるといった内容です。
通常盤から差が出るのは、主に描き込みの密度です。
- モニタ画面のグラフやテキスト (01) — RD は通常版に近い、BD は控えめ
- 構図の作り込み・小物 (02, 04) — RD は植栽や椅子まで描く、BD はシンプル化
- 抽象表現の密度 (03) — RD は線が太く明瞭、BD はやや薄い
- アイソメの機械ディテール (05) — RD は「サーバラックが整然と並ぶ」、BD は「ミニチュア都市」寄り
- 画面の中身など「絵の中の絵」 (06) — RD はテキストを描こうとする、BD は完全省略
つまり、RD 推奨は通常版の描き込みを 4-step でかなり保つ、BD 公式はそれをさらに 2 倍速にする代わりに描き込み密度が一段下がる、という構図です。
| 観点 | 通常版 (30 step) | RD 推奨 (4 step) | BD 公式 (4 step) |
|---|---|---|---|
| 1 枚平均生成秒 (連載 6 プロンプト) | ~33 秒 | ~7.5 秒 (約 4-5 倍速) | ~3.5 秒 (約 9-10 倍速) |
| 描き込み密度 | ◎ | ○ (通常版に近い) | △ (一段控えめ) |
| アイキャッチ最終仕上げ | ◎ | ○ | △ |
| 試行錯誤・量産 | △ (重い) | ○ | ◎ (1 枚 3 秒台) |
| GPU 占有 | 4-5 GB | ~5 GB | ~5 GB |
強みを引き出す例 — 写実ポートレートで 4-step に何が残るか
通常版 4/16 で文句なし ○ だった写実ポートレート 3 種を、両パターンで再走しました。
| プロンプト | 通常版 4/16 (30 step) | RD 推奨 (4 step) | BD 公式 (4 step) |
|---|---|---|---|
| 07 クローズアップポートレート (肌・自然光) | ○ (32.6 s) | ○ (7.9 s) — そばかす・産毛・髪のほぐれを維持 | ○ (4.1 s) — 滑らかでイラスト寄り、写真的密度は薄い |
| 08 環境ポートレート (霧 + 逆光) | ○ (32.9 s) | ◎ (10.5 s) — 山肌・草地・服のテクスチャまで写真的、人物は 1 人 (プロンプト忠実) | △ (3.8 s) — 大気感は維持、ただし人物が 2 人になりプロンプトと不一致 |
| 09 ドラマティック光線 (レンブラント) | ○ (32.5 s) | ○ (8.6 s) — 老職人の表情・服のシワ・暗部質感が通常版に近い | ○ (3.8 s) — 顔の質感維持、机に道具らしき小物まで描く |
実際の出力 (RunDiffusion 推奨 4-step、写実 3 枚)
実際の出力 (ByteDance 公式 4-step、写実 3 枚 補足)
3 枚とも構図・顔・トーンは通常版と同等で、両パターンとも実用品質としては十分 ○ で出ます。差が出るのは肌の毛穴・服や背景のテクスチャ・暗部の道具など、写真としての密度を底上げする細部です。
おもしろいのが 08。RD 推奨は「young man」(単数) というプロンプトに正しく 1 人で応えますが、BD 公式は 2 人になってプロンプト忠実度が落ちました。速度を取りに行くほどプロンプト追従性も若干落ちる、というのが横断観察です。
3 枚で RD 合計 27 秒 / BD 合計 11.7 秒、通常版 30 step で同 3 枚を生成する約 98 秒に対して RD 約 3.6 倍速 / BD 約 8.4 倍速。試行錯誤やガチャでの量産は BD、最終仕上げで細部を最大化したい 1 枚は RD または通常版 (Ragnarok / Jugg_XI 30 step) という三段運用が現実的です。
通常版 vs Lightning RD vs Lightning BD 使い分け
| 場面 | 通常版 Jugg_XI (30 step) | Lightning RD 推奨 (4 step) | Lightning BD 公式 (4 step) |
|---|---|---|---|
| 1 枚あたり生成所要 | ~33 秒 | ~7.5 秒 (約 4-5 倍速) | ~3.5 秒 (約 9-10 倍速) |
| 日常的なアイキャッチ生成 | ○ | ◎ | ○ |
| 試行錯誤のプロンプト調整 | △ (時間がかかる) | ○ | ◎ (1 枚 3 秒台) |
| ガチャ的に多数候補生成 → 最良を選別 | △ | ○ | ◎ (10 枚で 35 秒) |
| プロンプト追従性 (構図・人数指示) | ◎ | ○ | △ (08 で人数を取り違える例) |
| 品質を最大化したい最終仕上げ 1 枚 | ◎ | ○ (通常版に近い) | △ (描き込みが一段控えめ) |
| 中央空けレイアウトのプレビュー | △ | ○ | ○ |
Lightning RD 推奨が「品質と速度のバランス点」、Lightning BD 公式が「ガチャ用の最速モード」、通常版が「最終仕上げの描き込み」 という三段構成で運用するのが、画質と時間の両方で得をする現実解です。
棚での位置づけ + 注意事項
Lightning 4S は 2 つの推奨設定どちらでも実用品質を出す、というのが本記事の評価です。本連載の SDXL 棚では:
- 試行錯誤・ガチャ・量産は Lightning BD (Euler / CFG=1.0) — 1 枚 3.5 秒で 10-30 枚回せる、当たり構図を引くまでが最速
- 日常的なアイキャッチや「Lightning 一発で仕上げたい時」は Lightning RD (DPM++ SDE / CFG=1.5) — BD の倍の時間 (1 枚 7.5 秒) と引き換えに描き込みが通常版に肉薄
- 品質を最大化したい最終仕上げは Ragnarok または Jugg_XI 通常版 — 同じ seed・同じプロンプトで切り替えれば、Lightning で見えた構図に最大密度の細部が乗る
という運用が、画質と時間の両方で得をする現実解です。SDXL-Lightning の蒸留を merge モデルから引き出す条件として CFG ≥ 1.0 / Steps=4 を守ることは必須です (CFG=0 では merge モデルが文字列だけのほぼ白画像で破綻、CFG > 2.0 で速度メリットが大幅に落ちる)。
「Ragnarok = SDXL の卒業証書」「Jugg_XI = 引退寸前の現役」「Jugg_XI Lightning = 同じ系統の高速版 (RD = 高品質モード / BD = 最速モード)」という 3 段 + Lightning 内 2 モードの構成が、SDXL 棚としては綺麗にまとまります。
次回予告
ここまでで Juggernaut XL ファミリーの「Ragnarok (4/15) → Jugg_XI (4/16) → Jugg_XI Lightning (4/17)」の 3 連発が完結しました。次回 4/19 からは別ファミリー、RealVisXL V5.0 (写実中心、pareido.jp 現行 eyecatch のベース) に移ります。同じく初日 = 概観 + メイン版評価、翌日 = Lightning 派生という構造で続けます。
Lightning 4S は 「速さと品質の二段構え (RD / BD) で安心して棚に置ける」 というのが本記事の判定です。次回は写実 eyecatch 本番運用のチェックポイントに切り替えます。
