Flux2TEModel_ GGUF appears to be offloaded to RAM instead of fully released, causing OOM on low-RAM systems

快速结论：该问题出现在使用 GGUF 格式的 Flux2TEModel_ 文本编码器（Qwen 3 8B GGUF Q8）时，模型卸载到系统 RAM 而非完全释放，导致低 RAM 系统（如 Google Colab 约 13GB）在加载 Flux UNet 时发生 OOM。目前无官方修补方案，但可以通过启动参数禁用动态 VRAM 来临时解决。

问题场景

用户在 ComfyUI v0.24 环境下，基于 Google Colab 的 Tesla T4（15GB VRAM）和约 13GB 系统 RAM，加载 Flux2 Klein 9B GGUF Q8 模型及 Flux2TEModel_ GGUF 文本编码器（Qwen 3 8B GGUF Q8）。在文本编码完成后，执行清理/卸载节点，但文本编码器仅从 VRAM 卸载到系统 RAM，而非完全释放，导致后续加载 Flux UNet（约 9.7GB）时 RAM 占用过高（90-96%），部分运行发生 OOM。

报错原文

Flux2TEModel_ loaded (~10GB)
Partial unload from VRAM
Flux UNet then loads (~9.7GB)
RAM usage often reaches 90-96%
Process OOMs while loading the UNet

注：用户日志中未记录显式错误代码，OOM 为系统内存不足的通用表现。

原因分析

目前证据表明，这是 ComfyUI-GGUF 节点缺少动态 VRAM 支持导致的。开发者指出，GGUF 模型在卸载时行为类似旧版本 pre-dynamic VRAM 方式，即模型数据被移至系统 RAM 而非彻底释放。这可能是以下原因之一：

ComfyUI-GGUF 节点尚未实现内存压力缓存（ram pressure cache）对 GGUF 模型的完整支持，导致模型引用在 RAM 中残留。
缺少 read_tensor_slice 协议更改，可能导致内存清理不彻底。
动态 VRAM 管理功能与 GGUF 格式的兼容性存在已知缺陷（相关 PR #14183 和 #14372 已合并，但核心问题仍在修复中）。

环境排查

ComfyUI 版本：v0.24
运行环境：Google Colab
显卡与显存：Tesla T4（15GB VRAM）
系统 RAM：约 13GB
模型：Flux2 Klein 9B GGUF Q8 + Flux2TEModel_ GGUF 文本编码器（Qwen 3 8B GGUF Q8）
已尝试的清理节点：多种 unload/cleanup 节点，效果一致
ComfyUI-GGUF 节点版本：未明确，但开发者确认其缺少动态 VRAM 支持

解决步骤

目前没有官方发布的修补方案，以下方法可优先尝试：

禁用动态 VRAM（临时方案）： 使用启动命令 --disable-smart-memory 禁用动态 VRAM 功能。注意：开发者表示该参数未来可能被移除，但当前仍有作用。
尝试相关 PR 修复（供高级用户）： 拉取开发者提到的 PR #14183 或 #14372，但已知 PR #14183 存在 Bug，需结合 AI 编码代理修正 read_tensor_slice 协议。具体验证内存钉住、释放和压力缓存行为。社区未报告成功案例，风险自担。
减少 RAM 占用（低配系统适配）： 使用量化程度更高的 GGUF 模型（如 Q6、Q4）降低单次加载体积，或切换至量化更小的文本编码器。
检查自定义节点冲突： 禁用所有自定义节点后复现，排除其他节点干扰。