☁️BizyAir Apply Controlnet with VAE
The DiT-era ControlNet apply node
- positive
- negative
- control_net
- vae
- image
- positive
- negative
The name says SD3, but the shape of this node is really "the ControlNet apply for DiT-based models" more broadly - anything built on a transformer backbone rather than a UNet, which by 2026 is most of the current generation (SD3.5, Flux-family, and whatever else BizyAir's catalog has onboarded that shares the architecture). The one thing that sets it apart from the plain Apply ControlNet node is a required vae input, and that's not incidental - it's a direct consequence of how ControlNet had to be re-implemented when the ecosystem moved off UNets.
Why the VAE is required here and not on the classic apply node. On a UNet architecture, ControlNet works by creating a trainable copy of the UNet's encoder blocks and feeding it the raw conditioning image directly, then adding its output into the frozen model's skip connections. DiT architectures don't have that structure to copy - ControlNet on Flux, SD3.5 and their peers gets re-implemented against attention and MLP layers instead, and getting the reference image into that pipeline means encoding it into latent space first, the same way your actual generation happens in latent space on these architectures. That's the VAE's job here: it's not decorating the workflow, it's how the conditioning image actually gets into a form the DiT-style ControlNet can use. This is also, concretely, why no SD-era ControlNet file works on a modern base and vice versa - the mechanism itself changed, not just the file format.
Inputs that matter. positive and negative (BIZYAIR_CONDITIONING), control_net (BIZYAIR_CONTROL_NET), vae (BIZYAIR_VAE), and image, all required. strength (default 1, range 0–10, step 0.01) and the start_percent/end_percent step window (0–1, step 0.001, defaulting to the full 0–1 range) work exactly like they do on the standard Advanced apply node - dial end_percent down toward 0.5-ish if you want the model to reclaim detail in the later steps rather than staying spatially pinned the whole way through. The current DiT-era union ControlNets generally publish lower recommended weights than the old SD 1.0 default too, so treat strength 0.65–0.9 as the more typical modern starting range rather than maxing it out.
Outputs: positive and negative, both BIZYAIR_CONDITIONING, ready to feed straight into your sampler or guider in place of your original pair.
Install: search "BizyAir" in ComfyUI Manager and click install, git clone https://github.com/siliconflow/BizyAir.git into custom_nodes then restart, or comfy node install bizyair - one install for the whole pack, this node included alongside the rest of BizyAir's ControlNet family. It's a cloud call under the hood, so a registered BizyAir account with your API key set is required - the README's first-use instructions apply to this node exactly as much as any other.
Troubleshooting. The most model-specific gotcha here is architecture mismatch: make sure the control_net you loaded was actually trained for the base model you're generating with (a ControlNet built for SD3.5 won't transfer to Flux or vice versa, since each DiT architecture needed its own ControlNet trained from scratch). Beyond that, the same advice as the Advanced apply node applies - pull end_percent down before raising strength if output feels over-constrained, and check your API key first for any stall or unexplained failure.
Inputs (8)
| Name | Type | Default | Description |
|---|---|---|---|
| positive | BIZYAIR_CONDITIONING | — | |
| negative | BIZYAIR_CONDITIONING | — | |
| control_net | BIZYAIR_CONTROL_NET | — | |
| vae | BIZYAIR_VAE | — | |
| image | IMAGE | — | |
| strength | FLOAT | 1.000–10 | — |
| start_percent | FLOAT | 0.0000–1 | — |
| end_percent | FLOAT | 1.0000–1 | — |
Outputs (2)
| Name | Type | Description |
|---|---|---|
| positive | BIZYAIR_CONDITIONING | — |
| negative | BIZYAIR_CONDITIONING | — |