RALUModelAdapter

RALUModelAdapter exists because RALU doesn't denoise at one resolution. It starts a quarter-size, selectively upscales tokens, and finishes at full resolution - and a flow-matching model's shift parameter controls how sampling effort splits between composition and detail. A shift tuned for one canvas size is wrong for another. This node patches the model so the shift tracks the resolution you're actually generating.

If the words "flow-matching" and "shift" are new, the one-paragraph version: FLUX and SD3 are rectified-flow models that predict a velocity from noise to image, and shift rebalances how much of that trajectory is spent on coarse structure versus fine detail. ComfyUI has a whole family of ModelSampling* patch nodes for exactly this. RALUModelAdapter is the RALU pack's version.

What it patches, per family

From the source, the node clones your model and swaps in a custom model_sampling patch:

• flux - builds a ModelSamplingFlux-based sampler with a shift computed from width and height. The formula is a linear ramp: shift ≈ 0.5 at 256×256-ish and ≈ 1.15 at 4096-ish total pixels. Smaller canvas, lower shift; bigger canvas, higher shift. Same idea as ComfyUI's own resolution-conditional shift nodes, hardcoded for RALU's needs.
• sd3 - uses ModelSamplingDiscreteFlow with a fixed shift=3.0 and multiplier=1000. No resolution dependence; SD3 just gets the standard flow sampling config.
• generic - returns the model unmodified. This matches the pack's broader stance: only flux and sd3 are actually implemented, and generic is a placeholder family.

The inputs are the three you'd guess: model (MODEL), width, height, and model_family. The single output is the patched MODEL, ready for a RALU sampler.

When you actually need it

Here's the catch: the pack usually applies this for you. RALUFluxWorkflowBridge calls adapt_model internally before it runs, and RALUSamplerCore's FLUX path derives the scheduler shift from the real model's sampling config. So in the shipped example workflows you never touch this node.

Where it matters is a hand-built graph: if you're running RALUSamplerCore outside the bridge, or you're being deliberate about which shift your SD3 chain uses, running the model through RALUModelAdapter first is the intended way to get a resolution-consistent shift. Think of it as the "don't forget the shift" node - the one you add so a half-res-then-full-res schedule doesn't denoise with a mismatched curve.

Installing

Same pack as the rest of the RALU nodes:

cd /path/to/ComfyUI/custom_nodes
git clone https://github.com/Milkyawaway/comfyui-ralu-sampling.git
cd /path/to/ComfyUI
python -m pip install opencv-python numpy typing-extensions
python main.py

Or via ComfyUI Manager, search "comfyui-ralu-sampling". Restart after install. The pack uses ComfyUI's modern comfy_api.latest node API, so keep ComfyUI reasonably up to date or the nodes won't register.

Troubleshooting

• model_family set to generic or sdxl? You get your model back untouched, no error, no patch. That's by design - those families aren't implemented. Set flux or sd3.
• This node alone doesn't make RALU run. It only patches sampling. You still need a RALU sampler and a RALUNoiseSource (with correlated_ralu mode) wired up.
• No heavy dependencies. It's pure model patching; opencv-python is needed elsewhere in the pack, but this node itself is trivial.

It's a boring node with a boring job, and that's fine. When your FLUX RALU runs come out with mushy details at odd resolutions, a wrong shift is one of the first suspects - and this is the knob.