ComfyUI 报 CUDA no kernel image is available：成因方向与判定路径

2026-08-09

CUDA error: no kernel image is available for execution on the device 这条报错，是 ComfyUI 装完之后最容易让人卡在第一步的那一类。它的特点是：ComfyUI 本身能起来，网页也打得开，工作流一跑到真正上 GPU 的节点就炸。于是很多人第一反应是「显存不够」「模型有问题」，开始换模型、加 --lowvram，绕一大圈都没绕到点上。

先按字面读这条串：no kernel image is available for execution on the device，说的是「设备上没有可用的 kernel image」，指向的是编译产物与设备对不上，而不是「显存不够」「模型文件坏了」这类描述。ComfyUI 官方 README 里跟显卡型号、CUDA 版本直接挂钩的规则，集中在安装矩阵那一节；所以这条串该先往哪儿查，README 其实已经给了指引。方向选错，后面所有动作都是白费。

官方仓库确实有这条错误的开放条目：issue #10468 反映了「CUDA error: no kernel image is available for execution on the device」这一现象，该 issue 创建于 2025-10-24，标签为 User Support，评论数 31，截至 2026-08-09 仍为 open。这里有两点要如实说清楚：第一，它的标签是 User Support 而不是 Bug 或 Potential Bug，也就是说它在仓库的分类里被归为用户支持问题，并不是官方确认的代码缺陷；第二，仍为 open 不等于官方正在修，也不等于无解。我们没有读过这条 issue 的正文和评论，所以下面所有的判断依据，一条都不来自它，全部来自官方 README 的版本矩阵和 comfy/cli_args.py（v0.31.0，核对日 2026-08-09）的参数语义。

判定第一步：先确认卡的代次，别急着看 torch

顺序反了是这类问题最常见的时间浪费。很多人上来就去查 torch 版本、装 nightly、换 CUDA Toolkit，装了一晚上还是同一条错——因为 ComfyUI 官方 README 是按显卡代次划分安装路径的，代次没定下来，torch 装哪个版本都是猜。

README 在版本矩阵里写得很直接：cu130 及以上，在 NVIDIA 20 系及以上是必需的（required）。同时 torch 2.7 是最低支持版本（minimally supported），但 README 极力推荐用更新的版本，并额外补了一句：如果你的 pytorch 超过 6 个月没更新，请更新它。

Windows portable 的分包规则把这件事说得更硬。官方一共提供四个包：

包	文件名	README 写明的适用范围
NVIDIA	`ComfyUI_windows_portable_nvidia.7z`	supports 20 series and above
NVIDIA 旧卡	`ComfyUI_windows_portable_nvidia_cu126.7z`	pytorch cuda 12.6 + python 3.12，Supports Nvidia 10 series and older GPUs，DO NOT USE THIS ON NEWER 20 SERIES AND ABOVE GPUS
AMD	`ComfyUI_windows_portable_amd.7z`	AMD GPUs
Intel	`ComfyUI_windows_portable_intel.7z`	Intel GPUs

这张表里唯一用全大写写的就是那句 DO NOT USE。README 很少这么写，说明这是个高频踩坑点。另外默认的 nvidia portable 包自带 python 3.13 与 pytorch cuda 13.0，README 还给了一句兜底：如果它起不来，更新 NVIDIA 驱动。

所以第一个判定动作就是回答两个问题：你的卡是 20 系及以上，还是 10 系及更老？你现在用的是哪个包 / 哪条 pip 命令装的 torch？ 这两个答案凑一起，错配基本就自己跳出来了。两种错配方向都存在，而且很容易反着犯：

新卡配旧构建：20 系及以上的卡，却下了 cu126 那个包，或者手动装了个老 torch。README 明说不要这么干。
老卡配新构建：10 系及更老的卡，用了默认的 nvidia portable（自带 cuda 13.0），而 README 给这类卡指的是 cu126 包。

判定第二步：确认 torch 构建，顺手把日志抓全

代次定了以后，才轮到确认「你环境里那个 torch 到底是什么构建」。这里有个 portable 用户特别容易搞错的点：portable 包自带一个内嵌的 Python，它和你系统里的 python 完全是两回事。在系统 CMD 里敲 python 查到的 torch 版本，跟 portable 实际跑的那个毫无关系。要问，就得用包里那个解释器去问。手动安装的用户同理，先确认自己在不在那个虚拟环境里。

抓日志这一步也值得单独说。comfy/cli_args.py（v0.31.0）里 --verbose 支持三种写法：不带值（等价于 DEBUG）、给一个 LEVEL、或者给 LEVEL FILE 两个值，合法等级是 DEBUG、DETAIL、INFO、WARNING、ERROR、CRITICAL，控制台默认 INFO。给两个值可以直接把详细日志落到文件里，比在控制台往上翻要靠谱。

还有一个反直觉的细节：--log-stdout 的 help 写的是「把正常进程输出送到 stdout」，并注明默认是 stderr。这解释了为什么不少人用 python main.py > log.txt 抓日志，结果文件里空空如也——输出压根没走 stdout。要么加 --log-stdout，要么用 --verbose DEBUG <日志文件路径> 直接指定文件。

把完整的 traceback 抓下来之后，重点只看一件事：报错串到底是哪一条。是 no kernel image is available for execution on the device，还是别的？这决定了要不要继续往下走。下一节会列几条长得很像、但完全不是同一回事的报错。

处置：按官方给的路径重装，别混装

README 在 Troubleshooting 章节只给了一条明确的处置办法，针对的是 Torch not compiled with CUDA enabled：

pip uninstall torch

