回報的 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 架構上獨立回報過——見下方「相關回報」。所以這看起來不是特定模型才有的問題。

重現步驟

1. 在 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)。
2. 確認基本運算正常(torch.ones(4,4,device='cuda')+1、fp16 矩陣乘法)——這些都會成功,確認基礎安裝沒問題。
3. 載入任何權重使用 comfy.ops.MixedPrecisionOps、採 int8_convrot(或單純 int8)量化、且權重數量不小(數百到數千個張量)的模型。
4. 觀察 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.
   

5. 對 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,只是在這顆晶片上除錯任何東西之前,值得先知道的前置條件。

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

• Comfy-Org/ComfyUI#15001 —— 同樣的架構(R9700/gfx1201)、同樣的「Found quantization metadata version 1」卡死訊號,但是不同模型(LTX 2.3)。那邊的根因被追到是 mmap-backed 的 .to(device) 額外開銷(每個張量固定約 0.5 秒),而不是這個 dispatch 缺口——很可能是這個架構上第二個、獨立的慢速路徑,不是同一個 bug,因為我們這邊套用 --disable-mmap 並沒有解決卡死問題。
• r/comfyui 上一篇討論透過 comfy-kitchen 的 hip 後端跑 Pixal3D/Trellis2 的文章:在 RDNA3(7900XT,gfx1100)上 93.99 秒就跑完,完全正常;但在 RDNA4(RX 9070,gfx1201)上,同一段 _naf_hr 程式碼路徑卡了 3 分鐘以上,而且逐步計時顯示 RDNA4 特有的變慢集中在特定的張量形狀呼叫上。同樣的世代規律:RDNA3 正常、RDNA4(gfx1201)壞掉。
• ROCm/TheRock#7992、#7861、#7839 —— 另外幾個跟 ROCm 10.0/torch 2.13「kernel pack」架構有關的 gfx1201/gfx1151 kernel dispatch 回歸問題,其中多個都回報 7.14.0 是最後一個已知正常的版本。

請求

• 把缺的無後綴 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 缺口是不同問題,但特別標記出來讓大家看到,因為顯然是同一個問題領域跟同一款硬體。如果能讓這兩邊的努力互相對上,應該會很有幫助。