Load CLIP FP8

ComfyUI does something quietly wasteful when it loads a text encoder: it takes your nice, small FP8 checkpoint and upcasts every weight to FP16/BF16 the moment it lands in VRAM. That's fine when your text encoder is a 300MB CLIP-L. It's a disaster when it's Qwen3 8B, where a ~7.5GB FP8 file inflates to 14.5GB of weights and spills over into system RAM - and suddenly every prompt encode takes 20-30 seconds while the GPU swaps memory around. Load CLIP FP8 is a drop-in replacement for the stock Load CLIP node that keeps those weights stored as FP8 and only upcasts each layer at the moment it's actually used. It's the same math, just not done all at once up front.

Why you'd reach for this

This node only earns its keep with huge text encoders - the Qwen3-class models that power Chroma, Flux 2, OmniGen2, HiDream, and similar modern workflows. Those are genuinely big: Qwen3 8B is an 8-billion-parameter LLM serving as a prompt conditioner, and the FP8 version is the difference between "fits on my 16GB card" and "runs off the GPU and into system RAM." The author, Dryw Filtiarn, built it for exactly that on an RX 9070 XT: with the stock loader his dual-CLIP Flux 2 workflow took ~280 seconds per image; with this node plus Sage Attention v2 it dropped to ~100 seconds. Most of that win is the clip encode going from 20-30 seconds down to sub-second.

It's also a GGUF alternative. This node loads plain FP8 safetensors and keeps them at FP8 - no GGUF, no dequantization overhead, no GGUF-vs-LoRA slowdown. The author is openly anti-GGUF for text encoders, and honestly, for big encoders this is the cleaner path.

The catch: on SD1.5/SDXL where the text encoder is small enough to fit anyway, this does nothing for you. It's a niche fix for a specific, painful problem - but when it's your problem, it's transformative.

How it works

After comfy.sd.load_clip does its normal load, the node walks every nn.Linear in the encoder and performs weight surgery. The weight is pulled out of PyTorch's _parameters, cast to torch.float8_e4m3fn, and stored as a non-persistent buffer. Each layer's forward is patched to materialize that buffer to the incoming activation dtype (FP16/BF16) just before the matrix multiply, then throw it away.

Because the weights now live in _buffers instead of _parameters, ComfyUI's internals get confused - its memory accounting would report the model as ~1.2GB (biases only), which makes the VRAM scheduler do dumb offloading. So the node applies three process-scoped, idempotent monkeypatches: module_size counts buffers too, get_key_weight falls back to the FP8 storage so LoRAs and patching still work, and model_size reports the true byte count. If your PyTorch lacks torch.float8_e4m3fn (older than 2.1), everything is skipped and you get stock FP16 behavior with a warning.

The inputs that matter

• clip_name - the text encoder file, picked from ComfyUI's text_encoders folder. Drop your FP8 checkpoint (or FP16/BF16 - the conversion happens post-load either way) into ComfyUI/models/text_encoders/ and select it.
• clip_type_name - the architecture variant: stable_diffusion, flux2, wan, hidream, sd3, mochi, cogvideox, and a dozen more. This mirrors the stock node's type menu; match it to your model.
• device (advanced) - default uses ComfyUI's normal placement; cpu forces load/offload to CPU.

The single output is a standard CLIP object, identical in type to the stock node's. Wire it into CLIP Text Encode (Prompt) exactly as you already do.

Installing it

Via ComfyUI Manager, search for comfyui-fp8-load-clip, or clone it by hand:

cd ComfyUI/custom_nodes
git clone https://github.com/DrywFiltiarn/comfyui-fp8-load-clip

Then restart ComfyUI. That's it - there are no Python dependencies beyond what ComfyUI already has, and the node downloads nothing; it uses text encoders you've already got or fetch yourself. Just make sure your PyTorch is ≥2.1 with FP8 support.

Common issues

The most likely one is environmental: no torch.float8_e4m3fn means no FP8, and the node silently falls back to stock behavior. Update PyTorch and confirm FP8 exists.

The bigger caveat is that this is a young node (v0.1.0, May 2026) that monkeypatches ComfyUI internals - comfy.model_management.module_size and comfy.model_patcher.get_key_weight. A ComfyUI update that changes those functions can break it, so if you see weird memory reporting or scheduler oddities after an upgrade, that's where to look. Device mismatches during inference usually mean model and inputs aren't both on cuda:0. And worth saying plainly: on cards where even the FP8 encoder doesn't fit, the GGUF lower-quant ladder still exists - FP8 is one step, not the whole staircase.