每一秒，都有出處。每一秒，都有出處。

1. 01

   6.0–6.4×

   原版 50 步 ÷ PAI 8

   加速方式比精度重要

   PAI 8 步比原版 50 步快 6.0–6.4 倍；同一種加速下，INT8 只比 FP8 快 3.6–10.2%（以去噪運算時間計；都是單一 seed 的單次冷呼叫，小差距僅供參考）。

   看數據
2. 02

   600.5 → 297.2 s

   一段的總時間

   成本在參考素材，448 砍半

   換角 run 裡，參考影片佔 DiT 序列 47%。把參考影片前處理成 448，一段從 600.5 s 降到 297.2 s。

   看數據
3. 03

   15.91 / 15.92 GiB

   整卡 NVML 峰值

   16 GB 放得下，但很勉強

   有參考素材時 DiT 保留最多 13.6 GiB，整卡峰值 15.91／15.92 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，遠超過 16 GB 的卡在 DiT 旁還挪得出的空間。參考影片編碼從 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

   失敗照實列出

   3 個 NF4 DiT 載入失敗、Turbo 4 送 8 步被拒、768 參考影片放 3 個角色 OOM、BF16 phase 生圖被准入拒絕：全部在表裡。

   看數據

時間單位為秒，VRAM 為 GiB（2^30 bytes）。同時執行的步驟（影片與音訊解碼、參考影片與音訊編碼）重疊，所以步驟相加會超過總時間。

10/18 實測每項各一次網頁版已做響度正規化；原始輸出約 −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 階段（所有去噪步）從開始到結束的實際經過時間（wall time），包含 AdaLN 準備、輸入組裝與釋放。本頁預設用這個。

去噪運算

Recorder 的 h3.denoise_av.compute_ms，只有去噪迴圈。舊報告引用的是這個，所以列成次要欄位。

端對端

從建立 run 到完成的實際經過時間（wall time）。只有所有步驟都在同一個 run 裡跑完時才列；沿用其他 run 的步驟時標「非端對端」。

裝置

每一步的裝置取自 run 紀錄的 node 與 resource group；封存裡沒有就標「未記錄裝置」，不推測。

GiB 與 GB

RTX 5080 與 RTX 3060 的 VRAM 一律用 GiB（2^30 bytes）；DGX Spark 的記憶體數字（meminfo 與 torch 峰值）一律用 GB（10^9 bytes）並標明。

torch 與 NVML

allocated／reserved 是 DiT 程序的 PyTorch 峰值；整卡 NVML 以 2 Hz 取樣，含其他程序的 CUDA context，是下限值。

1. 01DiT 基準：40 個 H3 DiT 變體哪個 DiT 變體最快、最省 VRAM？量化、加速與 AdaLN 設定會不會改變輸出？2026-10-17

   同一份文字條件、同一組參考 latent、同一個 seed（42），只換 DiT 變體：FP8／INT8／BF16／NF4 × 原版 50 步／PAI 8／Turbo 8／Turbo 4，加上 attention 與 AdaLN 設定，涵蓋純文字（t2va）與兩張角色圖（ref2va），768×448、124 幀。載入成功的 DiT 都在 RTX 5080 以逐層串流執行。測了 40 個 DiT 變體；37 個成片，3 個 NF4 變體載入失敗。文字條件由 DGX Spark 的 te-gb10 算一次、所有變體共用。

   結論

   • 速度先看加速方式、再看量化：同一種加速下 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 三個變體載入失敗：量化權重缺 comfy_quant 中繼資料，釘版 loader 拒絕。

   注意事項

   • 每個情境一個提示詞、一個 seed；只量載入後第一次呼叫，載入時間受 page cache 影響。
   • 文字與參考編碼只算一次並沿用，所以每列的 run 時間只含 DiT＋解碼＋封裝，不是端對端。
   • 兩張參考圖是透明 PNG，透明區送進模型時變黑，所以貼圖特別明顯。

   速度表中 40 列 →
