ComfyUI `--fast` 的四个优化项，开之前要知道的

2026-08-09

ComfyUI 的命令行参数里，--fast 是少见的、官方自己在 help 文本里就把话说得很难听的那一个。绝大多数参数的 help 是在描述它做什么，--fast 的 help 在描述它可能给你带来什么麻烦。

先把原话摆出来。在 comfy/cli_args.py（v0.31.0，核对日 2026-08-09）里，--fast [FEATURE ...] 的 help 注明这是「一些未经测试、可能劣化质量的优化，用于测试新特性，用了可能让你的 ComfyUI 崩溃」。

三条警示，三个不同的层次，值得拆开看：

未经测试：这不是「我们测了没问题」，而是「我们没测」。出了事没有已知的对照结论。
可能劣化质量：影响的是生成结果本身，而不只是速度。这类问题最阴险，因为它不报错。
可能让 ComfyUI 崩溃：影响的是进程能不能活着，这类问题反而好查。

所以这篇不是「教你怎么加速」，而是帮你在加这个参数之前，先想清楚三件事：开哪个、怎么在出问题时把它摘出来、以及什么情况下问题根本不在它身上。

四个枚举值，以及官方没告诉我们的部分

--fast 的合法取值来自源码里的枚举 PerformanceFeature，一共四项：

枚举值	在源码里的位置
`fp16_accumulation`	`PerformanceFeature` 枚举成员
`fp8_matrix_mult`	`PerformanceFeature` 枚举成员
`cublas_ops`	`PerformanceFeature` 枚举成员
`autotune`	`PerformanceFeature` 枚举成员

这张表故意写成这样，因为这就是我们能拿到的全部信息量。comfy/cli_args.py（v0.31.0）给的是 --fast 这一个参数整体的 help 文本，并没有为四个枚举值分别写说明。也就是说，如果你想知道 cublas_ops 具体改了什么、autotune 会在哪个环节生效、它们各自的代价落在速度还是精度上，官方的命令行帮助里查不到答案。

我知道有人会想「看名字大概能猜出来」。名字确实有指向性，但猜出来的东西不能当依据用——尤其是在一个 help 里明写了「可能劣化质量」的参数上。这里的正确姿势是承认信息不全，然后用一套能兜住信息不全的用法（下面第三节）去覆盖它，而不是靠脑补一份「各项作用说明」再照着开。

顺带说一个容易混的点。comfy/cli_args.py（v0.31.0）里还有另外几个名字带 fp8 的参数：精度组里的 --fp8_e4m3fn-unet、--fp8_e5m2-unet、--fp8_e8m0fnu-unet，它们的 help 字面是「把 unet 权重以该 fp8 格式存储」；另有一个独立的 --supports-fp8-compute，help 是「让 ComfyUI 表现得像设备支持 fp8 计算一样」。这些都是独立的参数，和 --fast fp8_matrix_mult 不是一回事，help 里也没有说明它们之间的关系。看到名字里都有 fp8 就当成一组来配，是自己给自己埋雷。

三态逻辑：这个参数的行为和你的直觉不一样

--fast 最反直觉的地方在解析规则上。源码里的行为是三态的：

你怎么写	结果
命令行里没有 `--fast`	空集合，四项都不启用
写了 `--fast`，但没跟任何值	启用全部四项
写了 `--fast` 并跟了具体项	只启用你列出的那些

第二行是关键。大多数命令行工具里，一个不带值的开关意味着「用默认档位」，而这里不带值意味着把四个未经测试的优化一次性全部打开——恰好是风险最大的那种写法，却也是最容易随手敲出来的那种写法。你在某个教程截图里看到一句 python main.py --fast，复制过来，等于四项全开。

对应到实际命令：

# 一项都不开（默认状态）
python main.py

# 四项全开 —— 风险最高的写法，别当成「开个加速」
python main.py --fast

# 只开一项
python main.py --fast fp16_accumulation

# 开指定的两项
python main.py --fast fp16_accumulation cublas_ops

以上为按官方参数语义组合的示例，未逐项实测，以官方文档与 --help 输出为准。

还有一个实践上的提醒：既然 --fast 后面可以跟零个到多个值，那么把它和别的参数混排在一条长命令中间时，值的边界在哪里就变得不那么一目了然。源码只明确了上面三种情况的结果，至于参数顺序带来的解析细节，我们没有依据可讲。所以稳妥的写法就一条：要开就显式写出枚举值，一个都不想漏地写全；不想开就干脆不写这个参数。永远别用「写了 --fast 但不带值」这种依赖默认行为的写法，它的默认恰好是最激进的那个。

结论先给：按需单开、随时能回退

把上面两节合起来，--fast 的合理用法只有一种形态：

一次只加一项。 四个枚举值分别开，别一起上。help 说了这些优化未经测试，那么同时开四项出问题时，你连是哪一项的责任都定位不了，只能整体回退到原点，前面的试验白做。
每次改动只动这一个变量。 加 --fast 的那一次，不要顺手再改精度参数、注意力实现或者缓存模式。comfy/cli_args.py（v0.31.0）里精度组、注意力组、缓存组各自都是互斥组，任何一个改动都可能独立地影响结果，混在一起改就没法归因。
保留一条不带 --fast 的启动方式。 无论你用的是快捷方式、.bat、shell 脚本还是 systemd 单元，都留一份原样的、什么都不加的启动命令。回退的成本越低，你越敢试；回退要现改配置文件，你就会倾向于「先忍着」，而忍着是这类问题拖成疑难杂症的主要原因。
它不是常驻配置的候选项。 一个 help 里写着「未经测试」「可能崩溃」的开关，不该出现在你给别人交付的部署文档里，也不该写进服务器上开机自启的命令行。自己机器上做试验可以，进生产就是另一回事了。

