ModelQuant

The same "purely experimental, no speed or storage benefit" disclaimer from this pack's README applies to ModelQuant as it does to its VAE and CLIP siblings - this isn't a way to shrink a checkpoint or speed up sampling, and if that's what you're after, GGUF conversion or an fp8 checkpoint is the real tool. What makes ModelQuant more interesting than a single bits knob is its shape: instead of one global precision, it splits the diffusion model along the same lines the MBW nodes use for merging - input blocks, middle blocks, output blocks - and lets you set a different bit depth for each. That's a genuinely useful structure for probing which part of a UNet tolerates precision loss worse: crush the middle down to 2 bits while leaving input and output at 8, and see whether the bottleneck is more or less fragile than the extremities.

Inputs and output

• model (required, MODEL) - the diffusion model to degrade.
• in_bits, mid_bits, out_bits (each required, 1–8, default 8) - independent precision for the input blocks, the middle block, and the output blocks respectively.

Output is a MODEL - wires straight into a KSampler exactly like the unmodified model would.

That in/mid/out split isn't a random API choice - it's the same three-region vocabulary this pack's MBW nodes use to talk about a UNet, just applied to precision instead of merge weight. If you've already used SD1 MBW Layers or SDXL MBW Layers to figure out that a particular region carries most of a trait you care about, ModelQuant lets you ask a related but different question about that same region: not "how much of model B's version of this block do I want," but "how much numeric precision does this specific region actually need before it starts costing quality." The two nodes are answering different questions with the same anatomy.

Installing it

ComfyUI Manager: search TechNodes, install, restart. Or by hand:

cd ComfyUI/custom_nodes
git clone https://github.com/TechnoByteJS/ComfyUI-TechNodes --depth 1

No model downloads, no extra dependencies to fight with.

Where people get burned

The recurring one across this whole quantization trio: expecting a VRAM or speed win that isn't there. This is an in-memory precision cut for the duration of one run - nothing gets written to disk, nothing gets faster. If you push all three fields down to 1–2 bits at once, expect the model to produce mush; that's the expected floor for a UNet this size holding this much information, not a crash to debug. And because the three fields degrade independently, a broken-looking image with in_bits/out_bits still at 8 and only mid_bits crushed tells you something real about where the model's information actually lives - that's the one legitimately interesting thing to do with this node, even though the pack's own author is upfront that it isn't a practical optimization.