2. 02換角實驗 R1–R6能不能用兩張角色圖，把參考影片裡的兩個角色換掉？哪種 prompt 有效、要花多久？2026-10-18

   ref2va-pc：文字編碼在 DGX Spark 的 te-gb10，參考影片編碼在 RTX 5080（R3／R6 系列在 RTX 3060），參考聲音編碼與聲音解碼在 RTX 3060，DiT 與影片解碼在 RTX 5080。比較 prompt 寫法、透明與白底角色圖、PAI 8 與 Turbo 4（seed 42、768×448、124 幀）。

   結論

   • prompt v1（參考影片 fully_preserved）會照抄原角色外觀（R1、R2）；v2 把影片當成只取運鏡與動作的 weak_reference，並明寫要換的服裝，兩個角色都換成功（R5）。
   • PAI 8＋2 張圖＋5.17 秒參考影片：DiT 456.6–480.6 s，整段 581.8–607.4 s；DiT 序列 79,296–80,832 列，約是只有兩張圖時（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；換角品質是目視判斷。
   • R3 系列的參考影片在 RTX 3060 編碼，venc 時間不能和 R1／R2／R5 直接比較。
   • 這些 run 的 te-gb10 仍載著兩份文字編碼器（實驗 11 修正），文字編碼的記憶體數字偏高。

   速度表中 7 列 →
3. 03VAE 常駐 vs 按需載入RTX 5080 上的影片 VAE 程序要一直載著，還是用時才啟動？2026-10-18

   vae-5080（影片解碼）與 venc-5080（參考影片編碼）的權重放在 pinned 主記憶體，每次呼叫才搬上 GPU。比較三種配置：兩個都常駐、只停 venc、兩個都停，量冷啟動、第一次與暖呼叫、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 vs 常駐 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 是由冷啟動與第一次呼叫的差加總的估算，不是一次端對端量測。
   • 「常駐」是程序與 CUDA context（各約 0.9 GiB）留在 5080，權重每次呼叫才搬上 GPU。
4. 04Turbo 4 固定 AdaLNTurbo 4 改用預先計算的 AdaLN 後，能不能在兩個 VAE 常駐時放進 RTX 5080？輸出會變嗎？2026-10-18

   為 Turbo 4（INT8、lx4 LoRA）建立 465 MB 的 AdaLN 預先計算檔，不必每次線上計算；在 R2、R5 的條件下量 VRAM 與 DiT 時間，並與線上版逐值比對 latent。

   結論

   • 兩個 VAE 常駐也放得下：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 vs 1.61 GiB。
   • 與 online 版的 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 時，每段最多幾幀、幾個角色放得進 RTX 5080？2026-10-18

   在兩個 VAE 常駐的正式配置下跑完整 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。
   • 三個 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 對照組與 R5 逐位元相同，以及 Studio 介面與 MCP 的結果相同。

   結論

   • 一段總時間 600.5 → 297.2 s；DiT 470.7 → 223.9 s（每個去噪步 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）：角色與服裝保留、切鏡點一致；動作較收斂（逐幀變化中位數 3.02 vs 4.02，原片 6.22），嘴型較小。
   • 768 對照組的 latent 與解碼影片和 R5 逐位元相同；Studio 介面與 MCP 跑出的 448 結果逐位元相同。

   注意事項

   • 畫質只看了一個 seed；448 在其他 seed 會不會漏衣服還沒測。
   • R5 的文字編碼是暖呼叫，768 對照組是重啟後第一次（79.9 s），所以總時間用 R5 比較。

   速度表中 3 列 →
7. 07參考影片 448 的換角上限參考影片 448 時，每段能多長、能放幾個角色？2026-10-18

   參考影片 448、PAI 8、seed 42，在兩個 VAE 常駐的正式配置下測 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 角色每段最多 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 是完整 pipeline，其餘沿用 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）。

   注意事項

   • 四個 seed 不是失敗率；漏衣服的程度是目視分級。

   速度表中 6 列 →
9. 09外部參考成本分析的核對一份外部分析說參考素材讓 ref2va 變慢，它說的對不對？成本到底在哪裡？2026-10-18

   逐條對照外部分析與程式碼、run 紀錄與 payload：拆解 R1 的 DiT 序列組成，用 8 個 run 擬合每步時間與序列長度的關係，並列出 2026-10-17 的 E1–E4 基準 run。

   結論

   • 大方向正確，但 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 主要在等同一份檔案下載。文字編碼拆成兩步、成本紀錄與 reference_video_short_edge 參數（實驗 06）已實作。

   注意事項

   • 時間模型只適用 RTX 5080、FP8 · PAI 8、768×448×124 的目標；「只換 seed 時沿用條件編碼約省 100 s」是推算，尚未實作與量測。

   速度表中 5 列 →
