Upscale Image (using Model, half precision)

A one-field change to a node you use every day

ComfyUI's Upscale Image (using Model) runs your ESRGAN-family model in float32. That's correct and it's slow. This node is that node with a dtype dropdown, and the interesting position is float16: the author measured about 2.2–2.6x faster on Ada (RTX 40 series) with 4x-UltraSharp, at PSNR 67.6dB versus float32. That is, for practical purposes, the same image.

Sixty-seven dB is not "identical" in the strict sense. It's the range where you cannot see the difference at normal viewing distance, and where any downstream diffusion pass will bury it completely. If you're already keeping a 4x upscale model in your pipeline and it's the slowest thing in the graph - which it usually is on a small card - this is free time. If you need byte-identical output for a diffing workflow, float32 is right there and is literally ComfyUI's own node.

bfloat16 is the third option. The tooltip is honest that it's "slightly less close" than float16, and there's not much reason to pick it on a consumer NVIDIA card where float16 is native and fast. bfloat16 is mainly for cards where fp16 denormal or dynamic-range behaviour is a genuine worry.

How it works

The node loads the upscale model, casts its weights to the requested dtype, and runs the forward pass at that precision. Two extra things happen when the environment allows. For ESRGAN-family models the pack runs the dense blocks with an append buffer and fused kernels, and in float16 the last upscale stage is processed in strips of 256 output rows. That last part isn't about speed - it's about the VRAM peak. The author measured a 512-pixel tile's process memory dropping from 2304MB to 768MB, with the output identical bit for bit. Those paths need NVIDIA with cuDNN (and Triton for the kernels); elsewhere the model just runs as it would in stock ComfyUI.

That's the part you probably didn't expect: a half-precision option that also makes upscaling fit on a card that was failing on it in float32.

Inputs and outputs

• upscale_model - your ESRGAN-style model, from an Upscale Model Loader.
• image - the image to scale.
• dtype - float32 (default, = ComfyUI's node), float16 (the one you want), bfloat16 (usually not).

One output, IMAGE. In a tiled pipeline it feeds the resize → VAE Encode → KSampler chain; in the pack's Ultimate SD Upscale+ path you don't use this node at all, because USDU+ runs its own upscale step.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/nyanmi-1828/ComfyUI-WeightFerry

or Manager → search WeightFerry → install → restart. No model downloads; you supply the upscale model. The pack's requirements.txt needs nothing beyond ComfyUI, though the fused-kernel path wants Triton (triton-windows on Windows) - without it you still get the precision change, just not the kernel gains. NVIDIA GPU and ComfyUI 0.38.0+.

Where it goes wrong

A different-looking result and no idea why. You changed to float16 and the image moved slightly. Expected - that's the whole trade. What you should not do is change dtype and a sampler at the same time and then wonder which one did it. One variable.

Alpha channels. Semi-transparent images have always been awkward through upscale models; this node splits alpha off, runs only the RGB, and reattaches. If you're upscaling cutouts, check the alpha survived before you build a whole workflow around it.

Old or exotic upscale models. The fused kernels and strip processing are aimed at ESRGAN-type architectures, and the fast path is cuDNN-dependent. On AMD, or on an unusual model, expect the plain path - same output, no speedup, and don't conclude the node did nothing because it was just running ComfyUI's maths under a different dtype.

Its own global setting. Ultimate SD Upscale+'s upscale step has a matching dtype default (float16), and WEIGHTFERRY_USDU_UPSCALE_DTYPE=float32 flips it back. This node's dtype field and that env var are separate things, set in separate places. If your USDU output doesn't match what this node produces, that's why.

Treating PSNR as a promise. 67dB was measured on one model, one image, one GPU. It'll be high for you too, but if you're doing quality-critical restoration at 4x with a delicate model, run the comparison once - float32 against float16 at the same seed - rather than taking a number from a README. It's two minutes and it settles the question on your actual content.