ComfyUI 报错 qwen_image21 架构无法识别：升级 ComfyUI-GGUF 加载器完整实操

RTX 4070 12GB 环境下，升级 ComfyUI-GGUF 加载器并排除旧节点重复加载，成功修复 qwen_image21 架构报错

2026-09-27 约 3894 字预计阅读 8 分钟

/images/Code-Art-Studio-images/comfyui-qwen-image-2.1-gguf-qwen-image21-fix/comfyui-qwen-image-2.1-gguf-qwen-image21-fix.webp

ComfyUI 报错 qwen_image21 架构无法识别：升级 ComfyUI-GGUF 加载器完整实操

一篇基于实际 Ubuntu + RTX 4070 12GB 环境的排障记录。本文记录的是一次真实成功案例：升级并清理 ComfyUI-GGUF 节点后，Qwen-Image-2.1 GGUF 工作流连续两次完成 25 步生成，耗时分别为 49.44 秒和 51.46 秒。不同机器上的路径、模型版本、工作流节点和运行速度可能不同，请根据实际日志调整。

一、先看问题：为什么模型文件在，却报架构错误？

此次机器的关键环境：

项目	实际配置
操作系统	Linux / Ubuntu
显卡	NVIDIA GeForce RTX 4070，显存 11872 MB
系统内存	日志报告 63027 MB
ComfyUI	0.37.4
Python	`/data/comfyui/venv/bin/python`，3.13.15
PyTorch	2.13.0+cu130
主目录	`/data/comfyui`
自定义节点额外搜索目录	`/data/custom_nodes`

工作流使用 Qwen-Image-2.1 GGUF 扩散模型、Qwen3-VL INT8 文本编码器和配套 VAE。最初遇到的关键报错为：

报错堆栈与模型目录树示意终端日志中红高亮 Unexpected architecture type in GGUF file 报错右侧为模型文件目录树

Unexpected architecture type in GGUF file: 'qwen_image21'

这个报错的关键在 architecture type，不是提示词、图片尺寸或采样步数。加载器读取 GGUF 文件后，看到了架构标识 qwen_image21，但当时使用的加载器没有正常接受它。因此本次第一优先级是核对 GGUF 自定义节点的版本与实际加载情况，而不是先重装 CUDA、PyTorch 或整个 ComfyUI。

注意：这是本次报错的排障方向，不代表其他机器出现同样文字时一定只有这一个原因。判断仍应结合自己的完整 traceback、节点目录、模型文件来源及工作流。Qwen-Image-2.1 GGUF 发布页标注了 qwen_image21 架构，并给出了 ComfyUI-GGUF 安装和模型放置方法：https://huggingface.co/abenzerps/Qwen-Image-2.1-Uncensored-GGUF。官方 ComfyUI 的 Qwen-Image-2.1 教程也列出了相应的文本编码器、VAE 与示例工作流：https://docs.comfy.org/tutorials/image/qwen/qwen-image-2-1。

二、操作前先确认：进程、路径、模型

在 Ubuntu + RTX 4070 12GB 环境下，ComfyUI 加载 Qwen-Image-2.1 GGUF 时出现 Unexpected architecture type in GGUF file: 'qwen_image21'，核心原因是 ComfyUI-GGUF 自定义节点版本过旧，未支持 qwen_image21 架构标识。动节点目录之前，先确认进程、路径与模型文件。

这台机器的启动日志显示：

[INFO] Adding extra search path custom_nodes /data/custom_nodes
[INFO] Adding extra search path text_encoders /data/models/text_encoders
[INFO] Adding extra search path vae /data/models/vae
[INFO] Adding extra search path diffusion_models /data/models/unet
[INFO] Adding extra search path diffusion_models /data/models/diffusion_models

因此，本篇命令使用 /data/custom_nodes 操作节点，模型则由 /data/models/... 这组额外搜索路径提供。这不是所有 ComfyUI 安装的默认目录；先看你自己的启动日志，不要把示例路径当作通用路径。

本次工作流中实际使用的文件及设置为：

GGUF 扩散模型：qwen-image-2.1-UC-Q6_K.gguf
文本编码器：qwen3vl_8b_int8_convrot.safetensors
VAE：qwen_image_2.1_vae_bf16.safetensors
CLIP 类型：qwen_image
文本编码节点：TextEncodeQwenImage21

扩散模型使用 GGUF 加载节点；文本编码器是 .safetensors，不要仅因为扩散模型是 GGUF，就把文本编码器也误认为必须使用 GGUF 加载节点。具体以文件格式和工作流节点为准。

动节点目录之前，先停止正在运行的 ComfyUI。如果服务在当前终端前台运行，按一次 Ctrl+C，等它退出并回到 Shell 提示符。本次终端先显示：

[INFO] Stopped server

随后检查端口：

ss -lntp | grep 8188

本次命令无输出，说明当时没有服务监听 8188。如果有输出，不要直接再次启动同端口实例，应先弄清是谁在监听。

