ComfyUI 0.32 升级实录，九天三个版本修的是同一件事

在本地跑 MiniMax H3 这类超大视频模型的，0.32 值得升。只用它出静态图的，可以不急。

这篇是一次真实升级的记录，从 0.30 跳到 0.32，包括升完实测快了多少，以及我在这个过程里踩到的坑。硬件是一台 NVIDIA DGX Spark（GB10 芯片，128GB 统一内存），跑的是 MiniMax H3，开源的全模态视频模型，能一次性生成画面和原生立体声。

一、九天三个版本，主线只有一条

0.30、0.31、0.32 分别发布于 2026 年 8 月 3 日、8 日和 11 日，九天三个版本，节奏相当密集。把三份 release notes 摊开看，它们在解决同一个问题，让 30B 级别的视频模型跑在普通人买得起的硬件上。

• 0.30 打地基。原生支持 MiniMax H3（模型开源当天就合并了），同时引入 MRU 权重调度加内存锁定（把模型权重缓存进系统内存）和 int8 卷积旋转嵌入查找。这三条是后面一切的前提，有了它们完整权重才能常驻内存，不用反复在硬盘和显存之间搬运。
• 0.31 还债。集中修 H3 首发留下的问题，专用的 int8 卷积旋转 VAE、音频采样器修复、音频 VAE 的完整显存卸载修复，外加 Wan-Animate2 并入内核。
• 0.32 收尾。继续修 H3 的 VAE 与峰值内存，顺带补上一批新模型支持。

0.30 是能跑，0.31 是跑得对，0.32 是跑得省。 在 0.30 那波尝鲜装上 H3 的人，手里那版基本是个半成品，后面两版修的很多都是你正在忍受的问题。

二、0.32 具体修了什么

按对使用者的影响排序。

H3 相关（四条，这是 0.32 的重点）

• Fix peak memory issue with H3。峰值内存修复，对大画幅出片影响最直接
• Optimize MiniMax-H3 VAE。VAE 解码优化
• Fix VAEDecodeTiled crash on NestedTensor latents。H3 的 latent 是嵌套张量，分块解码会崩，这条修掉了
• Fix for broken tiled audio decode。分块音频解码损坏修复。H3 是音视频一体的，这条同样落在 H3 用户头上

新模型支持

LTX 2.5（核心加配套节点两部分）、Qwen-Image 3.0 Pro、Grok-Imagine-Image-2.0。

底层与其他

补上了 comfy kitchen attention；扩展了 ER-SDE 噪声缩放；修了 upscale 模型在非动态显存加低显存这个组合下的崩溃；修了 clip vision 的一处回归；tokenizer 不再依赖 transformers；工作流模板库从 v0.11.37 升到 v0.11.39。

还有一条要单独拎出来说。官方最低支持的 PyTorch 提到了 2.7，同时把 cu130 的警告调得更显眼。这是升级前唯一可能卡住你的硬门槛，下面详说。

三、实测快了多少

同一台机器、同样的提示词和参数，升级前后对比如下，时间都是服务端实际执行耗时。

场景	0.30	0.32	变化
满画布 1344×768、124 帧、20 步	1351s（22.5 分钟）	1012.8s（16 分 53 秒）	快 25%
其中采样速度	51.5 s/step	46.95 s/step	快 8.8%
小图冒烟 864×480、39 帧、8 步	73s	60.1s	快 18%

总时间快了 25%，单步采样只快了 8.8%。

差额去哪了。去了采样之外的环节，也就是 0.32 那几条 VAE 优化和峰值内存修复生效的地方，解码和权重装载。这个拆解比只报一个 25% 有用，它告诉你如果还想再快，得往采样上想办法，解码那块上游已经榨过了。

顺带一提，我还测了 EasyCache 在 0.32 上的表现，它是 ComfyUI 自带的跳步缓存节点，在 advanced/debug 分类下。标准 20 步能省 40%（291.6s 降到 175.8s，1.66×），4 到 8 步的蒸馏加速档只能省 18%（153.2s 降到 125.6s，1.22×）。规律很直观，步数越少，可跳过的冗余就越少。

四、升级前的硬门槛是 PyTorch 2.7

0.32 把官方最低支持的 PyTorch 提到了 2.7。升级前先确认你环境里的版本。