需要说清楚的是：这里不推荐全开，也不是在说这四项没用。help 明确讲了它们的用途是用于测试新特性——你可以理解成官方给试验者留的口子，而不是给普通用户的性能开关。定位不同，用法就该不同。

怀疑是它引起的问题时，怎么判定

--fast 带来的问题分两类，判定路径完全不同，先分清你遇到的是哪一类。

第一类：崩溃、报错、起不来

这类反而好办，因为现象是二值的。

判定动作很直接：把 --fast 整段从命令行里去掉，其它一个字都不改，重新启动、跑同一个工作流。

去掉后不再崩溃 → 高度指向 --fast。接着把枚举值一项一项加回去，找出是哪一项。
去掉后照样崩溃 → 这事跟 --fast 没关系，别在这条路上耗，回到常规排查。

做这一步之前先把日志打开。comfy/cli_args.py（v0.31.0）里 --verbose [LEVEL] [FILE] 支持不带值、给一个 LEVEL、或者给 LEVEL FILE 两个值，合法等级是 DEBUG、DETAIL、INFO、WARNING、ERROR、CRITICAL，不带值时等价于 DEBUG，控制台默认等级是 INFO。崩溃类问题最怕的是现场没留下来，把 LEVEL FILE 两个值都给上、让详细日志落到文件里，比事后回忆终端上滚过去的内容靠谱得多。

另外，崩溃这件事本身有太多别的来源。在把账算到 --fast 头上之前，用 --disable-all-custom-nodes 起一次——这个参数的 help 就是不加载任何自定义节点；如果确实需要留个别节点参与对照，还有 --whitelist-custom-nodes NAME [NAME ...] 可以在禁用全部的前提下单独放行指定目录。自定义节点全关掉之后问题消失，那就跟 --fast 无关了。

第二类：不报错，但结果变了

这一类才是真麻烦，因为 help 里的「可能劣化质量」不会以任何形式提示你。而想做严格的前后对照，还有一个坎横在这里：

comfy/cli_args.py（v0.31.0）里 --deterministic 的 help 是让 pytorch 尽量使用较慢的确定性算法，而且明确写了「这可能并不能在所有情况下让图像可复现」。

这句话的分量很重。它意味着即便你固定了 seed、固定了工作流、加上了 --deterministic，也不能保证两次运行得到逐像素一致的结果。那么「加了 --fast 之后结果不一样了」这个观察本身，就不能直接推出「是 --fast 改坏了」——你缺一个能证明「不加 --fast 时两次运行是一致的」的基线。

所以顺序应该是这样：

先建基线。 完全不加 --fast，同一工作流、同一 seed 连跑两次，看看这台机器上本来的重复性是什么水平。
基线不稳就先停。 如果不加 --fast 时两次结果就已经有差异，那你手上这套环境不具备做质量对照的条件，此时任何关于 --fast 是否劣化质量的结论都是不成立的，别下。
基线稳，再单开一项做对照。 一次只开一个枚举值，其余参数原样不动。
拿不准就回退。 这一点没什么好挣扎的：--fast 提供的是官方标注为未经测试的优化，而你要的是可用的结果。判据模糊时，回退的代价远小于抱着一个说不清的变量继续往下做。

什么情况说明不是 `--fast` 的锅

避免一条道走到黑，下面这几种情形基本可以把 --fast 排除掉：

你的启动命令里压根没有 --fast。 按源码逻辑，没提供这个参数时就是空集合，四项一个都不启用。它没有「默认开一部分」这种中间状态，也不需要你额外去关。
去掉 --fast 后现象一模一样。 这是最硬的排除依据，别再回头怀疑它。
现象出现在 ComfyUI 加载模型之前，比如启动阶段就报环境相关的错。这类问题的方向在安装与依赖那一侧。
你真正改动的是别的互斥组。 例如精度组里的 --fp16-vae，它的 help 自己就注明了 might cause black images；这条是官方明确写在该参数上的，跟 --fast 不是一回事，别张冠李戴。
问题跟工作流内容强相关：换一个工作流就好、换回来就犯。这更像是节点或工作流本身的问题。

收口

--fast 这个参数值得记住的其实就三句话：不写就是不开，写了不带值是四项全开，出问题时第一个动作是整段去掉再跑一次。

至于四个枚举值各自到底做了什么——comfy/cli_args.py（v0.31.0）没有逐项说明，我们也就不替官方补。真要往下挖，方向是去读源码里 PerformanceFeature 这几个成员在哪些地方被判断和使用，那是代码层面的事，不是命令行帮助能回答的。在挖清楚之前，按需单开、留好回退路径，是对一个官方亲口说了「未经测试、可能劣化质量、可能崩溃」的开关最合适的态度。

延伸阅读

本文依据 ComfyUI 官方仓库（github.com/Comfy-Org/ComfyUI）的 README、comfy/cli_args.py、 release notes 与官方安全公告整理，核对日 2026-08-09，对应版本 v0.31.0；文中引用的 issue 状态为该日期的快照。本文内容为官方文档与源码口径，非本机实测。参数、默认值与功能随版本变动，请以官方文档与 python main.py --help 的实际输出为准。