10. 10前端與 MCP 實測實際用介面與 MCP 操作一個完整實驗，會遇到哪些問題？2026-10-18

    用實際安裝的 MCP 與 Studio 介面準備並執行實驗 06 的 448 實驗，記錄遇到的所有問題，並比對兩條路徑的輸出。

    結論

    • 第一階段 26 個問題，其中 3 個 major（MCP 丟掉大輸出、看不到 run 的輸入、推理頁素材順序與 Studio 不同），都已修正。
    • 第二階段新發現 7 項，例如 latent 雜湊含載入中繼資料、聲音元件冷呼叫數值不可重現、文字編碼重啟後第一次慢約 50 s；其中 2 項已修。
    • 介面跑與 MCP 跑的 448 結果逐位元相同。

    注意事項

    • 截圖是改名前的舊介面，所以不公開；網站的操作影片另外以英文介面錄製。
11. 11Spark 反推記憶體圖片反推放在 DGX Spark、和常駐的 te-gb10 共存，記憶體夠不夠？2026-10-18

    把圖片反推（qimg-vision-gb10，Qwen3-VL-4B BF16）放到 DGX Spark 與 te-gb10 共存；修正部署後實測記憶體、載入與呼叫時間，並修正 te-gb10 跑 ref2va 時重複載入文字編碼器的問題。

    結論

    • 修正前 te-gb10 跑過 ref2va 後會再載入一份相同的文字編碼器，多佔 51.5 GB；共用後只有一份，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，不含可回收的 page cache）。
    • 反推 4B：載入 62.5 s、圖說 5.3 s、分析 85.8 s；與 te-gb10 並存時 MemAvailable 最低 57.29 GB，常駐約多佔 11.6 GB。

    注意事項

    • DGX 的記憶體數字是 GB（10^9 bytes）；兩者並存時 te-gb10 的 ref2va 峰值只有推算，沒有實測。
    • 反推的圖說有錯（把水平拉坯紋寫成垂直條紋），品質只看了一張圖。

    速度表中 2 列 →
12. 12圖片生成驗證（Qwen-Image 2.1）RTX 5080 上的 Qwen-Image 2.1 與作者先前的圖片工具 DiT Studio 輸出是否一致？影片元件常駐時放不放得下？2026-10-18

    第一次 GPU 驗證：30 個 run（28 個經 API、2 個經 Image Studio）。逐像素比對 8 個歷史案例，量 BF16 phase、BF16 stream 與 Qwen-Image GGUF Q4_K_M 三種 DiT 變體的時間與 VRAM、VAE 的 full 與 tiled 解碼，以及中間預覽的代價。GPU 步驟都在 RTX 5080，合成在 CPU。

    結論

    • 8 個案例與 DiT Studio 的輸出 RGBA 逐像素相同（最大差 0）；BF16 phase 與 stream 的 latent 逐位元相同，批次與介面的圖也與單張 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 每步時間不變（713.8 vs 712.7 ms），主記憶體多 1.26 GiB。

    注意事項

    • GGUF 路由是 Q4_K_M 微調權重，不是原版權重；圖片反推不在這次範圍。
    • 逐 run 的數字取自封存的比較頁（原始 run 紀錄不在封存內）。

    速度表中 17 列 →
13. 13生圖 DiT 修正驗證呼叫後釋放 CUDA 快取之後，BF16 stream 能不能在正式狀態完整跑完？2026-10-18

    修正「每次呼叫後釋放 CUDA 快取、失敗時先清 frame」後，在 RTX 5080 正式狀態（H3 的 vae-5080／venc-5080 常駐）重跑實驗 12 失敗的 t2i-pc：同一個 prompt（陶杯）、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 每步 p50 只多 9.0 ms（+1.1%），端對端 43.0 s（文字編碼程序已暖）。
    • 已設定：t2i-pc 與 i2i-pc 改用 BF16 stream，並開啟預覽 VAE。

    注意事項

    • i2i、批次 4 張與 1536² 還沒在修正後的 GPU 上複驗；預覽縮圖的格狀紋理來自預覽方法本身。

    速度表中 2 列 →