一秒も、うやむやにしない。一秒も、うやむやにしない。

1. 01

   6.0–6.4×

   オリジナル 50 ÷ PAI 8

   精度より高速化方式

   PAI 8 はオリジナル 50 ステップより 6.0–6.4 倍速く、同じ高速化なら INT8 は FP8 より 3.6–10.2% 速いだけです（ノイズ除去の計算時間。いずれもコールドの単発・seed 1 つなので、小さな差は目安です）。

   データを見る
2. 02

   600.5 → 297.2 s

   1 セグメントの合計

   コストは参照素材、448 で半分

   差し替えの run では参照動画が DiT シーケンスの 47% を占めます。参照動画を 448 に前処理すると、1 セグメントが 600.5 s から 297.2 s になりました。

   データを見る
3. 03

   15.91 / 15.92 GiB

   カード全体の NVML ピーク

   16 GB に収まる、ただしぎりぎり

   参照ありでは DiT が最大 13.6 GiB を確保し、カード全体のピークは 15.92 GiB 中 15.91 GiB です。余裕 1.6 GiB は安全、0.8 GiB は不十分でした。

   データを見る
4. 04

   3.4×

   参照動画のエンコード：RTX 5080 対 RTX 3060

   エンコーダーは、それぞれ合う場所へ

   全精度の Qwen3-VL テキストエンコーダー（te-gb10）は DGX Spark に置いたままです。常駐で約 52 GB、呼び出し中は最大約 60 GB で、DiT と同居する 16 GB のカードにはとても収まりません。参照動画のエンコードは RTX 3060 から RTX 5080 に移し、248–250 s が 72–74 s になりました。

   データを見る
5. 05

   4 / 4

   衣装が漏れた seed

   Turbo 4 は速いが、元の衣装が残る

   差し替えの条件（参照動画 768、キャラクター 2 人）では、Turbo 4 の DiT は 229–236 s（PAI 8 は 466–473 s）ですが、4 つの seed すべてで元のキャラクターの衣装が出力に残りました。そのため本番の ref2va は PAI 8 のままです。

   データを見る
6. 06

   16

   失敗・取り消しの run

   失敗もそのまま載せる

   NF4 の DiT 3 種の読み込み失敗、8 ステップで送った Turbo 4 の拒否、参照動画 768 で 3 人を入れた OOM、BF16 phase の画像生成の事前チェック拒否。すべて表にあります。

   データを見る

時間は秒、VRAM は GiB（2^30 バイト）です。同時に実行するステップ（映像と音声のデコード、参照映像と音声のエンコード）は重なるため、ステップの合計は全体の時間を超えます。

10/18 計測各 1 回Web 版はラウドネスを正規化しています（元の出力は約 −37〜−50 LUFS、AAC 32 kHz）。

AI 生成 · Qwen-Image 2.1

Qwen-Image 2.1 の静止画

AI 生成 · Qwen-Image 2.1

1152×672・40 ステップ。テキストエンコード、DiT、VAE は RTX 5080、合成は CPU です。これらの静止画は fl2va の先頭フレームにも使いました。

• 夜明けの崖26.0 srun 3a6d932d
• ネオンの雨26.9 srun 0e2463b8
• オーロラの海25.9 srun d47c0fa1
• クローズアップ25.8 srun 577fc7a4

この節に映像はありません。差し替え実験の参照動画は第三者の素材のため、そこから派生した出力は公開しません。数値は公開しています。

DiT ステージ（実時間）

DiT ステージ（すべてのノイズ除去ステップ）の開始から終了までの時間で、AdaLN の準備、入力の組み立て、解放を含みます。このページの既定値です。

ノイズ除去の計算

レコーダーの h3.denoise_av.compute_ms で、ノイズ除去ループだけの時間です。古い報告はこの値を引用しているため、補助の列にしています。

エンドツーエンド

run の作成から完了までの実時間です。すべてのステップを同じ run で実行した場合だけ載せ、他の run のステップを再利用した行には「通し計測ではない」と表示します。

デバイス

各ステップのデバイスは run 記録の node と resource group から取っています。アーカイブにない場合は「実行デバイス未記録」とし、推測はしません。

GiB と GB

RTX 5080 と RTX 3060 の VRAM はすべて GiB（2^30 バイト）です。DGX Spark のメモリの値（meminfo と torch のピーク）はすべて GB（10^9 バイト）で表記します。

