前几天实验室的渲染流水线遇到了一个耗时的奇怪症状：GPU1（RTX 5060 Ti 16GB）上的 flux 任务每步耗时超过 2 分钟，而相同任务在 GPU0（同型号显卡）上整批只需约 54 秒。我们重复测试了 3 次 — 不是随机现象
先正确解读特征
我做的第一件事是在任务卡住时采集 6 次 nvidia-smi 样本，结果呈现出一个说明一切的特征：
| 卡住时的指标 | 测量值 |
|---|---|
| SM 利用率 | 96–99%（看起来"工作繁忙"） |
| 内存利用率 | 0–1%（完全没有数据传输） |
| 显卡功耗 | 38W（采样时异常低） |
| 每步耗时 | >120 秒（正常约 4 秒） |
SM 满载但内存为零 + 低功耗 = 显卡没有真正计算，它在空转等待。这是运行时的活锁，不是模型负载。对比正常任务的特征：sm 96–99% + mem-util 18–41% + 功耗 115–143W
实际变化的变量只有一个
GPU0 和 GPU1 使用同型号显卡、相同模型（flux1-dev fp8），但运行时不同：
- GPU0 (:8188) — imgfactory python_embeded, torch 2.13.0+cu130
- GPU1 (:8190) — venv Python 3.12, torch 2.7.1+cu128
当晚唯一的假设：运行时 2.7.1+cu128 与 5060 Ti 的 Blackwell 架构在重度反量化工作负载下不兼容。验证方法不难 — 将 GPU0 已验证的运行时通过 CUDA_VISIBLE_DEVICES=1 迁移到 GPU1 上运行，不触碰模型或工作负载
切换运行时后的结果
切换到 start_gpu1_v2（imgfactory python_embeded, torch 2.13.0+cu130，output/input/db 目录完全分离以避免与 8188 冲突）后：
| 检查项 | 结果 |
|---|---|
| 单任务 (job 85917) | 54.4 秒 — 恢复正常 |
| 连续 8 个任务 | 50.7–127.4 秒，全部通过 |
| 10 个任务总计 | 10/10 PASS · 中位时间 54.15 秒 |
| 与同期 GPU0 对比 | parity 100.3% (band ±50%) |
| GPU0 副作用 | 零 — 8188 在同一时段继续运行并发布图像 |
修复后 GPU1 的实际吞吐量 = 30.5 任务/小时（10 个任务 / 1,182 秒）
我们没做的事（也不该做）
- 没有删除旧 venv — 按"迁移不删除"规则保留在 E:\ComfyUI，只更改 schtask 指向新 launcher
- 没有触碰旧的 idle_watchdog（它曾帮助重启但导致重复实例）— 已移除，改为按需手动修复
- 没有改变任何其他东西：工作负载、参数、模型、队列顺序 — 一切字节级相同
实验室的教训
如果 GPU "变慢"，别急着怪模型或增加 VRAM — 先读这三个值：SM、内存利用率、瓦特数。如果 sm 满载但内存为零，问题几乎总是在运行时。正确的验证方法是只切换一个变量（运行时），保持其他一切不变，然后测量 10 个任务 — 而不是猜测并从头开始寻找新驱动