本次曾连续按两次 Ctrl+C，第二次在 Python 退出期间出现 KeyboardInterrupt。结合已返回 Shell、端口无监听，这次无需当作模型故障处理；以后按一次并等待即可。

再查看自定义节点目录：

find /data/custom_nodes -maxdepth 1 -mindepth 1 -type d \
  -name '*GGUF*' -printf '%f\n'

如果你不是这套目录布局，请将 /data/custom_nodes 换成启动日志里显示的实际扫描路径。

修复三步流程图备份旧节点克隆新版 ComfyUI-GGUF 旧目录移出扫描路径扫描目录只保留一个版本

三、实际修复：备份旧版、安装新版、排除重复加载

第一步：给旧节点改名备份

确认 ComfyUI 已停止后执行：

cd /data/custom_nodes

STAMP=$(date +%F_%H%M%S)
mv ComfyUI-GGUF "ComfyUI-GGUF_old_${STAMP}"

这一步不会删除旧代码，而是将它留在原目录并加上时间戳，便于回退。但有一个重要限制：改名备份不等于禁用节点。 如果旧目录还在 ComfyUI 扫描的自定义节点目录下，启动时仍可能被加载。这一点在本次第一次重启后确实发生了。

第二步：克隆新版 ComfyUI-GGUF

cd /data/custom_nodes

git clone https://github.com/leejet/ComfyUI-GGUF ComfyUI-GGUF

注意 Shell 命令应使用纯文本 URL；不要将网页的 Markdown 链接形式 [地址](地址) 原样复制进终端。

克隆完成后，不要只凭 git clone 成功就认为问题已解决。先确认加载器文件和架构标识：

test -f /data/custom_nodes/ComfyUI-GGUF/loader.py \
  && echo '新 GGUF loader：OK'

grep -R 'qwen_image21' /data/custom_nodes/ComfyUI-GGUF | head -20

本次得到：

新 GGUF loader：OK
/data/custom_nodes/ComfyUI-GGUF/tools/convert.py:    arch = "qwen_image21"
/data/custom_nodes/ComfyUI-GGUF/loader.py: ... "qwen_image21"}

随后进一步确认 loader.py：

grep -n 'qwen_image21' /data/custom_nodes/ComfyUI-GGUF/loader.py

本次输出：

13:                 "qwen_image", "ideogram4", "krea2", "minimax", "qwen_image21"}

这说明本次拉取的加载器代码包含这个架构名称。但它仍只是静态检查：实际能否执行，必须重启并跑工作流。

第三步：处理“旧版也被加载”的隐患

本次第一次启动后，日志中同时出现：

/data/custom_nodes/ComfyUI-GGUF_old_2026-09-27_114701
/data/custom_nodes/ComfyUI-GGUF

这证实两个目录都进入了 ComfyUI 的自定义节点加载流程。虽然仅凭该段日志不能断言工作流最终调用了哪一份代码，但它会使排障结果不明确。因此再次停止 ComfyUI，并把旧版移出扫描路径。

mkdir -p /data/custom_nodes_backups

mv /data/custom_nodes/ComfyUI-GGUF_old_2026-09-27_114701 \
   /data/custom_nodes_backups/

务必把命令中的 2026-09-27_114701 改成自己机器生成的实际时间戳。 可先用下列命令查看：

find /data/custom_nodes -maxdepth 1 -mindepth 1 -type d \
  -name 'ComfyUI-GGUF_old_*' -printf '%f\n'

移动后再次执行第二章的 find 命令检查扫描目录，本次输出仅有一行 ComfyUI-GGUF，旧版目录已不在扫描范围内。这样既保留了旧版，又能让此次自定义节点搜索目录只剩一个 GGUF 节点版本。不要为图方便直接 rm -rf；至少等新版实际生成成功后再考虑是否清理备份。

两次生成成功日志对比第一轮 full load 49.44 秒第二轮部分加载加 offload 51.46 秒均完成 25/25 步采样

四、重启及实测：怎样才算真正修好？

按此次环境的启动方式执行：

cd /data/comfyui

/data/comfyui/venv/bin/python main.py \
  --listen 127.0.0.1 \
  --port 8188 \
  --enable-manager

本机浏览器打开：

http://127.0.0.1:8188

127.0.0.1 是运行 ComfyUI 的那台机器自身；如果浏览器在另一台电脑，直接访问另一台电脑的 127.0.0.1 不会连到这台 Ubuntu 主机。远程访问方式需另行配置，不是本次修复步骤。

验证 1：启动日志只加载新版节点

在 Import times for custom nodes 一段，本次修复后只看到：

[INFO]    0.0 seconds: /data/custom_nodes/ComfyUI-GGUF

没有再看到 ComfyUI-GGUF_old_...。这说明旧节点已不在此次扫描范围内。

验证 2：工作流文件与节点设置没有选错

刷新浏览器后，打开原 Qwen-Image-2.1 工作流，逐项核对：