torch と NVML

allocated／reserved は DiT プロセスの PyTorch ピークです。カード全体の NVML は 2 Hz のサンプリングで他のプロセスの CUDA コンテキストを含み、下限値です。

1. 01DiT ベンチマーク：H3 DiT 40 種どの DiT バリアントが最も速く、VRAM が少ないか。量子化・高速化・AdaLN の設定で出力は変わるか。2026-10-17

   同じテキスト条件・同じ参照 latent・同じ seed（42）で、DiT コンポーネントだけを入れ替えました（FP8／INT8／BF16／NF4 × オリジナル 50 ステップ／PAI 8／Turbo 8／Turbo 4、attention と AdaLN の設定違いを含む）。テキストのみ（t2va）とキャラクター画像 2 枚（ref2va）で、768×448・124 フレームです。読み込めた DiT はすべて RTX 5080 のレイヤーストリーミングで実行しています。DiT コンポーネント 40 種を計測し、37 種が動画を出力、NF4 の 3 種は読み込みに失敗しました。テキスト条件は DGX Spark の te-gb10 で 1 回だけ計算して共有しています。

   結論

   • 速度はまず高速化方式、次に量子化で決まります。同じ高速化なら INT8 は FP8 より 3.6–10.2% 速く、BF16 は 1.6–2.0 倍遅く、オリジナル 50 ステップは PAI 8 より 6.0–6.4 倍遅くなります（ノイズ除去の計算時間）。
   • テキストのみの最速は INT8・PAI 8（DiT 33.2 s、ノイズ除去 26.0 s）で、本番の dit-5080（FP8・PAI 8）は 37.8 s／28.9 s です。参照ありの最速は INT8・Turbo 4（83.9 s／74.4 s）、本番の FP8・PAI 8 は 120.9 s／115.5 s です。
   • 実験 01 は 2026-10-17 に、コールドロード直後の初回呼び出しを計測しています。2026-10-18 の本番 run は読み込み済みの DiT による fl2va の呼び出しで 31.7–38.7 s（ウォームになってからは 31.7–33.2 s）、ここでの同じ dit-5080 は 37.8 s です。行の比較は同じ実験の中だけで行ってください。
   • AdaLN モードと使用後の解放（host／drop）は出力を変えません（デコード後の MD5 が一致）。ただし online の AdaLN は呼び出しごとにステップ外で 23–32 s 余分にかかります（fixed 2–8 s、off 2–3 s）。
   • 参照ありでは PAI 8 と Turbo 8 が黒背景の参照画像を画面に貼り付けました（124 フレーム中 21–22、37–43 フレーム）。Turbo 4 とオリジナルは 0 フレームです。NF4 の 3 種は、量子化重みに comfy_quant メタデータがなくローダーに拒否されました。

   注意点

   • 各条件でプロンプト 1 つ・seed 1 つです。計測は読み込み直後の 1 回目の呼び出しのみで、読み込み時間はページキャッシュの影響を受けます。
   • テキストと参照のエンコードは 1 回だけ計算して再利用したため、各行の実行時間は DiT＋デコード＋多重化だけで、エンドツーエンドではありません。
   • 参照画像 2 枚は透過 PNG で、モデル入力時に透過部分が黒くなるため、貼り付けが特に目立ちます。

   速度表の 40 行 →
