Zura Wan 2.2 Turbo Switch

Here's the chore it removes. You want to iterate fast on a Wan 2.2 Animate clip, so you run a step-distilled LoRA stack at 6 steps and CFG 1.0. Then you want one good take at full quality, which means 40 steps and CFG 5.0 - different LoRA strengths, effectively a different model. The usual workflow is to keep two loaders in the graph and bypass the wrong half by hand, or keep two workflows on disk and let them drift apart.

Turbo Switch keeps both branches wired and picks one from a boolean.

What it is

Four inputs, three outputs, no model files, no downloads. It's the piece of graph plumbing that lets you say "turbo" or "quality" without touching anything else. Straight from the source: it "never loads hidden LoRAs" - the LoRA branches stay visible in the graph, which is why the example workflow uses rgthree's Power Lora Loader. Nothing magic happens behind the panel, and that's the right design; you can see the whole stack.

Inputs and outputs

• base_model and accelerated_model - two MODEL wires.
• turbo - a boolean. On, it takes the accelerated branch; off, the base branch.
• accelerated_steps - 4, 6 or 8. The author's measured default is 6; 4 is about a third faster for roughly 6% less edge detail, and 5 (not offered) buys nothing over either neighbour.

Outputs: model, steps, cfg. Wire model into the sampler's model input and steps/cfg into the sampler's own steps and cfg - they override those widgets when connected.

What it emits is fixed and Wan-2.2-Animate-specific: turbo runs the accelerated branch at 4–8 steps with CFG 1.0; quality runs the base branch at 40 steps with CFG 5.0.

That CFG 1.0 isn't a stylistic choice. Step-distilled LoRAs are trained to solve a schedule in a handful of large jumps, so the usual guidance-scale relationship stops applying - with speed LoRAs you want CFG 1.0, and pushing step count past what the distillation expects creates artifacts rather than refining them. If you've ever run a 4-step distilled model at 20 steps out of caution and gotten mush, that's the mechanism. The 4/6/8 restriction on accelerated_steps is enforcing the same rule.

How it works

The interesting bit is the lazy inputs, and it's what separates this from a plain switch node. Both base_model and accelerated_model are declared lazy, and the node's check_lazy_status returns only the name of the branch currently selected. ComfyUI therefore doesn't execute the other branch at all - the unselected loader (and anything feeding it) simply doesn't run this pass. So you're not paying to have a second 14B checkpoint sitting resident, and you don't get the classic switch-node problem where both branches get evaluated because the engine walked the graph and found both wired in.

That's the whole trick: an A/B switch where the unused side is genuinely skipped, not merely ignored. That's the "selector" shape of switch, not the "first non-null fallback" shape - and the distinction matters exactly when a branch is expensive.

Install

Nothing extra. It ships in ComfyUI_zura_nodes: ComfyUI Manager → Zura Nodes, or

cd ComfyUI/custom_nodes
git clone https://github.com/ZURAVFX/ComfyUI_zura_nodes

then restart. No checkpoints, no ONNX files, no ffmpeg. The pack's requirements.txt extras (requests, yt-dlp, ultralytics) are for the loader and mask nodes.

Where people get burned

• Connect the selected model branch before running. You wired the accelerated branch only, left turbo on, and... no - you left turbo off, so it wants base_model, which is empty. Either wire both branches or flip the checkbox. This is the node's whole vocabulary of complaints, and it's a clear one.
• Expecting it to load LoRAs for you. It won't, by design. The turbo/quality difference lives in the LoRA loaders feeding each branch - that's where the pack's tested stack sits (the two lightx2v-style distills at 0.70 and 0.60 feeding the accelerated side, the bf16 relight LoRA at 1.00 on both).
• Using it on another model family. The 4-step/CFG-1.0 versus 40-step/CFG-5.0 split is tuned for Wan 2.2 Animate, and the node's own docstring says so. Point it at a scheduler with different expectations and you're just making numbers up.
• Forgetting the override. Because steps and cfg are emitted as wires, the sampler's own widgets go dead the moment you connect them. If your render looks like a 40-step run when you wanted turbo, check which branch the checkbox is actually on before you go hunting in the sampler.
• Assuming "turbo" exists for long clips. It speeds up each chunk of the loop; it doesn't change how many chunks your clip needs, and identity drift across chunk boundaries is a separate problem the sampling settings won't fix.