AMD 卡上 ComfyUI 跑不动的排查清单
AMD 卡上跑 ComfyUI 最难受的地方，不是报错本身，而是同一句「跑不动」可能落在四个完全不同的层上：torch 根本不是 ROCm 构建、torch 是 ROCm 构建但你的卡不在官方支持列表里、卡在支持列表里但加载环节停住、以及压根跟 AMD 没关系的通用问题。这四层的处置手段互不相通，顺序搞错就会一路瞎试。
下面这份清单按「先排除便宜的可能」的顺序走。所有事实来自 ComfyUI 官方仓库 README 与 comfy/cli_args.py（v0.31.0，2026-08-08），不是本机实测；参数与默认值会随版本变，最终以 python main.py --help 的实际输出为准。
第一步：先确认 torch 到底是不是 ROCm 构建
现象：启动直接崩，或者一跑就报 Torch not compiled with CUDA enabled。
怎么确认：报错文案里带 CUDA，但它同样会出现在 AMD 机器上——因为照着 NVIDIA 教程装出来的 torch 一样能 import，光看「装好了」判断不出问题。README 的 Troubleshooting 章节整节只给了这一条故障与处置，就是这一条。
处置：README 的做法是先卸载：
pip uninstall torch
然后用你这块卡对应平台的命令重新装一遍。AMD 在 Linux 上的稳定版命令是：
pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/rocm7.2
ROCm 7.2 的 nightly 是这条：
pip install --pre torch torchvision torchaudio --index-url https://download.pytorch.org/whl/nightly/rocm7.2
注意 index-url 是 rocm7.2 而不是 cu130——这就是区别所在。装完在 ComfyUI 目录里再跑一次 pip install -r requirements.txt。
怎么验证：重新 python main.py，看启动日志有没有打印 Total VRAM {} MB, total RAM {} MB 和 Set vram state to: {名字} 这两行。前者说明设备被识别到了，后者告诉你当前落在哪个 VRAM 状态上（源码里的枚举是 DISABLED / NO_VRAM / LOW_VRAM / NORMAL_VRAM / HIGH_VRAM / SHARED）。
什么情况说明不是这个原因：如果这两行日志本来就打印得好好的，说明 torch 侧没问题，别在这一层继续折腾，直接跳到第二步。
第二步：确认自己该走哪条安装线
现象：torch 装的确实是 ROCm 版本，但启动就是识别不到卡，或者一跑就崩。
怎么确认：先搞清楚你的卡属于哪一代。README 在 AMD 这块给了两套完全独立的路线，很多人不知道有第二套：
| 路线 | 命令 index | README 定位 |
|---|---|---|
| ROCm 稳定版 | download.pytorch.org/whl/rocm7.2 | Linux |
| ROCm 7.2 nightly | download.pytorch.org/whl/nightly/rocm7.2 | Linux |
| RDNA 3（RX 7000 系） | rocm.nightlies.amd.com/v2/gfx110X-all/ | Experimental，Windows 与 Linux |
| RDNA 3.5（Strix halo / Ryzen AI Max+ 365） | rocm.nightlies.amd.com/v2/gfx1151/ | Experimental，Windows 与 Linux |
| RDNA 4（RX 9000 系） | rocm.nightlies.amd.com/v2/gfx120X-all/ | Experimental，Windows 与 Linux |
后三条的完整写法形如：
pip install --pre torch torchvision torchaudio --index-url https://rocm.nightlies.amd.com/v2/gfx120X-all/
处置：README 对这三条 index 的说明是——它们比上面的构建硬件支持更少，但能在 Windows 上工作，并且要装对应自己硬件的 pytorch 版本。这个定位很关键：它不是「更好的选择」，而是「用支持面换 Windows 可用性」的实验性通道，README 把它归在 Experimental 下。Windows 上走 Manual Install 想用 AMD 卡，README 给的就是这三条 index；Linux 用户如果稳定版能用，就没必要换过来。
Windows 侧另有一个官方 portable 包 ComfyUI_windows_portable_amd.7z。但要提醒一句：README 在 Installing 章节明确写了 portable 包不推荐给普通用户，普通用户应该用桌面应用。portable 的定位是「拿到最新 commit + 完全便携」，不是「更专业的选择」。
怎么验证：换完 index 重装后，同样看启动日志那两行。
什么情况说明不是这个原因：如果你的卡不属于 RDNA 3 / 3.5 / 4 中任何一代，这三条 nightly index 不是给你准备的，换过去也没意义，往下走第三步。
第三步：卡不在 ROCm 正式支持列表里，用 HSA_OVERRIDE_GFX_VERSION
现象：torch 是 ROCm 的，卡也在，但一到实际计算就出问题。
怎么确认：看你的卡是不是 README 点名的「ROCm 未正式支持」那一类。README 的 Running 章节只给了两个取值，对应两类卡：
- 6700、6600 以及可能的其它 RDNA2 或更老的卡：
HSA_OVERRIDE_GFX_VERSION=10.3.0 python main.py
- AMD 7600 以及可能的其它 RDNA3 卡：
HSA_OVERRIDE_GFX_VERSION=11.0.0 python main.py
处置：照抄对应那条。README 用的措辞是「以及可能的其它」，这是留了余地的说法，意思是它没给你一张完整的卡型对照表，同代的其它型号只是「有可能」适用。别指望这两个值能覆盖所有情况。
另外要注意，README 给的是 shell 里前置环境变量的写法，属于 Linux/macOS 口径。Windows 上设置环境变量的方式不同，README 没有给对应写法，别把这一行原样粘进 PowerShell 就认定等价。
怎么验证：加了这个环境变量之后重新启动，看能不能走完一次最简单的图。
什么情况说明不是这个原因：如果你的卡本来就在 ROCm 正式支持范围内（比如你走的是第二步里的 RDNA 4 nightly），这个变量不该乱加——它的用途是「让 ROCm 把你的卡当成另一个 gfx 版本」，在本来就支持的卡上属于额外变量，排查时反而干扰判断。
第四步：能起来，但停在「Requested to load」不动了
现象：日志打印出 Requested to load {模型类名} 之后就没了下文，进度条不动，也不报错。
怎么确认：官方仓库 issue #13730 反映了「LTX 2.3 FP8/Q4KM 在 RX 7900 XTX + ROCm 上会在 Requested to load LTXAV 处停住，除非把 dynamic VRAM / pinned memory / async offload 关掉」这一现象，该 issue 创建于 2026-05-06，标签为 Potential Bug，截至 2026-08-09 仍为 open。这里必须说清楚两件事：标签 Potential Bug 的字面含义是「疑似 bug」，不代表官方已确认；我们也没有读过这条 issue 的正文与评论，所以下面给的不是「issue 里的解法」，而是按 cli_args.py 的参数语义推出的三个可关的开关。
处置：这三个机制在 v0.31.0 里各自有独立的关闭开关：
| 机制 | 关闭参数 | help 原意 |
|---|---|---|
| dynamic VRAM | --disable-dynamic-vram | 关闭 dynamic VRAM，改用基于估算的模型加载 |
| pinned memory | --disable-pinned-memory | 禁用 pinned memory |
| async offload | --disable-async-offload | 关闭异步权重卸载 |
排查时一个一个加，别三个一起上——三个一起关就算好了，你也不知道是哪个在起作用，下次升级完还得重来一遍。
顺带说一个反直觉的点：dynamic VRAM 在默认状态下是开着的。源码里的判定函数是这样写的：
def enables_dynamic_vram():
if args.enable_dynamic_vram:
return True
return not args.disable_dynamic_vram and not args.highvram and not args.gpu_only and not args.novram and not args.cpu
也就是说，你什么参数都不加时它是启用的，而这时候 --lowvram 按其 help 原文「Doesn’t do anything if dynamic vram is enabled」——什么都不做。老教程里「显存小就加 --lowvram」这一条在当前版本已经不成立了，这是很多人从旧版本换过来之后困惑的来源。反过来，--highvram、--gpu-only、--novram、--cpu 这四个会顺带关掉 dynamic VRAM，你以为只是让模型多留在显存里，实际上同时退回了估算式加载。
怎么验证：加参数重启后，盯 Requested to load 那一行后面还有没有 {N} models unloaded. 之类的后续输出；日志里 Enabled pinned memory {} 和 Using async weight offloading with {} streams 这两行在关掉对应机制后应该不再出现，可以用它们确认参数真的生效了，而不是拼错被忽略。
什么情况说明不是这个原因：如果你根本没走到 Requested to load 这一行就崩了，那是加载之前的问题，回第一、二步。
第五步：Triton 后端在 AMD 上有「自动默认」
这条容易被漏掉，因为它跟大多数人对 ComfyUI 参数的直觉相反。
--enable-triton-backend 的 help 写的是启用 comfy-kitchen 的 Triton 后端，并注明启动时默认关闭。但另一个参数 --disable-triton-backend 的 help 写的是强制关闭，覆盖 ROCm/AMD 的自动默认与 --enable-triton-backend。
把这两句放一起读就明白了：「默认关闭」是通例，AMD/ROCm 上存在一个「自动默认」，是这个通例之外的分支。所以如果你在 AMD 上遇到跟注意力实现或算子相关的怪异行为，--disable-triton-backend 是一个值得试的排查开关——它的语义优先级最高，同时覆盖自动默认和显式启用。
怎么验证：加与不加各跑一次同一张图，看行为是否变化。什么情况说明不是这个原因：如果加上它之后现象一模一样，就把它从命令行里去掉，别留着当护身符——多一个非默认参数，下次排查就多一个变量。
提速开关：PYTORCH_TUNABLEOP_ENABLED=1，以及它的代价
README 在 AMD 这块给了一条提速提示：可以试试 PYTORCH_TUNABLEOP_ENABLED=1，并且明确注明代价是首次运行非常慢。
这条要单独拎出来讲，是因为它极容易被误判成故障：你为了提速加了这个变量，结果第一次跑比之前还慢得多，然后开始怀疑是不是环境又坏了，回头把前四步全查一遍。README 已经把这个代价写在明面上了，第一次慢是预期内的。判定方法也简单——把这个变量去掉再跑一次，如果速度回到原样，那就是它，不是别的。
哪些现象其实跟 AMD 没关系
AMD 用户有个共同的心理陷阱：一出问题就往「AMD 支持不好」上归因，然后在 ROCm 这一层反复折腾。下面这几种现象，官方口径里有更直接的解释，跟你是不是 A 卡无关：
- 高分辨率出黑图，且日志里有 xformers 告警。源码在检测到问题版本时会输出「WARNING: This version of xformers has a major bug where you will get black images when generating high resolution images.」并提示降级或升级 xformers。看到这条就是版本问题，官方指得很明确。另外
--fp16-vae的 help 本身就注明 might cause black images，先看自己有没有加它。 - 采样时没有预览图。
--preview-method的源码默认值是none。想要预览得显式加--preview-method auto。 - 改了 prompt 就重新加载模型。官方仓库 issue #14618 反映了「ComfyUI keeps loading models on every prompt change」这一现象，创建于 2026-06-24，标签为 Potential Bug，截至 2026-08-09 仍为 open。这条 issue 的标题里没有出现 AMD 或 ROCm，把这个现象直接归到显卡品牌上没有依据。README「Notes」章节给出的执行规则是：只有相对上次执行发生变化的部分会被执行，如果只改了图的末端，那么只有你改动的部分以及依赖它的部分会重新跑。判断自己是不是被缓存参数影响了，先看启动命令里有没有
--cache-none——它的 help 原意就是每次运行都重新执行每个节点。 - 日志里出现内存泄漏提示，例如
Potential memory leak detected with model {类名}, doing a full garbage collect...，官方文案给的方向是避免循环引用、检查还有谁在引用它。这类提示几乎总是指向自定义节点。用--disable-all-custom-nodes启动做一次二分，如果提示消失，问题就在节点侧，跟显卡没关系。 - Windows 上感觉可用显存莫名少了一点。源码里
EXTRA_RESERVED_VRAM默认是 400MB，而 Windows 上是 600MB，源码注释原文是#Windows is higher because of the shared vram issue。这是所有 Windows 用户都一样的，不是 AMD 特有。想自己接管这个值可以用--reserve-vram。
另外三条值得知道的 AMD 相关 open issue
排查时了解「有人跟你一样」是有用的，但只到「有人反映过」为止——我们没有读过这些 issue 的正文与评论，所以不要指望从这里拿到解法：
- issue #10369 反映了「Hip memory issue in 9070xt with rocm-7.0.2」这一现象，创建于 2025-10-16，标签为 Potential Bug，截至 2026-08-09 仍为 open。
- issue #8211 反映了「AMD RYZEN AI MAX+ 395 w/ Radeon 8060S not supported」这一现象，创建于 2025-05-20，标签为 Potential Bug，截至 2026-08-09 仍为 open。注意 README 里 RDNA 3.5 那条 nightly index 的括注写的是 Strix halo / Ryzen AI Max+ 365，与这条 issue 里的型号并不是同一个写法，不要想当然认为换上那条 index 就等于解决。
- issue #5759 反映了「ComfyUI Stuck During VAE Decoding」这一现象，创建于 2024-11-24，标签为 AMD、Potential Bug，截至 2026-08-09 仍为 open。
再说一遍：Potential Bug 是「疑似 bug」，不是官方已确认；仍为 open 也不等于官方认定无解。
一条组合起来的排查用启动命令
把上面几个排查开关拼在一起，大致是这个样子（仅用于定位问题，定位完请逐个去掉）：
python main.py --disable-dynamic-vram --disable-pinned-memory --disable-async-offload --disable-triton-backend --disable-all-custom-nodes --verbose DEBUG
--verbose 不带值时等价于 DEBUG，合法等级是 DEBUG / DETAIL / INFO / WARNING / ERROR / CRITICAL，默认控制台等级是 INFO。以上为按官方参数语义组合的示例，未逐项实测，以官方文档与 --help 输出为准。
这条命令的用途是「把所有可疑机制一次性摁掉，看还崩不崩」。如果这样都还崩，问题多半在第一、二步的环境层；如果不崩了，再一个一个把参数加回去，找出到底是哪一个。日常使用千万别长期挂着这一串——每个非默认参数都是下次排查时的噪音。
延伸阅读
- ComfyUI 在 Apple Silicon 上的已知边界：先分清是 MPS 的限制，还是你装错了环境
- ComfyUI 报 CUDA no kernel image is available：成因方向与判定路径
- ComfyUI 报 CUDA OOM 时的排查顺序
本文依据 ComfyUI 官方仓库（github.com/Comfy-Org/ComfyUI）的 README、comfy/cli_args.py、
release notes 与官方安全公告整理，核对日 2026-08-09，对应版本 v0.31.0；
文中引用的 issue 状态为该日期的快照。本文内容为官方文档与源码口径，非本机实测。
参数、默认值与功能随版本变动，请以官方文档与 python main.py --help 的实际输出为准。