2. 02キャラクター差し替え実験 R1–R6キャラクター画像 2 枚で参照動画の 2 人を差し替えられるか。どのプロンプトが有効で、どれだけ時間がかかるか。2026-10-18

   ref2va-pc で実行しました。テキストエンコードは DGX Spark の te-gb10、参照動画のエンコードは RTX 5080（R3／R6 系列は RTX 3060）、参照音声のエンコードと音声デコードは RTX 3060、DiT と映像デコードは RTX 5080 です。プロンプトの書き方、透過と白背景のキャラクター画像、PAI 8 と Turbo 4 を比較しました（seed 42、768×448、124 フレーム）。

   結論

   • プロンプト v1（参照動画を fully_preserved）は元のキャラクターの外見まで写しました（R1、R2）。v2 は動画をカメラと動きだけの weak_reference にして差し替える衣装を明記し、2 人とも差し替えに成功しました（R5）。
   • PAI 8＋画像 2 枚＋参照動画 5.17 秒で、DiT 456.6–480.6 s、全体 581.8–607.4 s でした。DiT のシーケンス長は 79,296–80,832 行で、画像 2 枚だけの場合（35,136）の約 2.3 倍です。
   • 参照動画のエンコードは venc-5080 で約 71.9–73.7 s、venc-3060 で約 247.6–250.2 s だったため、本番の流れは RTX 5080 に切り替えました。
   • Turbo 4 は失敗しました。R3／R6 はパイプラインが 8 ステップ固定のため LoRA のサンプリング契約に拒否され（INVALID_ARGUMENT）、R3b は DiT で GPU_OOM（追加 1.08 GiB が必要、空き 1.07 GiB）、R6b は途中で取り消しました。

   注意点

   • seed は 1 つだけで、差し替えの品質は目視による判断です。
   • R3 系列は参照動画を RTX 3060 でエンコードしたため、venc 時間は R1／R2／R5 と同列に比べられません。
   • これらの run の te-gb10 はテキストエンコーダーを 2 つ読み込んでいたため（実験 11 で修正）、テキストエンコードのメモリ値は高めです。

   速度表の 7 行 →
3. 03VAE：常駐かオンデマンドかRTX 5080 上の映像 VAE プロセスは読み込んだままにするか、使うときだけ起動するか。2026-10-18

   vae-5080（映像デコード）と venc-5080（参照動画エンコード）の重みは pinned メモリに置き、呼び出しのたびに GPU へ転送します。両方常駐、venc だけ停止、両方停止の 3 構成で、コールドスタート、初回とウォームの呼び出し、DiT の速度、空きメモリを比較しました。

   結論

   • オンデマンド読み込みはレンダリングごとに約 24–27 s 増えます（見積もり。コールドスタートは vae-5080 11.9–15.8 s、venc-5080 8.6–10.7 s、初回呼び出しはデコード +1.1–1.8 s、エンコード +0.8 s）。
   • DiT の速度は変わらず（ノイズ除去 463.2 s、常駐時 463.8–464.3 s）、latent はビット単位で一致しました。利点は DiT 中の空きメモリが 19.1 → 34.3 GiB に増えることだけなので、常駐を維持しました。
   • Turbo 4（online AdaLN）＋参照動画は両方の VAE を止めたときだけ収まりました。DiT 252.8 s、カード全体の余裕は約 0.3 GiB で、venc だけ止めた構成では GPU_OOM でした。

   注意点

   • 24–27 s はコールドスタートと初回呼び出しの差を足し合わせた見積もりで、1 回のエンドツーエンド計測ではありません。
   • 「常駐」とはプロセスと CUDA コンテキスト（各約 0.9 GiB）が 5080 に残ることで、重みは呼び出しごとに GPU へ転送します。
4. 04Turbo 4 と AdaLN の事前計算Turbo 4 で事前計算した AdaLN を使えば、VAE 2 つを常駐させたまま RTX 5080 に収まるか。出力は変わるか。2026-10-18

   Turbo 4（INT8、lx4 LoRA）用に 465 MB の AdaLN 事前計算ファイルを作り、毎回のオンライン計算をなくしました。R2・R5 の条件で VRAM と DiT 時間を計測し、オンライン版と latent を値ごとに比較しました。

   結論

   • VAE 2 つを常駐させても収まりました。DiT 229.3–235.3 s（PAI 8 は約 470 s）、torch allocated／reserved は 11,644／13,070 MiB（PAI 8 は 11,418／12,842）、実質の余裕は 1.40 GiB（PAI 8 は 1.61 GiB）です。
   • オンライン版と latent は完全に一致しました（動画 1,193,472 値、音声 13,248 値、最大差 0）。
   • 画質面では seed 42 で元のキャラクターの白いフリルのスカートが漏れ（実験 08 で 4/4 の seed すべてで確認）、ref2va-pc は PAI 8 のままにしました。

   注意点

   • テキストと参照のエンコードは R2／R5 の出力を再利用しているため、ここでの時間は DiT（R5 条件ではデコードも）だけです。

   速度表の 2 行 →
