ComfyUI Quant Load Errors: GGUF, fp8, NVFP4, INT8

Before you change anything, search your ComfyUI console for the line Found quantization metadata version 1. ComfyUI logs it the moment it sees a quantised tensor in a checkpoint. If the line is absent, ComfyUI never recognised the file as quantised — it loaded the packed 4-bit or 8-bit tensors as if they were ordinary weights, and the run will die later inside a matmul rather than at load time with a useful message. That single line splits every problem on this page into two: "the file was not recognised" (wrong metadata, wrong loader node, wrong download) versus "it was recognised and the kernels are missing" (wrong package, wrong PyTorch build, wrong GPU).

Quantised checkpoints broke differently in 2026 than they did in 2024. It used to be one question — GGUF or fp8. Now a single model ships as bf16, fp8_scaled, GGUF Q4 and Q8, NVFP4, INT8 ConvRot and an AWQ text encoder, each needing a different loader, a different package and in some cases a different GPU generation. Half the "corrupt file" reports in the tracker are none of those things; they are a format the installed stack cannot execute.

Everything in the tables below was read from source rather than inferred: ComfyUI's comfy/quant_ops.py and comfy/utils.py on master, ComfyUI's requirements.txt, and the READMEs of the two loader packs people actually install. Where a claim is only a bug report, it is labelled as one.

What you will not find here: quality-loss or speed percentages per format. Producing those honestly needs a controlled bench across five GPU generations, we do not have one, and inventing them is exactly the thing that makes pages like this untrustworthy. This page answers "will it load and run", not "which is prettiest".

Which Quantisation Formats Does ComfyUI Natively Recognise?

Seven, and they are enumerated in one dictionary. QUANT_ALGOS in comfy/quant_ops.py is the definitive list of formats ComfyUI core can execute without a custom node. Anything not in this table needs a third-party loader.

Four things in that table are worth stopping on, because each one explains a different class of bug report.

mxfp8 is conditional. It is only added to QUANT_ALGOS when a flag named _CK_MXFP8_AVAILABLE is true — that is, when the installed comfy-kitchen build supports it. On an older comfy-kitchen the key simply is not registered, so an MXFP8 file is not "broken", it is invisible. The matching log line is blunt: comfy_kitchen does not support MXFP8, please update comfy_kitchen.

"INT8 ConvRot" is not 8-bit. The format string is convrot_w4a4 — four-bit weights and four-bit activations, packed into torch.int8 containers. The int8 in the filename is the storage type, not the precision. People compare it against GGUF Q8 expecting a like-for-like trade and get a surprise; it is a far more aggressive quantisation than the name suggests.

NVFP4 is the only core format with a real block structure. Group size 16, and it carries four scale tensors rather than two. NVIDIA's format pairs 4-bit values with an 8-bit block scale; take ComfyUI's group size of 16 and the storage arithmetic falls out: 4 + 8/16 = 4.5 bits per weight, before the two per-tensor scales. That block structure is also why it is the format most likely to be shipped without the metadata that describes it — there is simply more to describe.

asym_w4a8_int8 exists and almost nobody talks about it. Asymmetric 4-bit weights with 8-bit activations. If you see it in a filename, it goes through the same comfy-kitchen path as the other int8-container formats.

For the concepts underneath all of this — what a block scale is, why 4-bit weights need one, what "asymmetric" means — start with our quantisation explainer.

Which Loader Node and Package Does Each Format Need?

This is the table the page exists for. Match the file you downloaded to a row, then check you have both the node and the package. Missing either produces a different symptom, listed in the last column.

The single most important row is the fp8_scaled one, because it is the row people get wrong in the opposite direction: do not set weight_dtype to fp8_e4m3fn when loading a file that is already fp8_scaled. The core UNETLoader node exposes exactly four options — default, fp8_e4m3fn, fp8_e4m3fn_fast and fp8_e5m2 — and the three non-default ones are a cast applied to whatever you loaded, meant for squeezing a bf16 file into less VRAM. A pre-quantised scaled-fp8 checkpoint already carries its scales; leave the dropdown on default and let the metadata drive it.

Note also what is not in ComfyUI's requirements.txt: gguf. comfy-kitchen==0.2.31 and safetensors>=0.4.2 are there; the GGUF library is not, because GGUF diffusion support is not core. That is the whole reason UnetLoaderGGUF shows up in the red "node types were not found" dialog — the pack was never installed, or it was installed and its pip install --upgrade gguf step ran against a different Python than the one ComfyUI uses. Our guide to missing node types in ComfyUI covers the wrong-Python case in detail, because it is by far the most common way a "correctly installed" custom pack stays broken.

