知仓学习社知仓学习社
ComfyUI-GGUF：加载量化模型报 GGML_ASSERT 断言失败 / 全站资源搜索
搜索 更新 2026-10-02
报错 107 热门自定义节点/工作流专有报错 含未核实说明

ComfyUI-GGUF：加载量化模型报 GGML_ASSERT 断言失败

报错原文（原样） 
GGML_ASSERT(info->ne[i] > 0) failed
检索关键词 GGML_ASSERT、GGML_ASSERT(info->ne[i] > 0) failed、ComfyUI-GGUF、UnetLoaderGGUF、dequantize、GGMLQuantizationType、量化模型
先看这一句 用 ComfyUI-GGUF 的 GGUF 加载器载入量化模型时，进程直接崩溃/抛出断言失败，错误里带 GGML_ASSERT；有时是加载阶段失败，有时是跑到一半才崩。
适用版本 与 ComfyUI-GGUF 节点版本强相关：新量化类型需要新版本节点；旧版 GGUF 节点对新模型会失败 · 核实日期 2026-09-26 · 状态 可能已过期，正在复核
适用环境：Windows 便携版、秋叶/绘世整合包、ComfyUI Desktop、Linux + 云 GPU、Docker/服务器

现象与触发场景

常见触发场景：

  • 下载的 GGUF 文件本身损坏或下载不完整
  • 该量化类型不被当前 ComfyUI-GGUF 版本支持（新量化类型早于节点支持）
  • 把不兼容的量化文件与合并/转换流程混用（如把两个模型合并后再量化）
  • 把 GGUF 文本编码器与 fp8/原生 safetensors 主模型随意混搭

根因

  • GGML 底层在做张量维度校验，量化文件头部元数据与实际张量尺寸不一致（文件损坏、转换中断、来源本身有问题）时会命中断言并直接终止
  • 较新的量化类型（社区讨论中出现过 np.uint32(39) is not a valid GGMLQuantizationType 这类报错）需要更新的 GGUF 节点版本支持，旧版本解析不了该类型
  • 某些模型（社区 issue 记录过 Wan 2.2 的合并场景）经合并后再量化会产出非法张量，属于量化流程本身的问题而非 ComfyUI 的问题

解决步骤

已按「最可能有效」排序。请从上往下做，每做完一步用「验证」确认，不要一次改五处。

  1. 先更新 ComfyUI-GGUF 到最新版，排除节点太旧
    很多 GGML_ASSERT 与「不认识的量化类型」是因为节点版本落后于模型文件。用 Manager 更新 ComfyUI-GGUF，或进目录 git pull；更新后完全重启 ComfyUI 再试。这一步成本最低，应先做。
    cd ComfyUI\custom_nodes\ComfyUI-GGUF
    git pull
  2. 重新下载/校验 GGUF 文件，排除文件损坏
    GGML_ASSERT 是底层断言，最常见的物理原因就是文件不完整。核对文件体积与发布页标注是否一致，必要时用发布方给的哈希校验；从原始发布页（Hugging Face 仓库）重新下载，避免用第三方转存或断点续传中断得到的文件。
  3. 确认该量化类型是否被支持，必要时换量化档位
    若报错涉及未知的 GGMLQuantizationType，说明该量化档位当前节点/ComfyUI 版本不支持。改用更常规的量化档位（如社区常用的 Q4_K_M / Q5_K_M / Q8_0），或者改用原生 safetensors/fp8 版本模型先跑通。
  4. 不要在 GGUF 与 fp8 之间混搭文本编码器/主模型
    GGUF 主模型配 GGUF 文本编码器、fp8 主模型配官方 fp8 文本编码器，是最稳的组合。跨类混搭（例如 GGUF unet + 只给 fp8 clip）常表现为加载阶段报错或输出异常，排障时应先换成成套的模型组合再定位。
  5. 把 dequantize 脚本用于离线排查
    ComfyUI-GGUF 仓库自带 tools 下的量化/反量化脚本（如 dequant.py）。对可疑文件做一次反量化，能快速判断是文件本身非法还是节点解析问题——脚本阶段就失败基本可确定是文件问题。

验证是否修好

重新下载并用新版本 GGUF 节点加载后，能正常完成一次出图且命令行不再出现 GGML_ASSERT。

补充说明

error_text 取自 city96/ComfyUI-GGUF issue #345 标题原文（标题含 'is back!' 字样，此处仅取断言语句本身；完整版见 sources）。另有 issue #327 标题 'Llama cpp quantize failed at GGML Assert'、#351 标题 'Wan 2.2 merge fails quantisation.' 佐证量化流程本身也可能是根因。dequant.py 的确切参数用法未在本次搜索结果中逐字确认，标注 [未核实]。

来源

按可信度排列：官方 issue / 官方文档 > 节点仓库 issue > 社区帖 > 中文社区文章。 链接以纯文本给出（本站不做站外跳转），需要核对时请自行复制到浏览器打开。
  1. [109] （节点仓库 issue）　ComfyUI-GGUF/tools/llama.cpp/ggml/src/ggml.c:22112: GGML_ASSERT(info->　https://github.com/city96/ComfyUI-GGUF/issues/345
  2. [243] （节点仓库 issue）　Llama cpp quantize failed at GGML Assert　https://github.com/city96/ComfyUI-GGUF/issues/327
  3. [244] （节点仓库 issue）　Wan 2.2 merge fails quantisation.　https://github.com/city96/ComfyUI-GGUF/issues/351
  4. [245] （节点仓库 issue）　leejet/ComfyUI-GGUF: GGUF Quantization support for native ComfyUI mode　https://github.com/leejet/ComfyUI-GGUF
本条的可靠性边界 下面这些位置带 [未核实] 标记，是采集时没找到一手来源的部分，请自行验证：
  • 补充说明

本条报错提到的节点仓库

下面这些节点仓库的名字出现在本条报错的正文里。这里只说「名字出现过」，没有断定问题就是它引起的； 点进去可以看这个包的用途、适配模型与下载量。

city96/ComfyUI-GGUF 节点库

这条报错要用到的东西

按本条报错所属的类别（热门自定义节点/工作流专有报错）列出站内相关的下载包与板块入口。 它们不是「必须下载才能修好」，而是这一类问题里最常要动到的东西；具体怎么做，以上面的解决步骤为准。

常用节点速查包常用节点参数小抄 / 常见连法示意图 待挂载
节点库找到对应节点仓库，看它的适配模型 板块 工作流看官方模板里这条工作流本来是怎么连的 板块

同一类别的其他条目

【100】打开别人的工作流，节点全变红，提示节点缺少 class_type 属性 有来源 【101】ComfyUI-Manager 连不上 Comfy Registry，刷新缓存失败 含未核实 【102】ComfyUI-Impact-Pack 导入失败：No module named 'ultralytics'（缺少检测模型依赖） 有来源 【103】comfyui_controlnet_aux 导入失败：No module named 'timm' 有来源 【104】WanVideoWrapper：No module named 'sageattention'（SageAttention 未安装或装错环境） 含未核实
这个解法对你有效吗 记录只存在你自己的浏览器里，不需要注册账号。

返回报错库