Nodes/ComfyUI_FlowRVS/FlowRVS_SM_KSampler
ComfyUI Node

FlowRVS_SM_KSampler

A 'sampler' that runs one step by default — and usually should stay that way

By smthemex·Created 11 months ago·Updated 7 months ago· 8
FlowRVS_SM_KSampler
  • model
  • cond
  • condition
steps1

The name is a lie in the best possible way. FlowRVS_SM_KSampler has no CFG slider, no seed, no scheduler dropdown, no positive/negative pair - the widgets that define every KSampler you've ever touched. What it has is a steps input that defaults to 1, and that's the one you'll leave alone most of the time.

Here's the context. FlowRVS is a flow-matching model: the same family as Wan itself, but fine-tuned with a training objective that converges in very few denoising steps - the kind of distillation-adjacent trick the community has been chasing across all of video generation (that's the same reason people run Wan at 4-8 steps with lightx2v, or VACE at 2-4). For a small 1.3B DiT doing segmentation rather than pretty pixels, one step genuinely produces a usable mask. The example workflow shipped with the pack runs at steps=1 and the README's whole pitch is "more frames, better fps, fewer steps."

So the inputs:

  • model - the MODEL out of FlowRVS_SM_Model.
  • cond - the dict-on-a-wire from FlowRVS_SM_Cond, which carries the encoded video latent and the prompt embeddings.
  • steps - default 1, up to 10000. More steps = smoother/cleaner mask latents, at linear cost. If your masks come out mushy or with soft false-positive blobs, bump to 2-4. Past that you're paying for nothing; this isn't a quality ladder, it's a small model converging.

Mechanically it's honest flow-matching: it builds a FlowMatchEulerDiscreteScheduler, then iterates the timesteps feeding the DiT the current mask latents along with the original video latent as the conditioning signal - so the "video condition" it passes in is literally the clip you're segmenting, which is how the model knows what to deform into a mask. When it's done, it adds the sampled mask latents to the cond dict and passes the whole thing on.

The output is typed CONDITIONING and named condition, but again - it's the same internal dict, now carrying latents. That's why it feeds FlowRVS_SM_Decoder, not a VAEDecode. Do not try to substitute a stock KSampler in this slot; the wiring won't survive it.

Installing

cd ComfyUI/custom_nodes
git clone https://github.com/smthemex/ComfyUI_FlowRVS.git
pip install -r requirements.txt

Or ComfyUI Manager → search "ComfyUI_FlowRVS". The dependencies (diffusers, transformers, sentencepiece, timm, pycocotools, moviepy…) are heavy; the four model files the README lists go in ComfyUI/models/diffusion_models, ComfyUI/models/vae, and ComfyUI/models/FlowRVS, plus the umt5 text encoder for the text side.

Troubleshooting

  • Masks look like a smeared gray mess - don't crank steps to 100. Go to 2, then 4. If it's still bad, the problem is upstream: wrong VAE (must be the diffusers Wan VAE, not Comfy-Org's), or the text encoder isn't umt5.
  • It runs but nothing changes between 1 and 4 steps - that's normal when the model is already confident; leave it at 1 and save the GPU.
  • Slow first run - this node unloads other models from VRAM before it starts, so the first queue can look like it's stalling. It's not; it's making room for the DiT.

Worth knowing: the same author (smthemex) publishes several of these paper-ports, and they share a house style - few knobs, defaults that actually work, terse docs. This node is the best example of "trust the default" in the pack.

CategoryFlowRVS_SM

Inputs (3)

NameTypeDefaultDescription
modelMODEL
condCONDITIONING
stepsINT11–10000

Outputs (1)

NameTypeDescription
conditionCONDITIONING