Which GPUs Can Actually Execute Each Format?

Format support is architecture-gated, and ComfyUI mostly does not check before it tries. That is the uncomfortable part. There is no compute-capability guard in quant_ops.py for NVFP4, ConvRot or the int8 paths on NVIDIA — the gate lives inside the compiled comfy-kitchen kernels, so an unsupported card gives you a runtime failure rather than a clean "your GPU cannot do this".

The ROCm rule is written down, and it is stricter than people assume. _rocm_kitchen_arch_supported() in quant_ops.py carries this docstring verbatim:

comfy-kitchen's INT8 Triton kernels compile tl.dot to matrix-core instructions.
RDNA3/3.5/4 (gfx11xx/gfx12xx) have WMMA and CDNA (gfx9xx) has MFMA; RDNA1/RDNA2
(gfx10xx) have neither, so the INT8 path hangs the GPU there.

The function returns true for any gfx11/gfx12 prefix and for the explicit CDNA list gfx908, gfx90a, gfx940, gfx941, gfx942, gfx950. Everything else returns false. Read that middle sentence again: on RDNA1 and RDNA2 the INT8 path does not error, it hangs the GPU. If you are on an RX 5000 or RX 6000 series card and ComfyUI locks the machine solid the moment sampling starts, that is a documented outcome, not a mystery.

And the RDNA3 answer is not simply "yes". In current master the automatic ROCm enable is commented out — the branch reads elif args.enable_triton_backend: with the _rocm_kitchen_arch_supported() half of the condition disabled. So on a supported AMD card you get the accelerated INT8 path only if you launch with --enable-triton-backend, and only with Triton 3.7 or newer; older Triton logs Triton %s is too old for the ROCm INT8 path (needs >= 3.7); comfy-kitchen triton backend disabled. Without the flag you are on the eager fallback, which works but is not what the format was built for.

If you are choosing a card rather than debugging one, the VRAM side of the question is in our FLUX VRAM requirements by GPU table, and the low-VRAM survival options are in running FLUX on a low-VRAM GPU.

What Does Each Load Error Actually Mean?

Real strings only. Anything sourced from a bug report rather than from code is labelled.

Two rows there are load-order problems dressed as format problems. If your traceback is about devices rather than dtypes — tensors on cuda:0 and cpu in the same op — that is a different failure entirely and it is covered in ComfyUI device mismatch errors.

Why Does a Bad Quant File Crash Instead of Erroring?

Because ComfyUI's quantisation detection is designed to return None rather than raise. This is the mechanism behind the most-reported new-model failure of 2026, and once you have seen it in the source it stops being mysterious.

The detection function is four lines:

def detect_layer_quantization(state_dict, prefix):
    for k in state_dict:
        if k.startswith(prefix) and k.endswith(".comfy_quant"):
            logging.info("Found quantization metadata version 1")
            return {"mixed_ops": True}
    return None

No .comfy_quant keys, no exception — just None. And .comfy_quant keys do not exist in the file you downloaded; they are manufactured at load time by convert_old_quants(), which reads the _quantization_metadata entry out of the safetensors header, walks its layers dictionary, and writes one .comfy_quant tensor per quantised layer:

state_dict["{}.comfy_quant".format(k)] = torch.tensor(
    list(json.dumps(v).encode('utf-8')), dtype=torch.uint8
)

So the chain is: header metadata → per-layer JSON → UTF-8 bytes → a uint8 tensor → detection. Break the first link and every later one silently no-ops. A publisher who exports NVFP4 weights but forgets to write _quantization_metadata produces a file that loads perfectly, reports no error, and then hands packed uint8 tensors to F.linear, which is where the traceback lands. That is exactly the shape of the reported LTX-2.5 nvfp4 failure: loads silently as unquantised, crashes in F.linear.

The utf-32-be report is the same chain failing one link later. Because the JSON is round-tripped through raw bytes, an empty comfy_quant tensor hands Python's json module a zero- or four-byte input — and CPython's JSON encoding sniffer guesses utf-32-be for a byte sequence that starts with null bytes. The UnicodeDecodeError naming a codec nobody chose is a downstream symptom of empty tensors, not a text-encoding bug in your install. There is no client-side fix; the file needs rebuilding.

Practical consequence: treat Found quantization metadata version 1 as a required pre-flight check for every new quantised checkpoint. Absent line plus a working-looking load means you are running a broken file, no matter how confident the model card was. There is an older legacy path too — if the file has no _quantization_metadata but does contain a scaled_fp8 key, convert_old_quants() synthesises the layer table from that instead, which is why fp8_scaled files from before the metadata format still work.

