TurboDiffusion I2V Sampler

This is the node you installed the pack for. TurboDiffusionI2VSampler is the whole pipeline in one box: it takes your text prompt, your starting image, and the two models the loader node provides, and returns finished video frames. No KSampler, no manual VAE encode/decode, no figuring out Wan's awkward latent layout. If you've used native Wan 2.2 in ComfyUI and winced at the 25-minute 720p renders, the pitch here is 4 steps instead of 30.

What it does, mechanically

The node runs the full I2V path internally, which is why it works:

1. Pulls the text embedding out of your CONDITIONING.
2. Encodes your start image with the Wan VAE - one real frame plus num_frames - 1 zero frames, with a mask on the first frame so the model knows it's animating that image forward.
3. Initializes Gaussian noise from your seed.
4. Runs dual-expert rCM sampling: the high-noise model handles steps 0 → boundary, gets offloaded, then the low-noise model refines steps boundary → num_steps.
5. Decodes the latents back to frames.

The boundary default of 0.9 means the first ~3.6 of your 4 steps run on the high-noise expert (motion, structure) and the last sliver on the low-noise expert (detail). Drop it and the low-noise expert does more; crank it and motion gets rougher. 0.9 is a fine place to start.

The inputs that matter

You've got the two MODEL inputs (high-noise and low-noise from TurboWanModelLoader), conditioning (from a CLIPTextEncode fed by the umT5 encoder), vae (from TurboWanVAELoader), and image. Those are plumbing. The knobs you'll actually turn:

• num_frames - must be 8n+1. 49, 77, 121, 225. The step is already locked to 8 in the UI so you can't get it wrong.
• num_steps - 1-4, default 4. It's a distilled model: more steps doesn't buy you much, fewer saves time. Don't wander above 4, it wasn't trained for it.
• resolution + aspect_ratio - pick 480 (low VRAM), 480p, 720/720p, or custom. As a rough map from the README: 8-12 GB VRAM → 480 at 49 frames; 16 GB → 480p at 77 or 720p at 49; 24 GB+ → 720p at 77+. The width/height fields only matter when resolution is custom.
• boundary (0.9), sigma_max (200), use_ode - leave these alone at first. use_ode gives sharper but less robust sampling; the SDE default is the safer one.

Output is a single frames tensor in plain ComfyUI IMAGE format (frame-batched, B*T, H, W, C), so it plugs into any image/video preview or straight into the pack's TurboDiffusionSaveVideo.

Speed and quality: the honest part

The README claims ~60-90 seconds for 720p, 77 frames, 4 steps on a 3090 with SLA attention, and that's roughly in the right zip code. A real-world report from early adopters: a 6-second (≈145 frame) 720p clip ran about 5 minutes on a 3090 - ~100x faster than native Wan, and 2-3x faster than Wan 2.2 + lightx2v LoRAs, without the warping the LoRAs introduce.

Here's the trade. TurboDiffusion is distilled, and distillation costs detail. Close-ups and slow shots look close to native; fast, sudden motion turns into noise artifacts (the classic example: speckle crawling up around the feet), and smoke/splashes/wide shots show the compression. One early tester's verdict after a week: for their work the lightx2v turbo LoRAs were the better option. Treat this node as a superb iteration tool - nail the prompt at 4 steps, then decide whether you need the full-render pass.

Troubleshooting

• CUDA OOM - drop resolution to 480 or num_frames to 49. The node itself prints a warning when the frame tensor gets big.
• Slow or "horrible" output on a 5090 - a few 5090 users reported this pack runs badly there (one filed it as issue #8). It seems genuinely happier on the 3090-class cards the author tested.
• OOM that won't go away regardless of settings - if you're on PyTorch 2.9, downgrading to 2.8 is the documented community fix.