GGUF File Info 🔍

GGUF filenames lie. A file called flux1-dev-Q4_K.gguf is usually mostly Q4_K - but real quantized files are mixed precision, with a handful of F16/F32 layers kept full precision where it matters. Sometimes the file isn't even the architecture the name claims, or it's a text encoder that someone's labeled like a diffusion model. And once you're deep enough into the ecosystem to be grabbing GGUF versions of niche models from random HuggingFace repos, "trust me, it's Q4" stops being good enough.

That's the job of this node: it's a read-only inspector that opens a .gguf file and tells you what's actually inside - architecture metadata, name, quantization version, and a genuine per-tensor quant-type breakdown - without ever loading the thing into a pipeline. Run it first on any downloaded file before you feed it to a loader. It's the sanity gate the other five GGUF nodes in OmniNodes assume you used.

How it works

It uses the gguf package's GGUFReader to parse the file's header: the typed key-value metadata (which stores things like general.architecture and general.name) plus the tensor index. It counts how many tensors use each GGML quant type, totals up the tensor data bytes and element count, and reports the dominant type. Crucially, it never dequantizes or reads tensor data - it's header-and-index inspection only. That makes it instant even on multi-gigabyte files, and it works on files no loader in the pack supports yet, because it doesn't have to understand them, just read their index.

It's also an accidental corruption check: a truncated or mangled download often won't parse as valid GGUF at all, and the node returns a clear parse error naming the file instead of letting you discover the problem three nodes downstream.

Inputs and outputs

Just two inputs, and the second is optional:

• gguf_name - dropdown of .gguf files across the model folders the pack's GGUF nodes share (diffusion_models, unet, unet_gguf, clip, clip_gguf, vae, checkpoints). If nothing shows up, use path_override for an absolute path.

Outputs are both strings: summary is the human-readable readout (architecture, name, quant version, file size, dominant quant type, and the full per-type breakdown), and metadata_json is the same information as structured JSON - the quant_type_counts and kv_metadata fields are handy if you want to compare two files programmatically or log what a workflow consumed.

Installing

This is one of the six GGUF nodes in OmniNodes, TensorVizion's large all-purpose pack. Install the pack once, then its one GGUF dependency:

cd ComfyUI/custom_nodes/
git clone https://github.com/TensorVizion/OmniNodes
cd OmniNodes && pip install -r requirements.txt   # adds gguf

Restart ComfyUI. Manager users can search "OmniNodes" instead - but keep the pip install gguf step; it isn't bundled with ComfyUI, and without it this node returns a plain "install gguf" error message rather than failing silently. You'll find it under TensorVizion/GGUF.

What to look for in the output

Three things worth actually checking. First, the dominant quant type vs. the filename - a mismatch means you're about to build a workflow around a file that isn't what its name promised. Second, the architecture line: if you expected a UNet/DiT and it says t5 or llama, you've grabbed a text encoder or an LLM, not a diffusion model. Third, the breakdown itself - a "Q8" file that shows most tensors at Q8 but a tail of F32 is normal and fine; what you're looking for is anything bizarre, like a file where the dominant type contradicts the name entirely. Thirty seconds of inspection here saves you a ten-minute confusing load failure later.