项目	本次设置	核对重点
GGUF 扩散模型	`qwen-image-2.1-UC-Q6_K.gguf`	使用 GGUF 专用扩散模型加载节点，不误选其他版本
文本编码器	`qwen3vl_8b_int8_convrot.safetensors`	文件格式为 safetensors，核对下拉框中的准确名称
CLIP 类型	`qwen_image`	它是文本编码器节点选项，不要求等于 GGUF 架构名
VAE	`qwen_image_2.1_vae_bf16.safetensors`	核对所选文件
文本编码节点	`TextEncodeQwenImage21`	核对工作流实际所用节点
测试尺寸和采样	1024×1024；25 steps；CFG 1；`euler`；`simple`	先做一次基础测试，不同时修改多个变量

其中 qwen_image 与 qwen_image21 分别处在不同的配置层面：前者是文本编码器加载类型，后者是 GGUF 文件的架构标识。不要因为这两个字符串不同就随意修改节点类型。模型文件的放置、节点示例可核对前面列出的官方文档与模型发布页。

验证 3：提交任务，观察从接收提示词到执行完成的日志

点击运行后，重点看新出现的日志，而不是只看启动成功。本次第一轮依次出现：

[INFO] got prompt
[INFO] Requested to load QwenImage21TEModel_
[INFO] gguf qtypes: BF16 (68), Q6_K (229)
[INFO] Requested to load QwenImage21
[INFO] loaded completely; 5989.67 MB usable, 5732.32 MB loaded, full load: True
100%|...| 25/25 [00:42<00:00, 1.70s/it]
[INFO] Prompt executed in 49.44 seconds

第二轮得到：

[INFO] got prompt
[INFO] Requested to load QwenImage21
[INFO] loaded partially; 5423.17 MB usable, 5377.95 MB loaded,
       354.38 MB offloaded, 39.38 MB buffer reserved
100%|...| 25/25 [00:45<00:00, 1.83s/it]
[INFO] Prompt executed in 51.46 seconds

这些日志逐层说明：工作流收到任务、文本编码器进入加载流程、GGUF 量化类型被解析、QwenImage21 扩散模型进入加载流程、25 步采样完成，最后任务执行结束。两次运行均未再出现先前的 Unexpected architecture type in GGUF file: 'qwen_image21'。RTX 4070 12GB 显存（5732 MB 全量加载 / 5378 MB 部分加载 + 354 MB offload）足以承载 Q6_K 量化版本，验证了两轮测试在 12GB 显存下的可行度。

第二次出现 loaded partially、354.38 MB offloaded，是在该次内存调度下部分权重被卸载的记录，本身不是新的报错；也不能单凭这几行就断言该设置在所有场景下速度最佳。

日志里还出现了 model_type FLUX 与 Requested to load WanVAE 等内部名称。不要只依据一个内部显示名称就认定选错了模型；先核对工作流里选中的真实文件、任务是否走完以及输出图。更重要的是：Prompt executed 证明任务完成，不保证图像内容一定符合提示词。 修复记录应额外打开输出图，排除空白图、噪点图或明显跑题的图。

五、故障复盘与以后可复用的检查表

本次最容易忽视的地方不是克隆命令，而是“备份目录仍被扫描”：

最初的报错指向加载器不接受 qwen_image21 架构。
新克隆版本的 loader.py 已包含 qwen_image21。
第一次启动发现新、旧 GGUF 节点目录同时被加载。
把旧目录移出自定义节点扫描路径后，重启日志只剩新版。
两次实际工作流均完成 25 步采样和整个任务。

面对相似报错，可以依序核对：

[ ] 是否记录了第一条真正的报错，而不是只看最后一行？
[ ] GGUF 文件声明的架构，当前加载器是否识别？
[ ] 实际启动时加载的是哪个节点目录？
[ ] 是否有改名后仍被扫描的旧节点？
[ ] 重启后是否只剩一个需要使用的 GGUF 节点版本？
[ ] 扩散模型、文本编码器、VAE 是否各选了正确文件？
[ ] 任务是否从 got prompt 跑到 25/25 和 Prompt executed？
[ ] 输出图片本身是否符合预期？

**本次结论：**在这台 RTX 4070 12GB 的机器上，不需要通过重装 Python、PyTorch、CUDA 或全部模型文件解决这个具体错误。升级 GGUF 加载器、排除旧节点重复加载，然后用完整生成日志验证，成功消除了 qwen_image21 架构报错。旧版目录仍保存在 /data/custom_nodes_backups/，以备需要时回退。

参考资料：

ComfyUI 官方 Qwen-Image-2.1 教程：https://docs.comfy.org/tutorials/image/qwen/qwen-image-2-1
本次所用 GGUF 模型的发布页与使用说明：https://huggingface.co/abenzerps/Qwen-Image-2.1-Uncensored-GGUF
ComfyUI-GGUF 项目：https://github.com/leejet/ComfyUI-GGUF