Load CLIP (Quantized)

The text encoder stopped being a rounding error. On Flux 2 Dev it's 24B of a 56B total - 43% of the model, roughly 18GB by itself - and the KB's verdict is that the encoder is frequently the component that decides whether anything fits on your card at all. That's why modern practice treats it as its own file you load and quantize independently. This node is the QuantOps way to do that: load a single quantized text encoder (CLIP, T5, Qwen, whatever) and hand ComfyUI a ready-to-use CLIP object.

It's not for everyone. If your full-precision encoder already fits, this buys you nothing. If you're stuck at 12GB and the encoder is what's tipping you over, quantizing it is usually the least-painful lever you can pull - the usual advice is to spend your precision budget on the diffusion model and squeeze the encoder. How much that costs is genuinely contested in the community: one user reported a big quality gap between fp8 and a full Qwen3-8B encoder while another ran a Q2 encoder and called it completely fine. YMMV, but the VRAM savings are guaranteed.

How it works

The node reads the safetensors, detects the quantization format of every layer, and forwards that information into ComfyUI's model options so the text-encoder factory builds the right mixed-precision ops. The headline format is int8_tensorwise - DeepSeek-style int8 weights with tensorwise scaling that run through torch._int_mm, the fast integer matmul - which is the format silveroxides pushed before ConvRot INT8 became the thing ComfyUI adopted natively. The other formats in the dropdown (float8_e4m3fn and its blockwise/rowwise cousins, mxfp8, hybrid_mxfp8, nvfp4) map to different quantization layouts you'll mostly encounter as files on silveroxides' HuggingFace.

The inputs that matter

• clip_name - the quantized encoder file from your text_encoders folder.
• type - two dozen architecture options (stable_diffusion, sd3, ltxv, cosmos, lumina2, wan, hidream, chroma and more). Pick the family your model uses; the node needs it to build the right CLIPType.
• quant_format - auto scans the file and figures it out; set it explicitly only when you know you want to force a specific layout.
• kernel_backend - pytorch or triton. Triton is the fast path for int8 on cards that support it, but it needs the extra setup below.
• disable_dynamic and low_memory - the same loading-path toggles the whole pack shares: they control whether ComfyUI's mmap-backed dynamic VRAM loader is used or bypassed.

Output is a single CLIP, which feeds a CLIP Text Encode node exactly like any other encoder output.

Installing it

Pack install as usual: ComfyUI Manager → search "ComfyUI-QuantOps", or clone it:

cd ComfyUI/custom_nodes
git clone https://github.com/silveroxides/ComfyUI-QuantOps

Restart and let it pull in unifiedefficientloader>=0.5.2. Encoder files live on silveroxides' HuggingFace.

Where people get burned

Two things. First, int8_tensorwise is not plug-and-play on a 30-series card. The README's setup list is specific: torch 2.10+cu130 or newer, the matching triton-windows wheel (on Linux, plain pip install triton), silveroxides' pre-compiled comfy-kitchen int8 wheel from his HuggingFace, and the --enable-triton-backend ComfyUI launch flag. Skip any step and the fast backend won't engage - it may silently fall back or error. Second, the pack is deprecated: with int8 ConvRot now native in ComfyUI (v0.27.0+), the author has stopped maintaining and says so in no uncertain terms in the README. If you're starting fresh on a recent ComfyUI, the native path is the better bet - this node's value is mostly in loading the older tensorwise/format files already out there.