ModelSamplingContinuousEDM (Ray)

ModelSamplingContinuousEDM (Ray) is the utility node you reach for when a model's built-in noise schedule is wrong for the way you're sampling it, and you want to patch it without touching the weights. It's the raylight-port of ComfyUI's ModelSamplingContinuousEDM, and it exists because the sigma range a model was trained with isn't always the sigma range that samples well.

Quick primer for anyone who skipped the math: diffusion models denoise from a high-noise state (high sigma) to clean (low sigma), and that range is called the schedule. Different model families were trained on different ranges - SD-style models, EDM-style models, v-prediction models, and flow-matching models all speak slightly different sigma dialects. This node swaps in a continuous EDM-style sampling object so a checkpoint behaves as if it were trained with the sigma bounds you specify.

The inputs

• sampling - the prediction type: v_prediction, edm, edm_playground_v2.5, eps, or cosmos_rflow. This is the big switch. Pick the type that matches how the model was trained; the node even sets the right latent format for Playground v2.5 automatically.
• sigma_max - the high end of the noise range (default 120). Raise it if the model never seems to start from enough noise; lower it if early steps look overblown.
• sigma_min - the clean end (default 0.002). Standard stuff, usually left alone.

All three are floats, so you get a single node that re-casts a checkpoint's sampling behavior. Feed ray_actors in, get ray_actors out, wire the chain to your Ray sampler.

Why you'd actually use it

Two scenarios, both real. First: you're running a checkpoint that wasn't trained in EDM space (older SD checkpoints, v-prediction models) and you want EDM-style sigma handling - the edm and v_prediction presets exist precisely for this. Second: you're on the newer Cosmos flow-matching family and need the cosmos_rflow path, which the node supports with the proper ModelSamplingCosmosRFlow base.

The honest truth is this is a fiddly, "I know what I'm doing" node. If you don't already know which sampling type your model expects, you shouldn't be touching sigma_max - and the defaults (120/0.002) are safe to leave alone. The value here is that raylight makes the same surgery available inside a multi-GPU graph, so you don't have to give up distributed sampling just because a model needs a schedule transplant.

Same install as everything else in the pack (ComfyUI Manager → "raylight", or clone + pip install -r requirements.txt), no model downloads. There's also a stock non-Ray equivalent in ComfyUI if you want to test the settings on a single GPU before committing them to the distributed run.