R9700 comfyUI ROCm 10.x up 有人跑通嗎？我看還有不少 issue 求大佬帶飛

CS6

[gfx1201] hip 後端缺少無 _dtype 後綴的 dequant 函式 —— 靜默退回慢速單執行緒 eager 後端,導致模型載入異常緩慢

回報的 repo: Comfy-Org/comfy-kitchen

摘要

在 AMD Radeon AI PRO R9700(RDNA4,gfx1201)上,載入任何權重會經過 comfy/ops.py 的 _load_quantized_module() 路徑的量化模型,對於數十 GB 等級的模型會需要 10 到 60 分鐘以上,整段時間單一 CPU 核心會被釘在 ~95-100% 使用率,而 GPU 使用率始終接近 0%。

根因:comfy_kitchen 的 hip 後端只實作了幾個反量化(dequantize)函式的 _dtype 後綴版本,卻沒有實作 comfy/ops.py 在載入權重時真正呼叫的「無後綴」(bare)版本。由於 BackendRegistry 的優先序是 ["hip", "cuda", "triton", "eager"],而 hip 沒有把這個無後綴函式名稱註冊為自己的能力,dispatch 機制找不到 hip 候選,只好一路退回到 eager——一個純 Python/通用 PyTorch 實作,完全沒有 ROCm 加速——而且是對每一個權重張量都這樣做。

這個問題在一個完全乾淨的安裝環境下就能重現(官方 rocm/pytorch:rocm10.0_ubuntu26.04_py3.14_pytorch_release_2.13.0 Docker image、comfy-kitchen==0.2.35、依規定額外裝好 amd-torch-device-gfx1201==2.13.0+rocm10.0.0),所以不是環境設定錯誤造成的。

環境資訊

GPU:AMD Radeon AI PRO R9700(RDNA4,gfx1201)
OS/Image:rocm/pytorch:rocm10.0_ubuntu26.04_py3.14_pytorch_release_2.13.0(AMD 官方 image)
torch:2.13.0+rocm10.0.0(+ 另外裝 amd-torch-device-gfx1201==2.13.0+rocm10.0.0,這是讓任何 kernel 能正常派發運算所必需的——詳見下方備註)
comfy-kitchen:0.2.35(在 0.2.10 上也重現)
ComfyUI:2026-09-20 當下的 master 分支
涉及的自訂節點:ComfyUI_MinimaxH3HybridLoader / ComfyUI-MiniMax-H3-Turbo(MiniMax H3 影片模型,int8_convrot 量化的 ~25GB 文字編碼器 + ~20GB 擴散模型 transformer),但同樣的「Found quantization metadata version 1」/「Using MixedPrecisionOps for text encoder」卡死症狀,也有其他使用者在載入完全不相關的模型(例如 Pixal3D/Trellis2)、同樣是 gfx1201 架構上獨立回報過——見下方「相關回報」。所以這看起來不是特定模型才有的問題。

重現步驟

在 gfx1201 機器上,安裝乾淨的 comfy-kitchen==0.2.35 + 對應的 ROCm-10.0 torch 全套(torch、amd-torch-device-gfx1201、rocm-sdk-core/rocm-sdk-libraries/rocm-sdk-device-gfx1201,版本都對齊 ==...+rocm10.0.0/10.0.0)。
確認基本運算正常(torch.ones(4,4,device='cuda')+1、fp16 矩陣乘法)——這些都會成功,確認基礎安裝沒問題。
載入任何權重使用 comfy.ops.MixedPrecisionOps、採 int8_convrot(或單純 int8)量化、且權重數量不小(數百到數千個張量)的模型。

觀察 log 卡在這裡不動:

Found quantization metadata version 1
Using MixedPrecisionOps for text encoder
CLIP/text encoder model load device: cuda:0, offload device: cpu, current: cpu, dtype: torch.float16
Requested to load MiniMaxH3TEModel_
Model MiniMaxH3TEModel_ prepared for dynamic VRAM loading. 25882MB Staged. 0 patches attached. Force pre-loaded 310 weights: 1272 KB.

對 ComfyUI process 跑 ps -o pid,etimes,time,pcpu,會看到單一執行緒整段時間都釘在 ~90-100% CPU;rocm-smi --showuse 則顯示 GPU 使用率全程只有 ~0-3%。

根因分析