然后用对应平台的命令重新装。这条思路对我们这个场景同样适用——先卸干净再按官方命令装，而不是在旧环境上叠加安装。NVIDIA 侧 README 给的两条原始命令是：

pip install torch torchvision torchaudio --extra-index-url https://download.pytorch.org/whl/cu130

nightly：

pip install --pre torch torchvision torchaudio --index-url https://download.pytorch.org/whl/nightly/cu132

装完 torch 之后，在 ComfyUI 目录里补依赖：

pip install -r requirements.txt

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

portable 用户的处置更简单粗暴：别在 portable 里手动折腾 torch，直接换成代次对应的那个包。10 系及更老换 cu126 包，20 系及以上用默认的 nvidia 包。顺带两条 README 里的解压提示：用 7-Zip 或较新版本 Windows 的资源管理器解压；解压出问题时，右键文件 → 属性 → 解除锁定（unblock）。模型不用重下，小模型放回 ComfyUI\models\checkpoints，多文件的大模型按说明放进 ComfyUI\models\ 下对应子目录；如果不想搬来搬去，README 指向仓库里的 extra_model_paths.yaml.example，改名为 extra_model_paths.yaml 后编辑，就能让新包直接指到原来的模型目录。

Python 版本这里也顺带确认一下，README 的口径是：3.13 支持得很好（very well supported）；3.12 是在 3.13 上遇到自定义节点依赖问题时的退路；3.14 能用，但某些自定义节点可能有问题，free threaded 变体因为部分依赖会启用 GIL，不算完全支持。cu126 那个 portable 包自带的就是 3.12。

处置后怎么验证

验证不要只看「网页打得开」，那一步在出问题之前本来就是好的。要看的是：

重新启动一次，用同样的方式抓完整日志（--verbose DEBUG <日志文件路径>，或加 --log-stdout 后重定向）。
在新装好的那个解释器环境里再确认一次 torch 的构建版本，跟你的代次对上 README 的要求（20 系及以上要 cu130 及以上）。
跑一次原来必炸的那条工作流，重点确认那条错误串还在不在。注意是「同一条串还在不在」，而不是「报没报错」——换成另一条错误串，说明第一层问题过去了，接着按新的串排。

如果换包/重装之后仍是同一条 no kernel image 串，且代次与构建确认无误，那么再考虑 README 那条兜底提示：更新 NVIDIA 驱动。这条是官方对默认 nvidia portable 起不来时给的建议，不是对本错误的专门解法，别指望它必然管用。

什么情况说明不是这个原因

这一节是这篇文章相对「报错大全」的唯一增量。下面几种情况，往版本矩阵上查都是白查：

报的是 Torch not compiled with CUDA enabled。 这是 README Troubleshooting 章节里唯一列出的那条错误。它字面说的是「当前这个 torch 在编译时就没启用 CUDA」，和「有 CUDA、但没有对应架构的 kernel」不是同一句话。README 给的处置很直接：pip uninstall torch，然后按对应平台的命令重装。README 对这条错误没有再给别的说明，我们也不替它补。

报的是 operation not supported。 官方仓库 issue #940 反映了「Default arg “cuda-malloc” causes CUDA error: operation not supported on GTX 960M GPU」这一现象，该 issue 创建于 2023-07-19，标签为 User Support，评论数 43，截至 2026-08-09 仍为 open。我们没有读过它的正文，不对根因下结论；但从参数侧有一个成本极低的对照动作：comfy/cli_args.py（v0.31.0）里 --cuda-malloc / --disable-cuda-malloc 是一组互斥参数，help 注明 torch 2.0 及以上默认启用 cudaMallocAsync。也就是说这个东西默认是开着的，你没加参数不代表它没生效。加上 --disable-cuda-malloc 再起一次，是一条能明确二分的判定动作。

报的是显存不足类。 这类现象在仓库里另有条目，跟本文完全不是一条线。看到 OOM 就不要再回头折腾 CUDA 构建版本了。

只在开了某个 attention 实现时才炸。 comfy/cli_args.py（v0.31.0）里 --use-split-cross-attention、--use-quad-cross-attention、--use-pytorch-cross-attention、--use-sage-attention、--use-flash-attention 是一组五选一的互斥参数，加了其中任何一个，跑的就不是默认那条实现路径。判定动作是：把这些参数全部去掉，用最朴素的 python main.py 再起一次。如果去掉就不炸，问题范围就缩到你选的那个实现上，而不是版本矩阵。顺带一提，前两个的 help 还注明「Ignored when xformers is used」，也就是说在用 xformers 的环境里它们会被忽略——你以为切换了，其实没切。

只在装了某些自定义节点时才炸。 直接用 --disable-all-custom-nodes 起一次做对照，这个参数的语义就是不加载任何自定义节点。如果干净启动一切正常，那就是节点侧带的东西有问题，跟版本矩阵无关。需要保留个别节点时，可以配合 --whitelist-custom-nodes 指定目录，二分定位。

你根本不是 N 卡。 AMD、Intel、Apple Silicon 各有各的安装路径和各自的典型报错，README 里 AMD 走 ROCm 或 Experimental 的 Windows/Linux 构建（后者 README 注明硬件支持更少，仅 RDNA 3、3.5、4），Intel Arc 走 xpu 索引，Apple 走 pytorch nightly。看到 CUDA 字样的错误串出现在非 N 卡环境里，第一件事是回头确认自己装的是不是对应平台的包，而不是去调 CUDA 版本。

最后提醒一句：这类问题的解决顺序几乎从来不是「多试几个参数」，而是「把代次和构建这两个事实钉死」。参数能改的是行为，改不了二进制里编译进去了哪些架构。

延伸阅读

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