allanmeng-ComfyUI-XPUSYS-Monitor/docs/predictor_explained_CN.md

工作流成功率预测——通俗解读

这份文档面向普通用户，用日常语言解释插件是如何预测"你的工作流能不能跑起来"的。 不需要数学基础，只需要知道显存、内存是什么就够了。

---

一、插件在预测什么？

当你在 ComfyUI 里搭好一个工作流，准备点击运行之前，插件会悄悄帮你估算一件事：

"以当前机器的状态，这个工作流大概有多大概率能跑完，而不是中途崩溃？"

这个概率就是状态栏里 PRED 胶囊显示的预测工作流执行成功率。

---

二、为什么需要预测？

跑 AI 图像生成最常见的崩溃原因只有一个：内存不够用。

具体来说是**显存（VRAM）**不够用。AI 模型（比如 Flux、SD 系列）在运行时必须加载进显卡的显存里，如果模型太大、显存太小，程序就会报错崩溃（OOM，Out of Memory）。

但"显存不够"这件事并不是非黑即白的——

• 有时候模型稍微超出显存一点点，系统会自动借用电脑内存来临时存放，仍然能跑
• 有时候借用内存也不够，还会用硬盘虚拟内存来凑，速度极慢但可能勉强跑完
• 只有当所有资源都不够用时，才真的必然崩溃

所以成功率是一个连续的概率，而不是简单的"能 / 不能"。

---

三、一个关键洞察：模型不需要同时在显存里

这是整个算法最重要的前提，很多人没意识到这一点。

想象你有三本厚厚的参考书（CLIP 文本编码器、扩散模型、VAE 解码器），但书桌（显存）只能放下一本。

一般人会想："三本书都放不下，肯定没法做作业。"

但实际上，你做作业的流程是：

先查第一本 → 放回书架 → 拿出第二本 → 放回书架 → 拿出第三本

ComfyUI 就是这样运作的。它以采样（Sampling）为核心步骤，工作流本质上是串行的——一个模型用完就卸载，下一个再加载。

所以判断"能不能跑"的真正规则是：

1. 书桌够不够放下最厚的那本书（硬约束）
2. 书架空间够不够存放所有书（软约束）

---

四、插件能"看到"什么？

这是理解预测准确性的关键：插件只能预测它看得见的资源。

显卡里的显存分三类：

类型	能被 ComfyUI 控制吗？	算法处理方式
当前空闲显存	✓ 直接可用	计入可用量
PyTorch 占用的显存（模型缓存）	✓ 工作流开始前主动释放	计入可用量
系统与环境（驱动、桌面渲染、第三方程序）	✗ ComfyUI 看不到、控制不了	排除，视为永久占用

内存（RAM）也一样：

类型	算法处理方式
当前空闲内存	计入可用量
其他程序占用的内存（浏览器、游戏）	排除，ComfyUI 无法预测它们会不会释放

这个原则保证了预测是保守但可靠的：宁可低估可用量、略微悲观，也不依赖不可控因素做乐观假设。

---

五、"可用显存"是怎么算的？

很多人以为显卡标注 12 GB，可用就是 12 GB。实际上：

可用显存 = （空闲显存 + PyTorch缓存）× 0.9

为什么乘以 0.9？

显存在使用过程中会产生内存碎片。就像一个停车场，表面上还有很多空位，但都是零散的小格子，一辆大车（大模型）反而停不进去。乘以 0.9 是对这种碎片化损耗的折扣。

为什么不减去"系统预留"？

因为系统和环境占用的显存（驱动、桌面渲染）已经不在空闲量里了——系统不会把自己要用的那部分报告成空闲。OS 和驱动自我管理的部分，不需要我们再手动扣除。

对于一张 12 GB 显卡，系统与环境通常占用约 23 GB，实际可分配给模型的空间大约在 89 GB 左右。

---

六、两个约束怎么影响成功率？

约束一：硬约束——最大模型能否装入显存

