ModelSamplingDiscrete

You almost never add this node to a workflow yourself - you add it when a downloaded LoRA or an obscure checkpoint tells you to, or when a model comes out of the loader looking wrong and you suspect the loader picked the wrong sampling recipe. ModelSamplingDiscrete is the switchboard for the thing that decides what a denoising step actually means.

Every diffusion checkpoint ships with a bit of hidden configuration called the model sampling: the math that maps timesteps to sigmas, and the formula that turns the network's raw output into a denoised image. That math lives inside the model object, and this node replaces it on a clone of the model without touching the weights. That's the whole trick - it's a patch, not a transform.

What the sampling choices mean

The sampling dropdown is the real surface here. Six options, each a different contract about what the network is trained to predict:

• eps - predict the noise. The classic SD 1.5 recipe, and the default most loaders pick.
• v_prediction - predict velocity (a blend of noise and image). Used by many modern models and video models; gets you better high-sigma behavior.
• lcm - a distilled 50-step schedule with LCM's skip/scale re-parameterization, built for LCM-distilled checkpoints and LoRAs that are trained to work in a handful of steps.
• x0 - predict the denoised image directly.
• img_to_img / img_to_img_flow - expect a noisier starting latent, tuned for img2img rather than fresh generation.

Then there's zsnr, a toggle rather than a mode. Zero-terminal-SNR changes the noise schedule so the last timestep isn't pure noise - some SDXL-era models and fine-tunes were trained that way and look washed-out or milky unless you flip it on.

Where it goes and what comes out

It plugs in right after the checkpoint loader (or LoRA stack) and before the sampler. The single MODEL output replaces the model object, so everything downstream just continues as if nothing happened. The mechanism, in source terms: it clones the model, builds a new sampling object, and patches it in with add_object_patch("model_sampling", ...). Nothing else changes, which is why it's safe to add and remove freely.

The gotchas

The classic beginner trap is matching a prediction type to a model that wasn't trained for it. Force eps onto a v-prediction model and you get oversaturated, broken output - the fix is flipping the dropdown, not deleting the node and starting over. And note this node deals with the discrete 1000-step schedule family. If a workflow asks for ModelSamplingContinuousEDM or ModelSamplingContinuousV instead, it wants the continuous-time variant, which is a different node - same idea, different math.

The other thing worth knowing: when a checkpoint's own config already sets the sampling type correctly (which is the normal case), this node is a no-op you don't need. It exists for the models that don't, and for the people experimenting with putting a model "in the wrong mode" on purpose. One of those people is probably you, eventually.