python -c "import torch; print(torch.__version__)"

低于 2.7 的话，要么先升 torch，要么先别升 ComfyUI。我这边是 2.13.0+cu130，远超门槛，所以这条没成为问题。如果你的环境是一年前搭的，或者用的是某个整合包，很可能就卡在这儿。

五、自定义节点导入成功不等于能用

这是我这次真正栽了的地方，也是我认为最值得写出来的一条。

升级重启后我看启动日志，五个自定义节点全部 import 正常，没有一条报错。冒烟出片也通过了。于是我写下了”无兼容性回归”。

结果是错的。 后来复测才发现，其中一个自定义采样器一跑就崩，报错是这个。

AttributeError: 'MiniMaxH3FlowSampling' object has no attribute 'audio_scale'

根因很有意思。ComfyUI 把音视频双时钟做进了内核，新版本加了一个 ModelSamplingAV 类，带 audio_scale 属性，核心代码会直接调用它。那个自定义节点当初为了实现双时钟，把整个 model_sampling 换成了自己的类，自然没有这个新属性。我拿新旧两版镜像对比确认过，ModelSamplingAV 在 0.30 里根本不存在，是新加的。

这引出一个升级时的普遍模式。你装的自定义节点，可能已经被上游内核吸收了。

社区节点填的往往是官方暂时的空白，等官方把这块能力做进内核，那个节点就从补充变成了冲突。所以升级后遇到自定义节点报错，先去 release notes 里搜一下这个功能官方是不是自己做了，再决定要不要动手修节点。

我这次的正解就是这样找到的。内核提供了一个原生节点可以完成同样的事，接线更简单，实测还快一点点。能确认节点已经不需要，比把它修好省事得多。

由此得出一条具体的验收纪律。升级验收要跑主要使用路径，启动日志不算数。 我的错误在于冒烟测试只跑了标准档，实际出成片用的是另一条路径。import 成功只能证明它加载了，证明不了它能干活。

（另一个侧面的例子。0.32 的修复清单里有一条 Fix VAEDecodeTiled crash on NestedTensor latents。我在写多段续接脚本时独立撞上了同一类问题，H3 的 latent 是嵌套张量，直接喂给普通解码节点会报 'list' object has no attribute 'is_nested'。release notes 里那些看起来抽象的修复条目，往往对应着你迟早会踩的具体的坑，值得扫一眼再升。）

六、升级操作上的四条注意

1. 留好回滚点，成本几乎为零。 动手前先给旧镜像打个标签，把 Dockerfile 备份一份。

docker tag comfyui:mine comfyui:mine-<旧版本>
cp Dockerfile Dockerfile.bak-<日期>

回滚就是把标签指回去重启，比出事之后再想办法便宜得多。

2. 钉版本，别用 latest。 用 git tag 或 commit 钉死构建，这样你随时知道自己跑的是哪一版，也能精确回退。顺带一提，如果你之前为了某个修复手工 cherry-pick 过补丁，升级前查一下那个补丁是不是已经官方合并了。我这次就是，升完把自定义 cherry-pick 直接删掉，回到干净的 tag。

3. 别照着旧的脚本副本跑。 插件和整合包的缓存目录里，每装过一个版本就留一份副本。我调脚本时随手取到了一个旧版本的副本，用的是已经废弃的接线方式，结果它在新版上崩了。我把这事当成生产环境坏了汇报了出去，查下来是自己取错了版本。 取脚本先确认它归属哪个包，按版本号排序取最新那份。

4. 存量的经验禁忌值得趁升级复测一遍。 我们内部记了一条”某某加速节点不能和蒸馏加速叠加用”。复测下来，那条依据是理论推断，我们从没实测过，而且新版本恰好修了相关问题。真跑一遍，它在标准 20 步档能省 40%，完全可用。升级也是清理陈旧结论的时候。

七、验证比升级本身花时间得多

升级动作本身二十分钟就完了，剩下大半天都花在验证上，而验证过程本身埋了一堆坑。这几条我都是真栽了才知道的。

看到报错，先确认是不是升级引入的

重启后日志里有一条 IMPORT FAILED: nodes_glsl.py（缺 libX11.so.6），我第一反应是升级搞坏了。