这是决定生死的关键。

如果工作流里最大的单个模型（通常是主模型，比如 Flux Dev 约 9.8 GB）超过了显存的实际可用量，程序在加载这个模型时就会直接崩溃，不管内存还剩多少都救不了。

用一条指数衰减曲线来描述这种风险——溢出越多，成功率下降越陡：

溢出 0%  → 成功率 100%（完全没问题）
溢出 10% → 成功率约 74%（开始有风险）
溢出 30% → 成功率约 41%（风险较高）
溢出 50% → 成功率约 22%（很可能崩）
溢出 100%→ 成功率约 5%（几乎必崩）

为什么用指数曲线而不是直线？因为显存溢出的危险是加速恶化的——超一点点还有驱动层的缓冲机制来救，超太多就什么都救不了。

平台差异：NVIDIA 的"溢出容忍"

上面的曲线是针对 Intel Arc 的严格标准。对于 NVIDIA 显卡，情况大不相同：

平台	溢出容忍系数	实际能力
Intel Arc	1.0x	硬约束严格，超显存容易崩溃
NVIDIA	4.0x	CUDA UVM 支持显存溢出约 4 倍仍能运行

NVIDIA 为什么能超显存运行？

NVIDIA 的 CUDA 驱动有一套 Unified Virtual Memory (UVM) 机制：

• 模型不需要全部常驻显存
• 驱动自动在显存和系统内存之间分页调度
• 虽然速度变慢，但程序不会崩溃

这意味着同样是 8 GB 显存跑 20 GB 模型：

• Intel Arc：成功率 ≈ 5%（几乎必崩）
• NVIDIA：成功率 ≈ 47%（能跑，只是慢）

插件会自动识别显卡类型，应用对应的溢出容忍系数。

---

约束二：软约束——总量能否在内存中循环

这是决定稳定性的关键。

即使最大的单个模型能装进显存，如果你的工作流里模型很多（比如叠了很多 LoRA，或者同时有多个 checkpoint 节点），总量加起来可能远超显存。

这时候，多余的部分需要在系统内存（RAM）里中转——用一个加载一个、用完放回。

三种情况：

1. 总量 ≤ 显存可用量：最理想，所有模型都能常驻显存，成功率 100%

2. 总量超出显存，但超出部分 ≤ 空闲内存：内存够中转，只是速度会慢，成功率在 70%～100% 之间

3. 连空闲内存也不够，需要动用虚拟内存（硬盘分页）：速度极慢，不稳定，成功率在 5%～70% 之间

4. 连虚拟内存都不够：必然失败，成功率趋近 0%

---

七、最终成功率怎么得出？

最终成功率 = 硬约束成功率 × 软约束成功率

举几个例子感受一下：

场景	硬约束	软约束	最终
轻量工作流，全部装入显存	100%	100%	100%
主模型刚好装入，但总量稍超显存	100%	84%	84%
主模型略超显存，但内存充足	74%	100%	74%
两个约束都有压力	74%	70%	52%
主模型严重超出显存	22%	任意	≤22%

可以看出：只要最大模型装不进显存，整体成功率就会被大幅拉低，无论内存多大都帮不了多少。

---

八、延展知识

8.1 什么是显存碎片？

显存碎片（Memory Fragmentation）是一种常见的内存管理问题。

想象显存是一排停车位，每辆车（每个模型/张量）停进去后，如果中间的车离开了，会留下空缺。下次要停一辆大车时，即使总空位够，但没有连续的大空位，大车就停不进去。

PyTorch 会尽量复用显存块，但在模型频繁加载/卸载后，碎片不可避免。Intel Arc 的驱动目前对碎片整理的支持比 NVIDIA 弱，所以 0.9 的折扣对 Arc 用户来说是合理的保守估计。

8.2 什么是 OOM（Out of Memory）？

OOM 是 AI 跑图最常见的错误，完整报错通常是：

torch.cuda.OutOfMemoryError: CUDA out of memory.

