老显卡启动就崩：cudaMallocAsync 这条线索
手上还压着一张老卡的人，多半遇到过这种事：环境装得干干净净，依赖一个不缺，python main.py 敲下去，进程直接挂了，浏览器连 127.0.0.1:8188 都没得开。日志翻上去一看，是 CUDA 那一层报的错，而不是 Python 语法或者缺包。
这时候大部分人的动作是：重装驱动、换 CUDA 版本、重建 venv、换 torch 轮子。折腾一晚上，回来还是崩。
有一条线索比这些都便宜，值得先试：ComfyUI 有一个默认就开着的显存分配器开关。
一、这个默认值到底是什么
在 ComfyUI v0.31.0（核对日 2026-08-09）的 comfy/cli_args.py 里，设备选择那一组有一对参数：--cuda-malloc 和 --disable-cuda-malloc。它们的作用是启用或禁用 cudaMallocAsync，而 help 里明确注明了一句关键的话：torch 2.0 及以上默认启用。
这句话值得多读两遍。它的意思是，你什么参数都不加、直接 python main.py 启动，只要你的 torch 是 2.0 或更高（今天基本都是），这个开关就是开着的。它不是一个你得主动打开的加速选项，而是一个你得主动关掉的默认行为。
这就是反直觉的地方。命令行里没写的东西，人一般默认它是关的；但这一条恰好相反。所以当你在网上搜到「加 --disable-cuda-malloc 就好了」的建议时，心里要清楚：这不是「开启某个兼容模式」，而是「把一个你压根不知道开着的默认值关掉」。
再说说这两个参数的关系：按 v0.31.0 的 comfy/cli_args.py，这两个参数是互斥的，也就是说它们在同一个互斥组里，一条启动命令里只能出现其中一个，不要图省事两个都写上。
至于 cudaMallocAsync 在哪些设备、哪些驱动版本上被支持、内部怎么工作，comfy/cli_args.py 的 help 没有说，我们也不猜。这篇只按「它默认开着、可以关掉」这一层事实来用它。
二、官方仓库里对应的那条 issue
这条线索不是凭空来的。官方仓库 issue #940 反映了「默认参数 cuda-malloc 在 GTX 960M 上导致 CUDA error: operation not supported」这一现象，该 issue 创建于 2023-07-19，标签为 User Support，截至 2026-08-09 仍为 open。
几点必须说清楚，免得读者会错意：
- 我们没有读过这条 issue 的正文和评论，上面那句话是它的标题所述的现象，不是根因分析。
- 标签是
User Support，这是「用户求助」类，既不是官方确认的 bug，也不代表官方给出了结论。 - 它到今天仍是 open。open 不等于「官方已经承认这是缺陷」，也不等于「这事没人管」，它就只是 open。
所以正确的用法是：把 #940 当成一条方向提示——「老 NVIDIA 卡 + 启动期 CUDA 报错」这个组合下，有人把矛头指向过这个默认参数，那你也值得花两分钟试一下。仅此而已。别拿它当结论去跟人争。
三、怎么确认是不是这个原因
不要一上来就加参数。按下面这个顺序走，每一步都能砍掉一大片可能性。
第一步：先确认崩在不在 CUDA 这条路上。
python main.py --cpu
--cpu 在 v0.31.0 的 help 里就是「全部用 CPU（慢）」。它慢得没法干活，但这里我们不是要它干活，只是要一个判定信号：如果加了 --cpu 就能正常启动、能打开界面，说明问题出在 GPU 这条路径上，继续往下查；如果 --cpu 也崩，那崩溃发生在完全不走 CUDA 的路径上，这条显存分配器的线基本可以先放下，请直接跳到本文最后一节。
第二步：把自定义节点摘干净。
python main.py --disable-all-custom-nodes
这个参数的 help 就是「不加载任何自定义节点」。启动期崩溃里有相当一部分是某个节点在导入阶段炸的，跟 CUDA 无关。摘干净还崩，才轮得到怀疑核心；摘干净就好了，那你该去逐个排节点，而不是在这里改分配器。
顺带一提，如果你确实需要在关掉全部节点的同时保留某几个，v0.31.0 里还有 --whitelist-custom-nodes NAME [NAME ...]，它的 help 就是「在开启上一条时，仍然加载指定的自定义节点目录」，配合上一条使用。
第三步：把日志打详细，别看那一行摘要。
python main.py --verbose DEBUG
--verbose 接受不带值、一个 LEVEL、或者 LEVEL FILE 两个值，合法等级是 ('DEBUG', 'DETAIL', 'INFO', 'WARNING', 'ERROR', 'CRITICAL')，不带值时等价于 DEBUG，控制台默认等级是 INFO。想直接落到文件就给两个值：
python main.py --verbose DEBUG comfy-boot.log
这里有个很容易吃亏的细节：ComfyUI 的正常进程输出默认走 stderr，不是 stdout。所以你要是习惯性地用 > log.txt 重定向，很可能拿到一个空文件，然后误以为「它什么都没打就死了」。要么按上面那样让 --verbose 自己写文件，要么加 --log-stdout 把输出改到 stdout。这一条纯粹是命令行使用习惯上的坑，跟你的显卡没关系，但坑住的人不少。
第四步：去掉那个默认值。
python main.py --disable-cuda-malloc
前三步都指向「GPU 路径上、非自定义节点、启动阶段」，就该轮到它了。注意别和 --cuda-malloc 同时写。
四、处置之后怎么验证
加完 --disable-cuda-malloc，验收要看三处，缺一处都算没验完：
- 进程活着。启动过程走完没有退出，服务起在默认端口
8188（--port的默认值就是 8188，你要是改过端口就看自己的）。 - 界面能打开。默认
--listen只监听127.0.0.1，所以在本机浏览器访问就行；如果你是在另一台机器上访问，那是另一个问题（要加--listen），别把它和这次崩溃混在一起判断。 - 真正跑一次。启动成功不代表推理路径也没事，随便跑一个最简单的工作流，让它真的过一遍 GPU。启动期不崩、采样期才崩，是完全不同的两个故事。
确认有效之后，把这个参数固化下来，别指望每次手敲。Windows 上如果你用的是官方的 Windows Portable Package，就改它自带的启动脚本里那条命令行；自己建的 venv 环境就改自己的启动脚本。Linux/macOS 上把它写进你平时用的 shell 启动脚本，或者交给系统的服务管理器托管。注意后面这半句属于通用运维做法，不是 ComfyUI 官方文档的内容，官方文档只负责告诉你这个参数存在、语义是什么，怎么落到你的机器上是你自己的事。
顺带提一句 Windows Portable Package 的定位：README 的 Installing 章节对它写的是「不推荐普通用户使用，普通用户应该用上面那个桌面应用」。你要是纯粹为了跑通一次而临时抓了便携包，心里有个数。
顺便说一句，--disable-cuda-malloc 不是「性能优化」，它是「换一条兼容路子」。help 里没有给任何关于速度、显存占用的说明，我们也不替它编。你只该期待一件事：能起来。
五、什么情况说明不是这个原因
这一节才是重点，不然很容易在一条道上走到黑。
加了 --disable-cuda-malloc 照样崩。 那这条线到此为止，别再纠缠。可以顺着另一个方向看：官方仓库 issue #10468 反映了「CUDA error: no kernel image is available for execution on the device」这一现象，创建于 2025-10-24，标签为 User Support，截至 2026-08-09 仍为 open。同样地，我们没读过它的正文，只是提示你这类报错在仓库里是另一条独立的线索，它的标题里压根没提 cuda-malloc，所以别顺手把两件事并成一件来处理。
--cpu 也崩。 说明崩溃根本没走到 GPU 那一层，八成是 Python 环境、依赖版本或者某个导入阶段的东西。回去查第二步的自定义节点，或者查依赖。
你的启动命令里带了 --fast。 先把它摘掉再谈别的。--fast 的 help 原文就注明这是「一些未经测试、可能劣化质量的优化，用于测试新特性，用了可能让你的 ComfyUI 崩溃」——官方自己都这么写了，它崩了不冤。
不是崩溃，是黑图。 出图全黑跟启动崩溃完全是两回事。在 v0.31.0 的参数里，官方唯一明确和黑图关联起来的开关是 --fp16-vae，它的 help 注明 might cause black images。另外 --force-upcast-attention 的 help 里写着「如果它修好了黑图请上报」。这两条都跟 cudaMallocAsync 无关。
启动很顺，跑到一半才炸、还伴随 OOM。 这属于显存与动态加载那条线，不是分配器开关这条线。相关的是 dynamic VRAM 那一整套机制和 --reserve-vram、--disable-dynamic-vram 之类的参数，得单独排。
你的卡不是 NVIDIA。 AMD 走 ROCm、Apple 走 MPS，--cuda-malloc 这一对参数是 CUDA 侧的东西，在这些平台上追这条线索基本是浪费时间。官方仓库里 AMD/ROCm 与 Apple Silicon/MPS 各有独立的一批 open issue，跟 CUDA 侧这条线不是一回事，处置方向也不一样。
最后一条，也是最常被忽略的： issue #940 是 2023 年的，标签是 User Support，至今 open。它能给你的只是「有人在老 NVIDIA 卡上怀疑过这个默认参数」这一个信息量。它不能给你的是：官方结论、适用卡型范围、修复计划。别把一条 open 的求助帖读成官方文档。
排查这类问题，最值钱的不是记住哪个参数管用，而是养成先做减法的习惯：--cpu 砍掉一半、--disable-all-custom-nodes 再砍掉一半、--verbose DEBUG 把剩下的照亮，最后才轮到改具体开关。顺序反了，你会在一个错的方向上花掉一整个晚上。
以上命令均为按 v0.31.0 的官方参数语义组合的示例，未逐项实测，以官方文档与 python main.py --help 的实际输出为准。
延伸阅读
本文依据 ComfyUI 官方仓库（github.com/Comfy-Org/ComfyUI）的 README、comfy/cli_args.py、
release notes 与官方安全公告整理，核对日 2026-08-09，对应版本 v0.31.0；
文中引用的 issue 状态为该日期的快照。本文内容为官方文档与源码口径，非本机实测。
参数、默认值与功能随版本变动，请以官方文档与 python main.py --help 的实际输出为准。