ClipFP8ConverterNode

Some VRAM problems aren't the diffusion model at all - they're the text encoder. On Flux-class workflows the T5-XXL encoder can eat several gigabytes on its own, and for many people the very first memory fix is running that encoder in fp8 rather than touching the model. Normally that means downloading a pre-converted fp8 T5 file and rewiring your workflow around it. ClipFP8ConverterNode does the same cast in the graph: load your checkpoint, route the CLIP output through it, and the encoder weights become fp8 on the fly.

It comes from the ComfyUI_DiffusionModel_fp8_converter pack, alongside ModelFP8ConverterNode (the diffusion-model half of the same idea). Together they get you a full fp8 pipeline from an ordinary fp16 checkpoint with no Python scripts and no file juggling.

Where this actually pays off

Be honest about sizing. For an SDXL or Pony checkpoint, the CLIP part is a fraction of the file - the 5GB+ UNet dwarfs it - so this node saves you maybe a few hundred MB of VRAM. Nice, but not life-changing. It matters once you're running a model with a big LLM-style encoder like T5-XXL, where fp8 can be the difference between fitting and not. The author verified T5-XXL converts cleanly, and the community consensus backs that up: an fp8 text encoder is near-lossless for most prompts and is "often the first switch users make." Keep the model full precision and squeeze the encoder - that's the classic low-VRAM recipe.

How it works

The node pokes around the CLIP wrapper ComfyUI hands it - checking both clip_layer and cond_stage_model, the two places a loaded encoder's weights live - and recursively casts every parameter to torch.float8_e4m3fn. Same raw cast as the model node, same in-place mutation, same CLIP object coming back out the other end. One quirk: like its sibling, it swallows exceptions and returns the original encoder if something breaks, so a failed conversion is a console message, not a red node. Check the terminal if quality or behavior seems unchanged.

Inputs and outputs

Two sockets, zero knobs:

clip in - the CLIP output of Checkpoint Loader (or Unclip Loader).
CLIP out - the same object with fp8 weights, ready to feed CLIP Text Encode.

To keep it in memory for the current generation, just wire the output to your CLIP Text Encode node. To write an actual fp8 CLIP file, feed it to ComfyUI's built-in CLIPSave - or into CheckpointSave alongside a ModelFP8ConverterNode output to bake a whole fp8 checkpoint. Saved files land in ComfyUI/output/checkpoints. Without a save node, nothing hits disk, which trips people up the first time.

Install

Same as any custom node - there's no dependency beyond torch, no model to download:

cd ComfyUI/custom_nodes
git clone https://github.com/Shiba-2-shiba/ComfyUI_DiffusionModel_fp8_converter.git

then restart ComfyUI. Or search "ComfyUI_DiffusionModel_fp8_converter" in ComfyUI Manager. The node appears under the conversion category.

The honest caveats

Don't expect it to fix a VRAM crash caused by the model. It only shrinks the encoder. If the diffusion model itself is what doesn't fit, you want the Model half of this pack or GGUF.
Blanket cast, no scaling. Fine for trained weights in practice, but it's a blunt instrument compared to ComfyUI's native fp8 handling.
Only quantize when you need to. If your card fits everything at fp16, fp8 buys you nothing but smaller files.

Bottom line: if your VRAM pain is really T5 pain, this is the fastest way to test that theory - ten seconds of wiring, no downloads, no scripts.