或 Intel Arc 上：

RuntimeError: XPU out of memory.

本质是 PyTorch 尝试分配一块显存时失败了。一旦触发 OOM，当前推理任务会立即终止，已生成的中间结果全部丢失。

常见触发原因：

• 模型太大
• 分辨率太高（高分辨率的潜变量张量很占显存）
• 批量生成数量太多（batch size > 1）
• 显存碎片累积，重启 ComfyUI 后好转

8.3 什么是虚拟内存？

虚拟内存（Virtual Memory / Page File）是 Windows 在物理内存不足时，把内存内容临时写到硬盘上的机制。

对 AI 跑图来说，虚拟内存是最后的救命稻草，但代价极大：

• HDD（机械硬盘）：读写速度约 100 MB/s，加载一个 10 GB 模型需要约 100 秒
• SSD（固态硬盘）：读写速度约 500 MB/s～3000 MB/s，勉强可用但仍然很慢
• NVMe SSD：读写速度约 3000 MB/s～7000 MB/s，配合合理的工作流有时能跑完

这也是为什么算法把虚拟内存区间的成功率压得很低（5%～70%）——能不用就不用。

8.4 Intel Arc 的统一内存架构

与 NVIDIA 独立显卡不同，Intel Arc（尤其是移动版）采用统一内存架构（UMA），即 CPU 和 GPU 共享同一块物理内存池。

这带来一个好处：理论上，当 Arc 显存不足时，系统可以更自然地让模型"溢出"到系统内存，因为两者本来就在同一个内存池里，只是分配方式不同。

实际影响是：对 Arc 用户来说，软约束（总量溢出到内存）的惩罚相对更小，本算法的 P_load 系数在 Arc 上可能稍微保守了一些。

8.5 模型文件大小 vs 实际显存占用

本算法用磁盘文件大小来估算显存占用，这是一个近似值，实际存在以下差异：

模型格式	精度	文件大小与显存占用关系
.safetensors FP16	半精度	约相等（最常见）
.safetensors FP32	单精度	约相等
.gguf Q4_K_M	4-bit 量化	文件远小于 FP16 等效，算法会高估占用
.gguf Q8	8-bit 量化	文件比 FP16 小约一半，算法会高估占用

结论： 如果你用的是量化模型（GGUF），实际显存占用比算法估计的小，真实成功率会比显示的高。这是一个已知的保守估计，对用户来说是安全方向的偏差。

8.6 为什么成功率不是 100% 就是 0%？

直觉上，模型要么能装进去要么不能，应该是非黑即白。但现实中有很多模糊因素：

1. 驱动层缓冲：显卡驱动有一套隐式的内存管理，有时能在 OOM 触发前做最后的挤压和整理
2. PyTorch 缓存池：PyTorch 会预先霸占一些显存作为缓存，关键时刻可以释放
3. 系统状态随机性：同一台机器，不同时间运行同一工作流，后台进程占用的内存/显存会有波动
4. 模型加载顺序：ComfyUI 的节点执行顺序有时会影响峰值显存时机

这些因素加在一起，使得"临界状态"下的结果确实是概率性的，而不是确定性的。

---

九、如何利用这个预测？

成功率	建议操作
≥ 95%（轻松）	直接运行，无需顾虑
80%～95%（安全）	可以运行，偶尔可能因后台进程波动失败
40%～80%（预警）	建议关闭其他大内存程序，或降低模型精度
< 40%（危险）	强烈建议减少工作流中的模型数量，或换更小的模型

降低内存压力的实用技巧：

• 用量化版模型（GGUF Q4/Q8）替代 FP16 模型
• 工作流中不需要的节点设为 bypass（算法会自动排除 bypass 节点）
• 关闭浏览器、游戏等大内存占用程序
• 重启 ComfyUI 清理显存碎片
• 如果用多个 LoRA，考虑合并成单个 LoRA

---

本文档配套技术文档：predictor_algorithm.md