>>> import comfy_kitchen
>>> from comfy_kitchen.registry import registry
>>> registry._priority
['hip', 'cuda', 'triton', 'eager']
>>> sorted(registry._capabilities['eager'] - registry._capabilities['hip'])
['dequantize_int8_convrot_weight', 'dequantize_int8_embedding', 'dequantize_int8_simple',
 'dequantize_mxfp8', 'dequantize_nvfp4', 'prepare_int4_weight_for_int8_linear',
 'quantize_mxfp8', 'quantize_nvfp4', 'rotate_int8_convrot_weight',
 'scaled_mm_mxfp8', 'scaled_mm_nvfp4']

comfy_kitchen/backends/hip/__init__.py 定義了 dequantize_int8_convrot_weight_dtype(...) 跟 dequantize_int8_simple_dtype(...),但從來沒有註冊 comfy/ops.py 模型載入路徑(_load_quantized_module → 權重反量化/重新量化)實際呼叫的無後綴版本 dequantize_int8_convrot_weight / dequantize_int8_simple。反觀 comfy_kitchen 自己的 cuda 後端確實有把這兩個無後綴函式實作成一行的 wrapper,內部呼叫 _dtype 版本並預設輸出 float32:

# backends/cuda/__init__.py
def dequantize_int8_convrot_weight(q, scale, group_size) -> torch.Tensor:
    return dequantize_int8_convrot_weight_dtype(q, scale, group_size, DTYPE_TO_CODE[torch.float32])

hip 後端沒有對應的實作——這個無後綴的函式名稱根本沒出現在它的 _build_constraints() 能力字典裡——所以 dispatch 對這個函式名稱找不到任何 hip 候選,只好一路掉到優先序清單最後的 eager。

已驗證的部分修法

把同樣的一行 wrapper 模式加進 comfy_kitchen/backends/hip/__init__.py(兩個函式都加),並在 _build_constraints() 補上對應的能力條目,確實有效——直接驗證過:

>>> import comfy_kitchen
>>> from comfy_kitchen.registry import registry
>>> 'dequantize_int8_convrot_weight' in registry._capabilities['hip']
True
>>> comfy_kitchen.backends.hip.dequantize_int8_convrot_weight(q, scale, 64)  # 在 GPU 上跑,輸出正確

# 加在 backends/hip/__init__.py 裡,dequantize_int8_simple_dtype 後面:
def dequantize_int8_simple(q: torch.Tensor, scale: torch.Tensor) -> torch.Tensor:
    return dequantize_int8_simple_dtype(q, scale, DTYPE_TO_CODE[torch.float32])

# 加在 dequantize_int8_convrot_weight_dtype 後面:
def dequantize_int8_convrot_weight(q: torch.Tensor, scale: torch.Tensor, group_size: int) -> torch.Tensor:
    return dequantize_int8_convrot_weight_dtype(q, scale, group_size, DTYPE_TO_CODE[torch.float32])

(另外在 _build_constraints() 裡加對應的 "dequantize_int8_simple" / "dequantize_int8_convrot_weight" 條目,內容照抄 _dtype 版本、只是拿掉 output_dtype_code 這個參數。)

但這只解決了一部分的卡死問題。 套用這個修法之後,同一個模型還是會在同一行 log 卡住 30 分鐘以上。dequantize_int8_embedding 在 hip 完全沒有實作(連 _dtype 版本都沒有可以借用)——這幾乎可以確定是文字編碼器載入卡住的真正原因,因為文字編碼器有很大的 embedding 表,而這個函式在 hip 上完全沒有加速路徑。這個需要真正寫一份原生實作,不是包一層 wrapper 就能解決,已經超出我自己能貢獻的範圍。

附註:重現過程中會先卡到的另一個、不相關的問題

給任何想重現這個問題的人:在全新安裝的 ROCm 10.0 環境下,torch.cuda.is_available() 會回傳 True、裝置名稱也能正確解析,但任何 kernel 呼叫(包括 torch.ones(4,4,device='cuda')+1)都會噴 hipErrorInvalidImage,除非額外裝上 amd-torch-device-gfx1201==2.13.0+rocm10.0.0(跟 torch/rocm-sdk-device-gfx1201 一起裝)。這是一個獨立的套件,裝的是 torch 給這個確切架構用的外部「kernel pack」——官方安裝文件並沒有明顯提到這點。這不是 comfy-kitchen 的 bug,只是在這顆晶片上除錯任何東西之前,值得先知道的前置條件。

請求

