Apply LoRA Stack (Quantized)

The naive way to apply a LoRA to a quantized model is to just... patch it, and watch your INT8 fast path die. Every layer gets dequantized, patched in fp32, and requantized on every sampling step, so the more LoRAs you stack, the more you pay. This node is the other half of the fix - it's where the "quantized" LoRA stack actually does its thing, taking one or more LoRA Stack Entry (Quantized) outputs and patching them into a quantized (or plain floating-point) MODEL.

What it does

Apply LoRA Stack (Quantized) takes a MODEL in, patches the configured LoRAs into it, and hands a patched MODEL out to your sampler. The interesting part is the mode dropdown, because it decides how the patch happens, and that's the whole game with quantized weights:

• Stochastic (default) - the speed pick. LoRA deltas are combined in fp32 and the layer is requantized once, instead of dequantize-patch-requantize every step. It handles native W4A8 the same way: one dequant, patch, requantize. The trade-off is that requantization can swallow very small deltas, and the pack logs a warning about that on INT4 models and tiny strengths.
• Dynamic - keeps compatible INT8/W4A4 LoRA deltas as actual runtime matrix multiplications, so nothing gets requantized and you keep full delta precision. The cost: each LoRA adds matmuls to every affected layer, so VRAM and first-compile time go up, and W4A8 targets get a console warning before falling back to the Standard path.
• Standard - ComfyUI's ordinary MODEL patch path, kept around for comparison and compatibility.

Inputs and outputs

Three things go in: model (a quantized or floating-point MODEL - the tooltip says both work), mode (the dropdown above), and loras - the autogrow socket. Each LoRA Stack Entry (Quantized) you connect adds another lora_N input, up to 100 entries. One quirk worth knowing: ComfyUI's frontend renders widgets below autogrow sockets regardless of schema order, so the mode dropdown appears below the LoRA inputs even though the backend treats it as the first input. Don't go hunting for it.

Output is a single MODEL, ready for the sampler - or through Quantized Lazy Torch Compile if you want the compiled path.

Install

Same pack as the entry node: ComfyUI Quantization Toolkit in ComfyUI Manager, or:

cd ComfyUI/custom_nodes
git clone https://github.com/SparknightLLC/ComfyUI-QuantizationToolkit

Then restart ComfyUI. Needs ComfyUI 0.32.0+ and a comfy-kitchen with the ConvRot W4A4 / asymmetric W4A8 layouts; no extra pip packages. The registry ID still says "ComfyUI-INT8-Fast-Fork" even though the repo and display name moved on - it's all the same pack, a fork of BobJohnson24's ComfyUI-INT8-Fast.

Where people get burned

Real-world signal on this exact problem is thin (the fork author is not exactly a household name), but the underlying INT8+LoRA pain is well documented: Kijai himself flagged that offloading plus LoRA on INT8 was very slow and that stacking two LoRA nodes could re-introduce the slowdown, with a comfy-kitchen memory leak behind one report (fixed around 0.2.16). Practical takeaways: if you're on a mixed W4A8 model, prefer Stochastic and skip Dynamic; if a stack feels sluggish, try fewer entries or a single merged one; and remember Dynamic LoRAs are runtime-only - they can't be baked into a saved quantized checkpoint. Use Stochastic (or bake before quantizing) when you need the result to survive a save.