5. 05差し替えの上限（参照動画 768）参照動画 768 のとき、1 セグメントで何フレーム・何人まで RTX 5080 に収まるか。2026-10-18

   VAE 2 つを常駐させた本番構成で ref2va-pc 全体を実行し（seed 42）、PAI 8 と Turbo 4 fixed で 3 人・124 フレームと 2 人・141 フレームを試しました。3 枚目のキャラクター画像は 2 枚目の複製で、メモリと時間だけの確認です。

   結論

   • PAI 8：2 人・124 フレームは可能（余裕 1.61 GiB）。3 人・124 フレームは GPU_OOM（FFN に 2.49 GiB 必要、空き 2.24 GiB）、2 人・141 フレームも GPU_OOM（連続 2.34 GiB が必要、空き 1.55 GiB＋断片化 1.71 GiB）でした。
   • Turbo 4 fixed：3 人・124 フレームは GPU_OOM、2 人・141 フレームは成功しました（DiT 269.9 s、余裕 0.695 GiB）。ただし画質の問題は実験 08 を参照してください。
   • 3 件の OOM はすべて DiT の開始直後（完了ステップ 0）に起きましたが、テキストと参照のエンコードが先に終わるため、失敗した run でもそれぞれ 118.0–133.5 s かかりました。

   注意点

   • 3 人目は複製画像のため、実際の 3 人の画質は表しません。
   • OOM の境界はメモリの断片化に左右され、入力が変われば変わる可能性があります。

   速度表の 4 行 →
6. 06参照動画の短辺を 448 に参照動画の前処理を 448 に下げると、速度・VRAM・画質はどうなるか。2026-10-18

   R5 の条件（PAI 8、2 人、124 フレーム、seed 42）のまま、参照動画の前処理の短辺だけを 768 から 448 に変えました（1280×720 → 800×448）。出力は 768×448 のままです。768 の対照 run が R5 とビット単位で一致すること、Studio の UI と MCP の結果が一致することも確認しました。

   結論

   • 1 セグメントの合計は 600.5 → 297.2 s、DiT は 470.7 → 223.9 s（ノイズ除去 1 ステップの p50 は 57.9 → 27.5 s）、参照動画のエンコードは 73.7 → 28.6 s、DiT のシーケンス長は 80,832 → 52,544 になりました。
   • DiT の torch allocated／reserved は 11.15／12.54 GiB → 8.24／10.40 GiB です。
   • 画質（seed 1 つ）：キャラクターと衣装は保たれ、カット位置も同じです。動きは控えめになり（フレーム間変化の中央値 3.02、768 は 4.02、元動画 6.22）、口の動きも小さくなりました。
   • 768 の対照 run は latent とデコード後の動画が R5 とビット単位で一致し、UI と MCP で実行した 448 の結果もビット単位で一致しました。

   注意点

   • 画質は seed 1 つだけの確認で、448 で他の seed でも衣装が漏れないかは未検証です。
   • R5 のテキストエンコードはウォーム呼び出し、768 の対照 run は再起動後の初回（79.9 s）だったため、合計時間は R5 と比較しています。

   速度表の 3 行 →
7. 07参照動画 448 での差し替え上限参照動画 448 のとき、1 セグメントをどこまで長く、何人まで入れられるか。2026-10-18

   参照動画 448、PAI 8、seed 42 で、VAE 2 つを常駐させた本番構成のまま 2 人 124／141／158 フレームと 3 人 124 フレームを試し、成功した 5 点で VRAM モデルを当てはめました。3 枚目のキャラクター画像は複製です。

   結論

   • すべて成功しました。2 人 124／141／158 フレーム（DiT 223.9／257.4／282.3 s、合計 297.2／339.6／365.7 s）、3 人 124 フレーム（322.5／411.2 s）で、余裕は 4.52／4.16／3.76／3.20 GiB です。
   • VRAM モデル：allocated のピーク ≈ 2,892 MiB＋0.1056 MiB × シーケンス長（5 点の残差 35 MiB 未満）。実測で余裕 1.6 GiB は安全、0.8 GiB は不十分です。
   • 上限はワンクリック差し替えに反映済みです（1–2 人は 1 セグメント最大 158 フレーム、3 人は 124 フレーム）。141 フレームの出力ではショット 1 に元動画の字幕消しのぼかしが写り込みました。

   注意点

   • 3 人目は複製画像です。175 フレーム以上はモデルによる推定のみで計測値ではないため、このページには描いていません。

   速度表の 3 行 →