Why Did INT8 or fp8 Stop Working After an Update?

Three moving parts, and they version independently. A ComfyUI update that "broke quantisation" almost always means one of them slipped out of alignment, not that the format changed.

1. comfy-kitchen. ComfyUI pins it exactly — comfy-kitchen==0.2.31 in requirements.txt, not a range. Pull a new ComfyUI, skip pip install -r requirements.txt, and you are running new ComfyUI against old kernels. That is the "Int8 clip stopped working in latest nightly" class of report. Re-run the requirements install against ComfyUI's own Python, then confirm the absence of the Failed to import comfy_kitchen line.
2. PyTorch's CUDA build. comfy-kitchen disables its entire CUDA backend when torch.version.cuda parses below 13. A routine pip install torch that pulls a cu12x wheel silently demotes every fp8 and fp4 layer. The warning is loud when it happens — "If you are on nvidia 20 series and above it is required that you update your pytorch to cu130 or higher" — but it prints once at startup and scrolls away.
3. The custom packs. ComfyUI-GGUF and ComfyUI-nunchaku each track ComfyUI's internals; an updated ComfyUI with a stale pack fails in whichever direction the internals moved.

The diagnostic is the startup log, not the workflow. Restart ComfyUI, capture the first fifty lines, and check three things in order: did comfy-kitchen import, was a cu130 warning printed, and did the custom packs load. If all three are clean and it still fails, the problem is the file. Broader startup and import failures — the ones where a pack refuses to load at all — are a separate diagnosis; the complete ComfyUI guide covers the install layout that causes most of them.

How Do I Tell a Format Problem From a Corrupt Download?

Check the file before you debug the software. Three checks, in ascending order of effort, and they rule out most of what gets misfiled as a quantisation bug.

# 1. Size. A Git LFS pointer is a three-line text file that looks like a model.
ls -l model.safetensors

# 2. Header. safetensors stores an 8-byte little-endian header length,
#    then that many bytes of JSON. If this prints garbage, the file is bad.
head -c 8 model.safetensors | xxd

# 3. Metadata. This is the check that actually answers the quant question:
#    does the file carry _quantization_metadata at all?
from safetensors import safe_open
with safe_open("model.safetensors", framework="pt") as f:
    md = f.metadata() or {}
    print("has _quantization_metadata:", "_quantization_metadata" in md)
    print(sorted(md.keys()))

If check 3 prints False on a file whose name says nvfp4 or int8, stop. You have the malformed-export case from the previous section, and nothing you install locally will fix it. Report it to the publisher, and use a GGUF build of the same model in the meantime — GGUF carries its quantisation description inside the file format itself rather than in a sidecar metadata field, which is precisely why it is the format that keeps working when everything else is churning.

Error while deserializing header: HeaderTooLarge at check 2 means the download is truncated, full stop. It is not a quantisation error and no loader node will rescue it.

Which Format Should I Actually Pick?

Pick on constraints, not on quality claims — and this page deliberately does not rank them. What it can tell you is which choices are available to you:

• You want the widest compatibility and the fewest moving parts: GGUF. One extra custom pack, one pip package, no architecture gate, no metadata sidecar. It is the format least likely to be broken by a ComfyUI update because it depends on the least.
• You are on Blackwell and want the newest fast paths: NVFP4, with a torch built for CUDA 13. You get the format the vendors are optimising for and you accept being on the leading edge of the bug reports quoted throughout this page.
• You are on Ada, Ampere or Turing: fp8_scaled if the model ships one, otherwise GGUF. NVFP4 is not available to you regardless of VRAM.
• You are on an AMD card: GGUF unless you are on RDNA3 or newer and willing to pass --enable-triton-backend with Triton 3.7+. On RDNA1/RDNA2 avoid the int8 formats entirely — the docstring says the path hangs the GPU.
• You just need the thing to fit: the constraint is usually VRAM, not format. Size it first with our quantisation calculator and the FLUX VRAM table.

For a worked example of a modern model that ships several of these builds side by side, our Z-Image Turbo ComfyUI guide walks through the loader wiring for each.

What This Page Does Not Cover

