FlowRVS_SM_KSampler
A 'sampler' that runs one step by default — and usually should stay that way
- model
- cond
- condition
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- theMODELout ofFlowRVS_SM_Model.cond- the dict-on-a-wire fromFlowRVS_SM_Cond, which carries the encoded video latent and the prompt embeddings.steps- default1, up to10000. 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.
Inputs (3)
| Name | Type | Default | Description |
|---|---|---|---|
| model | MODEL | — | |
| cond | CONDITIONING | — | |
| steps | INT | 11–10000 | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| condition | CONDITIONING | — |