# 三个 15 秒任务耗时差异分析（01:04:27 / 01:04:13 / 00:11:20）

> 数据来源：ComfyUI `/history` 服务端内存历史（3 个任务保留）+ 日志 `Prompt executed` + 输出文件 ffprobe。
> 结论：**三者同为 15s@24fps，但步数、模型档位、后处理完全不同——64 分钟与 11 分钟的差距 = 步数(25→8) × 模型档位(减轻显存) × RTX 放大阶段 三者叠加（≈5.8×）**。

---

## 一、任务参数对比表（历史图完整解析）

| 维度 | 任务 1（Boat15sRTX_00011） | 任务 2（Boat15sRTX_00012） | 任务 3（090453_00001_audio.webm） |
|---|---|---|---|
| 日志耗时 | **01:04:27** | **01:04:13** | **00:11:20** |
| 提交方式（client_id） | `dasiwa-v18-23d4cc91`（**脚本管线**） | `dasiwa-v18-429c212a`（**脚本管线**） | `0fcff0ec-0fcc...`（**Web UI**） |
| 提交时间（CST） | 09-06 13:55:48 | 09-06 13:55:48（同批排队） | 09-06 16:54:04 |
| 时长/帧数 | 15s / **362 帧** | 15s / 362 帧 | **15s**（duration=15） |
| 采样步数 | **25 步** | 25 步 | **8 步** |
| 采样器 | res_multistep / simple / cfg=1.0 | 同左 | **euler / simple / denoise=1.0** |
| 分辨率 | 544×960 基座 → **RTX 2× 放大 → 1088×1920** | 同左 | **544×992 直出（无放大）** |
| UNET | `ref2va_pruned_int8_convrot`（标准 8-bit 权重） | 同左 | `dasiwa_minimax_h3_ref2va_v1_pruned_hybrid_bf16`（**加速混合模型**） |
| CLIP / VAE | NVFP4-AWQ / fp16+fp32 | 同左 | **int4_convrot / int8 VAE**（更省显存） |
| 工作流结构 | Director 单遍 + RTX Upscale + CreateVideo | 同左 | **2× SamplerCustomAdvanced（两遍采样）+ Legacy Director + SeedControl + 双 SigmaShift + ModelAttentionBackend** |

---

## 二、为什么同样是 15s，差 5.8 倍

时间账（64 分钟 ≈ 3840s；11 分钟 ≈ 680s；比值 ≈ 5.6×）：

1. **步数 25 → 8（≈3.1×）**：任务 1/2 是 25 步官方采样（日志实锤 143s/it × 25 ≈ 60 分钟）；任务 3 是 8 步加速采样。采样时间几乎与步数线性相关，这是第一主因。
2. **模型显存档位（每步更快 + 减 offload）**：任务 3 用 dasiwa hybrid bf16（疑似融合加速/蒸馏）+ **int4 CLIP + int8 VAE**，显存占用更小 → 16GB 卡上每步的权重搬运（offload）更少，每步耗时显著低于任务 1/2 的 int8_convrot + NVFP4 组合。
3. **任务 1/2 多一段 RTX 2× 放大**（DaSiWa_RTX_UpscalerRefiner，544×960→1088×1920）：增加约 5–10 分钟 GPU 后处理；任务 3 无放大阶段。
4. 任务 3 虽有两遍采样（2× SamplerCustomAdvanced），总步数仍只有 8 步档，≤ 任务 1/2 的 25 步。

---

## 三、纠正一个关键认知：Boat 系列不是 UI 提交的

- 任务 1/2（64 分钟、25 步、RTX 放大）**全部由 dasiwa 脚本管线提交**（client_id 前缀 `dasiwa-v18-`）——它们就是你之前在 dl-hub `Boat15sRTX` 输出里看到的系列。
- 真正由 **Web UI 提交的任务 3（090453）反而是 11 分钟的加速档**。
- 因此上一轮"UI 提交更稳/更慢"的观感，本质是：**UI 任务恰好用了 8 步 + 加速混合模型（轻量、短时），而脚本任务跑的是 25 步 + RTX 重配置（长时、重载）**——与提交通道无关，与"任务负载档位"直接相关。
- 这也与历史崩溃样本吻合：此前在 sage 启用期崩溃的正是这类 25 步/重载/带后处理的长任务路径；轻量加速任务天然更难暴露问题。

---

## 四、实用结论（怎么让脚本通道也快）

想让 dasiwa 脚本任务也达到 11 分钟档：
1. **降步数**：脚本默认已是 8 步（v18_pipeline steps=8），但 Boat 任务跑了 25 步 → 检查脚本/UI 里是否被覆写成了 25；保持 8 步（或 4 步 Turbo）。
2. **换加速模型**：`dasiwa_minimax_h3_ref2va_v1_pruned_hybrid_bf16`（任务 3 用的）比 `ref2va_pruned_int8_convrot` 每步更快、显存更省，质量差异待对比后定稿。
3. **后处理拆开**：RTX 放大（约 +5–10min）与主生成拆分执行，先出 544×960 草稿再批量放大，或按需才开 RTX。
4. 同样的 15s：**25 步重载 ≈ 60–64min；8 步轻载 ≈ 10–15min**；两者质量差异可在固定 seed 下做一次对比，按场景（草稿 vs 成品）选择档位。

---

## 五、附：数据提取方法（可复现）

```bash
# ComfyUI 服务端内存历史（保留最近任务）：
curl --noproxy '*' 'http://192.168.31.31:8189/history?max_items=8'
# 任务 json 中：prompt[2]=节点图，prompt[3]=meta(client_id/create_time)
# 日志耗时：grep -a "Prompt executed in" /home/zyw/comfyui_h3.log | tail
# 输出参数：ffprobe -show_entries stream=width,height,r_frame_rate,duration <输出.mp4>
```