RuntimeError: Expected all tensors to be on the same device, but got weight is on cpu, different from other tensors on xpu:0 (when checking argument in method wrapper_XPU___fused_rms_norm)

问题场景

用户在 ComfyUI 0.36.0 上对 Minimax H3 模型执行 VAE encode/decode 流程（报错栈实际落在 VAE decode 的视频解码阶段，即 vae.decode → minimax/vae.py → comfy_kitchen rms_rope → torch.rms_norm）时触发异常。回退到 0.35.2 后相同操作正常。另有用户在 0.37.0 上以 --novram 启动时，于 VAE decode 视频步骤复现；同一环境下音频 VAE decode 正常，改用 --lowvram 则可通过。

报错原文

RuntimeError: Expected all tensors to be on the same device, but got weight is on cpu, different from other tensors on xpu:0 (when checking argument in method wrapper_XPU___fused_rms_norm)

[ERROR] !!! Exception during processing !!!
[ERROR] Traceback (most recent call last):
  File "E:\ComfyUI\execution.py", line 547, in execute
    ...
  File "E:\ComfyUI\comfy\ldm\minimax\vae.py", line 805, in decode
    return self.decode_temporal(z, output_buffer)
  File "E:\ComfyUI\comfy\ldm\minimax\vae.py", line 740, in decode_temporal
    clip_dec = self._adaptive_decode(clip_z)
  File "E:\ComfyUI\comfy\ldm\minimax\vae.py", line 502, in _adaptive_decode
    return self.tiled_decode(z)
  File "E:\ComfyUI\comfy\ldm\minimax\vae.py", line 614, in tiled_decode
    tile = next(tiles)
  File "E:\ComfyUI\comfy\ldm\minimax\vae.py", line 595, in _decode_tile_row
    yield from self._decode_pixels(torch.cat(group)).chunk(len(group))
  File "E:\ComfyUI\comfy\ldm\minimax\vae.py", line 476, in _decode_pixels
    return self.decoder(self.post_quant_conv(z))
  ...

原因分析

从报错本身看，激活张量已经位于 xpu:0，但参与 fused_rms_norm 的某个 RMSNorm scale/weight 权重张量仍留在 CPU，因此算子检查设备一致性时直接失败。结合 0.35.2 正常、0.36.0 失败的分界，这更像是 0.36.0 引入的一次设备放置回归，并且只在走 tiled/adaptive VAE 视频解码路径、需要调用 rms_rope 时暴露出来。

0.37.0 在 --novram 下复现、--lowvram 可绕开，说明显存管理策略会影响权重张量被放到哪块设备，但不代表根因就是显存策略本身。执行栈中出现的 ComfyUI-Lora-Manager 钩子只是包了一层节点调用，最终报错发生在更底层的 core/kitchen 代码，因此不能直接归因于该自定义节点。

环境排查

• 确认 ComfyUI 版本：0.36.0 触发、0.35.2 正常；0.37.0 在 --novram 下可复现。
• 确认启动参数：是否使用 --novram；可对照测试 --lowvram。
• 确认运行设备为 Intel XPU（报错设备名 xpu:0），并记录所使用的 Intel 显卡与驱动版本。
• 记录 Python、PyTorch/IPEX 版本（Issue 正文未提供，需要用出问题的机器自行记录）。
• 先禁用全部自定义节点重跑，以排除 ComfyUI-Lora-Manager 等钩子对执行栈的干扰。
• 确认触发节点是 Minimax VAE 解码中的视频路径，而非音频路径（后者在本 Issue 中正常）。

解决步骤

1. 先用 0.35.2 与 0.36.0 对照复现，确认是否为自己环境下的版本分界问题（Issue 中报告者已验证此分界）。
2. 在 0.36.0 上禁用所有自定义节点后重跑同一工作流，排除 LoRA Manager 等钩子的影响。若此时不再报错，先定位具体自定义节点，而不是按内核问题处理。
3. 若禁用自定义节点后仍然复现，说明问题在 core/kitchen 路径；如使用 --novram，可优先尝试改用 --lowvram 作为规避手段（Issue 中有用户报告此方式可通过）。
4. 需要定位细节时，在 rms_rope 调用前打印 query、key、rotary_pos_emb、q_scale、k_scale 各自的 device。若 q/k 已在 XPU 而某个 scale 张量仍在 CPU，即可确认是设备放置回归。
5. 应用 PR #16391 的代码改动（Issue 中报告者确认此修改解决了问题）。
6. 升级到包含该修复的最新版本（Issue 关闭时状态为 “issue solved in latest version”）。

验证方法

重新运行同一 Minimax H3 VAE decode 工作流（即原先触发 fused_rms_norm 报错的视频解码步骤），确认不再出现设备不一致异常；同时对照音频 VAE decode 仍能正常完成，说明修复没有破坏原有路径。

参考来源

Comfy-Org/ComfyUI #16390

AI 工具推荐

想把多个 AI 模型放在一个入口？

GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。

了解 GamsGo AI

推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。