8. 08Turbo 4 の複数 seed 比較Turbo 4 で元のキャラクターの衣装が漏れるのは毎回起きるのか。2026-10-18

   R5 の条件（参照動画 768、2 人、124 フレーム）で seed 42／7／1234／31337 を使い、PAI 8 と Turbo 4 fixed を比較しました。seed 42 はパイプライン全体、ほかの seed は R5 の条件エンコードを再利用し、DiT とデコードだけを再実行しています。

   結論

   • Turbo 4 は 4/4 の seed で元のキャラクターの白いフリルのスカートが漏れ、4/4 で字幕消しのぼかしも写しました。PAI 8 も漏れますが（明確 1、半透明の残像 2、なし 1）、ぼかしは 0/4 でした。
   • 速度は PAI 8 の DiT が 465.8–472.6 s、Turbo 4 が 229.2–235.5 s でした。
   • 結論として ref2va-pc は PAI 8 のままとし、Turbo 4 の下書きルートは追加しません。速さが必要なら PAI 8＋参照動画 448（DiT 224 s）を使います。

   注意点

   • 4 つの seed は失敗率を示すものではなく、衣装の漏れは目視による段階評価です。

   速度表の 6 行 →
9. 09参照コストに関する外部分析の検証参照素材が ref2va を遅くするという外部分析は正しいか。コストは実際どこにあるか。2026-10-18

   外部分析をコード、run の記録、payload と 1 項目ずつ照合しました。R1 の DiT シーケンスの内訳を分解し、8 つの run からステップ時間とシーケンス長の関係を当てはめ、2026-10-17 の基準 run E1–E4 も並べています。

   結論

   • 大筋は正しいものの、R1 の主なコストは参照画像ではなく参照動画でした。79,268 行のうち参照動画 37,296（47%）、Qwen ビジョン 16,944（21%）、参照画像 10,880（14%）、生成する動画 12,432（16%）、テキストと音声 1,716 です。
   • ステップ時間のモデルは step(L) ≈ 1.68e-4·L＋6.81e-9·L² 秒で、13k–81k 行で誤差は約 ±3% です（RTX 5080、FP8・PAI 8）。
   • 報告の誤り：映像デコードは実際には FP32 で、aenc の 6.98 s は主に同じファイルのダウンロード待ちでした。テキストエンコードの 2 段階化、コスト記録、reference_video_short_edge パラメーター（実験 06）を実装済みです。

   注意点

   • 時間モデルは RTX 5080・FP8・PAI 8・出力 768×448×124 にのみ当てはまります。「seed だけ変えるなら条件エンコードを再利用して約 100 s 節約」は推定で、未実装・未計測です。

   速度表の 5 行 →
10. 10フロントエンドと MCP の実地テストUI と MCP で実験を最初から最後まで操作すると、どんな問題に当たるか。2026-10-18

    実際にインストールした MCP と Studio の UI で実験 06 の 448 実験を準備・実行し、遭遇した問題をすべて記録して、2 つの経路の出力を比較しました。

    結論

    • 第 1 段階で 26 件の問題があり、うち major 3 件（MCP が大きな出力を落とす、run の入力が見えない、推論ページの素材順が Studio と違う）はすべて修正済みです。
    • 第 2 段階では新たに 7 件が見つかりました（latent のハッシュに読み込みメタデータが含まれる、音声コンポーネントのコールド呼び出しが数値的に再現しない、テキストエンコードが再起動後の初回に約 50 s 遅い など）。うち 2 件は修正済みです。
    • UI と MCP で実行した 448 の結果はビット単位で一致しました。

    注意点

    • スクリーンショットは改名前の旧 UI のため公開しません。サイトの操作動画は英語 UI で別途録画しています。
