RUM FLUX.2 Native Match VAE Decode

RUMFlux2NativeMatchVAEDecode is the last link in the diffusers-match chain, and it exists because "decode with the VAE" turned out to be surprisingly load-bearing. It takes your sampled latents and the FLUX.2 VAE and produces an image using the same attention math and post-processing as the diffusers reference pipeline - not whatever ComfyUI's default VAEDecode happens to do.

The pack's TECH doc is refreshingly honest about how much work this took. ComfyUI's default VAE path wasn't just slightly off - the VAE's GroupNorm upcasts BF16 to FP32 while a following F.linear kept its weights in BF16, causing a dtype mismatch that shifted every pixel by 2-3 values (PSNR ≈ 28 dB: "same image, but not identical"). The node fixes that with dtype-aligned linear layers and swaps the attention blocks to diffusers' exact attention formulation. After the fix, the four reference test images came back pixel-identical (max_abs=0).

Inputs and output

• samples - the LATENT from your sampler.
• vae - the FLUX.2 VAE (flux2-vae.safetensors in models/vae/). Not an SDXL VAE; different latent space, and it will show.

Output: image, ready for preview or save.

Both shipped workflows route the final latent through this node, then RUMRoundImageForSave, then SaveImage - the round node exists because the reference also quantizes pixels through PIL's rounding before saving, and bit-exactness includes that final step.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/Rinne414/ComfyUI-RUM
cd ComfyUI-RUM
pip install -r requirements.txt
python scripts/download_models.py --comfy-root /path/to/ComfyUI --include-teacher-clip

Restart ComfyUI. Needs v0.26.2+ (nested latents, the sampler API).

Gotchas

• --cpu-vae ruins the match. Some ComfyUI builds (Aki launcher notably) default to it. CPU vs GPU floating point differs enough to shift pixels 0-7. If your "same seed" output drifts from the reference, check your launch args - a 24GB card runs model + VAE on GPU fine.
• Nested latent batches > 1 raise. The node won't silently decode only the first latent anymore (a 0.2.9 fix); it errors instead. Single-image workflows are unaffected.
• It's a match-path node. For the plain native path, stock VAEDecode is fine. This one's value is pixel parity with the upstream reference, and if you're not validating against that reference, the difference between it and stock decode is measurable but rarely visible.