# UI 提交任务稳定性分析（2026-09-06）

> 背景：用户观察到"在 UI 上提交任务似乎不会遇到黑屏/死机/重启"，要求分析 UI 提交的任务并解释原因。
> 结论先行：**观察属实，但真因与提交通道（UI vs API）无关——是"禁 sage + DPM 修复 + CUDA13"让机器整体恢复了健康**。UI 和 API 提交走同一个 ComfyUI `/prompt` 接口、同一个进程，不存在"UI 更安全"的机制；区别只在任务负载轮廓与并发习惯。

---

## 一、UI 提交的任务实录（GPU 机 192.168.31.31 核对）

### 输出目录中的命名任务系列（均为手工 UI 提交的痕迹，filename_prefix 带语义）

| 系列 | 数量 | 时间 | 说明 |
|---|---|---|---|
| `Boat15sRTX_00001~00012`（output/video/ 根） | 12 条 | ~9/4 – 9/6 | 用户主任务系列：**15 秒 + RTX 放大** |
| `25S_v9_seg1/seg2`、`v10_seg2`、`v11_seg2` | 4 条 | 之前 | 25 秒任务分段（链式生成） |
| `FaceRefine_00001~00005`（含 -audio 版） | 10 个文件 | 之前 | 人脸修复后处理系列 |
| `H3_5s_8step_accel_00001` | 1 条 | 8/29 | 早期 5s/8 步加速测试产物 |
| `2026-09-06/090453_00001_audio.webm` | 1 条 | 9/6 09:04 | 当前正在跑/刚完成的 Director 任务 |

### 重负载任务实测参数（ffprobe，输出文件本体）

| 文件 | 分辨率 | fps | 时长 | 帧数 | 体量 |
|---|---|---|---|---|---|
| `Boat15sRTX_00012_.mp4` | **1088×1920（竖屏 9:16）** | 24 | **15.08s** | 362 | 2.1MP（推测 0.5MP 基座 + RTX 2× 放大） |
| `090453_00001_audio.webm` | 544×992 | 24 | — | — | 0.54MP 基座 |

### 日志执行耗时（最近 3 条，全部成功）

```
Prompt executed in 01:04:27   ← 约 15s/25 步/2MP 级大任务
Prompt executed in 01:04:13   ← 同上（连续两条一小时任务）
Prompt executed in 00:11:20   ← 加速档任务
```

### 健康指标

- 崩溃签名计数（`illegal memory / Fatal Python / launch failure / CUDA error`）= **0**
- 当前进程参数无 `--use-sage-attention`；DPM 修复仍在；CUDA 13 / torch 2.11
- **近两天 12+ 条 UI 任务全部完成，包括连续两条 1 小时+ 的 15s 2MP 重负载**

---

## 二、为什么"UI 提交不崩"——真因分析

### 1. 决定性因素：根因已被移除，与通道无关

| 历史症状 | 根因 | 状态 |
|---|---|---|
| 黑屏（黑色输出画面） | SageAttention Triton 后端在 Blackwell 上对部分模型（Qwen/Wan）输出黑屏（社区 Comfy-Org#11583 多方确认） | **已移除**（禁 `--use-sage-attention`）→ 自然不再黑屏 |
| 死机（进程崩溃，最快 7 分钟） | 同上的 sage Triton 路径内核不稳（本机 A/B：禁 sage 后 100min+ 无故障） | **已移除** |
| 重启（GPU 掉总线需重启） | MoDT 主板 PCIe 动态链路 Gen1↔Gen5 震荡（`NVreg_DynamicPowerManagement=0x00` 已修） | **已修复** |
| 整机断电（9/3、9/9 各一次） | 市电/PSU（非软件），与提交通道无关 | 待硬件侧排查 |

UI 与 API 提交走的是**同一个 ComfyUI 进程、同一个 `/prompt` 接口**，任何全局后端问题对两者是一视同仁的。之前崩溃样本期内"裸配置、零参数也崩，2/8 步即崩"（8 月记录）也证明：**崩溃不挑提交通道**。

### 2. 但 UI 与脚本提交确实存在"负载轮廓"差异（影响主观感受，不改变根因）

| 维度 | UI 手工提交 | 脚本/管线提交（dsw-v18 等） |
|---|---|---|
| 并发 | 串行、一条跑完才下一条，肉眼可见 | 早期曾叠加任务/排队不均，易显存互相挤压 |
| 参考输入 | 单图/双图居多、尺寸常规 | 历史上有 350 帧长视频 + 2MP 多图 rv2v 的重载 |
| 参数 | Director 默认/手工调（近两天 25 步 15s） | 脚本默认 8 步加速档，或极端档位 |
| 队列 | 人工监督，出问题即停 | 无人值守，崩了才发现 |

即：**UI 任务恰好都是"当前健康配置能扛住的载重"**，所以观感更稳；脚本跑极端载重（或曾经开着 sage）时更容易撞上问题。

### 3. 结论

- 你观察到的"UI 提交稳定"是真的，但它不能归功于 UI——**当前任何通道提交同样稳定**（0.54MP~2.1MP、8~25 步、1 小时级任务均已验证）。
- 想让脚本通道也获得同等稳定体验：保持禁 sage、DPM 修复、CUDA13；**串行提交、避免任务叠加**；极端参数（多参考/超长视频）先用 UI 冒烟。
- 真正要盯的剩余风险是硬件侧：9/3、9/9 的整机断电（市电/PSU），与 UI/API 无关——建议 UPS/电源排查按先前记录继续。

---

## 三、维持监控（不变）

```bash
# 崩溃签名（应为 0）
grep -cE "illegal memory|Fatal Python|launch failure|CUDA error" /home/zyw/comfyui_h3.log
# 掉总线（应为空）
dmesg | grep -i xid
# 链路速率（修复基线 32GT/s）
lspci -vv -s "$(lspci | grep -i nvidia | cut -d' ' -f1)" | grep LnkSta
```

---

## 四、相关记录

- 前序：`ComfyUI-H3运维记录.md`、`2026-09-06-SageAttention是否导致GPU掉线-核实.md`、`2026-09-06-H3提速方案.md`（同目录）
- 社区佐证：黑色输出与 Triton 后端：https://github.com/Comfy-Org/ComfyUI/discussions/11583