Mixed workflow warmup loses model residency on GB10 unified memory

快速结论：这个报错通常出现在 GB10 这类统一内存（Unified Memory）机器上，把 ComfyUI 作为单一常驻服务进程使用、并在同一进程内混合预热 image / video / audio 多种工作流时；对应英文问题描述是 Mixed workflow warmup loses model residency on GB10 unified memory。优先排查模型驻留（model residency）生命周期与显存/内存账目判定，而不是先怀疑工作流本身。

适用环境：ComfyUI 单服务进程；NVIDIA DGX Spark 风格统一内存系统；GB10 平台；NVIDIA GPU（具体驱动/CUDA 版本 Issue 未给出）；Python、PyTorch 版本 Issue 未给出。Issue 中测试过的启动参数为 --highvram、--gpu-only、--disable-async-offload。

最快修复方案：暂无确认的一步修复方案。Issue 中作者临时采用的可行做法是按工作流类型分别启动独立 ComfyUI 实例（例如一个实例只做 image，另一个只做 video），但这只是绕过问题，不是修复。

注意事项：该 Issue 在 GitHub 上标记为 Feature（功能请求）并已关闭，本身没有给出已验证的代码级修复或补丁。多实例方案需要额外的 API 路由，并且会重复占用 CUDA context、浪费资源，也无法利用统一内存的全局动态分配能力。Issue 里提到的“weak references / execution cache ownership 导致模型被回收”属于作者推测的“可能原因”，未经确认。

问题场景

用户在 NVIDIA DGX Spark 风格统一内存系统上，把 ComfyUI 作为单个服务进程运行，并在同一进程内连续预热多种类型的工作流（image、video、audio），希望通过一次预热后让模型在内存预算允许时保持可复用。

预期行为：先预热 image 工作流，再预热 video、audio 工作流，随后按 image → video → image 的顺序执行时，第二次 image 运行应复用已预热的 image 模型，不再支付冷加载代价。

实际行为：同一工作流重复运行很快，但一旦切换到另一种工作流类型，之前工作流的模型就丢失了可复用的已加载状态。用户的实测数据为：首次 image 运行约 120s，重复 image 运行约 9s，而 image → video → image 之后 image 又回到约 120s。video → audio → video 也有类似现象。

报错原文

Mixed workflow warmup loses model residency on GB10 unified memory

Actual behavior:
Same-workflow repeated runs are fast, but switching to another workflow type causes the previous workflow’s models to lose reusable loaded state.

Observed example:
* First image run: about 120s
* Repeated image run: about 9s
* image -> video -> image: image returns to about 120s again

Similar behavior happens with video -> audio -> video.

Startup flags tested:
--highvram
--gpu-only
--disable-async-offload

These improve same-workflow reuse, but do not make models stay reusable across mixed workflow categories.

说明：这里的“报错原文”是 Issue 中对异常行为的描述，并非抛出的异常堆栈。Issue 未提供具体的 Python traceback、CUDA error 或崩溃日志。

原因分析

可能原因是模型驻留生命周期（LoadedModel lifecycle）与执行缓存的持有关系问题。按 Issue 作者推测，当前 LoadedModel 生命周期依赖弱引用 / 执行缓存所有权，切换工作流后较早的 ModelPatcher 对象可能被垃圾回收，于是即使 PyTorch 侧仍保留了一部分内存，ComfyUI 也不再把它当作已加载模型来复用。

另一个可能原因是统一内存让 CUDA 空闲显存统计变得困难：CUDA、PyTorch、host memory 与 cgroup 限制可能各自报告不同的可用内存视图，导致驱逐或部分卸载（eviction / partial unload）的判定过于保守。这部分同样属于“可能原因”，Issue 中未给出确认结论。

需要区分的是：启动参数确实能改善同一工作流内的复用，但不能让模型跨工作流类型保持可复用，所以问题不在单个工作流本身，而在于跨工作流切换时的驻留语义。

环境排查

确认是否运行在统一内存系统（如 NVIDIA DGX Spark / GB10）上，而不是普通独立显存显卡。
确认 ComfyUI 是否作为单一服务进程长期运行，并在同一进程内混合使用 image / video / audio 工作流。
确认是否曾用 --highvram、--gpu-only、--disable-async-offload 测试过，并记录加与不加时的复用差异。
分别观察同一工作流重复运行与跨工作流切换运行的耗时，确认是否稳定复现 120s / 9s / 120s 这一模式。
记录 CUDA、PyTorch、Python 及 NVIDIA 驱动版本；Issue 未提供这些版本，出现问题时建议自行留存以便对照。
关注内存账目：CUDA 报告的可用显存、PyTorch 缓存、host memory 与 cgroup 限制是否互相矛盾。

解决步骤

先明确当前没有官方确认的一步修复方案，不要期待通过某个参数彻底解决跨工作流驻留问题。
可优先尝试调整启动参数：分别测试 --highvram、--gpu-only、--disable-async-offload，确认它们对同一工作流复用的改善程度；注意这些参数在 Issue 中并未解决跨工作流类型复用的问题。
如果目标是尽快恢复服务可用性，可采用 Issue 作者的临时方案：按工作流类型分别启动独立 ComfyUI 实例，例如一个实例专门跑 image，另一个专门跑 video，再在前端加 API 路由分发请求。
评估该临时方案的成本：多实例会重复创建 CUDA context、增加资源占用，且无法利用统一内存的全局动态分配。
持续跟踪该 Issue 的后续进展，因为它在 GitHub 上标记为 Feature 并已关闭，相关修复可能出现在后续版本或其他关联 PR 中。
如果要在单实例下长期使用，建议在服务层监控跨工作流切换后的模型重载行为，作为是否再次触发该问题的判断依据。

验证方法

按 image → video → image 的顺序执行并测量时间。如果第二次 image 运行接近重复运行的水平（Issue 中约 9s），而不是回到首次的冷加载水平（约 120s），说明模型驻留已被保留。同样的方法可用于 video → audio → video。仅凭 --highvram 等参数带来同一工作流内的提速，不能作为跨工作流驻留问题的验证通过依据。