TwinFlow_SM_KSampler

If you've got a TwinFlow-distilled model loaded, this node is the whole reason you bothered. TwinFlow is inclusionAI's self-adversarial flow distillation (arXiv 2512.05150) - instead of keeping a frozen teacher plus a discriminator around, the model learns to rectify its own flow field, which is how a 20B model becomes a 1–2 step generator without tripling memory. But a distilled flow model doesn't behave like a normal diffusion checkpoint. Run it through ComfyUI's stock KSampler and you get noise or mush; the community learned that fast. This node is the dedicated sampler, and it's where the speed claim actually lives.

How it works

The sampler is a port of the UCGM-S unified flow-matching loop, tuned for few-step stochastic sampling. The clever part is what the node does with your steps: at 1–2 steps it switches on stochastic sampling (a noise-injection ratio of 0.8 at one step, 1.0 at two) and a "few-step" style that jumps straight at the clean image. Beyond 2 steps it goes deterministic and hands you a choice between the any and mul sampling styles, which just differ in how sampling effort is distributed across timesteps. It also builds the prompt attention mask itself from your conditioning, sets CFG to 0 - TwinFlow is guidance-distilled, so there is no negative prompt and none is offered - and generates.

That last point is worth repeating because it catches everyone: there's no negative input on this node. You wire positive conditioning in and that's it.

The inputs that matter

• positive - CONDITIONING from a standard CLIPTextEncode (the example workflow uses the Comfy-Org Qwen or Z-Image CLIP loaders). One input, no negatives.
• steps - default 2, and that's the number people actually use. The README's speed figures are all two-step. One step is faster and noticeably worse; the author's own update notes say 1-step quality is mediocre and big images want more steps.
• block_num - default 10, and it's the low-VRAM control. With block_num > 0, the transformer is split into blocks that get swapped to the GPU in groups, so you can run Qwen-Image on a 12GB card (~15s per 1024×768, offloading). Set it to 0 to load everything onto the GPU - the README says do exactly that if you have more than 16GB, for maximum speed.
• force_offload - none / clip / all. clip unloads ComfyUI's CLIP models before sampling, which the README recommends for most cases; all unloads everything. If you're generating repeatedly with the same prompt, none avoids reload churn.
• width / height - default 1024, in 16-pixel steps, up to 16384. Z-Image's native ceiling is ~2MP, so beyond that you're relying on DyPE (see the model node's use_dype) or a smaller canvas.
• seed - nothing exotic, it just works like you'd hope.

The single output, latents, goes into a VAEDecode with the matching VAE (Qwen's qwen_image_vae.safetensors, Z-Image's Flux ae.safetensors).

Troubleshooting

• White noise / garbage. The #1 cause is running the model through a normal KSampler. If you're using this node and still getting noise, check for Sage Attention - it's been reported to wedge this sampler, and toggling it off fixes it.
• "It's not actually faster." First-run comparisons against Qwen-Image 4-step Lightning LoRA showed TwinFlow winning on time but not by a mile (roughly 9–10s vs 13–14s per image on an RX 7900 XTX). The win compounds at 1–2 steps and at higher resolutions; at 4+ steps the advantage shrinks.
• Low quant quality. Q4 and below look bad with this method - the model loads and the shapes are right, but the output is soft and oversaturated. Use Q8 (or BF16) whenever it fits.
• Low VRAM hangs. If generation stalls rather than errors, drop block_num down so more offloads happen, or close other apps; a 24GB report of a stuck Q6 suggests it was a VRAM edge, not a bug.

The honest verdict: at 2 steps it's a real speedup and quality is surprisingly close to the distilled originals. One step is a demo, not a workflow. And no, you don't need to understand the flow math - just don't touch sampling_style until you're chasing a specific look.