ReAL Sampler

Adaptive stepping, without a node pack the size of a framework

Sampler choice in 2026 is basically a two-horse race: whatever ComfyUI ships, and RES4LYF if you want to actually tune. ReAL is a third option that sits in the middle - one sampler, a handful of dials, and it makes its own decisions about how far to jump per step.

ReAL stands for "Accelerating Flow Matching through Segment Advancement with Shared Lookahead" - the paper is Yin et al., 2026. The idea: instead of a fixed sigma schedule, take a lookahead at where the trajectory seems to be heading, check whether the local residual is small enough to justify a jump of K steps, and if so, jump. When the trajectory is bending (early steps, or a prompt change mid-denoise), it doesn't jump and you pay full price. It's a flow-matching sampler, so it's aimed at DiTs - Anima, the Cosmos family, Wan, Qwen-Image - not SDXL's epsilon-prediction UNets.

My take: the appeal is not that it's better than RES4LYF's best solver, because who knows. The appeal is that it's four fields with sensible defaults in a node you already have installed, and the author includes a tail guard and a fallback policy that show somebody actually looked at where this technique produces artifacts. Treat it as an experiment with good hygiene, not a guaranteed upgrade.

How it works

Each step does a short shared lookahead - a small extra evaluation used by both the local and the segment decision - then compares the residual against two tolerances. q_loc governs the local step, q_seg the segment you'd like to advance over. If both pass, it advances up to max_span_K steps at once. If not, it falls back to a normal single step, recomputing the velocity after a long jump so you don't carry a bad estimate forward. Below tail_protect_sigma it stops skipping altogether, because the last few steps are where colours and outlines are decided.

Inputs and outputs

• max_span_K (default 4, range 2–24) - the biggest jump allowed. The tooltip's guidance is concrete: 3–4 is safe for 16 steps, about 12 for 50. Scale it with your step count.
• q_loc (0.7) - local residual tolerance. Tighten it to be conservative.
• q_seg (1.25) - segment tolerance. The tooltip's own framing: 1.25 is the quality setting, 1.65 is the faster one. This is the dial that matters most.
• carry_policy - fallback_only (default) recomputes velocity after a long jump; always reuses it. The author recommends fallback_only against artifacts on few-step models. Take that advice.
• tail_protect_sigma (0.15) - below this sigma nothing is skipped. Protects the finishing steps.

One output, SAMPLER. It goes into SamplerCustomAdvanced (or SamplerCustom) in the sampler slot. You also need a sigma source in that graph - the pack's TORS Scheduler, a BasicScheduler, or a KSampler-free custom setup.

Worth knowing: loading the pack also appends real to KSampler's sampler dropdown, so you can select ReAL without wiring a custom-sampling graph at all. If you go that route the sampler runs with its defaults and you don't get the four dials. Fine for a trial, not for tuning.

Install

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

or Manager → search WeightFerry → install → restart. No extra pip packages - the pack's requirements.txt asks for nothing. NVIDIA, ComfyUI 0.38.0+.

Where it goes wrong

Type mismatch with a custom-sampling graph missing a sigma source. SAMPLER isn't a KSampler input in the normal node - KSampler takes a sampler name string, not a sampler object. If you've wired the output into a stock KSampler you'll get a red link and a validation error. Use SamplerCustomAdvanced or pick real in the dropdown.

Few-step models. With a Turbo LoRA at 6–8 steps, max_span_K 4 means you could jump more than half your schedule in one go. Even with tail_protect_sigma doing its job, that's a lot of trust in a lookahead. Drop to 2 or 3, or don't bother - there's nothing left to accelerate.

Comparing it in isolation. A different sampler makes a different image. That's true of euler vs dpmpp too, and it means "ReAL is worse" often just means "ReAL is different." If you want to know whether it's faster to a comparable image, compare at matched perceived quality - same seed, step counts adjusted so the two land at similar detail - not at identical step counts. Otherwise you're measuring the schedule, not the sampler.

Stacking with TaylorSeer. ReAL can jump several steps at once, and TaylorSeer extrapolates across skipped steps. The pack handles the obvious collision with max_predict_steps on the TaylorSeer node, which caps how far a prediction may reach. If you run both, set that cap. Without it you're compounding two approximations with no bound on the error.

Unfamiliar paper, familiar caution. This is a 2026 sampler from one author's implementation, backed by one README's measurements. Nobody on Reddit is arguing about its settings. If your baseline workflow is working, keep it as a comparison branch rather than a migration.