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/电源排查按先前记录继续。
三、维持监控（不变）
# 崩溃签名（应为 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