☁️BizyAir ModelSamplingFlux

Flow-matching models like Flux don't tune their behavior through the sampler and scheduler the way SD 1.5/SDXL do, that knob has largely moved somewhere else: a timestep shift that decides how sampling effort splits between composition and fine detail. This node is where that shift lives for Flux specifically, patching a BIZYAIR_MODEL before it reaches your sampler, and it's the cloud-run equivalent of ComfyUI's own stock ModelSamplingFlux node, same parameters, same effect, running against a model hosted on SiliconFlow's servers instead of your local weights.

What shift actually does, and why width/height are inputs here

max_shift (default 1.15) and base_shift (default 0.5) together define how the noise schedule stretches as resolution changes, higher-resolution generations get more shift, and that's not incidental, it's the reason width and height (both default 1024) are inputs on this node at all. Flux was trained across a range of resolutions, and the model expects the timestep schedule to adapt accordingly, generate at a much larger size than the defaults assume without adjusting shift and the model can under- or over-commit to detail relative to what the resolution actually calls for.

This is worth knowing in the context of the broader "Karras is dead on flow-matching models" story: the old habit of reaching for a fancier scheduler to fine-tune output quality doesn't transfer to Flux, aggressive schedule reshaping is a documented failure mode on this architecture family, not just a suboptimal choice. Shift is roughly where that tuning effort actually goes now. If your Flux generations look undercooked or oddly composed at an unusual aspect ratio or resolution, this node, not the scheduler dropdown, is the first place to look.

Practical guidance

Leave max_shift/base_shift at their defaults unless you have a specific reason to move them, they're tuned to match how Flux itself was trained. Do set width/height to match your actual target generation size rather than leaving them at the 1024 default if you're working at a substantially different resolution, that's the one input on this node most likely to be wrong for your workflow if left untouched.

Output is BIZYAIR_MODEL, a patched model, chain it directly into your BizyAir_KSampler or BizyAir_KSamplerAdvanced in place of the unpatched model coming straight off the loader.

Installing it

Through ComfyUI Manager: search "BizyAir", install, restart. Or clone it directly:

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

Every node in this pack, including this one, needs a BizyAir/SiliconFlow API key before it will actually execute, set via the "click to login" prompt on first use. Account signup involves phone-number verification, and it's worth knowing in advance that some users outside China have reported trouble getting that step to accept a non-Chinese number.

Common issues

If output quality doesn't improve after adjusting width/height here, double-check that these values actually match the resolution of the latent_image you're feeding the sampler downstream, a mismatch between what this node thinks the target size is and what the sampler is actually generating defeats the point of setting them. Applying this node to a non-Flux BIZYAIR_MODEL won't produce a useful result either, the shift values here are specifically calibrated to Flux's training, not a general-purpose tool.

As with every node in the pack, a run that stalls or fails with no clear workflow cause almost always traces back to the API key. Separately: BizyAir occasionally ends up installed without you asking for it when ComfyUI Manager misresolves an unrelated missing-node error on an older shared workflow, that's a real quirk, not malware, and removable through the Manager.