11. 11DGX Spark でのリバースプロンプトとメモリ画像のリバースプロンプトを DGX Spark に置き、常駐の te-gb10 と共存させてメモリは足りるか。2026-10-18

    画像のリバースプロンプト（qimg-vision-gb10、Qwen3-VL-4B BF16）を DGX Spark に置いて te-gb10 と共存させ、修正後にメモリ・読み込み・呼び出し時間を計測しました。あわせて、te-gb10 が ref2va のたびにテキストエンコーダーを重複して読み込む問題も修正しました。

    結論

    • 修正前は te-gb10 が ref2va のあとに同一のテキストエンコーダーをもう 1 つ読み込み、51.5 GB 余分に使っていました。共有後は 1 つだけになり、ref2va 呼び出しのピークは allocated／reserved 56.81／59.66 GB、終了後は 51.69／52.30 GB で、出力は R5 とビット単位で一致しました。
    • GB10 はユニファイドメモリのため、利用可能量は MemAvailable − 4 GiB（64.10 GB）としました。torch の mem_get_info（回収可能なページキャッシュを含まず 8.53 GB）は使いません。
    • 4B のリバースプロンプトは読み込み 62.5 s、キャプション 5.3 s、解析 85.8 s でした。te-gb10 と共存したときの MemAvailable の最低値は 57.29 GB で、常駐させると約 11.6 GB 増えます。

    注意点

    • DGX のメモリ値は GB（10^9 バイト）です。共存時の te-gb10 の ref2va ピークは推定のみで未計測です。
    • キャプションには誤りがありました（横方向のろくろ目を縦縞と記述）。品質の確認は画像 1 枚だけです。

    速度表の 2 行 →
12. 12画像生成の検証（Qwen-Image 2.1）RTX 5080 上の Qwen-Image 2.1 の出力は作者の以前の画像ツール DiT Studio と一致するか。動画コンポーネントを常駐させたまま収まるか。2026-10-18

    初めての GPU 検証で 30 run（API 28、Image Studio 2）を実行しました。過去の 8 ケースをピクセル単位で比較し、BF16 phase・BF16 stream・Qwen-Image GGUF Q4_K_M の 3 つの DiT コンポーネントの時間と VRAM、VAE デコードの full と tiled、途中プレビューのコストを計測しました。GPU のステップはすべて RTX 5080、合成は CPU です。

    結論

    • 8 ケースすべてで DiT Studio の出力と RGBA がピクセル単位で一致しました（最大差 0）。BF16 phase と stream の latent はビット単位で一致し、バッチと UI の画像も単発 run と同一でした。
    • 当時、本番状態で完走したのは GGUF ルートだけでした。BF16 phase は事前チェックで拒否（14.77 GiB 必要、空き 11.66 GiB）、BF16 stream は DiT が完了（1024² で 32.5–33.2 s）した直後に VAE デコードで OOM。原因はテキストエンコードと DiT が呼び出し後に CUDA キャッシュを解放しないことでした。
    • VAE デコードは 1024² の full で 0.74–0.79 s（allocated 7.05 GiB）。tiled ではピンクの細い縦線が出ます。1536² の full は 16 GB のカードでは実行できません。
    • 途中プレビュー（4 ステップごと）は 11/11 枚が出力され、GPU の 1 ステップ時間は変わらず（713.8 ms と 712.7 ms）、メインメモリは 1.26 GiB 増えました。

    注意点

    • GGUF ルートは Q4_K_M の微調整重みで、オリジナルの重みではありません。画像のリバースプロンプトは今回の範囲外です。
    • run ごとの数値はアーカイブ内の比較ページから取っています（元の run 記録はアーカイブにありません）。

    速度表の 17 行 →
13. 13画像 DiT 修正の検証呼び出し後に CUDA キャッシュを解放するようにしたら、BF16 stream は本番状態で最後まで動くか。2026-10-18

    「呼び出しごとに CUDA キャッシュを解放し、失敗時は先にフレームを破棄する」修正のあと、RTX 5080 の本番状態（H3 の vae-5080／venc-5080 常駐）で実験 12 で失敗した t2i-pc を再実行しました。同じプロンプト（陶器のカップ）、1024²、40 ステップ、seed 42、VAE full で、プレビューなしと 4 ステップごとのプレビューを比べました。

    結論

    • 合格です。エンドツーエンド 47.9 s（テキストエンコード 12.15 s、DiT 33.04 s、VAE 1.82 s）、カード全体の NVML ピークは 11,849 MiB で、画像は修正前の参照出力とピクセル単位で一致しました。
    • 4 ステップごとのプレビューでは 11 枚すべてが出力され、GPU の 1 ステップ p50 は 9.0 ms（+1.1%）増えただけで、エンドツーエンドは 43.0 s でした（テキストエンコードのプロセスはウォーム）。
    • 設定済み：t2i-pc と i2i-pc の DiT を BF16 stream に切り替え、プレビュー用の VAE を有効にしました。

    注意点

    • i2i、4 枚バッチ、1536² は修正後の GPU でまだ再検証していません。プレビューの格子状の模様は手法そのものによるものです。

    速度表の 2 行 →