☁️BizyAir KSampler (Advanced)

This is the same idea as BizyAir KSampler, cloud-side sampling that runs on SiliconFlow's infrastructure instead of your card, but built for the workflows where you need to stop denoising partway through and hand the latent off to something else. Two-stage hires-fix pipelines, refiner passes, or chaining a couple of sampling stages with different settings all lean on this node's extra controls rather than the plain one.

What's different from the basic KSampler

Four fields do the actual work here. add_noise (enable/disable) decides whether fresh noise gets injected at the start of this sampling call, disable it and the node continues denoising an already-partially-denoised latent instead of starting fresh, which is exactly what you want on the second half of a split pass. start_at_step and end_at_step (both up to 10,000, versus the plain KSampler's hard 50-step cap) let you carve out a slice of the schedule to run, so one KSamplerAdvanced node can do steps 0-15 and a second can pick up 15-30. return_with_leftover_noise (enable/disable) controls whether the output latent keeps its residual noise so the next stage can keep denoising it correctly, or gets fully resolved as a finished image latent.

Everything else is identical to the basic sampler: noise_seed instead of seed (same role, different name because there's now a separate concept of "adding noise" at all), steps, cfg, sampler_name/scheduler off the same full stock ComfyUI list, and positive/negative/latent_image wired the same way. Output is a LATENT.

The same architecture-first sampler advice applies as with any KSampler variant: check whether your checkpoint is DDPM-style (SD 1.5/SDXL and its finetunes, where Karras schedules are a genuine correction) or flow-matching (Flux, Z-Image, and similar, where Karras and exponential schedules are a documented failure mode, not just a worse choice). Take the model card's recommendation before defaulting to habit.

The type constraint carries over

Same rule as the rest of the pack: model here is BIZYAIR_MODEL, not the stock MODEL type, and positive/negative want BIZYAIR_CONDITIONING. You build the whole sampling chain out of BizyAir loaders and encoders, you don't splice this into an otherwise-local workflow. If you're chaining two KSamplerAdvanced nodes for a multi-stage pass, both need to sit downstream of the same BizyAir model-loading subgraph.

Installing it

Through ComfyUI Manager: search "BizyAir" and install, or clone it directly:

cd ComfyUI/custom_nodes && git clone https://github.com/siliconflow/BizyAir.git

Restart ComfyUI. Before anything runs you need a BizyAir/SiliconFlow API key, set on first use through the "click to login" prompt the README points to. Account signup uses phone-number verification, and it's worth knowing in advance that people outside China have reported friction getting that step to accept a non-Chinese number.

Common issues

If a run stalls or fails outright with no obvious workflow error, check the API key first, that's the most common cause with any BizyAir node, this one included. A type mismatch at the model or conditioning sockets means something upstream isn't a BizyAir node, swap it for the equivalent BizyAir loader.

Worth double-checking your start_at_step/end_at_step math if a multi-pass chain produces an oversharpened or blown-out image: overlapping ranges, or an add_noise/return_with_leftover_noise mismatch between stages (e.g. the first stage discards leftover noise but the second stage expects it), is the usual culprit and it's a workflow-logic issue, not something wrong with the node.

Also worth knowing, separate from anything this node does: ComfyUI Manager has been known to auto-install the whole BizyAir pack when it misresolves an unrelated missing-node error on an older shared workflow. If BizyAir shows up in your custom_nodes folder uninvited, it's legitimate software from SiliconFlow rather than something malicious, and it's safe to remove via the Manager if you don't want it.