🚀 Upscale Image CUDAspeed

This is a "more pixels" upscaler, not a "more detail" one - worth saying up front, because it decides whether you need it at all. It takes an ESRGAN-family model you already have and runs it through torch.compile, fp16 autocast, and tile processing tuned for batches. If your image is already sharp and you just need it bigger, this is a drop-in replacement for Comfy's stock UpscaleImageWithModel that shaves real time off the job. If you're hoping it'll invent detail the way SeedVR2 or SUPIR does, it won't - that's generation, and this is the opposite lane.

The Fixed in the class name is the whole story. The author's README complains about compiled models recompiling every time the input size changes, and this node is their patch: the compiled forward pass is cached per model hash and per input size, so running 200 video frames at 1280x720 compiles once and reuses the result. The mechanism is otherwise what you'd expect from a Comfy upscale: it loads any Spandrel-compatible single-image model, then drives comfy.utils.tiled_scale with your tile_size/overlap and the model's scale as upscale_amount, outputting straight to GPU. torch.compile(..., dynamic=False) gives it fixed-size kernels, cudagraphs are deliberately disabled (a known crash source), and a second CUDA stream preps input data while the first computes.

Two honest caveats. First, "compiled model survives restart" is half a lie - the pack persists a compile record to compiled_models/*.pkl, not the compiled artifact itself, so each new session still recompiles once per model and size. Expect a warm-up stall on the first run of a session. Second, compiled ESRGAN forward passes sometimes blow up numerically, which is exactly what the "washed out / all-white" output reports are. The node has built-in statistical post-processing - NaN scrubbing, clamping, quantile normalization back to [0,1] - that catches most of it. If you still get a white frame, flip enable_compile to disable and it behaves like the stock node.

The inputs you'll actually touch:

• upscale_model - from UpscaleModelLoader. The README's pick is RealESRGAN_x2plus.pth; anything Spandrel loads works (Real-ESRGAN, Real-CUGAN, SwinIR, HAT).
• tile_size (default 0 = auto) - the author's advice: set it to your video's longest edge, e.g. 1280 for 1280x720. Auto-computes if you leave it.
• overlap (default 0 = auto) - 8 is the suggested minimum.
• enable_compile - leave on; only disable if compile errors or output looks wrong.
• precision / use_autocast - auto/enable are sensible; README recommends forcing fp16.
• optimization_level - balanced default; speed on big VRAM, memory on small cards.
• batch_size (optional) - 1 is the right default for frame-at-a-time video work.

The single output is an IMAGE, ready to feed SaveImage or VHS_VideoCombine. The bundled example workflow is literally video: VHS_LoadVideo → this node → VHS_VideoCombine.

Install it the usual way: ComfyUI Manager, search "ComfyUI-Upscale-CUDAspeed", or

cd ComfyUI/custom_nodes
git clone https://github.com/piscesbody/ComfyUI-Upscale-CUDAspeed.git
pip install -r requirements.txt

then restart. Dependencies are light - spandrel>=0.3.0 and torch>=2.0.0 (you need 2.0+ for torch.compile; most Comfy installs already have that). It optionally pulls in spandrel_extra_arches for non-commercial architectures if you have it. Nothing bundles a model file, so drop your .pth into ComfyUI/models/upscale_models or the node has nothing to run.

Troubleshooting is mostly covered above: slow first run = compile warm-up; OOM = it auto-halves the tile size across three retries, or switch to memory mode and shrink tile_size; compile errors on Windows happen, and the answer is turning enable_compile off. Worth knowing this pack has essentially zero community footprint (its README is Chinese, the audience skews video/anime upscale users) - so if you're stuck, the verbose console logs this node prints are your best friend, not a reddit thread. My honest take: for one lonely 2x still, the compile warm-up eats the savings and you won't feel it. Where this earns its keep is the batch and video-frame case - same model, same size, hundreds of runs. That's when "CUDA speed" stops being a label and starts being real.