把缺的無後綴 dequantize_int8_convrot_weight / dequantize_int8_simple wrapper 加進 hip 後端(修法如上,如果有幫助我很樂意開 PR)。
應該需要一份原生(或包裝過)的 hip 版 dequantize_int8_embedding 實作,才能完全解決 gfx1201 上有量化 embedding 表的模型(例如文字編碼器)的載入卡死問題。
更廣泛地說:能不能讓這類 dispatch 缺口變得「看得見」(例如第一次某個函式從「應該要加速」的後端掉到 eager 時印一行警告),而不是完全靜默?這樣可以省下很多除錯時間——現在的 log 完全沒有任何跡象顯示一個 25GB 的模型即將被丟進通用 Python fallback 路徑處理。

備註

我看到 #183(還沒合併)已經在針對 gfx1200/gfx1201、專門為 H3 形狀的 projection 調校 HIP INT8 ConvRot 的計算 kernel(@qweqweewqe7-create)——那是同一條程式碼路徑的不同層次(kernel 幾何/效能調校,前提是 dispatch 真的有走到 hip),跟這個 dispatch 缺口是不同問題,但特別標記出來讓大家看到,因為顯然是同一個問題領域跟同一款硬體。如果能讓這兩邊的努力互相對上,應該會很有幫助。

Xiaote

这看着就是 comfy-kitchen hip 后端的 capability 注册缺失，不是你的环境问题——你定位到 bare vs _dtype 后缀这一步，方向是对的。

把机制说完整一点：comfy/ops.py 的 _load_quantized_module() 调的是无后缀函数名，BackendRegistry 按 ["hip","cuda","triton","eager"] 找候选；hip 只在带 _dtype 后缀的名字上注册了能力，于是候选里没有 hip，一路退到 eager，而且对每个权重张量都重试一次这个回退——几十 GB 模型钉死一个核 10–60 分钟、GPU 全程 0%，症状完全对得上。

可做的几步：

先把差异坐实：在干净环境里把 hip 后端实际注册的算子名列出来，和 comfy/ops.py 里真正被调用的 bare 名对一遍，确认差的就是那几个 dequant 的 bare alias（hip 有 xxx_dtype、没有 xxx）。这一步的证据比"加载很慢"更能让上游认账。
临时绕过（不改上游代码）：在 ComfyUI 启动前 monkeypatch，把 hip 后端的 _dtype 实现注册一个无后缀别名进去：
reg.register("hip", bare_name, getattr(hip_impl, dtype_name))
具体签名以 comfy-kitchen==0.2.35 的 BackendRegistry 为准。注册成功后 dispatch 会命中 hip，不再退 eager。这是验证根因最快的方式。
pin 版本 + 报上游：ROCm 10.0 + torch 2.13 + py3.14 + comfy-kitchen 0.2.35 + 当天 master 是极前沿组合，能复现就尽快给 Comfy-Org/comfy-kitchen 开 issue，附最小复现（干净 image、版本号、缺失的 bare/dtype 名清单）。这种注册缺失上游补起来通常很快，等它比你自己维护 patch 省事。
别把希望押在单卡 32G：25GB TE + 20GB DiT，就算 dequant 修好，加载/推理仍要 offload，速度受 PCIe 和系统内存约束；修好 bare dispatch 解决的是"加载 10–60 分钟"，不等于全流程飞快。
合并报告：Trellis2/Pixal3D 在 gfx1201 上的独立回报告诉你这不是特定模型，开 issue 时把这些也挂上，说明是后端注册层的系统性问题。

terry

我弟这个话题太深奥，论坛没几个看得懂的

David Wang

请问用4090 48G 在linux环境也有这个问题吗？

抡锤者

R9700 comfyUI ROCm 10.x up 有人跑通嗎？我看還有不少 issue 求大佬帶飛

摘要

環境資訊

重現步驟

根因分析

已驗證的部分修法

附註:重現過程中會先卡到的另一個、不相關的問題

相關回報(獨立佐證這是 `gfx1201` 這一整代的通病,不是特定模型才有)

請求

備註

抡锤者

R9700 comfyUI ROCm 10.x up 有人跑通嗎？ 我看還有不少 issue 求大佬帶飛

摘要

環境資訊

重現步驟

根因分析

已驗證的部分修法

附註:重現過程中會先卡到的另一個、不相關的問題

相關回報(獨立佐證這是 gfx1201 這一整代的通病,不是特定模型才有)

請求

備註

R9700 comfyUI ROCm 10.x up 有人跑通嗎？我看還有不少 issue 求大佬帶飛

相關回報(獨立佐證這是 `gfx1201` 這一整代的通病,不是特定模型才有)