拿新旧两版镜像各跑一次对比才确认，这个文件在旧版镜像里同样存在，同样报错。这是精简基础镜像缺 X11 库导致的存量问题，跟本次升级无关，而且那是着色器节点，跟我的用途也无关。

升级后看到报错，先问一句”旧版是不是也这样”，代价只是多跑一条命令，能省掉一整轮无用排查。

计时的三个陷阱，我全踩了

想量升级到底快了多少，看着简单，实际有三个地方会给你假数字。

其一，节点级执行缓存。 同样的参数重复提交，ComfyUI 直接命中缓存秒回。我重跑一次基准，70 秒就跑完了，实际只重做了解码，采样根本没算。做基准测试必须换 seed。

其二，别的进程在占内存。 我先前用本地大模型做了些别的活，它按默认策略常驻占了 24GB。随后跑大画幅计时，可用内存不够，模型被迫走动态装载，整跑被拖慢。这个数字和历史基线根本不可比，只能作废重跑，白等半小时。讽刺的是，跑前先确认内存余量这条，我们自己的文档里早就写了，我没照做。

其三，wall time 里混进了排队时间。 我有一次没看到提交回执，又发了一遍，结果队列里躺着两个一模一样的任务。我的脚本量的是从提交到完成，第二个任务排在后面等了十分钟，真正执行时全部命中缓存，量出来的数字既包含排队又不含计算，双重失真。

正解是别用脚本的 wall time，去 /history 里取执行时间戳。

# 从 /history 拿这个任务真正的执行耗时
msgs = history[prompt_id]["status"]["messages"]
t = {name: payload.get("timestamp") for name, payload in msgs}
seconds = (t["execution_success"] - t["execution_start"]) / 1000.0

用这个方法一查就水落石出。那两个重复任务里，先跑的真实执行 579.9 秒，后跑的 0.0 秒，27 个节点全部命中缓存。

对照实验的接线，必须和生产完全一致

我要对比两条不同的加速路径，其中一条用的是官方节点。我在它前面又加了一个功能相同的补丁节点，想着保险起见都加上。

结果那条路径耗时虚高 36%（210.8 秒 vs 真实的 155.4 秒），输出轨迹也跑偏了。原因很简单。那个官方采样器本身就自带该功能，我等于把同一个参数施加了两遍。

差一点我就据此写下”官方路径更慢、建议换掉”的反向结论。给自带某能力的节点再叠加同功能补丁，得到的是一个无效对照。 动手前先读节点说明（/object_info/<节点名> 里就有描述），或者干脆照生产实际用的图去搭。

参数别凭印象填，查一下只要一秒

写测试脚本时，我凭印象把某个加载器的类型参数填成了 minimax_h3，提交直接被拒。正确的值是 minimax，而且还漏了一个必填字段。

这类信息 /object_info 里全都有，查一次不到一秒，而提交失败要等到任务被拒才发现。凡是”我记得应该是……”的参数，都值得先查一眼。

单个样本的结论不作数，哪怕证据看起来铁证如山

这是我这轮最该记住的一条。

我在测某个缓存节点能不能和多段视频续接一起用。第一个 seed 跑出来，第二段画面整段崩坏，重影、色边、纹理糊成一片，抽帧一看简直是铁证。我当场下了结论，这条路走不通，别用。

第二个 seed 完全没复现。补到五个样本才定出真相，五次里崩一次，另外四次画面干净，指标也挤在很窄的一个区间里。正确的结论是可以用，每段出来过一眼。

生成模型的 seed 间方差常常大过你想测的效应。证据越醒目，越容易让人跳过复核，画面这种一眼可见的东西会让人产生”还需要再测吗”的错觉。文字数据反倒不容易骗到自己。

“至少两个 seed”这条判据，其实是我同一天才刚写下的。写下来和做得到，中间还隔着一次教训。

八、要不要升

• 跑 H3 或其他大视频模型。升，0.32 修的四条全在你身上，实测大画幅快 25%
• 还停在 0.30。更该升，0.31 那批音频和 VAE 修复你一直在忍受
• 只出静态图。不急，0.32 对你主要是新增了几个模型支持
• 环境里 PyTorch 低于 2.7。先解决这个，再谈升级

这次升级本身很顺利，改一行版本号、重建镜像、重启，二十分钟搞定。