DPM++ Extended Samplers (status)

What you're actually dragging onto the canvas

This node has no inputs, no outputs, and no settings. Not a crawling bug on this page - the class really is an empty passthrough. INPUT_TYPES returns {"required": {}}, RETURN_TYPES is (), and its one method prints a line to the console. Its whole job is to sit in the node list under sampling/custom_sampling/dpmpp_extended and confirm the pack imported without exploding.

The actual product is the pack around it. On load it registers a pile of extra sampler names into ComfyUI's global registry, so they appear in the ordinary KSampler sampler_name dropdown next to euler and dpmpp_2m. You don't wire those up either - you just pick one from the list.

That distinction matters, because sampler tuning is where a lot of 2026 advice lives. DPM++ 2M Karras is scoped to SD 1.5/SDXL finetunes now; flow-matching models (Flux, Z-Image, Anima) want Euler-family solvers on conservative schedules, which is why packs like RES4LYF went mainstream. This one is a small single-author entry in that space: DPM++ extended to higher orders plus the author's Flow-WLS method, benchmarked on Anima - a Cosmos DiT, i.e. flow-matching.

How it works, mechanically

At import time __init__.py walks a dict of sampler functions and, for each name, appends it to comfy.samplers.SAMPLER_NAMES and injects the callable into comfy.k_diffusion.sampling as sample_<name>. That second step matters: ComfyUI resolves a sampler name by looking up exactly that attribute, so injecting it is how a dropdown entry becomes working code. Registration happens at import, before any node runs.

The families it adds:

• dpmpp_1m_sde_gpu … dpmpp_8m_sde_gpu, plus _m_heun_gpu (Heun corrector, 2 model calls per step) and _m_ancestral variants
• dpmpp_3s_* … dpmpp_8s_* singlestep solvers (deliberately starting at order 3 so they can't shadow official names like dpmpp_2s_ancestral)
• dpmpp_adaptive_sde_gpu, dpmpp_adaptive_heun_gpu, dpmpp_adaptive_ancestral
• cab_2 … cab_6
• flow_wls_3, flow_wls_4, flow_wls_5, flow_wls_6, flow_wls_8
• flow_unipc_2, flow_unipc_3

The Flow-WLS entries are the headline. The code computes a velocity field as (x - denoised) / sigma, keeps the last L velocities and their step sizes, fits a quadratic through them by weighted least squares with exponential memory decay (gamma = 0.85, so older steps count less), then integrates that parabola analytically across the step. That's why deeper history smooths instead of blowing up: you're fitting a low-degree curve to more points - a Savitzky-Golay filter wearing a sampler's coat. Early on there isn't enough history, so the fit drops to a lower degree. Neither gamma nor the degree is exposed. The number in the name is the only knob.

Inputs and outputs that matter

There aren't any. DPMPPExtendedStatus has zero inputs and zero outputs, and it's flagged as an output node, so ComfyUI executes it on every queue run - printing [dpmpp_extended] registered samplers: [...] to the console. That's it. Don't try to wire it to a VAEDecode; there's nothing to connect. Everything you'd normally think of as setting up the node happens in KSampler: sampler_name, steps, cfg, scheduler.

Install

No model downloads, no venv surgery. Declared dependencies are numpy and torch, both already present. (pyproject.toml also lists scipy, but nothing in the shipped code imports it - ignore the mismatch.)

Try ComfyUI Manager first - search Flow-WLS & DPM++ Extended Samplers. If it's not indexed yet, clone it:

cd ComfyUI/custom_nodes
git clone https://github.com/YakovSava/research-unipc-dpmpp

Restart ComfyUI, then confirm two things: the status node shows up in node search, and the new names are in a KSampler's sampler_name dropdown. If they're missing, read the startup console - an import error kills both, since registration happens at import.

Where people get burned

A stock name gets quietly replaced. The registration loop overwrites the k-diffusion function unconditionally, and the pack registers names stock ComfyUI already ships - dpmpp_2m_sde_gpu among them. The SAMPLER_NAMES list is guarded against duplicates; the function injection isn't. Orders 1–3 are claimed as literal transcriptions, so in theory nothing changes - but if an old workflow's baseline shifts after install, look here first.

Order 4+ is explicitly experimental. The module docstring doesn't mince words: orders 1–3 match published code, orders 4–8 are the author's generalization, and high-order polynomial extrapolation tends to blow up (Runge phenomenon) early in the schedule. The repo ships test_order_convergence.py so you can measure accuracy yourself. The README's tables - SSIM climbing to 0.80 at 10 steps - are one model, one GPU, one resolution, self-reported.

Nobody has hit your bug before. I went looking for community signal on this pack and found none: zero threads mentioning flow_wls, the author, or the repo across the corpus. It's a single-author research repo with a Zenodo DOI, which means self-published, not peer-reviewed. Fine for trying high-order multistep on a flow-matching model, but treat it as an experiment, not the sampler you ship a client workflow on.

ComfyUI too old. The pack imports offset_first_sigma_for_snr, sigma_to_half_log_snr and to_d from comfy.k_diffusion.sampling. Older builds don't expose all of those; the import fails and nothing registers. Update ComfyUI and restart.