• No quality or speed numbers. Stated at the top and worth repeating, because every other page on this topic has them and most cannot say where they came from. A format-by-format quality ranking needs a fixed seed, a fixed prompt set and one bench per architecture. We do not have that bench.
• comfy-kitchen's internals are closed to this analysis. We read where ComfyUI calls it and what it does when the import fails. The per-architecture kernel matrix inside the package is not something we can enumerate from ComfyUI's source, which is exactly why the NVIDIA rows above cite NVIDIA rather than pretending to a compute-capability table.
• Version drift is guaranteed. QUANT_ALGOS gained three entries in a year. The pinned comfy-kitchen version will move. Check comfy/quant_ops.py in your own install before trusting any table here, including this one.
• The bug reports are open and will churn. The NVFP4-metadata, MiniMax H3 AWQ text-encoder, GGUF pinned-memory and INT8 nightly reports are quoted as reports. Search the tracker before you rebuild a workflow around a workaround.

FAQ

How do I know if ComfyUI recognised my checkpoint as quantised?

Search the console for Found quantization metadata version 1. ComfyUI logs it from detect_layer_quantization() the first time it sees a .comfy_quant tensor. No line means no recognition, and no recognition means the packed weights are being treated as ordinary weights — which typically surfaces as a crash inside a linear layer much later, with a traceback that says nothing about quantisation.

Why does my NVFP4 file load fine and then crash during sampling?

Almost certainly a missing _quantization_metadata entry in the safetensors header. ComfyUI builds its per-layer quant table from that header field; when it is absent, detection returns None silently and the 4-bit packed tensors reach F.linear as raw uint8. Verify with the safe_open snippet above — if the key is absent, the file is malformed and no local fix exists.

Do I need to change weight_dtype when loading an fp8_scaled model?

No. Leave it on default. The core UNETLoader offers default, fp8_e4m3fn, fp8_e4m3fn_fast and fp8_e5m2; the last three are casts applied to whatever you load, intended for shrinking a bf16 file. A scaled-fp8 checkpoint already carries its own scales, and overriding the dtype fights the metadata rather than helping it.

Does INT8 work on an AMD RDNA3 card?

The architecture qualifies — _rocm_kitchen_arch_supported() returns true for any gfx11 or gfx12 device — but in current master the automatic ROCm enable is commented out, so you must launch with --enable-triton-backend and have Triton 3.7 or newer. On RDNA1/RDNA2 (gfx10xx) do not try: the source docstring states those cards lack the matrix-core instructions and the INT8 path hangs the GPU.

Why do I get a UnicodeDecodeError mentioning utf-32-be?

Because the per-layer quant config is round-tripped through raw bytes in a uint8 tensor, and an empty tensor hands Python's json module a byte string it cannot identify. CPython's encoding sniffer guesses utf-32-be from leading null bytes, so the codec named in the error is a red herring. It was reported against a MiniMax H3 nvfp4-awq text encoder with empty comfy_quant tensors. The file needs rebuilding.

What is the difference between GGUF Q8 and INT8 ConvRot?

Very nearly everything. GGUF Q8_0 is a block-quantised weight format that a custom loader dequantises to your compute dtype before the matmul, so it runs on any card. convrot_w4a4 is a ComfyUI-native format executed by comfy-kitchen kernels, and despite the "int8" in most filenames it is 4-bit weights with 4-bit activations stored in torch.int8 containers. Different precision, different code path, different hardware requirements.

My GGUF node is missing after installing ComfyUI-GGUF. Why?

Nearly always the wrong Python. gguf is not in ComfyUI's requirements.txt — it is a dependency of the custom pack — so pip install --upgrade gguf has to run against the interpreter ComfyUI itself uses, which on a portable Windows build is not the one on your PATH. The frontend dialog reads When loading the graph, the following node types were not found: UnetLoaderGGUF. Our missing node types guide walks through finding the right interpreter.

Sources

• ComfyUI — comfy/quant_ops.py (QUANT_ALGOS format table, comfy-kitchen import and failure message, cu130 warning, _rocm_kitchen_arch_supported() and its docstring, Triton 3.7 requirement)
• ComfyUI — comfy/utils.py (detect_layer_quantization, convert_old_quants, _quantization_metadata and .comfy_quant)
• ComfyUI — requirements.txt (comfy-kitchen==0.2.31, safetensors>=0.4.2, and the absence of gguf)
• ComfyUI — nodes.py (the four UNETLoader weight_dtype options)
• city96/ComfyUI-GGUF (node class names, gguf>=0.13.0, and the three error strings quoted above)
• nunchaku-tech/nunchaku and ComfyUI-nunchaku (SVDQuant INT4 on 20-series, NVFP4 on RTX 5090, NunchakuFluxDiTLoader)
• NVIDIA TensorRT Model Optimizer (nvidia-modelopt, the toolkit that produces NVFP4 checkpoints, and NVFP4's association with Blackwell RTX 50-series)
• Bug reports quoted as reports, findable via the nvfp4 and gguf searches in the Comfy-Org tracker