Nodes/Comfy-WaveSpeed/🚀Quantize Model
ComfyUI Node

🚀Quantize Model

Shrink an already-loaded model without reloading it

By chengzeyi·Created 2 years ago·Updated 5 days ago· 1,230
🚀Quantize Model
  • model
  • MODEL
â—„object_to_patchdiffusion_modelâ–º
◄quant_type▾►
â—„filter_fnfnmatch_matches_fqnâ–º
â—„filter_fn_kwargs{"pattern": ["*"]}â–º
◄kwargs—►

"🚀Quantize Model" (class VelocatorQuantizeModel) is the odd one out in the WaveSpeed velocator family. The other 🚀 nodes quantize while loading; this one takes a model you've already loaded and quantizes it in place, then hands it back. Same goal - smaller weights, smaller VRAM footprint - but it slots into your graph after a loader instead of replacing it. Feed it the output of any Load Diffusion Model (or Load Diffusion Model+), tell it a quant_type, and the model comes out the other side compressed.

Why would you want that, when the pack also ships load-and-quantize nodes? Because this one is model-agnostic. It doesn't care which loader produced the model, whether it's a checkpoint, a diffusers-style folder, or a conversion from another pack. It's the "retrofit" option: keep your existing graph, slip one node in, shrink the model.

How it works

On execute it unloads everything else from VRAM, force-loads the target model fully to the GPU, and runs xelerate's quantize over the diffusion model's weights. The result is patched back into the model's diffusion_model object (or whatever object_to_patch points at) and returned as a new MODEL. The filter_fn mechanism is the power move here: by default it quantizes everything matching ["*"], but you can narrow the pattern to quantize only specific layer names and leave critical layers in full precision.

Inputs that matter

  • model - an already-loaded model. The output is a MODEL for your sampler.
  • object_to_patch - which sub-object to quantize; diffusion_model by default, the standard target.
  • quant_type - the scheme menu, same as the other velocator nodes: int8_dynamic, the e4m3_* family, int8_weightonly, e4m3_weightonly, and the 4-bit tier (nf4_weightonly, af4_weightonly, int4_weightonly).
  • filter_fn / filter_fn_kwargs - fnmatch_matches_fqn with pattern ["*"] by default; narrow the pattern to quantize selectively.
  • kwargs - pass-through options for xelerate's quantizer.

Install - and the honest warning

The pack installs the usual way:

cd ComfyUI/custom_nodes
git clone https://github.com/chengzeyi/Comfy-WaveSpeed.git

And the node hard-requires xelerate, same as every velocator node - without it you hit assert HAS_VELOCATOR, "velocator is not installed" immediately. The pack doesn't install it (its pyproject.toml has zero dependencies) and the README doesn't document these nodes at all.

Now the part I want to be straight with you about. Looking at the shipped code, this is the roughest node in the velocator set. Its handler function references a quantize parameter that the node's own input schema never exposes - a classic "experimental code that got shipped" inconsistency. It may work in your version, it may not, and there's essentially no community coverage of these nodes to tell you which. If you hit a weird error here, it's not your workflow. That's the state of this corner of the pack.

Where people get burned

  • VRAM spike on load. This node force-loads the full model to the GPU before quantizing - the exact opposite sequencing of the load-and-quantize nodes, which shrink on CPU first. If you can't fit the model unquantized, this node may OOM where Load & Quantize Diffusion Model wouldn't.
  • Quality vs. VRAM, again. The aggressive 4-bit weight-only schemes are where the real savings are, but they carry the usual dequantization overhead and visible quality cost that the KB's quantization writeup lays out for the whole GGUF-style ladder.
  • Scope. If you're already at the point of quantizing, ask whether you want the retrofit node or the load-time one. For tight VRAM the load-and-quantize path is usually the safer choice; this node shines when your graph is fixed and you just want to compress a model that's already there.

Use it with the same mindset as the rest of the velocator family: it's a promising, barely-documented experiment, not a battle-tested daily driver. Know what you're signing up for.

Categorywavespeed/velocator

Inputs (6)

NameTypeDefaultDescription
modelMODEL—
object_to_patchSTRINGdiffusion_model—
quant_typeCOMBO10 options: int8_dynamic, e4m3_e4m3_dynamic, e4m3_e4m3_dynamic_per_tensor, int8_weightonly, e4m3_weightonly, e4m3_e4m3_weightonly, +4
filter_fnSTRINGfnmatch_matches_fqn—
filter_fn_kwargsSTRING{"pattern": ["*"]}—
kwargsSTRING—

Outputs (1)

NameTypeDescription
MODELMODEL—